Qualidade de Software - CMMI

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Centro de Computação e Tecnologia da 
Informação 
 
Qualidade de Software 
 
Engenharia de Software III 
 
Prof. Daniel Luis Notari 
 
Setembro - 2013 
Qualidade de Software 
• A qualidade de software é uma área de 
conhecimento da engenharia de software 
– que objetiva garantir a qualidade do software através 
da definição e normatização de processos de 
desenvolvimento. 
• Apesar dos modelos aplicados na garantia da 
qualidade de software atuarem principalmente 
no processo, 
– o principal objetivo é garantir um produto final que 
satisfaça às expectativas do cliente, dentro daquilo 
que foi acordado inicialmente. 
 
 
Qualidade 
“Segundo a norma ISO 9000 (versão 2000), a 
qualidade é o grau em que um conjunto de 
características inerentes a um produto, 
processo ou sistema cumpre os requisitos 
inicialmente estipulados para estes.” 
 
Qualidade X Processo SW 
“No desenvolvimento de software, a qualidade 
do produto está diretamente relacionada à 
qualidade do processo de desenvolvimento, 
desta forma, é comum que a busca por um 
software de maior qualidade passe 
necessariamente por uma melhoria no 
processo de desenvolvimento.” 
Modelos de Maturidade 
 
 
 “Um modelo de maturidade é uma coleção 
estruturada de elementos que descrevem 
características de processos efetivos” 
 
Processo de SW 
• Um processo é 
– uma sequencia de passos realizados para um 
determinado propósito [IEEE 610.12, 1690]; 
• processo de software 
– envolve métodos, técnicas, ferramentas e 
pessoas. 
• Um processo pode ser descrito de duas 
formas: 
– por propósito ou resultado e por atividade. 
Processo de SW 
• A descrição por propósito ou resultado é 
– utilizada quando não há necessidade de detalhar o 
processo, 
– apenas indicar o objetivo e o resultado. 
• A descrição por atividade 
– é a abordagem mais conhecida e intuitiva. 
– Nela são descritas as atividades com as inter-relações 
e o algoritmo de execução de cada atividade. 
– As atividades devem atingir o propósito do processo. 
Processo de SW 
• Para isso deve adotar as premissas: 
– Que procedimentos e métodos serão usados para a 
execução das atividades; 
– Que ferramentas e equipamentos suportarão a 
realização das atividades, de forma a simplificar e 
automatizar o trabalho; 
– Qual o perfil adequado de quem irá executar as 
atividades e qual o treinamento requerido nos 
procedimentos, métodos, ferramentas para que se 
possam realizar as atividades de forma adequada; 
– Quais as métricas de processo que poderão ser 
empregadas para que a execução do processo possa 
ter a qualidade avaliada. 
ISO/IEC 12207 
• Estabelece uma arquitetura de alto nível do 
ciclo de vida de software 
– que é construída a partir de um conjunto de 
processos e seus inter-relacionamentos. 
– Os processos são descritos tanto em nível de 
propósito/saídas como em termos de atividades. 
• Não possui nenhuma ligação com 
– métodos, ferramentas, treinamentos, métricas ou 
tecnologias empregadas. 
ISO/IEC 12207 
• Os processos são agrupados, 
– de acordo com a sua natureza, 
– ou seja, o seu objetivo principal no ciclo de vida 
de software. Esse agrupamento resultou em 4 
diferentes classes de processos, que são: 
• Processos fundamentais; 
• Processo de apoio; 
• Processos organizacionais; 
• Processos de adaptação. 
Processos fundamentais (1/2) 
• Necessários para que um software seja 
executado. Eles iniciam o ciclo de vida e 
comandam outros processos. São eles: 
• Aquisição: 
– possui o propósito de obter o produto e/ou 
serviço que satisfaça suas necessidades; 
• Fornecimento: 
– possui o propósito de prover um produto e/ou 
serviço; 
Processos fundamentais (1/2) 
• Desenvolvimento: 
– possui o propósito de transformar um conjunto de 
requisitos em um produto ou sistema de software; 
• Operação: 
– possui o propósito de operar o produto no seu 
ambiente e prover suporte aos usuários; 
• Manutenção: 
– possui o propósito de modificar o produto de 
software e depois dar liberação para o uso. 
Processos de apoio (1/3) 
• Os processos de apoio auxiliam outro processo. Eles são 
usados para garantir a qualidade, mas não são 
fundamentais. São eles: 
• Documentação: 
– possui o propósito de prover, manter um registro de 
informações de software; 
• Gerência de configuração: 
– possui o propósito de estabelecer e manter a integridade de 
todos os produtos de trabalho (artefato) de um processo do 
projeto; 
• Garantia da qualidade: 
– possui o propósito de prover garantia de que os produtos e 
processos estão em conformidade com o requisitos 
(padrões/normas) pré-definidos; 
 
