PUC

ISSN 0103-9741 Monografias em Cincia da Computao n 13/03

Acompanhamento de Projetos

Arndt von Staa

Departamento de Informtica

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO RUA MARQUS DE SO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL

PUC RIO - DEPARTAMENTO DE INFORMTICA Monografias em Cincia da Computao, N 13/03 Editor: Carlos J. P. Lucena

ISSN 0103-9741

Maio, 2003

Acompanhamento de Projetos
Arndt von Staa

Responsvel por publicaes: Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentao e Informao PUC-Rio Departamento de Informtica Rua Marqus de So Vicente, 225 - Gvea 22453-900 Rio de Janeiro RJ Brasil Tel. +55 21 3114-1516 Fax: +55 21 3114-1530 E-mail: bib-di@inf.puc-rio.br

Acompanhamento de Projetos
Arndt von Staa
arndt@inf.puc-rio.br Departamento de Informtica Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio) Rua Marqus de So Vicente 225, Gvea 22453-900 Rio de Janeiro, RJ, Brasil PUC-Rio.Inf.MCCxx/aa Ms/Ano Abstract: In this article we examine some of the more relevant features of project tracking tools. It is not our intention to design the best possible tool, if such a thing exists. Rather we aim at providing a set of guidelines that may help a software development manager to choose among available tools. Of course the sketches may also be used as the starting point of a tool development project. Following three tools will be outlined: time sheet; problem recording and tracking; and configuration item registering and tracking. The three tools can be integrated. If integrated, they help to reduce the effort to acquire tracking data. In this way we expect that more reliable project tracking data could be gained. An interesting side effect is the possibility to gather data that helps finding the true causes of quality and productivity problems. Keywords: Artifact registering, Configuration management, Problem tracking, Software development plan, Software process, Time sheet.

Resumo: Neste artigo procuraremos identificar as propriedades mais relevantes das ferramentas de acompanhamento de projetos de desenvolvimento de software. No pretendemos especificar o melhor conjunto de ferramentas possvel, se que isto existe. Queremos somente caracterizar propriedades que ferramentas adequadas deveriam ter. Ou seja, os esboos podero ser utilizados como critrios de avaliao de ferramentas existentes. Embora no seja objetivo principal, claro que, alm de servir como critrios para a escolha de ferramentas, os esboos podero ser utilizados como ponto de partida para o desenvolvimento de ferramentas de apoio ao acompanhamento de projetos de software. Sero esboadas trs classes de ferramentas: a folha de tempo, o acompanhamento de problemas e o registro e acompanhamento de itens de configurao. Estas trs ferramentas podem ser integradas. Atravs da integrao pode-se reduzir o esforo de aquisio de dados, aumentando, assim, a chance de se ter um acompanhamento fiel do desenvolvimento em progresso. Em muitas ocasies a coleta de dados tambm permitir identificar as causas sistmicas dos problemas de qualidade e produtividade. Palavras chave: Acompanhamento de problemas, Folha de tempo, Gerncia da configurao, Plano de desenvolvimento de software, Processo de desenvolvimento de software , Registro de artefatos.

1. Introduo
lugar comum iniciar artigos que tratam de engenharia de software dizendo que o desenvolvimento de software est em crise, uma vez que um nmero considervel de projetos, ou no concluram no prazo ou no produziram sistemas com qualidade tal que possam ser utilizados a contento. Para substanciar esta afirmao, cita-se um percentual de projetos mal sucedidos extrado de algum artigo, sem questionamento algum quanto poca em que a estatstica foi coletada, a forma de sua obteno e a natureza das organizaes provocadoras da catstrofe. Seguem-se propostas para a soluo do problema1. Infelizmente estas propostas so exatamente isto: propostas, uma vez que raro terem sido avaliadas com o cuidado que merecem. Existem autores que contestam essa viso calamitosa. Hoje difcil encontrar alguma atividade humana que no dependa de alguma forma de software. A rede de distribuio de energia, as redes de televiso e telecomunicaes, os bancos, os aparelhos de monitorizao de pacientes, os tomgrafos, os avies, os trens, os carros, os aparelhos auditivos digitais, os controles remotos e uma mirade de artefatos ou sistemas, todos so computarizados. No somente isto, software tornou-se uma indstria que movimenta centenas de bilhes de dlares ao ano. Ora se software fosse to ruim assim, isso tudo no seria possvel. Por outro lado, no h dvida que existem problemas, alguns de longa data, carecendo de soluo adequada at hoje. Boehm e Basili [BB 2001] mencionam que fazem mais de 15 anos que se recomenda identificar faltas o mais cedo possvel, uma vez que o crescimento do custo de sua remoo cresce com expoente maior do que 1 com relao ao tempo decorrido entre o instante em que ocorre o erro que introduz a falta e o instante em que ela estar completamente removida. Estes mesmos autores dizem que a remoo de faltas detectadas aps a entrada em servio podem custar at 100 vezes mais do que o que custaria a remoo durante o desenvolvimento. Na realidade pode-se dizer que fazem mais de 30 anos que se recomenda a preveno de faltas, pois j por volta de 1969 era proposto o uso de prova da corretude de programas como um instrumento de preveno de faltas [Floyd 1967, Hoare 1969]. Para muitos o problema de produzir sistemas de qualidade satisfatria2 reside na forma de gerenciar projetos. Tem autores que afirmam que, utilizando processos apropriados, perfeitamente possvel conseguir-se realizar um nmero expressivo de projetos dentro dos oramentos estipulados e produzindo resultados com qualidade satisfatria [BABCCHMRS 2000, Humphrey 1989, Humphrey 1995, Humphrey 2000, PWCC 1995]. Esmiuando-se as explicaes de todos esses autores, temos que, na realidade, so 3 os principais fatores: gesto, disciplina e proficincia da equipe. O emprego de pessoal sem adequada formao, sem oferecer treinamento local nos padres e processos da organizao, sem dar oportunidade de aperfeioamento contnuo, e a prpria inexistncia de padres e processos devidamente documentados, inegavelmente um fator que contribui para a crise do software [Cockburn 2001]. Na realidade no crise do setor de software, , sim, crise na organizao que utiliza pessoas sem adequada proficincia por

H muito [Brooks 1986] afirmava no acreditar que algum fosse capaz de produzir a bala de prata (leia-se tecnologia ou metodologia) capaz de matar o lobisomem (leia-se a crise de software). Um artefato que possui qualidade satisfatria adequado e no possui faltas nem deficincias do ponto de vista dos usurios, clientes e desenvolvedores. Tampouco possui excesso de qualidade encarecendo inutilmente o artefato.
1

uma razo de falsa economia. crise de organizaes que no investem em padres, na explicitao dos processos que usam e nem na memria quanto realizao de projetos passados. o tipo de economia que acaba saindo cara. O programador, ou analista, que abomina padres, que adora trabalhar em horrios no convencionais, que altera artefatos sem avisar os outros, que considera especificaes serem de pouca utilidade, que no procura entender o porqu das coisas que est fazendo ou usando, outro gerador de crise. Indisciplina h muito vem sendo citada como uma das grandes causas para a crise de software. Artigos publicados na dcada de 70 j apontavam isto. Existem at propostas tipo Cleanroom [MDL 1987] em que a imposio de disciplina levada a um extremo. Mesmo a atualmente to badalada Extreme Programming [Beck 1999, Wake 2001], apesar de parecer uma volta aos ureos tempos da programao herica, depende fortemente de disciplina de trabalho e obedincia a padres e a processos estabelecidos. Existem vrios tipos de gerentes de projeto. Caracterizarei somente 3. O mais danoso o ditador. Este tipo de gerente determina quem far o que, quanto tempo poder utilizar para faz-lo, quantos recursos poder utilizar, etc. Quem faz as estimativas ele. Tipicamente utiliza sistemas de planejamento e controle de projetos, gera belssimos diagramas de Gantt que ningum leva a srio, quase invariavelmente no termina dentro de prazos ou custos, pois assumiu compromissos para agradar o chefe ou o setor de marketing. Outra categoria de gerente o coordenador. Este ouve os que realizaro as tarefas e d a eles a autoridade para o dimensionamento de prazos e necessidades de recursos. Acompanha a execuo e promove revises das estimativas sempre que observar desvios sistemticos ou significativos. Tambm utiliza diagramas de Gantt mas que passam a ser levados a srio pois representam compromissos viveis assumidos pelos desenvolvedores. Este tipo de gesto preconizada por CMM e outros [PWCC 1995, FSM 1998]. Os projetos costumam ser realizados dentro dos prazos e custos estabelecidos na ltima reviso dos planos. Finalmente, o terceiro o facilitador. Este se preocupa em facilitar e agilizar o trabalho. O estabelecimento de prazos e necessidades de recursos est estritamente ao cargo dos desenvolvedores. Para reduzir os riscos utiliza-se o desenvolvimento incremental, em que cada incremento requer de 3 a 6 meses para ser completado. Esta forma de gesto proposta pelas metodologias geis [Cockburn 2001, Highsmith 2002], em particular por Extreme Programming [Beck 1999, BF 2000] e tm a virtude de serem altamente adaptveis s mudanas que vo surgindo no decorrer do projeto. Tambm aqui prazos e recursos so respeitados, uma vez que o escopo de cada incremento ser diminudo sempre que se observar que no ser possvel atingir a meta estabelecida. Evidentemente o segredo para o acerto das estimativas est nas revises dos planos e/ou do escopo do projeto e que ocorrem com alguma freqncia. Mas para isto necessrio um sistemtico acompanhamento do desenrolar do projeto, confrontando continuamente o que est sendo realizado com o que se esperava que fosse realizado conforme registrado no plano. No restante deste artigo examinaremos em mais detalhe aspectos relacionados com o acompanhamento de projetos de desenvolvimento de software. Na seo 2 so resumidamente abordados o que se entende por plano, processo definido do projeto e metaprocessos. Na seo 3 so abordados os conceitos bsicos de acompanhamento de projetos. Na seo 4 so esboadas as ferramentas folha de tempo, registro e acompanhamento de problemas, e registro e acompanhamento de itens de configurao. A seo 5 conclui o artigo.

2. Planos, processos definidos e meta-processos

Ao desenvolver software lidamos com duas grandes categorias de conceitos: processos e artefatos. Um artefato qualquer resultado tangvel (existe sob a forma de papel ou arquivo de computador), composto ou no, fruto da realizao de uma ou mais atividades. So exemplos: mdulos de programas, manuais, arquivos contendo auxlio on-line, especificaes, planos, logs de teste, cadernos de anotao de problemas, folhetos de propaganda, bases de dados histricos, etc. Artefato um conceito recursivo. Assim o sistema como um todo um artefato. Os programas, manuais, bases de dados etc. que o constituem so tambm artefatos, e assim por diante. No nvel elementar um artefato um arquivo (por exemplo: xxx.java) ou documento (por exemplo: o caderno de anotao de problemas). O objetivo de um projeto de desenvolvimento , portanto, criar um conjunto harmonioso3 de artefatos que juntos implementam satisfatoriamente a aplicao almejada. Um plano de desenvolvimento pode ser visto como um programa que ser executado por diversas pessoas ao invs de s-lo por um autmato. Nas disciplinas de sistemas de computao aprende-se que bastante complexa e sujeita a panes a programao de sistemas distribudos (vrios processadores cooperando para realizar um determinado clculo). exatamente isto que um plano um sistema distribudo , com pelo menos mais trs agravantes: i. no poder ser testado antes de ser posto em uso. Diferente de um programa, um plano ser executado exatamente uma vez e, nesta nica vez, tem a obrigao de dar certo. Isto , deve produzir o sistema desejado com qualidade satisfatria e dentro dos prazos e custos estimados. Quem programa sabe como difcil escrever programas complexos que estejam corretos antes do primeiro teste. ii. o executor no um autmato e, portanto, difcil, se no impossvel, estabelecer a priori a confiabilidade dos resultados, tampouco possvel determinar com exatido a necessidade de tempos e de recursos; iii. o plano alterado durante a sua execuo em funo do conhecimento adquirido ao execut-lo (mudanas de requisitos, mudanas de arquitetura, etc.), e de problemas4 observados durante a sua execuo (erros sistemticos de estimativas, rotao de pessoal, etc.). Alm disso projetos so sujeitos a muitos imprevistos (falta de energia, quebra de equipamento, doenas, etc.). Note que uma das primeiras recomendaes em disciplinas de engenharia de software que os programas no devem modificar a si prprios, pois tornam virtualmente impossvel saber, atravs de inspees, se podero produzir o resultado desejado. Mas exatamente isso o que acontece com planos. claro que isso mostra que planejar o desenvolvimento de um determinado software quase uma misso impossvel, se no forem tomadas algumas precaues. Uma das precaues a de desenvolver um meta-plano a ser instanciado, produzindo um plano de desenvolvimento de uma aplicao. A instanciao se d com base nas caractersticas do ambiente de desenvolvimento e da aplicao a desenvolver. Utilizando a terminologia de CMM [PWCC 1995, FSB 1998] um tal meta-plano o Processo de Software

