José Malcher Jr.

Eng. Software – Analista de Sistemas

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