CMM Capability Matury Model

Transcrição

1 CMM Capability Matury Model Insucesso das Metodologias de Desenvolvimento de Software: o foco excessivo que estas colocam nas atividades de Engenharia, em detrimento das atividades de Gerenciamento.

2 CMM Capability Matury Model Modelo SEI- CMM (Univ. Carnegie-Mellon) Foco em: Boas técnicas de desenvolvimento não adiantam se o projeto como um todo é mal conduzido + conceitos mais genéricos do Gerenciamento da Qualidade Total = Melhoria na definição de melhores processos de gerenciamento de projetos de software

3 CMM Capability Matury Model O CMM procura orientar a organização a implementar a melhoria contínua do processo de software: Através de um modelo de 5 níveis, priorizado de forma lógica as ações a serem realizadas. Quanto maior o nível, maior a maturidade da organização, o que se traduz em maior qualidade dos produtos final, prazos e custos mais baixos e maior previsibilidade em cronogramas e orçamentos.

4 CMM Capability Matury Model

5 CMM Capability Matury Model No nível 1, chamado de Inicial, o desenvolvimento é caótico (ad hoc). Não existem procedimentos padronizados, estimativas de custos e planos de projeto. Cada qual desenvolve como quer, não existe documentação e Não há mecanismos de controle que permitam ao gerente saber o que está acontecendo, identificar problemas e riscos e agir de acordo. Como conseqüência, os desvios não são corrigidos e ocorrem os problemas como prazos não cumpridos, orçamentos estourados, software sem qualidade e usuários insatisfeitos. Raramente existe um cronograma ou um orçamento. ¾

6 CMM Capability Matury Model Para passar ao nível 2, a organização deve instituir controles básicos de projeto: Gerenciamento de Requisitos e de Projetos (técnicas para planejar e estimar o esforço em projetos, e controlar o progresso) Controle Gerencial (verificação pela Gerência do progresso do projeto em momentos pré-determinados + a qualidade dos produtos) instituição de um Grupo de Garantia de Qualidade instituição de procedimentos básicos de Gerenciamento de Configuração (para garantir que mudanças no projeto e manutenções solicitadas não destruam o que já foi feito, garantindo um mínimo de estabilidade no desenvolvimento).

7 CMM Capability Matury Model Chegando ao nível 2, chamado Repetível: A organização está em condições de ter maior controle sobre seus projetos, e pode-se esperar que as estimativas sejam mais precisas (já que se desenvolve uma base histórica intuitiva) e a qualidade do software produzido seja maior. No entanto, caso a empresa enfrente o desafio de atacar projetos de características distintas das que está acostumada (usando uma nova tecnologia, por exemplo), esta informação será irrelevante, e a empresa poderá regredir ao nível 1.

8 CMM Capability Matury Model Para passar ao nível 3, Definido, é necessário: Introduzir uma Metodologia de Desenvolvimento formal padronizada, com: um ciclo de vida definido + métodos, técnicas e ferramentas apropriadas, como inspeções e técnicas abrangentes de teste. Estabelecer o time encarregado exclusivamente da melhoria contínua do processo de software (time SEPG). Ao chegar a este nível, a empresa terá um fundamento claro para desenvolver sistemas e também para melhorar o próprio processo, especialmente quando surgirem crises.

9 CMM Capability Matury Model No nível 3, entretanto, os controles ainda são basicamente qualitativos, não havendo meios de quantificar a qualidade dos produtos e a eficiência do processo. A empresa deve estabelecer métricas de forma a medir características específicas dos produtos. A forma de coletar, armazenar e analisar estes dados é definida e, com base nesta informação, pode-se sugerir melhorias específicas nos produtos. Neste ponto, a empresa estará no nível 4, ou Gerenciado.

10 CMM Capability Matury Model Para subir do nível 4 o. (Gerenciado) para o 5 o. Nível (Otimização), deve-se: Estabelecer meios para a coleta automática de métricas e para a utilização da informação coletada de forma a prevenir problemas. A idéia é analisar as causas dos problemas e atacá-las para evitar que volvem a ocorrer. Enquanto os dados coletados no nível 4 podem informar, por exemplo, quantos erros existem em um programa, a preocupação no nível 5 é melhorar o processo para evitar que tais erros aconteçam no próximo projeto.

11 CMM Capability Matury Model

12 CMM Visão Geral

