Mapeamento dos processos de desenvolvimento ágeis em relação ao Modelo de Melhoria do

1. Universidade Estadual de Feira de Santana Departamento de Tecnologia Curso de Engenharia de Computação Mapeamento dos processos de desenvolvimento ágeis em relação ao Modelo de Melhoria do Processo de Software do Brasil (Mps.Br) nível G Discente: Claudio Ari Bergossi Santos Orientador: Prof. Ms. José Amancio Macedo Santos

2. Roteiro Introdução Processos e Modelos de Qualidade (Motivação) Cenário Nacional de Empresas de Software Problemática Objetivos Metodologia Fundamentação Teórica Mapeamento Análise do Mapeamento Conclusões Referências

3. Introdução

4. Introdução • Surgimento e Evolução da Engenharia de Software: • Década de 50; • Década de 60; • Década de 70; • Década de 80; • Década de 90; • Manifesto Ágil (2001).

5. Introdução • Surgimento dos modelos de Qualidade de Software: • Capability Maturity Model (CMM) : • Intituto de Engenharia de Software (SEI) • Anos 90; • Capability Maturity ModelIntegration(CMMI). • Melhoria de Processos do Software Brasileiro (MPS.BR); • Dezembro de 2003; • Associação para Promoção da Excelência do Software Brasileiro (SOFTEX); • Baseado no CMMI e nas normas ISO/IEC 12207 e ISO/IEC 15504 (SOFTWARE; SINGH, 1989)

6. Processos Ágeis e Modelos de Qualidade de Software (Motivação)

7. Processos Ágeis e Modelos de Qualidade de Software (Motivação) • Mercado competitivo. • Dependência da utilização de softwares por todos os setores. • Mercado não comporta mais a falta de qualidade; • Busca por qualidade e sucesso em projetos de software.

8. Processos Ágeis e Modelos de Qualidade de Software (Motivação) • Processos Ágeis: • Resultados visíveis a curto prazo; • Suporta mudanças com naturalidade; • Presença do cliente em todo o processo; • Produto final com qualidade para o cliente.

9. Processos Ágeis e Modelos de Qualidade de Software (Motivação) • Modelos de Qualidade: • Organização do Processo de desenvolvimento; • Melhoria da qualidade de produtos e serviços; • Comprovação da qualidade do Processo de desenvolvimento; • Avaliações periódicas visando a garantia de qualidade; • Pontuação em Licitações públicas.

10. Cenário Nacional de Empresas de Software

11. Cenário Nacional de Empresas de Software As Empresas do Setor de Software e Serviços – 2008 • Fonte: (SOFTWARE, 2009)

12. Cenário Nacional de Empresas de Software • Crescimento do número de empresas de desenvolvimento de Software: • Segundo a Associação Brasileira de Empresas de Software (ABES) (2008): • Aumento de 15,5% de 2004 à 2008 (SOFTWARE, 2009).

13. Cenário Nacional de Empresas de Software • Total de organizações com Avaliação MPS (vigentes ou não): • Fonte: (SOFTEX, 2009)

14. Problemática

15. Problemática • Poucas empresas com selo de certificação do MPS.BR; • Dificuldades na produção de software com qualidade; • MPS.BR (o que fazer) X Metodologias Ágeis (como fazer); • É possível relacionar estes dois temas?

16. Problemática • Trabalhos relacionados: • Mapeamento do (MPS.BR) para empresas que utilizam Extreme Programming como metodologia de desenvolvimento (SANTANA;TIMÓTEO;VASCONCELOS, 2006) • Mapeamento do Feature Driven Development(FDD) em relação ao MPS.BR níveis G e F (CAMARGO, 2007) • Mapeamento do Feature Driven Development(FDD) em relação ao MPS.BR níveis G e F (LAURINDO, 2007)

17. Objetivos

18. Objetivos Gerais • Mapear os processos de desenvolvimento ágeis em relação ao Modelo de Melhoria do Processo de Software do Brasil no seu nível G.

