Teste Qualidade de Software

Aula 24
Caixa Econômica Federal (CEF) (Técnico

Bancário-Tecnologia) Passo Estratégico
de Informática
Autor:
Thiago Rodrigues Cavalcanti
01 de Junho de 2023
Thiago Rodrigues Cavalcanti
Aula 24
QUALIDADE DE SOFTWARE - CMMI. CONCEITOS

BÁSICOS, ESTRUTURA E OBJETIVOS. PRINCIPAIS
NORMAS. AQUISIÇÃO, DESENVOLVIMENTO E
MANUTENÇÃO DE SISTEMAS
Sumário
Análise Estatística ........................................................................................................................................ 2
Roteiro de revisão e pontos do assunto que merecem destaque .................................................................. 4
Qualidade de Software ............................................................................................................................. 4
Conceitos .............................................................................................................................................. 4
Aspectos Importantes ........................................................................................................................... 5
Visões de Qualidade.............................................................................................................................. 5
Garantia da Qualidade de Software .......................................................................................................... 6
Gerenciamento de Qualidade ............................................................................................................... 7
Modelos de Qualidade .............................................................................................................................. 8
Norma ISO/IEC 9126 ............................................................................................................................. 9
CMMI (versão 1.3) ............................................................................................................................... 11
MPS.BR ............................................................................................................................................... 16
Aposta estratégica ..................................................................................................................................... 24
Questões estratégicas ................................................................................................................................ 26
Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

www.estrategiaconcursos.com.br
. Túlio Lages
Aula 00 Rodrigues Cavalcanti
Thiago
Aula 24
ANÁLISE ESTATÍSTICA
Inicialmente, convém destacar os percentuais de incidência de todos os assuntos previstos no nosso curso
– quanto maior o percentual de cobrança de um dado assunto, maior sua importância:
Grau de incidência em
concursos similares
Assunto
CESGRANRIO
4 - Engenharia de software: Processos de software: Processo Unificado
(UP): conceitos gerais, disciplinas, fases, papéis, atividades e artefatos;
Métodos ágeis (Scrum, XP, FDD, Lean, Kanban, SAFe, UX); Análise e 14,85%
projeto orientados a objetos; A Linguagem UML: modelos e diagramas;
Padrões de projeto;
6 - Linguagens de programação: noções sobre linguagens de programação;
Linguagens Java SE; AngularJS; Angular; TypeScript 4.X; Javascript; Python
13,37%
3.9.X (bibliotecas Pandas, NumPy, SciPy, Matplotlib e Scikit-learn); Scala;
R; Kotlin; Objective-C; .Net; Flutter; Swift.
Linguagem SQL; 10,40%
5 - Estrutura de dados e algoritmos: Busca sequencial e busca binária sobre
arrays; Ordenação (métodos da bolha, ordenação por seleção, ordenação 9,41%
por inserção); Lista encadeada; Pilha; Fila; Noções de árvore binária.
3 - Redes de computadores: Fundamentos de comunicação de dados; Meios
físicos de transmissão; Elementos de interconexão de redes de
computadores (gateways, switches, roteadores); Estações e servidores.
8,91%
Tecnologias de redes locais e de longa distância; Arquiteturas, protocolos e
serviços de redes de comunicação; Arquitetura TCP/IP; Arquitetura cliente
servidor; Conceitos de Internet e Intranet.
1 - Organização e arquitetura de computadores: Arquitetura básica de um
computador: CPU e hierarquia de memória; Armazenamento e
representação de dados: base binária e complemento a dois, ponto
6,93%
flutuante e caracteres; Armazenamento e representação de instruções;
Modos de endereçamento; Conjunto típico de instruções de uma CPU;
Subsistema de entrada/saída e dispositivos de armazenamento secundário.
Arquiteturas de software: arquitetura em camadas, arquitetura MVC,
arquitetura orientada a serviços; Métricas e estimativas de software;
Análise por pontos de função: conceitos básicos e aplicações; Engenharia
de requisitos: elicitação de requisitos, identificação das fontes de 6,44%
informação, técnicas de elicitação, técnicas de modelagem, análise de
requisitos, validação e verificação, gerência de requisitos, ferramentas.
Nuvem pública e privada. DevOps.

. Túlio Lages
Thiago
Aula 24
10 - Bancos de dados: Modelagem conceitual de dados: a abordagem

entidade-relacionamento; Modelo relacional de dados (conceitos básicos e
5,45%
normalização); Conceitos de banco de dados e sistemas gerenciadores de
bancos de dados (SGBD);
Data Warehouse: modelagem conceitual para data warehouses, dados
5,45%
multidimensionais;
2 - Sistemas Operacionais: Funções e estrutura de um sistema operacional;
Processos: conceitos básicos, comunicação, sincronização e
escalonamento; Gerência de memória: partições fixas e variáveis, 4,95%
realocação, memória virtual, swapping, sistemas de arquivos; Windows 10
(32-64 bits).
7 - Desenvolvimento de software para a Web: sistemas distribuídos e
microserviços; Arquitetura e padrões de projeto Java EE8; Servlets; JSF;
2,97%
JSP; Ajax; Interoperabilidade de sistemas; SOA e Web Services; Padrões
HTML 4.01, XHTML 1.0, XML, XSLT, UDDI, WSDL e SOAP.
8 - Teste de software: Controle da qualidade estático: revisão, inspeção,
medição estática, análise estática; Princípios e técnicas de teste de
software: teste de unidade, teste de integração, teste de regressão, teste
alfa, teste beta, teste de segurança, teste de aceitação e de aprovação; 2,48%
Desenvolvimento dirigido por testes. 9 - Gerência de configuração:
Conceitos e práticas; Uso de ferramentas de gerência de configuração;
Controle de defeitos: conceitos e práticas.
13 - Qualidade de software: CMMI/MPS-BR: Conceitos básicos e objetivos;
1,98%
Disciplinas e formas de representação; Níveis de capacidade e maturidade.
11 - Portais corporativos: Arquitetura da informação, portlets e RSS;
Ferramentas de Gestão de Conteúdos; Modelo de Acessibilidade do
1,98%
Governo Eletrônico. 14 - Segurança da Informação: Segurança cibernética:
Resolução CMN nº 4893, de 26 de fevereiro de 2021.
2 - Sistemas Operacionais: Funções e estrutura de um sistema operacional;
Processos: conceitos básicos, comunicação, sincronização e
escalonamento; Gerência de memória: partições fixas e variáveis, 1,49%
realocação, memória virtual, swapping, sistemas de arquivos; ambiente
Linux (SUSE SLES 15 SP2).
COBIT; Noções sobre gestão de segurança da informação: normas NBR
1,49%
ISO/IEC 27001 e 27002.
Big data: Fundamentos, técnicas de preparação e apresentação de dados. 0,99%
12 - Gestão e governança de TI: ITIL; 0,50%

. Túlio Lages
Thiago
Aula 24
ROTEIRO DE REVISÃO E PONTOS DO ASSUNTO QUE