Processos de apoio (2/3) 
• Verificação: 
– possui o propósito de confirmar que os produtos e/ou 
serviços refletem os requisitos especificados; 
• Validação: 
– possui o propósito de confirmar que os requisitos para 
o uso específico de um produto e/ou serviço são 
atendidos; 
• Revisão conjunta: 
– possui o propósito de manter o entendimento 
(gerencial comum com os stakeholders); 
Processos de apoio (3/3) 
• Auditoria: 
– possui o propósito de determinar independentemente 
a conformidade dos produtos e processos contra os 
requisitos definidos; 
• Resolução de problema: 
– possui o propósito de assegurar que todos os 
problemas levantados sejam analisados e resolvidos; 
• Usabilidade; 
• Contrato. 
Processos organizacionais (1/2) 
• Os processos organizacionais auxiliam a organização e 
gerência geral dos processos e podem ser empregados fora 
do domínio de projetos e contratos específicos, servindo 
para toda a organização. São eles: 
• Gerência: 
– possui o propósito de organizar, monitorar e controlar a 
iniciação e o desempenho dos processos; 
• Infra-estrutura: 
– possui o propósito de manter uma infra-estrutura estável e 
confiável; 
• Melhoria: 
– possui o propósito de estabelecer, avaliar, controlar e melhorar 
um processo de ciclo de vida de software; 
Processos organizacionais (1/2) 
• Recursos humanos: 
– possui o propósito de prover e manter recursos humanos 
adequados mantendo as suas capacitações consistentes com o 
negócio; 
• Gestão de ativos: 
– possui o propósito de gerenciar a vida dos ativos (reusáveis) 
desde a concepção até a desativação; 
• Gestão de programa de reuso: 
– possui o propósito de planejar, estabelecer, controlar, monitorar 
os programas de reuso; 
• Engenharia de domínio: 
– possui o propósito de desenvolver e manter modelos de 
domínio, arquiteturas e ativos deste domínio. 
Processos de adaptação 
 
• Os processos são adaptáveis a: 
– Projeto; 
– Organização; 
– Cultura; 
– Modelo de ciclo de vida, métodos e técnicas, e 
linguagens. 
Atividades do desenvolvimento 
 
• Algumas atividades importantes para o 
desenvolvimento de software serão descritas a seguir. 
São elas: 
– Implementação; 
– Levantamento de requisitos; 
– Análise dos requisitos do software; 
– Projeto da arquitetura do software; 
– Projeto detalhado do software; 
– Codificação e testes do software; 
– Integração do software; 
– Teste de qualificação do software; 
– Instalação do software; 
– Testagem e aprovação do software 
ISO/IEC 15504 
• Software Process Improvement and Capability 
dEtermination (SPICE) 
 
– Define processo de desenvolvimento de software 
– Evolução da ISO/IEC 12207 
• Define um modelo de referência de processo 
– um conjunto de processos considerados universais 
e fundamentais para a boa prática da engenharia 
de software; 
ISO/IEC 15504 
• Define seis níveis de capacidade, 
– sequenciais e cumulativos
– podem ser utilizados como uma métrica para 
avaliar como uma organização está realizando um 
determinado processo e, 
– também podem ser utilizados como um guia para 
a melhoria. 
ISO/IEC 15504 
• Modelos de Maturidade 
– Nível 0: Processo Incompleto 
– Nível 1: Processo Realizado 
– Nível 2: Processo Gerenciado 
– Nível 3: Processo Estabelecido 
– Nível 4: Processo Previsível 
– Nível 5: Processo Otimizado 
23 
Qualidade de Software 
CMM 
 Uma Visão Geral 