19. Objetivos Específicos • Mapear as Práticas do Scrum em relação ao nível G do Mps.Br; • Mapear as Práticas do Extreme Program(XP) em relação ao nível G do Mps.Br; • Mapear as Práticas do Feature Driven Development (FDD) em relação ao nível G do Mps.Br;

20. Objetivos Específicos • Descrever o como essas três metodologias ágeis atendem ou não os requisitos propostos pelo nível G do MPS.BR; • Apresentar os resultados do mapeamento de forma sintetizada.

21. Metodologia

22. Metodologia • Levantamento bibliográfico: • Metodologias Ágeis: • Extreme Programing (XP); • Scrum; • Feature Driven Development (FDD). • Modelos de Qualidade de Software: • MPS.BR; • CMMI. • Trabalhos relacionados.

23. Metodologia • Definição de Critérios para a classificação das metodologias ágeis em relação aos requisitos propostos pelo do MPS.BR; • Tabela de Critérios para a classificação Fonte: (MARCAL; SOARES; BELCHIOR, 2007)

24. Metodologia • Definição de um formato para o mapeamento: • [Título do requisito] • [Descrição resumida dos • resultados esperados, obtidos • através do Guia de Implementação • do modelo de referência] • (XP): [Análise das práticas do XP em relação aos resultados esperados;] • (Scrum):[Análise das práticas do Scrum em relação aos resultados esperados;] • (FDD):[Análise das práticas do FDD em relação aos resultados esperados.]

25. Metodologia • Realização do mapeamento das metodologias ágeis em relação aos requisitos do nível G do MPS.BR; • Realização da análise dos resultados do mapeamento;

26. Fundamentação Teórica

27. Fundamentação Teórica • Manifesto Ágil: • Histórico (HIGHSMITH, 2001); • Valores: • Indivíduos e interação entre eles mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudanças mais que seguir um plano.

28. Fundamentação Teórica (XP) • Extreme Programing (XP): • Foco da Metodologia (implementação); • Valores; • Comunicação; • Simplicidade; • Coragem; • Feedback; • Respeito.

29. Fundamentação Teórica (XP) • Extreme Programing (XP): • As 12 práticas (BECK, 1999); • Versões pequenas; • Jogo do planejamento; • Design simples; • Programação em pares; • Testes; • Refatoração; • Integração contínua; • Propriedade coletiva do código; • Ritmo sustentável; • Cliente Presente; • Metáfora; • Padrões de Código.

30. Fundamentação Teórica (Scrum) • Scrum: • Foco da Metodologia (Gerenciamento do Projeto); • Artefatos do Scrum (SCHWABER; BEEDLE, 2001); • Product Backlog; • Selected Backlog; • Sprint Backlog; • Impediment Backlog; • Burndown Chart.

31. Fundamentação Teórica (Scrum) • Scrum: • Ciclo de Vida do Scrum: Fonte: (ALLIANCE, 2009)

32. Fundamentação Teórica (FDD) • Feature Driven Development (FDD). • FocodaMetodologia (modelagem e implementação); • As 8 práticas do FDD (PALMER; FELSING, 2002); • Modelagem de domínio de objetos; • Desenvolvimento por funcionalidade; • Propriedade de Classe; • Equipes por funcionalidades; • Inspeções; • Versões regulares; • Gerenciamento de Configurações; • Relatórios de progresso.

33. Fundamentação Teórica (FDD) • Feature Driven Development (FDD). • Ciclo de vida do FDD: Fonte: (HEPTAGON, 1997)

34. Fundamentação Teórica (MPS.BR) • Modelo de Qualidade Mps.Br: • Adequado ao CMMI; • Níveis de Maturidade de G-A; • Apoio: • Ministério da Ciência e Tecnologia; • Financiadora de Estudos e Projetos; • Serviço Brasileiro de Apoio às Micro e Pequenas Empresas; • Banco Interamericano de Desenvolvimento.

35. Fundamentação Teórica (MPS.BR) • Estrutura do MPS.BR Fonte: (SOFTEX, 2009)

