Qualidade do Processo de Manutenção de Software

Transcrição

1 Qualidade do Processo de Manutenção de Software CLAUDIA CAPPELLI¹ MARCOS R. S. BORGES² RENATA ARAUJO 3α 1 PROCESS IMPROVEMENT TECHNOLOGY Rua Cambaúba 1145 / Ilha do Governador, Rio de Janeiro, RJ, , Brasil cappelli@ism.com.br ² NCE & IM / UFRJ Caixa Postal 2324 Rio de Janeiro, RJ, , Brasil mborges@nce.ufrj.br 3 Escola de Informática Aplicada UNIRIO Av. Pasteur 458, Térreo, Urca Rio de Janeiro, RJ, , Brasil renata.araujo@uniriotec.br Resumo A Engenharia de Software tem avançado muito na definição de modelos de qualidade para melhoria do processo de desenvolvimento de software, visando obter software totalmente aderente aos requisitos do usuário e com menor nível de defeitos. Isso se torna possível na medida que estes modelos procuram garantir a qualidade dos produtos de software gerados ao longo do processo de desenvolvimento. Levando-se em conta que a Manutenção do Software também pode ser considerada como parte do processo de desenvolvimento, esses modelos deveriam ter continuidade de utilização qualquer que fosse a modificação realizada no software, de forma a se garantir a não deterioração da qualidade atestada ao mesmo durante seu desenvolvimento. O que ocorre no entanto é que a maioria dos modelos propõe processos bastante formais que podem não se justificar para determinados tipos de manutenções. O presente trabalho descreve uma proposta de adaptação de um modelo para garantia da continuidade da qualidade de software durante toda sua vida útil, assim como o desenvolvimento de uma ferramenta (TRACE) para auxílio neste processo. PALAVRAS-CHAVE: padrões, processo, manutenção, adaptação de processo, CMM. α também professora colaboradora do Programa de Mestrado NCE & IM/UFRJ

2 Qualidade do Processo de Manutenção de Software 1 Introdução Atualmente, a área de Engenharia de Software tem parte de sua atenção voltada para a definição de modelos para melhoria da qualidade na construção de software. Hoje já são utilizados largamente, de forma prática, modelos que buscam melhoria da qualidade de software [1][2][3][5][4]. Estes modelos, em sua maioria, atribuem a qualidade do software ao processo como ele foi construído e aos produtos gerados. Entretanto, a qualidade alcançada ao término do processo de desenvolvimento não garante necessariamente que a mesma irá se perpetuar durante toda a vida útil deste software. Ou seja, utilizar um modelo de qualidade para desenvolvimento de projetos não é garantia para uma manutenção de software com qualidade. Os produtos de software gerados durante o desenvolvimento de um projeto e que poderão sofrer algum tipo de alteração após a implantação do mesmo, necessitam de processos que garantam sua qualidade durante o ciclo de manutenção. O problema que vamos focar neste artigo é a deterioração da qualidade do software a partir do momento em que este é implantado e passa a sofrer manutenções. Se as manutenções que o software for sofrendo ao longo de sua existência não forem realizadas utilizando-se também algum modelo de qualidade, esta irá se deteriorar rapidamente. Por outro lado, utilizar o mesmo modelo de qualidade para o desenvolvimento de projetos pode tornar o processo inviável por ser, em muitos casos, principalmente para manutenções pequenas e emergenciais, mais custoso e demorado que a própria manutenção. Este artigo apresenta uma proposta para a adaptação de um modelo de qualidade de software para a manutenção de sistemas tanto corretivas, adaptativas e perfectivas, mas, cuja característica principal seja seu caráter de pequeno porte de alteração e a urgência de sua realização. O modelo que nos baseamos nesta proposta é o modelo CMM [5], dada sua demanda por utilização nas organizações de software. Tal adaptação do CMM compreende a revisão dos processos, padrões e procedimentos deste modelo para apoiar efetivamente e com menos custos as manutenções mencionadas. A proposta apresentada neste artigo compreende também a definição de uma ferramenta de suporte à atividade de manutenção baseada no modelo adaptado. O artigo está dividido em seis partes. A segunda seção apresenta definições de manutenção de software. A terceira seção apresenta a manutenção no modelo de maturidade de software CMM. A quarta seção trata da adaptação das práticas do modelo CMM, através da adaptação de procedimentos e padrões utilizados para projetos e determinados tipos de manutenção - pequenas manutenções e manutenções emergenciais. A quinta seção apresenta os objetivos da construção de uma ferramenta para apoio ao processo de manutenção, seus pré-requisitos, escopo, sua arquitetura e seus requisitos funcionais. Finalmente, a sexta seção apresenta as conclusões do trabalho.