MERECEM DESTAQUE
A ideia desta seção é apresentar um roteiro para que você realize uma revisão completa do assunto e, ao mesmo
tempo, destacar aspectos do conteúdo que merecem atenção.
Qualidade de Software
Conceitos
De acordo como SWEBOK 3.01, a qualidade de software se refere “as características desejadas de produtos
de software, a extensão em que um produto de software em particular possui essas características e aos
processos, ferramentas e técnicas que são usadas para garantir essas características”. Portanto, ela está
diretamente ligada com a qualidade do processo através do qual o software é desenvolvido, portanto, para
se ter qualidade em um produto de software é necessário ter um processo de desenvolvimento bem
definido, que deve ser documentado e acompanhado.
Nas normas ISO/EIC 9126-1 e ISO/EIC 25010 a definição de qualidade de software é "a capacidade do
produto de software em satisfazer as necessidades implícitas e explícitas quando usado em condições
específicas".
“Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram

explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a
características implícitas que são esperadas de todo software desenvolvido por profissionais”
[Pressman,1994].
A qualidade de software não pode ser entendida como perfeição. Qualidade é um conceito
multidimensional, realizado por um conjunto de atributos, representando vários aspectos relacionados ao
produto: desenvolvimento, manutenção e uso. Qualidade é algo factível, relativo, dinâmico e evolutivo,
adequando-se ao nível dos objetivos a serem atingidos (SIMÃO, 2002)2.
1
SWEBOK. Guide to the Software Engineering Body of Knowledge. Projeto criado pela IEEE para
servir como referência em assuntos considerados, de forma geral, como pertinentes a Engenharia de
Software. Disponível em: <https://www.computer.org/web/swebok>.
2
SIMÃO, R. P. S. Características de Qualidade para Componentes de Software. 2002. Dissertação
(Mestrado em Informática Aplicada) - Programa de Pós-Graduação em Informática, Fundação
Educacional Edson de Queiroz, Universidade de Fortaleza, Fortaleza.

. Túlio Lages
Thiago
Aula 24
Aspectos Importantes
Diante das definições acima, chegamos a três aspectos importantes. Segundo Crosby 3 “A qualidade é a
conformidade aos requisitos”. Esta definição nos dá direção sobre qual o caminho seguir para julgar a
qualidade de um software.
• Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade
aos requisitos significa falta de qualidade.
• Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a
maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem
seguidos, o resultado quase que seguramente será a falta de qualidade.
• Existe um conjunto de requisitos implícitos que frequentemente não são mencionados na
especificação (por exemplo o desejo de uma boa manutenibilidade).
Note que se o software se adequar aos seus requisitos explícitos, mas deixar de cumprir seus requisitos
implícitos, a qualidade do software pode ser comprometida.
Visões de Qualidade
Desenvolvedor
Para o desenvolvedor, a qualidade do software está voltada às características internas. Entretanto, a

qualidade interna tem que responder às questões externas que o cliente venha a questionar. Por exemplo:
• As funções X estão disponíveis e são executadas eficientemente?

• Funciona corretamente em imprevistos, como, por exemplo, efetuar débito em uma conta com
saldo negativo?
• O software é seguro, ou seja, evita que pessoas ou sistemas não autorizados tenham acesso aos
dados para modificar?
• É fácil de usar ou requer muito treinamento?
• É fácil de integrar com outros sistemas existentes?
• Aceita trabalhar com arquivos de outros sistemas ou enviar dados para outros sistemas?
Por essas questões, os desenvolvedores não podem menosprezar o papel do usuário/cliente, não podendo
se esquecer das necessidades implícitas do uso.
Usuário
3
Philip Bayard Crosby, uma das mais importantes personalidades da qualidade.

. Túlio Lages
Thiago
Aula 24
Na visão do usuário, seu interesse está no uso do software, na sua funcionalidade, no desempenho e nos
efeitos que o uso possa produzir na sua empresa ou organização. Ou seja, o cliente valoriza a qualidade do
software de acordo com sua resposta às suas necessidades.
Gerente
Existe ainda a visão do gerente da empresa, onde a qualidade do produto não pode ser desvinculada dos
interesses da organização. Os gerentes avaliam aspectos de conformidade em relação aos requisitos dos
clientes e desenvolvedores e também aspectos de custo e cronograma.
Garantia da Qualidade de Software
Para se garantir a qualidade de um produto deve ser implementado um conjunto de métodos e técnicas
durante seu desenvolvimento. Abaixo vou citar e definir alguns desses métodos e técnicas.
Identificação de Defeitos
Conhecer os conceitos de erro, defeito e falha é o requisito básico para se construir um processo de garantia
de qualidade. É preciso saber identificar o problema, antes de investigar sua origem e, desta forma, saber
corrigi-lo. Abaixo temos esses conceitos bem definidos:
• Erro: Trata-se de um engano de um indivíduo.

• Defeito: Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha. Podemos
encontrar os seguintes tipos de defeitos:
Informação Estranha Informação desnecessária.
Fato Incorreto Informação que não é verdadeira para as condições especificadas.
Inconsistência Informações conflitantes
Ambiguidade Informação passível de ter múltiplas interpretações
Omissão Informação necessária não incluída
• Falha: Evento notável onde o sistema viola suas especificações.
Quanto antes um defeito for exposto, menor será o custo para correção e maior a probabilidade de corrigi-
lo corretamente e de forma definitiva. Como solução é necessário introduzir atividades de VV&T ao longo
de todo o ciclo de desenvolvimento.
Validação, Verificação e Testes (VV&T)

. Túlio Lages
Thiago
Aula 24
As atividades de VV&T atuam na garantia de qualidade, assegurando que o software cumpre as

especificações definidas e atende às necessidades de seus usuários. Abaixo temos as definições:
• Verificação: A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado.
Ou seja, se os requisitos e funcionalidades documentados foram implementados, além disso a
verificação também pode ser realizada para especificação de sistemas, para avaliar se os requisitos
estão sendo documentados como deveriam e ainda prever falhas ou inconsistências entre requisitos.
Normalmente é caracterizada pela pergunta: Fizemos o software corretamente?
• Validação: A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas do
cliente. Ou seja, se os requisitos, independente do que foi planejado, estão sendo implementados
para atender a regra de negócio do cliente, se o sistema é realmente aquilo que o cliente quer e está
pagando para ter. A validação final do sistema é realizada pelo próprio cliente ou usuário. Também
caracterizada por uma pergunta: Fizemos o software correto?
Os principais métodos de Validação e Verificação são:
1) Estática: Revisões de Software (Revisões aos Pares, Inspeções de Software, entre outros).
Denomina-se estática, pois não envolve a execução do produto, mas apenas leitura de artefatos,
como código.
São processos ou atividades para leitura de um artefato de software visando assegurar que ele
cumpre sua especificação e atende às necessidades de seus usuários. Tem por objetivo realizar
validação e verificação estática de artefatos de software. Pode ser aplicada a qualquer artefato
produzido ao longo do processo de desenvolvimento de software.
Tipos de Revisões:
• Inspeções de Software: mais focadas em encontrar defeitos.