Um conjunto harmonioso de artefatos formado por artefatos que no guardam contradies, conflitos ou inconsistncias entre si. Entendemos por problema coletivamente qualquer relato de falha, relato de defeito ou solicitao de adaptao, melhoria ou evoluo.
3

Definido do Projeto. Este um processo de software estabelecido e bem caracterizado visando determinados domnios de aplicao5 e/ou de soluo6, descrito em termos de padres, procedimentos, ferramentas e mtodos de desenvolvimento de classes especficas de artefatos. As definies de processos podem variar desde um simples esquema (estrutura de tarefas genricas) at uma complexa mquina de estados indicando todas as tarefas e as respectivas pr e ps-condies, todos os tipos de artefatos a serem produzidos e respectivos critrios de aceitao, todas as ferramentas a serem utilizadas, todos os padres a serem respeitados e todos os papis a serem desempenhados pelas pessoas que realizaro as tarefas. Processos so instanciados caso a caso, estabelecendo o plano de desenvolvimento de um projeto especfico. Pelo fato de estarem documentados e amparados em dados histricos, os processos reduzem significativamente os riscos de produzir planos incompletos ou no realizveis. Cabe ressaltar que podero existir vrios processos de software definidos em uma mesma organizao. Isto decorre do fato desses processos visarem explicitamente determinados domnios. Infelizmente, existe o risco de se estabelecer processos definidos, que sistematicamente produziro maus planos. Para reduzir este risco pode-se utilizar meta-processos. Estes so processos genricos que determinam as caractersticas que qualquer processo especfico deve satisfazer. A instanciao de um meta-processo visando um determinado domnio resulta no processo de software definido do projeto. So exemplos de meta-processos o CMM [PWCC 1995, FSB 1998] e o SPICE [SPICE 1998]. Faz parte do meta-processo dizer como o processo instanciado ser avaliado quanto sua eficcia e eficincia. Tambm faz parte dizer como ser evoludo caso apresente problemas ou se torne tecnologicamente defasado. Caso o meta-processo, os processos dele derivados e os planos instanciados a partir desses processos tiverem sido gerados com cuidado e caso eles sejam sistematicamente revisados, aumenta-se a capacitao da organizao que os utiliza a produzir software de qualidade satisfatria dentro dos limites de tempo e recursos estipulados. essencialmente esta a idia que est por trs de normas tipo CMM e SPICE. Infelizmente, o fato de no existir uma teoria adequada para validar a eficcia destes trs artefatos e do processo de derivao, faz com que nem sempre esta forma de atuar seja coroada de xito. Os artefatos bem como os respectivos processos de instanciao so criados empiricamente a partir da experincia profissional de vrias pessoas. Isto no quer dizer que no possam levar a bons resultados. Quer dizer somente que no se consegue ter certeza de atingir bons resultados em cada projeto. Quer dizer tambm que determinadas pessoas ou organizaes tero mais sucesso do que outras, uma vez que o resultado depende da proficincia e de caractersticas individuais dos membros da equipe.

3. Acompanhamento
Infelizmente, a obedincia a um plano de boa qualidade no assegura que o resultados, isto os artefatos produzidos, sejam de qualidade satisfatria. Tampouco assegura um desenrolar eficiente do processo. Isto decorre do fato dos executores serem pessoas, dos planos
5

Domnio de aplicao identifica a rea em que se situa a aplicao, por exemplo: sistemas de controle de estoque, sistemas de comando e controle, sistema de controle de processos qumicos, sistemas de registro acadmico. Domnio de soluo identifica a tecnologia utilizada para implementar os software, por exemplo: cliente / servidor; orientado a objetos; baseado em mltiplos agentes distribudos.
4

evolurem durante a execuo, da distribuio de tarefas e de uma grande gama de imponderveis. Como j foi insinuado, as causas do mau funcionamento podem residir tanto na execuo (erros de pessoas ou instrumentos), como tambm no prprio plano, ou pior, nos processos, meta-processos e processos de instanciao. Isto nos obriga a conduzir freqentes avaliaes quanto corretude dos artefatos e da execuo do plano, bem como do acerto do prprio plano. Acompanhamento o processo de monitorar a execuo de um plano. Segundo CMM acompanhar projetos tem os seguintes objetivos: Acompanhar os resultados e desempenhos reais confrontando-os com o plano de desenvolvimento de software. Tomar aes corretivas e gerenci-las at sua concluso, sempre que resultados ou desempenhos reais desviarem significativamente do que foi estabelecido (estimado) no plano de desenvolvimento de software. Assegurar que as alteraes nos compromissos de software se dem atravs de acordo entre as pessoas e os grupos envolvidos.

Na realidade devemos estender estes objetivos de modo que no somente os planos sejam controlados, mas tambm os processos e meta-processos. Temos ento mais um objetivo: Acompanhar processos e meta-processos obtendo indicadores quanto sua eficcia em instanciar planos e processos7.

Ao redigir programas complexos fortemente recomendado que sejam inseridas assertivas executveis no cdigo. Estas verificam, durante a execuo do programa, se o estado do programa no ponto onde se encontra a assertiva corresponde a um estado vlido. Caso o estado encontrado durante a execuo no seja vlido, sinalizada a ocorrncia de um problema. Da mesma forma o acompanhamento de um plano de projeto somente auxiliar no controle da sua execuo, caso contenha indicaes claras do que esperado em pontos de controle e marcos. Estas indicaes esto substanciadas no plano, devendo escalonar o desenvolvimento dos artefatos, estabelecer os prazos e recursos disponibilizados para cada tarefa, explicitar os critrios de aceitao e os mtodos de verificao da qualidade dos artefatos (pr e ps condies das tarefas). De tudo o que foi dito fcil concluir que o acompanhamento poder ocorrer em variados graus de granularidade, bem como pode focar uma variedade de propriedades de um plano. Isto explica a grande variedade de propostas do que seria um bom plano e de ferramentas de acompanhamento e medio existente no mercado. Explica tambm a superficialidade com que freqentemente o assunto tratado na literatura.

4. Formas de acompanhamento
Nesta seo discutiremos algumas formas de acompanhamento. No pretendemos nem exaurir o assunto, nem definir a melhor de cada uma das formas. Pretendemos meramente raciocinar sobre a necessidade e o porqu de cada forma de acompanhamento. O objetivo fornecer critrios para gerentes e equipes tcnicas capazes de auxili-los ao selecionar as ferramentas e tcnicas mais adequadas s suas necessidades.

