Modelos de medição de software PSM e CMM

Modelo de Maturidade de Software – Modelos de medição de software PSM e CMM

PSM (Practical Software Measurement)

O PSM é um modelo para mensuração de projetos de software criado em 1994, sob o patrocínio do DoD (Departamento da Defesa Norte-Americano). O modelo foi elaborado e vem sendo atualizado por renomeados profissionais da área de Software Process Improvement, tais como John McGarry, David Card e Beth Layman.

O PSM foi utilizado como base para elaboração da Process Área Meansurement and Analysis do CMMI (Capability Maturity Model – Integration ou Modelo de Maturidade em Capacitação – Integração) é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas).

O que é o PSM?

PSM é um modelo que estrutura a atividade de mensuração em um projeto de software; é um processo para medir e melhorar processos, projetos e produtos de software.

Objetivos do PSM

• Estabelecer um processo de medição dos projetos de software e gerenciamento dos sistemas;
• Prover bases de informações e comunicações para tomada de decisão;
• Estabelecer uma fundação para melhorar o gerenciamento organizacional e executivo.

ATENÇÃO: Um de seus diferenciais é que suporta integração de medidas organizacionais em seu processo de desenvolvimento e gerenciamento.

Utilização do PSM

O PSM foi utilizado como base para elaboração da Process Area Meansurement and Analysis do CMMI (o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas).

Exemplos de organizações que participam ativamente do desenvolvimento do PSM são: Força Aérea, Exército e Marinha norte-americanos; Software Productivity Consortium; Boeing; GTE; Raytheon-Hughes; Lockheed-Martin; MITRE; Software Engineering Institute; Teraquest, TRW.

Modelos do PSM

O PSM é um modelo que estrutura a atividade de mensuração em um projeto de software é um processo para medir e melhorar processos, projetos e produtos de software. Em nível prático o PSM procura resolver dois problemas:

• Como especificar de uma maneira formal as medidas que deverão ser utilizadas no projeto, ou seja, os indicadores a serem usados;
• Como deverá ser conduzido o processo de medição. Para atingir tais objetivos, o PSM faz uso do modelo de Informação que fornecer um caminho para a seleção das medidas utilizadas. Vamos aprofundar melhor sobre o assunto a seguir.

Modelo de informação

O Modelo de Informação do PSM define uma estrutura para a definição das medidas que deverão ser utilizadas no projeto. Cada especificação é escrita por um membro do PSM e inclui os conceitos abaixo:

• Atributo – propriedade relevante do ponto de vista das necessidades de informação.
• Método – operação que mapeia o atributo para uma escala.
• Medida Básica – valor resultante da aplicação do método a um atributo.
• Função – algoritmo combinando duas ou mais medidas básicas.
• Medida Derivada – valor resultante da aplicação de uma Função.
• Modelo – algoritmo combinando medidas e critérios de decisão.
• Indicador – estimativa ou avaliação que provê uma base para tomada de decisão.

Exemplo simples:

Com o objetivo de obter estimativas de produtividade no desenvolvimento de software, poderíamos ter a aplicação do seguinte Modelo de Informação:

Para cada projeto obter:

• Atributos – horas trabalhadas no projeto.
• Métodos – contar horas(obtendo o esforço do projeto), contar pontos de função (obtendo o tamanho funcional do projeto).
• Medidas Básicas – esforço do projeto em horas, tamanho do projeto em pontos de função.
• Função – dividir tamanho do projeto pelo esforço (obtendo Pontos de Função/Hora).

A partir dos resultados obtidos para os projetos, obter:

• Indicador – média e intervalo de confiança a 2 desvios-padrões para a produtividade.

Conjunto de medidas do PSM

As medidas devem ser obtidas a partir das necessidades de informação. O PSM inclui um conjunto de medidas já utilizadas com sucesso pela indústria. As medidas correspondem a categorias previamente definidas. Assim, as métricas selecionadas serão agrupadas nas seguintes áreas:

Prazo e Progresso – relacionados ao cumprimento dos prazos do projeto.

Exemplos: funcionalidades implantadas esforço despendido, milestones alcançados no prazo e fora do prazo, funcionalidades testadas, solicitações de mudanças, revisões.

Recursos e custo – relacionados à adequação entre o trabalho a ser executado e os recursos alocados ao projeto.

Exemplos: Esforço do desenvolvimento; custo de pessoal; esforço médio para solução de defeitos; overhead organizacional, overhead de atividades não planejadas, viagens etc.

Tamanho e Estabilidade do Produto – informações relacionadas à estabilidade das funcionalidades ou à capacidade requerida do software.

Exemplos: tamanho em função da técnica de estimativas; estabilidade em função do número de mudanças/acréscimo/remoção de requisitos.

Qualidade do produto – relacionada à capacidade do software produzido de atender sem falhas às necessidades do usuário.

Exemplos: ciclo de vida do software; taxa de retrabalho; densidade de defeitos; complexidade do produto.

Performance do Processo – relacionada à capacidade do processo de atender às necessidades apresentadas por cada projeto.

Exemplos: produtividade; efetividades dos testes; efetividade de processos de revisões/inspeções; taxa de retrabalho; percentual de esforço por fase de desenvolvimento.

Eficácia da Tecnologia – trata da viabilidade e adequação das alternativas técnicas propostas, incluindo reuso, maturidade e qualidade dos componentes.

