Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Marco Aurélio Vilaça de Melo

Transcrição

1 Requisitos de Ferramentas de Apoio aos Processos de Medição de Software Marco Aurélio Vilaça de Melo Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG Brasil Resumo. Para produzir de maneira eficaz em um ambiente dinâmico, uma empresa de desenvolvimento de software deve continuamente coletar, analisar e usar medidas para dar suporte a vários decisões gerenciais [INSIGHT 2002]. Qualquer sucesso no processo de medição depende de automatizar o máximo possível a atividade de medição [CUTTER IT JOURNAL 2003]. Este documento apresenta um catálogo com os principais requisitos para se obter um bom método ou ferramenta de apoio aos processos de medição de software. 1. Introdução O avanço da tecnologia e o aumento na demanda de desenvolvimento vêm fazendo com que haja um aumento no tamanho e complexidade dos softwares. E esse aumento tem como efeito colateral uma maior possibilidade na ocorrência defeitos durante o desenvolvimento [Gomes 2001]. Para tentar minimizar o número de defeitos no desenvolvimento de software surgiram diversas técnicas para padronizar o seu desenvolvimento e por conseqüência melhorar a qualidade dos produtos. Para alcançar níveis cada vez mais altos de qualidade, torna-se necessário melhorar o ciclo de vida do software e, para tornar isto possível, dados quantitativos que descrevam a realidade do processo precisam ser obtidos e devidamente analisados [GOMES 2001]. A medição de software auxilia no monitoramento do processo de desenvolvimento de software, proporcionando uma avaliação contínua desse processo possibilitando alterações caso seja identificado algum desvio [FRANÇA 1998]. Diante deste quadro, onde cada vez mais as informações históricas de projetos influenciam na melhoria de processo de desenvolvimento das empresas, aumenta a necessidade de ferramentas e métodos que auxiliam na obtenção, manutenção e análise destes dados. A medição de software gera uma quantidade grande de informação, 1

2 que só poderá ser manipulada eficazmente através de uma ferramenta automatizada [FRANÇA 1998]. Um fato que demonstra que a qualidade dos softwares tem ganhado mais importância no processo de desenvolvimento, é que passou a ser uma área-chave específica do nível 2 do CMMI. Este artigo tem como principal objetivo descrever um catálogo de requisitos para o desenvolvimento de ferramenta ou metodologia de apoio ao processo de medição de software. Podendo auxiliar os desenvolvedores e pesquisadores de ferramentas de medição de software na tarefa de fazer uma ferramenta que cubra uma grande parte dos requisitos necessários para apoiar nas medições de software. Além disso, ela poderá ajudar aos analistas de qualidade e/ou processo na decisão para adoção da ferramenta que mais atenda às necessidades da empresa. Não temos como objetivo enumerar as métricas necessárias para uma boa medição do processo de desenvolvimento de software. Mesmo porque essas métricas podem variar de acordo com a empresa e até mesmo o tipo ou tamanho do projeto. As principais fontes de extração dos requisitos de ferramentas de apoio a medição são artigos de pesquisa que descrevem funcionalidades de ferramentas de medição, artigos que dissertam sobre a qualidade de software e também artigos que avaliam técnicas e metodologia de medição de software. Além disso, foram utilizadas as documentação técnicas de modelos de capacitação, por exemplo, o CMMI para a fundamentação do trabalho. Esse artigo tem como público de interesse os diversos níveis hierárquicos de profissionais das empresas de desenvolvimento de software, pois as métricas obtidas durante essa atividade ajudam na melhoria de desempenho das atividades de quase todos os atores dessa área. O analista de sistemas poderá obter métricas específicas de sua produtividade e com isso estipular metas e controlar o número de defeitos em seu código. A equipe de qualidade é beneficiada diretamente, pois são as métricas coletadas que vão proporcionar uma idéia mais precisa que como está a qualidade do produto desenvolvido. Também se beneficia a equipe de processos, pois diante dos resultados das análises das métricas é possível mensurar o grau de identificação das tarefas realizadas com o processo estabelecido. E com isso identificar possíveis falhas no processo, possibilitando uma mudança pontual desses procedimentos. Os gerentes de projetos também se beneficiarão, pois eles terão acesso a informações do estado do projeto e poderão fazer uma projeção de atrasos e riscos que o projeto corre diante do estado atual. 2