7 Para simplificar a redao estamos utilizando o termo processo para denotar o Processo de Software Definido do Projeto e meta-processo para denotar o processo padronizado pelo CMM ou SPICE.
5

4.1. Folha de tempo A folha de tempos visa a medio do esforo dos executores de um plano. Tipicamente relaciona as atividades realizadas por um executor em determinado dia. Uma atividade qualquer ao executada por determinada pessoa. As atividades incluem todo o trabalho que o corpo tcnico e gerencial realiza para desempenhar tarefas do projeto e da organizao. Atividades podem ser recorrentes, bem como podem ter nada a ver diretamente com o projeto, como, por exemplo atividades pessoais, participar em treinamento, ou registrar medies em planilhas de acompanhamento. So exemplos de atividades: redigir a especificao de um mdulo, redigir o cdigo de um mdulo, inspecionar um mdulo, refatorar8 um mdulo, testar um mdulo, redigir um captulo de um documento, registrar tempo na folha de tempo, participar de uma reunio, explicar o sistema para usurios, resolver problemas particulares. O registro do esforo fundamental para poder-se estimar prazos e recursos necessrios em projetos futuros. necessrio tambm para se verificar se existem erros de estima sistemticos no plano. Como j foi mencionado, um plano um artefato vivo, no sentido que evoludo no decorrer de sua execuo. No entanto, no basta registrar-se a durao das atividades, o registro deve estar relacionado com o plano de desenvolvimento. Alm disso deve servir ainda de subsdio para controlar o desempenho do ambiente9 e da equipe de desenvolvimento. Do ponto de vista de planejamento, atividades nem sempre so de interesse, uma vez que no necessariamente conduzem a um resultado de qualidade controlada. Usualmente um plano estabelecido em termos de tarefas10. Uma tarefa uma unidade de trabalho bem definida no processo de software. O incio e a concluso de uma tarefa fornecem gerncia um ponto de controle visvel do progresso do projeto. Tal como projetos, tarefas tm incio e fim e no so recorrentes. Tarefas esto associadas a artefatos e possuem uma estrutura recursiva semelhante destes. Tarefas podem ser realizadas atravs de uma ou mais atividades cada qual envolvendo uma ou mais pessoas. So exemplos de tarefas: produzir um mdulo a ser aceito segundo algum critrio explicitamente definido no plano; produzir um documento (manual) a ser aceito segundo algum critrio explicitamente definido no plano. As tarefas tm critrios de prontido (pr-condies) e critrios de finalizao (pscondies, critrios de qualidade, padres) [IEEE 1990]. As condies de prontido precisam estar satisfeitas para que a tarefa possa ser iniciada. As condies de concluso devem estar asseguradas ao terminar a tarefa. Tal como em programao, pode-se verificar se a seqncia de execuo de um plano vivel comparando as condies de concluso com as condies de prontido de tarefas consecutivas. Os critrios de aceitao devem ter uma parcela estabelecida atravs de padres publicados. A outra parcela estar vinculada s caractersticas especficas do produto sendo desenvolvido. Exemplo de critrio de prontido: especificao do mdulo ABC aceita segundo o padro X verificado atravs de inspeo.

Refatorar (refactoring) a atividade de reorganizar um ou mais mdulos de modo que as interfaces e a estrutura interna dos mdulos tornada mais manutenvel. Proceder ao refatoramento aumenta a evolutibilidade do mdulo [Fowler 2000]. Uma idia similar pode ser aplicada a outros artefatos, tais como auxlio, documentao, arquiteturas e modelos. O ambiente de desenvolvimento formado por processos, procedimentos, mtodos, ferramentas, plataformas de desenvolvimento e uma variedade de bases de dados utilizadas para registrar as medies e os artefatos. Muitos sistemas de planejamento e controle de projetos utilizam o termo atividade para o que entendemos aqui por tarefa.
6

10

Exemplo de critrio de concluso: o mdulo ABC, o correspondente mdulo de teste especfico e os arquivos de script de teste esto disponveis e foram verificados segundo o padro Y. A distino entre tarefas e atividades necessria. Considere o desenvolvimento de um mdulo. O cdigo estar redigido no indica que possa ser utilizado. Tampouco ter sido testado suficiente para indicar que possa ser utilizado. Enquanto no estiver completamente redigido, inspecionado, testado, integrado e aceito segundo os critrios estabelecidos, o mdulo no existe do ponto de vista do restante do projeto. Evidentemente, a produo do mdulo pode envolver vrias pessoas e levar vrios dias. A tarefa ento produzir mdulo W aceito segundo padro X, a especificao Y e o teste Z. Esta tarefa formada por vrias atividades que sero registradas nas folhas de tempo de quem tiver realizado a atividade. Note que uma atividade pode ser realizada por vrias pessoas (ex. atender a uma reunio de inspeo), mesmo assim ela figurar na folha de tempo de cada uma das pessoas que participaram na atividade. Por exemplo, no processo Extreme Programming exigido que programas sejam codificados por duas pessoas trabalhando juntas em um mesmo computador [Beck 1999]. exigido, ainda, que os testes sejam redigidos antes de se iniciar o desenvolvimento dos mdulos. Ao registrar as atividades de um dia pode-se registrar ainda: uma descrio resumida do que foi feito e das dificuldades encontradas ao realizar a atividade. A anlise deste texto livre permitir extrair informaes relevantes e recorrentes que, no futuro, deveriam ser solicitadas explicitamente. Desta forma podese evoluir gradualmente o sistema de folha de tempo mantendo a sua adequao s caractersticas especficas da organizao. Ao aplicar GQM Goal Question Metric [BR 1988, GHW 1995] fortemente recomendado que sistemas de medio sejam estabelecidos somente quando se sabe para que medir. Caso contrrio provavelmente o esforo gasto na medio ser desperdiado uma vez que as medidas no sero utilizadas para aprimorar o ambiente. natureza da atividade, como por exemplo: estudo, especificao de mdulo, codificao, redao dos casos de teste, realizao dos testes, depurao, alterao do cdigo, refatorao, reviso final do mdulo. As possveis naturezas devem ser estabelecidas pela gerncia de projetos. Esta forma de definir atividades permite utilizar como nome da atividade o nome da tarefa, especializando esta para uma atividade atravs da sua natureza. Permite tambm realizar estudos sobre as naturezas de atividades que mais consomem tempo. Se, por exemplo, a equipe de desenvolvimento gasta muito tempo em depurao, conveniente providenciar treinamento e, possivelmente, acrescentar ferramentas de controle da qualidade do cdigo fonte ao acervo do ambiente. Depois, pode-se verificar se as mudanas no ambiente e no processo surtiram o desejado efeito de reduo do tempo gasto em depurao. artefatos criados ou alterados pela atividade. De maneira geral espera-se que uma atividade somente altere os artefatos resultantes da tarefa qual pertence a atividade. No entanto, ao desenvolver um artefato a sua interface pode ser modificada. Isto obriga um ajuste em todos os artefatos interrelacionados com o artefato em produo. Por sua vez, isto pode acarretar uma considervel propagao de alteraes. Os artefatos criados ou alterados deveriam aparecer nas ps condies da tarefa. Note que isto reala a dificuldade de se estabelecer corretamente as condies de prontido e as de concluso.

