Evolução de Sistemas de Software: Uma Abordagem Quantitativa

Evolução de Sistemas de Software: Uma Abordagem Quantitativa Miguel Carlos Pacheco Afonso Goulão (Licenciado) Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores DOCUMENTO PROVISÓRIO Julho de 1999

Dissertação realizada sob a orientação do Professor Doutor Pedro Manuel Moreira Vaz Antunes de Sousa Professor Auxiliar do Departamento de Engenharia Electrotécnica e de Computadores Instituto Superior Técnico Universidade Técnica de Lisboa iii

iv

Resumo A actividade de manutenção de sistemas de software absorve uma percentagem muito elevada dos recursos existentes para o desenvolvimento e manutenção dos mesmos. Não obstante a intensa actividade de investigaçãoanível internacional no sentido de desenvolver abordagens quantitativas que facilitem a gestão da evolução de sistemas, existe ainda um grande fosso entre as propostas desenvolvidas a nível académico e a realidade das organizações produtoras de software. Esta dissertação contribui com uma abordagem integrada para o suporte às actividades de manutenção e respectiva gestão, com uma base quantitativa, consubstanciada na implementação de uma ferramenta destinada a apoiar a abordagem proposta num ambiente distribuído, utilizando uma intranet como meio de transmissão de dados. A combinação de um sistema de produção automática de documentação do código fonte dos sistemas a manter, com um sistema de rastreio de acções de evolução e a análise de complexidade das mesmas constituem o núcleo da dissertação. O primeiro aspecto lida com a insuficiente ou inadequada documentação existente acerca dos sistemas a manter. O segundo, com a rastreabilidade da evolução dos sistemas e do processo que lhe está subjacente. O terceiro enquadra-se na abordagem quantitativa que se pretende dar à gestão do processo de software, tendo como objectivo fundamental a sua melhoria. v

vi

Abstract Software system s maintenance absorbs a high percentage of the resources made available by organizations to the software development and maintenance activities. In spite of the significant international research effort towards the development of quantitative approaches to the management of software system s evolution, the gap between the academic proposals and the software industry s reality remains a problem. This thesis presents an integrated quantitative approach to support and manage software maintenance. This proposal is reinforced by the development of a suitable software tool to support it on a distributed environment, using an intranet as the data transmission backbone. The tool combines the automatic production of source code documentation with a software evolution tracking system and software complexity analysis. The first aspect of the tool deals with the problem of non existent or outdated documentation on the maintained systems source code. The second one provides the means for tracking the evolution of software systems and underlying software process. The third aspect gives way for a quantitative approach on software process management, with the ultimate goal of software process improvement. vii

viii

Palavras Chave & Keywords Palavras Chave Engenharia de Software Empírica Sistemas de Rastreio de Acções de Evolução Qualidade de Software Modelos de Complexidade do Software Evolução do Processo de Software Ferramentas de Apoio à Manutenção de Sistemas de Software Keywords Empirical Software Engineering Software Evolution Tracking Systems Software Quality Software Complexity Models Software Process Improvement Tool Support for Software System s Maintenance ix

x

Agradecimentos Ao meu orientador, Professor Pedro Sousa, desejo agradecer o apoio prestado ao longo da elaboração desta dissertação, em particular pelo espírito crítico e objectivo com que pautou as diversas discussões que tivemos acerca do trabalho que originou esta tese. Ao Engenheiro Fernando Brito e Abreu, coordenador do projecto do qual surgiu esta tese, desejo expressar a minha gratidão pela sua total disponibilidade e entusiasmo no acompanhamento e discussão de diversos aspectos relacionados com este projecto, desde o estabelecimento de objectivos, à colaboração na elaboração de diversos documentos de carácter científico produzidos no âmbito deste trabalho, sem esquecer as revisões a este documento. Numa perspectiva mais abrangente, gostaria também de manifestar o meu reconhecimento pelo gosto que ao longo dos últimos anos me foi incutindo pelas actividades de investigação e ensino. À Direcção de Análise e Métodos de Apoio à Gestão da Marinha Portuguesa, em particular ao Cmdt. Carmo Durão, ao CTen. Bigotte de Almeida, ao Ten. Silva Monteiro e ao Ten. Palmeiro Ribeiro, pelo interesse e colaboração, sem os quais a elaboração do presente trabalho não teria sido possível. Ao INESC, pelo apoio institucional, logístico e científico que me proporcionou. Aos meus colegas do Grupo de Engenharia de Software e da Unidade de Reengenharia da Link. Aos meus irmãos, Pedro, Jorge, Beatriz, Amélia e Maria, à minha velha amiga Fátima, ao meu pai, Manuel, aos meus tios Lurdes e Armando, e aos restantes familiares, por todo o apoio, amor e carinho que sempre me deram. xi

