Comparando padrões de Qualidade

22/4/2014 23:30:18 - Fábio Ferreira de Souza

image

Esta é uma imagem ilustrativa que compra o CMMI, que é um padrão de qualidade de software e o MPS.br, o padrão de qualidade de software brasileiro.

É interessante notar que o nível 1 do CMMI, significa não seguir um processo, ou ter qualquer padrão de qualidade, mas por outro lado o nível G do MPS.br já significa ter algum controle sobre o processo e a qualidade.

Abaixo, extrai da Wikipédia os níveis dos padrões de qualidade mais conhecidos, e fiz uma breve analise de algumas coisas que dá para fazer individualmente como programador.

MPS.br

  • A - Em Otimização;
  • B - Gerenciado quantitativamente;
  • C - Definido;
  • D - Largamente Definido;
  • E - Parcialmente Definido;
  • F - Gerenciado;
  • G - Parcialmente Gerenciado.

Note que os níveis de processo se dividem simplesmente em: Gerir > Definir > Quantificar > Otimizar.

Refletindo do mais alto nível ao mais simples, é obvio que sempre podemos melhorar, otimizar é achar formas de melhorar o que já está bom, continuamente, pois sempre haverá algo a melhorar em qualquer coisa que fazemos.

Só é possível quantificar, quando já foi definido métricas, valores numéricos que pontuem o software e o processo aplicado, enquanto não há números qualquer avaliação é apenas subjetivamente qualitativa, do tipo: “melhor ou pior que”, assim comparações qualitativas são de certa forma uma comparação binaria.

Assim os primeiros processos definirão os níveis que serão quantificados e otimizados com o tempo, por meio de uma gestão constante, otimizando todo o processo.

CMMI

Nível 1: Inicial (Ad-hoc)

Não possui áreas de processo.

Nível 2: Gerenciado / Gerido

  • Gerenciamento de Requisitos - REQM (Requirements Management)
  • Planejamento de Projeto - PP (Project Planning)
  • Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control)
  • Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)
  • Medição e Análise - MA (Measurement and Analysis)
  • Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance)
  • Gerência de Configuração - CM (Configuration Management)

Nível 3: Definido

  • Desenvolvimento de Requisitos - RD (Requirements Development)
  • Solução Técnica - TS (Technical Solution)
  • Integração de Produto - PI (Product Integration)
  • Verificação - VER (Verification)
  • Validação - VAL (Validation)
  • Foco de Processo Organizacional - OPF (Organizational Process Focus)
  • Definição de Processo Organizacional - OPD (Organizational Process Definition)
  • Treinamento Organizacional - OT (Organizational Training)
  • Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
  • Gerenciamento de Riscos - RSKM (Risk Management)
  • Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution)

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

  • Desempenho de Processo Organizacional - OPP (Organizational Process Performance)
  • Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nível 5: Em otimização

  • Gestão de Processo Organizacional - OPM (Organizational Process Management)
  • Análise Causal e Resolução - CAR (Causal Analysis and Resolution)

Em vermelho destaquei partes do CMMI, que o programador deve ter sempre em mente para qualquer projeto, a imagem clássica abaixo ilustra muito alguns “porquê”


  • REQM - Como o cliente explicou

  • PP - Como o analista planejou

  • TS - Como o programador codificou

  • Como o consultor de negócio descreveu

  • Como o projeto foi documentado

  • OT - O que a assistência técnica instalou

  • SAM - Como o cliente foi cobrado

  • IPM - Como é suportado

  • VAL - O que o cliente realmente necessitava

Há alguns comentários mais explicativos no link abaixo:

O desenvolvimento de um projeto a ironica e triste realidade

e você pode criar e personalizar estas tirinhas também:

http://www.projectcartoon.com/

Infelizmente essa é uma dura realidade quando não existe processos, e nem conceitos de qualidade, portanto para o programador é necessário principalmente:

REQM – Entender o que o cliente realmente precisa.
Nem sempre o que o cliente diz precisar é realmente o que ele realmente precisa.
Nem sempre o que o programador quer fazer é o que o cliente precisa.
O cliente nem sempre entende o suficiente de tecnologia para tomar as melhores decisões, e o programador quer sempre usar o que há de mais moderno mesmo sem conhecer profundamente.

Os requisitos tem que deixar claro o que o software DEVE fazer, dentro dos limites da criatividade do que PODE ser feito como um diferencial para a solução.

PP – Planejamento e Prazos precisam ser reais

MA – É preciso definir algumas métricas para saber se o objetivo esperado foi alcançado

VAL – O cliente tem que aceitar o que foi entregue baseado no que foi solicitado.
O software DEVE fazer o que o cliente pediu, e PODE fazer algo a mais como um diferencial, desde que tenha sido planejado

CM – Deve ser definido como será continuado o projeto, a implantação, as atualizações, treinamento…

RSKM – Qualquer projeto envolve riscos, deve-se analisar quais os riscos que engloba o projeto, e deixar o cliente ciente a fim de planejar ações ou simplesmente aceitar problemas quando ocorrer.

ISO 15504 (SPICE)

 

 

Outras Referencias Pessoais: