Engenharia de Software | Qualidade de software | Modelo de Qualidade de Software
ISO/IEC 15.504 (SPICE)
Fazendo uso dos modelos de qualidade de software aplicados ao processo do ciclo de vida e gerências de risco na qualidade de software, temos a ISO/IEC 15.504, conhecida como SPICE. De acordo com a sua visão, a avaliação do processo será utilizada para identificar o aperfeiçoamento.
A SPICE irá compreender o estado dos seus próprios processos com a finalidade de identificar aperfeiçoamentos. Além disso, quando utilizada, poderá levar ao aperfeiçoamento dos processos. Desse modo, promove a capacidade para ir ao encontro de uma classe específica de contratos no futuro. O esquema a seguir demonstra a visão do SPICE (ISO/IEC 15.504).
Conheça as cinco partes da ISO 15.504:
- Conceitos e vocabulário.
- Requisitos mínimos para a realização de uma avaliação visando à consistência e à repetibilidade.
- Guia (não normativo) para a interpretação dos requisitos para a realização de uma avaliação.
- Guia (não normativo) para a determinação da capacidade (perfil de capacidade) e melhoria de processo (perfil + plano de ação).
- Modelo de referência de processos (não normativo) aderente aos requisitos da Parte 2. Podem ser usados outros modelos, como, por exemplo, a ISO 12.207 ou o CMMI.
Elementos normativos da ISO 15.504
A imagem a seguir, desenvolvida pelo professor da Unicamp Mário L. Côrtes, apresenta os modelos de qualidade de software. Acompanhe!
Fonte: Modelos de Qualidade de SW (CÔRTES, Mario L. s.d.).
Utilização da ISO/IEC 15.504
A ISO/IEC 15.504 é utilizada para determinar a situação no início de uma iniciativa e avaliar o progresso durante ela.
Ela irá fornecer um perfil detalhado do estado dos processos, mensurados de acordo com um modelo que representa um consenso internacional sobre as melhores práticas.
Os seus resultados podem ser utilizados para comparar as normas práticas com outras referências.
A ISO/IEC 15.504 não obriga que se siga um percurso específico de aperfeiçoamento. Pelo contrário, ela incentiva o desenvolvimento de um programa de aperfeiçoamento com base nas suas próprias necessidades.
Determinação da capacidade
A determinação da capacidade refere-se à avaliação de uma organização ou de um projeto para determinar os riscos inerentes ao resultado bem-sucedido de um contrato, de um desenvolvimento ou da entrega de serviços.
Pode expressar a capacidade necessária ou os critérios de seleção, sendo que dos perfis reais pode surgir uma capacidade oferecida – com base nas evidências de projetos atuais ou passados juntamente com as evidências das medidas de aperfeiçoamento propostas.
A avaliação SPICE pode ser realizada por um organismo independente, pela organização de um cliente ou pela própria entidade (autoavaliação). A determinação da capacidade também pode ser realizada internamente para verificar os riscos de um novo projeto.
CMMI
Conforme você viu nesta disciplina, uma métrica importante é a medição dos níveis de maturidade. Esse processo é chamado de método de verificação e faz uso dos níveis do Modelo de Maturidade (CMM). Assim, medimos o modelo de maturidade de capacidade – e com sua evolução temos o CMMI.
O gráfico a seguir representa a visão geral do software segundo o CMM.
O modelo CMMI, como ferramenta no gerenciamento de projetos de software, é o que há de mais completo quando o assunto é qualidade de software.
Mas o que é CMMI?
O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (genéricas ou específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).
Desenvolvido pelo SEI (Software Engineering Institute), o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.
O CMMI possui duas representações: “contínua” ou “por estágios”. Essas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representação contínua e por estágios
Representação continua: possibilita a organização utilizando a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizada por níveis de capacidade (capability levels).
Representação por estágios: disponibiliza uma sequência predeterminada para melhoria baseada em estágios. Cada estágio serve de base para o próximo. Essa representação é caracterizada por níveis de maturidade (maturity levels).
Estágios do CMMI
O CMMI está divido em cinco estágios. Acompanhe:
MPS
MPS (Melhoria do Processo de Software) é uma metodologia para o processo de desenvolvimento de software. Inclusive, temos a nomenclatura MPS-BR. Ou seja, a metodologia atende a critérios para o processo de software brasileiro.
Essa metodologia foi criada por um conjunto de organizações ligadas ao desenvolvimento de software. Dentre as instituições envolvidas pode-se citar:
- Softex (SP);
- RioSoft (RJ);
- COPPE/UFRJ (RJ);
- CESAR (PE).
Na verdade, essas são organizações normalmente não governamentais, e muitas vezes de origem acadêmica, possuindo uma atuação de destaque junto à comunidade de software brasileira. Enfatiza-se, dentro do MPS-BR, o uso das principais abordagens internacionais voltadas para a definição, a avaliação e a melhoria dos processos de software. Tal fato torna o MPS-BR compatível, inclusive, com as práticas do CMMI.
Há ainda no MPS-BR uma estrutura de níveis de maturidade, de forma similar àquela existente dentro do CMMI. Os diferentes níveis de maturidade do MPS-BR constituem um meio para indicar qual o nível da empresa que se está considerando. Cada classificação possível atesta, assim, diferentes graus no controle de processos e qual a qualidade que se pode esperar da organização que a detém.
O que diferencia a metodologia MPS-BR do modelo CMMI são, justamente, os níveis de capacidade de maturidade do modelo em avaliação.
MPS-BR: níveis de maturidade
Conheça os sete níveis de maturidade previstos pelo MPS-BR:
A – Em otimização: há a preocupação com questões como inovação e análise de causas.
B – Gerenciado quantitativamente: avalia-se o desempenho dos processos, além de sua gerência quantitativa.
C – Definido: aqui ocorre o gerenciamento de riscos.
D – Largamente definido: envolve verificação, validação, além da liberação, instalação e integração de produtos, dentre outras atividades.
E – Parcialmente definido: considera processos como treinamento, adaptação de processos para gerência de projetos, além da preocupação com a melhoria e o controle do processo organizacional.
F – Gerenciado: introduz controles de medição, gerência de configuração, conceitos sobre aquisição e garantia da qualidade.
G – Parcialmente gerenciado: nesse ponto inicial, deve-se começar o gerenciamento de requisitos e de projetos.
MPS-BR
Devido à necessidade do grande investimento para o CMMI, indica-se como alternativa o MPS-BR, principalmente para empresas de pequeno e médio porte. Inclusive, essa tem sido uma exigência para as licitações de empresas governamentais e não governamentais.
APRENDA +
Para saber mais sobre os modelos de qualidade de software ISO/IEC 15.504 (SPICE), CMMI E MPS acesse os links:
• Qualidade de Processo de Software – normas ISO 12.207 e 15.504; http://slideplayer.com.br/slide/367553/
• Qualidade – MPS.BR; http://www.softex.br/mpsbr/
• Maturidade no desenvolvimento de software: CMMI e MPS-BR; http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mps-br/27010
• CMMI para iniciantes; http://www.linhadecodigo.com.br/artigo/1401/cmmi-para-iniciantes.aspx#ixzz3aEAVrUPO
• Guia do MPS.br vira app na Apple. http://www.fabricadetestes.com.br/index.php?option=com_k2&view=item&id=105:guia-do-mpsbr-vira-app-na-apple
Referências
KOSCIANSKI, André. Qualidade de software. São Paulo: Novatec, 2007.
PAULA FILHO, Wilson de. Engenharia de software: fundamentos, métodos e padrões. Rio de Janeiro: LTC, 2009.
PFLEEGER, Shari Lawrence. Engenharia de software. São Paulo: Pearson, 2003.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. Porto Alegre: Bookman, 2011.
Material retirado da WEB
Engenharia de Software | Qualidade de software | Modelo de Qualidade de Software