3 2 Manutenção de Software Após a implantação, grande parte dos sistemas sofre alterações ao longo do período em que estão sendo utilizados. Seus requisitos originais são modificados para refletir algum tipo de mudança nas necessidades do usuário, mudança de ambiente, introdução de novo hardware ou software, correção de erros e outros. Este processo de mudança do software após sua implementação é chamado de Manutenção de Software [6]. A literatura classifica a manutenção de software basicamente em quatro categorias: preventiva, adaptativa, corretiva e perfectiva [6]. A manutenção preventiva, por se tratar de uma modificação do software para melhorias em sua confiabilidade, manutenibilidade, ou para oferecimento de uma base melhor para futuras ampliações, pode ser desenvolvida como um projeto e consequentemente usar na íntegra a aplicação de um modelo de qualidade utilizado para desenvolvimento de novos projetos. Para as demais categorias (corretiva, adaptativa e perfectiva), não fica tão clara a aplicação direta de um mesmo modelo utilizado para o desenvolvimento de software. Os fatores que irão decidir a forma como iremos utilizar um modelo de qualidade para manutenção de software, são o que chamaremos de características ou sub-classificações, que se referem basicamente ao tamanho da manutenção e o prazo de entrega da mesma: o Prazo de entrega: Agendável: Manutenção necessária, porém para a qual não existe uma data final pré-determinada, ou seja, a mesma pode ser planejada sem que previamente já se tenha uma data para o término da mesma; Emergencial: Manutenção para a qual tem-se uma data final prédeterminada, mesmo antes de ser feito um levantamento inicial do escopo da mesma; o Tamanho: Grande / Média: Manutenção que envolve mais do que 40 HH (homens hora) de esforço para sua realização; Pequena: Manutenção que envolve menos do que 40 HH (homens hora) de esforço para sua realização. Estas 4 (quatro) classificações podem ser combinadas, onde manutenções agendáveis podem ser grandes/médias ou pequenas, bem como manutenções emergenciais também podem ser de grande/médio porte ou pequenas.

4 1.1. Dificuldades da Manutenção Podemos dizer que a manutenção do software é um processo de mudança para garantir a sobrevivência do mesmo. No entanto, segundo Schneidewind [7], o processo de manutenção é bastante árduo devido a 3 fatores: a) Não existem formas ainda eficazes de acompanhar os produtos gerados e o processo de geração dos mesmos na manutenção de software. Os modelos disponíveis para garantia da qualidade de software são bastante completos, porém muito focados no desenvolvimento de novos projetos; b) Dependendo de como o software foi construído, a realização de mudanças em geral desencadeia um efeito dominó sobre o qual tem-se muita dificuldade de previsão. Isso se deve ao fato de não se ter uma ferramenta apropriada para identificação de conseqüências que uma manutenção poderá acarretar. Este efeito é citado também por Rajlich [10], o qual propõe um modelo que permite identificar a propagação da mudança; c) Em geral a manutenção é apresentada na Engenharia de Software como um processo iniciado imediatamente após a implantação do software. Isso não seria um problema, não fosse o pouco ou nenhum envolvimento das equipes de manutenção durante o processo de desenvolvimento do software. Uma visão diferente é dada por Cousin e Collofello [8]. Eles acreditam que as equipes de manutenção poderiam resolver melhor todos os problemas de manutenção de software se dispusessem de documentação atualizada, treinamento contínuo e ferramentas automatizadas. Uma combinação destes três itens poderia ser o melhor caminho para a continuidade da qualidade do software. Focando mais diretamente a documentação do software, muitos esforços tem sido feitos na tentativa de melhorar o processo de documentação de software. No estudo de Garland [11] é discutido um método para se incorporar informações sobre a solução de problemas numa base de dados que contém todo o acompanhamento da manutenção do software. Muitas das questões citadas nos levam a identificar que a falta de modelos de qualidade definidos especificamente para a manutenção de software ou adaptados para a mesma, e a carência de ferramentas que permitam a implementação destes modelos, podem vir a deteriorar a qualidade do software ao longo do processo de manutenção. 3 A Manutenção de Software no modelo CMM O modelo de maturidade e capacitação em software CMM (Capability Maturity Model), assim como tantos outros modelos desenvolvidos ao longo do final dos anos 80, propõe mudanças culturais na organização referente ao trabalho de desenvolvimento de software nas empresas. Ele tem como principal objetivo a padronização e a documentação através da definição de procedimentos do processo de desenvolvimento de software, assim como a melhoria de qualidade. O modelo vem sendo implantado em várias empresas ao longo dos últimos anos ao redor do