13 Gestão de Projetos Resultado de uma pesquisa feita por Gartner Group (2010) sobre os problemas enfrentamos pelas organizações quando não implantam ferramentas para auxiliar na gestão de projetos. Os resultados foram: 51% de todos os projetos extrapolam o orçamento ou ultrapassam o prazo final; 15% dos projetos falham completamente; 94% dos entrevistados reportaram que implementar uma metodologia de gerenciamento de projetos, adicionou valor às suas organizações; Software de gerenciamento: pode reduzir custos de 2 a 5%, melhorar produtividade entre 20 e 25%, e elevar de 10 a 15% a receita para projetos mais estratégicos.

14 "O propósito do Planejamento do Projeto (PP) é estabelecer e manter planos que definam as atividades de projeto. O propósito do Monitoramento e Controle do Projeto (PMC) é proporcionar um entendimento do progresso do projeto, de forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano. O propósito da Gestão de Risco (RSKM) é identificar potenciais problemas antes que ocorram. Para isso, as atividades de tratamento de risco podem ser planejadas e colocadas em prática quando necessário, durante a vida do produto ou do projeto, para mitigar impactos indesejáveis na obtenção dos objetivos." [CMMi para Desenvolvimento, versão 1.2]

15 Gestão de Projetos

16 Gestão de Projetos - Alguns conceitos A gestão efetiva de projetos de software focaliza 4 Ps: (a)pessoal (b)produto de software (c)processo de desenvolvimento de software (d)projeto (project) de software

17 Gestão de Projetos - Alguns conceitos (a) Pessoal Interessados (stakeholders) Gerentes seniores. Definem os aspectos do negócio Gerentes de projeto. Devem planejar, motivar, organizar e controlar os profissionais que fazem o trabalho de software. Profissionais (desenvolvedores). Fornecem aptidões técnicas para fazer a engenharia de um produto ou aplicação. Clientes. Especificam os requisitos para o software submetido à engenharia. Usuários finais. Interagem com o software depois que ele é liberado para uso.

18 Gestão de Projetos - Alguns conceitos Equipe de Software - Modelos (paradigmas) de equipes (de pessoal): Fechado. Estrutura hierárquica rígida Aleatório. Estrutura fraca e dependente da iniciativa individual. É vantajosa em projetos de inovação ou desenvolvimento tecnológico. Aberto. Combina aspectos dos paradigmas fechado e aleatório. Síncrono. Apoiado na compartimentalização natural do problema. Organiza as equipes para trabalhar em partes do problema. Pouca comunicação entre as equipes. Equipes ágeis. Características para um bom desempenho: Os membros da equipe devem confiar uns nos outros A distribuição de aptidões deve ser adequada ao problema Estrelas podem ter que ser excluídas da equipe, se a coesão tiver que ser mantida

19 Gestão de Projetos - Alguns conceitos (b) Produto Descrição do Escopo do software: define os limites do software que será desenvolvido. O escopo do projeto de software não deve ser ambíguo e deve ser inteligível para os níveis gerenciais e técnicos. Contexto. Como o software a ser construído se encaixa no contexto de um sistema maior, do produto ou do negócio? Objetivos da informação. Que objetos de dados visíveis para o cliente são produzidos como saída e quais são necessários para a entrada? Função e desempenho. Que funções o software desempenha para transformar a entrada na saída? Existem características de desempenho que devem ser tratadas? Decomposição do software: é importante para o gerente, que auxilia nas decisões A decomposição do problema (particionamento ou elaboração do problema) é uma atividade que se situa no núcleo da análise dos requisitos. São descompostos: a funcionalidade que precisa ser entregue e o processo que será usado para entregá la.

20 Gestão de Projetos - Alguns conceitos (c) Processo de Desenvolvimento de Software O gerente de projeto deve decidir qual o modelo de processo mais adequado para: o cliente e o pessoal que executará o trabalho as características do produto o ambiente da equipe de projeto Deve ser criado um plano de completo que reflita as tarefas de trabalho necessárias para preencherem as atividades de arcabouço.

21 (d) Gestão de Projetos

22 Gestão de Projetos - Planejamento Planejamento de projeto de software abrange 5 atividades: estimativa de recursos, tempo e custos. cronogramação análise de riscos planejamento de gestão da qualidade planejamento de gestão de modificação Compõem documento Plano de Projeto (aka Plano de Gerenciamento)