• Walkthroughs: são mais apropriados para atividades de brainstorming, para explorar
alternativas de projeto e resolução de problemas.
2) Dinâmica: Testes de Software (Testes de unidade, de integração, do software, entre outros).
Processo de executar um programa ou sistema com o objetivo de revelar a presença de erros; ou,
falhando nesse objetivo, aumentar a confiança sobre o programa. Envolve todo um processo de
planejamento, fases de teste, etc.
Gerenciamento de Qualidade
O Gerenciamento de Qualidade se importa em definir padrões e procedimentos para o desenvolvimento de

software com qualidade.
• Garantia de qualidade
o Focada no processo;
o Estabelece procedimentos que conduzem a um software de alta qualidade

. Túlio Lages
Thiago
Aula 24
• Planejamento de qualidade
o Seleciona os procedimentos adequados ao projeto de software específico
• Controle de qualidade
o Focado no produto
o Assegura que os resultados estão dentro do esperado
A garantia de qualidade é focada no processo e tem a preocupação em não inserir defeitos (prevenção)
durante a construção do produto, já no controle da qualidade a preocupação é no produto final, isto é, deve
haver uma inspeção visando a detecção de defeitos no produto seja ele o software ou uma documentação
para certificar que os resultados obtidos foram os esperados.
Garantia da Qualidade de Software X Controle da Qualidade de

Software
Existe uma confusão entre os conceitos dos termos Controle da Qualidade (Quality Control) e Garantia da
Qualidade (Quality Assurance). Embora usados de maneira errônea em muitos lugares, ambos os termos
têm propósitos totalmente diferentes.
Garantia da Qualidade (Quality Assurance) Controle da Qualidade (Quality Control)

Garantia da qualidade garante que o processo é As atividades de controle da qualidade focam na
definido e apropriado. descoberta de defeitos em i específicos.
Metodologia e padrões de desenvolvimento são Um exemplo de controle da qualidade poderia ser:
exemplos de garantia da qualidade. "Os requisitos definidos são os requisitos certos?".
Garantia da qualidade é orientada a processo. Controle da qualidade é orientado a produto.
Garantia da qualidade é orientada a prevenção. Controle da qualidade é orientado a detecção.
Foco em monitoração e melhoria de processo. Inspeções e garantia de que o produto de trabalho
atenda aos requisitos especificados.
As atividades são focadas no início das fases no As atividades são focadas no final das fases no ciclo
ciclo de vida de desenvolvimento de software. de vida de desenvolvimento de software.
Garantia da qualidade garante que você está Controle da qualidade garante que os resultados do
fazendo certo as coisas e da maneira correta. seu trabalho são os esperados conforme requisitos.
É importe observar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste
de software é orientado a produto e está dentro do domínio do controle da qualidade.
Modelos de Qualidade
A avaliação da qualidade de produtos de software normalmente é feita através de modelos de avaliação de

qualidade. Esses modelos descrevem e organizam as propriedades de qualidade do produto em avaliação.
Os modelos de avaliação mais aceitos e usados no mercado são:
• Norma ISO/IEC 9126, proposta pela ISO (International Organization for Standardization).
• CMMI (Capability Maturity Model Integration), proposto pelo CMM (Capability Maturity Model).

. Túlio Lages
Thiago
Aula 24
• MPS, criado pela Softex (Associação para Promoção da Excelência do Software Brasileiro).
Entretanto, nosso edital também cobra o modelo de processo de software MPS.BR (Melhoria de Processos
do Software Brasileiro), criado em 2003 pela Softex (Associação para Promoção da Excelência do Software
Brasileiro).
Norma ISO/IEC 9126
O modelo proposto pela ISO/IEC 9126 (NBR 13596) tem como objetivo servir de referência básica na
avaliação de produto de software.
A ISO/IEC em sua primeira parte, descreve um modelo de qualidade do produto de software, composto por
duas partes: qualidade interna e externa e qualidade de uso, como pode ser observado na tabela abaixo.
Tipo de Qualidade Descrição

Especifica seis características para qualidade interna e externa, as quais por sua
Qualidade Interna e vez são subdivididas em sub características que são manifestadas externamente,
Externa quando o software é utilizado como parte de um sistema computacional, e são
resultantes de atributos internos do software.
Especifica quatro características de qualidade em uso, mas não apresenta o
modelo de qualidade em uso além do nível de característica, que é para o
Qualidade de uso
usuário, o efeito combinado das seis características de qualidade do produto de
software.
Na tabela abaixo temos o modelo de propósito geral da qualidade interna e externa que define as seis
amplas categorias de características de qualidade de software. Estas características estão relacionadas
diretamente com os requisitos não funcionais esperados de um software.
Características Sub Características Significado

Existência de um conjunto de funções
Adequação
apropriadas para as tarefas requeridas;
Funcionalidade
Produção de resultados ou efeitos
Acurácia
(como as funções e corretos;
propriedades específicas Habilidade de interação do produto de
do produto, satisfazem as Interoperabilidade
software com outros produtos;
necessidades do usuário)
Aptidão para evitar acessos não
Segurança de acesso
autorizados a programas e dados;

. Túlio Lages
Thiago
Aula 24
O produto está de acordo com as

Conformidade convenções, as normas ou os
regulamentos estabelecidos.
Confiabilidade Estado de maturação do software,
Maturidade detectada por sua baixa frequência de
(como o produto de falhas;
software é capaz de O nível de desempenho é mantido, quando
Tolerância a falhas
manter seu nível de ocorrem falhas;
desempenho, ao longo do Existem mecanismos que restabelecem e
tempo, nas condições Recuperabilidade restauram os dados após a ocorrência de
estabelecidas) falhas.
Usabilidade Facilidade de entendimento dos conceitos
Inteligibilidade
utilizados no produto de software;
(o esforço necessário para
a utilização do sistema, Apreensibilidade Facilidade de aprendizado do software;
baseado em um conjunto
de implicações e de Faculdade de operar e controlar operações
condições do usuário) Operacionalidade
pertinentes ao software.
Eficiência Comportamento em Relaciona-se com a quantidade dos
relação aos recursos recursos empregados.
(como os recursos e os
tempos envolvidos são
compatíveis com o nível Comportamento em Refere-se ao tempo de resposta de
de desempenho requerido relação ao tempo processamento.
pelo software)
Característica de ser possível diagnosticar
Analisibilidade
deficiências e causas de falhas;
Manutenibilidade
Característica que o produto deve ter de
(refere-se ao esforço Modificabilidade forma a facilitar modificações e remoções
necessário para a de defeitos;
realização de alterações Ausência de riscos ou ocorrências de
Estabilidade
específicas, no produto de defeitos inesperados no software;
software)
Testabilidade Facilidade de o produto ser testado.
Portabilidade Faculdade de o produto poder ser

Adaptabilidade
adaptado a novos ambientes;
(facilidade do software
poder ser transferido de Capacidade para ser Facilidade de instalação do produto de
um ambiente para outro) instalado Software Conformidade com padrões;

. Túlio Lages
Thiago
Aula 24
O produto de software pode ser