5 mundo e tem sido também utilizado como parte do processo de globalização das mesmas. O modelo CMM é composto de cinco níveis de maturidade que determinam qual a capacitação do processo. Com exceção do nível 1, cada nível é composto por várias Áreas Chave de Processo (KPAs). Uma visão das áreas-chave de processo sugeridas para cada nível de maturidade é apresentada na Figura 1. Processo continuamente aprimorado Otimizado 5 Prevenção de defeitos Gerência de mudanças tecnológicas Gerência de mudanças no processo Processo disciplinado Inicial 1 Processo consistente, padrão Repetitível 2 Processo previsível Definido 3 Gerenciado 4 Gerência de requisitos Planejamento de Projetos Acompanhamento de projetos Gerência de subcontratos Garantia de qualidade Gerência de configuração Foco no processo Definição do processo Programa de treinamento Administração de software integrada Engenharia de produto Coordenação entre grupos Gerência quantitativa de p rocessos Gerência da qualidade de software Figura 1 Áreas-Chave de Processo por nível de maturidade CMM Cada área conduz a metas de melhoria do processo para um determinado nível. A definição de cada Área Chave está organizada em cinco seções chamadas de Características Comuns. As Características Comuns, por sua vez contém as Práticas Chave, que por sua vez determinam as atividades necessárias para a melhoria de uma Área Chave do Processo. A Figura 2 mostra um esquema detalhado desta estrutura. Para as manutenções agendáveis de porte grande / médio, podemos aplicar por completo as práticas sugeridas pelo modelo CMM utilizads para desenvolvimento independentemente de serem corretivas, adaptativas ou perfectivas. Como se tratam de manutenções agendáveis e de grande ou médio porte, podemos seguir os mesmos passos utilizados para o desenvolvimento de novos projetos. Os fatores que permitem isso se deve ao fato de serem agendáveis, ou seja, não terem uma data pré-definida para término e de necessitarem de mais de 40 HH para sua elaboração, permitindo então o seguimento de todos os processos previstos para atendimento de um modelo de qualidade e documentação formal. Para as manutenções pequenas agendáveis e para as emergenciais, não importando se são corretivas, adaptativas ou perfectivas, já não podemos dizer o mesmo. A pequenas agendáveis não justificariam um processo tão completo quanto os definidos para desenvolvimento de projetos. Na maioria das vezes o simples seguimento do processo formal de desenvolvimento poderia ser mais extenso do que a execução da manutenção em si. Para as emergenciais normalmente o

6 requisito principal é o prazo (já possui uma data de término pré definida para a mesma), o que implica num cronograma com data fim já pré-estabelecida e sendo assim, devido a premência de tempo, faz-se o que é necessário (vai-se direto para a fase de construção do software) e depois documenta-se (em alguns casos) o que foi feito e não o processo de desenvolvimento da manutenção. Processo Capacitação indica Objetivos Nível de Maturidade contém Área Chave Processo alcança Implementação ou Institucionalização abordam Infraestrutura ou Atividades organizado por Características Comuns contém Práticas Chaves descrevem Figura 2 - Estrutura do modelo CMM Algumas práticas definidas pelo CMM não são de tão fácil aplicação nas manutenções emergenciais e de pequeno porte principalmente pela premência de tempo e pela inviabilidade do custo, ou seja, para serem aplicadas necessitam de adaptação ou redução de escopo. O problema está no tratamento a ser dado aos requisitos e as necessidades do gerenciamento. Deve haver um processo de adaptação para cada uma das práticas, se necessário. As áreas chaves do processo devem ser interpretadas de acordo com os princípios das práticas de manutenção de software. Neste processo é importante verificar que o escopo da manutenção é limitado a correções e melhorias, o que é bastante diferente da criação de novos softwares [9]. 4 Adaptação do Modelo CMM para manutenções emergenciais e de pequeno porte