A um bando de patifes que se dedicaram de forma criativa a tornar tudo isto bem mais interessante: Rita, Jota, Marta, Nuno, Teresa, Inês, Pedro, Hugo, Ilídio, Fred, Lurdes, J.P., Zé, Joana e Sofia. Lisboa, 4 de Agosto de 1998 Miguel Carlos Pacheco Afonso Goulão xii

Conteúdo Resumo v Abstract vii Palavras Chave & Keywords ix Agradecimentos xi Índice xviii Lista de Figuras xxi Lista de Tabelas xxiii Notação xxv 1 Introdução 1 1.1 Motivação.................................... 2 1.2 Contribuições Fundamentais......................... 4 1.3 Enquadramento do Trabalho......................... 5 1.4 Estrutura da Dissertação............................ 6 xiii

2 Fundamentos e Trabalho Relacionado 9 2.1 Introdução.................................... 9 2.2 Qualidade e Engenharia de Software..................... 12 2.2.1 Origens................................. 12 2.2.2 Qualidade de software......................... 14 2.2.3 Engenharia de Software........................ 16 2.3 Processo de Software.............................. 17 2.4 Maturidade do Processo............................ 17 2.4.1 Validade da avaliação da maturidade do processo......... 20 2.5 Processo de Medição.............................. 21 2.5.1 Metodologia GQM........................... 22 2.5.2 Métricas de Processo.......................... 26 2.5.3 Métricas de Produto.......................... 27 2.6 Recolha de Dados................................ 32 2.6.1 Sistemas de Rastreio de Acções de Evolução............ 32 2.6.1.1 PITS - Project Issue Tracking System........... 33 2.6.1.2 TeamTrack.......................... 36 2.6.1.3 Sistemas de Recolha de Métricas de Produto....... 38 2.7 Modelos de Estimação de Recursos...................... 40 2.7.1 O Modelo COCOMO.......................... 40 2.7.2 O Modelo de Pontos de Função.................... 44 2.8 Iniciativas de Melhoria do Processo de Software.............. 48 2.9 Síntese...................................... 49 xiv

3 O projecto SofTrack 51 3.1 Enquadramento................................. 51 3.2 O Problema................................... 52 3.2.1 Facilidade de manutenção....................... 52 3.3 Factores limitativos da facilidade de manutenção.............. 54 3.3.1 Estratégia para melhoria do processo................ 56 3.3.2 Sistemas em análise.......................... 57 3.4 Re-documentação de sistemas......................... 58 3.5 Factores Humanos............................... 59 3.6 Arquitectura do SofTrack............................ 60 3.6.1 Rede de Comunicação......................... 61 3.6.2 Servidor................................. 63 3.6.2.1 Recolha de Métricas de Produto - Logiscope....... 64 3.6.2.2 Documentação Automática de Software......... 66 3.6.2.3 Repositório do Processo de Software........... 69 3.6.2.4 Gerador de Relatórios de Análise............. 76 3.6.2.5 Servidor de Sessão...................... 78 3.6.2.6 Estabelecimento de uma Política de Acesso a Dados.. 78 3.6.3 Cliente.................................. 80 3.6.4 Repositórios de Dados......................... 81 3.7 Síntese...................................... 82 4 Aspectos de Concepção e Realização 83 4.1 Introdução.................................... 83 xv