27 
O que é o CMM? 
 Uma estrutura que descreve os elementos 
chaves de um processo de software eficaz. 
 Um caminho de melhoramento evolucionário (5 
níveis de maturidade) para organizações de 
software mudarem de um processo de software 
imaturo, ad hoc, para um processo maduro, 
disciplinado. 
28 
CMM - Capability Maturity Model 
 Capability Maturity Model 
 (Modelo de Maturidade da Competência) 
 Maturidade da Competência : competência em 
controlar o Processo de Software 
(desenvolvimento, gerenciamento e 
manutenção). 
 Maturidade da Competência Maturidade 
do Processo de Software 
29 
Maturidade de Processo de Software 
 A maturidade dos processos de software de uma 
organização influencia na sua capacidade de 
atingir metas de custo, qualidade e cronograma 
 A qualidade do processo de software pode ser 
analisada através do nível de maturidade do 
processo. 
33 
INICIAL 
Organizações 
Caóticas 
CMM: 
Nível 1 de Maturidade 
• O processo de software é 
caracterizado como ad hoc, e 
ocasionalmente até mesmo 
caótico. 
• Poucos processos são definidos e 
o sucesso depende de esforços 
individuais e heróicos. 
35 
CMM - Nível 1 - Inicial 
Organizações Caóticas 
 A organização não provê um ambiente estável para 
o desenvolvimento e manutenção de software 
 Cronogramas e orçamentos são frequentemente 
abandonados por não serem baseados em 
estimativas realísticas 
 Numa crise para cumprir cronograma, etapas 
planejadas do ciclo de vida não são realizadas 
prejudicando a qualidade do software 
36 
 Desempenho basicamente em função da 
competência e heroísmo das pessoas que fazem 
o trabalho. 
 O processo de software é imprevisível, já que é 
constantemente alterado no decorrer do projeto 
 Os maiores problemas com os quais se 
defrontam as organizações de software são 
gerenciais e não técnicos. 
CMM - Nível 1 - Inicial 
Organizações Caóticas 
37 
REPETÍVEL 
Organizações 
Disciplinadas 
CMM: 
Nível 2 de Maturidade 
• Processos administrativos básicos são 
estabelecidos para acompanhar custo, 
cronograma e funcionalidade. 
• A disciplina de processo está em repetir 
sucessos anteriores em projetos com 
aplicações similares. 
39 
 Caracterizado pela existência de um processo efetivo de 
planejamento e gerenciamento do projeto de software 
onde os controles sobre os procedimentos, 
compromissos e atividades são bem fundamentados. 
 Os processos de planejamento e gerenciamento do 
projeto de software devem ser praticados na 
organização, documentados, treinados e controlados. 
 Neste nível ainda não há preocupação com o processo 
de engenharia de software 
CMM - Nível 2 - Repetível 
Organizações Disciplinadas 
40 
 O planejamento e gerenciamento de novos projetos 
são baseados na experiência obtida com projetos 
similares, que tenham obtido sucesso no passado 
 Um fator relevante para a organização nesse nível é a 
dependência das experiências anteriores. 
 O desenvolvimento de novos tipos de produtos pode 
causar um desequilíbrio no projeto, nas estimativas de 
custos e nos cronogramas 
CMM - Nível 2 - Repetível 
Organizações Disciplinadas 
41 
DEFINIDO 
Organizações 
Padronizadas 
• Os processos de software, tanto para 
atividades administrativas quanto para de 
engenharia estão documentados, 
padronizados e integrados em um processo 
de software padrão para a organização. 
• Todos os projetos usam uma versão 
aprovada do processo de software padrão 
da organização para desenvolvimento e 
manutenção de software. 
CMM: 
Nível 3 de Maturidade 
43 
 Caracterizado principalmente pela existência de um 