7 De acordo com o que foi discutido em seções anteriores, temos dois casos basicamente para os quais deveríamos adaptar a utilização do modelo CMM. São eles: Manutenções de Pequeno Porte e Manutenções Emergenciais. Para estes tipos de manutenção precisamos de processos mais ágeis. Para tal mostramos abaixo as atividades definidas em cada Área Chave do modelo que poderiam ser aplicadas ou não nestes tipos de manutenções de forma diferente do que num projeto ou outro tipo de manutenção. Tais adaptações foram devidamente analisadas e não impactam na perda de qualidade do produto. Nível 2 Área Chave: Gerência de Requisitos Finalidade: Estabelecer e manter um acordo com o usuário com relação aos requisitos a serem observados no software a fim de se ter um entendimento comum entre as partes envolvidas. Esta gerência controla a evolução dos requisitos de um sistema. Atividade Revisar requisitos alocados antes de incorporá-los ao projeto de software Utilizar requisitos alocados como base para o desenvolvimento do software Revisar alterações nos requisitos alocados e incorporá-los ao projeto de software Aplicável Prática (S/N) S - Identificar requisitos imcompletos ou ausentes - Verificar se os requisitos são apropriados, possíveis e consistentes - Negociar os compromissos resultantes da implementação destes requisitos - Analisar impacto de inclusão alteração do requisito S - Os requisitos devem ser a base para a manutenção - Os requisitos devem ser a base para o modelo de dados - Os requisitos devem estar integrados aos já existentes N - Como estamos tratando de manutenções emergenciais e de pequeno porte, os requisitos costumam ser definidos uma primeira vez e como o tempo é premissa básica para implementação ou sua complexidade é muito pequena em geral não há alterações nos requisitos ao longo de sua implementação, não sendo portanto necessário um processo de revisão no caso de alteração dos mesmos.

8 Área Chave: Planejamento do Projeto de Software Finalidade: Estabelecer planos exeqüíveis para desenvolver um determinado software, bem como para gerenciar o projeto de software segundo estes planos. Atividade Estimar o tamanho dos produtos de Software Estimar o esforço e custo do projeto de software Estimar recursos computacionais críticos Estabelecer o cronograma de software do projeto Identificar os produtos de software Aplicável Prática (S/N) S - Realizar estimativa para os principais produtos a serem criados/alterados assim como para as atividades a serem realizadas. No caso de manutenções emergenciais identificar para cada produtos quais serão contemplados antes e quais serão contemplados após a realização da manutenção. S - Baseado no tamanho estimado, derivar o esforço necessário e o custo da manutenção. S - No caso da manutenção envolver aquisição ou alteração de recursos computacionais, estimar o custo dos mesmos. S - Identificar a data de realização da manutenção e o prazo para execução da mesma. No caso das manutenções emergenciais a data de término já é pré-definida S - Os produtos de software que deverão ser mantidos atualizados para as manutenções emergenciais e de pequeno porte são os requisitos, modelos de dados, código e testes. Todas as demais atividades previstas nesta Área Chave dizem respeito à elaboração do plano do projeto, participar da proposição do projeto, iniciar planejamento, documentar o plano e gerenciar dados de planejamento que não se aplicam às manutenções emergenciais e de pequeno porte. Área Chave: Supervisão e Acompanhamento do Projeto de Software Finalidade: Fornecer uma visão realista do progresso do projeto de software, permitindo que a gerência tome ações eficazes quando o projeto desviar-se de forma significativa dos planos de software. Como esta área chave é apoiada na premissa da existência de um plano para o desenvolvimento do software, nos tipos de manutenção abordados neste trabalho, sua prática não será necessária. Nestes tipos de manutenção em geral não é feito

