PUC ISSN 003-974 Moografias em Ciêcia da Computação 3/03 Acompahameto de Projetos Ardt vo Staa Departameto de Iformática PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO RUA MARQUÊS DE SÃO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL
PUC RIO - DEPARTAMENTO DE INFORMÁTICA ISSN 003-974 Moografias em Ciêcia da Computação, Nº 3/03 Editor: Carlos J. P. Lucea Maio, 2003 Acompahameto de Projetos Ardt vo Staa
Resposável por publicações: Rosae Teles Lis Castilho Assessoria de Biblioteca, Documetação e Iformação PUC-Rio Departameto de Iformática Rua Marquês de São Vicete, 225 - Gávea 22453-900 Rio de Jaeiro RJ Brasil Tel. +55 2 34-56 Fax: +55 2 34-530 E-mail: bib-di@if.puc-rio.br
Acompahameto de Projetos Ardt vo Staa ardt@if.puc-rio.br Departameto de Iformática Potifícia Uiversidade Católica do Rio de Jaeiro (PUC-Rio) Rua Marquês de São Vicete 225, Gávea 22453-900 Rio de Jaeiro, RJ, Brasil PUC-Rio.If.MCCxx/aa Mês/Ao Abstract: I this article we examie some of the more relevat features of project trackig tools. It is ot our itetio to desig the best possible tool, if such a thig exists. Rather we aim at providig a set of guidelies that may help a software developmet maager to choose amog available tools. Of course the sketches may also be used as the startig poit of a tool developmet project. Followig three tools will be outlied: time sheet; problem recordig ad trackig; ad cofiguratio item registerig ad trackig. The three tools ca be itegrated. If itegrated, they help to reduce the effort to acquire trackig data. I this way we expect that more reliable project trackig data could be gaied. A iterestig side effect is the possibility to gather data that helps fidig the true causes of quality ad productivity problems. Keywords: Artifact registerig, Cofiguratio maagemet, Problem trackig, Software developmet pla, Software process, Time sheet. Resumo: Neste artigo procuraremos idetificar as propriedades mais relevates das ferrametas de acompahameto de projetos de desevolvimeto de software. Não pretedemos especificar o melhor cojuto de ferrametas possível, se é que isto existe. Queremos somete caracterizar propriedades que ferrametas adequadas deveriam ter. Ou seja, os esboços poderão ser utilizados como critérios de avaliação de ferrametas existetes. Embora ão seja objetivo pricipal, é claro que, além de servir como critérios para a escolha de ferrametas, os esboços poderão ser utilizados como poto de partida para o desevolvimeto de ferrametas de apoio ao acompahameto de projetos de software. Serão esboçadas três classes de ferrametas: a folha de tempo, o acompahameto de problemas e o registro e acompahameto de ites de cofiguração. Estas três ferrametas podem ser itegradas. Através da itegração pode-se reduzir o esforço de aquisição de dados, aumetado, assim, a chace de se ter um acompahameto fiel do desevolvimeto em progresso. Em muitas ocasiões a coleta de dados também permitirá idetificar as causas sistêmicas dos problemas de qualidade e produtividade. Palavras chave: Acompahameto de problemas, Folha de tempo, Gerêcia da cofiguração, Plao de desevolvimeto de software, Processo de desevolvimeto de software, Registro de artefatos.
. Itrodução É lugar comum iiciar artigos que tratam de egeharia de software dizedo que o desevolvimeto de software está em crise, uma vez que um úmero cosiderável de projetos, ou ão cocluíram o prazo ou ão produziram sistemas com qualidade tal que possam ser utilizados a coteto. Para substaciar esta afirmação, cita-se um percetual de projetos mal sucedidos extraído de algum artigo, sem questioameto algum quato à época em que a estatística foi coletada, a forma de sua obteção e a atureza das orgaizações provocadoras da catástrofe. Seguem-se propostas para a solução do problema. Ifelizmete estas propostas são exatamete isto: propostas, uma vez que é raro terem sido avaliadas com o cuidado que merecem. Existem autores que cotestam essa visão calamitosa. Hoje é difícil ecotrar alguma atividade humaa que ão depeda de alguma forma de software. A rede de distribuição de eergia, as redes de televisão e telecomuicações, os bacos, os aparelhos de moitorização de pacietes, os tomógrafos, os aviões, os tres, os carros, os aparelhos auditivos digitais, os cotroles remotos e uma miríade de artefatos ou sistemas, todos são computarizados. Não somete isto, software torou-se uma idústria que movimeta ceteas de bilhões de dólares ao ao. Ora se software fosse tão ruim assim, isso tudo ão seria possível. Por outro lado, ão há dúvida que existem problemas, algus de loga data, carecedo de solução adequada até hoje. Boehm e Basili [BB 200] mecioam que fazem mais de 5 aos que se recomeda idetificar faltas o mais cedo possível, uma vez que o crescimeto do custo de sua remoção cresce com expoete maior do que com relação ao tempo decorrido etre o istate em que ocorre o erro que itroduz a falta e o istate em que ela estará completamete removida. Estes mesmos autores dizem que a remoção de faltas detectadas após a etrada em serviço podem custar até 00 vezes mais do que o que custaria a remoção durate o desevolvimeto. Na realidade pode-se dizer que fazem mais de 30 aos que se recomeda a preveção de faltas, pois já por volta de 969 era proposto o uso de prova da corretude de programas como um istrumeto de preveção de faltas [Floyd 967, Hoare 969]. Para muitos o problema de produzir sistemas de qualidade satisfatória 2 reside a forma de gereciar projetos. Tem autores que afirmam que, utilizado processos apropriados, é perfeitamete possível coseguir-se realizar um úmero expressivo de projetos detro dos orçametos estipulados e produzido resultados com qualidade satisfatória [BABCCHMRS 2000, Humphrey 989, Humphrey 995, Humphrey 2000, PWCC 995]. Esmiuçado-se as explicações de todos esses autores, temos que, a realidade, são 3 os pricipais fatores: gestão, disciplia e proficiêcia da equipe. O emprego de pessoal sem adequada formação, sem oferecer treiameto local os padrões e processos da orgaização, sem dar oportuidade de aperfeiçoameto cotíuo, e a própria iexistêcia de padrões e processos devidamete documetados, iegavelmete é um fator que cotribui para a crise do software [Cockbur 200]. Na realidade ão é crise do setor de software, é, sim, crise a orgaização que utiliza pessoas sem adequada proficiêcia por Há muito [Brooks 986] afirmava ão acreditar que alguém fosse capaz de produzir a bala de prata (leia-se tecologia ou metodologia) capaz de matar o lobisomem (leia-se a crise de software). 2 Um artefato que possui qualidade satisfatória é adequado e ão possui faltas em deficiêcias do poto de vista dos usuários, clietes e desevolvedores. Tampouco possui excesso de qualidade ecarecedo iutilmete o artefato.
uma razão de falsa ecoomia. É crise de orgaizações que ão ivestem em padrões, a explicitação dos processos que usam e em a memória quato à realização de projetos passados. É o tipo de ecoomia que acaba saido cara. O programador, ou aalista, que abomia padrões, que adora trabalhar em horários ão covecioais, que altera artefatos sem avisar os outros, que cosidera especificações serem de pouca utilidade, que ão procura eteder o porquê das coisas que está fazedo ou usado, é outro gerador de crise. Idisciplia há muito vem sedo citada como uma das grades causas para a crise de software. Artigos publicados a década de 70 já apotavam isto. Existem até propostas tipo Clearoom [MDL 987] em que a imposição de disciplia é levada a um extremo. Mesmo a atualmete tão badalada Extreme Programmig [Beck 999, Wake 200], apesar de parecer uma volta aos áureos tempos da programação heróica, depede fortemete de disciplia de trabalho e obediêcia a padrões e a processos estabelecidos. Existem vários tipos de geretes de projeto. Caracterizarei somete 3. O mais daoso é o ditador. Este tipo de gerete determia quem fará o que, quato tempo poderá utilizar para fazê-lo, quatos recursos poderá utilizar, etc. Quem faz as estimativas é ele. Tipicamete utiliza sistemas de plaejameto e cotrole de projetos, gera belíssimos diagramas de Gatt que iguém leva a sério, quase ivariavelmete ão termia detro de prazos ou custos, pois assumiu compromissos para agradar o chefe ou o setor de marketig. Outra categoria de gerete é o coordeador. Este ouve os que realizarão as tarefas e dá a eles a autoridade para o dimesioameto de prazos e ecessidades de recursos. Acompaha a execução e promove revisões das estimativas sempre que observar desvios sistemáticos ou sigificativos. Também utiliza diagramas de Gatt mas que passam a ser levados a sério pois represetam compromissos viáveis assumidos pelos desevolvedores. Este tipo de gestão é precoizada por CMM e outros [PWCC 995, FSM 998]. Os projetos costumam ser realizados detro dos prazos e custos estabelecidos a última revisão dos plaos. Fialmete, o terceiro é o facilitador. Este se preocupa em facilitar e agilizar o trabalho. O estabelecimeto de prazos e ecessidades de recursos está estritamete ao cargo dos desevolvedores. Para reduzir os riscos utiliza-se o desevolvimeto icremetal, em que cada icremeto requer de 3 a 6 meses para ser completado. Esta forma de gestão é proposta pelas metodologias ágeis [Cockbur 200, Highsmith 2002], em particular por Extreme Programmig [Beck 999, BF 2000] e têm a virtude de serem altamete adaptáveis às mudaças que vão surgido o decorrer do projeto. Também aqui prazos e recursos são respeitados, uma vez que o escopo de cada icremeto será dimiuído sempre que se observar que ão será possível atigir a meta estabelecida. Evidetemete o segredo para o acerto das estimativas está as revisões dos plaos e/ou do escopo do projeto e que ocorrem com alguma freqüêcia. Mas para isto é ecessário um sistemático acompahameto do deserolar do projeto, cofrotado cotiuamete o que está sedo realizado com o que se esperava que fosse realizado coforme registrado o plao. No restate deste artigo examiaremos em mais detalhe aspectos relacioados com o acompahameto de projetos de desevolvimeto de software. Na seção 2 são resumidamete abordados o que se etede por plao, processo defiido do projeto e metaprocessos. Na seção 3 são abordados os coceitos básicos de acompahameto de projetos. Na seção 4 são esboçadas as ferrametas folha de tempo, registro e acompahameto de problemas, e registro e acompahameto de ites de cofiguração. A seção 5 coclui o artigo. 2
2. Plaos, processos defiidos e meta-processos Ao desevolver software lidamos com duas grades categorias de coceitos: processos e artefatos. Um artefato é qualquer resultado tagível (existe sob a forma de papel ou arquivo de computador), composto ou ão, fruto da realização de uma ou mais atividades. São exemplos: módulos de programas, mauais, arquivos cotedo auxílio o-lie, especificações, plaos, logs de teste, caderos de aotação de problemas, folhetos de propagada, bases de dados históricos, etc. Artefato é um coceito recursivo. Assim o sistema como um todo é um artefato. Os programas, mauais, bases de dados etc. que o costituem são também artefatos, e assim por diate. No ível elemetar um artefato é um arquivo (por exemplo: xxx.java) ou documeto (por exemplo: o cadero de aotação de problemas). O objetivo de um projeto de desevolvimeto é, portato, criar um cojuto harmoioso 3 de artefatos que jutos implemetam satisfatoriamete a aplicação almejada. Um plao de desevolvimeto pode ser visto como um programa que será executado por diversas pessoas ao ivés de sê-lo por um autômato. Nas disciplias de sistemas de computação aprede-se que é bastate complexa e sujeita a paes a programação de sistemas distribuídos (vários processadores cooperado para realizar um determiado cálculo). É exatamete isto que é um plao um sistema distribuído, com pelo meos mais três agravates: i. ão poderá ser testado ates de ser posto em uso. Diferete de um programa, um plao será executado exatamete uma vez e, esta úica vez, tem a obrigação de dar certo. Isto é, deve produzir o sistema desejado com qualidade satisfatória e detro dos prazos e custos estimados. Quem programa sabe como é difícil escrever programas complexos que estejam corretos ates do primeiro teste. ii. o executor ão é um autômato e, portato, é difícil, se ão impossível, estabelecer a priori a cofiabilidade dos resultados, tampouco é possível determiar com exatidão a ecessidade de tempos e de recursos; iii. o plao é alterado durate a sua execução em fução do cohecimeto adquirido ao executá-lo (mudaças de requisitos, mudaças de arquitetura, etc.), e de problemas 4 observados durate a sua execução (erros sistemáticos de estimativas, rotação de pessoal, etc.). Além disso projetos são sujeitos a muitos imprevistos (falta de eergia, quebra de equipameto, doeças, etc.). Note que uma das primeiras recomedações em disciplias de egeharia de software é que os programas ão devem modificar a si próprios, pois toram virtualmete impossível saber, através de ispeções, se poderão produzir o resultado desejado. Mas é exatamete isso o que acotece com plaos. É claro que isso mostra que plaejar o desevolvimeto de um determiado software é quase uma missão impossível, se ão forem tomadas algumas precauções. Uma das precauções é a de desevolver um meta-plao a ser istaciado, produzido um plao de desevolvimeto de uma aplicação. A istaciação se dá com base as características do ambiete de desevolvimeto e da aplicação a desevolver. Utilizado a termiologia de CMM [PWCC 995, FSB 998] um tal meta-plao é o Processo de Software 3 Um cojuto harmoioso de artefatos é formado por artefatos que ão guardam cotradições, coflitos ou icosistêcias etre si. 4 Etedemos por problema coletivamete qualquer relato de falha, relato de defeito ou solicitação de adaptação, melhoria ou evolução. 3
Defiido do Projeto. Este é um processo de software estabelecido e bem caracterizado visado determiados domíios de aplicação 5 e/ou de solução 6, descrito em termos de padrões, procedimetos, ferrametas e métodos de desevolvimeto de classes específicas de artefatos. As defiições de processos podem variar desde um simples esquema (estrutura de tarefas geéricas) até uma complexa máquia de estados idicado todas as tarefas e as respectivas pré e pós-codições, todos os tipos de artefatos a serem produzidos e respectivos critérios de aceitação, todas as ferrametas a serem utilizadas, todos os padrões a serem respeitados e todos os papéis a serem desempehados pelas pessoas que realizarão as tarefas. Processos são istaciados caso a caso, estabelecedo o plao de desevolvimeto de um projeto específico. Pelo fato de estarem documetados e amparados em dados históricos, os processos reduzem sigificativamete os riscos de produzir plaos icompletos ou ão realizáveis. Cabe ressaltar que poderão existir vários processos de software defiidos em uma mesma orgaização. Isto decorre do fato desses processos visarem explicitamete determiados domíios. Ifelizmete, existe o risco de se estabelecer processos defiidos, que sistematicamete produzirão maus plaos. Para reduzir este risco pode-se utilizar meta-processos. Estes são processos geéricos que determiam as características que qualquer processo específico deve satisfazer. A istaciação de um meta-processo visado um determiado domíio resulta o processo de software defiido do projeto. São exemplos de meta-processos o CMM [PWCC 995, FSB 998] e o SPICE [SPICE 998]. Faz parte do meta-processo dizer como o processo istaciado será avaliado quato à sua eficácia e eficiêcia. Também faz parte dizer como será evoluído caso apresete problemas ou se tore tecologicamete defasado. Caso o meta-processo, os processos dele derivados e os plaos istaciados a partir desses processos tiverem sido gerados com cuidado e caso eles sejam sistematicamete revisados, aumeta-se a capacitação da orgaização que os utiliza a produzir software de qualidade satisfatória detro dos limites de tempo e recursos estipulados. É essecialmete esta a idéia que está por trás de ormas tipo CMM e SPICE. Ifelizmete, o fato de ão existir uma teoria adequada para validar a eficácia destes três artefatos e do processo de derivação, faz com que em sempre esta forma de atuar seja coroada de êxito. Os artefatos bem como os respectivos processos de istaciação são criados empiricamete a partir da experiêcia profissioal de várias pessoas. Isto ão quer dizer que ão possam levar a bos resultados. Quer dizer somete que ão se cosegue ter certeza de atigir bos resultados em cada projeto. Quer dizer também que determiadas pessoas ou orgaizações terão mais sucesso do que outras, uma vez que o resultado depede da proficiêcia e de características idividuais dos membros da equipe. 3. Acompahameto Ifelizmete, a obediêcia a um plao de boa qualidade ão assegura que o resultados, isto é os artefatos produzidos, sejam de qualidade satisfatória. Tampouco assegura um deserolar eficiete do processo. Isto decorre do fato dos executores serem pessoas, dos plaos 5 Domíio de aplicação idetifica a área em que se situa a aplicação, por exemplo: sistemas de cotrole de estoque, sistemas de comado e cotrole, sistema de cotrole de processos químicos, sistemas de registro acadêmico. 6 Domíio de solução idetifica a tecologia utilizada para implemetar os software, por exemplo: cliete / servidor; orietado a objetos; baseado em múltiplos agetes distribuídos. 4
evoluírem durate a execução, da distribuição de tarefas e de uma grade gama de impoderáveis. Como já foi isiuado, as causas do mau fucioameto podem residir tato a execução (erros de pessoas ou istrumetos), como também o próprio plao, ou pior, os processos, meta-processos e processos de istaciação. Isto os obriga a coduzir freqüetes avaliações quato à corretude dos artefatos e da execução do plao, bem como do acerto do próprio plao. Acompahameto é o processo de moitorar a execução de um plao. Segudo CMM acompahar projetos tem os seguites objetivos: Acompahar os resultados e desempehos reais cofrotado-os com o plao de desevolvimeto de software. Tomar ações corretivas e gereciá-las até sua coclusão, sempre que resultados ou desempehos reais desviarem sigificativamete do que foi estabelecido (estimado) o plao de desevolvimeto de software. Assegurar que as alterações os compromissos de software se dêem através de acordo etre as pessoas e os grupos evolvidos. Na realidade devemos esteder estes objetivos de modo que ão somete os plaos sejam cotrolados, mas também os processos e meta-processos. Temos etão mais um objetivo: Acompahar processos e meta-processos obtedo idicadores quato à sua eficácia em istaciar plaos e processos 7. Ao redigir programas complexos é fortemete recomedado que sejam iseridas assertivas executáveis o código. Estas verificam, durate a execução do programa, se o estado do programa o poto ode se ecotra a assertiva correspode a um estado válido. Caso o estado ecotrado durate a execução ão seja válido, é sializada a ocorrêcia de um problema. Da mesma forma o acompahameto de um plao de projeto somete auxiliará o cotrole da sua execução, caso coteha idicações claras do que é esperado em potos de cotrole e marcos. Estas idicações estão substaciadas o plao, devedo escaloar o desevolvimeto dos artefatos, estabelecer os prazos e recursos dispoibilizados para cada tarefa, explicitar os critérios de aceitação e os métodos de verificação da qualidade dos artefatos (pré e pós codições das tarefas). De tudo o que foi dito é fácil cocluir que o acompahameto poderá ocorrer em variados graus de graularidade, bem como pode focar uma variedade de propriedades de um plao. Isto explica a grade variedade de propostas do que seria um bom plao e de ferrametas de acompahameto e medição existete o mercado. Explica também a superficialidade com que freqüetemete o assuto é tratado a literatura. 4. Formas de acompahameto Nesta seção discutiremos algumas formas de acompahameto. Não pretedemos em exaurir o assuto, em defiir a melhor de cada uma das formas. Pretedemos meramete raciociar sobre a ecessidade e o porquê de cada forma de acompahameto. O objetivo é forecer critérios para geretes e equipes técicas capazes de auxiliá-los ao selecioar as ferrametas e técicas mais adequadas às suas ecessidades. 7 Para simplificar a redação estamos utilizado o termo processo para deotar o Processo de Software Defiido do Projeto e meta-processo para deotar o processo padroizado pelo CMM ou SPICE. 5
4.. Folha de tempo A folha de tempos visa a medição do esforço dos executores de um plao. Tipicamete relacioa as atividades realizadas por um executor em determiado dia. Uma atividade é qualquer ação executada por determiada pessoa. As atividades icluem todo o trabalho que o corpo técico e gerecial realiza para desempehar tarefas do projeto e da orgaização. Atividades podem ser recorretes, bem como podem ter ada a ver diretamete com o projeto, como, por exemplo atividades pessoais, participar em treiameto, ou registrar medições em plailhas de acompahameto. São exemplos de atividades: redigir a especificação de um módulo, redigir o código de um módulo, ispecioar um módulo, refatorar 8 um módulo, testar um módulo, redigir um capítulo de um documeto, registrar tempo a folha de tempo, participar de uma reuião, explicar o sistema para usuários, resolver problemas particulares. O registro do esforço é fudametal para poder-se estimar prazos e recursos ecessários em projetos futuros. É ecessário também para se verificar se existem erros de estima sistemáticos o plao. Como já foi mecioado, um plao é um artefato vivo, o setido que é evoluído o decorrer de sua execução. No etato, ão basta registrar-se a duração das atividades, o registro deve estar relacioado com o plao de desevolvimeto. Além disso deve servir aida de subsídio para cotrolar o desempeho do ambiete 9 e da equipe de desevolvimeto. Do poto de vista de plaejameto, atividades em sempre são de iteresse, uma vez que ão ecessariamete coduzem a um resultado de qualidade cotrolada. Usualmete um plao é estabelecido em termos de tarefas 0. Uma tarefa é uma uidade de trabalho bem defiida o processo de software. O iício e a coclusão de uma tarefa forecem à gerêcia um poto de cotrole visível do progresso do projeto. Tal como projetos, tarefas têm iício e fim e ão são recorretes. Tarefas estão associadas a artefatos e possuem uma estrutura recursiva semelhate à destes. Tarefas podem ser realizadas através de uma ou mais atividades cada qual evolvedo uma ou mais pessoas. São exemplos de tarefas: produzir um módulo a ser aceito segudo algum critério explicitamete defiido o plao; produzir um documeto (maual) a ser aceito segudo algum critério explicitamete defiido o plao. As tarefas têm critérios de protidão (pré-codições) e critérios de fialização (póscodições, critérios de qualidade, padrões) [IEEE 990]. As codições de protidão precisam estar satisfeitas para que a tarefa possa ser iiciada. As codições de coclusão devem estar asseguradas ao termiar a tarefa. Tal como em programação, pode-se verificar se a seqüêcia de execução de um plao é viável comparado as codições de coclusão com as codições de protidão de tarefas cosecutivas. Os critérios de aceitação devem ter uma parcela estabelecida através de padrões publicados. A outra parcela estará viculada às características específicas do produto sedo desevolvido. Exemplo de critério de protidão: especificação do módulo ABC aceita segudo o padrão X verificado através de ispeção. 8 Refatorar (refactorig) é a atividade de reorgaizar um ou mais módulos de modo que as iterfaces e a estrutura itera dos módulos torada mais mauteível. Proceder ao refatorameto aumeta a evolutibilidade do módulo [Fowler 2000]. Uma idéia similar pode ser aplicada a outros artefatos, tais como auxílio, documetação, arquiteturas e modelos. 9 O ambiete de desevolvimeto é formado por processos, procedimetos, métodos, ferrametas, plataformas de desevolvimeto e uma variedade de bases de dados utilizadas para registrar as medições e os artefatos. 0 Muitos sistemas de plaejameto e cotrole de projetos utilizam o termo atividade para o que etedemos aqui por tarefa. 6
Exemplo de critério de coclusão: o módulo ABC, o correspodete módulo de teste específico e os arquivos de script de teste estão dispoíveis e foram verificados segudo o padrão Y. A distição etre tarefas e atividades é ecessária. Cosidere o desevolvimeto de um módulo. O código estar redigido ão idica que possa ser utilizado. Tampouco ter sido testado é suficiete para idicar que possa ser utilizado. Equato ão estiver completamete redigido, ispecioado, testado, itegrado e aceito segudo os critérios estabelecidos, o módulo ão existe do poto de vista do restate do projeto. Evidetemete, a produção do módulo pode evolver várias pessoas e levar vários dias. A tarefa é etão produzir módulo W aceito segudo padrão X, a especificação Y e o teste Z. Esta tarefa é formada por várias atividades que serão registradas as folhas de tempo de quem tiver realizado a atividade. Note que uma atividade pode ser realizada por várias pessoas (ex. ateder a uma reuião de ispeção), mesmo assim ela figurará a folha de tempo de cada uma das pessoas que participaram a atividade. Por exemplo, o processo Extreme Programmig é exigido que programas sejam codificados por duas pessoas trabalhado jutas em um mesmo computador [Beck 999]. É exigido, aida, que os testes sejam redigidos ates de se iiciar o desevolvimeto dos módulos. Ao registrar as atividades de um dia pode-se registrar aida: uma descrição resumida do que foi feito e das dificuldades ecotradas ao realizar a atividade. A aálise deste texto livre permitirá extrair iformações relevates e recorretes que, o futuro, deveriam ser solicitadas explicitamete. Desta forma podese evoluir gradualmete o sistema de folha de tempo matedo a sua adequação às características específicas da orgaização. Ao aplicar GQM Goal Questio Metric [BR 988, GHW 995] é fortemete recomedado que sistemas de medição sejam estabelecidos somete quado se sabe para que medir. Caso cotrário provavelmete o esforço gasto a medição será desperdiçado uma vez que as medidas ão serão utilizadas para aprimorar o ambiete. atureza da atividade, como por exemplo: estudo, especificação de módulo, codificação, redação dos casos de teste, realização dos testes, depuração, alteração do código, refatoração, revisão fial do módulo. As possíveis aturezas devem ser estabelecidas pela gerêcia de projetos. Esta forma de defiir atividades permite utilizar como ome da atividade o ome da tarefa, especializado esta para uma atividade através da sua atureza. Permite também realizar estudos sobre as aturezas de atividades que mais cosomem tempo. Se, por exemplo, a equipe de desevolvimeto gasta muito tempo em depuração, é coveiete provideciar treiameto e, possivelmete, acrescetar ferrametas de cotrole da qualidade do código fote ao acervo do ambiete. Depois, pode-se verificar se as mudaças o ambiete e o processo surtiram o desejado efeito de redução do tempo gasto em depuração. artefatos criados ou alterados pela atividade. De maeira geral espera-se que uma atividade somete altere os artefatos resultates da tarefa à qual pertece a atividade. No etato, ao desevolver um artefato a sua iterface pode ser modificada. Isto obriga um ajuste em todos os artefatos iterrelacioados com o artefato em produção. Por sua vez, isto pode acarretar uma cosiderável propagação de alterações. Os artefatos criados ou alterados deveriam aparecer as pós codições da tarefa. Note que isto realça a dificuldade de se estabelecer corretamete as codições de protidão e as de coclusão. 7
artefatos utilizados. Artefatos utilizados são artefatos ecessários para realizar a atividade e que podem ou ão ser afetados pela atividade. Por exemplo, ao redigir o código de um módulo, em pricípio a sua especificação ão deve ser alterada. O registro de artefatos utilizados e de artefatos alterados, evidecia uma relação de depedêcia etre artefatos. Mater esta relação os bacos de dados do projeto é bastate iteressate para a tomada de decisão de passos de mauteção futuros. O cojuto de todos os artefatos utilizados ou alterados deveria aparecer as pré codições da tarefa, equato que o de artefatos alterados ou gerados deveria aparecer as pós-codições da tarefa. artefatos podem, a realidade devem, ser reutilizados. Coseqüetemete uma tarefa poderá estar desevolvedo artefatos pertietes a mais de um projeto. coforme será discutido a seção a seguir, uma atividade também deve refereciar as FAP Ficha de Acompahameto de Problema a que diz respeito [FS 998]. A figura a seguir esboça o diagrama de classes para uma folha de tempo. Data Pessoa Folha Projeto Natureza Tarefa Artefato Atividade FAP Figura. Esboço da estrutura de classes do subsistema folha de tempos 4.2. Acompahameto de problemas Uma das dificuldades que assedia o desevolvimeto de software é assegurar a itegridade dos sistemas em face às cotíuas alterações. Por mais que se tome cuidado ao especificar sistemas, é ievitável que estas veham a ser alteradas [Beck 999, Lehma 998, LB 985], aida mesmo durate o desevolvimeto. Isto idica que, a realidade, o desevolvimeto de software é um processo de amadurecimeto o qual, através de várias iterações, se coverge para o sistema desejado. Ou seja, problemas sempre surgirão, torado ecessário o seu registro e o acompahameto até que teham sido completamete resolvidos. Ao acompahar deve-se procurar idetificar as causas. Se estas forem sistemáticas deve-se alterar o processo, ou o meta-processo, de modo que em projetos futuros ão mais ocorra esta classe de problemas. Em [BB 200] Boehm e Basili afirmam que cerca de 40 a 50% do esforço é de um projeto é cosumido em retrabalho desecessário. Ifelizmete esta estatística ão mecioa a fração que se deve a erros de desevolvimeto, em a fração devida às mudaças de especificação que poderiam ter sido evitadas se a especificação tivesse sido mais cuidadosa. Nem todo o retrabalho é desecessário. Quado for seguido um processo de desevolvimeto icremetal, uma das regras básicas é mater a complexidade istatâea 8
a meor possível. Isto é fortemete sugerido os processos ágeis, tais como Extreme Programmig [Beck 999, Cockbur 200] e o ciclo de vida espiral [Boehm 988]. Desta forma os artefatos são desevolvidos visado estritamete a iteração correte. Evidetemete que, à medida que se vai evoluido de icremeto para icremeto, pode-se ter a ecessidade de alterar artefatos já cocluídos o passado. Neste caso é sempre recomedado proceder a uma revisão rigorosa da orgaização itera dos artefatos através de uma refatoração [Beck 999, Fowler 2000]. Isto assegurará a evolutibilidade do artefato o futuro. Cabe salietar que diversas estatísticas evideciam que mauteção sucessiva de artefatos leva à sua deterioração estrutural, a meos que se realize um esforço cosciete de reorgaizar a sua estrutura. É ecessário, etão, cotrolar e coordear as alterações e, aida, idetificar istâcias de retrabalho evitável e as respectivas causas. O simples uso de um sistema de cotrole versões ão é suficiete, uma vez que pouco ou ada iforma sobre as causas das alterações. O objetivo destes sistemas é possibilitar, sempre que ecessário, a recostrução automática das várias versões de um artefato. Mas o que queremos é registrar os problemas, idetificar as suas causas e acompahar a sua resolução até que estejam completamete resolvidos. Queremos, aida, viabilizar o acompahameto de problemas pelos diferetes iteressados, tais como usuários, clietes, geretes e desevolvedores. Fialmete, desejamos que os desevolvedores afetados pela alteração de um artefato sejam iformados desta alteração, evitado o retrabalho despedido ao ajustar os artefatos coseqüetes às alterações de um ou mais dos seus artefatos atecedetes. Problemas são registrados por algum observador. Este pode ser uma pessoa pertecete à equipe de desevolvimeto, bem como qualquer pessoa extera a ela como, por exemplo, o usuário. Problemas podem ser registrados em logs de teste automatizado. Neste caso o observador é formado pelos casos de teste que evideciaram o problema. Histórico de alterações Critérios e padrões de cotrole da qualidade Histórico de alterações Artefatos atecedetes Especificação Criação Alteração Artefato coseqüete Artefato Laudo Cotrole da qualidade Laudo FAP Gerêcia da evolução FAP FAP - ficha de acompahameto de problema Outro artefato FAP Avaliação extera Figura 2. Atividades ao realizar uma tarefa com cotrole da qualidade. A Figura 2 mostra iteração das atividades de desevolvimeto e mauteção com as de cotrole da qualidade e de acompahameto de problemas. Um artefato coseqüete pode 9
ser criado a partir de um ou mais artefatos atecedetes. Em geral estes são especificações. Ao utilizar testes automatizados redigidos ates de se desevolver [Beck 999] existem pelo meos dois artefatos atecedetes, a especificação (cojuto de historietas, casos de uso) e o script de teste. Ao criar um artefato devem ser obedecidas as especificações bem como diversos padrões ou ormas técicas. Uma vez criado o artefato, ele deverá ter a sua qualidade cotrolada. Este cotrole gera um laudo. É fortemete recomedado que o laudo seja um documeto. São exemplos: logs de execução de testes automatizados, artefatos cotedo aotações de ispeção, caderos de aotação de problemas. No PSP (Persoal Software Process) [Humphrey 995] é exigido que sejam registrados iclusive os erros de sitaxe de programas fote, tais como falta de potoe-vírgula. A justificativa é que pessoas precisam saber que têm problemas para que tomem alguma iiciativa para resolver ou evitá-los. Problemas recorretes evidetemete merecem ateção específica, já problemas esporádicos são fruto do simples fato de humaos serem falíveis 2. Uma vez gerado um laudo deve ser decidido o que fazer. Etre as diversas possibilidades temos: resolver completamete o problema através da alteração do artefato, procededo, a seguir a um ovo cotrole da qualidade. Evidetemete isto cofigura retrabalho que, de maeira geral, seria evitável caso o desevolvimeto fosse correto por costrução. protelar a resolução do problema para uma oportuidade mais tarde. Neste caso o problema registrado o laudo é trasformado uma solicitação de alteração. Todas as solicitações de alteração, relatórios de falha ou defeito, solicitações de adaptação, melhoria ou evolução são registradas em uma ficha de acompahameto de problema FAP [FS 998]. relacioar o problema com algum dos artefatos atecedetes. Neste caso cria-se uma solicitação de alteração a ser viculada a este artefato atecedete. registrar uma FAP a ser relacioada com um artefato específico. Durate o desevolvimeto, teste, avaliação, ou uso podem ser idetificados problemas relacioados com artefatos de elevado ível de abstração. Por exemplo, pode-se observar um problema o produto X e ão o artefato que efetivamete cotém a falta causadora. Como artefato é um coceito recursivo, tora-se ecessário procurar o artefato específico com o qual o problema deve ser relacioado para, somete etão, iiciar a sua resolução. Utilizado esta abordagem pode-se restrigir a aceitação de um artefato ao fato do seu laudo estar vazio após o cotrole da qualidade. Isto ão quer dizer que ão existam pedêcias, quer dizer somete que as possíveis pedêcias estão registradas como solicitações de alteração e poderão ser resolvidas o futuro sem comprometer o uso do artefato este mometo. Uma vez um artefato tedo sido aceito, cria-se uma versão imutável dele. Coseqüetemete qualquer alteração a ser feita o futuro, mesmo as decorretes de FAPs já cohecidas mas ão cocluídas, gerará uma ova versão do artefato. Todas as versões de Padrões e ormas embora similares, gozam de uma difereça relevate. Padrões são desevolvidos e matidos por uma ou mais orgaizações visado as suas ecessidades específicas. Já as ormas são desevolvidas e matidas por órgãos de ormatização (p.ex. ABNT, ANSI, DIN, ISO) e potecialmete afetam todas as orgaizações que atuam o ramo de egócio visado pela orma. 2 Errare humaum est, perseverare i errore est diabolicum. 0
um artefato, juto com uma explicação da causa do problema, são armazeadas o histórico de alterações. Este é usualmete implemetado através de alguma ferrameta de cotrole de versão. A Figura 3, a seguir, mostra um possível processo de tratameto de FAPs. Nesta figura os hexágoos represetam estados em que a FAP espera por algum serviço. Já as elipses represetam estados em que a FAP está sedo processada por alguma atividade. Os rótulos das arestas represetam as codições fiais das atividades, idicado qual o estado a seguir ao cocluir a atividade com aquela codição. Todas as FAPs geradas, idepedetemete de sua origem, etram o estado Aguardado aálise iicial. De lá progridem para o estado em aálise. O objetivo deste é determiar se o problema deve ser resolvido imediatamete, se deve receber um tratameto emergecial, se se refere a um problema já resolvido ou idêtico ao de outra FAP, se existe suficiete iformação para poder iiciar a resolução do problema, ou, fialmete, se se trata de um ão problema a ser simplesmete igorado. Iício Aguardado aálise iicial aprovada Em solução emergecial ão aprovada Aguardado aálise protelada falha grave Aguardado solução emergecial dados isuficietes Aguardado iformação Iformação adicioal recebida Aguardado iformação dados isuficietes Em aálise autorizada Aguardado solução suspesa Sedo resolvida cocluída ão aprovada recusada Aguradado aprovação Sedo cotrolada cacelada já resolvida recusada ão aceita aprovada Fim aceita Sedo implatada Aguradado implatação Figura 3. Processo de tratameto de uma FAP Sempre que ão possa ser dada uma solução, a FAP volta ao estado Aguardado aálise. De tempos em tempos essas FAPs são reaalisadas. Esta ova aálise leva em cota o estado correte do projeto e corrige possíveis erros de aálise o passado. Quado a FAP etra o estado Aguardado solução passa a ser resposabilidade da gerêcia selecioar os recursos a serem utilizados para resolvê-la. Desta forma estabelece-se um vículo etre as atividades de plaejameto e as de evolução dos artefatos. A solução dada a uma FAP deve sempre passar por uma aprovação. Uma vez aprovada, a ova solução pode ser implatada, ou seja, torada dispoível para os usuários e/ou os demais desevolvedores. Especificações podem ser alteradas durate o desevolvimeto. As coseqüêcias se materializarão sob a forma de ovos laudos evideciado os testes que falharam com relação artefatos coseqüetes. Em processos ágeis problemas ão são documetados explicitamete. Problemas de fucioalidade e cofiabilidade surgem sob a forma de laudos de teste, sedo que os testes
devem ser automatizados [Beck 999, Cockbur 200]. Pouco é dito quato ao tratameto de solicitações de alteração depois da etrega do sistema. A orma ISO/IEC 5504 [SPICE 998] requer explicitamete o registro e o acompahameto de problemas idetificados durate o desevolvimeto e após à etrega. O CMM [PWCC 995, FSB 998] exige o registro durate o desevolvimeto, ada sedo dito com relação aos problemas após a etrega. Do poto de vista dos dados maipulados, uma FAP precisa registrar: a pessoa que origiou a FAP e a pessoa que aceitou a solução. Uma vez aceita a solução, a versão aceita do artefato é passada para a pessoa resposável por armazear os artefatos o sistema de cotrole de versão. Restrigir o úmero de pessoas autorizadas a fazer isto tem a vatagem de assegurar o cumprimeto de padrões de desevolvimeto, teste e cotrole da qualidade. as versões dos artefatos resultates da criação ou alteração realizada durate a resolução do problema idetificado a FAP. É possível que várias FAPs sejam agregadas ao realizar um determiado passo de mauteção. Todas elas resultam em um ou mais artefatos criados, alterados, ou descotiuados. as versões dos artefatos iicialmete associadas à FAP. Esta relação facilita o trabalho de aálise ecessário para corretamete associar uma FAP aos artefatos que efetivamete resolverão o problema idetificado. as formas de idetificar os problemas, por exemplo: teste, ispeção, uso. Esta iformação tem por objetivo auxiliar a aquisição de dados estatísticos relativos ao istate em que são idetificados problemas. Evidetemete se uma taxa grade de problemas for idetificada após a etrega, precisa-se tomar alguma ação de melhoria de processos para que tal ão acoteça mais. Ifelizmete isto é mais difícil do que se imagia. Em [BB 200] Boehm e Basili dizem que 40 a 50% do software etra em produção cotedo faltas ão triviais. Com vistas a uma itegração etre o sistema de acompahameto e as folhas de tempo é iteressate que atividades relacioem as FAPs sedo resolvidas pela atividade. Desta forma a aquisição de dados de acompahameto de esforço produzirá também as relações de iterdepedêcia etre FAPs e artefatos efetivamete alterados. A figura a seguir esboça o diagrama de classes para o acompahameto de problemas. Artefato iicial Pessoa registra aprova Estado progresso FAP Forma de observação Atividade Artefato Causa Figura 4. Esboço do diagrama de classes do subsistema de acompahameto de problemas. 2
4.3. Registro de artefatos É sempre coveiete registrar os artefatos e acompahar a sua evolução. Ao desevolver sistemas maiores isto se tora imprescidível. Estas ações são realizadas pela gerêcia de cofiguração 3. A fialidade da GCS Gerêcia de Cofiguração de Software é estabelecer e mater a itegridade dos artefatos ao logo de todo o ciclo de vida do software. A GCS ada de mãos dadas com o registro e acompahameto de problemas. A GCS evolve: idetificar a cada mometo o estado dos ites de cofiguração de software. Ites de cofiguração são artefatos de software selecioados, acompahados de sua descrição. cotrolar sistematicamete as mudaças a cofiguração. mater, através da gerêcia, a itegridade e rastreabilidade da cofiguração ao logo do ciclo de vida de software. cotrolar a itegridade de artefatos compostos, levado em cota a versão de cada um dos compoetes, ou seja, cotrolar a cofiguração do artefato composto. registrar e relatar o estado de progresso das FAPs. saber ode estão armazeadas, ou guardados os artefatos 4. Os artefatos colocados sob gerêcia de cofiguração são deomiados ites de cofiguração e icluem os artefatos que são etregues ao cliete (produtos), por exemplo, documetos de requisitos do software, o código executável e os mauais. Iclui aida os artefatos gerados e utilizados o desevolvimeto mas que ão são explicitamete dispoibilizados para o usuário. São exemplos: projeto de arquitetura, casos de teste, módulos fote, compiladores e ferrametas de software. Cabe salietar que são ites de cofiguração, etre outros, as versões de compiladores e das ferrametas CASE utilizadas. Isto se deve ao fato destes ites serem cruciais para o desevolvimeto. Em caso de acidete deve ser possível recostruir corretamete o ambiete de modo que se evite a perda de cotiuidade o desevolvimeto. Fialmete, cabe salietar que em todos os artefatos são ites de cofiguração. À medida que se desevolve o software, são idetificados os ites de cofiguração e são estabelecidas baselies, para dar maior seguraça ao desevolvedor e permitir maior cotrole do desevolvimeto. Baselie é um item de cofiguração formalmete aalisado, revisado e aprovado, que serve de base para o desevolvimeto posterior. É, portato, um marco de referêcia o desevolvimeto de software, caracterizado pela etrega de um ou mais ites de cofiguração aprovados por meio de uma revisão técica formalmete defiida [Pressma 995]. Os artefatos que costituem uma baselie podem ser alterados somete através de procedimeto formal de cotrole de alterações [IEEE 990]. Uma baselie é, etão, uma versão estável de um artefato composto, cotedo todos os compoetes que costituem este artefato em um determiado mometo. A Figura 5 esboça o processo de gerêcia da cofiguração. Surgido a ecessidade de realizar uma alteração evolvedo um ou mais ites de cofiguração o grupo de pessoas resposáveis pela GCS realiza o check-out (retirada) dos ites requeridos, copiado-os do sistema de cotrole de versões ode se ecotra o artefato para uma área de trabalho. É feita 3 No cotexto de Gerêcia da Cofiguração uma cofiguração é o cojuto de características físicas e fucioais de hardware e software coforme estabelecidas em algum documeto técico ou realizadas por um produto. [IEEE 990] 4 Nem todos os artefatos serão armazeados em algum meio computacioal. Algus serão documetos papel guardados em algum arquivo. 3
a alteração. Após, é realizado o cotrole da qualidade dos artefatos alterados. Caso estes sejam aprovados é realizado o check-i (icorporação) dos ites trasferido-os da área de trabalho para o sistema de cotrole de versões. Simultaeamete os ites são removidos da área de trabalho. Ao iserir um artefato a base de versões é criada uma ova versão deste. Assegura-se, assim, a possibilidade de recuperar qualquer uma das versões ateriores de um determiado item. Criação Registro de artefatos Registrar artefato Arquivos Artefato ão cotrolado Armazear artefato Item de cofiguração Cotrole de versão Check-i Trabalho cocluído Criar artefato Não aceito Aceito Cotrolar artefato Área trabalho Item de cofiguração Tipo artefato Artefato ão cotrolado Check-out Item de cofiguração Alterar artefato Editar artefato Alteração autorizada Figura 5. Esboço do processo de gerêcia da cofiguração No caso de artefatos ão cotrolados, o processo é simplificado descosiderado-se as etapas de check-i e check-out. Para poder localizar os artefatos e difereciar a sua atureza é ecessário registrar os artefatos. Este registro pode coter iformações complemetares para facilitar a localização de um artefato caso existam muitos, ou caso seja desejado ver se é possível reutilizar algum existete. Uma das atividades básicas da gerêcia de cofiguração é o registro de todos os artefatos, idicado aqueles que costituem ites de cofiguração. Ao registrar um artefato deve-se idetificar todos os seus compoetes, caso seja composto. Na realidade deve-se registrar, para cada versão de um artefato, as versões dos artefatos que o costituem, assim cada versão de um artefato poderá ser recostruído a partir das versões de seus compoetes. Além de cohecer a composição de um artefato é ecessário cohecer as relações de precedêcia. Ou seja é ecessário saber quais são os artefatos coseqüetes de um determiado artefato. Isto permitirá verificar o impacto que uma alteração em um artefato pode ter sobre o sistema como um todo. Facilita, também, o rastreameto das propriedades idetificadas em um dado artefato os seus artefatos subseqüetes. Fialmete processos moderos utilizam freqüetemete ferrametas que geram artefatos completos ou esqueletos a partir de outros. É importate também saber quais são os artefatos gerados a partir de determiado artefato e quais as ferrametas utilizadas para tal. 4
Projeto Estado do artefato depede de Tarefa Artefato gera composto por Atividade FAP Figura 6. Esboço do diagrama de classes do subsistema de registro de artefatos. 5. Coclusão Neste artigo procuramos idetificar as propriedades mais relevates das ferrametas de acompahameto de projetos de desevolvimeto de software. Cabe observar, mais uma vez, que ão pretedíamos especificar a melhor ferrameta possível, se é que isto existe. Queríamos tão somete caracterizar propriedades que ferrametas deveriam ter, de modo que se dispoha de critério de escolha para ferrametas existetes. Além de servir como critérios para a escolha de ferrametas, evidetemete os esboços podem ser utilizados como poto de partida para o desevolvimeto de ferrametas de apoio ao acompahameto de projetos de software. É claro que muitas lacuas deverão ser preechidas de modo que se possa dispoibilizar um cojuto de ferrametas adequado à orgaização. Foram esboçadas três classes de ferrametas: a folha de tempo, o acompahameto de problemas e o registro e acompahameto de ites de cofiguração. Estas três ferrametas podem, e devem, ser itegradas. Uma vez dispoibilizadas, dever-se-ia ser capaz de evoluilas de modo que se possa adicioar medições, bem como extrair as estatísticas relevates para uma determiada orgaização. Esta forma icremetal de desevolvimeto é particularmete iteressate por facilitar a idetificação dos problemas efetivamete vividos pela orgaização [BR 988, GHW 995, LSOHR 998]. Utilizado um gerador de aplicações foi desevolvido um protótipo de sistema de acompahameto o Departameto de Iformática da PUC-Rio, evideciado a utilidade de uma ferrameta itegrada, apesar da baixa qualidade de sua iterface de usuário. Está em progresso o desevolvimeto de um ovo cojuto de ferrametas que, esperamos, possa ser utilizado em escala maior. Esta ferrameta será evetualmete dispoibilizada como freeware. Referêcias bibliográficas [BABCCHMRS 2000] Boehm, B.W.; Abts, C.; Brow, A.W.; Chulai, S.; Clark, B.K.; Horowitz, E.; Madachy, R.; Reifer, D.; Steece, B.; Software Cost Estimatio with COCOMO II; Pretice Hall; 2000. [BB 200] Boehm, B.; Basili, V.; Software Defect Reductio Top 0 List ; IEEEComputer 34(); 200; pags. 35-37. 5
[Beck 999] Beck, K., Extreme Programmig Explaied: Embrace Chage, Addiso Wesley Logma, Ic., Massachusetts, 999. [BF 2000] Beck, K.; Fowler, M.; Plaig Extreme Programmig; Addiso Wesley; 2000. [Boehm 988] Boehm, B.W.; A Spiral Model of Software Developmet ad Ehacemet ; IEEE Computer 2(5); IEEE Computer Society; 988; pags. 6-72. [BR 988] [Brooks 986] Basili, V.R.; Rombach, H.D.; The TAME project: Towards improvemetorieted software eviromets ; IEEE Trasactios o Software Egieerig 4(6); IEEE Computer Society; 988; pags 758-773. Brooks, F.P.; No Silver Bullet - Essece ad Accidets of Software Egieerig ; IEEE Computer 20(4); IEEE Computer Society; 986; pags. 0-9. [Cockbur 200] Cockbur, A.; Agile Software Developmet; Addiso-Wesley; 200. [Floyd 967] [Fowler 2000] [FS 998] [FSM 998] [GHW 995] Floyd, R.W.; Assigig Meaig to Programs ; Proceedigs Symposium i Applied Mathematics vol 9; America Mathematical Society; 967; pas 9-32 (valor histórico). Fowler, M.; Refactorig: Improvig the Desig of Existig Code; Addiso Wesley; 2000. Freire, F.; Staa, A.v.; Cocerto: Um Sistema de Acompahameto da Qualidade Pós-Etrega ; Workshop em Qualidade de Software; Marigá, PR; SBC; 998; pags. 9-26. Fiorii, S.T.; Staa, A.v.; Martis, R.B.; Egeharia de Software com CMM; Brasport; Rio de Jaeiro, RJ; 998. Gresse, C.; Hoisl, B.; Wüst, J.; A Process Model fo GQM-Based Measuremet ; Software Techology Trasfer Iitiative Techical Report STTI- 95-04-E, Uiversity of Kaiserslauter, Departmet of Computer Sciece; 995. [Highsmith 2002] Highsmith, J; Agile Software Developmet Ecosystems; Addiso Wesley; 2002 [Hoare 969] Hoare, C.A.R.; A Axiomatic Basis for Computer Programmig ; Commuicatios of the ACM 2(0); 969; pags 576-583 (valor histórico). [Humphrey 989] Humphrey, W.S.; Maagig the software process; Addiso-Wesley; 989. [Humphrey 995] Humphrey, W.S.; A Disciplie for Software Egieerig; Addiso- Wesley; 995. [Humphrey 995] Humphrey, W.S.; Itroductio to the Team Software Process; Addiso- Wesley; 2000. [IEEE 990] [LB 985] [Lehma 998] IEEE Stadard Glossary of Software Egieerig Termiology; ANSI/IEEE Std 60.2-990. Lehma, M.M.; Belady, L.A.; Software Evolutio: Processes of Software Chage; Academic Press; 985. Lehma, M.M.; Software Future: Maagig Evolutio ; IEEE Software 5(); IEEE Computer Society; 998; pags. 40-44. 6