Qualidade de

software
 Material Teórico
Motivação de Qualidade

Responsável pelo Conteúdo:

Prof. Ms. Douglas Almendro

Revisão Textual:
Profa. Esp. Márcia Ota
 Motivação de Qualidade

• Motivação de Qualidade

• Qualidade x tipo de software

• Avaliação da qualidade do produto

Nesta Unidade, será explanado o conceito de qualidade. Esse

primeiro passo nos levará ao entendimento de certificações
dadas às metodologias que são utilizadas no mercado de
software. Então, não perca nenhum detalhe dessa unidade.

Considerando o conhecimento adquirido por meio dos conceitos iniciais de qualidade e

algumas metodologias voltadas para software, a proposta desta Unidade é mostrar que a
qualidade faz parte da vida cotidiana. Vale salientar que a visão popular que se tem do
conceito de qualidade pode ser muito diferente de como ele é usado profissionalmente.
Por isso, não deixe de assistir, também, à apresentação narrada do conteúdo e de alguns
exercícios resolvidos.
Finalmente, e o mais importante: fique atento às atividades avaliativas propostas e ao prazo
de realização e envio.

5
 Unidade: Motivação de Qualidade

Contextualização

Ao desenvolver um software, devemos estar familiarizados com os conceitos de qualidade.