9 um acompanhamento do progresso da mesma devido as suas próprias características de tempo de execução. Área Chave: Garantia de Qualidade de Software Finalidade: Fornecer à gerência a visibilidade da eficácia do processo que está sendo utilizado para o desenvolvimento do software e da qualidade dos produtos que estão sendo gerados. No caso das práticas previstas por esta área, a proposta é que as mesmas sejam realizadas por amostragem e não necessariamente durante a execução da manutenção emergencial ou de pequeno porte. As revisões e auditorias poderiam ser realizadas para um grupo de manutenções de forma a documentar desvios e recomendar melhorias caso necessário. A visibilidade destas manutenções poderia ser dada em grupo ao invés de caso a caso. Área Chave: Gerência de Configuração de Software Finalidade: Estabelecer e manter a integridade dos produtos de software ao longo do ciclo de vida do software. As práticas previstas por esta área são gerais para toda a instalação. Não se aplicando diretamente a um tipo específico de manutenção ou projeto. Os itens que devem ser colocados sob gerência de configuração já devem estar definidos para o processo de manutenção como um todo e serão os mesmos para manutenções emergenciais e de pequeno porte. Deve haver uma área encarregada de manter o repositório de baselines, controlar a liberação de produtos para manutenção, gerar relatórios de problemas entre outras atividades. Quanto à geração de planos para gerência de configuração e registros dos itens que ficarão sob gerência de configuração, estas só se justificariam no caso de projetos ou manutenções maiores. Área Chave: Gerência de Contrato de Software Finalidade: Selecionar contratadas de software qualificadas e gerenciá-las efetivamente. Esta área chave em geral não se aplica diretamente para manutenções emergenciais e de pequeno porte pelas próprias características das mesmas. Não é prática nas organizações que vá se desenvolver um contrato para a realização de uma manutenção emergencial ou de pequeno porte. Em geral estas são realizadas nas próprias instalações da empresa ou nas instalações da empresa responsável pela manutenção do software, não sendo necessária a elaboração e gerência de um contrato específico para as mesmas. Nível 3 Área Chave: Foco no Processo da Organização Finalidade: Estabelecer a responsabilidade organizacional para as atividades do processo de software que melhoram a capacitação de processo de software da organização. Esta área chave é responsável pela criação de um grupo de processo de engenharia de software que por sua vez é o encarregado de coordenar, desenvolver e manter os processos de software da organização. Como suas metas estão voltadas para

10 esta coordenação e planejamento de atividades de melhoria e para a identificação de pontos de melhoria no processo de software, não há aqui nenhuma prática específica para o processo de manutenção de software. Área Chave: Definição do Processo da Organização Finalidade: Desenvolver e manter um conjunto de ativos de processo de software que sejam úteis e melhorem o desempenho dos processos utilizados nos diversos projetos. Esta área chave é responsável pela criação do processo padrão da organização de onde são derivados os processos de software definidos do projeto que por sua vez derivam no plano do projeto. Como suas atividades estão voltadas para o desenvolvimento e manutenção do processo de software padrão e para a coleta e disponibilização de informações a respeito do uso do processo de software padrão da organização, nenhuma de suas práticas é específica para a manutenção de software. Área Chave: Gerência de Software Integrada Finalidade: Integrar as atividades de engenharia e gerência de software em um processo de software coerente e bem definido, e que é adaptado a partir do processo de software padrão da organização. Esta área chave implementa a forma de se gerar o processo de software definido do projeto a partir do processo de software padrão da organização. Sendo assim tem como maioria de suas atividades itens já relacionados na área chave de planejamento de projetos, apenas agregando a elas o fato de estarem baseadas num processo padrão e como derivá-las deste processo. O único item que tem relevância para manutenções emergenciais e de pequeno porte é o mesmo citado na área chave de planejamento de projetos, ou seja, estimativa. Nesta área chave, é agregada à estimativa o fato de utilizar dados contidos em bancos de dados da organização, ou seja, dados reais sobre outros projetos ou manutenções já realizadas. Esta atividade também é recomendada para as manutenções contidas no escopo deste trabalho. Área Chave: Engenharia de Produtos de Software Finalidade: Executar de forma consistente um processo de engenharia bem definido que integra todas as atividades de engenharia de software, para conduzir, de maneira eficaz e eficiente, produtos de software corretos e consistentes. Atividade Integrar instrumentos de engenharia de software ao processo de software definido do projeto Implementar os requisitos de software Implementar o projeto do software Aplicável Prática (S/N) N - Esta atividade é definida para o processo de desenvolvimento e manutenção como um todo. S - Idem ao que foi definido na Área Chave de Gerência de Requisitos (Nível 2) S - Aderir aos padrões de projeto - Aderir aos padrões de interfaces