artefatos utilizados. Artefatos utilizados so artefatos necessrios para realizar a atividade e que podem ou no ser afetados pela atividade. Por exemplo, ao redigir o cdigo de um mdulo, em princpio a sua especificao no deve ser alterada. O registro de artefatos utilizados e de artefatos alterados, evidencia uma relao de dependncia entre artefatos. Manter esta relao nos bancos de dados do projeto bastante interessante para a tomada de deciso de passos de manuteno futuros. O conjunto de todos os artefatos utilizados ou alterados deveria aparecer nas pr condies da tarefa, enquanto que o de artefatos alterados ou gerados deveria aparecer nas ps-condies da tarefa. artefatos podem, na realidade devem, ser reutilizados. Conseqentemente uma tarefa poder estar desenvolvendo artefatos pertinentes a mais de um projeto. conforme ser discutido na seo a seguir, uma atividade tambm deve referenciar as FAP Ficha de Acompanhamento de Problema a que diz respeito [FS 1998].

A figura a seguir esboa o diagrama de classes para uma folha de tempo.

Data 1 n Pessoa 1 n Folha 1 n n 1 n n Atividade n n n n FAP 1 Natureza

Projeto

Tarefa n n Artefato

Figura 1. Esboo da estrutura de classes do subsistema folha de tempos

4.2. Acompanhamento de problemas Uma das dificuldades que assedia o desenvolvimento de software assegurar a integridade dos sistemas em face s contnuas alteraes. Por mais que se tome cuidado ao especificar sistemas, inevitvel que estas venham a ser alteradas [Beck 1999, Lehman 1998, LB 1985], ainda mesmo durante o desenvolvimento. Isto indica que, na realidade, o desenvolvimento de software um processo de amadurecimento no qual, atravs de vrias iteraes, se converge para o sistema desejado. Ou seja, problemas sempre surgiro, tornando necessrio o seu registro e o acompanhamento at que tenham sido completamente resolvidos. Ao acompanhar deve-se procurar identificar as causas. Se estas forem sistemticas deve-se alterar o processo, ou o meta-processo, de modo que em projetos futuros no mais ocorra esta classe de problemas. Em [BB 2001] Boehm e Basili afirmam que cerca de 40 a 50% do esforo de um projeto consumido em retrabalho desnecessrio. Infelizmente esta estatstica no menciona a frao que se deve a erros de desenvolvimento, nem a frao devida s mudanas de especificao que poderiam ter sido evitadas se a especificao tivesse sido mais cuidadosa. Nem todo o retrabalho desnecessrio. Quando for seguido um processo de desenvolvimento incremental, uma das regras bsicas manter a complexidade instantnea
8

a menor possvel. Isto fortemente sugerido nos processos geis, tais como Extreme Programming [Beck 1999, Cockburn 2001] e no ciclo de vida espiral [Boehm 1988]. Desta forma os artefatos so desenvolvidos visando estritamente a iterao corrente. Evidentemente que, medida que se vai evoluindo de incremento para incremento, pode-se ter a necessidade de alterar artefatos j concludos no passado. Neste caso sempre recomendado proceder a uma reviso rigorosa da organizao interna dos artefatos atravs de uma refatorao [Beck 1999, Fowler 2000]. Isto assegurar a evolutibilidade do artefato no futuro. Cabe salientar que diversas estatsticas evidenciam que manuteno sucessiva de artefatos leva sua deteriorao estrutural, a menos que se realize um esforo consciente de reorganizar a sua estrutura. necessrio, ento, controlar e coordenar as alteraes e, ainda, identificar instncias de retrabalho evitvel e as respectivas causas. O simples uso de um sistema de controle verses no suficiente, uma vez que pouco ou nada informa sobre as causas das alteraes. O objetivo destes sistemas possibilitar, sempre que necessrio, a reconstruo automtica das vrias verses de um artefato. Mas o que queremos registrar os problemas, identificar as suas causas e acompanhar a sua resoluo at que estejam completamente resolvidos. Queremos, ainda, viabilizar o acompanhamento de problemas pelos diferentes interessados, tais como usurios, clientes, gerentes e desenvolvedores. Finalmente, desejamos que os desenvolvedores afetados pela alterao de um artefato sejam informados desta alterao, evitando o retrabalho despendido ao ajustar os artefatos conseqentes s alteraes de um ou mais dos seus artefatos antecedentes. Problemas so registrados por algum observador. Este pode ser uma pessoa pertencente equipe de desenvolvimento, bem como qualquer pessoa externa a ela como, por exemplo, o usurio. Problemas podem ser registrados em logs de teste automatizado. Neste caso o observador formado pelos casos de teste que evidenciaram o problema.
Critrios e padres de controle da qualidade

Histrico de alteraes

Histrico de alteraes

Artefatos antecedentes Especificao Criao

Artefato conseqente Artefato Alterao

Laudo

Controle da qualidade Gerncia da evoluo

Laudo

FAP

FAP

Outro artefato
FAP - ficha de acompanhamento de problema

FAP

Avaliao externa

Figura 2. Atividades ao realizar uma tarefa com controle da qualidade.

A Figura 2 mostra interao das atividades de desenvolvimento e manuteno com as de controle da qualidade e de acompanhamento de problemas. Um artefato conseqente pode
9

ser criado a partir de um ou mais artefatos antecedentes. Em geral estes so especificaes. Ao utilizar testes automatizados redigidos antes de se desenvolver [Beck 1999] existem pelo menos dois artefatos antecedentes, a especificao (conjunto de historietas, casos de uso) e o script de teste. Ao criar um artefato devem ser obedecidas as especificaes bem como diversos padres ou normas11 tcnicas. Uma vez criado o artefato, ele dever ter a sua qualidade controlada. Este controle gera um laudo. fortemente recomendado que o laudo seja um documento. So exemplos: logs de execuo de testes automatizados, artefatos contendo anotaes de inspeo, cadernos de anotao de problemas. No PSP (Personal Software Process) [Humphrey 1995] exigido que sejam registrados inclusive os erros de sintaxe de programas fonte, tais como falta de pontoe-vrgula. A justificativa que pessoas precisam saber que tm problemas para que tomem alguma iniciativa para resolver ou evit-los. Problemas recorrentes evidentemente merecem ateno especfica, j problemas espordicos so fruto do simples fato de humanos serem falveis12. Uma vez gerado um laudo deve ser decidido o que fazer. Entre as diversas possibilidades temos: resolver completamente o problema atravs da alterao do artefato, procedendo, a seguir a um novo controle da qualidade. Evidentemente isto configura retrabalho que, de maneira geral, seria evitvel caso o desenvolvimento fosse correto por construo. protelar a resoluo do problema para uma oportunidade mais tarde. Neste caso o problema registrado no laudo transformando numa solicitao de alterao. Todas as solicitaes de alterao, relatrios de falha ou defeito, solicitaes de adaptao, melhoria ou evoluo so registradas em uma ficha de acompanhamento de problema FAP [FS 1998]. relacionar o problema com algum dos artefatos antecedentes. Neste caso cria-se uma solicitao de alterao a ser vinculada a este artefato antecedente. registrar uma FAP a ser relacionada com um artefato especfico. Durante o desenvolvimento, teste, avaliao, ou uso podem ser identificados problemas relacionados com artefatos de elevado nvel de abstrao. Por exemplo, pode-se observar um problema no produto X e no no artefato que efetivamente contm a falta causadora. Como artefato um conceito recursivo, torna-se necessrio procurar o artefato especfico com o qual o problema deve ser relacionado para, somente ento, iniciar a sua resoluo.

Utilizando esta abordagem pode-se restringir a aceitao de um artefato ao fato do seu laudo estar vazio aps o controle da qualidade. Isto no quer dizer que no existam pendncias, quer dizer somente que as possveis pendncias esto registradas como solicitaes de alterao e podero ser resolvidas no futuro sem comprometer o uso do artefato neste momento. Uma vez um artefato tendo sido aceito, cria-se uma verso imutvel dele. Conseqentemente qualquer alterao a ser feita no futuro, mesmo as decorrentes de FAPs j conhecidas mas no concludas, gerar uma nova verso do artefato. Todas as verses de

11

Padres e normas embora similares, gozam de uma diferena relevante. Padres so desenvolvidos e mantidos por uma ou mais organizaes visando as suas necessidades especficas. J as normas so desenvolvidas e mantidas por rgos de normatizao (p.ex. ABNT, ANSI, DIN, ISO) e potencialmente afetam todas as organizaes que atuam no ramo de negcio visado pela norma. Errare humanum est, perseverare in errore est diabolicum.
10

12

um artefato, junto com uma explicao da causa do problema, so armazenadas no histrico de alteraes. Este usualmente implementado atravs de alguma ferramenta de controle de verso. A Figura 3, a seguir, mostra um possvel processo de tratamento de FAPs. Nesta figura os hexgonos representam estados em que a FAP espera por algum servio. J as elipses representam estados em que a FAP est sendo processada por alguma atividade. Os rtulos das arestas representam as condies finais das atividades, indicando qual o estado a seguir ao concluir a atividade com aquela condio. Todas as FAPs geradas, independentemente de sua origem, entram no estado Aguardando anlise inicial. De l progridem para o estado em anlise. O objetivo deste determinar se o problema deve ser resolvido imediatamente, se deve receber um tratamento emergencial, se se refere a um problema j resolvido ou idntico ao de outra FAP, se existe suficiente informao para poder iniciar a resoluo do problema, ou, finalmente, se se trata de um no problema a ser simplesmente ignorado.
Aguardando anlise inicial Em soluo emergencial

Incio

aprovada

no aprovada

Aguardando anlise

protelada falha grave Em anlise autorizada

Aguardando soluo emergencial

Aguardando informao dados insuficientes

Informao adicional recebida

Aguardando soluo

suspensa

Sendo resolvida

concluda Aguradando aprovao

dados insuficientes Aguardando informao cancelada j resolvida recusada aceita no aceita

no aprovada recusada

Sendo controlada aprovada Aguradando implantao

Fim

Sendo implantada

Figura 3. Processo de tratamento de uma FAP

Sempre que no possa ser dada uma soluo, a FAP volta ao estado Aguardando anlise. De tempos em tempos essas FAPs so reanalisadas. Esta nova anlise leva em conta o estado corrente do projeto e corrige possveis erros de anlise no passado. Quando a FAP entra no estado Aguardando soluo passa a ser responsabilidade da gerncia selecionar os recursos a serem utilizados para resolv-la. Desta forma estabelece-se um vnculo entre as atividades de planejamento e as de evoluo dos artefatos. A soluo dada a uma FAP deve sempre passar por uma aprovao. Uma vez aprovada, a nova soluo pode ser implantada, ou seja, tornada disponvel para os usurios e/ou os demais desenvolvedores. Especificaes podem ser alteradas durante o desenvolvimento. As conseqncias se materializaro sob a forma de novos laudos evidenciando os testes que falharam com relao artefatos conseqentes. Em processos geis problemas no so documentados explicitamente. Problemas de funcionalidade e confiabilidade surgem sob a forma de laudos de teste, sendo que os testes
11

devem ser automatizados [Beck 1999, Cockburn 2001]. Pouco dito quanto ao tratamento de solicitaes de alterao depois da entrega do sistema. A norma ISO/IEC 15504 [SPICE 1998] requer explicitamente o registro e o acompanhamento de problemas identificados durante o desenvolvimento e aps entrega. O CMM [PWCC 1995, FSB 1998] exige o registro durante o desenvolvimento, nada sendo dito com relao aos problemas aps a entrega. Do ponto de vista dos dados manipulados, uma FAP precisa registrar: a pessoa que originou a FAP e a pessoa que aceitou a soluo. Uma vez aceita a soluo, a verso aceita do artefato passada para a pessoa responsvel por armazenar os artefatos no sistema de controle de verso. Restringir o nmero de pessoas autorizadas a fazer isto tem a vantagem de assegurar o cumprimento de padres de desenvolvimento, teste e controle da qualidade. as verses dos artefatos resultantes da criao ou alterao realizada durante a resoluo do problema identificado na FAP. possvel que vrias FAPs sejam agregadas ao realizar um determinado passo de manuteno. Todas elas resultam em um ou mais artefatos criados, alterados, ou descontinuados. as verses dos artefatos inicialmente associadas FAP. Esta relao facilita o trabalho de anlise necessrio para corretamente associar uma FAP aos artefatos que efetivamente resolvero o problema identificado. as formas de identificar os problemas, por exemplo: teste, inspeo, uso. Esta informao tem por objetivo auxiliar na aquisio de dados estatsticos relativos ao instante em que so identificados problemas. Evidentemente se uma taxa grande de problemas for identificada aps a entrega, precisa-se tomar alguma ao de melhoria de processos para que tal no acontea mais. Infelizmente isto mais difcil do que se imagina. Em [BB 2001] Boehm e Basili dizem que 40 a 50% do software entra em produo contendo faltas no triviais.