Entre eles, podemos citar o CMM (Capability Maturity Model), e a ISO/SPICE (Software Process
Improvement & Capability Determination.
O CMM é o modelo desenvolvido pelo Instituto de Engenharia de Software (SEI) da
Universidade Carnegie-Mellon, EUA, visando dar às organizações diretrizes sobre como
aprimorar o processo.
A ISO/SPICE (Software Process Improvement & Capability Determination), cujo objetivo é
gerar normas ISO/IEC para a avaliação de processos de software.
Norma ISO/IEC 12207, define um processo de ciclo de vida do software.
Norma ISO/IEC 9000-3, apresenta diretrizes para a aplicação da ISO 9001 (voltada para
indústria), por empresas que desenvolvem software, para o processo de desenvolvimento e
manutenção de software Avaliação da qualidade do produto.
Com base nos conceitos de qualidade, estaremos mais à frente, optando pela melhor
metodologia a ser seguida. É assim que seguiremos uma metodologia de qualidade.

6
 Motivação de Qualidade

Antes de iniciarmos nossos estudos, vamos primeiro entender o significado de qualidade. Veja:
O Dicionário Aurélio define qualidade como: “propriedade, atributo ou condição das coisas
ou das pessoas capaz de distingui-las das outras e de lhes determinar a natureza” [Aurélio86].
Como um atributo de um item, a qualidade se refere a coisas que podem ser medidas, ou
seja, comparadas com padrões conhecidos, tais como, tamanho, cor, propriedades elétricas,
maleabilidade, etc. Entretanto, é mais difícil categorizarmos qualidade em software, que é uma
entidade intelectual, do que em objetos físicos.
Quando falamos de qualidade, deparamo-nos com diversas situações. Veja um exemplo:
O que seria um automóvel que tem qualidade?
Vêm-nos em mente diversos tipos, modelos e marcas tão sonhadas, mas o que devemos observar?
Esses automóveis tão sonhados espelham a qualidade principalmente pela funcionalidade,
segurança, fácil manutenção e diversas outras conformidades que necessitamos.
Aproveitando o nosso exemplo do automóvel, quando nos deparamos por um aviso no
rádio, televisão e/ou internet, sobre um recall de um determinado automóvel, qual a sensação
que é esperada a princípio por todos?
Provavelmente, a sensação de que houve um defeito no projeto do automóvel, pois o
que nos surpreende é que logo em seguida mostram o lote em que se deve efetuar o recall,
do número x até o número y desse veículo e modelo... Isso mostra, de fato, que houve
algum erro, defeito ou bug?
Sim, mas o erro foi identificado a tempo e, mesmo assim, conseguiram saber quais veículos
produzidos da linha de montagem tiveram esta anomalia.
Isso prova que as maiorias das indústrias (nesse caso, automobilísticas) conseguem ter
controle de todos os processos efetuados na criação de um veículo.
Vale salientar que as indústrias têm como controlar essas anomalias, mas nem sempre foi
assim, para chegar a esse grau de excelência, erram muito.
Bem, mas e quando falamos de software?
Definir qualidade de software é uma tarefa difícil. Muitas definições têm sido propostas e uma
definição decisiva poderia ser debatida interminavelmente.
Ao se examinar um item baseado em suas características mensuráveis, dois tipos de qualidade
podem ser encontradas: qualidade de projeto e qualidade de conformidade [Pressman97].
• Qualidade de projeto se refere a características que projetistas especificam para um item
(desempenho, tolerância, etc.). O enfoque maior é nos requerimentos, na especificação e
no projeto do sistema.
• Qualidade de conformidade é o grau, no qual, as especificações do projeto são seguidas
durante o processo de desenvolvimento. O enfoque maior é na implementação.

7
 Unidade: Motivação de Qualidade

Uma definição de qualidade de software que se encaixa nesse escopo é: “conformidade a

requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento
claramente documentados e a características implícitas que são esperadas de todo software
profissionalmente desenvolvido” [Pressman95].
Hoje, temos uma dependência crescente em sistemas computacionais.
Sistemas computacionais dependem cada vez mais do software. Por isso, o mau funcionamento
do software pode gerar custos altos.
Alguns exemplos do passado:
• bug do milênio;
• avião F-16: voou de cabeça para baixo ao cruzar o equador devido à falha no software
de navegação;
• lançamento do ônibus espacial Columbia foi atrasado em 1981 devido à alteração errada
em rotina de sincronização;
• ao menos duas mortes causadas por overdose de radiação por causa de uma falha de
software no Therac-25;
[Link]
Agora, reflita:
No futuro, o que pode acontecer se bancos perderem milhões, clientes virem saldos de suas
contas sumirem de repente, telefones pararem de funcionar, aviões tiverem suas rotas desviadas,
vários trens/metrô forem colocados no mesmo trilho, entre muitos outros exemplos relacionados
às consequências do mau funcionamento dos softwares?

Características de Qualidade
Abaixo, temos uma figura que representa as características de qualidade segundo McCall.
Cada item representa uma característica de cada processo.

Modelo de Qualidade de McCall et al, 1977

8
 Com relação ao uso do produto (características operacionais):

• correção: o quanto um programa satisfaz a sua especificação e cumpre os objetivos

visados pelo cliente;
• confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida;
• eficiência: a quantidade de recursos computacionais e de código exigida para que um
programa execute sua função;
• integridade: o quanto o acesso ao software ou aos dados por pessoas não autorizadas
pode ser controlado;
• usabilidade: o quanto de esforço é necessário para aprender, preparar a entrada e
interpretar a saída de um programa.

Com relação às alterações do produto (habilidade para ser alterado):

• manutenibilidade: o quanto de esforço é necessário para localizar e eliminar erros em

um programa.
• flexibilidade: o quanto de esforço é necessário para modificar um programa.
• testabilidade: o quanto de esforço é necessário para testar um programa a fim de garantir
que ele execute a função pretendida.

Com relação às alterações do produto (habilidade para ser alterado):

• portabilidade: o quanto de esforço é necessário para transferir um programa de uma
plataforma de hardware e/ou software para outra.
• reusabilidade: o quanto um programa (ou partes dele) pode ser reutilizado em outros
programas.
• interoperabilidade: o quanto de esforço é necessário para se acoplar um programa a outro.

Funcionalidade: o software satisfaz às necessidades explícitas e implícitas do usuário?

Confiabilidade: o software, durante um período de tempo, funciona de acordo com as
condições preestabelecidas?
Usabilidade: o software é fácil de usar?
Eficiência: o software não desperdiça recursos?
Manutenibilidade: o software é fácil de alterar?
Portabilidade: o software é facilmente adaptável a diferentes plataformas?

9
 Unidade: Motivação de Qualidade

Características e subcaracterísticas
Funcionalidade: o software satisfaz às necessidades explícitas e implícitas do usuário?
• Adequação: propõe-se a fazer o que é apropriado?
• Acurácia: gera resultados corretos ou conforme acordado?
• Interoperabilidade: é capaz de interagir com os sistemas especificados?
• Conformidade: está de acordo com normas e convenções previstas em leis, normas e
descrições similares?
• Segurança de acesso: evita o acesso não autorizado, acidental ou deliberado acesso a
programa e dados?

Confiabilidade: o software, durante um período de tempo, funciona de acordo com as

condições preestabelecidas?
• Maturidade: com que frequência apresenta falhas?
• Tolerância a falhas: ocorrendo falhas, como ele reage?
• Recuperabilidade: é capaz de recuperar dados após uma falha?

Usabilidade: o software é fácil de usar?

• Inteligibilidade: é fácil entender os conceitos utilizados ?
• Apreensibilidade: é fácil de aprender a usar ?
• Operacionalidade: é fácil de operar e controlar a operação ?

Eficiência: o software não desperdiça recursos?

• Comportamento em relação tempo: qual é o tempo de resposta e de processamento?
• Comportamento em relação aos recursos: quanto recurso usa? Durante quanto tempo?

Manutenibilidade: o software é fácil de alterar?

• Analisabilidade: é fácil encontrar um erro quando ocorre?
• Modificabilidade: é fácil modificar e remover erros?
• Estabilidade: há grandes riscos de erros quando se faz alterações?
• Testabilidade: é fácil testar quando se faz alterações?

Portabilidade: o software é facilmente adaptável a diferentes plataformas?

• Adaptabilidade: é fácil adaptar a outras plataformas sem aplicar outras ações ou meios
além dos fornecidos para esta finalidade no software considerado?
• Capacidade para instalar: é fácil instalar em outras plataformas?
• Capacidade para substituir: é fácil substituir por outro software?
• Conformidade: está de acordo com padrões e convenções de portabilidade?
10
 Qualidade x tipo de software

Cada tipo de software tem seu próprio requisito de qualidade, a importância de cada
característica depende diretamente do tipo de software por exemplo.

No exemplo acima, temos a importância que cada processo em cada sistema, cada um exige
mais do que o outro de acordo com seus requisitos, em uns mais itens em outros menos itens.
A figura abaixo mostra os diferentes pontos de vista das pessoas envolvidas no processo de
desenvolvimento de software.

Figura: Diferentes pontos de vista

Quais são os principais objetivos da qualidade?

• Aprimorar o processo de desenvolvimento e, em consequência, melhorar a qualidade do
produto resultante.

11
 Unidade: Motivação de Qualidade

• Avaliar a qualidade do produto, visando emitir documento oficial sobre a qualidade de um

software e sua conformidade em relação a uma norma ou padrão.
• Adquirir um software, com o intuito de escolher o produto mais adequado dentre um
conjunto de produtos selecionados.

Aprimoramento do processo de software

Algumas iniciativas visando melhorias do processo de software:
SEI/CMM (Capability Maturity Model), modelo desenvolvido pelo Instituto de Engenharia de
Software (SEI) da Universidade Carnegie-Mellon, EUA, visando dar às organizações diretrizes
sobre como aprimorar o processo.
ISO/SPICE (Software Process Improvement & Capability Determination), cujo objetivo é
gerar normas ISO/IEC para a avaliação de processos de software.
Norma ISO/IEC 12207, define um processo de ciclo de vida do software.
Norma ISO/IEC 9000-3, apresenta diretrizes para a aplicação da ISO 9001 (voltada para
indústria), por empresas que desenvolvem software, para o processo de desenvolvimento e
manutenção de software Avaliação da qualidade do produto.
Algumas normas:
ISO/IEC 9126 (NBR 13596), define as características de qualidade de software que devem
estar presentes em todos os produtos.
ISO/IEC 12119, estabelece os requisitos de qualidade para pacotes de software e instruções
para teste, considerando esses requisitos.
ISO/IEC 14598-5, define um processo de avaliação da qualidade de produto de software.

Avaliação da qualidade do produto

Como fazer?
- organismos de certificação:
• No Brasil, para fornecer o certificado ISO 9000, existem empresas credenciadas pelo
INMETRO.
- avaliar in-house:
• Utilizar equipe multidisciplinar com especialistas da área de tecnologia e especialistas da
área que se utilizará do software (ie, que vão olhar para o software a partir do ponto de
vista do cliente) ,grupo de Garantia da Qualidade do Software.

12
 - contratar empresas para avaliação:
• Existem empresas que fazem avaliação do software mas, por não serem credenciadas pelo
INMETRO, não emitem certificado oficial. São, no entanto, mais acessíveis e ágeis que os
organismos credenciados.

Alguns entraves à qualidade segundo o IEEE610.12-1990:

Erro(engano) Ação humana que produz um resultado incorreto. Mistake

Incorreção em um passo, processo ou definição de dados;
Falha manifestação no software de um engano cometido pelo Fault (bug)
desenvolvedor.
Diferença entre o valor obtido e o valor esperado, ou
Erro seja, qualquer estado intermediário incorreto ou resultado Error
inesperado na execução do software.
Defeito Incapacidade de fornecer o serviço, conforme especificado. Failure

Por que surgem as falhas?

Alterações:
• Alterações degradam a estrutura do software, tornando-o cada vez mais difícil de alterar.

Tempo:
• Com o tempo, os custos das implementações das alterações aumentam, e a capacidade do
sistema em prestar os serviços esperados diminui.

Complexidade:
• difícil de desenvolver: um único desenvolvedor não é capaz de entender o sistema
como um todo;
• difícil de usar;
• difícil de entender: código incompreensível, falta de documentação.

Garantia da Qualidade do Software

Definição de um arcabouço para se atingir a qualidade do produto de software
[Sommerville01, 24.1]
Padrão sistemático e planejado de ações que são exigidas para garantir a qualidade do
software. [Pressman92, 17.1.2]
Visa responder às seguintes questões:
• O software atende às características de qualidade desejadas ?

13
 Unidade: Motivação de Qualidade

• O desenvolvimento do software foi conduzido conforme os padrões preestabelecidos ?

• As disciplinas técnicas cumpriram adequadamente seus papéis como parte da atividade de
Garantia da Qualidade?

Norma ISO/IEC 14598 pode ser usada para definir o processo de Avaliação.

Atividades da Garantia de Qualidade segundo Pressman

Aplicação de métodos, técnicas e ferramentas, uso pelos desenvolvedores de métodos e
ferramentas que ajudem a conseguir especificações, projetos, etc., de maior qualidade.
Realização de revisões técnicas, o objetivo é avaliar a qualidade do artefato de software
(especificação, projeto, ...) produzido ao longo do desenvolvimento.
Atividades de testes em complemento às revisões e outras técnicas.
Aplicação de padrões
• padrões podem ser usados: para documentos, documentação do código e estilo de
codificação (como usar linguagem de programação).
• padrões podem ser determinados pelo cliente, por normas internacionais ou pela empresa
de desenvolvimento.

Atividades de Garantia de Qualidade

Controle de alterações, toda mudança no software tem potencial para introduzir erros ou
criar efeitos colaterais, que propagam erros no controle de mudanças durante desenvolvimento
e manutenção, sendo essencial para garantir a qualidade do software.
Medição, obtenção de métricas a fim de rastrear a qualidade do software e avaliar o impacto
de mudanças nos métodos e procedimentos usados para desenvolvimento e manutenção.
Anotação e manutenção de registros para manter histórico com resultados de revisões,
auditorias, controle de alterações e outras atividades de garantia de qualidade, que devem ser
levados ao conhecimento dos desenvolvedores.
Com isso, conseguimos ter uma noção de qualidade e chegar a uma conclusão de qualidade
de software que devido ao aumento da competitividade e a preocupação em oferecer ao
mercado softwares que atendam às expectativas de seus clientes, os desenvolvedores de
software têm buscado aplicar os conceitos de qualidade em seus produtos. Dada a história e os
fatos mencionados, notamos que, nos dias de hoje, a qualidade dos softwares desenvolvidos
devem aumentar significativamente. Algumas certificações existentes no mercado têm dado
uma atenção especial nos processos de qualidade e mobilizado as organizações a adotarem
este tipo de processo em todos seus produtos. Espera-se que as organizações comecem a incluir
em seu processo de desenvolvimento, o processo de qualidade de software, não apenas no
momento que o produto foi finalizado ou desenvolvido, mas desde o início de sua concepção,
para não ser surpreendido com a possibilidade de ocorrerem falhas no ciclo de vida do software.

14
Material Complementar

Para aprofundar seus estudos sobre Qualidade, temos abaixo os sites e as seguintes referências:
• [Link]
• [Link]
• [Link]
• [Link]
• GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado
a objetivos. Porto Alegre: Bookman, 2000.
• SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-
Wesley, 2007.

15
 Unidade: Motivação de Qualidade

Referências

J. McCall, P. Richards and G. Walters. Factors in Software Quality (3 vols.), NTIS AD-
AO49-014, 015, 055, Nov. 1977.

[Link]. Software Engineering, A Practicioners Approach, McGraw-Hill.

Steven R. Rakitin. “Software Verification and Validation: a Practitioner’s Guide”.

Artech House, 1997.

Nelma S. Gomes. “Qualidade de Software - Uma Necessidade”. Artigo obtido em fev/2003

em: [Link]/cst/arquivos/Qualidade_de_Soft.pdf

PRESSMAN, Roger S. Engenharia de software. 6ª ed. Porto Alegre: Bookman, 2006.

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a

objetivos. Porto Alegre: Bookman, 2000.

SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-Wesley,

2007.

RESENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3ª Ed. Rio

de Janeiro: Brasport, 2005.

FILHO, Wilson de Pádua Paula. Engenharia de software: fundamentos, métodos e

padrões. 3ª ed. Rio de Janeiro: LTC, 2005.

FERNANDES, Aguinaldo Aragon.

[Link]
(22/07/2010, 17:35h)

[SEI2000] Sei, An Overview of Capability Maturity Model Integration (CMMI) – Version

1.0, Tutorial presented at SIMPROS 2000 [23], 2000.

[SEI2002a] Sei, Web Site do software Engineering Institute – SEI, [Link]

edu/ (CMMI nodels available at [Link]/cmmm).

[ISO9001:2000] International Standard Organization Certification for IMS Company.

[ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement:

Information Technology – Amendement to ISO/IEC 12207, versão PDAM 3, novembro 2000.

16
Anotações

17
[Link]
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000
Qualidade de
Software
 Material Teórico
CMM - Capability Maturity Model (Modelo de Maturidade
em Capacitação)

Responsável pelo Conteúdo:

Prof. Ms. Douglas Almendro

Revisão Textual:
Profa. Ms. Selma Aparecida Cesarin.
 CMM - Capability Maturity Model
(Modelo de Maturidade em Capacitação)

• Introdução

• CMM

• Níveis do CMM

• Chaves do Processo de Produção

• Entendendo os níveis de maturidade

• Métricas de Qualidade de Software

• Sistemas de Gerenciamento de Qualidade

·· Nesta Unidade, será explanado o conceito de CMM. Este

passo nos levará ao entendimento da certificação dada ao
software e que é utilizada no mercado. Então, não perca
nenhum detalhe dessa Unidade.

Estamos em nossos estudos sobre CMM. A ideia principal é mostrar a descrição deste modelo
de maturidade e os principais elementos de um processo de desenvolvimento de software.
Veremos os estágios de maturidade por que passam as organizações enquanto evoluem no
seu ciclo de desenvolvimento de software, por meio de avaliação contínua, identificação de
problemas e ações corretivas.
Este caminho de melhoria é definido por cinco níveis de maturidade, que estudaremos em
nossas aulas.

5
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

Contextualização

O CMM fornece às organizações uma orientação sobre como adquirir controle do processo de
desenvolvimento de software e como avançar para uma cultura padrão na gestão de software.
O objetivo principal é acompanhar, por meio dos níveis de maturidade, a realização de um
processo controlado e mensurado que tem como fundamento a melhoria contínua.
A cada nível de maturidade corresponde um conjunto de práticas de software e de gestão
específicas, denominadas áreas-chave do processo (KPAs – Key Process Areas).
Por este estudo, teremos uma boa visão, principalmente sobre como melhor gerir os processos
de desenvolvimento de software.

6
 Introdução
Já temos em mente o que vem a ser qualidade, mas, para reforçarmos o conceito, observe
como o dicionário Aurélio define qualidade: “propriedade, atributo ou condição das coisas ou
das pessoas capaz de distingui-las das outras e de lhes determinar a natureza” (Aurélio, 1986).
Como um atributo de um item, a qualidade se refere àquilo que pode ser medido, ou
seja, comparado com padrões conhecidos, tais como tamanho, cor, propriedades elétricas,
maleabilidade etc.
Entretanto, é mais difícil categorizarmos qualidade em software, que é uma entidade
intelectual, do que em objetos físicos.
Vamos começar a nossa Unidade explicando a que nos referimos quando falamos de
qualidade de software, principalmente no quesito de processos.

Mas o que seria processo?

Conjunto de atos por que se realiza uma operação qualquer (química, farmacêutica, industrial
etc.): um processo de fabricação de nitroglicerina. / Sequência contínua de fatos que apresentam
certa unidade, ou que se reproduzem com certa regularidade; andamento, desenvolvimento: o
processo de uma crise econômica (Aurélio, 1986).
Para a engenharia de software, seria um conjunto de passos de procedimentos parcialmente
ordenados, relacionados a artefatos, pessoas, recursos, estruturas organizacionais e restrições,
tendo como objetivo produzir e manter o produto de software requisitado.
O CMM ajuda a apontar quais são os procedimentos a serem exigidos para que tenhamos
excelência na atividade.

CMM
Vamos falar, agora, sobre o CMM.
O CMM surgiu durante a década de 1980, como um modelo para avaliação de risco na contratação
de empresas de software pelo Departamento de Defesa dos Estados Unidos, que desejava ser capaz
de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações
como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados.
Para desenvolver esse processo, o DOD constituiu, junto a Carnegie-Mellon University, o SEI
(Software Engineering Institute), que, além de ser responsável pela evolução da família CMM,
também realiza diversas outras pesquisas em engenharia de software.
Observe os dados cronológicos:
• 1986 – início do desenvolvimento de um modelo de maturidade de processo, para ajudar as
organizações a melhorarem seus processos de software (por solicitação do governo federal);

7
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

• Junho 1987 – liberação de breve descrição do modelo de maturidade de processo de software;

• Setembro 1987 – versão preliminar do questionário de maturidade 1991 – 1ª. versão
do CMM (Versão 1.0);
• 1993 – depois de 5 anos de experiência, o modelo de maturidade evoluiu para um modelo
completamente definido, usando conhecimento adquirido das avaliações de processo de
software e de extensivo retorno das indústrias e do governo CMM – Capability Maturity
Model for Software (atualmente usada).
Premissa básica que está por baixo do trabalho do SEI sobre maturidade de processo é “A
qualidade de um software produto é profundamente determinada pela qualidade do processo
de desenvolvimento e de manutenção usado para construí-lo”.
O SEI desenvolveu um modelo de 5 níveis que orienta uma organização em como
“amadurecer” seus processos de software.
O modelo descreve um caminho evolucionário, que vai de um processo indisciplinado para
um processo disciplinado.
Sem a disciplina descrita no modelo, programas de melhoria podem mostrar-se ineficientes porque
os fundamentos necessários para apoiar os melhoramentos sucessivos não foram estabelecidos.
Os 5 níveis de maturidade descrevem fundamentos sucessivos para melhoria contínua do
processo e definem uma escala ordinal para medir a maturidade de processo de uma organização.
As vantagens dos níveis de maturidade é que eles fornecem prioridades claras, que
orientam a seleção de algumas atividades de melhoramento que serão muito úteis, se
implementadas imediatamente.
Isso é importante porque a maioria das organizações podem focalizar somente algumas
poucas atividades de melhoramento de cada vez.

8
 Níveis do CMM
O CMM fornece às organizações orientação sobre como ganhar controle do processo de
desenvolvimento de software e como evoluir para uma cultura de excelência na gestão de software.
O objetivo principal nas transições desses níveis de maturidade é a realização de um processo
controlado e mensurado como a fundação para melhoria contínua.
Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas,
denominadas áreas-chave do processo.
Estas devem ser implantadas para a organização atingir o nível de maturidade em questão.
O nível de maturidade é um estágio evolutivo bem definido, em busca de um processo
de software maduro. Cada nível de maturidade fornece uma gama de fundamentos para a
melhoria contínua do processo e um conjunto de práticas de software e gestão específicas,
denominado áreas-chave do processo, que devem ser implantadas para a organização atingir o
nível de maturidade em questão.
Cada nível compreende um conjunto de objetivos de processos que, quando satisfeitos,
estabilizam um componente importante do processo de software. Alcançando cada nível da
estrutura de maturidade, estabelecem-se diferentes componentes no processo, resultando em
um crescimento na capacidade processual da organização.
A maturidade do processo de software é a extensão para a qual um processo específico é
explicitamente definido, gerenciado, medido, controlado e efetivado. A maturidade representa
o potencial de crescimento e indica a riqueza do processo de software da organização e a
consistência com que o mesmo é aplicado em todos os seus projetos.
Em uma organização madura, o processo de software é bem compreendido – o que geralmente
é feito por meio de documentação e treinamento – e está sendo continuamente monitorado e
melhorado pelos seus usuários.
A atividade de um processo de software maduro é conhecida e implica que a produtividade e
a qualidade resultantes do processo possam ser continuamente melhoradas por meio de ganhos
consistentes na disciplina alcançada com a sua utilização.
Quando uma organização obtém ganhos na maturidade de um processo de software, ela o
institucionaliza por meio de políticas, padrões e estruturas organizacionais.
A institucionalização exige a construção de uma infraestrutura e de uma cultura corporativa
que possa dar suporte aos métodos, práticas e procedimentos de negócio, que perdurem após
possíveis afastamentos daqueles que originalmente os definiram.
Vamos ver o que possuem os níveis de maturidade do CMM.

Nível 1: Inicial
No nível 1 de maturidade, os processos normalmente são ad hoc e a organização geralmente
não dispõe de ambiente estável. O sucesso nestas organizações depende da competência e do
heroísmo dos funcionários e não do uso de processos estruturados. Devido ao imediatismo,
um ambiente caótico, o nível 1 de maturidade raramente produz um produto ou serviço que
funcione. Assim, frequentemente, eles excedem o orçamento e o prazo em seus projetos.
9
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

Nível 2: Repetível
No nível 2 de maturidade, o desenvolvimento do software é repetido. O processo pode não
se repetir para todos os projetos da organização, que pode usar ferramentas de Gerência de
Projetos para mapear os custos e o prazo do projeto.
A adoção de um processo de desenvolvimento ajuda a garantir que práticas existentes são
utilizadas em momentos de stress. Quando estas práticas são adotadas, os projetos decorrem e
são gerenciados de acordo com o planejamento inicial.

O status do projeto e os serviços entregues são visíveis ao gerenciamento (por exemplo: é

possível a visualização de marcos do projeto e o término da maioria das tarefas).

Técnicas de gerenciamento de projetos são estabelecidas para mapear custos, prazos e

funcionalidades. Um mínimo de disciplina nos processos é estabelecido para que se possa repetir
sucessos anteriores em projetos com escopo e aplicação similar. Ainda há um risco significante
de exceder os custos e estimativas de prazo de desenvolvimento.

Nível 3: Definido

A organização possui um conjunto de processos padrão, que são a base do nível 3 e estão
estabelecidos e melhorados periodicamente. Estes processos padrão são usados para estabelecer
uma consistência dentro da organização e os projetos estabelecem seus processos definidos pelo
conjunto de padrões processuais da organização.

O gerenciamento da organização estabelece os objetivos dos processos, baseado no

conjunto de padrões pré-definidos e garante que estes objetivos sejam encaminhados de
forma apropriada.

Uma crítica distinção entre os níveis 2 e 3 é o escopo dos padrões, descrição dos processos e
procedimentos. No nível 2, os padrões, descrições de processos e procedimentos podem ser bem
diferentes em cada instância específica do processo (por exemplo, em um projeto particular).
No nível 3, os padrões, descrições de processo e procedimentos para o projeto são guiados pelo
conjunto padrão de processos da organização.

Nível 4: Gerenciado

Utilizando métricas precisas, o gerenciamento pode efetivamente controlar os esforços para

desenvolvimento de software. Em particular, o gerenciamento pode identificar caminhos para
ajustar e adaptar o processo para projetos particulares, sem perda de métricas de qualidade ou
desvios das especificações.

Organizações neste nível conseguem metas quantitativas para o processo de desenvolvimento

de software e de manutenção.

10
 Nível 5: Otimizado

O nível de maturidade 5 foca no contínuo aumento do desempenho dos processos por

meio de melhorias de inovação tecnológica e incremental. Objetivos de melhoria quantitativa
dos processos para a organização são estabelecidos, continuamente revisados, refletindo os
objetivos da organização e usando critérios de gerência de processos.

Os efeitos da melhoria da revisão dos processos são medidos e acompanhados, utilizando-se

processos de melhoria de qualidade. Ambos – os processo definidos e o conjunto de processos
padrão da organização – são alvos de melhoria de métricas.

Chaves do Processo de Produção

Cada nível, com exceção do primeiro, é composto por áreas chave de processo. Essas áreas
são formadas por sessões, chamadas áreas comuns. As áreas comuns especificam as práticas
chave necessárias para se alcançar a principal meta da área chave do processo, que são uma
descrição do caminho que uma organização deve tomar para se tornar madura. Este caminho
foi baseado em anos de experiência, tanto no processo de produção, quanto no gerenciamento
do processo.

As áreas chaves de processo do nível repetível são definidas como :

»» Gerenciamento de requisitos: Os requisitos do sistema são controlados de forma

a estabelecer um perfil mínimo a ser utilizado pela engenharia de software e pela
administração. Os planos, produtos e atividades do software são sempre consistentes
com os requisitos de sistema;

»» Planejamento do Projeto: Estimativas relativas ao software são documentadas para

uso no planejamento e acompanhamento do projeto do software. As atividades de
projeto de software e compromissos assumidos são planejadas e documentadas;

»» Visão geral e acompanhamento do projeto: Resultados reais são acompanhados

de acordo com o planejamento do software. Quando os resultados apresentam um
significativo desvio do planejamento do software, são tomadas ações corretivas, que são
acompanhadas até o final do projeto. Mudanças nos compromissos assumidos são feitas
em comum acordo com os grupos e indivíduos afetados;

»» Gerenciamento de subcontratados: O contratante seleciona subcontratos qualificados.

Ele os subcontratados estão de acordo no que diz respeito aos compromissos assumidos
um com o outro e mantém uma comunicação constante. O contratante acompanha os
resultados reais do subcontratado, de acordo com os compromissos assumidos;

11
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

»» Garantia da qualidade do software: As atividades de garantia de qualidade de

software são planejadas. A conformidade dos produtos de software e atividades com os
padrões, procedimentos e requisitos é verificada objetivamente. Os grupos e indivíduos
afetados são informados das atividades de garantia de qualidade de software e de seus
resultados. Questões relacionadas a não conformidade que não são resolvidas dentro do
projeto de software são encaminhadas à gerência geral;

»» Gerenciamento de configuração: As atividades de gerenciamento de configuração

são planejadas. Os produtos de trabalho de software são identificados, controlados e
estão disponíveis. Mudanças nos produtos de trabalho identificados são controlados. Os
grupos e pessoas afetadas são informados da situação atual e projetada dos produtos de
trabalho de software.

As áreas chaves de processo do nível definido são definidas como:

»» Foco do processo organizacional: São coordenadas atividades de desenvolvimento e
melhoramento do processo de software em toda a organização. Os pontos fortes e fracos
do processo de desenvolvimento de software utilizado são identificados, de acordo com
um padrão de processo. São planejadas atividades de desenvolvimento e melhoramento
do processo em nível de organização;
»» Definição do processo organizacional: O processo padrão de desenvolvimento de
software da organização é desenvolvido e mantido. A informação relacionada ao uso do
processo padrão de desenvolvimento de software é coletada, revisada e disponibilizada;
»» Programa de treinamento: As atividades de treinamento são planejadas.
»» É fornecido treinamento para o desenvolvimento de habilidades e conhecimentos
necessários para realizar o gerenciamento do software e as funções técnicas, tanto para o
grupo de engenharia de software, quanto para outros relacionados ao desenvolvimento;
»» Gerenciamento de software integrado: O processo de software definido para o
projeto é uma versão adaptada do processo padrão de desenvolvimento de software da
organização. O projeto é planejado e gerenciado de acordo com este padrão;
»» Engenharia de produto de software: As atividades de engenharia de software são
definidas, integradas e consistentemente realizadas para produzir o software;
»» Coordenação intergrupos: Os grupos de engenharia identificam, acompanham e
resolvem todas as questões intergrupos. Todos os grupos de trabalho afetados concordam
com os requisitos do cliente e com os acordos entre os grupos de engenharia;
»» Revisão conjunta: Atividades de revisão conjunta são planejadas. Defeitos nos produtos
de trabalho são identificados e removidos.

As áreas chave de processo do nível gerenciado são definidas como:

»» Gerenciamento quantitativo dos processos: As atividades de gerenciamento
quantitativo dos processos são planejadas. O desempenho do processo de desenvolvimento
de software definido é controlada quantitativamente. A capacidade do processo de
desenvolvimento de software padrão da organização é conhecida em termos quantitativos;

12
 »» Gerenciamento da qualidade de software: As atividades de gerenciamento da
qualidade de software do projeto são planejadas. Objetivos mensuráveis da qualidade
do produto de software e suas prioridades são definidos.
»» O progresso real em direção à realização dos objetivos de qualidade para os produtos de
software é quantificado e gerenciado.

As áreas chave de processo do nível otimizado são definidas como:

»» Prevenção de defeitos: As atividades de prevenção de defeitos são planejadas. As
causas comuns de defeitos são procuradas, identificadas e sistematicamente eliminadas;
»» Gerenciamento de mudanças tecnológicas: A incorporação de mudanças
tecnológicas é planejada. Novas tecnologias são avaliadas para determinar seu efeito
na qualidade e na produtividade e as adequadas são incorporadas na prática normal de
toda a organização;
»» Gerenciamento de mudanças no processo: O melhoramento contínuo do processo
é planejado. Toda a organização participa das atividades de melhoramento do processo
de software. O padrão de processo de software da organização e os processos de software
de cada projeto definido são melhorados continuamente.

Entendendo os níveis de maturidade

O CMM é um modelo descritivo, no sentido de descrever atributos essenciais (ou chave) que
seriam esperados para caracterizar uma organização em um nível particular de maturidade.
É um modelo normativo, no sentido de que as práticas detalhadas caracterizam os tipos
normais de comportamento que seriam esperados em uma organização que desenvolve projetos
em larga escala num contexto de contratação governamental.
A intenção é que o CMM tenha um nível suficiente de abstração que não restrinja
desnecessariamente a maneira que o processo de software é implementado pela organização;
ele simplesmente descreve o que normalmente seria esperado dos atributos essenciais do
processo de software.
Em qualquer contexto em que o CMM for aplicado, deveria ser utilizada uma interpretação
razoável das práticas. O CMM deve ser interpretado apropriadamente, utilizando-se o
conhecimento de peritos quando o ambiente comercial da organização difere significativamente
de uma grande organização fornecedora.
O CMM não é prescritivo; ele não diz à organização como melhorar. O CMM descreve a
organização em cada nível de maturidade sem prescrever os meios específicos para consegui-lo.
Pode levar vários anos para se passar do Nível 1 para o Nível 2; a movimentação entre os outros
níveis geralmente levará cerca de dois anos.

13
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

A melhoria de processo de software ocorre dentro do contexto dos planos estratégicos e dos
objetivos de negócio da organização, da sua estrutura organizacional, das tecnologias em uso,
da sua cultura social e sistema de gestão.
O CMM está voltado para os aspectos de processo da Gestão da Qualidade Total; a
melhoria de processo bem sucedida implica que os aspectos fora do escopo de processo de
software também sejam encaminhados (por exemplo: as questões pessoais envolvidas nas
mudanças da cultura organizacional que possibilitem a implementação e a institucionalização
das melhorias de processo).

O que o CMM não cobre

O CMM não é uma bala de prata [BROOKS, 1987] e não trata todos os assuntos que são
importantes para o sucesso dos projetos. Por exemplo, o CMM não indica peritos em domínios
específicos de aplicações, não defende tecnologias específicas de software, nem sugere como
selecionar, contratar, motivar e reter pessoas competentes.
Apesar de esses assuntos serem cruciais para o sucesso do projeto, alguns deles têm sido analisados
em outros contextos [CURTIS, 1990]. Entretanto, eles não têm sido integrados ao CMM.
O CMM foi especificamente desenvolvido para prover uma estrutura ordenada e disciplinada
dentro da qual possa se encaminhar assuntos de processo de gestão e desenvolvimento de software.

Métricas de Qualidade de Software

Um elemento chave de qualquer processo de engenharia é a medição. Nós usamos medidas

para melhor entendermos os atributos dos modelos que criamos e, o mais importante, é que
nós usamos medidas para avaliarmos a qualidade dos produtos de engenharia ou sistemas que
nós construímos.
Ao contrário de outras engenharias, a engenharia de software não é baseada em leis
quantitativas básicas, medidas absolutas não são comuns no mundo do software.
Ao invés disso, nós tentamos derivar um conjunto de medidas indiretas que levam a métricas
que fornecem uma indicação de qualidade de alguma representação do software.
Embora as métricas para software não sejam absolutas, elas fornecem uma maneira de
avaliar qualidade por meio de um conjunto de regras definidas.

Garantia de qualidade de software (SQA)

Um dos desafios críticos para qualquer programa de qualidade é tornar possível que qualquer
pessoa possa fazer revisões no trabalho de pessoas experientes.

14
 Gerentes querem os melhores projetistas para projetar o produto, então, em geral, SQA não
pode tê-los. A necessidade é concentrar esforços em métodos de SQA que permitam que o
desenvolvimento possa ser revisado por pessoas que não são desenvolvedores.
O papel de SQA é monitorar os métodos e os padrões que os engenheiros de software
usam e verificar se eles estão usando apropriadamente seus conhecimentos. Pessoas podem ser
experientes em SQA sem, no entanto, serem experientes em projeto de software.

Atividades de garantia de qualidade de Software

Em SQA, temos uma variedade de tarefas, que podem se dividir em dois grandes grupos:
os engenheiros de software, que fazem o trabalho técnico, e o grupo de SQA, que tem
responsabilidades no plano de qualidade, na inspeção, na conservação de registros históricos,
na análise e no reporting das atividades de SQA para o gerente do projeto.
Os engenheiros de software buscam qualidade de software, aplicando sólidos métodos e
medidas, conduzindo revisões técnicas formais e realizando testes de software bem planejados.
O papel do grupo de SQA é ajudar o time de engenharia de software a alcançar um produto
de alta qualidade.
O Instituto de Engenharia de Software (SEI) recomenda as seguintes atividades a serem
realizadas por um grupo de SQA:

»» Preparar um plano de SQA para o projeto. O plano é desenvolvido durante o planejamento

do projeto e é revisado por todas as partes interessadas;

»» Participar do desenvolvimento da descrição do processo do projeto do software. O time

de engenharia de software seleciona um processo para o trabalho a ser realizado. O grupo
de SQA revisa a descrição do processo, verificando se ele está de acordo com a política
organizacional, os padrões internos para o software, os padrões impostos externamente
e outras partes do plano de projeto de software;

»» Revisar as atividades dos engenheiros de software para verificar se o processo de software

definido está sendo seguido. O grupo de SQA identifica, documenta e trilha os desvios do
processo e verifica quais correções devem ser realizadas;

»» Garantir que os desvios no trabalho do software e nos produtos do trabalho são

documentados e mantidos de acordo com o procedimento documentado;

»» Registrar qualquer discordância e reportar para o gerente.

Além dessas atividades, o grupo de SQA coordena o controle e o gerenciamento de mudanças

e ajuda a coletar e analisar métricas de software.

15
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

Sistemas de Gerenciamento de Qualidade

Personal Software Process (PSP)

O estímulo original para desenvolver o PSP surgiu de questões sobre o Capability Maturity
Model (CMM). Muitos viam o CMM como projetado para grandes organizações e não entendiam
como ele poderia ser aplicado a trabalhos individuais e em times pequenos de projeto.
Apesar do CMM poder ser aplicado para ambas, pequenas e grandes organizações, uma
orientação mais específica se tornava claramente necessária.
Após alguns anos de pesquisa, 12 das 18 áreas chave de processo do CMM foram adaptadas
para o trabalho de engenheiros de software individuais.
O principal objetivo do PSP é fazer com que os engenheiros de software fiquem atentos no
processo que eles usam para fazer seus trabalhos e estejam sempre verificando suas performances
no processo.
Engenheiros de software são treinados individualmente para um conjunto de objetivos
pessoais, definindo os métodos a serem usados, medindo seus trabalhos, analisando os
resultados, e ajustando os métodos para atingir seus objetivos.
O PSP é uma estratégia para o desenvolvimento pessoal com o objetivo de aumento de produtividade.
Trabalhos experimentais foram iniciados em algumas corporações para verificar como
engenheiros experientes poderiam reagir ao PSP e explorar a introdução de seus métodos. Foi
verificado que os engenheiros de software geralmente são atraídos pela estratégia do PSP e
encontram métodos que ajudam em seus trabalhos. Nas palavras de um engenheiro: “Isto não é
para a empresa, é para mim”. O leitor interessado pode obter informações adicionais em [SEI] .

O PSP aplica princípios de processo para o trabalho do engenheiro de software por:

»» Fornecer um padrão de processo pessoal definido;
»» Introduzir uma família de medidas de processo;
»» Usar essas medidas para trilhar e avaliar o desempenho;
»» Se esforçar para obter critérios de qualidade e melhorar os objetivos.

Usando o PSP, engenheiros:

»» Desenvolvem um plano para todo o projeto;
»» Registram seu tempo de desenvolvimento;
»» Trilham seus defeitos;
»» Mantêm dados de um projeto em relatórios resumidos;
»» Usam esses dados para planos de projetos futuros;
»» Analisam dados que envolvem seus processos a fim de aumentar suas performances.

16
Visão crítica sobre controle de qualidade de software
O grande problema no controle de qualidade de software é ainda a falta de consciência de
muitas empresas e profissionais que lidam com sistemas complexos em adotarem uma política
de qualidade nos trabalhos a serem desenvolvidos.
Como prova disso, uma pesquisa realizada em 1995 pelo Subprograma Setorial da Qualidade
e Produtividade em Software (SSQP/SW), no qual foi indicado que [CESAR97]:
»» Apenas 38,9% das empresas incluem sistematicamente metas ou diretrizes para qualidade
em seus planos;
»» 25,1% delas coletam sistematicamente indicadores de qualidade de seus produtos e serviços;
»» Apenas 11,5% têm um programa de qualidade total implantado;
»» A grande maioria (85,9%) não conhece o modelo CMM;
»» 66,6% não adota nenhum procedimento específico de garantia da qualidade do produto
de software;
»» A avaliação de desempenho dos funcionários é feita periodicamente em apenas 16,4%
das empresas; 54,1% delas disseram fazê-la informalmente.

O importante não é o modelo a ser seguido. Quando o objetivo é otimizar a qualidade do software,
deve-se ter cuidado, porém, em definir certos limites para os resultados a serem alcançados.
A criação de software com qualidade requer um esforço tanto no nível financeiro quanto no
nível de conscientização das pessoas envolvidas no processo, sem, no entanto, sairmos da órbita
em que o cliente é o termômetro da qualidade de um determinado produto.
Mesmo se o produto (software) alcançar grande parte dos requisitos de qualidade, mas
ultrapassar uma data que seja de vital importância para o cliente, o produto não terá qualquer
serventia e, por isso, deve-se ter compromisso com prazos e outras coisas mais e, em certos
casos, é desejável restringir o escopo da qualidade (partindo do máximo da qualidade para uma
qualidade muito boa) a ser atingida, a fim de satisfazer as necessidades do cliente.
Esta é uma visão realística de encarar a qualidade de software nos sistemas a serem desenvolvidos.

17
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

Material Complementar

Para aprofundar seus estudos sobre CMM, consulte os sites e as seguintes referências:

99 [Link]
99 [Link]
99 [Link]

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a objetivos.

Porto Alegre: Bookman, 2000.
SOMMERVILLE, Ian. Engenharia de software. [Link]. São Paulo: Pearson Addison-
Wesley, 2007.

18
 Referências

FERNANDES, Aguinaldo Aragon. [Link]

redepro_palestra_1.pdf. Acesso em: 22 jul. 2010.

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a objetivos.

Porto Alegre: Bookman, 2000.

GOMES, Nelma S. Qualidade de Software - Uma Necessidade. Artigo obtido em fev.

2003 em: [Link]/cst/arquivos/Qualidade_de_Soft.pdf.

MCCALL J.; RICHARDS P.; WALTERS, G. Factors in Software Quality (3 vols.), NTIS AD-
AO49-014, 015, 055, Nov. 1977.

PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e padrões.

[Link]. Rio de Janeiro: LTC, 2005.

PRESSMAN, Roger S. Engenharia de software. [Link]. Porto Alegre: Bookman, 2006.

_______. Software Engineering, A Practicioners Approach, McGraw-Hill.

RAKITIN, Steven R. Software Verification and Validation: a Practitioner’s Guide. Artech

House, 1997.

RESENDE, Denis Alcides. Engenharia de software e sistemas de informação. [Link]. Rio

de Janeiro: Brasport, 2005.

SOMMERVILLE, Ian. Engenharia de software. [Link]. São Paulo: Pearson Addison-Wesley, 2007.

[SEI2000] Sei, An Overview of Capability Maturity Model Integration (CMMI) – Version

1.0, Tutorial presented at SIMPROS 2000 [23], 2000.

[SEI2002a] Sei, Web Site do software Engineering Institute – SEI, [Link]

edu/ (CMMI Models available at [Link]/cmmm).

[ISO9001:2000] International Standard Organization Certification for IMS Company.

[ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement:

Information Technology – Amendement to ISO/IEC 12207, versão PDAM 3, novembro 2000.

19
 Unidade: CMM - Capability Maturity Model (Modelo de Maturidade em Capacitação)

Anotações

20
[Link]
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000
Qualidade de
Software
 Material Teórico
Capability Maturity Model – Integration (CMMI) (Modelo de
Maturidade em Capacitação – Integração)

Responsável pelo Conteúdo:

Prof. Ms. Douglas Almendro

Revisão Textual:
Prof. Ms. Luciano Vieira Francisco
 Capability Maturity Model – Integration
(CMMI) (Modelo de Maturidade em
Capacitação – Integração)

• Introdução

• CMMI-DEV

• A representação contínua

• Áreas de processo

Nesta Unidade será explanado o conceito de CMMI, passo que

lhe levará ao entendimento da certificação dadas aos softwares
e que é utilizada no mercado, então fique atento(a) a todos os
detalhes desta Unidade.
A mesma atenção vale aos exemplos e às atividades propostas,
bem como aos respectivos prazos de entrega.

A ideia principal é mostrar a descrição desse modelo de maturidade de integração. Nesta

Unidade você verá os estágios de maturidade pelos quais passam as organizações enquanto
evoluem em seus ciclos de desenvolvimento de software, através de avaliação contínua,
identificação de problemas e ações corretivas. Este caminho de melhoria é definido por
níveis de maturidade, que estudaremos em nossas aulas.

5
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Contextualização

Os processos e o desenvolvimento de soluções com engenharia de software são o foco

do CMMI. Dada sua estrutura e abrangência, pode-se até dizer que o CMMI “poderia” ser
utilizado para outros negócios que não “software”. Ou seja, inúmeras de suas práticas podem
ser empregadas em projetos de construção civil, administração, marketing e diversos outros.
O CMMI colabora na organização e aprimoramento de processos, tornando-os mais maduros
e eficientes. Os modelos de capacidade e maturidade atingidos em seus níveis ajudam a prever
o comportamento de determinado processo diante do cenário ao qual o projeto se encontra.
Em resumo, torna-se possível saber se o projeto vai ou não dar certo.

6
 Introdução

Há anos se tornou vital fazer software com qualidade em um curto prazo de tempo. Com isso
empresas adotam medidas voltando-se para a redução de custos, qualidade e diminuição de defeitos
do produto final, satisfação dos envolvidos da equipe, usuários e clientes. Essas medidas utilizadas
têm como principal objetivo diminuir os riscos e os possíveis fracassos de um projeto.
O modelo Capatibility Maturity Model – Integration (CMMI), em português Modelo
de Maturidade em Capacitação – Integração, criado pelo Software Enginering Institute (SEI),
em português Instituto de Engenharia de Software, como inúmeros outros modelos utilizados,
é uma forte ferramenta para o planejamento e gerenciamento de aquisições, desenvolvimento,
manutenção e suporte do produto.
Esse modelo tem como missão auxiliar empresas e organizações na prestação de serviços,
aquisições e, principalmente, no desenvolvimento de produtos, visando a melhoria de seus
processos internos, considerando desde os processos que são extremamente imprevisíveis e
futuramente podem acarretar no fracasso do projeto, e modificando-os para que se tornem
processos bem estabelecidos e seguros, garantindo assim o sucesso do projeto.
Ao longo do tempo foram realizados ajustes no modelo CMMI. Em 27 de outubro de 2010
foi lançada a versão atual do CMMI (versão 1.3), que possui três modelos:
»» CMMI para Desenvolvimento (CMMI-DEV);
»» CMMI para Aquisição (CMMI-ACQ);
»» CMMI para Serviços (CMMI-SVC).

CMMI-DEV
O CMMI para desenvolvimento tem a missão de melhorar processos que são destinados à
elaboração de produtos e serviços. É composto pelas melhores práticas de desenvolvimento e
manutenção do produto final.
O modelo CMMI-DEV possui características de Engenharia de Sistemas, Engenharia de Software,
Gestão de Projetos, entre outras áreas, além disso, é amplamente utilizado nos setores bancários,
hardware de computadores, softwares e indústria automobilística, para citar alguns exemplos.

CMMI-ACQ
Neste modelo de CMMI para aquisição o enfoque esta em atividades correlacionadas à
prestação de serviços conjuntamente à aquisição de desenvolvimento de produtos.
Este modelo contém práticas de Gestão de Projetos, Gestão de Processos e Engenharia de
Aquisição, onde é utilizado na aquisição e gestão de fornecedores.
7
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Empresas dos setores aeroespacial, software, defesa, entre outras são o público-alvo desse
tipo de modelo.

CMMI-SVC
Este modelo é aplicado em atividades de gestão e também prestação de serviços. Nesse estão
contidas práticas de Gestão de Serviços, Gestão de Projetos, entre outras áreas.
Organizações relacionadas à educação, saúde, hotelaria e telecomunicações são as principais
usuárias desse modelo.
O CMMI é uma evolução de diversos outros modelos, comumente explicado em dois tipos
de representações:
»» A primeira é a representação contínua, a qual é similar à norma onde se define o
processo de desenvolvimento de software chamada ISO/IEC 15504, onde é separada
por níveis de capacidade para cada processo. O modelo CMMI não foi criado a partir
da norma ISO/IEC 15504, porém, são dados como modelos compatíveis;
»» A segunda é a representação por estágios, onde se define um caminho para o
aperfeiçoamento da organização, dividida em áreas e descrita em cinco diferentes
níveis de maturidade.

A representação contínua
Na representação contínua a empresa tem a liberdade de escolha para aplicar os processos
de acordo com suas necessidades e os objetivos que pretende alcançar, possibilitando processos
com diferentes níveis. É adequado usar a representação contínua quando a empresa quer
converter apenas alguns processos, tornando-os mais maduros.
Essa representação é dividida em seis níveis, os quais são chamados de incompleto; realizado
(ou executado); gerenciado; definido; gerenciado quantitativamente; otimizado.
Figura 1 – Níveis da representação contínua.

Fonte: Falbo (2008).

8
 Especificando-os, temos:
»» Nível 0: Incompleto – esse nível retrata um processo que comumente não é executado,
ou é executado parcialmente;
»» Nível 1: Realizado (ou executado) – o processo deve ser executado com o objetivo
de completar as tarefas necessárias para a execução de um processo;
»» Nível 2: Gerenciado – é o planejamento da execução dos processos, onde a equipe do
projeto faz a comparação do que foi planejado com o que foi efetivamente executado;
»» Nível 3: Definido – é construído tomando a direção do processo que já existe, porém
é sustentada uma descrição do processo;
»» Nível 4: Gerenciado quantitativamente – o processo é gerenciado quantitativamente
por estudos estatísticos;
»» Nível 5: Otimizado – este nível é adaptado para que as necessidades da
organização sejam plenamente supridas através da alteração e adaptação do
processo gerenciado quantitativamente.

A representação por Estágios

Nesta representação a sequência é predeterminada e deve ser seguida rigorosamente, pois
cada estágio depende diretamente do anterior. Divida em cinco níveis de maturidade, pode ser
assim esquematizada:

Figura 2 – Níveis da representação por estágios.

Fonte: O QUE É CMMI? ([20--]).

Nível 1 – inicial:
O nível inicial pode ser facilmente considerado como um estágio caótico e talvez o mais
complexo do projeto, onde os processos são mal definidos e os funcionários acabam dedicando
mais tempo na correção das atividades realizadas.
Nessa fase inicial é necessário que os profissionais se empenhem e deem o máximo de si,
pois o que salvará o projeto e dará um empurrão inicial será a união dos esforços individuais.

9
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Essa fase cobra redobrada atenção às possíveis situações:

»» Deficiências no planejamento;
»» Cronogramas impossíveis de cumprimento;
»» Documentação pouco confiável;
»» Ausência de controle de requisitos e avaliação do cliente.

O processo de software é tratado como uma caixa preta, pois nesse momento apenas é
possível visualizar as entradas e os produtos finais, de modo que todo o trâmite nesse ínterim
fica impossibilitado de ser visualizado.

Figura 3 – Processo de software segundo o nível 1.

Fonte: Falbo (2008).

Nível 2 – Gerenciado:
Nesta etapa são discutidos e estabelecidos os processos básicos do gerenciamento do projeto,
como planejamento de custos, aquisições e prazos. Na maioria dos casos a organização é disciplinada,
porém, por certas resistências pode ocorrer resistência para a implantação de mudanças.
Em inúmeros casos usar projetos que obtiveram sucesso no passado é uma grande ideia,
levando ao bom encaminhamento e término seguro do projeto.
O processo é visto como diversas caixas pretas interligadas, possibilitando a visualização em
alguns pontos. Esses pontos são chamados de marcos do projeto.
O avanço do projeto é controlado mediante a evolução dos requisitos. A cada marco realizado
são aplicadas avaliações onde o progresso e a construção do software são notados e ponderados.

Figura 4 – Processo de software segundo o nível 2.

Fonte: Falbo (2008).

Nível 3 – Definido:
Todas as atividades de um processo padrão de software (ligadas a gerenciamento ou
engenharia de software) passam pelas etapas de documentação, padronização e integração.
No desenvolvimento e na manutenção do software são utilizadas versões aprovadas ou
adaptadas desses processos, onde são enquadradas para os requerimentos e características do
projeto em desenvolvimento.

10
 Nesta etapa as funções de cada envolvido no projeto estão bem definidas e claras. Com
isso, a organização utilizará processos estabelecidos e padronizados. Assim, a porcentagem de
sucesso do projeto é aumentada significativamente e os riscos diminuem, pois a saída de um
membro da equipe, por exemplo, pode ser facilmente suprida, dado que existem planos de
riscos definidos e o impacto de qualquer imprevisto ocorrido se torna mínimo.
Figura 5 – Processo de software segundo o nível 3.

Fonte: Falbo (2008).

Nível 4 – Gerenciado quantitativamente (removido da versão 1.3):

Nesta fase são realizados relatórios estatísticos onde são visualizados os detalhes das métricas
utilizadas no processo de software. A partir disso são estudados tanto o processo como o produto
de software, onde são quantitativamente avaliados e controlados.
A qualidade é realizada por um grupo que é apenas alocado para esse tipo de tarefa, onde
rotineiramente analisam a qualidade e aprimoram o software.

Figura 6 – Processo de software segundo o nível 4.

Fonte: Falbo (2008).

Nível 6 – Otimização (removido da versão 1.3):

O contínuo aperfeiçoamento do processo é estabelecido através de sua avaliação quantitativa
e também pela implantação de tecnologias e ideias inovadoras.
Nesta etapa os processos estão bem definidos e a compreensão sobre esses ultrapassa os processos
praticados, tornando facilmente compreensíveis os efeitos causados em qualquer possível alteração.
Além disso, as tecnologias e melhorias são implantadas como parte de rotinas diárias.
Figura 7 – Processo de software segundo o nível 5.

Fonte: Falbo (2008).

11
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Nesse tipo de representação a maturidade organizacional é medida pelo conjunto inteiro de

seus processos. Assim, a empresa necessita que todos seus processos sejam classificados como
nível 2 para que a instituição seja certificada como uma empresa nível 2.
Com isso, pode-se supor que uma empresa possui 22 processos, onde 21 são classificados
como nível 4 e o processo restante é classificado como nível 3. Com tal cenário essa empresa
não poderá ser certificada como nível 4 de maturidade, pois só poderá ser classificada como tal
se todos os seus processos atingirem o nível 4.
A utilização do modelo por estágio é realizada quando a empresa já faz uso de algum
outro modelo de maturidade por estágios. Instituições empresariais fazem uso desse tipo de
representação quando têm a pretensão de alcançar certo nível de maturidade para poderem ser
comparadas com outras empresas do ramo, ou quando pretendem trazer a experiência e o nível
de conhecimento ganhos por outras empresas, para então utilizar em suas áreas de aplicação.

Áreas de processo

O modelo CMMI versão 1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação
por estágios, as áreas são divididas da seguinte forma:

Nível 1 – Inicial:
Não possui áreas de processo.

Nível 2 – Gerenciado:
»» Gerenciamento de requisitos – processo onde são identificadas inconsistências dos
requisitos e dos produtos de trabalho, onde deve-se realizar a gestão desses;
»» Planejamento de projeto – criar e concretizar planos específicos para aplicação nos projetos;
»» Acompanhamento e controle de projeto – para o gerenciamento eficaz é preciso
providenciar informações suficientes;
»» Gerenciamento de acordo com fornecedores – fase onde são realizadas negociações
de acordos de produtos, fornecedores e também toda a gestão das aquisições;
»» Medição de análise – são realizadas medições e, a partir dessas, são executados
estudos para a verificação de desvios ou variações fora do planejamento;
»» Garantia da qualidade de processo e produto – processo onde é realizada a
verificação da garantia do projeto, visando garantir se o produto possui os requisitos e
qualidade desejados;
»» Gerência de configuração – processo onde é mantida a integridade dos produtos
do projeto.

12
Nível 3 – Definido:
»» Desenvolvimento de requisitos – fase onde é realizada a análise e o desenvolvimento
dos requisitos para a composição do produto;
»» Solução técnica – processo onde é desenvolvido e implementado o conjunto de
soluções para os requisitos apontados;
»» Integração de produto – para garantir a entrega do produto, nesta etapa é realizada
a junção de componentes, funções, módulos e outros produtos;
»» Verificação – processo onde é avaliado se o desenvolvimento do produto é
realizado corretamente;
»» Validação – realização da demonstração do produto no ambiente definido,
demonstrando se esse possui todas as especificações e requisitos definidos;
»» Foco de processo organizacional – realização de estudo para a verificação das
deficiências que os processos e a organização possuem, seguido de um planejamento e
implantação de melhorias baseadas no estudo elaborado;
»» Definição de processo organizacional – estabelecimento dos padrões da organização;
»» Treinamento organizacional – para a melhor realização de suas funções, os
envolvidos do projeto devem estar cientes e bem treinados sobre suas funções. Para
tanto, são ministrados cursos, palestras e reuniões para que os funcionários possam
adquirir conhecimento e realizar de forma eficaz suas tarefas e atividades;
»» Gerenciamento integrado de projeto – onde é trabalhada a comunicação entre as
equipes envolvidas no projeto;
»» Gerenciamento de riscos – nesse processo são antecipadamente gerenciados os riscos
que podem vir a acontecer, funcionando como um plano B ou uma válvula de escape;
»» Análise de decisão e resolução – a tomada de decisões é um fato importante no
projeto. Nesse processo são realizados os critérios que se devem seguir para uma
tomada de decisão.

Nível 4 – Quantitativamente gerenciado:

»» Desempenho de processo organizacional – esse processo possui a função de
estabelecer linhas de base e os modelos para a gestão quantitativa, além de garantir um
entendimento do conjunto de processos da organização;
»» Gerenciamento quantitativo de projeto – onde são gerenciados quantitativamente
os processos definidos e que foram realizados para o alcance da qualidade e desempenho.

Nível 5 – Em otimização:
• Gestão de processo organizacional – criar condições que comprovem que houve
melhorias no desempenho dos processos;
• Análise casual e resolução – processo onde são identificados os problemas e defeitos
do produto, assim como são planejadas ações para a prevenção de problemas futuros.

13
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Material Complementar

Para aprofundar seus estudos sobre CMMI, acesse os sites listados abaixo, assim como tome
contato com as seguintes referências bibliográficas:

A TECNOLOGIA EVOLUI muito rápido: desafios, moral e ética. 2 jun. 2014. Disponível
em: <[Link] Acesso em 26 jul. 2014.

GAMMA, E. Padrões de projeto: soluções reutilizáveis de software orientado a objetivos.

Porto Alegre, RS: Bookman, 2000.

ISO/IEC 15504. IBPI, [20--]. Disponível em: <[Link]

Acesso em 26 jul. 2014.

MARQUES, H. M. et al. Fábricas de software e o processo de desenvolvimento segundo

a experiência da FábricaUm. CIN/UFPE, [20--]. Disponível em: <[Link]
br/~in953/olds/relatorios/[Link]>. Acesso em 26 jul. 2014.

SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007.

14
 Referências

CMMI para Desenvolvimento (CMMI-DEV) – versão 1.2. Pittsburgh, PA, USA: Carnegie
Mellon Software Engineering Institute, 2006. Disponível em: <[Link]
CMMI-DEV_1-2_Portuguese.pdf>. Acesso em: 26 jul.2014.
FALBO, R. de A. Qualidade de processo de software CMMI. DI/UFES, 2008. Disponível em:
<[Link]
files/Aula%252010%2520-%2520Qualidade%2520de%2520Processo%2520-%2520CMMI.
ppt+&cd=2&hl=pt-BR&ct=clnk&gl=br>. Acesso em: 26 jul.2014.
FIGUEIREDO, E. O modelo CMMI. DCC/UFMG, [20--]. Disponível em: <[Link]
[Link]/~figueiredo/disciplinas/aulas/cmmi_v01.pdf>. Acesso em: 26 jul.2014.
GOMES, P. R. M.; RIBEIRO, R. M. C. Introdução a CMMI. LDS/UFCG. Campina Grande,
PB, 29 set. 2008. Disponível em: <[Link] Acesso
em: 26 jul.2014.
GROFFE, R. J. Maturidade no desenvolvimento de software: CMMI e MPS-BR. Devmedia,
[20--]. Disponível em: <[Link]
software-cmmi-e-mps-br/27010>. Acesso em: 26 jul.2014.
GUIMARÃES, C. F. O CMMI e o gerenciamento da qualidade de projetos de software.
O Gerente, 31 jan. 2011. Disponível em:<[Link]
da-qualidade-de-projetos>. Acesso em: 26 jul.2014.
O QUE É CMMI? ISD Brasil, [20--]. Disponível em: <[Link]
[Link]>. Acesso em: 26 jul.2014.
TRISTACCI, C. CMMI. [20--]. Disponível em: <[Link]
Acesso em: 26 jul.2014.

15
 Unidade: Capability Maturity Model – Integration (CMMI) (Modelo de Maturidade em Capacitação – Integração)

Anotações

16
[Link]
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000
Qualidade de Serviços
 Material Teórico
ISO - International Organization for Standardization

Responsável pelo Conteúdo:

Prof. Ms. Douglas Almendro

Revisão Textual:
Prof. Ms. Claudio Brites
 ISO - International Organization for
Standardization

• Organismos Normativos

• ISO

Nesta unidade, serão explanados conceitos relacionados à

Organização Internacional para Padronização, a ISO. Este
passo nos levará ao entendimento das certificações dadas a
softwares utilizadas no mercado.

Nesta unidade, realizaremos estudos sobre os modelos da ISO. A ideia principal é mostrar as
normas e as descrições desses modelos. Veremos os órgãos normativos e as séries ISO sobre
os desenvolvimentos de software, seus regulamentos e ações corretivas.
Não deixe de assistir, também, a apresentação narrada do conteúdo e de alguns
exercícios resolvidos.
Finalmente, e o mais importante, fique atento às atividades avaliativas propostas e ao prazo
de realização e envio delas.

5
 Unidade: ISO - International Organization for Standardization

Contextualização

Qualquer organização gostaria de melhorar a forma pela qual opera – quer isso signifique
melhorar a sua participação no mercado, reduzir seus custos, gerenciar o risco mais eficazmente,
ou ampliar a satisfação dos clientes. Um sistema de gestão lhe dá a estrutura necessária para
monitorar e melhorar o desempenho em qualquer área de seu interesse.
A ISO 9001 é de longe a estrutura de qualidade melhor estabelecida, sendo utilizada
atualmente por mais de 750 mil organizações em 161 países. Ela define o padrão não só para
sistemas de gestão de qualidade, mas para sistemas de gestão em geral.
Ela ajuda todos os tipos de organizações a obterem sucesso através de uma melhora na
satisfação de seus clientes, na motivação dos colaboradores, entre outras melhorias contínuas.

6
 Organismos Normativos

Muito antigamente, os produtos em geral eram construídos de maneira artesanal – o oleiro

pegava a argila e transformava ela em vasos. Pegava-se a matéria bruta e a transformava em
produto final. Esse modo de fazer as coisas impossibilitava que os produtos fossem padronizados
–era quase impossível comprar dois vasos idênticos. Com o passar do tempo, com a revolução
industrial, produtos começaram a ser construídos de modo padronizado, em um sistema fabril em
que poucas empresas têm acesso à matéria bruta, pois, na maioria das vezes, uma empresa compra
vários produtos de outras empresas e, com essas “partes”, compõe ela mesmo um outro produto
final. Com essa linha de montagem rígida e esquematizada os órgãos normativos foram criados.

Organismos normativos são instituições que ditam regras criadas com base no trabalho de
especialistas. Essas regras servem de base para:

»» realizar especificações de produtos;

»» organizar o fornecimento de serviços
»» a elaboração da legislação em diversos países.

A hierarquia de órgãos regulamentadores é feita da seguinte maneira:

»» Órgão Internacional:
• ISO – Organização Internacional para Padronização;

»» Órgãos Nacionais: sendo eles:

• ABNT – Associação Brasileira de Normas Técnicas – Brasil;
• ANSI – American National Standards Institute – Estados Unidos;
• IPQ – Instituto Português de Qualidade – Portugal;
• IANORQ – Instituto Angolano de Normalização e Qualidade – Angola;

»» Órgãos Regionais:
• o AMN – Associação Mercosul de Normalização – Mercosul;
• o COPANT – Comissão Pan-Americana de Normas Técnicas – Continente Americano.

Quando uma organização pretende verificar se seu produto atende a todas as regras de uma
norma técnica, deve-se respeitar a hierarquia acima.

Com isso, digamos que a empresa X deseja que seu Sistema de Gestão de Qualidade seja
qualificado como sendo ISO-9000. Essa empresa deve obter essa certificação por meio de
organismos de certificação que são conhecidos internacionalmente. Como exemplo, podem ser
citadas organizações como: BRTUV, Fundação Carlos Alberto Vanzolini, entre outras.

7
 Unidade: ISO - International Organization for Standardization

ISO

Em 23 de Fevereiro de 1947, na cidade de

Genebra, Suíça, foi fundada a Organização
Internacional para Padronização – ISO . A sigla
dessa instituição deveria ser IOS e não ISO,
porém, pela diversidade de línguas, os fundadores
decidiram que a organização deveria ser conhecida
por uma só sigla, a qual provém da palavra isos que
em grego significa igualdade.
Em seu início, a ISO não confeccionava normas
internacionais, mas sim recomendações. Esses
documentos eram criados a partir de normas
nacionais que existiam na época.
O crescimento da organização aconteceu
rapidamente, na tabela abaixo podemos ter uma
noção de seu grande crescimento.

Tabela 1
Ano Documentos Produzidos
1952 5
1957 57
1965 1.400
2004 14.941

A ISO é a organização que reúne a comunidade

de padronização e cria normas de qualidade. Ela está
presente em mais de 163 países, conforme levantamento
de 2012, quando já possuía um total de mais de 19.000
normas publicadas.

IEC
Comissão Eletrotécnica Internacional – IEC – é a
organização encarregada das padronizações de tecnologias
elétricas e de tecnologias associadas a essas. Sua sede,
assim como a da ISSO, está localizada em Genebra, Suíça,
e foi fundada no ano de 1906.

8
Série ISO 9000
A série ISO 9000 contém a união de cinco normas, são as
normas: ISO 9000, 9001, 9002, 9003 e 9004. Essas normas
foram oficializadas em 1987 e desde então vêm sendo
usadas. Essa série não é considerada como um conjunto
de normas revolucionárias, pois elas foram baseadas em
normas britânicas – como a BS5750 e outras que já existiam
na época.
A função da série ISO 9000 é a satisfação do cliente pela
transparência do bom andamento do projeto e de todos os
estágios que mostram a qualidade da empresa.
Qualquer tipo de empresa pode utilizar as normas ISO 9000
– seja ela pequena ou grande, privada ou governamental.

A série ISO 9000 serve para qualificar o sistema de gestão de qualidade da empresa,
garantindo que produtos fabricados pelo processo dessa empresa tenham qualidade superior
aos produtos de outras empresas. Possuir a qualificação ISO 9000 significa que os produtos
criados por certo processo irão possuir os mesmos padrões de qualidade.

Uma empresa qualificada como ISO 9000 deve possuir alguns princípios básicos, alguns
deles são: a documentação de fácil acesso; equipamentos em bom estado de conservação
e manutenção; auditorias internas. Além disso, a empresa deve estar constantemente em
autoanálise, tomando medidas preventivas e corretivas para o bom funcionamento dos processos
e para que seja garantido o sucesso dos projetos.

Com essas ações, a empresa fica possibilitada de atender a demanda de pedidos, possui uma
documentação concreta e garante a qualidade de seus produtos.

ISO 9001:2008
Pelas constantes revisões e atualizações, adotou-se o padrão de escrever o nome da norma
e o ano de sua última atualização separados por dois pontos, com isso, a ISO 9001:2008 nada
mais é do que a atualização do ano de 2008 da norma ISO 9001.

Essa norma utiliza uma abordagem de melhoria no desenvolvimento e na implementação

de um sistema de gestão de qualidade, visando obter maior grau de satisfação do cliente no
atendimento de seus objetivos.

A ISO 9001 possui diversas vantagens para a empresa que a adota, dentre essas vantagens
podemos citar:
»» Melhoria em processos de gerenciamento de riscos, aumentando a porcentagem de
sucesso do projeto;
»» Redução do desperdício, por conta do bom planejamento, de uma documentação
ampla e do foco nos processos operacionais;

9
 Unidade: ISO - International Organization for Standardization

»» Melhoria em processos intrassetoriais, nos quais a comunicação é altamente valorizada,

expondo os possíveis problemas que as equipes envolvidas no projeto possam sofrer
(ou sofrem).
Em seguida, temos um modelo Planejar, Fazer, Checar, Agir – PDCA – que está relacionado
a norma ISO 9001:

Derivada da norma britânica BS5750, a ISO 9001 foi criada com o intuito de aprimorar
mais ainda a qualidade e a padronização de um produto. Na época, a norma BS5750 era
reconhecida como uma das principais normas de qualidade, mas não tratava e nem possuía em
seus objetivos a satisfação do cliente. Por conta disso, a ISO 9001 entrou em cena objetivando
suprir essa deficiência da norma BS5750.

Nos dias atuais, a ISO 9001 é uma das normas mais usadas mundialmente em empresas que
almejam a melhoria contínua a partir do monitoramento e do aprimoramento constante. Ela é
utilizada em mais de 750 mil organizações em 160 países.

ISO 9000-3
Registrada como norma pela ISO em Junho de 1993, a ISO 9000-3 possui os mesmos caminhos
e procedimentos da norma ISO 9001, mas aplicados a conceitos como desenvolvimento,
fornecimento e manutenção de software. Em resumo, podemos afirmar que para cada conceito
ou item que reside na norma ISO 9001, temos um conceito correspondente na ISO 9000-3
aplicado à qualidade de software.

10
 A ISO 9000-3 possui uma deficiência considerável: não realiza o tratamento de problemas
com o uso da Melhoria Contínua do Processo de Software – SPI –, como feito em modelos de
referência na área – como o CMMI ou a norma ISO/IEC 15504. Com isso, a norma ISO 9000-
3 apresenta quais processos devem ser utilizados pelas organizações, mas não demonstra o
caminho para que elas conduzam seus processos de forma eficiente, para atingirem os resultados
esperados.

A norma ISO 9001 é firmada em vinte critérios, que compreendem diversos aspectos
relacionados à garantia de qualidade. O ponto central de normas como a ISO 9001 é a
documentação.

Desde sua criação, em 1991, a ISO 9000-3 foi atualizada duas vezes. A primeira atualização
aconteceu no ano de 1994, e a atualização mais recente aconteceu no ano de 1997. A NBR -ISO
9000-3 é a norma brasileira equivalente à ISO 9000-3, embora baseada em sua primeira versão
– por isso, em relação à norma ISO 9000-3, a NBR-ISO 9000-3 está bastante desatualizada.
Em sua primeira edição, a ISO 9000-3 fazia a divisão de suas diretrizes em três partes
principais:
»» Estrutura: a estrutura é a parte que cuida de todo e qualquer aspecto organizacional
ligado ao sistema de qualidade;
»» Atividades de Suporte: é a parte que dita a condução de atividades, como
desenvolvimento do software, documentação, manutenção, etc.;
»» Atividades do Ciclo de Vida: são as atividades relacionadas ao ciclo de vida do produto.
Essa estrutura deixou de ser usada quando a ISO 9000-3 foi atualizada. Após essa atualização,
a norma passou a utilizar exatamente o mesmo mapeamento e as mesmas diretrizes usados na
norma ISO 9001.

ISO/IEC 12207
A norma ISO/IEC 12207 veio para estabelecer uma linguagem comum entre o desenvolvedor,
o cliente e todos os stakeholders (partes envolvidas) do projeto. Essa linguagem é estabelecida
através da clareza dos ciclos e também de processos bem definidos. Essa norma é conhecida
como a norma de Processos do Ciclo de Vida do Software.

Essa norma é fundamentada em dois princípios:

»» Modularidade: nesse princípio, os processos devem ser bem amarrados e fortemente
conectados; porém, a interface entre os processos deve ser mínima;
»» Responsabilidade: para cada processo estabelecido é designado um membro
da equipe a ser responsável por aquele processo; com isso, várias pessoas estarão
envolvidas com o projeto.
»» A ISO/IEC 12207 realiza o agrupamento em processos primários de atividades que
farão, ou poderão fazer, parte da execução do ciclo de vida. Esse agrupamento é
dividido em três classes de processos, sendo elas:

11
 Unidade: ISO - International Organization for Standardization

»» Processos Fundamentais: são os processos que ditam as regras no contrato entre o

fornecedor e o cliente, onde são tratadas a execução do desenvolvimento do software
e a manutenção do mesmo durante o ciclo de desenvolvimento. Os processos que são
classificados como fundamentais são:
»» Aquisição: tem como função obter produtos ou serviços terceirizados para suprir suas
necessidades;
»» Fornecimento: é o ato de fornecer um produto, o qual especificamente seria um
produto de software;
»» Desenvolvimento: a função desse processo é transformar requisitos em um sistema
de software funcional, que atenda aos requisitos propostos;
»» Operação: o propósito desse processo é realizar o sistema de software no campo para
o qual é destinado, esclarecendo, assim, possíveis dúvidas e problemas dos usuários;
»» Manutenção: a manutenção é o processo no qual o desenvolvedor realiza modificações
e correções no software após esse já estar em uso.
»» Processos de Apoio: são os processos utilizados para a garantia da qualidade do software.
Eles visam melhores conformidade e segurança no desenvolvimento de um software, mas
não são fundamentais. Os processos classificados como processos organizacionais são:
»» Documentação: processo que tem como propósito registrar toda e qualquer informação
do software, como: comandos, manual do usuário, descrição, etc.;
»» Gerência de Configuração: processo que tem a função de estabelecer a integridade dos
produtos do trabalho de determinado processo do projeto;
»» Garantia de Qualidade: processo que cuida da garantia do produto, ou seja, verifica se
o produto está em conformidade com os requisitos;
»» Verificação: realiza a análise que verifica se o produto reflete os requisitos especificados;
»» Validação: processo que confirma se os requisitos são devidamente atendidos pelo
produto;
»» Revisão Conjunta: processo que tem como função sustentar/garantir o entendimento
entre gerência e as partes envolvidas;
»» Auditoria: é o processo que tem o propósito de averiguar a funcionalidade do produto
contra os requisitos;
»» Resolução de Problemas: tem o propósito de garantir que todos os problemas
questionados serão analisados e resolvidos.
»» Processos Organizacionais: são os processos que ajudam a organização e a gerência estabelecer
uma boa empresa. Os processos classificados como processos organizacionais são:
»» Gerencia: processo que organiza, controla e monitora o cumprimento dos processos;
»» Infraestrutura: processo que verifica e faz com que a empresa possua uma infraestrutura
estável e confiável;

12
 »» Melhoria: processo que tem as funções de melhorar, avaliar e controlar o ciclo de vida
do software em desenvolvimento;
»» Recursos Humanos: processos que mantém a consistência dos recursos humanos com
o negócio.
Para total eficiência e melhor aproveitamento da norma ISO/IEC 12207, os processos
apresentados acima podem, e devem, ser adaptados aos interesses da empresa e aos objetivos
que se quer alcançar com determinado projeto de software.

ISO/IEC 15504
A norma ISO/IEC 15504, também conhecida como Software Process Improvement and
Capability Determination – SPICE –, foi criada como um framework. É a norma que define
o Processo de Desenvolvimento do Software. Desde o ano de 1993, a ISO em parceria com
a Comunidade Internacional do projeto SPICE vem desenvolvendo a norma ISO/IEC 15504,
baseando-se em modelos como CMM e em normas como as da série ISO 9000. A ISO só veio
publicar oficialmente a norma SPICE em outubro de 2003, fruto da evolução da norma ISO/
IEC 12207, embora com os mesmos níveis de capacidade das usadas no modelo CMMI.
Nesse modelo são usados conjuntos de boas práticas da Engenharia de Software, que são
considerados fundamentais. Assim como no modelo CMMI, a norma ISO/IEC 15504 possui
níveis de capacidade que servem para que a empresa se autoavalie e aplique planos para a
ampliação da melhoria de seus processos – também servem para que a empresa seja avaliada
por outras organizações e instituições. Seus níveis de capacidade são: incompleto, executado,
gerenciado, estabelecido, previsível e otimizado.
1. Incompleto: Esse nível retrata um processo que muitas vezes não é executado, ou é
executado parcialmente.
2. Executado: O processo deve ser executado com o objetivo de completar as tarefas
necessárias para a execução de um processo.
3. Gerenciado: É o planejamento da execução dos processos, onde a equipe do projeto
faz a comparação do que foi planejado com o que foi executado.
4. Estabelecido: O processo é construído tomando a direção do processo que já existe;
porém é sustentada uma descrição do processo.
5. Previsível: O processo é gerenciado quantitativamente por estudos estatísticos.
6. Otimizado: Este nível é adaptado para que as necessidades da organização sejam
todas supridas por meio da alteração e da adaptação do processo gerenciado
quantitativamente.

O modelo de referência SPICE é dividido em duas dimensões:

»» Dimensão de Processo: essa dimensão utiliza conceitos firmados em Engenharia
de Software que são considerados essenciais. Um modelo que utiliza a dimensão de
processo é a norma ISO/IEC 12207;

13
 Unidade: ISO - International Organization for Standardization

»» Dimensão de Capacidade: essa dimensão é dividida em cinco categorias de processo:

»» Cliente-Fornecedor: são os processos que tratam de assuntos que envolvem as partes
de principal interesse, os clientes e os desenvolvedores do software – o qual, nesse caso,
é classificado como fornecedor;
»» Engenharia: esses são os processos que estão relacionados à Engenharia de Software,
e que cuidam de assuntos pertinentes à tecnologia, às práticas, ferramentas, aos modelos
de maturidade, etc.;
»» Suporte: são processos usados em diferentes projetos e em toda a organização durante
todo o ciclo de vida do software, desde a documentação até a sua manutenção;
»» Gestão: esses processos são relacionados a qualquer gestão de projetos, de processos
e de setores da organização;
»» Organização: esses são os processos que atendem às necessidades de gerir e implantar
melhorias na organização.

A norma ISO/IEC 15504 é usada por empresas que procuram realizar melhorias internas em
seus processos. Essa norma tem o intuito de concretizar uma análise disciplinada dos processos
utilizados em uma organização, identificando seus pontos fracos e fortes. A partir dessa análise,
serão estruturados estudos e planos de melhorias.

14
Material Complementar

Para aprofundar seus estudos sobre a ISO, acesse as referências abaixo:

»» [Link]
»» [Link]
»» [Link]
»» [Link]

15
 Unidade: ISO - International Organization for Standardization

Referências

J. McCall, P. Richards and G. Walters. Factors in Software Quality (3 vols.), NTIS AD-
AO49-014, 015, 055, Nov. 1977.

[Link]. Software Engineering, A Practicioners Approach, McGraw-Hill.

Steven R. Rakitin. “Software Verification and Validation: a Practitioner’s Guide”.

Artech House, 1997.

Nelma S. Gomes. “Qualidade de Software - Uma Necessidade”. Artigo obtido em fev/2003

em:[Link]/cst/arquivos/Qualidade_de_Soft.pdf

PRESSMAN, Roger S. Engenharia de software. 6ª ed. Porto Alegre: Bookman, 2006.

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a objetivos.

Porto Alegre: Bookman, 2000.

SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-Wesley, 2007.

RESENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3ª Ed. Rio

de Janeiro: Brasport, 2005.

FILHO, Wilson de Pádua Paula. Engenharia de software: fundamentos, métodos e padrões.

3ª ed. Rio de Janeiro: LTC, 2005.

FERNANDES, Aguinaldo Aragon. [Link]

redepro_palestra_1.pdf (22/07/2010, 17:35h)

[SEI2000] Sei, An Overview of Capability Maturity Model Integration (CMMI) – Version

1.0, Tutorial presented at SIMPROS 2000 [23], 2000.

[SEI2002a] Sei, Web Site do software Engineering Institute – SEI, [Link]

edu/ (CMMI Models available at [Link]/cmmm).

[ISO9001:2000] International Standard Organization Certification for IMS Company.

[ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement:

Information Technology – Amendement to ISO/IEC 12207, versão PDAM 3, novembro 2000.

16
Anotações

17
[Link]
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000
24/10/2019 Fazer teste: AS_I – QUALIDADE DE SOFTWARE - 40h_Turma_03...

Estado de Conclusão da Pergunta: ?

QUALIDADE DE SOFTWARE - 40h_Turma_03_102019 Material Didático ... Hora de Exercitar!
Fazer teste: AS_I

Fazer teste: AS_I

Informações do teste
Descrição
Instruções
Várias Este teste permite 3 tentativas. Esta é a tentativa número 1.
tentativas
Forçar Uma vez iniciado, este Teste deve ser concluído em uma sessão. Não saia do teste
conclusão antes de clicar em Salvar e enviar.

PERGUNTA 1 0,2 pontos   Salva

Complete a lacuna:

_______________: o quanto de esforço é necessário para se acoplar

um programa a outro.

a. Portabilidade

b. Testabilidade

c. Interoperabilidade

d. Reusabilidade

e. Flexibilidade

PERGUNTA 2 0,2 pontos   Salva

Complete a lacuna:

Com relação às alterações do produto (habilidade para ser

alterado):

______________: o quanto de esforço é necessário para testar um

programa a fim de garantir que ele execute a função pretendida.

a. Reusabilidade.

b. Manutenibilidade.

[Link] 1/3
24/10/2019 Fazer teste: AS_I – QUALIDADE DE SOFTWARE - 40h_Turma_03...
c. Flexibilidade.
Estado de Conclusão da Pergunta:
d. Testabilidade.
e. Portabilidade.

PERGUNTA 3 0,2 pontos   Salva

Complete a lacuna:

Com relação ao uso do produto (características operacionais):

__________: o quanto um programa satisfaz a sua especificação e

cumpre os objetivos visados pelo cliente.

a. Usabilidade

b. Eficiência

c. Correção

d. Integridade

e. Confiabilidade

PERGUNTA 4 0,2 pontos   Salva

Segundo McCall, quais são as características de qualidade, que se

referem a características operacionais?

a. Usabilidade, eficiência, manutenibilidade e portabilidade..

b. Portabilidade, reusabilidade e interoperabilidade.

c. Manutenibilidade, flexibilidade e testabilidade.

d. Usabilidade, eficiência e correção.

e. Correção, confiabilidade, integridade e eficiência.

PERGUNTA 5 0,2 pontos   Salva

Com relação às alterações do produto (habilidade para ser

alterado):
Portabilidade é ____________________________________________________
_________________________________________________________________
Reusabilidade é ___________________________________________________
_________________________________________________________________
Interoperabilidade é ______________________________________________
__
_________________________________________________________________
a.

[Link] 2/3
24/10/2019 Fazer teste: AS_I – QUALIDADE DE SOFTWARE - 40h_Turma_03...

Estado de Conclusão da Pergunta:

• o quanto de esforço é necessário para localizar e eliminar

erros em um programa.
• o quanto de esforço é necessário para modificar um
programa.
• o quanto de esforço é necessário para testar um
programa a fim de garantir que ele execute a função
pretendida.

• o quanto um programa (ou partes dele) pode ser

reutilizado em outros programas.
• o quanto de esforço é necessário para transferir um
b. programa de uma plataforma de hardware e/ou software
para outra.
• o quanto de esforço é necessário para se acoplar um
programa a outro.

• o quanto de esforço é necessário para transferir um

programa de uma plataforma de hardware e/ou software
para outra.
c. • o quanto um programa (ou partes dele) pode ser
reutilizado em outros programas.
• o quanto de esforço é necessário para se acoplar um
programa a outro.

• o quanto de esforço é necessário para transferir um

programa de uma plataforma de hardware e/ou software
para outra.
d. • o quanto de esforço é necessário para se acoplar um
programa a outro.
• o quanto um programa (ou partes dele) pode ser
reutilizado em outros programas.

• o quanto de esforço é necessário para se acoplar um

programa a outro.
• o quanto um programa (ou partes dele) pode ser
e. reutilizado em outros programas.
• o quanto de esforço é necessário para transferir um
programa de uma plataforma de hardware e/ou software
para outra.

Clique em Salvar e Enviar para salvar e enviar. Clique em Salvar todas as respostas para
salvar todas as respostas.

Salvar todas as respostas Salvar e Enviar

[Link] 3/3
24/10/2019 Fazer teste: AS_II – QUALIDADE DE SOFTWARE - 40h_Turma_...

Estado de Conclusão da Pergunta: ?

QUALIDADE DE SOFTWARE - 40h_Turma_03_102019 Material Didático ... Hora de Exercitar!
Fazer teste: AS_II

Fazer teste: AS_II

Informações do teste
Descrição
Instruções
Várias Este teste permite 3 tentativas. Esta é a tentativa número 1.
tentativas
Forçar Uma vez iniciado, este Teste deve ser concluído em uma sessão. Não saia do teste
conclusão antes de clicar em Salvar e enviar.

PERGUNTA 1 0,2 pontos   Salva

Quais são os níveis de maturidade do CMM?

I. Inicial.
II. Repetível.
III. Quanti cado.
IV. De nido.
V. Gerenciado.
VI. Inde nido.
VII. Otimizado.
Estão corretos os itens:

a. I, II, III, IV, V, VI e VII.

b. III, IV, V, VI e VII.

c. I, II, III, IV e V.

d. II, III, IV, V e VI.

e. I, II, IV, V e VII.

PERGUNTA 2 0,2 pontos   Salva

Complete a lacuna.
A ________________________________software é a extensão para a
qual um processo especí co é explicitamente de nido,
gerenciado, medido, controlado e efetivado.
[Link] 1/3
24/10/2019 Fazer teste: AS_II – QUALIDADE DE SOFTWARE - 40h_Turma_...
g

dePortabilidade
Estado a. Conclusão dado processo de software.
Pergunta:

b. Reusabilidade do processo de software.

c. Manutenibilidade do processo de software.

d. Flexibilidade do processo de software.

e. Maturidade do processo de software.

PERGUNTA 3 0,2 pontos   Salva

No _____________ de maturidade, os processos são geralmente ad

hoc e a organização geralmente não dispõe de um ambiente
estável. O sucesso nestas organizações depende da competência
e heroísmo dos funcionários e não no uso de processos
estruturados. Devido ao imediatismo, um ambiente caótico, o
nível 1 de maturidade raramente produz um produto ou serviço
que funcione. Assim, frequentemente eles excedem o orçamento
e o prazo em seus projetos.

a. Nível 5.

b. Nível 1.

c. Nível 3.

d. Nível 2.

e. Nível 4.

PERGUNTA 4 0,2 pontos   Salva

Para desenvolver esse processo, o DOD constituiu junto a

Carnegie-Mellon University o:

a. SPIN.

b. AIEE.

c. SEI.

d. IRE.

e. IEEE.

PERGUNTA 5 0,2 pontos   Salva

Complete a lacuna.
______________________________ são controlados de forma a
estabelecer um per l mínimo a ser utilizado pela engenharia de
software e pela administração. Os planos, produtos e atividades
do software são sempre consistentes com os requisitos de
sistema.

Gerenciamento de s bcontratados
[Link] 2/3
24/10/2019 Fazer teste: AS_II – QUALIDADE DE SOFTWARE - 40h_Turma_...
a. Gerenciamento de subcontratados.
Estado de Conclusão da Pergunta:
b. Gerenciamento de con guração.

c. Planejamento do Projeto.

d. Garantia da qualidade do software.

e. Gerenciamento de requisitos.

Clique em Salvar e Enviar para salvar e enviar. Clique em Salvar todas as respostas para
salvar todas as respostas.

Salvar todas as respostas Salvar e Enviar

[Link] 3/3
24/10/2019 Fazer teste: AS_III – QUALIDADE DE SOFTWARE - 40h_Turma_...

Estado de Conclusão da Pergunta: ?

QUALIDADE DE SOFTWARE - 40h_Turma_03_102019 Material Didático ... Hora de Exercitar!
Fazer teste: AS_III

Fazer teste: AS_III

Informações do teste
Descrição
Instruções
Várias Este teste permite 3 tentativas. Esta é a tentativa número 2.
tentativas
Forçar Uma vez iniciado, este Teste deve ser concluído em uma sessão. Não saia do teste
conclusão antes de clicar em Salvar e enviar.

PERGUNTA 1 0,2 pontos   Salva

Criar e concretizar planos especí cos para a aplicação nos

projetos são características de qual área de processo?

a. Integração do produto.

b. Análise casual e resolução.

c. Gerenciamento integrado de projeto.

d. Planejamento de projeto.

e. Gerenciamento de requisitos.

PERGUNTA 2 0,2 pontos   Salva

Quando o assunto é a área de processo de veri cação, é correto

a rmar que é o processo onde é

a. mantida a integridade dos produtos do projeto.

desenvolvida e implementada a série de soluções para os

b.
requisitos apontados.

realizada a demonstração do produto no ambiente

c. de nido, demonstrando se esse possui todas as
especi cações e requisitos de nidos.

avaliado se o desenvolvimento do produto é realizado

d.
corretamente
[Link] 1/3
24/10/2019 Fazer teste: AS_III – QUALIDADE DE SOFTWARE - 40h_Turma_...
corretamente.
Estado e.
de Conclusão da Pergunta:

veri cada a garantia do projeto, visando garantir se o

produto possui os requisitos e qualidade desejados.

PERGUNTA 3 0,2 pontos   Salva

O modelo CMMI versão 1.2 é dividido em quantas áreas de

processo?

a. Duas áreas de processo.

b. Vinte áreas de processo.

c. Seis áreas de processo.

d. Cinco áreas de processo.

e. Vinte e duas áreas de processo.

PERGUNTA 4 0,2 pontos   Salva

O nível 0 – Incompleto da representação contínua é:

O nível que retrata um processo que comumente não é

a.
executado, ou é executado parcialmente.

O nível que é adaptado para que as necessidades da

b. organização sejam supridas através da alteração e
adaptação do processo gerenciado quantitativamente.

O nível que retrata uma leitura que comumente é

c.
executada, ou é executada integralmente.

O nível que é gerenciado quantitativamente por estudos

d.
estatísticos.

O nível do planejamento da execução dos processos, onde

e. a equipe do projeto faz a comparação do que foi planejado
com o que foi executado.

PERGUNTA 5 0,2 pontos   Salvar resposta

Na representação por estágios o que uma empresa precisa para

ser certi cada como uma organização nível 4?

Possuir metade dos processos classi cados como nível 3 e

a.
a outra metade dos processos classi cados como nível 4.

b. Possuir todos os processos classi cados como nível 3.

c. Possuir metade dos processos classi cados como nível 4.

d. Possuir todos os processos classi cados como nível 4.

[Link] 2/3
24/10/2019 Fazer teste: AS_III – QUALIDADE DE SOFTWARE - 40h_Turma_...
p

Estado e.
dePossuir
Conclusão daos
todos Pergunta:
processos classi cados como nível 1.

Clique em Salvar e Enviar para salvar e enviar. Clique em Salvar todas as respostas para
salvar todas as respostas.

Salvar todas as respostas Salvar e Enviar

[Link] 3/3
24/10/2019 Fazer teste: AS_IV – QUALIDADE DE SOFTWARE - 40h_Turma_...

Estado de Conclusão da Pergunta: ?

QUALIDADE DE SOFTWARE - 40h_Turma_03_102019 Material Didático ... Hora de Exercitar!
Fazer teste: AS_IV

Fazer teste: AS_IV

Informações do teste
Descrição
Instruções
Várias Este teste permite 3 tentativas. Esta é a tentativa número 2.
tentativas
Forçar Uma vez iniciado, este Teste deve ser concluído em uma sessão. Não saia do teste
conclusão antes de clicar em Salvar e enviar.

PERGUNTA 1 0,2 pontos   Salva

Quando o assunto é a norma ISO/IEC 12207, é correto a rmar

que:

I – essa norma foi criada para estabelecer uma linguagem

coerente, a qual é constituída por meio da clareza dos ciclos e
que é comum entre os desenvolvedores, os clientes e os
participantes do projeto.
II – a ISO/IEC 12207 foi criada com base na ISO/IEC 12207.
III – a ISO/IEC 12207 é conhecida como a norma de Processos do
Ciclo de Vida do Software.

a. Apenas I está correta.

b. Apenas II está correta.

c. Apenas I e II estão corretas.

d. Apenas I e III estão corretas.

e. Todas as alternativas estão corretas.

PERGUNTA 2 0,2 pontos   Salva

Qual é a precedência de órgãos normativos?

emÓrgão
Clique a. Internacional,
Salvar e Enviar paraÓrgãos
salvarNacionais, Órgãos
e enviar. Clique Regionais.
em Salvar todas as respostas para salvar todas as r

b. Órgão Internacional, Órgãos Nacionais, Órgãos Estaduais.

[Link] 1/3
24/10/2019 Fazer teste: AS_IV – QUALIDADE DE SOFTWARE - 40h_Turma_...

deÓrgãos
Estado c. Regionais,
Conclusão Órgãos Estaduais, Órgãos Nacionais.
da Pergunta:

d. Órgãos Nacionais, Órgãos Estaduais, Órgãos Regionais.

e. Órgão Internacional, Órgãos Regionais, Órgãos Estaduais.

PERGUNTA 3 0,2 pontos   Salva

Quando o assunto é a norma ISO/IEC 15504, é correto a rmar

que:

I – a norma ISO/IEC 15504 é a que de ne o processo de

desenvolvimento de software.
II – a norma ISO/IEC 15504 é dividida em seis níveis de
capacidade.
III – a norma ISO/IEC 15504 também é conhecida como SPICE.

a. Apenas I está correta.

b. Apenas II está correta.

c. Apenas I e II estão corretas.

d. Apenas I e III estão corretas.

e. Todas as alternativas estão corretas.

PERGUNTA 4 0,2 pontos   Salva

Qual é a classe de processos que tem a função de garantir a

qualidade do software, visando melhor conformidade e
segurança no desenvolvimento?

a. Processos de Apoio.

b. Processos de Qualidade.

c. Processos de Padronização.

d. Processos Fundamentais.

e. Processos Organizacionais.

PERGUNTA 5 0,2 pontos   Salva

A norma ISO/IEC 15504 foi criada com base em quais modelos já

existentes?

a. ISO 9000-3 e CMMI

b. BS5750 e CMM
Clique c.
emSérie
Salvar
ISOe 9000
Enviar para
e ISO salvar e enviar. Clique em Salvar todas as respostas para salvar todas as r
9000-3

d Série ISO 9000 e BS5750

[Link] 2/3
24/10/2019 Fazer teste: AS_IV – QUALIDADE DE SOFTWARE - 40h_Turma_...
d. Série ISO 9000 e BS5750
Estado e.
deSérie
Conclusão da Pergunta:
ISO 9000 e CMM

Clique em Salvar e Enviar para salvar e enviar. Clique em Salvar todas as respostas para salvar todas as r

[Link] 3/3
 AS1
PERGUNTA 1
1. Complete a lacuna:

_______________: o quanto de esforço é necessário para se acoplar um programa a outro.

a. Reusabilidade

b. Flexibilidade

c. Portabilidade

d. Testabilidade

e. Interoperabilidade

0,2 pontos
PERGUNTA 2
1. Quais são os principais objetivos da qualidade?
i. Aprimorar o processo de desenvolvimento e, em consequência, melhorar a qualidade do produto
resultante.
ii. Avaliar a qualidade do produto, visando emitir documento oficial sobre a qualidade de um software e
sua conformidade em relação a uma norma ou padrão.
iii. Adquirir um software, com o intuito de escolher o produto mais adequado dentre um conjunto de
produtos selecionados.
iv. Revisar o quanto um programa (ou partes dele) pode ser reutilizado em outros programas.
v. Avaliar o quanto de esforço é necessário para se acoplar um programa a outro.
a. i(V),ii(V),iii(V),iv(V) e v(F).

b. i(V),ii(F),iii(V),iv(F) e v(F).

c. i(V),ii(V),iii(V),iv(F) e v(F).

d. i(V),ii(V),iii(V),iv(F) e v(V).

e. i(F),ii(V),iii(V),iv(F) e v(F).

0,2 pontos
PERGUNTA 3
1. Complete a lacuna:

Com relação às alterações do produto (habilidade para ser alterado):

______________: o quanto de esforço é necessário para testar um programa a fim de garantir que ele
execute a função pretendida.
a. Flexibilidade.

b. Testabilidade.

c. Reusabilidade.

d. Manutenibilidade.

e. Portabilidade.

0,2 pontos
PERGUNTA 4
1. Com relação às alterações do produto (habilidade para ser alterado):
Portabilidade é ____________________________________________________
_________________________________________________________________
Reusabilidade é ___________________________________________________
_________________________________________________________________
Interoperabilidade é ________________________________________________
_________________________________________________________________
• o quanto um programa (ou partes dele) pode ser reutilizado em outros programas.
• o quanto de esforço é necessário para transferir um programa de uma plataforma de hardware
a.
e/ou software para outra.
• o quanto de esforço é necessário para se acoplar um programa a outro.

• o quanto de esforço é necessário para se acoplar um programa a outro.

• o quanto um programa (ou partes dele) pode ser reutilizado em outros programas.
b.
• o quanto de esforço é necessário para transferir um programa de uma plataforma de hardware
e/ou software para outra.

• o quanto de esforço é necessário para transferir um programa de uma plataforma de hardware

e/ou software para outra.
c.
• o quanto um programa (ou partes dele) pode ser reutilizado em outros programas.
• o quanto de esforço é necessário para se acoplar um programa a outro.

• o quanto de esforço é necessário para localizar e eliminar erros em um programa.

• o quanto de esforço é necessário para modificar um programa.
d.
• o quanto de esforço é necessário para testar um programa a fim de garantir que ele execute a
função pretendida.

• o quanto de esforço é necessário para transferir um programa de uma plataforma de hardware

e/ou software para outra.
e.
• o quanto de esforço é necessário para se acoplar um programa a outro.
• o quanto um programa (ou partes dele) pode ser reutilizado em outros programas.

0,2 pontos
PERGUNTA 5
1. Complete a lacuna:

Com relação ao uso do produto (características operacionais):

__________: o quanto um programa satisfaz a sua especificação e cumpre os objetivos visados pelo
cliente.
a. Confiabilidade

b. Usabilidade

c. Integridade

d. Correção

e. Eficiência

AS2
PERGUNTA 1
1. Quais são os níveis de maturidade do CMM?
I. Inicial.
 II. Repetível.
III. Quantificado.
IV. Definido.
V. Gerenciado.
VI. Indefinido.
VII. Otimizado.
Estão corretos os itens:
a. III, IV, V, VI e VII.

b. I, II, III, IV e V.

c. I, II, IV, V e VII.

d. I, II, III, IV, V, VI e VII.

e. II, III, IV, V e VI.

0,2 pontos
PERGUNTA 2
1. Para desenvolver esse processo, o DOD constituiu junto a Carnegie-Mellon University o:
a. IEEE.

b. AIEE.

c. SPIN.

d. SEI.

e. IRE.

0,2 pontos
PERGUNTA 3
1. As áreas chaves de processo do nível gerenciado são definidas como:
Garantia da qualidade do software, gerenciamento de subcontratados e visão geral e
a.
acompanhamento do projeto.

b. Revisão conjunta, coordenação intergrupos e engenharia de produto de software.

c. Gerenciamento quantitativo dos processos e gerenciamento da qualidade de software.

d. Foco do processo organizacional e gerenciamento de configuração.

Gerenciamento de software integrado, programa de treinamento e definição do processo

e.
organizacional.

0,2 pontos
PERGUNTA 4
1. Complete a lacuna.
A ________________________________software é a extensão para a qual um processo específico é
explicitamente definido, gerenciado, medido, controlado e efetivado.
a. Reusabilidade do processo de software.

b. Flexibilidade do processo de software.

c. Maturidade do processo de software.

 d. Portabilidade do processo de software.

e. Manutenibilidade do processo de software.

0,2 pontos
PERGUNTA 5
1. No _____________ de maturidade, os processos são geralmente ad hoc e a organização geralmente não
dispõe de um ambiente estável. O sucesso nestas organizações depende da competência e heroísmo dos
funcionários e não no uso de processos estruturados. Devido ao imediatismo, um ambiente caótico, o
nível 1 de maturidade raramente produz um produto ou serviço que funcione. Assim, frequentemente eles
excedem o orçamento e o prazo em seus projetos.
a. Nível 2.

b. Nível 3.

c. Nível 4.

d. Nível 1.

e. Nível 5.

AS3
PERGUNTA 1
1. O modelo CMMI versão 1.2 é dividido em quantas áreas de processo?
a. Seis áreas de processo.

b. Cinco áreas de processo.

c. Duas áreas de processo.

d. Vinte áreas de processo.

e. Vinte e duas áreas de processo.

0,2 pontos
PERGUNTA 2
1. É adequado usar a representação contínua quando
a. a empresa quer converter todos os seus processos em sistemas mais maduros.

b. a empresa quer implementar todos os processos, para que se tornem mais legíveis.

c. todos os processos da empresa são categorizados como processos de nível 1.

d. A empresa pretende usar a maturidade alcançada para um modelo de comparação.

e. a empresa quer converter apenas alguns processos, para que se tornem mais maduros.

0,2 pontos
PERGUNTA 3
1. Quando o assunto é a área de processo de verificação, é correto afirmar que é o processo onde é
verificada a garantia do projeto, visando garantir se o produto possui os requisitos e qualidade
a.
desejados.

realizada a demonstração do produto no ambiente definido, demonstrando se esse possui todas as

b.
especificações e requisitos definidos.
 c. desenvolvida e implementada a série de soluções para os requisitos apontados.

d. avaliado se o desenvolvimento do produto é realizado corretamente.

e. mantida a integridade dos produtos do projeto.

0,2 pontos
PERGUNTA 4
1. Na representação por estágios o que uma empresa precisa para ser certificada como uma organização
nível 4?
Possuir metade dos processos classificados como nível 3 e a outra metade dos processos
a.
classificados como nível 4.

b. Possuir todos os processos classificados como nível 4.

c. Possuir todos os processos classificados como nível 1.

d. Possuir todos os processos classificados como nível 3.

e. Possuir metade dos processos classificados como nível 4.

0,2 pontos
PERGUNTA 5
1. O nível 0 – Incompleto da representação contínua é:
O nível do planejamento da execução dos processos, onde a equipe do projeto faz a comparação
a.
do que foi planejado com o que foi executado.

b. O nível que retrata uma leitura que comumente é executada, ou é executada integralmente.

O nível que é adaptado para que as necessidades da organização sejam supridas através da
c.
alteração e adaptação do processo gerenciado quantitativamente.

d. O nível que retrata um processo que comumente não é executado, ou é executado parcialmente.

e. O nível que é gerenciado quantitativamente por estudos estatísticos.

AS4
PERGUNTA 1
1. Quando o assunto é a norma ISO/IEC 15504, é correto afirmar que:

I – a norma ISO/IEC 15504 é a que define o processo de desenvolvimento de software.

II – a norma ISO/IEC 15504 é dividida em seis níveis de capacidade.
III – a norma ISO/IEC 15504 também é conhecida como SPICE.
a. Apenas I está correta.

b. Apenas II está correta.

c. Apenas I e II estão corretas.

d. Apenas I e III estão corretas.

e. Todas as alternativas estão corretas.

0,2 pontos
PERGUNTA 2
1. A norma ISO/IEC 15504 foi criada com base em quais modelos já existentes?
a. ISO 9000-3 e CMMI

b. BS5750 e CMM

c. Série ISO 9000 e ISO 9000-3

d. Série ISO 9000 e BS5750

e. Série ISO 9000 e CMM

0,2 pontos
PERGUNTA 3
1. Qual é a classe de processos que tem a função de garantir a qualidade do software, visando melhor
conformidade e segurança no desenvolvimento?
a. Processos de Apoio.

b. Processos de Qualidade.

c. Processos de Padronização.

d. Processos Fundamentais.

e. Processos Organizacionais.

0,2 pontos
PERGUNTA 4
1. Quais são os processos que compõem a classe de Processos Fundamentais da norma ISO/IEC 12207?
a. Documentação, Aquisição, Verificação, Validação, Verificação.

b. Aquisição, Fornecimento, Desenvolvimento, Verificação, Manutenção.

c. Aquisição, Fornecimento, Desenvolvimento, Operação, Manutenção.

d. Documentação, Aquisição, Gerência de Qualidade, Verificação.

e. Documentação, Auditoria, Aquisição, Manutenção, Resolução de Problemas

0,2 pontos
PERGUNTA 5
1. Quando o assunto é a norma ISO/IEC 12207, é correto afirmar que:

I – essa norma foi criada para estabelecer uma linguagem coerente, a qual é constituída por meio da
clareza dos ciclos e que é comum entre os desenvolvedores, os clientes e os participantes do projeto.
II – a ISO/IEC 12207 foi criada com base na ISO/IEC 12207.
III – a ISO/IEC 12207 é conhecida como a norma de Processos do Ciclo de Vida do Software.
a. Apenas I está correta.

b. Apenas II está correta.

c. Apenas I e II estão corretas.

d. Apenas I e III estão corretas.

e. Todas as alternativas estão corretas.