11 e bases de dados - Integrar-se na arquitetura do software - Afetar o projeto com todos os requisitos solicitados - Atualizar documentação que demonstre os padrões de dados e relacionamentos da aplicação. Controlar o código S - Identificar que módulos estarão sendo alterados para garantir a implementação dos requisitos solicitados - Garantir que o código contenha todos os requisitos incluídos e alterados - Identificar bases de dados afetadas - Utilizar os mesmos métodos e padrões utilizados pelo desenvolvimento - Integrar novo código ao já existente Implementar testes de software S - Identificar testes por módulo alterado - Ter definido para cada teste os dados envolvidos e o resultado esperado. Planejar e executar testes de integração Planejar e executar testes de sistema e aceitação Implementar documentação de software Coletar e analisar dados de defeitos Manter consistência do conjunto de produtos de software S - Testar os componentes do software afetados pela manutenção S - Identificar testes para verificação de requisitos - Apresentar ao usuário os testes executados para aceitação destes. S - Documentar requisitos alterados / incluídos - Atualizar documentação dos módulos - Atualizar documentação de dados - Atualizar documentação de testes N - Esta atividade deve ser realizada na organização como um processo geral para a manutenção e desenvolvimento. S - Garantir a coerência entre requisitos, dados, código e

12 testes. Área Chave: Coordenação entre Grupos Finalidade: Estabelecer mecanismos para o grupo de engenharia de software participar ativamente junto aos outros grupos de engenharia de maneira que o projeto satisfaça as necessidades dos clientes. Esta área chave envolve a interação do grupo de engenharia de software com outros grupos de engenharia e procura resolver através de alguns procedimentos as questões técnicas e as dependências críticas entre estes grupos. No caso de manutenções emergenciais e de pequeno porte não há necessariamente um procedimento específico para a coordenação entre grupos caso isso se faça necessário. O procedimento que estiver definido para qualquer outro tipo de manutenção também pode ser aqui utilizado dado que qualquer negociação antecederá a execução da mesma. Área Chave: Revisão por Pares Finalidade: Remover de forma eficiente os defeitos de software ainda nos estágios iniciais de sua criação e como conseqüência identificar melhorias para estes produtos. Esta área chave estabelece a prática de revisões de software do tipo Walkthrough e Inspeções. No caso das manutenções emergenciais e de pequeno porte, o que recomendamos é que sejam feitos grupos para realização das atividades previstas por esta área por amostragem. Todo software que sofrer alteração emergencial ou de pequeno porte deverá poder ser identificado e posteriormente verificado, identificando-se se a manutenção foi realizada dentro dos padrões de qualidade estabelecidos para a organização. Não haveria portanto nenhuma prática específica para estes tipos de manutenção a não ser o fato de serem realizadas por amostragem e posteriormente a sua implantação. Área Chave: Programa de Treinamento Finalidade: Desenvolver as habilidades e os conhecimentos das pessoas da organização, de maneira que venham a desempenhar efetiva e eficientemente seus papéis. Esta área chave define a existência de um Programa de Treinamento para toda a Área de desenvolvimento e manutenção de software de forma a capacitar seus profissionais. Portanto não há nenhuma prática específica a ser praticada de forma diferenciada para profissionais que realizem manutenções emergenciais ou de pequeno porte. O mesmo treinamento deve ser dado para qualquer profissional que atue em manutenção de software Benefícios Esperados