processo de engenharia de software bem definido, 
documentado e padrão para a empresa. 
 As saídas de uma atividade fluem naturalmente para 
as entradas da próxima atividade 
 Cada projeto de software utiliza o processo padrão da 
organização como base para implementar seu próprio 
processo. 
CMM - Nível 3 - Definido 
Organizações Padronizadas 
44 
 Existe um grupo para processos de software (SEPG) 
responsável por facilitar atividades de definição e 
melhoria de processos. 
 Existe um programa de treinamento que assegura que 
todos tenham o conhecimento e a capacidade requerida 
para desenvolver suas tarefas, utilizando as ferramentas 
e os métodos disponíveis 
 Processos que dêem poderes as pessoas para 
realizarem o trabalho 
CMM - Nível 3 - Definido 
Organizações Padronizadas 
45 
GERENCIADO 
Organizações 
Previsíveis 
• São coletadas medidas detalhadas da 
qualidade do processo e do produto. 
• Tanto o processo de software quanto os 
produtos são quantitativamente 
compreendidos e controlados. 
CMM: 
Nível 4 de Maturidade 
47 
 Caracterizado pela existência de processos de software 
passíveis de medida. 
 A produtividade e a qualidade são medidas em todas 
as etapas do processo de software e para todos os 
projetos da organização. 
 O controle sobre produtos e processos de todos os 
projetos são adquiridos através da diminuição da 
variação do seu desempenho para dentro de limites 
quantitativos aceitáveis. 
CMM - Nível 4 - Gerenciado 
Organizações Previsíveis 
48 
 A organização começa a aplicar métricas de controle de 
qualidade para aumentar a qualidade e a produtividade 
do software entregue aos clientes. 
 À medida que a organização adquire mais conhecimento 
sobre o produto, tem a oportunidade de remover várias 
fontes de comprometimento da qualidade final 
 Isto proporciona a oportunidade de colocar o produto 
sob um controle estatístico de qualidade. 
CMM - Nível 4 - Gerenciado 
Organizações Previsíveis 
49 
OTIMIZADO 
Organizações com 
Melhoria 
Contínua 
CMM: 
Nível 5 de Maturidade 
• Melhorias contínuas são realizadas no 
processo, utilizando-se as medidas 
quantitativas de qualidade do 
processo e produto, e também 
aplicando-se idéias e tecnologias 
inovadoras. 
51 
 Caracterizado pela existência de processos de software 
com contínua melhoria. 
 Os processos de software são avaliados para prevenir 
tipos de defeitos conhecidos devido à recorrência, e as 
lições aprendidas são disseminadas para outros 
projetos. 
 Tecnologias que proporcionem mais retorno para 
processos específicos, utilizados pela organização, são 
selecionadas para serem introduzidas, de maneira 
gerenciável na organização. 
CMM - Nível 5 - Otimizado 
Melhoria Contínua 
52 
 Apesar de o processo ser maduro, ele é alvo de 
contínuas melhorias. 
 Os grupos de projetistas analisam o rendimento do 
projeto para determinar as causas dos defeitos. 
 Nesse nível foi atingido um ambiente de excelência em 
engenharia de software 
CMM - Nível 5 - Otimizado 
Melhoria Contínua 
54 
Níveis de maturidade não 
podem ser omitidos 
 Processos dos níveis mais altos de maturidade podem 
ser realizados até mesmo por organizações do nível 1 
(embora talvez ineficazmente).
 Competência em processos é construída em estágios, 
uma vez que alguns processos não são eficazes quando 
outros não estão estáveis. 
 Cada nível oferece um fundamento necessário para 
melhorias a serem implementadas no nível seguinte. 
55 
 Sem a disciplina de gerenciamento o processo de 
engenharia é sacrificado. 
 Medidas detalhadas são inconsistentes sem um 
processo definido. 
 O efeito de inovação de processo não é claro em um 