Capacidade para
substituído por outro, sem grandes
substituir
esforços.
O produto está segundo os padrões ou
Conformidade
convenções de portatilidade.
A tabela abaixo apresenta as quatro características definidas na qualidade de uso.
Características
Eficácia: capacidade do produto de software de permitir que seus usuários atinjam metas especificadas
com acurácia e completitude, em um contexto de uso especificado.
Produtividade: capacidade do produto de software de permitir que seus usuários empreguem
quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado.
Segurança: capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a
pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado.
Satisfação: capacidade do produto de satisfazer usuários, em um contexto de uso especificado.
CMMI (versão 1.3)
O CMMI, sigla para Capability Maturity Model Integration (Modelo de Maturidade em Capacitação
Integração) é um modelo de maturidade que sugere o que deve ser aplicado pelas organizações nos
processos de software. Ele é baseado nas melhores práticas para desenvolvimento e manutenção de
produtos, com ênfase tanto em engenharia de sistemas quanto em engenharia de software.
A versão mais atual do CMMI é a 1.3 publicada em 27 de outubro de 2010 e ela possui os seguintes modelos
para três áreas de interesse:
• CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e

serviços. Contém práticas que cobrem: Gerenciamento de projetos, Gerenciamento de processos,
Engenharia de sistemas, Engenharia de hardware, Engenharia de software e outros processos de
suporte usados em desenvolvimento e manutenção.
• CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e
serviços; e
• CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços.
Representações
O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a
organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
• Representação Continua
Possibilita a organização utilizar a ordem de melhoria que melhor atender os objetivos de negócio da
empresa. É caracterizado por Níveis de Capacidade (Capability Levels).

. Túlio Lages
Thiago
Aula 24
Nesta representação a capacidade é medida por processos separadamente, onde é possível ter um processo
com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa.
A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais
maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a
maturidade alcançada como modelo de comparação com outras empresas.
• Representação Por Estágios
Disponibiliza uma sequência pré-determinada para melhoria baseada em estágios que não deve ser
desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade
(Maturity Levels).
Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos
os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase
todos os processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir
obter o nível de maturidade três.
Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios,
quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando
pretende usar o nível de conhecimento obtido por outros para sua área de atuação.
Nível de maturidade
Por meio de um processo formal de avaliação, uma organização é classificada em um “nível de maturidade”
que varia de um a cinco.
O nível de maturidade indica em que medida os processos daquela organização são maduros. Quanto maior
o nível de maturidade, melhores e mais maduros são os processos.
Os níveis são organizados de modo a estabelecer as prioridades na condução de programas de melhoria do

processo de software. Cada nível é considerado como pré-requisito para o nível seguinte, que se apoia nas
competências que a organização desenvolveu no nível imediatamente inferior.
Abaixo temos uma imagem mostrando como os níveis de maturidade são divididos.

. Túlio Lages
Thiago
Aula 24
As principais características dos níveis acima são:
Nível 1 - Inicial. Imaturidade organizacional; os processos são improvisados e geralmente não são seguidos;
compromissos de prazo e custo não são cumpridos; o planejamento não é feito com base em estimativas;
as qualidades, procedimentos e conhecimentos pertencem às pessoas e não aos projetos; as chances de
sucesso dependem das habilidades pessoais dos gerentes e desenvolvedores
Nível 2 - Gerenciado. Políticas e procedimentos para gerenciar o desenvolvimento de software estão

definidas e são obedecidas; o planejamento é baseado em estimativas e na experiência anterior de outros
projetos; os projetos utilizam processos definidos, usados, disseminados, documentados, medidos e
fiscalizados com rotinas de melhoria; os processos afetados são puramente gerenciais (não técnicos) e
pertencem aos projetos e não às pessoas.
Nível 3 - Definido. Os processos utilizados são estabelecidos e padronizados em toda a organização;

processos técnicos passam a ser considerados ao lado dos processos gerenciais; tanto os processos
gerenciais quanto os técnicos passam a ser repetidos; os processos pertencem a organização e não mais aos
projetos.
Nível 4 - Quantitativamente Gerenciado. São estabelecidas metas quantitativas para os processos e

produtos, medidas de qualidade e produtividade são coletadas em todos os projetos; é estabelecido
controle estatístico de processos; a gestão passa a ser feitas com bases quantitativas.
Nível 5 - Otimização. A organização está engajada na melhoria contínua de seus processos; identificação
de pontos fracos e defeitos; ações preventivas sobre causas; mudanças mais significativas de processos e/ou
tecnologias são feitas a partir de análise de custo/benefício com base em dados quantitativos.

. Túlio Lages
Thiago
Aula 24
O modelo CMMI possui ao todo 22 áreas de processo para que a organização alcance o nível máximo de
maturidade. Abaixo temos uma lista com as áreas correspondentes a cada nível.
• Nível 1: Inicial
▪ Não possui áreas de processo.
• Nível 2: Gerenciado
▪ Gerenciamento de Requisitos - REQM (Requirements Management)
▪ Planejamento de Projeto - PP (Project Planning)
▪ Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control)
▪ Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)
▪ Medição e Análise - MA (Measurement and Analysis)
▪ Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance)
▪ Gerência de Configuração - CM (Configuration Management)
• Nível 3: Definido:
▪ Desenvolvimento de Requisitos - RD (Requirements Development)
▪ Solução Técnica - TS (Technical Solution)
▪ Integração de Produto - PI (Product Integration)
▪ Verificação - VER (Verification)
▪ Validação - VAL (Validation)
▪ Foco de Processo Organizacional - OPF (Organizational Process Focus)
▪ Definição de Processo Organizacional - OPD (Organizational Process Definition)
▪ Treinamento Organizacional - OT (Organizational Training)
▪ Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
▪ Gerenciamento de Riscos - RSKM (Risk Management)
▪ Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution)
• Nível 4: Quantitativamente gerenciado

▪ Desempenho de Processo Organizacional - OPP (Organizational Process Performance)
▪ Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)
• Nível 5: Otimização
▪ Gestão do Desempenho Organizacional - OPM (Organizational Performance Management)

. Túlio Lages
Thiago
Aula 24
▪ Análise Causal e Resolução - CAR (Causal Analysis and Resolution)
Nível de capacidade
Um nível de capacidade para uma área de processo é atingido quando todos os objetivos genéricos são
satisfeitos até aquele nível.
Os quatro níveis de capacidade, cada um servindo de fundação para melhoria contínua de processos, são
designados pelos números de 0 a 3:
Nível 0 – Incompleto. Neste nível de capacidade, a Área de Processo não alcança uma ou mais metas
específicas. Como já dissemos, no CMMI a coisa é binária. Não adianta fazer o quase. É tudo ou nada. Assim
sendo, a Área de Negócio classificada no nível zero significa a mesma não é executada ou é executada de
forma parcial.
Nível 1 – Executado. Neste nível, a Área de Processo satisfaz todas as suas metas específicas, o que garante
que o trabalho necessário é feito a fim de transformar entradas bem definidas em saídas adequadas para
aquela Área de Processo.
Nível 2 – Gerenciado. Neste nível, a Área de Processo é planejada e executada de acordo com uma política
e há o emprego adequado de recursos e pessoas. Além disso, a Área de Processo produz resultados
controlados uma vez que é monitorado e revisado. Cabe aqui uma observação importante, apesar da Área
de Processo ser executada de acordo com uma política, não significa dizer que seja algo padronizado, pois
esta é uma característica específica do próximo nível. Se pudermos exprimir em palavras a diferença entre
Política e Padrão diria que este (padrão) envolve ferramentas, procedimentos, métodos de trabalho
definidos para os projetos da organização, enquanto aquele (Política) representa princípios gerais, diretrizes
a serem seguidas pela Área de Processo.

