Gerenciamento de Requisitos comoAlternativa de Otimização na Manutenção      de Softwares já Implantados:           Um Est...
Sumário-   Introdução-   Referencial teórico-   Estudo de Caso-   Melhorias Propostas-   Avaliação das Melhorias-   Consid...
Introdução     Motivação   Falta de documentação dos requisitos;   Documentações inadequadas;   Instabilidade dos requi...
Introdução Objetivo GeralRealizar uma engenharia reversa paraidentificar e mapear as dependências dosrequisitos de um soft...
Introdução     Objetivos Específicos   Compreender os métodos atuais de gerenciamento de    requisitos de software;   Co...
Introdução     Objetivos Específicos   Criar uma matriz de rastreabilidade, a fim de mapear as    dependências entre os r...
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 (S...
Referencial Teórico     Qualidade de Software   A qualidade de software é a capacidade de um sistema,    componente ou pr...
Referencial Teórico     Engenharia de Requisitos   Processo que abrange todas as atividades necessárias    para criar e m...
Referencial Teórico     Engenharia Reversa   A partir do sistema existente, a partir da análise do    código-fonte, inter...
Estudo de Caso     Unidade de análise   Empresa de TI;   Software de mercado em constante manutenção;   Equipe de manut...
Estudo de Caso    Coleta de dados   Observação       junto a atendentes do suporte, visando identificar divergências    ...
Estudo de Caso        Análise dos dados históricos                                                                        ...
Estudo de Caso     Análise dos dados   Os dados foram analisados conforme o seu conteúdo;   O critério de comparação foi...
Estudo de Caso            Problemas identificados#                            Resumo dos Problemas                        ...
Melhorias PropostasEquipe de Manutenção
Melhorias PropostasEquipe de Desenvolvimento
Melhorias Propostas               Rastreabilidade de RequisitosManutenção da Matriz                    Validação do Mapeam...
Melhorias Propostas    Ferramenta de apoio   Foi utilizado o IBM Rational RequisitePro® 7.1 para    realizar o gerenciame...
Avaliação das Melhorias     Preparação    Para colocar em prática as melhorias propostas, foram    necessárias as seguinte...
Avaliação das Melhorias     Acompanhamento    Metodologia similar ao da pesquisa e levantamento de    informações   Obser...
Avaliação das Melhorias     Observação   Melhoria da qualidade de software, reduzindo a    quantidade de divergências rep...
Avaliação das Melhorias     Entrevistas   Redução da insegurança para realização das implementações,    pois era possível...
Avaliação das Melhorias         Dados Históricos        Levantamento considerando dois trimestre de trabalho         (mai...
Avaliação das Melhorias         Dados Históricos           Tipo de Tarefa           Horas TrabalhadasAnálise e Projeto    ...
Avaliação das Melhorias         Resultados    Etapa do Processo de                                                      Q1...
Avaliação das Melhorias    Resultados   Aumento de 14,77% no tempo na realização dos    trabalhos de Análise de Negócio e...
Considerações Finais     Limitações   Dificuldade para realizar o mapeamento dos requisitos;   Grande esforço necessário...
Considerações Finais    Oportunidades   Inclusão de uma etapa para a descrição funcional do    antigo requisito que fora ...
Considerações Finais     Trabalhos Futuros   Complementar a documentação dos requisitos do software da    empresa;   Imp...
Considerações Finais     Conclusões   Identificação e formalização dos      processos   de    manutenção de software da E...
Referências Bibliográficas   IEEE, Institute of Electrical and Electronics Engineers: Software Engineering, IEEE    Stand...
Gerenciamento de Requisitos comoAlternativa de Otimização na Manutenção      de Softwares já Implantados:           Um Est...
Upcoming SlideShare
Loading in …5
×

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

1,063 views

Published on

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

2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total views
1,063
On SlideShare
0
From Embeds
0
Number of Embeds
36
Actions
Shares
0
Downloads
16
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Gerenciamento de Requisitos comoAlternativa de Otimização na Manutenção de Softwares já Implantados: Um Estudo de Caso Marcelo Schumacher
  2. 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. 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. 4. Introdução Objetivo GeralRealizar uma engenharia reversa paraidentificar e mapear as dependências dosrequisitos de um software já implantandoe em constante manutenção.
  5. 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. 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. 7. Referencial Teórico Processo de Software Qualidade de Software Engenharia de Requisitos Engenharia Reversa
  8. 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. 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. 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. 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. 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. 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. 14. Estudo de Caso Análise dos dados históricos Horas Quantidad Tipo de Tarefa Tipo de Tarefa Trabalhadas eCustomização - Projeto 32 Análise e Projeto 333,43Não Conformidade, BUG 219 Cenário de Teste 17,75Sugestão/Melhoria 48 Construção/Manutenção 1683,05Tarefa Interna 20 Homolog. Análise 6IPP (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. 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. 16. Estudo de Caso Problemas identificados# Resumo dos Problemas Grau de Impacto1 Dificuldade em verificar áreas do software afetadas por manutenções Alto2 Excesso de divergências liberadas para o mercado Alto Elevado índice de retrabalho, reportado pela equipe de testes para a3 equipe de desenvolvimento Alto4 Falta de documentação que descreva as funcionalidades do sistema Alto5 Falta de análise de impacto no processo de manutenção Médio6 Não identificação formal dos requisitos do software Médio Falta de compartilhamento formal de conhecimento dos profissionais mais7 experientes para os demais profissionais Médio Falta de conhecimento da equipe de manutenção sobre todo o contexto8 do software Baixo
  17. 17. Melhorias PropostasEquipe de Manutenção
  18. 18. Melhorias PropostasEquipe de Desenvolvimento
  19. 19. Melhorias Propostas Rastreabilidade de RequisitosManutenção da Matriz Validação do Mapeamento
  20. 20. Melhorias Propostas Ferramenta de apoio Foi utilizado o IBM Rational RequisitePro® 7.1 para realizar o gerenciamento dos requisitos
  21. 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. 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. 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. 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. 25. Avaliação das Melhorias Dados Históricos Levantamento considerando dois trimestre de trabalho (mai. a out/nov 2009); Tipo de Tarefa Horas TrabalhadasAnálise e Projeto 102,38Definição Requisitos 81,77Homolog. Análise 6Homolog. Requisitos 3Construção/Manutenção 649,61Cenário de Teste 15,75Testes 508,84Reconstrução 465,02 Total 1832,37 Tarefas de Manutenção por Tipo de Atividade / Q1 / Processo Anterior
  26. 26. Avaliação das Melhorias Dados Históricos Tipo de Tarefa Horas TrabalhadasAnálise e Projeto 87,92Definição Requisitos 104,83Homolog. Análise 11,92Homolog. Requisitos 17Construção/Manutenção 821,65Cenário de Teste 12,33Testes 485,98Reconstrução 197,73 Total 1739,36 Tarefas de Manutenção por Tipo de Atividade / Q2 / Novo Processo
  27. 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. 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. 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. 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. 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. 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. 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. 34. Gerenciamento de Requisitos comoAlternativa de Otimização na Manutenção de Softwares já Implantados: Um Estudo de Caso OBRIGADO Marcelo Schumacher

×