processo cheio de ruído. 
Níveis de maturidade não 
podem ser omitidos 
56 
Outros modelos CMM 
• SW-CMM (Capability Maturity Model for Software) 
• SE-CMM (Systems Engineering Capability Maturity 
Model) 
• SA-CMM (Software Acquisition Capability Maturity 
Model) 
• P-CMM (People Capability Maturity Model) 
• IPD-CMM (Integrated Product Development 
Capability Maturity Model) 
Exercício 
• Para cada um dos níveis do CMM: 
1. Pesquise sobre as áreas chaves de cada 
processo. 
2. Identifique os elementos de engenharia de 
software presentes. 
3. Pensando no Processo Unificado, identifique o 
que pode ser usado do PU em cada nível. 
4. Pensando em Modelagem Ágil (XP e SCRUM), 
identifique o que pode ser usado do PU em cada 
nível. 
CMMI 
O que é CMMI 
(Capability Maturity Model Integration) 
“O CMMI consiste das melhores práticas que 
envolvem o desenvolvimento e manutenção de 
produtos e serviços abrangendo o ciclo de vida do 
produto desde sua concepção até a entrega e 
manutenção” 
• Exemplos: aeronave, câmera digital, pacote de 
software, suporte técnico para produto de 
software, serviços de processamento de dados, 
etc. 
Evolução do CMMI 
• Desde 1991 os CMMs tem desenvolvido uma 
grande quantidade de disciplinas; 
• Modelos: utilidade X custo; 
• Solução: modelo integrador (CMMI) 
• O framework CMMI foi desenvolvido pelo projeto 
CMMI - SEI; 
Evolução do CMMI 
• Missão do time de produto CMMI: 
Combinar 3 modelos 
– SW-CMM (CMM for software); 
– SECM (System engineering capability model); 
– IPD-CMM (Integrated product development CMM). 
• O framework CMMI foi projetado: 
– para suportar futuras integrações; 
– para ser consistente/compatível com a ISO/IEC 15504; 
 
Corpos de conhecimentos 
• Atualmente são 4 os corpos de conhecimento: 
– Engenharia de sistemas; 
– Engenharia de software; 
– Desenvolvimento integrado de produto e processo; 
– Aquisição de fornecedores; 
• Para o CMMI, estes corpos de conhecimento são 
referenciados como disciplinas. 
 