. Túlio Lages
Thiago
Aula 24
Nível 3 – Definido. Neste nível, a Área de Processo, além de fazer tudo dos níveis anteriores, é uma
adaptação do processo padrão da organização. A Área de Processo fornece informações para sua melhoria.
Diferentemente do que se possa pensar, é neste nível de capacidade que uma Área de Processo começa a
fazer uma melhoria em seu próprio processo. No nível 3, a melhoria está baseada na identificação de pontos
fortes e pontos fracos da Área de Processo.
Abaixo temos uma tabela, atualizada de acordo com a versão 1.3 do CMMI, com os níveis de capacidade X
níveis de maturidade.
==1feb8f==
MPS.BR
O modelo MPS.BR foi criado em 2003 pela Softex (Associação para Promoção da Excelência do Software
Brasileiro), com o objetivo de melhorar a capacidade de desenvolvimento de softwares por empresas
brasileiras.
O MPS.BR funciona como um selo que indica o nível de maturidade da empresa em relação às práticas
relacionadas ao desenvolvimento de software. Esse selo funciona como uma garantia que a empresa utiliza
as boas práticas e possui condições de desenvolver um software de qualidade, dentro dos custos e prazos
estabelecidos. Algumas licitações estão exigindo esse selo para as empresas poderem participar.
Entre as metas do MPS.BR temos a que visa definir e aprimorar um modelo, reconhecido nacional e
internacionalmente, de melhoria e avaliação de processo de software, visando preferencialmente as micro,
pequenas e médias empresas, com o objetivo de atender as necessidades do negócio. Também são
estabelecidos um processo e um método de avaliação, que dá sustentação e garante que o MPS.BR está
sendo empregado de forma coerente às suas definições.
A base técnica para a construção e aprimoramento do modelo MPS.BR é composta pelas normas e modelos
internacionalmente reconhecidos: o CMMI; a NBR ISO/IEC 12207 – Processo de Ciclo de Vida de Software;
as emendas 1 e 2 da norma internacional ISO/IEC 12207; e a ISO/IEC 15504 – Avaliação de Processo.
O programa mobilizador MPS.BR está dividido em 3 componentes:
• Modelo de Referência (MR-MPS);

• Método de Avaliação (MA-MPS);

. Túlio Lages
Thiago
Aula 24
• Modelo de Negócio (MN-MPS).

MR-MPS
O Modelo de Referência (MR-MPS) define níveis de maturidade que são uma combinação entre os
processos e sua capacidade. Isso permite avaliar e atribuir graus de efetividade na execução dos processos.
As atividades e tarefas necessárias para atender ao propósito e aos resultados.
▪ Níveis de maturidade
Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de

melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma
organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define
sete níveis de maturidade:
1) A (Em Otimização);
2) B (Gerenciado Quantitativamente);
3) C (Definido);
4) D (Largamente Definido);
5) E (Parcialmente Definido);
6) F (Gerenciado);
7) G (Parcialmente Gerenciado).
Na imagem abaixo podemos observar que esses níveis são representados como uma pirâmide e formam
uma escala de maturidade.

. Túlio Lages
Thiago
Aula 24
A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de
maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de
melhoria. O progresso e o alcance de um determinado nível de maturidade MPS se obtêm, quando são
atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de
processo estabelecidos para aquele nível.
(G) Parcialmente Gerenciado

O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de Requisitos.
Gerência de O propósito do processo Gerência de Projetos é estabelecer e manter planos que

projetos (GPR) definem as atividades, recursos e responsabilidades do projeto, bem como prover
informações sobre o andamento do projeto que permitam a realização de
correções quando houver desvios significativos no desempenho do projeto. O
propósito deste processo evolui à medida que a organização cresce em
maturidade.
Gerência de O propósito do processo Gerência de Requisitos é gerenciar os requisitos do
requisitos (GRE) produto e dos componentes do produto do projeto e identificar inconsistências
entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
(F) Gerenciado

. Túlio Lages
Thiago
Aula 24
O nível de maturidade F é composto pelos processos do nível de maturidade anterior (G) acrescidos dos
processos Aquisição, Garantia da Qualidade, Gerência de Configuração, Gerência de Portfólio de Projetos
e Medição.
Aquisição (AQU) O propósito do processo Aquisição é gerenciar a aquisição de produtos3 que

satisfaçam às necessidades expressas pelo adquirente.
Gerência de O propósito do processo Gerência de Configuração é estabelecer e manter a
configuração integridade de todos os produtos de trabalho de um processo ou projeto e
disponibilizá-los a todos os envolvidos.
Garantia da O propósito do processo Garantia da Qualidade é assegurar que os produtos de
qualidade (GQA) trabalho e a execução dos processos estejam em conformidade com os planos,
procedimentos e padrões estabelecidos.
Gerência de O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter
portfólio de projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os
projetos (GPP) objetivos estratégicos da organização.
Medição (MED) O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados
relativos aos produtos desenvolvidos e aos processos implementados na
organização e em seus projetos, de forma a apoiar os objetivos organizacionais.
(E) Parcialmente definido
O nível de maturidade E é composto pelos processos dos níveis de maturidade anteriores (G e F),
acrescidos dos processos Avaliação e Melhoria do Processo Organizacional, Definição do Processo
Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. O processo Gerência de
Projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no
processo definido para o projeto e nos planos integrados.
Avaliação e O propósito do processo Avaliação e Melhoria do Processo Organizacional é

melhoria do determinar o quanto os processos padrão da organização contribuem para
processo alcançar os objetivos de negócio da organização e para apoiar a organização a
organizacional planejar, realizar e implantar melhorias contínuas nos processos com base no
(AMP) entendimento de seus pontos fortes e fracos.
Definição do O propósito do processo Definição do Processo Organizacional é estabelecer e
processo manter um conjunto de ativos de processo organizacional e padrões do ambiente
organizacional de trabalho usáveis e aplicáveis às necessidades de negócio da organização.
(DFP)
Gerência de O propósito do processo Gerência de Recursos Humanos é prover a organização e
recursos humanos os projetos com os recursos humanos necessários e manter suas competências
(GRH) adequadas às necessidades do negócio.
Gerência de O propósito do processo Gerência de Reutilização é gerenciar o ciclo de vida dos
reutilização (GRU) ativos reutilizáveis.
(D) Largamente definido