4.2 Recolha de Métricas de Produto........................ 83 4.3 Documentação Automática do Software................... 86 4.4 Repositório de Processo do Softrack..................... 86 4.5 Agregação da Informação Acerca de Processo e Produto......... 88 4.6 Geração de Relatórios de Análise....................... 91 4.7 Servidor de Sessão............................... 92 4.7.1 Servlets.................................. 92 4.7.2 Cookies................................. 94 4.7.3 Servidor de Sessão........................... 95 4.7.3.1 Classes de base........................ 95 4.7.3.2 Ciclo de vida do servidor de sessão............ 96 4.7.3.3 Inicialização do servidor de sessão............ 96 4.7.3.4 Estrutura dos pedidos dirigidos ao SofTrack....... 99 4.7.3.5 Satisfação de pedidos no servidor de sessão....... 100 4.7.4 Gestão da política de acesso a dados................. 107 4.7.5 Acesso aos Dados via JDBC...................... 108 4.7.6 Visualização de Relatórios....................... 110 4.8 Síntese...................................... 111 5 Análise Quantitativa da Evolução de Sistemas de Software 115 5.1 Introdução.................................... 115 5.2 Leide Pareto................................... 116 5.3 Processo de Software.............................. 117 5.3.0.1 Processo de recolha de dados............... 117 xvi

5.3.0.2 Caracterização das Acções de Evolução.......... 120 5.3.0.3 Estabilidade e Fiabilidade do Software.......... 130 5.3.0.4 Satisfação dos clientes.................... 130 5.4 Modelos de Estimação............................. 132 5.4.1 Modelo para a Complexidade de Software............. 133 5.4.1.1 Avaliação da Complexidade de Software......... 133 5.4.1.2 Construção do Modelo................... 134 5.5 Facilidade de Manutenção Revisitada.................... 140 5.6 Heurísticas para o Desenho de Software................... 141 5.7 Síntese...................................... 142 6 Conclusões e Trabalho Futuro 143 6.1 Conclusões.................................... 143 6.2 Trabalho Futuro................................. 146 A Bibliografia 149 B Avaliação da Maturidade do Processo de Desenvolvimento 157 B.1 CMM - Capability Maturity Model...................... 157 B.2 BOOTSTRAP.................................. 161 B.3 SPICE - Software Process Improvement Capability and determination. 165 B.4 ISO 9000..................................... 168 C Apêndice B-Métricas de Complexidade do Produto 171 C.1 Métricas de Complexidade de Software................... 171 C.2 Complexidade Textual............................. 171 xvii

C.3 Complexidade Estrutural........................... 178 C.4 Outras Métricas................................. 181 xviii

Lista de Figuras 2.1 O modelo de qualidade do ISO/IEC9126................... 15 2.2 Estrutura genérica de um plano GQM.................... 26 2.3 Ciclo de vida de um registo no PITS...................... 33 2.4 Ciclo de vida de um registo no TeamTrack.................. 37 2.5 Extracção de características a partir do código fonte............. 39 2.6 Cálculo dos pontos de função......................... 46 3.1 Arquitectura do SofTrack............................ 61 3.2 Interacção entre os clientes e o SofTrack.................... 62 3.3 Arquitectura do Servidor............................ 63 3.4 Extracto de um grafo de dependências do SAMARITAN.......... 68 3.5 Vista do SAMARITAN.............................. 68 3.6 Ciclo de vida de um registo no RAPE.................... 71 3.7 Preenchimento dos dados por parte do utilizador.............. 74 3.8 Exemplo de lista de acesso de um utilizador................. 81 3.9 Vista da lista de acesso de um utilizador no SofTrack............ 82 4.1 Recolha de métricas de produto........................ 84 4.2 Agregação de métricas de produto e processo no SPSS........... 88 xix