13 A utilização das práticas do CMM para controle do processo de manutenções pequenas e emergenciais pode trazer grandes benefícios para a organização. A aplicação de um modelo na manutenção de software poderá trazer como resultado métricas que poderão ajudar na melhoria contínua do processo e consequentemente na redução de custo e risco da manutenção de software. O principal resultado esperado na viabilidade de adoção de algumas atividades de um modelo de qualidade para a manutenção de software, poderia proporcionar: Atualização contínua da documentação dos produtos de software que sofrem algum tipo de alteração após sua implantação; Geração de medições sobre o processo de manutenção de software; Atualização da base de conhecimento da organização sobre seus produtos de software; Suporte do trabalho das equipes de manutenção de software; Redução de risco; Aumento do controle sobre as manutenções que estão sendo realizadas no software; Redução do prazo de entrega; Aprimoramento das estimativas por se ter produtos com documentação atualizada. 5 A Ferramenta TRACE Em geral, o processo tradicional de desenvolvimento e manutenção de software define que a documentação do software deve ser feita através de manuais que expliquem seu funcionamento e operação. A documentação dos processos e produtos de software que foram produzidos durante a concepção do mesmo, ficam muito mais por definição do responsável pelo projeto de desenvolvimento ou manutenção. A documentação sobre o funcionamento e operação do software tem uma conotação mais forte do que as demais, por se tratar de produtos que terão utilização imediata após sua entrada em funcionamento, ou seja, são necessário à sua implantação. A documentação dos processos utilizados para a criação do software e os produtos gerados ao longo desta criação, só passarão a ser utilizados após a implantação do mesmo no caso deste ser alterado. Ou seja, esta documentação não é vital para a implementação do software. Um outro grande problema encontrado é que em geral esta documentação, apesar de poderem seguirem determinados padrões e procedimentos documentados para sua elaboração, os quais são definidos pelo CMM, não seguem necessariamente uma forma estruturada de utilização destes padrões e não obrigatoriamente são utilizadas ferramentas para este fim. Esta forma de documentação não estruturada, apesar de armazenar processos e produtos que documentam o desenvolvimento do software, não são capazes de permitir a utilização destes dados, e mais, não permitem que se possa transformar estes dados em informações úteis para o próprio processo de desenvolvimento e manutenção. O que se precisa para se manter qualidade no software é justamente o maios número de informações sobre o mesmo de forma fácil e simples de acesso. A

14 necessidade de conhecimento sobre os software existentes numa organização é fundamental para se garantir uma redução nos riscos de processamento dos mesmos e um aumento de produtividade no processo de desenvolvimento e manutenção. Atentado para estes e outros problemas, podemos dizer que para o processo de documentação de software ser viável é necessário que o mesmo seja feito de forma automatizada. Isso eqüivale a dizer que deve haver uma ferramenta de software que auxilie neste processo de forma a viabilizá-lo. Voltando agora as atenções para a manutenção de software, podemos dizer, que um dos fatores primordiais para se manter a qualidade do mesmo, é a existência de uma ferramenta na qual seja permitido o cadastramento de todos os produtos de software que são modificados durante toda a vida útil do software (Requisitos, Design, Código e Testes), os quais são gerados ao longo do desenvolvimento do software ou de manutenções no mesmo. O uso efetivo das adaptações às práticas do CMM nas pequenas manutenções e manutenções emergenciais exige a existência de uma ferramenta para suporte e consequente aumento de produtividade deste processo. Neste sentido, foi especificada uma ferramenta TRACE cujo objetivo principal é permitir a atualização constante dos produtos de software em manutenção, facilitando e agilizando o trabalho, tornando viável a documentação com qualidade de qualquer tipo de manutenção. 5.1 Principais Funcionalidades A ferramenta TRACE permite um conjunto de funcionalidades próprias do modelo proposto, desde o armazenamento de requisitos, módulos, casos de teste, estruturas de dados até a inclusão/manutenção de regras de negócio da empresa (Figura 3) ao acompanhamento de todas as mudanças ocorridas (Figura 4), verificando através de medições, se há aumento na produtividade e melhoria de qualidade. A ferramenta proporciona visibilidade aos diversos grupos de manutenção e as gerências, sobre o que está sendo realizado, de forma a facilitar o processo inter-grupos e o melhor gerenciamento da área. O tipo de informação contida nesta ferramenta pode aumentar a produtividade das equipes de manutenção e facilitar a documentação dos produtos de software alteradois pois permite o conhecimento da lista de requisitos por sistema, do mapa de requisitos X os módulos que os implementam, do mapa de módulos X os testes utilizados pelos mesmos, entre outros. 6 Conclusão Este artigo apresentou a adaptação de um modelo e a adoção de uma ferramenta para melhoria da qualidade no processo de manutenção de software. Este trabalho foi baseado na utilização do modelo de maturidade e capacitação em software CMM. Figura 3 Principais funçoes TRACE e exemplo de cadastramento de módulos