. Túlio Lages
Thiago
Aula 24
O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G ao E),
acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção
do Produto, Validação e Verificação.
Desenvolvimento O propósito do processo Desenvolvimento de Requisitos é definir os requisitos do

de requisitos (DRE) cliente, do produto e dos componentes do produto.
Integração do O propósito do processo Integração do Produto é compor os componentes do
produto (ITP) produto, produzindo um produto integrado consistente com seu projeto, e
demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o
ambiente alvo ou equivalente.
Projeto e O propósito do processo Projeto e Construção do Produto é projetar, desenvolver
construção do e implementar soluções para atender aos requisitos.
produto (PCP)
Validação (VAL) O propósito do processo Validação é confirmar que um produto ou componente
do produto atenderá a seu uso pretendido quando colocado no ambiente para o
qual foi desenvolvido.
Verificação (VER) O propósito do processo Verificação é confirmar que cada serviço e/ou produto de
trabalho do processo ou do projeto atende apropriadamente os requisitos
especificados.
(C) Definido
O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G ao D),
acrescidos dos processos Desenvolvimento para Reutilização, Gerência de Decisões e Gerência de Riscos.
Desenvolvimento O propósito do processo Desenvolvimento para Reutilização é identificar

para reutilização oportunidades de reutilização sistemática de ativos na organização e, se possível,
(DRU) estabelecer um programa de reutilização para desenvolver ativos a partir de
engenharia de domínios de aplicação.
Gerência de O propósito do processo Gerência de Decisões é analisar possíveis decisões
decisões (GDE) críticas usando um processo formal, com critérios estabelecidos, para avaliação
das alternativas identificadas.
Gerência de riscos O propósito do processo Gerência de Riscos é identificar, analisar, tratar,
(GRI) monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.
(B) Gerenciado quantitativamente
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C). Neste
nível o processo de Gerência da Operação do Serviço sofre sua segunda evolução, sendo acrescentados
novos resultados para atender aos objetivos de gerenciamento quantitativo.
Este nível não possui processos específicos.
(A) Otimização

. Túlio Lages
Thiago
Aula 24
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B).
Este nível não possui processos específicos.
A divisão em estágios, embora baseada nos níveis de maturidade do CMMISE/SWSM tem uma graduação
diferente, com o objetivo de possibilitar uma implementação e avaliação mais adequada as micro, pequenas
e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis também permite uma
visibilidade dos resultados de melhoria de processos em prazos mais curtos.
▪ Processos
Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais
(aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto,
instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do
processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria
do processo organizacional, definição do processo organizacional, desempenho do processo
organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na
organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição,
verificação, treinamento).
▪ Capacidade do Processo
A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de

resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com
que o processo é executado na organização. No MPS, à medida que a organização evolui nos níveis de
maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela
organização.
O atendimento aos atributos do processo (AP), através do atendimento aos resultados esperados dos
atributos do processo (RAP) é requerido para todos os processos no nível correspondente ao nível de
maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou
seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de
processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui
os processos de nível G).
A capacidade do processo no MPS possui os seguintes atributos de processos (AP):
1) AP 1.1 - O processo é executado (Nível G) - o processo realiza o que foi proposto para ele;
2) AP 2.1 - O processo é gerenciado (Nível G e F) - a execução do processo é gerenciada;
3) AP 2.2 - Os produtos de trabalho do processo são gerenciados (Nível G e F) - os produtos de
trabalho realizados pelo processo são gerenciados de forma adequada;
4) AP 3.1 - O processo é definido (Níveis E, D e C) - existe um padrão e que o mesmo apoia a
implementação do processo;

. Túlio Lages
Thiago
Aula 24
5) AP 3.2 - O processo está implementado (Níveis E, D e C) - o processo, padronizado, é de fato

implementado para atingir os seus objetivos;
6) AP 4.1 – O processo é medido (Nível B) - algumas medições são usadas para assegurar que o
desempenho do processo ajuda a alcançar os objetivos para o qual este processo foi proposto;
7) AP 4.2 – O processo é controlado (Nível B) - o processo é controlado estatisticamente, permitindo
se ter previsibilidade, estabilidade e capacidade de execução;
8) AP 5.1 – O processo é o objeto de inovações (Nível A) - as mudanças no processo são identificadas
a partir da análise dos seus indicadores e da investigação de possíveis inovações;
9) AP 5.2 – O processo é otimizado continuamente (Nível A) - as mudanças no processo têm, de fato,
impacto no alcance dos objetivos, no que tange os aspectos relevantes de melhoria do mesmo.
Note que ao lado de cada atributo relacionei o nível de maturidade ao qual ele está interligado.
Também é importante que você saiba que os atributos de processos 4.1, 4.2, 5.1 e 5.2 são exclusivos da
versão 1.2.
MA-MPS
O Método de Avaliação é composto pelo processo de avaliação MPS, método de avaliação MPS e
características da qualificação dos avaliadores. Este método permite a realização de avaliações segundo o
Modelo MPS.
O MA-MPS foi definido em conformidade com os requisitos para modelos de referência de processo e
métodos de avaliação de processos estabelecidos na norma ISO/IEC 15504-2 e atende aos requisitos
específicos do Programa MPS.BR. Desta forma, o método está em conformidade com a ISO/IEC 15504 e é
compatível com o método SCAMPI [1] para avaliação segundo o modelo CMMI, também definido com base
na ISO/IEC 15504.
O processo de avaliação é composto por quatro sub processos:
1) Contratar a avaliação;
2) Preparar a realização da avaliação;
3) Realizar a avaliação;
4) Documentar os resultados da avaliação.
MN-MPS
O Modelo de Negócio MN-MPS descreve regras de negócio para: implementação dos Modelos de
Referencias (MR-MPS) pelas instituições implementadoras; avaliação seguindo o Método de Avaliação
(MA-MPS) pelas instituições avaliadoras; habilitação de Consultores de Aquisição (CA) de software e
serviços correlatos e credenciamento de Instituições de Consultoria de Aquisição (ICA); realização tanto de
cursos e provas oficiais quanto de cursos especiais e workshops anuais do MPS, para capacitação de pessoas
no Modelo MPS.
O MN-MPS possui três domínios:

. Túlio Lages
Thiago
Aula 24
1) na retaguarda, domínio do Programa MPS.BR, coordenado pela Softex;