4.3 Exemplo de gerador de relatórios de gestão.................. 91 4.4 Java Servlet API................................. 96 4.5 Ciclo de vida do SessionServlet......................... 97 4.6 Método Init da classe SessionServlet................. 98 4.7 Excerto do código fonte de shownewuser.htm............... 100 4.8 Excerto do código fonte de shownewuser.htm............... 101 4.9 Método service da classe SessionServlet............... 103 4.10 Organização das classes de implementação de serviços........... 104 4.11 Método perform da classe ServNewUserC................ 105 4.12 Método redirect da classe ServiceC................... 106 4.13 Vista do Explorador do SofTrack........................ 108 4.14 Organização das classes de implementação de serviços........... 109 4.15 Método makequery da classe RAREHandleC................ 110 5.1 Gráfico de controlo da evolução do número de pedidos........... 120 5.2 Distribuição das acções, por estado do pedido................ 122 5.3 Distribuição das acções de evolução final, por origem do pedido..... 123 5.4 Distribuição das acções de evolução final, por módulo atingido...... 124 5.5 Distribuição das acções de evolução final, por prioridade.......... 125 5.6 Distribuição dos pedidos por fase do processo................ 126 5.7 Conjunto de pedidos pendentes atribuídos a um utilizador......... 127 5.8 Distribuição das acções de evolução final, por prioridade.......... 128 5.9 Distribuição das acções de evolução final, por prioridade.......... 128 5.10 Vista de um módulo no SAMARITAN..................... 129 xx

5.11 Métricas de complexidade do produto..................... 129 5.12 Tempo médio entre falhas............................ 130 5.13 Frequências de tempos de reparação...................... 131 5.14 Pedidos ordenados por tempo de reparação................. 131 5.15 Detecção de tempos de reposição atípicos................... 132 5.16 Distribuição das acções de evolução final, por prioridade.......... 135 5.17 Teste de Durbin-Watson............................. 139 5.18 Esforço estimado face ao esforço efectivo................... 140 B.1 O modelo CMM................................. 158 B.2 Ciclo de reavaliação de um processo...................... 162 B.3 Composição de processos no BOOTSTRAP.................. 162 B.4 Avaliação da maturidade no BOOTSTRAP.................. 163 xxi

xxii

Lista de Tabelas 2.1 Constantes do COCOMO para a estimação do esforço........... 42 2.2 Constantes do COCOMO para a estimação do prazo............ 43 2.3 Constantes do COCOMO para a estimação do esforço com o modelo intermédio.................................... 44 3.1 Sistemas Analisados no Projecto SofTrack.................. 57 3.2 Perfis de utilizadores............................... 79 5.1 Sistemas Analisados no Projecto SofTrack.................. 136 5.2 Parâmetros do Modelo de Esforço....................... 137 C.1 Níveis de linguagens............................... 176 xxiii

xxiv

Notação Ao longo do texto da presente tese, são usadas diversas notações tipográficas de forma a facilitar a leitura do mesmo: Expressões em inglês aparecem escritas em itálico. Conceitos novos são escritos em negrito. Informação extraída do código fonte de programas é apresentada em letra de máquina de escrever. Informação relativa a fórmulas matemáticas é indicada O restante texto é apresentado em românico. xxv

xxvi

1 Introdução A promoção da qualidade de produtos não deve ser apenas realizada através de inspecções ao produto final. A qualidade resulta em grande parte das condições criadas dentro de uma organização para a suportar. Por outras palavras, o processo de desenvolvimento de um produto é um factor essencial. No caso particular da produção de software, as organizações têm vindo a dedicar um crescente interesse à gestão do seu processo de software, encarando-o como um factor essencial para a entrega de software dentro dos prazos e orçamentos estimados, respeitando os critérios de qualidade estipulados (Derniame et al., 1999). O reconhecimento da dificuldade de gerir eficazmente aquilo que não se consegue medir tem funcionado como mola impulsionadora para muitos programas de métricas, em que as organizações procuram medir para poder gerir os seus processos de desenvolvimento (Dekkers, 1999). Existem razões fortes para suportar a actividade de medição. Os gestores de projecto necessitam de definir correctamente o produto, garantir a execução do projecto de forma eficiente e concluí-lo dentro do prazo estimado. As métricas de software podem auxiliar à obtenção destes objectivos (Abreu, 1992; Grady, 1992). À medida que um maior conjunto de organizações vai adoptando planos de métricas no âmbito de iniciativas de melhoria do processo de software, a utilização de uma abordagem quantitativa ao desenvolvimento de software está a tornar-se numa vantagem competitiva para as organizações que a adoptam. As métricas facilitam a detecção, padronização e melhoria das práticas de desenvolvimento que provem levar a melhores resultados. Em Portugal os casos em que o processo de software das organizações contempla 1