23 Gestão de Projetos - Planejamento Tarefas para o planejamento: Estabeleça o escopo do projeto; Determine a viabilidade; Análise riscos: Levantamento Análise: probabilidade, grau, impacto Planos de mitigação Determine os recursos necessários Humanos Softwares reusáveis Ambientais (ambiente de desenvolvimento)

24 Gestão de Projetos - Planejamento Estime custo e esforço Decomponha o problema Desenvolva duas ou mais estimativas usando tamanho FP ou PCU Desenvolva um cronograma Conjunto de tarefas Rede de tarefas Use uma ferramenta para fazer um cronograma Rastreamento

25 Gestão de Projetos - Planejamento Estime os recursos necessários Recursos Humanos Aptidões necessárias (posição na organização e especialidade) Esforço de desenvolvimento (pessoa mês) Recursos de Software Componentes de prateleira Componentes de experiência plena Componentes de experiência parcial Componentes novos

26 Gestão de Projetos - Planejamento Recursos de Ambiente Ambiente de engenharia de software Softwares de desenvolvimento Ferramentas de planejamento Ferramentas de gerenciamento Ferramentas de apoio Ferramentas de análise e projeto (CASE) Ferramentas de programação Ferramentas de testes Ferramentas de manutenção Frameworks

27 Gestão de Projetos - Planejamento Dicas para se fazer uma estimativa 1. adie a estimativa o mais que puder 2. use técnicas de decomposição simples 3. baseie as estimativas em projetos semelhantes 4. use um modelo empírico para estimativa

28 Plano de Projeto Análise de Riscos Um risco é um problema em potencial, que pode ou não ocorrer. Riscos em Engenharia de Software, no futuro de ambiente interno e externo... mercado, tecnologia economia, governo, política econômica e tecnológica, leis e apoio a P&D nos requisitos dos clientes, em ambientes tecnológicos, equipamentos, orçamentos, nas decisões: O que produzir? Com que métodos e ferramentas? Com que equipe? Com que nível de qualidade? Com qual orçamento?

29 Plano de Projeto Na análise de riscos são feitas as seguintes tarefas: Identificar o risco, Avaliar : a probabilidade que ele ocorra, estimar seu impacto, priorizar os riscos mais importantes Estabelecer um plano de contingência para resolver, administrar ou mitigar os riscos mais importantes.

30 Plano de Projeto Tipos de riscos: Riscos de projeto (riscos de que o desenvolvimento não ande de acordo com as espectativas) : identificam problemas orçamentários, de cronograma, de pessoal, de recursos, de clientes e de requisitos. Riscos técnicos (riscos de não conseguir construir uma solução que atenda as necessidades): identificam problemas de projeto, implementação, interface, manutenção, ambigüidade nas especificações, obsolescência, e tecnologia de ponta. Riscos de negócio (riscos de que a solução perca o interesse econômico) Riscos conhecidos: aqueles que podem ser descobertos com uma avaliação cuidadosa do plano de projeto, ambiente, etc. Riscos previsíveis: extrapolados de experiência em projetos anteriores. (rotatividade de pessoal, má comunicação com o cliente, etc.) Riscos imprevisíveis: extremamente difíceis de identificar antecipadamente.

31 Plano de Projeto Checklist de riscos conhecidos e previsíveis: tamanho do produto; impacto do negócio; características do cliente; definição do processo; ambiente de desenvolvimento; tecnologia para a construção; tamanho e experiência da equipe.

32 Plano de Projeto Componentes e fatores de risco: Risco de desempenho. Risco do produto não atender aos requisitos; Risco de custo. Risco do orçamento ser mantido; Risco de suporte. Risco do software não ser fácil de corrigir, adaptar e aperfeiçoar Risco de cronograma: risco de não conseguir cumprir os prazos Impacto dos riscos 1. negligencíavel; 2. marginal, 3. crítico e 4. catastrófico.

33 Plano de Projeto Riscos Categoria Probabilidade Impacto Mitigação A estimativa de tamanho pode ser significativamente baixa Tamanho do produto 60 % 2 Usuários finais resistem ao sistema Impacto no negócio 40 % 3

34 Plano de Projeto Mitigação (Atenuação), Monitoração e Gestão de Riscos Uma estratégia para lidar com riscos deve considerar 3 pontos: evitar o risco monitorar o risco gerenciar risco e planejar para contingência.

35 Plano de Projeto