Com vistas a uma integrao entre o sistema de acompanhamento e as folhas de tempo interessante que atividades relacionem as FAPs sendo resolvidas pela atividade. Desta forma a aquisio de dados de acompanhamento de esforo produzir tambm as relaes de interdependncia entre FAPs e artefatos efetivamente alterados. A figura a seguir esboa o diagrama de classes para o acompanhamento de problemas.
Estado progresso 1 1 Pessoa 1 aprova n n n n registra n n FAP n 1 Forma de observao Artefato inicial

n Atividade

Artefato

Causa

Figura 4. Esboo do diagrama de classes do subsistema de acompanhamento de problemas.

12

4.3. Registro de artefatos sempre conveniente registrar os artefatos e acompanhar a sua evoluo. Ao desenvolver sistemas maiores isto se torna imprescindvel. Estas aes so realizadas pela gerncia de configurao13. A finalidade da GCS Gerncia de Configurao de Software estabelecer e manter a integridade dos artefatos ao longo de todo o ciclo de vida do software. A GCS anda de mos dadas com o registro e acompanhamento de problemas. A GCS envolve: identificar a cada momento o estado dos itens de configurao de software. Itens de configurao so artefatos de software selecionados, acompanhados de sua descrio. controlar sistematicamente as mudanas na configurao. manter, atravs da gerncia, a integridade e rastreabilidade da configurao ao longo do ciclo de vida de software. controlar a integridade de artefatos compostos, levando em conta a verso de cada um dos componentes, ou seja, controlar a configurao do artefato composto. registrar e relatar o estado de progresso das FAPs. saber onde esto armazenadas, ou guardados os artefatos14.

Os artefatos colocados sob gerncia de configurao so denominados itens de configurao e incluem os artefatos que so entregues ao cliente (produtos), por exemplo, documentos de requisitos do software, o cdigo executvel e os manuais. Inclui ainda os artefatos gerados e utilizados no desenvolvimento mas que no so explicitamente disponibilizados para o usurio. So exemplos: projeto de arquitetura, casos de teste, mdulos fonte, compiladores e ferramentas de software. Cabe salientar que so itens de configurao, entre outros, as verses de compiladores e das ferramentas CASE utilizadas. Isto se deve ao fato destes itens serem cruciais para o desenvolvimento. Em caso de acidente deve ser possvel reconstruir corretamente o ambiente de modo que se evite a perda de continuidade no desenvolvimento. Finalmente, cabe salientar que nem todos os artefatos so itens de configurao. medida que se desenvolve o software, so identificados os itens de configurao e so estabelecidas baselines, para dar maior segurana ao desenvolvedor e permitir maior controle do desenvolvimento. Baseline um item de configurao formalmente analisado, revisado e aprovado, que serve de base para o desenvolvimento posterior. , portanto, um marco de referncia no desenvolvimento de software, caracterizado pela entrega de um ou mais itens de configurao aprovados por meio de uma reviso tcnica formalmente definida [Pressman 1995]. Os artefatos que constituem uma baseline podem ser alterados somente atravs de procedimento formal de controle de alteraes [IEEE 1990]. Uma baseline , ento, uma verso estvel de um artefato composto, contendo todos os componentes que constituem este artefato em um determinado momento. A Figura 5 esboa o processo de gerncia da configurao. Surgindo a necessidade de realizar uma alterao envolvendo um ou mais itens de configurao o grupo de pessoas responsveis pela GCS realiza o check-out (retirada) dos itens requeridos, copiando-os do sistema de controle de verses onde se encontra o artefato para uma rea de trabalho. feita
13

No contexto de Gerncia da Configurao uma configurao o conjunto de caractersticas fsicas e funcionais de hardware e software conforme estabelecidas em algum documento tcnico ou realizadas por um produto. [IEEE 1990] Nem todos os artefatos sero armazenados em algum meio computacional. Alguns sero documentos papel guardados em algum arquivo.
13

14

a alterao. Aps, realizado o controle da qualidade dos artefatos alterados. Caso estes sejam aprovados realizado o check-in (incorporao) dos itens transferindo-os da rea de trabalho para o sistema de controle de verses. Simultaneamente os itens so removidos da rea de trabalho. Ao inserir um artefato na base de verses criada uma nova verso deste. Assegura-se, assim, a possibilidade de recuperar qualquer uma das verses anteriores de um determinado item.
Criao Registro de artefatos Arquivos Artefato no controlado Registrar artefato Aceito Controlar artefato No aceito Criar artefato rea trabalho Armazenar artefato Tipo artefato Check-out Item de configurao Item de configurao Alterar artefato Controle de verso Item de configurao Check-in Trabalho concludo

Artefato no controlado

Editar artefato

Alterao autorizada

Figura 5. Esboo do processo de gerncia da configurao

No caso de artefatos no controlados, o processo simplificado desconsiderando-se as etapas de check-in e check-out. Para poder localizar os artefatos e diferenciar a sua natureza necessrio registrar os artefatos. Este registro pode conter informaes complementares para facilitar a localizao de um artefato caso existam muitos, ou caso seja desejado ver se possvel reutilizar algum existente. Uma das atividades bsicas da gerncia de configurao o registro de todos os artefatos, indicando aqueles que constituem itens de configurao. Ao registrar um artefato deve-se identificar todos os seus componentes, caso seja composto. Na realidade deve-se registrar, para cada verso de um artefato, as verses dos artefatos que o constituem, assim cada verso de um artefato poder ser reconstrudo a partir das verses de seus componentes. Alm de conhecer a composio de um artefato necessrio conhecer as relaes de precedncia. Ou seja necessrio saber quais so os artefatos conseqentes de um determinado artefato. Isto permitir verificar o impacto que uma alterao em um artefato pode ter sobre o sistema como um todo. Facilita, tambm, o rastreamento das propriedades identificadas em um dado artefato nos seus artefatos subseqentes. Finalmente processos modernos utilizam freqentemente ferramentas que geram artefatos completos ou esqueletos a partir de outros. importante tambm saber quais so os artefatos gerados a partir de determinado artefato e quais as ferramentas utilizadas para tal.