2 CAPÍTULO 1. INTRODUÇÃO uma abordagem quantitativa para a sua gestão são ainda excepcionais, contrariando uma tendência que se tem acentuado sobretudo em países do Norte da Europa, em que um crescente número de organizações adopta planos de métricas para promover a qualidade do processo (Punter & Lami, 1998). As razões por detrás deste facto vão desde a relativa juventude da indústria de software, ao reduzido ênfase que os planos curriculares da generalidade das licenciaturas em Informática dão à gestão do processo de software, particularmente no que respeita a projectos de grande dimensão. 1.1 Motivação A gestão da qualidade do software deve começar pela gestão dos seus defeitos (Humphrey, 1994). Um primeiro passo a dar nessa gestão é a criação de mecanismos de suporte ao registo dos defeitos encontrados. Com algum esforço adicional, é possível registar não apenas a detecção dos defeitos, mas também a sua caracterização e a descrição da acção de manutenção desencadeada para os solucionar. O âmbito desta actividade de registo pode ser alargado a toda a actividade de manutenção desenvolvida sobre os sistemas informáticos, abarcando, assim, actividades correctivas, evolutivas e preventivas. Com este registo alargado de actividades, implementado através de um sistema de rastreio de acções de evolução, está criada uma base para uma posterior recuperação da evolução histórica dos sistemas analisados, motivos que estiveram por detrás das acções de evolução, quem as realizou e com que esforço. Sendo uma evolução significativa relativamente à inexistência de registos, os sistemas de rastreio de acções de evolução (e.g. (Callahan et al., 1998; TeamShare, 1997; Rational, 1999)) apresentam ainda algumas lacunas: A facilidade de análise da descrição das acções de evolução, a um nível macroscópico depende bastante da disciplina no preenchimento dos registos, uma vez que as descrições são feitas de forma textual não estruturada. A não utilização sistemática de expressões chave bem definidas dificulta posteriores pesquisas. Esta questão coloca-se sobretudo ao nível de sistemas destinados a ser usados num ambiente aberto em que os registos de rastreio poderão ser

1.1. MOTIVAÇÃO 3 parcialmente preenchidos, por exemplo, pelos utilizadores finais dos sistemas rastreados. A possibilidade de combinar métricas de produto com métricas de processo não é contemplada neste tipo de ferramentas, o que limita o tipo de estudos que se podem realizar, nomeadamente no que diz respeito àanálise da complexidade do software. Um dos aspectos da qualidade de software preponderante para a remoção dos defeitos encontrados é a sua facilidade de manutenção. Esta, pode ser determinada à posteriori através da análise dos registos de manutenção, ou estimada através do estudo da complexidade inerente aos componentes de software a manter (Abreu & Melo, 1996). Com efeito, a recolha de métricas de complexidade de software 1 permite a detecção dos componentes com maior propensão para conter defeitos. É possível estabelecer limiares para várias métricas de complexidade, que servem para a construção de heurísticas acerca das soluções de desenho encontradas no desenvolvimento de software (). Outra forma de aumentar a facilidade de manutenção é a utilização de mecanismos de documentação automática do software, de forma a que, em qualquer momento, os membros das equipas de manutenção tenham acesso a versões actualizadas da documentação. Defende-se nesta dissertação que as três vertentes apresentadas para a melhoria do processo de software (rastreio de acções de evolução, análise da complexidade do software e documentação automática do mesmo) podem e devem ser integradas por forma a que os utilizadores destas facilidades não sejam sobrecarregados com um conjunto de várias ferramentas desagregadas. O cruzamento de dados relativos ao produto e ao processo permite também o desenvolvimento de estudos empíricos relacionando a complexidade do software com a sua facilidade de manutenção. Defende-se também a adopção de uma abordagem quantitativa para a gestão do processo de software, perspectivando a transformação deste numa actividade 1 O termo complexidade é aqui usado como sinónimo da dificuldade de compreensão dos componentes de software, por parte dos elementos da equipa responsável pela sua manutenção.