Engenharia de sistemas 
• Cobre o desenvolvimento total do sistema 
• Foca na transformação das necessidades, 
expectativas e restrições dos clientes em produtos 
e suporte a esses produtos durante as suas vidas 
Engenharia de software 
• Cobre o desenvolvimento de sistemas de software 
• Foca na aplicação sistemática e disciplinada de 
métodos de desenvolvimento, operação e 
manutenção de software 
Desenvolvimento integrado de produto e 
processo (IPPD) 
• É um método sistemático que alcança uma 
colaboração adequada dos relevantes 
stakeholders durante a vida do produto 
• É integrado com outros processos da Organização 
Aquisição de fornecedores 
• Permite que os Projetos utilizem fornecedores 
• Permite o monitoramento do fornecedor 
Selecionando disciplinas 
• As disciplinas são endereçadas através de : 
– áreas de processo associadas; 
– modelos de componentes (amplificações de 
disciplinas). 
• Área de processo: é um agrupamento de 
melhores práticas 
• As melhores práticas quando implementadas 
coletivamente, satisfazem um conjunto de 
objetivos 
Áreas de processo para engenharia de 
software 
1. Integração de produto (PI – product integration) 
2. Controle e monitoria de projeto (PMC – project monitoring and control) 
3. Planejamento do projeto (PP – project planning) 
4. Garantia da qualidade do produto e processo (PPQA – process and product quality 
assurance) 
5. Gerenciamento quantitativo do projeto (QPM – quantitative project management) 
6. Desenvolvimento de requisitos (RD – requirements development) 
7. Gerenciamento de requisitos (REQM – requirements management) 
8. Gerenciamento de riscos (RSKM – risk management) 
9. Gerenciamento de contrato de fornecedores (SAM – Supplier agreement 
management) 
10. Solução técnica (TS – technical solution) 
11. Validação (VAL - validation) 
12. Verificação (VER - verification) 
Áreas de processo para engenharia de 
software 
• São as mesmas listadas para a engenharia de 
sistemas 
• Possuem amplificações 
Áreas de processo para desenvolvimento integrado de 
produto e processo 
• São as mesmas listadas para a engenharia de 
sistemas, com duas áreas de processo adicionais: 
– Times integrados (IT – integrated teaming); 
– Ambiente Organizacional para integração (OEI – 
organizational environment for integration). 
• Possuem amplificações 
Áreas de processo para aquisição de 
fornecedores 
• São as mesmas listadas para a engenharia de 
sistemas, com uma área de processo adicional: 
– Gerenciamento de fornecedor integrado (ISM 
integrated supplier management). 
• Possuem amplificações. 
Diferentes métodos de CMMI 
• No CMMI, existem dois tipos de métodos, 
chamados de representações: por estágios 
(staged) e contínua (continuous) 
• Uma representação reflete a Organização, o uso e 
apresentação de componentes em um modelo 
Representação por estágios 
• Utilizado no software CMM 
• Utiliza um conjunto pré-definido de áreas de 
processo para definir um caminho de melhoria 
para uma Organização 
• Esse caminho de melhoria é descrito por um 
modelo de componente chamado nível de 
maturidade 
Representação contínua 
• Utilizado no SECM e IPD-CMM 
• Permite que uma Organização selecione uma área 
de processo específica e realize melhorias com 
relação a essa área 
• Utiliza níveis de capacidade para caracterizar 
melhorias relativas a uma área de processo 
individual 
Componentes da área de 
processo 
• São agrupados em três categorias: 
– Componentes obrigatórios (required components); 
– Componentes esperados (expected components); 
– Componentes informativos (informative components). 
Componentes obrigatórios 
• Descrevem o que uma Organização deve alcançar 
para satisfazer a área de processo 
• Correspondem aos objetivos específicos e 
genéricos (specific and generic goals) 
• O atendimento a um objetivo é utilizado em 
avaliações 
Componentes esperados 
• Descrevem o que uma Organização irá 
implementar para atender um componente 
obrigatório 
• Correspondem às práticas específicas e genéricas 
(specific and generic practices) 
• Guiam aqueles que implementam melhorias ou 
executam avaliações 
Componentes informativos 
• Provêm detalhes que ajudam a utilização dos 
componentes esperados e obrigatórios 
• Correspondem às Subpráticas, produtos de 
trabalho, amplificações de disciplinas, 
elaborações de práticas genéricas, títulos de 
objetivos e práticas, notas de objetivos e práticas 
e referências 
Entendimento dos níveis 
“Os níveis são utilizados no CMMI para descrever o 
caminho evolucionário recomendado para a 
Organização que espera melhorar os processos e 
seu uso para o desenvolvimento e manutenção de 
produtos e serviços” 
 
Entendimento dos níveis 
• Para a representação contínua, utiliza-se o termo 
nível de capacidade 
• Para a representação por estágios, utiliza-se o 
temo nível de maturidade 
• Ambas as representações providenciam maneiras 
de implementar melhorias de processo para 
atingir os objetivos de negócio 
 
O Processo de Avaliação no Brasil 
http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-
cmmi-no-brasil 
 
 
Exercícios 
1. Qual a principal diferença entre o CMM e o 
CMMI? 
2. Qual a diferença entre os níveis de 
capacidade e maturidade do CMMI? 
3. Qual é a diferença entre representação por 
estágio e contínua do CMMI? 
4. Procure número atualizados do uso de CMMI 
em empresas brasileiras e no mundo. 
Exercícios 
5. Pesquise um estudo de caso de uma empresa 
que usou implantou o CMMI e faça uma 
apresentação para relatar o que aconteceu. 
6. Leia o Artigo: O CMMI e o Gerenciamento da 
Qualidade de Projetos de Software e explique 
o que o CMMI tem a haver com o processo 
de desenvolvimento de software. Além disto, 
relate se é possível trabalhar com o CMMI 
em conjunto com uma metodologia do tipo 
XP, SCRUM ou RUP.