2) na linha de frente, domínio tanto das Instituições Implementadoras (II) e Instituições Avaliadoras (IA)
do MPS.BR quanto das Instituições de Consultoria de Aquisição (ICA) e instrutores dos cursos MPS;
3) no lado dos clientes, domínio das empresas que adotaram o Modelo MPS e Instituições
Organizadoras de Grupos de Empresas (IOGE), compreendendo:
▪ o Modelo de Negócio Cooperado (MNC) – pacote para grupos de empresas, próprio para Micro,
Pequenas e Médias Empresas (MPME) que desejam compartilhar custos e esforços
principalmente na implementação do Modelo MPS visando uma avaliação seguindo o MA-MPS;
▪ o Modelo de Negócio Específico (MNE) – personalizado para uma empresa, próprio para
organizações que desejam exclusividade na implementação e avaliação MPS.
Processo de Garantia da Qualidade - GQA
O propósito do processo de garantia da qualidade é assegurar que os produtos de trabalho e a execução dos
processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos.(MPS.BR –
Guia Geral, Setembro 2009, p.31)
Este processo está dividido em outros 4 procedimentos a serem executados, que são descritos abaixo cada,
em paralelo foi sugerido através da metodologia ágil Scrum como podemos implementar tais processos.
GQA 1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é
avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do
ciclo de vida do projeto; Ideias sobre evidências: Relatórios de auditorias de GQA executadas, segundo
plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame,
durante os sprints do Development (presprint, sprint e postsprint) e durante o postgame . Os relatórios
conterão resultados das auditorias de produtos de trabalho, realizados através de check-lists.
GQA 2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é

avaliada objetivamente; Ideias sobre evidências: Relatórios de auditoria de GQA executado, segundo
plano de GQA em pontos do ciclo de vida do projeto. Por exemplo, auditoria de GQA no final do Pregame,
durante os sprints do Development (presprint, sprint e postsprint) e durante o postgame. Os relatórios
conterão resultados de auditoria de processos, realizados através de check-lists. A mesma instância de
auditoria avaliará tanto produto quanto processo.
GQA 3. Os problemas e as não-conformidades são identificados, registrados e comunicados; Ideias

sobre evidências: Os problemas detectados durante a auditoria (NC-Não conformidades), serão registrados
numa ferramenta de issue-tracker, por exemplo, que deverá permitir o acompanhamento até a sua
resolução. Um dos pontos que poderá ser adotado no Scrum, o que potencializará a conscientização sobre
erros e, principalmente, como evitá-los, será a discussão dessas NC dentro das reuniões da equipe (daily
scrum ou sprint review), por exemplo.
GQA 4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas
efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é
realizado, de forma a garantir sua solução; Ideias sobre evidências: O foco aqui é o acompanhamento da
NC até a sua conclusão e a possibilidade de escalonamento, em caso de impasses na resolução. Esse ponto

. Túlio Lages
Thiago
Aula 24
tem um componente cultural relativo ao fato dos colaboradores serem “observados” por alguém de fora do
“team” e auditado nos seus erros. A filosofia dos métodos ágeis, por conterem traços de comportamento
mais libertos e de auto-gestão, talvez até facilite esse aspecto.
APOSTA ESTRATÉGICA
A ideia desta seção é apresentar os pontos do conteúdo que mais possuem chances de serem cobrados em
prova, considerando o histórico de questões da banca em provas de nível semelhante à nossa, bem como as
inovações no conteúdo, na legislação e nos entendimentos doutrinários e jurisprudenciais4.
Características Sub Características Significado

Existência de um conjunto de funções
Adequação apropriadas para as tarefas requeridas;
Produção de resultados ou efeitos
Funcionalidade Acurácia corretos;
Habilidade de interação do produto de
(como as funções e Interoperabilidade software com outros produtos;
propriedades específicas
do produto, satisfazem as Aptidão para evitar acessos não
necessidades do usuário) Segurança de acesso autorizados a programas e dados;
O produto está de acordo com as
Conformidade convenções, as normas ou os
regulamentos estabelecidos.
Confiabilidade Estado de maturação do software,
Maturidade detectada por sua baixa frequência de
(como o produto de falhas;
software é capaz de O nível de desempenho é mantido, quando
Tolerância a falhas ocorrem falhas;
manter seu nível de
4
Vale deixar claro que nem sempre será possível realizar uma aposta estratégica para um determinado
assunto, considerando que às vezes não é viável identificar os pontos mais prováveis de serem cobrados
a partir de critérios objetivos ou minimamente razoáveis.

. Túlio Lages
Thiago
Aula 24
desempenho, ao longo do Existem mecanismos que restabelecem e

tempo, nas condições Recuperabilidade restauram os dados após a ocorrência de
estabelecidas) falhas.
Usabilidade Facilidade de entendimento dos conceitos
Inteligibilidade utilizados no produto de software;
(o esforço necessário para Facilidade de aprendizado do software;
a utilização do sistema, Apreensibilidade
baseado em um conjunto
de implicações e de Faculdade de operar e controlar operações
condições do usuário) Operacionalidade pertinentes ao software.
Eficiência Comportamento em Relaciona-se com a quantidade dos
relação aos recursos recursos empregados.
(como os recursos e os
tempos envolvidos são Refere-se ao tempo de resposta de
compatíveis com o nível Comportamento em processamento.
de desempenho requerido relação ao tempo
pelo software)
Característica de ser possível diagnosticar
Analisibilidade deficiências e causas de falhas;
Manutenibilidade
Característica que o produto deve ter de
(refere-se ao esforço Modificabilidade forma a facilitar modificações e remoções
necessário para a de defeitos;
realização de alterações Ausência de riscos ou ocorrências de
Estabilidade defeitos inesperados no software;
específicas, no produto de
software) Facilidade de o produto ser testado.
Testabilidade
Faculdade de o produto poder ser

Adaptabilidade adaptado a novos ambientes;
Portabilidade Capacidade para ser Facilidade de instalação do produto de

instalado Software Conformidade com padrões;
(facilidade do software O produto de software pode ser
poder ser transferido de Capacidade para
substituído por outro, sem grandes
um ambiente para outro) substituir
esforços.
O produto está segundo os padrões ou
Conformidade convenções de portatilidade.

. Túlio Lages
Thiago
Aula 24
Imprima o capítulo Aposta Estratégica separadamente e dedique um tempo para absolver tudo o que está
destacado nessas duas páginas. Caso tenha alguma dúvida, volte ao Roteiro de Revisão e Pontos do Assunto
que Merecem Destaque. Se ainda assim restar alguma dúvida, não hesite em me perguntar no fórum.
QUESTÕES ESTRATÉGICAS
Nesta seção, apresentamos e comentamos uma amostra de questões objetivas selecionadas estrategicamente:
são questões com nível de dificuldade semelhante ao que você deve esperar para a sua prova e que, em
conjunto, abordam os principais pontos do assunto.
A ideia, aqui, não é que você fixe o conteúdo por meio de uma bateria extensa de questões, mas que você faça
uma boa revisão global do assunto a partir de, relativamente, poucas questões.
1. CESGRANRIO - Analista (UNIRIO)/Tecnologia da Informação/2019
Alguns requisitos não funcionais formam um grupo à parte, chamado “atributos de qualidade de
software”. Nesse grupo se encontram atributos tais como a disponibilidade, a confiabilidade e a
robustez. Alguns desses atributos são incompatíveis, isto é, a presença ou o aumento da relevância de
um deles afeta adversamente outros.

. Túlio Lages
Thiago
Aula 24
Qual atributo de qualidade é afetado negativamente pelo aumento da importância da portabilidade