4 CAPÍTULO 1. INTRODUÇÃO de engenharia, repetível, controlável e passível de ser transferida sem grandes sobressaltos entre sucessivos membros das equipas de manutenção, por oposição ao carácter eminentemente criativo de que o desenvolvimento de software ainda se reveste. 1.2 Contribuições Fundamentais As contribuições avançadas nesta dissertação consistem, no essencial, nos seguintes pontos: Definição e implementação de uma arquitectura para uma ferramenta que combina a documentação automática de código com a apoio à gestão quantitativa do processo de software. Este apoio resulta da recolha e análise de métricas de software incidindo sobre a complexidade do mesmo e o seu processo de desenvolvimento. Além da produção de diversos relatórios de apoio à gestão do processo de software a ferramenta proposta suporta o rastreio das acções de evolução do software. Por forma a que a recolha de dados acerca do processo seja realizada com a contribuição de todos os agentes envolvidos na sua evolução, desde a equipa de manutenção até aos utilizadores finais, a possibilidade de utilização da ferramenta é facultada através de uma rede de comunicação a que todos estes intervenientes têm acesso. Ensaio da arquitectura proposta num ambiente de produção de software não académico. Desenvolvimento de um modelo para a complexidade do software e sua relação com os custos de manutenção, com base nos dados recolhidos no caso de estudo oferecido pelo ensaio da arquitectura. Desenvolvimento de heurísticas de desenho de componentes de software, com base no modelo de complexidade acima referido. Estas heurísticas auxiliam as equipas de desenvolvimento na tomada de opções de desenho, com vista à produção de software que privilegie a facilidade de manutenção.

1.3. ENQUADRAMENTO DO TRABALHO 5 1.3 Enquadramento do Trabalho O trabalho apresentado nesta dissertação foi desenvolvido no âmbito do Grupo de Engenharia de Software de Lisboa do INESC 2. A actividade de investigação do grupo centra-se em torno de: Ambientes multi-utilizador orientados a objectos: desenvolvimento de aplicações distribuídas com separação de facetas; padrões de desenho; modelação de papeis. Recolha e análise de métricas para sistemas orientados a objectos: estimação de fiabilidade e facilidade de manutenção, avaliação da modularidade e outros aspectos arquitecturais, bem como o refinamento de um conjunto de métricas, denominado MOOD (Metrics for Object Oriented Design), vocacionadas para este paradigma. Gestão de projectos de software em larga escala: sistemas de gestão de configurações, metodologias de verificação e validação, modelização do processo de desenvolvimento de software, comparação de modelos de estimação de recursos, avaliação da maturidade e certificação do processo de desenvolvimento de software. Sistemas legados: engenharia inversa de modelos de dados; análise da complexidade de sistemas legados; utilização de tecnologia de web para a integração de actividades de recolha de dados acerca do processo de software e de métricas de produto, sistemas de rastreio de acções de evolução e desenvolvimento de modelos de análise de impacto de acções de evolução. O protocolo de cooperação estabelecido entre o INESC e a DAMAG 3 para a criação de mecanismos de auxílio à gestão do processo de software desta última constituiu o contexto para o ensaio da ferramenta e métodos de controlo quantitativo da evolução de sistemas apresentados ao longo da dissertação num ambiente não académico. 2 INstituto de Engenharia de Sistemas e Computadores 3 Direcção de Análise e Métodos de Apoio à Gestão da Marinha Portuguesa