3 2. Modelos e Características das Ferramentas de Apoio aos Processos de Medição de Software Como dito, o processo de medição de software desperta um grande interesse, nas diversas áreas da engenharia de software, e por isso, existem várias pesquisas sobre métodos e ferramentas que apóiem a coleta, manutenção e análise das informações coletadas. A seguir apresentamos algumas das técnicas que tentam auxiliar nessas tarefas: - TABA: é um meta-ambiente capaz de gerar, a partir da definição de um processo, ambientes de desenvolvimento de software (ADS) adequados às particularidades de projetos específicos [GOMES 2001]. - Goal-Question-Metric (GQM): é uma técnica criada na década de 80 para avaliação de defeito dos projetos desenvolvidos pela NASA, embora tenha sido usado originalmente para definir e avaliar objetivos para um determinado projeto em um ambiente específico, seu uso foi expandido. Tem como objetivo criar passos para uma evolução gradual da qualidade no desenvolvimento de software [BASILI 2004]. - Practical Software Measurement (PSM): é um projeto patrocinado pelo Departamento de Defesa e pelo exército norte-americanos, que tem como objetivo estabelecer um conjunto de práticas, ferramentas e serviços para auxiliar os gerentes de projetos a obter informações objetivas sobre os projetos em andamento, para que estes atinjam suas metas de prazo, custo e qualidade [BORGES 2004]. Existem também várias ferramentas baseadas ou não nas técnicas acima, que tem como principal objetivo automatizar o gerenciamento de métricas: - PSM-Insight: é uma ferramenta baseada no processo PSM que permite um alto nível de flexibilidade no gerenciamento de dados, incluindo modificação, consulta e capacidade sofisticada de gráficos [LUCERO 2001]. - Gemetrics: é uma ferramenta CASE auxiliar no gerenciamento de projeto e métrica. Ela integra recursos para o planejamento, gerenciamento de projeto e de métricas de software, gerando gráficos e relatórios fornecendo dados para decisões de projeto [vavassori 2001]. 3

4 - Hackystat: é uma ferramenta de medição de engenharia de software que tem como principal objetivo fornecer um processo útil e um produto de coleta de medidas e facilidades nas análises sem adicionar atrasos em sua atividade diária [JOHNSON 2004]. - ImPProS: é uma ferramenta para a melhoria de processos baseada nas fases do modelo IDEAL, que ajuda na organização gradual do processo de implementação de software [OLIVEIRA 2006]. Tem como principais objetivos especificar um meta-modelo de processo de software, apoiar na definição de um processo de software, permitir a avaliação de critérios desse processo, e ajudar na melhoria contínua do processo [OLIVEIRA 2005]. - PSEE-Metrics: é uma ferramenta que provê suporte ao planejamento e execução de programas de mensuração em processos de desenvolvimento de softwares, utiliza alguma práticas do PSM, tendo seus componentes organizados em três camadas: interação com o usuário, mecanismos de gerência de processos e repositórios [Garcia Júnior 2006]. 3. Requisitos Diante dos métodos e ferramentas estudados foram identificados requisitos que são importantes no apoio aos processos de medição de software, esses requisitos podem ser classificados da seguinte forma: 3.1- Apoio na definição de medidas O método/ferramenta deve auxiliar na identificação de quais métricas devem ser coletadas e armazenadas durante o processo de desenvolvimento de software [FRANCA 1998]. O que deve ser medido é uma informação importante na medição de software, a metodologia que propõe padronizar essa medição deve auxiliar a equipe de processos a definir quais são as medidas que devem ser coletadas durante o processo de desenvolvimento de software. Isto é necessário para a evitar o armazenamento de grande quantidade de informação desnecessária, causando grande confusão na análise dos dados. 4