36. Fundamentação Teórica (MPS.BR) • O Nível G do Mps.Br: • Gerência de Projetos (GPR): • 17 requisitos. • Gerência de Requisitos (GRE): • 5 Requisitos.

37. Fundamentação Teórica (MPS.BR) • Equivalência entre MPS.BR e CMMI: Fonte: (SOFTEX, 2009)

38. Mapeamento

39. Mapeamento • Foi realizado o mapeamento dos 22 requisitos pertencentes ao nível G do MPS.BR; • Foram criadas tabelas a partir dos resultados do mapeamento;

40. Mapeamento • GPR1 - O escopo do trabalho para o projeto é definido. • Segundo o guia de implementação do Nível G do MR-MPS (Modelo de Referência do Mps.Br): • [...] O escopo do projeto define todo o trabalho necessário, e somente ele, para entregar um produto que satisfaça as necessidades, características e funções especificadas para o projeto, de forma a concluí-lo com sucesso. [...] Este resultado também pode ser implementado por meio de um Documento de Visão ou outro documento que defina, claramente, o escopo do trabalho (SOFTEX MR-MPS, 2009, p.9) .

41. Mapeamento • XP: • - O XP não define o escopo de todo o projeto no inicio. O escopo do projeto é dividido através das releases (BECK, 1999), que são construídas no Jogo do Planejamento, contendo funcionalidades prioritárias para o cliente. Desta forma o XP atende parcialmente este requisito.

42. Mapeamento • Scrum: • - Para atender este requisito o Scrum utiliza o productbacklog, onde este possui uma lista com todos os requisitos que o sistema deve apresentar, representando o escopo do projeto. Desta forma este requisito é atendido pelo Scrum.

43. Mapeamento • FDD: • - A definição do escopo no FDD ocorre através de duas etapas Desenvolver o modelo abrangente, onde posteriormente este modelo é decomposto em funcionalidades através da prática: “Construir a lista de funcionalidades”. Desta forma o FDD contempla este requisito.

44. Mapeamento • GPR8- As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados. • Segundo o guia de implementação do Nível G do MR-MPS (Modelo de Referência do Mps.Br): • [...]Todos os recursos precisam ser explicitamente planejados, mesmo os já considerados como existentes e disponíveis ou que serão compartilhados com outros projetos, uma vez que se trata da sua alocação para uso. Estes itens podem, por exemplo, estar registrados no plano do projeto. Caso não haja necessidade de nenhum recurso a ser adquirido para o projeto deve-se registrar o fato de que a questão foi examinada (SOFTEXMR-MPS, 2009, p.13).

45. Mapeamento • XP: • - O planejamento formal de recurso não está no escopo do XP. • - No Jogo do Planejamento são abordadas as tarefas a serem implementadas na release e os recursos necessários para implementá-las, caso seja necessário. É de responsabilidade do coach organizar o ambiente de trabalho na fase de exploração (BECK; FOWLER, 2000), mas não há registro deste planejamento. Desta forma o XP atende parcialmente este requisito.

46. Mapeamento • Scrum: • -A preparação da infra-estrutura do projeto é realizada no início do projeto durante a fase de Staging (MARCAL; SOARES; BELCHIOR, 2007). Ao Product Backlog são adicionados os recursos necessários ao desenvolvimento, tais como: máquinas, ferramentas e demais investimentos necessários para a configuração do ambiente de desenvolvimento. Sendo assim o Scrum satisfaz este requisito.

47. Mapeamento • FDD: • -O planejamento de recursos e ambiente de trabalho no FDD, são responsabilidades do Gerente de Projeto (ABRAHAMSSON et al., 2002, p.53), fornecendo condições de trabalho adequadas para a equipe. Mas não há evidências sobre o registro deste planejamento. Portanto o FDD atende parcialmente este requisito.

48. Mapeamento • Tabela obtida após o mapeamento:

49. Análise do Mapeamento

50. Análise do Mapeamento • Gráficos obtidos através das tabelas resultantes do mapeamento do Processo GPR: