gerenciamento de requisitos como alternativa de otimização na manutenção de softwares já...

Marcelo Schumacher

Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção

de Softwares já Implantados: Um Estudo de Caso

Sumário

- Introdução

- Referencial teórico

- Estudo de Caso

- Melhorias Propostas

- Avaliação das Melhorias

- Considerações Finais

- Referências Bibliográficas

Introdução Motivação

Falta de documentação dos requisitos;

Documentações inadequadas;

Instabilidade dos requisitos durante o desenvolvimento;

Impactos das evoluções e correções;

Importância do gerenciamento dos requisitos para

garantir melhor qualidade.

Introdução Objetivo Geral

Realizar uma engenharia reversa para identificar e mapear as dependências dos requisitos de um software já implantando e em constante manutenção.

Introdução Objetivos Específicos

Compreender os métodos atuais de gerenciamento de requisitos de software;

Compreender as técnicas disponíveis para engenharia reversa de software;

Identificar os problemas atualmente enfrentados pela equipe da empresa de TI, em função da falta de documentação e da falta de gerenciamento de requisitos;

Identificar os requisitos de um software já desenvolvido e comercializado pela empresa de TI;

Introdução Objetivos Específicos

Criar uma matriz de rastreabilidade, a fim de mapear as dependências entre os requisitos identificados;

Utilizar a matriz de rastreabilidade de requisitos em alguns casos de manutenção;

Avaliar os resultados da utilização da matriz de rastreabilidade como apoio ao processo de manutenção;

Identificar ganhos obtidos e oportunidades de melhoria.

Referencial Teórico

Processo de Software

Qualidade de Software

Engenharia de Requisitos

Engenharia Reversa

Referencial Teórico Processo de Software

Conjunto de atividades e resultados que geram um produto de software (SOMMERVILLE, 2001)

Dentre os processos fundamentais, há quatro atividades comuns:

Especificação: Definição de funcionalidades e as restrições em suas operações;

Desenvolvimento: Construção do software, atendendo às especificações;

Validação: Verificar se o software atende às especificações;

Evolução: Garantir que o software siga uma evolução para correção de defeitos e atendimento às necessidades mutáveis.

Referencial Teórico Qualidade de Software

A qualidade de software é a capacidade de um sistema, componente ou processo satisfazer determinados requisitos, visando atender o usuário com suas necessidades e expectativas (IEEE, 1990);

Qualidade de software abrange tanto o produto quanto o processo de software (KALAIMAGAL, 2008);

Em razão disso foram criados os modelos de qualidade ISO/IEC 9126, ISO/IEC 15504, ISO/IEC 12207, CMM, CMMI e MPS.BR (KALAIMAGAL, 2008);

Cada modelo de qualidade possui conceitos que contribuem para a melhoria do produto e do processo de software;

Referencial Teórico Engenharia de Requisitos

Processo que abrange todas as atividades necessárias para criar e manter a documentação de requisitos de software (SOMMERVILLE, 2001);

O objetivo principal da engenharia de requisitos consiste na definição e descrição do que um software deve realizar para satisfazer as necessidades levantadas (PETERS, 2001).

O gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos do sistema (SOMMERVILLE, 2001);

Referencial Teórico Engenharia Reversa

A partir do sistema existente, a partir da análise do código-fonte, interface e ambiente, são abstraídas suas funcionalidades e são construídos os modelos de análise e projeto do sistema. A realização deste processo é chamada de Engenharia Reversa de Software (PIEKARSKI; QUINÁIA, 2000);

Seu objetivo consiste em auxiliar na compreensão da estrutura interna de sistemas complexos (PRESSMAN, 2001).

Estudo de Caso Unidade de análise

Empresa de TI;

Software de mercado em constante manutenção;

Equipe de manutenção dividida em 3 setores:

Manutenção;

Desenvolvimento;

Testes;

Gestão de tarefas realizada através do software JIRA

Estudo de Caso Coleta de dados

Observação

junto a atendentes do suporte, visando identificar divergências relatadas pelos clientes (jan. a set. 2009)

Entrevistas

com pessoas que mantém relação com o ambiente operacional do software (usuários avançados) e profissionais da manutenção, visando identificar relatos de divergências (nov. 2008 a ago. 2009);

Extração dos dados históricos

registrados na ferramenta para gerenciamento de tarefas, a fim de consolidá-los de maneira analítica, agrupando-as quanto a sua natureza (dez. 2008 a ago. 2009);

Estudo de Caso Análise dos dados históricos

Tipo de Tarefa Quantidad

e

Customização - Projeto 32

Não Conformidade, BUG 219

Sugestão/Melhoria 48

Tarefa Interna 20

IPP (Novas Funcionalidades) 3

Total 322

Tipo de Tarefa Horas

Trabalhadas

Análise e Projeto 333,43

Cenário de Teste 17,75

Construção/Manutenção 1683,05

Homolog. Análise 6

Homolog. Requisitos 2,5

Reconstrução 527,45

Definição Requisitos 272,35

Testes 531,02

Total 3393,77

Estudo de Caso Análise dos dados

Os dados foram analisados conforme o seu conteúdo;

O critério de comparação foi através da simples análise do conteúdo descritivo das tarefas;

Estes dados serviram para justificar e identificar as dificuldades no processo de manutenção, além de auxiliar na identificação de requisitos para construção da matriz de rastreabilidade;

Estudo de Caso Problemas identificados

# Resumo dos Problemas Grau de Impacto

1 Dificuldade em verificar áreas do software afetadas por manutenções Alto

2 Excesso de divergências liberadas para o mercado Alto

3

Elevado índice de retrabalho, reportado pela equipe de testes para a

equipe de desenvolvimento Alto

4 Falta de documentação que descreva as funcionalidades do sistema Alto

5 Falta de análise de impacto no processo de manutenção Médio

6 Não identificação formal dos requisitos do software Médio

7

Falta de compartilhamento formal de conhecimento dos profissionais mais

experientes para os demais profissionais Médio

8

Falta de conhecimento da equipe de manutenção sobre todo o contexto

do software Baixo

Melhorias Propostas

Equipe de Manutenção

Melhorias Propostas

Equipe de Desenvolvimento

Melhorias Propostas

Rastreabilidade de Requisitos

Manutenção da Matriz Validação do Mapeamento

Melhorias Propostas

Ferramenta de apoio

Foi utilizado o IBM Rational RequisitePro® 7.1 para realizar o gerenciamento dos requisitos

Avaliação das Melhorias Preparação

Para colocar em prática as melhorias propostas, foram necessárias as seguintes ações:

Construção a matriz de rastreamento de requisitos do

software usado neste estudo;

Capacitação dos profissionais envolvidos para assimilarem o novo método de trabalho;

Implementação das melhorias, em alguns projetos

piloto, a partir de setembro de 2009;

Avaliação das Melhorias Acompanhamento

Metodologia similar ao da pesquisa e levantamento de informações

Observação foi realizado um acompanhamento dos profissionais

envolvidos a fim de se perceber os resultados das melhorias propostas;

Entrevistas os profissionais envolvidos foram entrevistados para

opinarem sobre as melhorias propostas;

Registros históricos foram consultados registros históricos na ferramenta

de controle de tarefas (set. a nov. 2009);

Avaliação das Melhorias Observação

Melhoria da qualidade de software, reduzindo a quantidade de divergências reportadas pela equipe de Testes;

Menor quantidade de iterações entre analistas e desenvolvedores;

Boa parte das tarefas de desenvolvimento foram concebidas em menos horas do que o previsto;

Os desenvolvedores atuaram, reportando ao analista as necessidades de se relacionar mais requisitos;

Aumento da motivação das pessoas;

Avaliação das Melhorias Entrevistas

Redução da insegurança para realização das implementações, pois era possível anteceder o impacto;

Melhora da qualidade do software, reduzindo a existência de divergência relatadas;

Nenhuma recorrência foi relatada durante o período de estudo (ago. a nov. 2009);

Redução da necessidade de conhecimento do produto, pois praticamente todos os impactos estavam destacados, bastava executar o desenvolvimento;

Aumento de confiança e estima da equipe;

Estima-se por todos uma melhoria na comercialização e na expectativa do cliente, em virtude da melhora da qualidade do produto de software;

Avaliação das Melhorias Dados Históricos

Levantamento considerando dois trimestre de trabalho (mai. a out/nov 2009);

Tipo de Tarefa Horas Trabalhadas

Análise e Projeto 102,38

Definição Requisitos 81,77

Homolog. Análise 6

Homolog. Requisitos 3

Construção/Manutenção 649,61