14

Projeto

Estado do artefato 1 depende de gera composto por

Tarefa

n 1 1 1n n Artefato n n n nn

n Atividade n FAP

Figura 6. Esboo do diagrama de classes do subsistema de registro de artefatos.

5. Concluso
Neste artigo procuramos identificar as propriedades mais relevantes das ferramentas de acompanhamento de projetos de desenvolvimento de software. Cabe observar, mais uma vez, que no pretendamos especificar a melhor ferramenta possvel, se que isto existe. Queramos to somente caracterizar propriedades que ferramentas deveriam ter, de modo que se disponha de critrio de escolha para ferramentas existentes. Alm de servir como critrios para a escolha de ferramentas, evidentemente os esboos podem ser utilizados como ponto de partida para o desenvolvimento de ferramentas de apoio ao acompanhamento de projetos de software. claro que muitas lacunas devero ser preenchidas de modo que se possa disponibilizar um conjunto de ferramentas adequado organizao. Foram esboadas trs classes de ferramentas: a folha de tempo, o acompanhamento de problemas e o registro e acompanhamento de itens de configurao. Estas trs ferramentas podem, e devem, ser integradas. Uma vez disponibilizadas, dever-se-ia ser capaz de evoluilas de modo que se possa adicionar medies, bem como extrair as estatsticas relevantes para uma determinada organizao. Esta forma incremental de desenvolvimento particularmente interessante por facilitar a identificao dos problemas efetivamente vividos pela organizao [BR 1988, GHW 1995, LSOHR 1998]. Utilizando um gerador de aplicaes foi desenvolvido um prottipo de sistema de acompanhamento no Departamento de Informtica da PUC-Rio, evidenciando a utilidade de uma ferramenta integrada, apesar da baixa qualidade de sua interface de usurio. Est em progresso o desenvolvimento de um novo conjunto de ferramentas que, esperamos, possa ser utilizado em escala maior. Esta ferramenta ser eventualmente disponibilizada como freeware.

Referncias bibliogrficas
[BABCCHMRS 2000] Boehm, B.W.; Abts, C.; Brown, A.W.; Chulani, S.; Clark, B.K.; Horowitz, E.; Madachy, R.; Reifer, D.; Steece, B.; Software Cost Estimation with COCOMO II; Prentice Hall; 2000. [BB 2001] Boehm, B.; Basili, V.; Software Defect Reduction Top 10 List; IEEEComputer 34(1); 2001; pags. 135-137.
15

[Beck 1999] [BF 2000] [Boehm 1988]

Beck, K., Extreme Programming Explained: Embrace Change, Addison Wesley Longman, Inc., Massachusetts, 1999. Beck, K.; Fowler, M.; Planning Extreme Programming; Addison Wesley; 2000. Boehm, B.W.; A Spiral Model of Software Development and Enhancement; IEEE Computer 21(5); IEEE Computer Society; 1988; pags. 61-72. Basili, V.R.; Rombach, H.D.; The TAME project: Towards improvementoriented software environments; IEEE Transactions on Software Engineering 14(6); IEEE Computer Society; 1988; pags 758-773. Brooks, F.P.; No Silver Bullet - Essence and Accidents of Software Engineering; IEEE Computer 20(4); IEEE Computer Society; 1986; pags. 1019.

[BR 1988]

[Brooks 1986]

[Cockburn 2001] Cockburn, A.; Agile Software Development; Addison-Wesley; 2001. [Floyd 1967] Floyd, R.W.; Assigning Meaning to Programs; Proceedings Symposium in Applied Mathematics vol 19; American Mathematical Society; 1967; pas 19-32 (valor histrico). Fowler, M.; Refactoring: Improving the Design of Existing Code; Addison Wesley; 2000. Freire, F.; Staa, A.v.; Concerto: Um Sistema de Acompanhamento da Qualidade Ps-Entrega; Workshop em Qualidade de Software; Maring, PR; SBC; 1998; pags. 19-26. Fiorini, S.T.; Staa, A.v.; Martins, R.B.; Engenharia de Software com CMM; Brasport; Rio de Janeiro, RJ; 1998. Gresse, C.; Hoisl, B.; Wst, J.; A Process Model fo GQM-Based Measurement; Software Technology Transfer Initiative Technical Report STTI95-04-E, University of Kaiserslautern, Department of Computer Science; 1995. Highsmith, J; Agile Software Development Ecosystems; Addison Wesley; 2002 [Hoare 1969] Hoare, C.A.R.; An Axiomatic Basis for Computer Programming; Communications of the ACM 12(10); 1969; pags 576-583 (valor histrico). Humphrey, W.S.; Managing the software process; Addison-Wesley; 1989.

[Fowler 2000] [FS 1998]

[FSM 1998] [GHW 1995]

[Highsmith 2002]

[Humphrey 1989]

[Humphrey 1995] Humphrey, W.S.; A Discipline for Software Engineering; AddisonWesley; 1995. [Humphrey 1995] Humphrey, W.S.; Introduction to the Team Software Process; AddisonWesley; 2000. [IEEE 1990] [LB 1985] [Lehman 1998] IEEE Standard Glossary of Software Engineering Terminology; ANSI/IEEE Std 610.12-1990. Lehman, M.M.; Belady, L.A.; Software Evolution: Processes of Software Change; Academic Press; 1985. Lehman, M.M.; Software Future: Managing Evolution; IEEE Software 15(1); IEEE Computer Society; 1998; pags. 40-44.

16

[LSOHR 1998]

Latum, F.v.; Solingen,R.v.; Oivo, M.; Hoisl, B.; Ruhe, G.; Adopting GQMbased measurement in an industrial environment; IEEE Software 15(1); IEEE Computer Society; 1998; pags 78-86. Mills, H.D.; Dyer, M.; Linger, R.; Cleanroom Software Engineering; IEEE Software 4(5); IEEE Computer Society; 1987; pags 19-25.

[MDL 1987]

[Pressman 1995] Pressman, R. S.; Engenharia de Software, Makron Books do Brasil; 1995. [PWCC 1995] Paulk, M. C.; Weber, C. V.; Curtis, W.; Chrissis, M. B.; The Capability Maturity Model - Guidelines for Improving the Software Process; Addison Wesley, SEI series; 1995. ISO/IEC 15504: Information Technology - Software Process Assessment; Technical Report Series TR 15504-1 through TR 15504-9; ISO; 1998. Wake, W.C.; Extreme Programming Explored; Addison Wesley; 2001.

[SPICE 1998] [Wake 2001]

17