Departamento de Informática - CMM Capability Matury Model · 2019. 5. 3. · CMM Capability Matury Model No nível 1, chamado de Inicial, o desenvolvimento é caótico (ad hoc)

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


● 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


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



● 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. ● ¾


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


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


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


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


● Para subir do nível 4o. (Gerenciado) para o 5o. 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.


CMM – Visão Geral

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.

"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]

Gestão de Projetos

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


● (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.


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


● (b) ProdutoDescriçã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.


● (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.

(d) Gestão de Projetos

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)


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)


● 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


● 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


● 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


● 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

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?

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.

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.

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.

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.

Plano de Projeto

Riscos Categoria Probabilidade Impacto Mitigação

A estimativa de tamanho pode sersignificativamente

baixa

Tamanho do produto

60 % 2

Usuários finais resistem ao sistema

Impacto no negócio

40 % 3

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.

Plano de Projeto

Documents

Departamento de Informática - CMM Capability Matury Model · 2019. 5. 3. · CMM Capability Matury Model No nível 1, chamado de Inicial, o desenvolvimento é caótico (ad hoc)