Cenário de Teste 15,75

Testes 508,84

Reconstrução 465,02

Total 1832,37

Tarefas de Manutenção por Tipo de Atividade / Q1 / Processo Anterior

Avaliação das Melhorias Dados Históricos

Tipo de Tarefa Horas Trabalhadas

Análise e Projeto 87,92

Definição Requisitos 104,83

Homolog. Análise 11,92

Homolog. Requisitos 17

Construção/Manutenção 821,65

Cenário de Teste 12,33

Testes 485,98

Reconstrução 197,73

Total 1739,36

Tarefas de Manutenção por Tipo de Atividade / Q2 / Novo Processo

Avaliação das Melhorias Resultados

Etapa do Processo de

Manutenção Tipo de Tarefa

Q1 Q2

Horas % Horas %

Análise de Negócio e Sistemas

Análise e Projeto 102,38 5,59% 87,92 5,05%

Definição Requisitos 81,77 4,46% 104,83 6,03%

Homolog. Análise 6 0,33% 11,92 0,69%

Homolog. Requisitos 3 0,16% 17 0,98%

Total de Análise de Negócio e Sistemas 193,15 10,54% 221,67 12,74%

Desenvolvimento Construção/Manutenção 649,61 35,45% 821,65 47,24%

Testes Cenário de Teste 15,75 0,86% 12,33 0,71%

Testes 508,84 27,77% 485,98 27,94%

Total de Testes 524,59 28,63% 498,31 28,65%

Reconstrução e Reteste Reconstrução 465,02 25,38% 197,73 11,37%

Total de Horas Todas as Etapas 1832,37 1739,36

267,59 horas a menos para reconstrução; 58,48% de diferença; Esta redução era um dos principais

objetivos do trabalho;

No total geral, mesmo aumentando o fluxo do processo de manutenção, reduzimos 92,64 horas para

atender a um ciclo de manutenções; Redução 5,06% neste total;

Avaliação das Melhorias Resultados

Aumento de 14,77% no tempo na realização dos trabalhos de Análise de Negócio e de Sistemas

Redução de horas, principalmente da etapa de Reconstrução, o que permitiu absorver o tempo necessário para manutenção da matriz de rastreabilidade sem impactar no tempo previsto para desenvolvimento da atividade;

Redução em 5% da etapa de testes;

Cumprimento dos prazos previstos para quase todas as tarefas.

Considerações Finais Limitações

Dificuldade para realizar o mapeamento dos requisitos;

Grande esforço necessário para a engenharia reversa;

Dificuldade de apoio da equipe de desenvolvimento;

Impossibilidade de aplicação das melhorias pela equipe de Manutenção;

Limitação da licença para uso do IBM Requisite Pro;

Limitação da amostra utilizada;

Considerações Finais Oportunidades

Inclusão de uma etapa para a descrição funcional do antigo requisito que fora mapeado em virtude de uma nova manutenção;

Definição de um profissional responsável por fazer a manutenção da matriz de rastreabilidade.

Considerações Finais Trabalhos Futuros

Complementar a documentação dos requisitos do software da empresa;

Implementar o novo processo de manutenção na empresa;

Identificar oportunidades de melhorias na etapa de teste de software;

Padronizar e melhorar as interfaces das aplicações.

Considerações Finais Conclusões

Identificação e formalização dos processos de manutenção de software da Empresa;

Identificação das dificuldades enfrentadas para realização do processo de manutenção de software;

Avaliação da inclusão do gerenciamento dos requisitos no processo de manutenção de software da empresa;

Obtenção de resultados que indicam benefícios do gerenciamento dos requisitos no processo de manutenção de software;

Referências Bibliográficas

IEEE, Institute of Electrical and Electronics Engineers: Software Engineering, IEEE Standard 610.12 – 1990, IEEE, 1993.

KALAIMAGAL, Sivamuni; SRINIVASAN, Rengaramanujam. A Retrospective on Software Component Quality Models. Nova York, v. 33, n. 6, p. 1-9, 2008.

PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.

PIEKARSKI, Ana E. T; QUINÁIA, Marcos A. Reengenharia de Software: o que, por quê e como. Guarapuava: Departamento de Informática – UNICENTRO, 2000.

PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.

OBRIGADO

Marcelo Schumacher

Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção

de Softwares já Implantados: Um Estudo de Caso