Captura de conhecimento durante a manutenção de software Kleiber Damian de Sousa1, Nicolas Anquetil2, Káthia Marçal de Oliveira2 1
Fundo Nacional de Desenvolvimento da Educação (FNDE) SBS Quadra 02 Edifício Áurea – 70.070-929 – Brasília – DF – Brasil 2
Universidade Católica de Brasília (UCB) SGAN 916 Módulo B Av. W5 Norte – 70.790-160 – Brasília – DF – Brasil
[email protected], {anquetil,kathia}@ucb.br Abstract This paper describes an approach to capture the technical knowledge of the software maintainer that constantly needs to rediscover details about the core bussiness, the system architecture, the process used, etc. To solve this problem the approach presented uses a knowledge management technique called Postmortem Analysis that is traditionaly used at the end of software development projects aiming to collect experiences of the software engineers to improve software process. In this paper we present how to capture their lessons learnt during the execution of modifications in systems. With such approach we can discover knowledge about the maintenance process and mainly about the system that is maintained. Palavras-chave: APM, Postmortem, Manutenção de Software.
Resumo Este artigo apresenta uma abordagem de captura de conhecimento do técnico que mantém software e que constantemente precisa estar redescobrindo detalhes acerca do negócio da corporação, da arquitetura do sistema, dos processos utilizados, etc. Para propor uma solução para tal problema a abordagem faz uso de uma técnica de gestão de conhecimento chamada Análise Postmortem que tradicionalmente vem sendo usada ao final de projetos de desenvolvimento de software com vistas a descobrir as experiências dos engenheiros para melhorar o processo de desenvolvimento de software. Neste artigo é apresentado como capturar as lições aprendidas pelos técnicos durante a execução de manutenções nos sistemas. Com ela pode-se descobrir conhecimento sobre o processo de manutenção usado, e principalmente sobre o software que é mantido.
Keywords: PMA, Postmortem Analysis, Software Maintenance.
1. Introdução A gestão do conhecimento dentro da Engenharia de Software tem sido apresentada como uma maneira de preservação da memória organizacional [15] e alguns mecanismos têm sido usados neste contexto, tal como a fábrica de experiências [1]. Durante a manutenção de software os mantenedores lidam com diversos tipos de conhecimento, tal como os conceitos sobre o domínio da aplicação, sobre a organização
em si, sobre os requisitos novos e antigos do software, sobre os processos usados para se manter o sistema, sobre algoritmos ou técnicas de programação utilizadas, etc. Embora o conhecimento seja um bem precioso, os engenheiros de software não possuem o hábito de compartilhar o que aprendem durante o transcorrer de suas tarefas [2] e não dispõem de formas padronizadas de capturar e registrar o conhecimento usado nestas atividades [11]. Para ajudar a preservar estes tipos de conhecimento o uso de técnicas como a Análise Postmortem (APM) começam a ser utilizadas nos projetos de software das organizações [2, 8, 16]. Esta se trata de uma técnica de gestão de conhecimento na qual os participantes se reúnem ao final de projetos de desenvolvimento de software para enumerar aquilo que de positivo e negativo aconteceu, procurando repetir os acertos nos projetos futuros e evitar que os erros cometidos voltem a aparecer [16]. Estes aspectos são então registrados na forma de um relatório de revisão para que possam ser repassados a outras pessoas da organização que estarão assim se beneficiando futuramente com o compartilhamento das experiências percebidas com a APM. Entretanto, este tipo de procedimento tem sido adotado em projetos de desenvolvimento de software apenas e no que tange ao momento de aplicação a APM tem sido utilizada ao final dos projetos como mecanismo de melhoria do processo de desenvolvimento. Assim, pelo fato dos projetos serem normalmente extensos e pelo fato da manutenção de software ser altamente dependente do conhecimento e envolver uma série de conhecimentos acerca do domínio do software, dos processos usados, dos detalhes das organizações e do ambiente no qual esta está inserida [6] é que este trabalho se propõe a usar a APM em intervalos de tempo menores e durante a atividade de manutenção de software. Com isso, esta abordagem pode ajudar o mantenedor a registrar aquilo que aprendeu não somente sobre o processo utilizado para manter o software, mas principalmente sobre os detalhes que envolvem os sistemas e o domínio do software durante a execução de modificações nos sistemas, permitindo posteriormente buscar formas de empacotar este conhecimento e disseminá-lo entre os engenheiros de software. Face ao exposto, a seção 2 aborda a análise postmortem e como esta tem sido usada tradicionalmente. A seção 3 relata a importância do conhecimento para a atividade de manutenção. Na seção 4 é apresentada a abordagem de captura do conhecimento usado para se manter software e por fim, na seção 5 são mostradas as conclusões e os trabalhos que estão em andamento.
2. Análise Postmortem O filósofo George Santayanna afirma que “aquelas pessoas que não souberem aprender com o passado estarão condenadas a repeti-lo”. Esta frase traduz a essência da Análise Postmortem (APM) que se trata de uma técnica de gestão de conhecimento voltada para a revisão de projetos. Nela os participantes identificam o que de bom e de ruim aconteceu num projeto. Este tipo de procedimento pode possibilitar aos membros de uma organização aprender com o que aconteceu de positivo no projeto, permitindo a
eles repetir os acertos nos projetos futuros e também aprender com aquilo que ocorreu de negativo, para evitar a repetição dos erros [9]. Além disso, a APM pode possibilitar ao grupo propor ações corretivas que permitirão à equipe consertar os problemas detectados. Cabe ressaltar neste ponto que a APM por si só não é capaz de promover a gestão de conhecimento por completo, pois seu principal objetivo é explicitar o conhecimento, sem se preocupar com maneiras mais aprimoradas de empacotamento deste e posterior disseminação, os quais são prerrogativas da gestão do conhecimento organizacional. A APM é conduzida por uma figura chamada de facilitador da revisão. A forma de condução de uma APM pode variar de acordo com o tamanho da organização, o número de participantes envolvidos e a meta estabelecida para a revisão. Nas grandes empresas, tal como a Microsft e Apple, que dispõem de tempo e recursos, uma APM pode durar alguns meses enquanto as revisões que envolvem um número menor de pessoas podem durar umas poucas horas [4]. Para apoiar os facilitadores e os participantes da APM na explicitação do conhecimento algumas técnicas podem ser utilizadas, tal como: as sessões KJ (espécie de brainstorming estruturado), diagramas de Ishikawa (chamados também de diagramas espinha de peixe), questionários e entrevistas estruturadas. A APM tem sido considerada uma prática bastante recomendada em projetos de engenharia de software, conforme propõem [2, 3, 14]. Entretanto, observa-se que algumas características comuns podem ser observadas com sua utilização: ela tem sido usada para a melhoria de processos de software ou de aspectos gerenciais, está relacionada sempre ao contexto do desenvolvimento de software e por último tem sido usada somente ao final de projetos de software. Estudos mostram que a APM tem sido usada principalmente como instrumento de melhoria dos processos de software, por ser considerada uma forma de aprender com os erros e acertos. Além disso, ela tem sido usada para melhorar aspectos gerenciais e para a melhoria de estimativas de custo de projetos [2, 8, 14, 16, 17]. Um outro aspecto referente a APM mostra que ela possui uma relação estreita com o desenvolvimento de software e que tem sido usada ao final de projetos apenas. O fato é que usar a APM somente ao final de projetos tende a deixar excelentes oportunidades de melhoria de processos e descobertas sobre outros aspectos ligados ao software. Ou seja, realizar APMs somente ao final tende a capturar das pessoas conhecimentos genéricos que poderiam ser mais bem explorados se elas fossem aplicadas em intervalos de tempo menores tal como iterações em projetos de desenvolvimento e sub-atividades de um ciclo de manutenção de software. Além do mais, APMs de final de projeto podem não capturar as experiências de técnicos-chave que acabam deixando a equipe original por causa da alta rotatividade existente nos projetos de software [17]. 3. Conhecimento usado na manutenção de software A manutenção de software é resultante de mudanças no ambiente de negócio da organização onde o software opera, e por ser realizada quando o sistema está em sua fase de plena operação não pode ser deixada em segundo plano, já que muitas vezes este
mesmo software acaba se confundindo com o próprio negócio da organização. Assim, a manutenção nos sistemas é uma necessidade incontestável. Entretanto, o que se vê nas corporações é que se dá uma importância menor a esta fase do ciclo de vida do software. Além disso, um dos maiores problemas enfrentados por quem mantém software é a perda de conhecimento que ocorre durante as alterações nos sistemas [7]. Nestas os mantenedores precisam de conhecimentos sobre o domínio da aplicação, sobre os detalhes existentes no código-fonte, acerca da organização e das pessoas que nela trabalham, sobre as práticas adotadas, linguagens de programação, técnicas de modelagem, levantamento de requisitos, testes, etc. Ao não dispor de meios para registrar estes detalhes para que possam ser reaproveitadas nas manutenções futuras, o mantenedor pode estar executando um retrabalho, quando poderia estar realizando outras atividades, dado que o tempo gasto para compreender o sistema e ambiente no qual este está inserido demanda, de acordo com estudos, de 40% a 60% do tempo total gasto pelo mantenedor ao executar uma modificação num sistema [12, 13]. Ou seja, o conhecimento sobre o sistema em si demanda um tempo bastante razoável para ser adquirido e se for capturado e registrado poderá beneficiar outros mantenedores. Um outro ponto que reforça a necessidade por capturar o conhecimento do mantenedor diz respeito às documentações desatualizadas que contribuem para deteriorar um software que a cada nova modificação torna-se mais complexo e difícil de alterar. Por causa disso é importante conseguir do mantenedor este tipo conhecimento para que em algum local da organização este possa estar acessível e se tornar útil a outras pessoas. 4. Abordagem de captura do conhecimento na manutenção de software Antes de efetivamente mostrar a abordagem de captura de conhecimento nesta atividade cabe ressaltar dois aspectos que são capazes de justificar a aplicação da APM na manutenção de software: Primeiro, ela tem sido aplicada somente em projetos de desenvolvimento e ao final deles objetivando capturar conhecimento útil para melhorar o processo de software de uma organização. Segundo, a atividade de manutenção de software é altamente dependente do conhecimento técnico do mantenedor que muitas vezes não é a mesma pessoa que desenvolveu o aplicativo. Ou seja, não é quem detém o know-how sobre o software. Assim, explicitar o conhecimento adquirido pelo mantenedor deve ser uma máxima para as corporações que desejam aprender e evoluir continuamente [5]. Este trabalho procurou inserir a APM num contexto diferente, no caso a manutenção, e fazer uso da técnica em intervalos de tempo menores que os praticados nos projetos de desenvolvimento para capturar conhecimentos mais específicos que os tradicionalmente abordados. Ao final, o objetivo da abordagem é ajudar o mantenedor de software a explicitar o conhecimento que utiliza nos projetos de manutenção. Conhecimentos estes relacionados não somente ao processo usado nesta atividade (como ele é usado, quais procedimentos inerentes à organização são seguidos, quais técnicas e ferramentas são usadas, etc.), mas principalmente com relação ao sistema que
ele mantém (procurando explicitar detalhes sobre os componentes, requisitos, restrições, etc.). Com isto em mente, procurou-se dar respostas a três aspectos muito importantes com relação a aplicação das APMs no contexto da manutenção de software, quais sejam: (i) Quando aplicar as APMs? (ii)Que tipo de conhecimento coletar por meio das APMs? (iii)Como coletar os tipos de conhecimentos definidos por meio das APMs? 4.1 Quando aplicar a APM durante a manutenção de software A construção da abordagem para capturar o conhecimento usado na manutenção de software está em conformidade a dois pilares principais: primeiro, o processo de manutenção de software. Segundo, o uso da APM como mecanismo de explicitação do conhecimento técnico do mantenedor. Para tal, escolheu-se o processo de manutenção da ISO como referência, o padrão NBR ISO/IEC 12207 (1995), visto que qualquer organização que faça uso de um mecanismo ordenado para manter um software realiza basicamente os passos propostos por esta norma. Estes são mostrados graficamente na figura 1, bem como os marcos de aplicação das APMs no ciclo de alteração de software: • Implementação do processo: nesta etapa, são estabelecidos planos e procedimentos para registrar e controlar a atividade de manutenção e os pedidos feitos pelos usuários. • Análise do problema e da modificação: nesta etapa, é feita uma verificação minuciosa da solicitação, por parte do mantenedor, para que este possa oferecer opções de solução para o problema identificado, e também verificar o impacto que a modificação acarretará no sistema. • Implementação da Modificação: nesta etapa, são realizadas as tarefas propriamente ditas de alteração do produto de software, inclusive sua documentação. Nela, deve-se garantir a perfeita execução para se chegar à solução proposta. • Aceitação / Revisão da Modificação: nesta etapa, são feitas a homologação e a aprovação junto ao solicitante para que o produto possa ser liberado. • Migração para o ambiente de produção: nesta etapa, o produto gerado é colocado no ambiente de produção e uma avaliação deve ser conduzida para confirmar a execução perfeita da alteração. • Descontinuação do Software: nesta etapa, o software chega ao seu último estágio no ciclo de vida e não haverá mais modificações no mesmo. Durante a proposição da abordagem notou-se que existia uma “quebra”, um marco importante na execução de um ciclo de modificação, onde se sai do levantamento e mapeamento do problema propriamente dito para a construção da solução a ser adotada. Este marco é a transição entre a fase de análise dos requisitos e a de construção da solução, partindo do pressuposto que o tipo de manutenção em questão envolva as etapas tradicionais de um ciclo completo de modificação que possui os seguintes passos: análise, projeto, codificação, testes.
Visto que existe uma ruptura durante a execução do ciclo quando se vai do “o que se deseja resolver?” para “como resolver tal problema?”, notou-se oportuno realizar APMs em três pontos durante um ciclo de manutenção (ver figura 1). Implementação do Processo Análise do problema e da Modificação Implementação da Modificação Aceitação / Revisão da Manutenção
Análise Projeto
APM pós-análise (i)
Codificação Testes
APM pósimplementação (ii)
Migração para o ambiente de produção Descontinuação do Software
APM pós-ciclo de manutenção (iii)
Figura 1. Marcos para aplicação das APMs na manutenção Primeiro, ao final da fase de análise dos requisitos (i), com a meta de coletar conhecimento acerca do domínio do software, suas regras negociais, planejamento da manutenção e sobre os documentos gerados sobre o sistema. Nesta APM o conhecimento revisado seria aquele utilizado desde o início do ciclo de modificação, que começa a partir da recepção do pedido feito pelo usuário, se estendendo até a conclusão da análise de requisitos, passando ainda pela análise de impacto da modificação, planejamento e alocação dos recursos humanos que participarão da atividade de implementação. Segundo, ao final da implementação da modificação propriamente dita (ii), com a meta de coletar conhecimento acerca dos detalhes que circundam o aplicativo, tal como a modificação de componentes do software, detalhes sobre o uso das ferramentas para construção da solução, técnicas de teste, projeto e programação. Nesta APM o conhecimento revisado seria aquele utilizado pelos mantenedores desde o projeto da solução da modificação, passando pela codificação e findando-se nos testes funcionais do aplicativo. Por último, ao final do ciclo (iii), depois que o produto de software teve sua nova versão migrada para o ambiente de produção, com a meta de coletar conhecimento acerca do processo utilizado nas APMs, além dos detalhes percebidos pelos mantenedores para melhorar o processo de manutenção da organização e também para que as pessoas possam estabelecer uma visão compartilhada sobre o que aconteceu de relevante durante o ciclo de alteração como um todo. 4.2 Tipos de conhecimento-alvo da APM usada na manutenção de software Os tipos de conhecimento a serem coletados seriam feitos de acordo com o escopo e momento de aplicação da APM. Assim, detalhes sobre a utilização de
ferramentas de programação seriam vistas na segunda APM, na etapa de codificação da parte a ser alterada do software. Desta maneira foram estabelecidas categorias de conhecimento que serviriam posteriormente para enumerar questões relevantes na elaboração de um questionário direcionador para ajudar os participantes da APM a descobrirem conhecimentos úteis ao contexto da organização em que trabalham. Estas categorizações são resumidas no quadro 1 e foram estabelecidas com base nas atividades executadas pelo mantenedor durante a realização de um ciclo de manutenção realizado com base no processo de manutenção. Quadro 1 – Categorias de conhecimento para cada APM da abordagem Tipo de APM APM pós-análise de requisitos
APM pósimplementação
APM pós-ciclo de manutenção
Categorias de Conhecimento Detalhes sobre a requisição de modificação Estrutura Organizacional que faz uso do Software Opções identificadas para implementação da modificação Negociação com relação ao prazo para realização da manutenção Estimativa de esforço para realização da modificação Documentos que foram modificados Técnicas de elicitação de requisitos Ferramentas usadas Domínio da aplicação Detalhes acerca dos requisitos do software Linguagens e técnicas de programação Componentes do Software modificados Inter-relacionamento entre sistemas Inconsistências entre análise de requisitos e projeto Oportunidades de re-reengenharia do software Rastreabilidade entre artefatos Projeto de Banco de Dados Padrões de Projeto usados Técnicas de Testes utilizadas Documentação do processo de manutenção e de apoio usados Negociação entre área do setor de tecnologia Acompanhamento da modificação Processo de Manutenção Aplicação das APMs
4.3 Como realizar a APM durante a manutenção de software Sabendo quando e o que exatamente capturar por meio das APMs definiu-se como tornar possível esta explicitação do conhecimento, ou como ajudar o mantenedor a lembrar-se do que precisou durante uma manutenção e quais detalhes ele teve contato e que permitiram a ele executar as tarefas que lhe foram propostas. Para tal, optou-se inicialmente pela elaboração de questionários direcionadores. Alguns autores recomendam o uso de questionários para poder focar as APMs nos assuntos considerados mais importantes, ou naqueles em que se necessitam mais de melhoria [4, 9]. Eles são compostos por questões acerca das diversas categorias estabelecidas, conforme mostra o exemplo de uma parte de questionário da APM pós-implementação na figura 2.
Estes questionários são entregues antes da APM propriamente dita para que os mantenedores vão pensando nas respostas que servirão para direcionar a APM. No momento da APM, os tópicos mencionados nos questionários vão sendo trazidos à tona para que sejam descobertas as lições aprendidas pelos mantenedores durante o pedaço do ciclo que está sob revisão. A APM pode ser apoiada por algumas técnicas, conforme mencionado na seção 2, tal como uma entrevista estruturada, uma sessão KJ, diagramas de Ishikawa, ou ainda pela combinação destes dois últimos, como mostra [16]. O tipo de técnica de apoio a ser usada fica sob a decisão do facilitador da revisão que deverá considerar o tamanho da equipe envolvida, o tamanho da manutenção, a importância da manutenção, etc. Categoria: Detalhes sobre os requisitos • Foi descoberta alguma documentação do sistema que você não conhecia? Qual? Categoria: Componentes modificados • O que foi aprendido sobre os componentes do sistema que não se conhecia? • Você identificou algum aspecto sobre os componentes do sistema que os demais membros da equipe deveriam saber? • Você teve algum tipo de dificuldade para modificar os componentes ou documentos de projeto do sistema?
Figura 2. Parte do questionário direcionador da APM pós-implementação
4.4 Resultados obtidos com a APM aplicada durante a manutenção de software Até o momento foram aplicadas APMs no contexto da manutenção de software de uma autarquia do governo federal nas quais foram usadas entrevistas estruturadas, pelo fato delas proverem uma agenda bem definida e serem capazes de complementar aspectos se levar em consideração que o questionário simplesmente respondido pelo mantenedor pode gerar algumas dúvidas. Os resultados já mostram que conceitos importantes sobre o processo e o produto de software gerado pela manutenção, dente eles podem-se citar os seguintes: • Domínio da aplicação – o conhecimento do negócio referente a áreas específicas da organização que eram de domínio de um mantenedor em particular passaram a ser de domínio da equipe como um todo. • Detalhes na utilização do banco de dados - se não fossem explicitados tornar-seiam parte do modelo mental de um mantenedor de maneira isolada [17] e seria perdida a oportunidade de se aprender sobre os aspectos abordados a respeito da porção modificada do software. Além disso, as APMs possibilitaram aos mantenedores tomar conhecimento de detalhes como o funcionamento de determinadas tabelas do banco de dados que nem todos os membros da equipe conheciam. • Componentes da aplicação – partes do código-fonte que eram mantidos por uma pessoa da equipe passou a ser domínio de toda ela.
•
Inconsistências entre artefatos – a identificação de disparidades entre os documentos de especificação e os componentes implementados puderam ser atualizados, gerando consistência entre o que foi pedido e o que efetivamente foi construído como solução. • Possibilidades de reengenharia de porções do software – isto foi possível com a aplicação da APM pós-implementação que acabou por gerar manutenções para melhorar determinadas porções do aplicativo sob revisão. • Regras de negócio – regras importantes ao negócio do software foram explicitadas. Conhecendo-as, mais facilmente os mantenedores poderão alterar o software futuramente. O próximo passo é fazer uso de outras técnicas como a sessão KJ e adquirir mais experiência na aplicação das técnicas de apoio. 5. Conclusão Este trabalho apresentou uma abordagem para capturar o conhecimento do mantenedor de software que constantemente precisa estar lidando com aspectos relativos ao negócio da organização, técnicas, ferramentas, linguagens de programação, e principalmente precisa estar compreendendo e aportando soluções para os sistemas que suportam as diversas atividades desempenhadas pelas organizações que fazem uso dos sistemas de informação. A abordagem apresentada fez uso de uma técnica tradicionalmente aplicada ao final de projetos de desenvolvimento de software que tem como objetivo principal melhorar o processo de desenvolvimento de software. Neste trabalho procurou-se aplicá-la ao contexto da manutenção de software para coletar conhecimentos usados pelos mantenedores, tanto com relação ao processo de software utilizado, quanto com relação ao sistema mantido. Os trabalhos em andamento acerca desta pesquisa estão relacionados à aplicação da abordagem numa série de manutenções e também à instanciação de conceitos descobertos com as APMs tomando como base uma ontologia do conhecimento usado pelos mantenedores em uma autarquia da esfera federal brasileira. Em seguida, pretende-se buscar maneiras precisas de empacotamento destes conhecimentos para posterior disseminação para que possam ser reutilizados. Agradecimentos O presente trabalho foi realizado com apoio do CNPq, uma entidade do governo brasileiro voltada ao desenvolvimento científico e tecnológico. Referências [1] Basili, Victor R., Caldiera, Gianluigi, and Rombach, Dieter. Encyclopedia of Software Engineering, Volume 1, chapter The Experience Factory, pgs 469-476.John Wiley & Sons, 1994.
[2] Birk, Andreas. Dingsoyr, Torgeir. and Stalhane, Tor. Postmortem: Never Leave a Project Without It, IEEE Software, vol. 19, Num. 3, pgs. 43-45, May-June. 2002. [3] Brady, Sheila. DeMarco, Tom. Management Aided Software Engineering. IEEE Software, vol. 11, Num. 6, pgs. 25-32, November-December. 1994. [4] Collier, Bonnie. DeMarco, Tom. and Fearey, Peter. A Defiened Process for Project Postmortem Review, IEEE Software, vol. 13, Num. 4, pgs. 65-72, June-August. 1996. [5] Briand, Lionel C. On the many ways software engineering can benefit from knowledge engineering. In Proceedings of the 14th international conference on Software engineering and knowledge engineering (SEKE). 2002. Italy. [6] Dias, Marcio G. B., Anquetil, Nicolas., and Oliveira, Káthia M. Organizing the knowledge used in software maintenance. In Ulrich Reimer, Andreas Abecker, Steen Staab, and Gerd Stumme, editors, WM2003: Professionnelles Wissensmanagement { Erfahrungen und Visionen, number ISBN 3-88579-357-1, pages 65-72. Lecture Notes in Informatics, Gesellschaft fur Informatik, Bonn, April, 3rd 2003. Presented at the Learning Software Organizations Workshop. [7] Dias, Marcio G. B., Anquetil, Nicolas., and Oliveira, Káthia M. Organizing the knowledge used in software maintenance. Journal of Universal Computer Science, 9(7):641-658, 2003. [8] Dingsoyr, Torgeir., Moe, Nils Brede., and Oystein, Nytro. Augmenting experience reports with lightweight postmortem reviews. Lecture Notes in Computer Science, 2188:167{181, 2001. PROFES 2001, Berlin, Germany. [9] Humphrey, Watts S. The Postmortem. In Introduction to Team Software Process. 2000. Addison Wesley Longman, pgs. 185-196. Massashussets. 2000. [10] ISO/IEC 12207. Information technology | Software life cycle processes. ISO/IEC, 1995. [11] Komi-Sirvio, Seija., Mäntyniemi, Annukka, and Seppänen, Veikko. Toward a Practical Solution for Capturing Knowledge. IEEE Software, vol. 19, Num. 3, pgs. 60-62, May-June. 2002. [12] Pfleeger, Shari Lawrence. Software Engineering: Theory and Practice. Prentice Hall, 2nd Edition, 2001. [13] Pigoski, Thomas M. Practical Software Maintenance. John Wiley & Sons, Inc.,1996. [14] Reel, John S. Critical Success Factors in Software Projects. IEEE Software, vol. 16, Num. 3, pgs. 18-23, May-June. 1999. [15] Rus, Ioana., and Schneider Kurt. Knowledge Management in Software Engineering. IEEE Software, vol. 19, Num. 3, pgs. 26-38, May-June. 2002. [16] Stalhane, Tor, Dingsoyr, Torgeir., Hanssen, Geir K., and Moe, Nils Brede. Postmortem - An assessement of two approaches. In Proceedings of the European Software Process Improvement (EuroSPI). 2001. Ireland. [17] Yourdon, Ed. Minipostmortems. Computerworld, March 19, 2001.
