Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de Softwares já Implantados: Um Estudo de Caso

1. Gerenciamento de Requisitos como
Alternativa de Otimização na Manutenção
de Softwares já Implantados:
Um Estudo de Caso
Marcelo Schumacher

2. Sumário
- Introdução
- Referencial teórico
- Estudo de Caso
- Melhorias Propostas
- Avaliação das Melhorias
- Considerações Finais
- Referências Bibliográficas

3. 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.

4. 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.

5. 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;

6. 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.

7. Referencial Teórico
 Processo de Software
 Qualidade de Software
 Engenharia de Requisitos
 Engenharia Reversa

8. 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.

9. 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;

10. 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);

11. 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).

12. 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

13. 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);

14. Estudo de Caso
Análise dos dados históricos
Horas
Quantidad Tipo de Tarefa
Tipo de Tarefa Trabalhadas
e
Customização - Projeto 32 Análise e Projeto 333,43
Não Conformidade, BUG 219 Cenário de Teste 17,75
Sugestão/Melhoria 48 Construção/Manutenção 1683,05
Tarefa Interna 20 Homolog. Análise 6
IPP (Novas Funcionalidades) 3 Homolog. Requisitos 2,5
Total 322 Reconstrução 527,45
Definição Requisitos 272,35
Testes 531,02
Total 3393,77

15. 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;

16. 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
Elevado índice de retrabalho, reportado pela equipe de testes para a
3 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
Falta de compartilhamento formal de conhecimento dos profissionais mais
7 experientes para os demais profissionais Médio
Falta de conhecimento da equipe de manutenção sobre todo o contexto
8 do software Baixo

17. Melhorias Propostas
Equipe de Manutenção

18. Melhorias Propostas
Equipe de Desenvolvimento

19. Melhorias Propostas
Rastreabilidade de Requisitos
Manutenção da Matriz Validação do Mapeamento

20. Melhorias Propostas
Ferramenta de apoio
 Foi utilizado o IBM Rational RequisitePro® 7.1 para
realizar o gerenciamento dos requisitos

21. 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;

22. 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);

23. 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;

24. 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;

25. 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

26. 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

27. Avaliação das Melhorias
Resultados
Etapa do Processo de Q1 Q2
Tipo de Tarefa
Manutenção Horas % Horas %
Análise e Projeto 102,38 5,59% 87,92 5,05%
Definição Requisitos 81,77 4,46% 104,83 6,03%
Análise de Negócio e Sistemas
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%
Cenário de Teste 15,75 0,86% 12,33 0,71%
Testes
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;

28. 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.

29. 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;

30. 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.

31. 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.

32. 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;

33. 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.

34. Gerenciamento de Requisitos como
Alternativa de Otimização na Manutenção
de Softwares já Implantados:
Um Estudo de Caso
OBRIGADO
Marcelo Schumacher