de software?
A) flexibilidade
B) interoperabilidade
C) confiabilidade
D) eficiência
E) disponibilidade
Comentários
O atributo de Portabilidade se relaciona com a facilidade do software ser transferido para outro ambiente
tecnológico e manter-se operacional. A eficiência, por sua vez, refere-se ao desempenho do software em
comparação com a quantidade de recursos utilizadas.
Assim, na prática, para um software ser portável, a eficiência será prejudicada, pois o software não foi
otimizado para funcionar em um determinado ambiente de sistema operacional e de hardware.
Diante disso, a alternativa correta é a letra D.
Gabarito: alternativa D.
2. CESGRANRIO - Analista (PETROBRAS)/Sistema Júnior/2018
Ao longo do desenvolvimento de um software, um gerente de projeto percebeu que havia dificuldades

para garantir que os produtos gerados refletissem adequadamente os requisitos especificados.
Investigando mais, concluiu que seu processo de desenvolvimento precisaria ser melhorado. Decidiu,
então, implantar em sua equipe um processo de suporte de software que realizasse atividades
específicas para confirmar, com evidência objetiva, que os requisitos especificados fossem cumpridos.
O processo implantado por esse gerente é o de
A) auditoria
B) garantia de qualidade
C) resolução de problemas
D) validação
E) verificação

. Túlio Lages
Thiago
Aula 24
Comentários
Ao longo do desenvolvimento de um software, um gerente de projeto percebeu que havia dificuldades para
garantir que os produtos gerados refletissem adequadamente os requisitos especificados. Investigando
mais, concluiu que seu processo de desenvolvimento precisaria ser melhorado. Decidiu, então, implantar
em sua equipe um processo de suporte de software que realizasse atividades específicas para confirmar,
com evidência objetiva, que os requisitos especificados fossem cumpridos.
A verificação analisa se o software atende aos requisitos funcionais e não funcionais, ou seja, se eles foram
implementados.
Portanto, a alternativa correta é a letra E.
Gabarito: alternativa E.
3. CESGRANRIO - Analista de Sistemas Júnior (TRANSPETRO)/Processos de Negócio/2018
O custo da qualidade inclui todos os custos feitos na busca da qualidade, dividindo-se em custos de
prevenção, de avaliação e de falha, interna e externa.
Entre os custos de prevenção está o das atividades de

A) testes e depuração
B) coleta de dados e métricas de avaliação
C) retrabalho necessárias para corrigir o erro
D) condução de revisões técnicas para os produtos de engenharia de software
E) gerência para planejar e coordenar todas as atividades de controle e garantia de qualidade
Comentários
a questão aborda os custos de qualidade relacionados à prevenção de defeitos que, segundo (PRESSMAN)
inclui as atividades de:
• O custo de atividades de gerenciamento necessárias para planejar e coordenar todas as atividades

de controle e garantia da qualidade.
• O custo de atividades técnicas adicionais para desenvolver modelos completos de requisitos e de
projeto.

. Túlio Lages
Thiago
Aula 24
• Custos de planejamento de testes.

• O custo de todo o treinamento associado a essas atividades.
O custo da qualidade pode ser dividido em prevenção (abordado acima e escopo da questão), avaliação e
falhas.
Os custos de avaliação podem ser:
• Custo para realização de revisões técnicas para produtos resultantes de engenharia de software.
• Custo para coleta de dados e avaliação de métricas.
• Custo para testes e depuração.
Os custos das falhas podem ser:
• Custo necessário para realizar retrabalhos (reparos) para corrigir um erro.

• Custo que ocorre quando retrabalhos geram, inadvertidamente, efeitos colaterais que devem ser
reduzidos.
• Custos associados à reunião de métricas de qualidade que permitem a uma organização avaliar os
modos de falha.
Portanto, a alternativa correta é a letra E.
Gabarito: alternativa E.
...
Forte abraço e bons estudos.
"Hoje, o 'Eu não sei', se tornou o 'Eu ainda não sei'"
(Bill Gates)
Thiago Cavalcanti
Face: www.facebook.com/profthiagocavalcanti
Insta: www.instagram.com/prof.thiago.cavalcanti


Teste Qualidade de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Teste Qualidade de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 24

Caixa Econômica Federal (CEF) (Técnico

QUALIDADE DE SOFTWARE - CMMI. CONCEITOS

Análise Estatística ........................................................................................................................................ 2

Roteiro de revisão e pontos do assunto que merecem destaque .................................................................. 4

Qualidade de Software ............................................................................................................................. 4

Aspectos Importantes ........................................................................................................................... 5

Garantia da Qualidade de Software .......................................................................................................... 6

Gerenciamento de Qualidade ............................................................................................................... 7

Modelos de Qualidade .............................................................................................................................. 8

Norma ISO/IEC 9126 ............................................................................................................................. 9

CMMI (versão 1.3) ............................................................................................................................... 11

Aposta estratégica ..................................................................................................................................... 24

Questões estratégicas ................................................................................................................................ 26

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

10 - Bancos de dados: Modelagem conceitual de dados: a abordagem

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

ROTEIRO DE REVISÃO E PONTOS DO ASSUNTO QUE

“Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

Para o desenvolvedor, a qualidade do software está voltada às características internas. Entretanto, a

• As funções X estão disponíveis e são executadas eficientemente?

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

Garantia da Qualidade de Software

• Erro: Trata-se de um engano de um indivíduo.

Informação Estranha Informação desnecessária.

Fato Incorreto Informação que não é verdadeira para as condições especificadas.

Inconsistência Informações conflitantes

Ambiguidade Informação passível de ter múltiplas interpretações

Omissão Informação necessária não incluída

• Falha: Evento notável onde o sistema viola suas especificações.

Validação, Verificação e Testes (VV&T)

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

As atividades de VV&T atuam na garantia de qualidade, assegurando que o software cumpre as

Os principais métodos de Validação e Verificação são:

• Inspeções de Software: mais focadas em encontrar defeitos.

O Gerenciamento de Qualidade se importa em definir padrões e procedimentos para o desenvolvimento de

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

Garantia da Qualidade de Software X Controle da Qualidade de

Garantia da Qualidade (Quality Assurance) Controle da Qualidade (Quality Control)

A avaliação da qualidade de produtos de software normalmente é feita através de modelos de avaliação de

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

Norma ISO/IEC 9126

Tipo de Qualidade Descrição

Características Sub Características Significado

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

O produto está de acordo com as

Portabilidade Faculdade de o produto poder ser

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

O produto de software pode ser

A tabela abaixo apresenta as quatro características definidas na qualidade de uso.

CMMI (versão 1.3)

• CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

• Representação Por Estágios

Os níveis são organizados de modo a estabelecer as prioridades na condução de programas de melhoria do

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática

As principais características dos níveis acima são:

Nível 2 - Gerenciado. Políticas e procedimentos para gerenciar o desenvolvimento de software estão

Nível 3 - Definido. Os processos utilizados são estabelecidos e padronizados em toda a organização;

Nível 4 - Quantitativamente Gerenciado. São estabelecidas metas quantitativas para os processos e

Caixa Econômica Federal (CEF) (Técnico Bancário-Tecnologia) Passo Estratégico de Informática