5 3.2- Apoio na definição do processo de medição O método/ferramenta deve garantir a confiabilidade das informações coletadas. Para isto, ela deve auxiliar na definição de responsabilidades da coleta, garantindo que caso haja algum problema, seja possível identificar o responsável. [CUTTER IT JOURNAL 2002] Compartilhamento das medidas O método/ferramenta deve permitir que os dados coletados possam ser compartilhados, auxiliando em diferentes aspectos das medições, mas estes dados devem ser coletados/armazenados apenas uma vez e compartilhados para todas as visões necessárias. Os dados armazenados devem estar disponíveis também para serem compartilhados entre projetos, isto se justifica devido à necessidade de ter uma comparação de medidas entre os projetos [VAVASSORI 2001] Base de dados das medições O método/ferramenta deve prover uma forma de cadastro de medidas que proporciona uma recuperação fácil das informações e tenha uma flexibilidade para que permitam que os usuários produzam suas próprias consultas. Este requisito leva à necessidade que as medidas sejam armazenadas em um banco de dados [CARD 1998]. 3.5 Flexibilidade dos sistemas de medições O método/ferramenta deve ter um sistema de medição flexível e facilmente adaptável às características da organização. Este requisito possui dois contextos, o primeiro a flexibilidade de especificar novos requisitos específicos de cada projeto, isto é necessário para permitir que cada projeto tenha uma singularidade. No outro ponto, deve possuir a flexibilidade na escala das medidas, para conseguir unificar as diversas escalas que a mesma medida pode possuir, permitindo assim uma comparação real entre os vários projetos [FRANCA 1998] Apoio à coleta de dados O método/ferramenta deve possuir uma forma automatizada de coletar as métricas, este forma deve interferir o mínimo possível no trabalho dos profissionais que geram estas métricas [INSIGHT 2002]. Se possível ela deve fazer parte do próprio processo de desenvolvimento ou integrar com outras ferramentas já utilizadas pelos profissionais, extraindo automaticamente os dados necessários 5

6 [GOMES 2001]. Isto é importante para minimizar o custo desta coleta de dados, que em alguns casos, devido à sua dificuldade, pode até incentivar os profissionais a não realizarem essa coleta Apoio na análise das medidas coletadas O método/ferramenta deve apoiar o usuário no entendimento das medidas coletadas, fazendo análises estatísticas e se possível predizendo resultados, de acordo com tendência das medições atuais, estas informações são importantes por que darão suporte para melhoraria do processo de desenvolvimento de software e também para melhoria de qualidade [GARCIA JÚNIOR 2007] Geração dinâmica de dados derivados O método/ferramenta deve gerar dados derivados das métricas coletadas durante o desenvolvimento de software. Este requisito se justifica pela grande volume de informação gerado pelo armazenamento das medidas, não contribuindo para o aumento desse volume e também pela necessidade de derivar informações gerenciais das medidas armazenadas [CUTTER IT JOURNAL 2003] Visualizador de gráficos e tabelas O método/ferramenta deve ter um visualizador de tabelas e gráficos padronizados. Isto se justifica devido à facilidade de entendimento das informações disponíveis no uso desses recursos. Dando ênfase nas informações gerenciais do projeto, pois o objetivo da ferramenta é dar uma visão global, aos gerentes, do estado do projeto, além de servir como base para avaliação da qualidade do software [INSIGHT 2002] Personalização de gráficos e tabelas Além de possui um visualizador de dados em formato de tabelas e gráficos o método/ferramenta deve também disponibilizar um gerador de gráficos/tabelas sob medida das necessidades do usuário. A sua necessidade é constatada à medida que vemos que em cada empresa ou até mesmo entre projetos surgem necessidades visualização específicas [LUCERO 2001] Garantia de cumprimento O método/ferramenta deve possuir uma forma de garantir que determinada métrica foi preenchida. Isto se justifica devido à 6