15 Foram identificados diversas atividades neste modelo que poderiam dificultar na utilização completa no processo de manutenção de software, provocando a degradação da qualidade dos software ao longo do processo de manutenção. A aplicação de processos sugeridos pelo CMM também durante o processo de manutenção pode auxiliar a continuidade da qualidade atestada ao software no momento de sua criação. A principal contribuição deste trabalho é a proposta de uma adaptação do CMM para a área de manutenção de software. Esta adaptação tem por objetivo identificar atividades deste modelo que poderiam não ser realizadas no processo de manutenção, tornando o mesmo mais rápido e menos custoso. Algumas necessidades podem ser citadas como fortes argumentos para a adaptação de um modelo de qualidade para a manutenção de software e a instalação de uma ferramenta como a desenvolvida neste trabalho num ambiente de manutenção de software. São eles: Existência de controle sobre o processo de manutenção; Existência de padrões e procedimentos adaptados às necessidades da manutenção; Identificação da abrangência da manutenção; Redução do risco da manutenção;

16 Aumento da produtividade; Melhoria das estimativas de custo e esforço Figura 4 Principais relatórios TRACE Para que se tenha bons resultados com a utilização da adaptação do modelo CMM e com a utilização da ferramenta desenvolvida, é esperado que de certa forma haja uma mudança na forma de trabalho da área de manutenção de software. Todos os envolvidos com manutenção de software precisam utilizar o modelo adotado e a ferramenta, que servirá de auxílio a eles próprios. No caso das manutenções emergenciais, o processo a ser realizado não muda muito o que acontece na maioria das instalações. Devido a premência de tempo, constroe-se o que for necessário e depois documenta-se o que foi feito. O fator prazo continua sendo o mais importante nas manutenções emergenciais. O que muda na realidade são dois fatores. O primeiro é que após a manutenção toda a documentação do que foi realizado poderá ser registrada e segundo, e mais

17 importante, é a utilização da ferramenta para dar apoio ao processo, pois a mesma possui inúmeros recursos que podem auxiliar o desenvolvedor na construção. Mesmo com o prazo bastante exíguo o desenvolvedor pode lançar mão da ferramenta através de suas listas de referências cruzadas (relatórios disponíveis) a fim de identificar que itens estarão sendo afetados na manutenção. A ferramenta TRACE é relativamente genérica e pode ser utilizada no processo de manutenção de software independentemente das técnicas adotadas para o levantamento de requisitos ou definição de testes. A simplicidade de utilização permite que pessoas pouco familiarizadas com modelos de qualidade possam realizar contribuições de maneira bem intuitiva, sem necessidade de treinamento. Por ser uma ferramenta projetada para a web, pode ser facilmente disponibilizada. Permite ainda, por ter arquitetura aberta, integração com outras ferramentas de Engenharia de Software, como para Gerência de Configuração, Gerência de Requisitos, Design etc. Referências [1] K. El Eman, J. Drouin, W. Melo, SPICE The theory and practice of Software Process Improvement and Capability Determination. 1 ed. Los Alamitos, California, IEEE Computer Society Press [2] ISO/IEC a ISO/IEC Information Technology Software Process Assessment, [3] W.S. Humphrey, Characterizing the Software Process Maturity Framework, CMU-SEI-87-TR-11 ESD-TR , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania. [4] ISO-/IEC Information Technology Software Life-Cycle Processes, [5] M.C.Paulk, Capability Maturity Model for Software version 1.1 CMU/SEI-93-TR-24, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, Pennsylvania, [6] R.S. Pressman, Engenharia de Software. MAKRON Books do Brasil Editora Ltda., [7] N.F.Schneidewind, Introduction to the Special Section on Software Maintenance. The State of Software Maintenance. IEEE Transactions on Software Engineering, [8] L. Cousin, J.S. Collofello, A task-based approach to improving the software maintenance process - International Conference on Software Maintenance (ICSM) IEEE Orlando, Flórida Nov., 9-12, [9] D. Drew, Tailoring the software engineering Institute (SEI) Capability Maturity Model (CMM) to a software sustaining engineering organization - International Conference on Software Maintenance (ICSM) IEEE Orlando, Flórida Nov., 9-12, [10] V. Rajlich, R. Sridhar, VIFOR 2: A tool for browsing and documentation - International Conference on Software Maintenance (ICSM) IEEE Monterey, California Nov., 4-8, [11] J. Garland, F. Calliss, Improved change tracking for software maintenance - International Conference on Software Maintenance (ICSM) IEEE Sorrento, Italy Oct., 15-17, 1991.