6 CAPÍTULO 1. INTRODUÇÃO 1.4 Estrutura da Dissertação Além do presente capítulo, a dissertação é composta pelas seguintes partes: O Capítulo 2 fornece uma panorâmica sobre o trabalho desenvolvido actualmente no âmbito da melhoria do processo de software. Descrevem-se as origens da actividade de gestão da qualidade de software, bem como a sua transposição para o contexto da engenharia de software. São também abordados os aspectos essenciais relacionados com a melhoria do processo de software, com particular relevo para a recolha e análise de dados de suporte a essa actividade. Apresenta-se ainda algum trabalho relacionado com o desenvolvido no âmbito desta dissertação quer ao nível das ferramentas utilizadas, quer ao nível das abordagens quantitativas para um maior controlo da evolução de sistemas de software. O Capítulo 3 detalha o problema do controlo da evolução de sistemas de software, instanciado no caso de estudo que, ao longo de toda a dissertação, servirá de âncora para a discussão sobre os vários aspectos envolvidos no controlo do processo de desenvolvimento e manutenção de software numa organização. Este capítulo apresenta ainda a abordagem proposta nesta dissertação para o rastreio da evolução do software e respectivo processo, dentro de uma organização. É introduzida a arquitectura do sistema SofTrack, um sistema de rastreio da evolução de sistemas de software. O Capítulo 4 descreve os aspectos relacionados com a implementação do SofTrack, nomeadamente os processos de recolha de dados, sua análise e posterior disponibilização através da intranet da organização. Ao longo deste capítulo, é dado especial ênfase às tecnologias usadas na construção deste suporte computacional à actividade de evolução de software já existente. No capítulo 5 são analisados os dados recolhidos no âmbito do caso prático usado nesta dissertação. Não sendo, necessariamente, uma recolha exaustiva de toda a informação recolhida com o SofTrack (tal seria impossível no espaço

1.4. ESTRUTURA DA DISSERTAÇÃO 7 temporal de uma dissertação de Mestrado), pretende-se antes a ilustração de variadas técnicas de apoio à monitorização da evolução de sistemas, diagnóstico de eventuais problemas e estabelecimento de heurísticas para a avaliação da qualidade do software desenvolvido. Sendo certo que os valores concretos são específicos à organização em consideração, no caso prático apresentado, os aspectos fundamentais da abordagem são independentes da mesma. No capítulo 6 são apresentadas as conclusões da dissertação, perspectivando-se as orientações para trabalho futuro que resultam de novas oportunidades abertas pela elaboração desta tese. No apêndice A, apresentam-se alguns dos principais modelos de avaliação da maturidade do processo de software, por forma a fornecer algum enquadramento adicional às actividades descritas no presente documento, uma vez que o objectivo destas é precisamente o aumento da maturidade do processo de desenvolvimento. No apêndice B, descrevem-se as métricas de complexidade do software utilizadas nesta dissertação. No apêndice C, apresenta-se um exemplo de registo de acção de evolução completo que serviu de base para o rastreio realizado à evolução de sistemas, nesta dissertação.

8 CAPÍTULO 1. INTRODUÇÃO

2 Fundamentos e Trabalho Relacionado 2.1 Introdução A expressão crise do software acompanha as organizações produtoras de software há mais de três décadas, sendo sinónima de incapacidade para a sua produção com qualidade dentro do prazo e orçamento previstos. Em rigor, esta expressão talvez não seja completamente ajustada. Não o é, claramente, se o horizonte temporal a considerar consistir nas tais três décadas. A palavra crise deveria denotar um momento perigoso e decisivo para a indústria produtora de software. No entanto, os problemas representados por esta expressão são recorrentes, pelo que se poderia falar mais facilmente de dificuldades crónicas no desenvolvimento e manutenção de software, do que propriamente numa crise. A comunidade académica tem desenvolvido esforços no sentido de criar novas abordagens que permitam ultrapassar estas dificuldades crónicas. Por sua vez, a comunidade industrial sofre crescentes pressões, quer de carácter competitivo, quer resultantes da evolução tecnológica, para se adaptar rapidamente a novas formas de desempenhar a sua actividade. Na prática, este aparente casamento de interesses não tem sido tão profícuo como seria desejável, apesar dos progressos conseguidos, sobretudo durante a última década. As responsabilidades do fosso que infelizmente ainda existe entre as duas comunidades devem ser repartidas de parte a parte: a comunidade académica tem sentido algumas dificuldades na tarefa de validação dos benefícios oferecidos pelos avanços tecnológicos que vai propondo, criando assim alguma desconfiança na comunidade industrial; 9