7 necessidade garantir que todos as métricas e passos necessários para a completeza do processo foram cumpridos [GOMES 2001] Criação de limites e alarmes O método/ferramenta deve permitir a configuração de limites das métricas. Isso se justifica devido à necessidade de alertar os usuários quando certos limites são atingidos. Podendo assim, tomar providências para correção dessa métrica [JOHNSON 2004] Usabilidade O método/ferramenta deve ser de fácil uso, ou seja, deve conter conceitos de usabilidade. Isto se deve para que o usuário se concentre apenas nas atividades de controle e gerenciamento das métricas, não perdendo tempo na operação da ferramenta [INSIGHT 2002]. 4. Conclusão Como visto, a coleta de medidas dos projetos é uma importante ferramenta para que se possa aprimorar os processos de desenvolvimento e também para avaliar o progresso de determinado projeto. Mas apenas coletar informações sobre os projetos não é suficiente para que se garanta um bom aproveitamento desses dados. Uma técnica e/ou ferramenta que facilite e garanta o uso das medidas obtidas durante o desenvolvimento de projetos é de grande importância para uma instituição controle e melhore seus procedimentos. Para isto, é essencial que tal ferramenta possua requisitos básicos que ajudem nesse processo de coletar, armazenar e analisar tais medidas. 7

8

9 Referências Lucero, S. e Moris, D. (2001) PSM Insight: Power and Flexibility for Issue-Driven Measurement, em: 26th Annual NASA Goddard Software Engineering Workshop. Gomes, A., Mafra, S., Oliveira, K. e Rocha, A. (2001) Avaliação de Processos de Software na Estação Taba, em: XV Simpósio Brasileiro de Engenharia de Software. ISO 9001:2000, Quality Management Systems Requirements, ISO, Basili, V. R., Caldiera, G. e Rombach, H. D. The Goal Question Metric Approach. Borges, E. e Paula Filho, W. P., Um modelo de medição para processos de desenvolvimento de software, em: V SIMPROS - Simpósio Internacional de Melhoria de Processos de Software. Vavassori, F. B. Metodologia para o Gerenciamento Distribuído de Projetos e Métrica de Software f. Tese (Doutorado) - UFSC, Florianópolis. Johnson, P. M., Kou, H., Agustin, J. M., Zhang, Q., Kagawa, A. e Yamashita, T. (2004) Practical Automated Process and Product Metric Collection and Analysis in a Classroom Setting: Lessons Learned from Hackystat-UH, em: International Symposium on Empirical Software Engineering (ISESE 04). Card, D. N. e Jones, C. L. Status Report: Practical Software Measurement, em: Third International Conference On Quality Software, Vavassori, F. B., Souza, Everton Wilson e Fiamoncini, J. C. Ferramenta Case para Gerenciamento de Projetos e Métricas de Software, em: XV Simpósio Brasileiro de Engenharia de Software. SWEBOK Sofware Engineering Body of Knowledge, IEEE, Acessado em 15/10/2007. CMMI - Capability Maturity Model Integration. Acessado em 13/11/2007. Insight - Tailoring and Implementing an Organizational Measurement Process. The Army s Software Metrics Newsletter Spring Volume 6, Número 1. Implementing a Successful Measurement. Cutter IT Jounal. Novembro 2003, página

10 Oliveira, Sandro Ronaldo Bezerra e Vasconcelos, Alexandre Marcos de. A Continuous Improvement Model in ImPPros, Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06). Volume 02, páginas Washington, DC, USA. Franca, Luiz Paulo Alves, Staa, Arndt von e Lucena Carlos José Pereira. Medição de Software para Pequenas Empresas: Uma Solução Baseada na Web, ftp://ftp.inf.pucrio.br/pub/docs/techreports/98_32_franca.pdf. Acessado em 01/12/2007. Garcia Júnior, Paulo Roberto e Nunes Daltro José. APSEE-Metrics: um modelo para mensuração em processos de software. INFOCOMP Journal of Computer Science, volume 6, número 3, página 67-74,