Satisfação do Cliente – relaciona-se ao grau em que os produtos e serviços ofertados atendem às expectativas dos clientes.

Exemplos: número e tipo de reclamações; questionário de satisfação; tempo de resposta para atividades de suporte ao cliente.

SW-CMM (Capability Maturity Model for Software)

SW-CMM (Capability Maturity Model for Software) é uma conjunto de melhores práticas para os processos de desenvolvimento e manutenção de software. Com o SW-CMM, é possível avaliar e identificar pontos de melhoria. O SW-CMM mede a maturidade do processo em cinco níveis:

O SW-CMM, portanto, é um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software.

Histórico do CMM

• Início dos trabalhos deu-se em 1986, tendo sido publicada a versão 1.0 do SW-CMM em agosto de 1991;
• Em fevereiro de 1993 foi publicada a versão 1.1;
• Por ser específico para a área de software, o SW-CMM não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas;
• Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas, tais como Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM);
• Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.

Diversidade de Modelos e Padrões em diversas áreas:

Problemas encontrados:

• Diferentes estruturas, termos, e forma de medir;
• Causa confusão, especialmente quando mais de um modelo é usado;
• Difícil de integrar em um único programa de melhoria.

CMMI

O que é?

O CMMI (Capability Maturity Model Integration) foi criado com a finalidade de integrar os diversos modelos CMM.

Quando foi criado?

Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated – System / Software Engineering).

Quais versões?

Versões do CMMI:

• Versão 1.0: Agosto de 2000;
• Versão 1.1: Março de 2002;
• Versão 1.2: Agosto de 2006 (CMMI for Development).

Níveis de maturidade do SW-CMM

Um nível de maturidade é um patamar evolutivo bem definido, que visa a alcançar um processo de software maduro. Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de software, no nível 2, por exemplo, são focados aspectos gerenciais dos projetos. Vamos aprofundar melhor em cada nível.

1 – Inicial: Processo imprevisível e sem controle

SW-CMM: Nível 1 (Inicial)

• O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico.
• Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heroicos.
• O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.
• Organizações no nível 1 apresentam deficiências de planejamento e enfrentam dificuldades ao realizarem previsões.
• Cronogramas e planos são irrealistas.
• Como não há credibilidade no planejamento, mesmo aquilo que foi planejado não é seguido.
• Não há controle de requisitos e o cliente só os avalia na entrega do produto.
• É comum passar diretamente dos requisitos à codificação.
• A documentação é encarada como algo inútil.
• São comuns reações intransigentes à coleta de dados e ao uso de padrões, documentação e ferramentas.

2 – Repetível: Processo disciplinado

SW-CMM: Nível 2 (Repetível)

• Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo.
• É possível repetir sucessos de projetos anteriores em aplicações similares.
• Ao invés do processo ser uma única caixa preta, ele passa a ser uma sequência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.
• No Nível 2, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente.
• A organização é disciplinada, mas não está bem preparada para mudanças.
• Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos, porém, a gerência ainda não é proativa, tomando ações normalmente quando se está diante de uma crise.
• Os projetos podem ter processos diferentes, no entanto, existe uma política para guiar os projetos no estabelecimento desses processos.

3 – Definido: Processo consistente e padronizado

SW-CMM: Nível 3 (Definido)

• Um processo de software, composto por atividades de gerência e engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização.
• Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software.
• A organização interna das tarefas está definida e visível.
• Processos utilizados são estabelecidos e padronizados em toda a organização.
• Os processos pertencem à organização e não aos projetos.
• O Grupo de Processos (Software Engineering Process Group – SEPG) é responsável pelos processos da organização.
• Apesar da padronização, é possível adaptar os processos para as necessidades particulares de um projeto.
• Processos de engenharia de software são considerados ao lado dos processos gerenciais.
• Há treinamento técnico e gerencial.
• A organização consegue se manter dentro do processo mesmo em períodos de crise.
• Como o processo é bem-definido, caso um desenvolvedor abandone o projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores.
• Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores práticas existentes na organização.

4 – Gerenciado: Processo previsível e controlado

SW-CMM: Nível 4 (Gerenciado)

• A organização estabelece metas quantitativas de qualidade e produtividade para as atividades do processo e para os produtos produzidos são estabelecidas para cada projeto.
• Medidas de qualidade e produtividade são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento e a ocorrência de problemas.
• Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída.
• É estabelecido o controle estatístico de processos.
• Uma organização no nível 4 passa a ter uma gestão feita com bases quantitativas.
• Métricas detalhadas do processo de software e da qualidade do produto são coletadas.
• Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.

5 – Otimizado: Processo continuamente melhorado

SW-CMM: Nível 5 (Otimizado)

A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa e da implantação planejada e controlada de novas tecnologias.

• A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma proativa, prevenindo defeitos.
• O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo.
• Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.
• Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo/benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4.

Atividade proposta

Discuta com os colegas quais as ações que devem ser tomadas para que as organizações sejam homologadas com grau 5 no CMM.

Chave de resposta: O CMMI procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplina.

Referências

PFLEEGER, Shari Lawrence. Engenharia de software – teoria e prática. 2. ed. São Paulo: Pearson (Livros Universitários), 2003.

PRESSMAN, Roger S. Engenharia de software – uma abordagem profissional. 7. ed. São Paulo: MCGRAW-HILL BRASIL, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson (Livros Universitários), 2011.

Lista de Exercícios de Modelo de Maturidade de Software – Lista 6