Prévia do material em texto

Profº EDGAR AUGUSTO GONCALVES GURGEL DO AMARAL 
Olá! Bem-vindo (a) à disciplina Qualidade de Software. 
O estudo dessa disciplina pretende abordar os principais fatores, métodos e métricas para planejar e gerenciar o 
desenvolvimento de um software com qualidade. Para tanto, a proposta é motivar o desenvolvimento de software 
de forma disciplinada e sistemática olhando não só para os aspectos tecnológicos, mas também os aspectos de 
gestão de qualidade. 
A intenção da disciplina é, portanto, proporcionar o aprendizado e a experiência em gestão da qualidade de 
software, de tal forma que o software desenvolvido seja confiável o bastante, isto é, seja eficaz e siga padrões 
exigidos pelo contexto onde irá atuar(Normas ISO/IEC). 
A qualidade pode ser atribuída ao produto de software e ao processo de desenvolvimento de software. A proposta 
da disciplina é oferecer um guia para os alunos de nível superior quanto a importância das empresas implementarem 
normas e modelos que permitam a garantia e a correta avaliação de qualidade tanto de produtos de software 
quanto de processos de desenvolvimento de software. 
Ao final desta aula, você será capaz de: 
 
1. Apresentar o conceito de qualidade de 
software. 
2. Abordar sobre a importância da qualidade de 
produto e processo de 
software. 
3. Destacar a relevância da certificação oficial de 
qualidade para as empresas de software. 
 
Qualidade de Software, o que é? 
O conceito de Qualidade de Software pode ser considerado como um processo sistemático que focaliza todas as 
etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos especificados, 
prevenindo e eliminando defeitos. 
 
 
 
Desde então, a realidade de projetos de softwares registram que: 
Mais de 30% dos projetos são cancelados antes de serem finalizados; 
Mais de 70% dos projetos falham nas entregas das funcionalidades; 
Os custos extrapolam em mais de 180% do orçamento inicial; 
Os prazos excedem em mais de 200% os cronogramas originais. 
Uma pesquisa realizada pela agência Reuters, no ano de 2002, em Nova York (EUA), descreve que “bugs” em 
software custaram US$ 60 bilhões por ano aos EUA. A pesquisa também descobriu que a aplicação de melhores 
testes nos programas de software podem eliminar falhas e etapas iniciais de desenvolvimento, promovendo uma 
redução nos custos em US$ 22,2 bilhões. E ainda, cerca de 80% dos custos com desenvolvimento de softwares são 
gerados para identificar e corrigir defeitos de programação em milhares de linhas de código. 
Qualidade é: estar em conformidade com os requisitos dos clientes. antecipar e satisfazer os desejos dos clientes. 
escrever tudo o que se deve fazer e fazer tudo o que foi escrito. 
Qualidade de software é: 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. 
Destaca-se que Pressman (2002), faz referência a padrões de desenvolvimento explicitamente documentados, ou 
seja, refere-se à aplicação por órgãos especializados, de normas conjuntas que registrem as próprias condições e 
objetivos propostos pelo desenvolvedor. 
Da mesma forma, o autor cita as características implícitas, que significam aplicação de normas conjuntas com vistas 
a atender as diferenças entre os usuários, a evolução do tempo, as éticas, as questões de segurança e outras 
visões subjetivas do software desenvolvido. 
Para ajudar nessa questão, a International Organization for Standardization – ISO e a International Electrotechnical 
Comission – IEC, orgãos normalizadores com importância internacionalmente reconhecida no setor de software, se 
uniram para editar normas internacionais conjuntas para os mais diversos setores, no mundo inteiro. 
 
Nível internacional: Normas como as da ISO e IEC, resultantes da cooperação e acordo entre determinado número 
de nações com interesses comuns. 
Nível Regional: Normas estabelecidas por um limitado grupo de países de um mesmo continente para benefício 
mútuo e normas editadas após consenso dos interessados em um país por uma organização nacional de normas que 
seja reconhecida como autoridade no respectivo país. 
Por ser assim, Pressman (2002) complementa que: 
Os requisitos de software são a base da medição da qualidade. 
Os padrões especificados (standards) definem um conjunto de critérios de desenvolvimento. 
Existe um conjunto de características implícitas não mencionadas: 
• Facilidade de uso; • Boa manutenção . 
Por outro lado, Sommerville (2007) estabelece que o gerenciamento de qualidade está estruturado em três 
atividades principais: 
Garantia de Qualidade - Padrões que conduzem a um software de alta qualidade. 
Planejamento de Qualidade - Seleção de procedimentos e padrões apropriados adaptados para um projeto de 
software específico. 
Controle de Qualidade - Aprovação de processos que assegurem que o desenvolvimento de software tenha seguido 
corretamente os procedimentos e padrões de qualidade de projeto. 
Enfim, nesta visão, os padrões exigidos devem englobar boas práticas para que sejam gerados produtos de alta 
qualidade. Dessa forma, acredita-se que há muito mais gerenciamento de qualidade do que padrões e burocracia 
associada para assegurar que os padrões foram seguidos. Complementa o autor que a base do gerenciamento da 
qualidade advém de aspectos intangíveis tais como a elegância, a capacidade de leitura do código e da 
documentação de qualidade gerada ao longo da existência de um software. A documentação de qualidade deve 
variar de acordo com o tamanho do software tendo como propósito a comunicação entre a equipe que participa do 
desenvolvimento do software. 
Qualidade de Produto X Qualidade de Processo de Software 
A qualidade de um sistema de software pode ser entendida sob diversas formas e, utilizando-se de diferentes 
abordagens. 
Assim, um conjunto de normas que tratam deste assunto no âmbito da ISO, estabelece um modelo de qualidade 
com os seguintes componentes: 
Processo de Desenvolvimento: Cuja qualidade afeta a qualidade na forma como o produto de software foi gerado. 
Qualidade em Uso: Consiste na qualidade percebida pelo usuário e na aferição da qualidade do software em cada 
contexto específico de usuário. 
Produto: Compreende os atributos de qualidade e dividem-se em atributos internos e externos, que se diferenciam 
pela forma como são aferidos (interna ou externamente ao produto de software) e, em conjunto, compõem a 
qualidade do produto de software em si. 
Destaca-se que a qualidade do processo contribui para a melhoria da qualidade do produto, que, por sua vez, 
contribui para a melhoria da qualidade em uso: 
 
Através da adequação dos atributos internos do software atende-se a um pré-requisito para o alcance do 
comportamento externo desejado, que por sua vez, é um pré-requisito para o alcance da qualidade de uso. 
 
 
Pensar em desenvolver um software com qualidade é considerar o processo correto pelo qual produtos ou serviços 
são convertidos em bens materiais. 
Torna-se relevante considerar que, uma vez o processo realizado corretamente, um bom produto final será 
desenvolvido. Assim, todos os processos de uma determinada atividade são importantes; se os processos forem 
desenvolvidos com qualidade, o produto final terá qualidade. 
Qualidade do software na visão do usuário 
Até aqui, abordamos o conceito de qualidade com foco no processo de desenvolvimento do software e no produto 
final, agora, trataremos de uma importante questão: a visão do usuário do software. 
Muitas vezes os desenvolvedores de software se esquecem das necessidades implícitas de seus clientes, questões 
tais como: 
O cliente pode ter desejos e necessidades diferentes em relação ao mesmo tipo de produto? 
E qual o interesse dos usuários de software? 
Em primeiro lugar, vamosconsiderar que o efeito da globalização expandiu o elenco de atores no mercado 
aumentando a oferta de produtos, tornando assim o cliente mais consciente de seu poder. Dessa forma, esse novo 
cliente vai demandar por produtos e processos de software de melhor qualidade. 
Em outro momento, os clientes vão buscar responder algumas questões como... 
Funciona adequadamente em imprevistos, como, por exemplo, efetuar débito em uma conta com saldo 
insuficiente? 
As funções requeridas estão disponíveis e são executadas eficientemente? 
O software é seguro, ou seja, evita que pessoas ou sistemas não autorizados tenham acesso aos dados para leitura 
ou modificação? 
Permite que pessoas ou sistemas autorizados para acessar os dados não tenham acesso negado a eles? 
É fácil de integrar com outros sistemas existentes? 
O suporte técnico é confiável e atende com a rapidez necessária? 
É certo que essa mudança de postura do consumo vai exigir melhor qualidade de produtos e processos para atender 
a esse novo cliente. 
A utilização de software de qualidade garante a segurança das transações, dos negócios, das pessoas envolvidas e 
mantém alta disponibilidade dos serviços. Produtos e serviços são considerados aceitáveis se apresentarem 
desempenho dentro de certos limites. 
Por fim é relevante afirmar que os esforços pela qualidade nos mais diversos setores organizacionais já provaram 
que os gastos em qualidade se pagam em muito pouco tempo. 
O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de 
menos retrabalho e menor índice de perdas. 
No caso de software, isto pode significar reaproveitamento de códigos de programa, menor prazo de entrega, menor 
custo de manutenção e maior satisfação do cliente, que vai refletir em maior participação no mercado. 
Para mais informações, leia agora o capítulo 27 de Gerenciamento de Qualidade – Sommerville (2007, pg. 423-
426), e o capítulo 28 de Aprimoramento de Processo – Sommerville (2007, pg. 439-443) 
O INMETRO, Instituto Nacional de Metrologia, Normalização e Qualidade Industrial, é o órgão brasileiro responsável 
pelo credenciamento e supervisão de organismos de certificação, organismos de inspeção e laboratórios de ensaios, 
nas empresas nacionais. 
 A certificação emitida pelo INMETRO, atende de forma criteriosa aos padrões de qualidade exigidos no 
desenvolvimento industrial e consequentemente, atesta que um produto, serviço, sistema ou pessoal cumpre os 
requisitos de uma norma, especificação ou regulamento técnico. 
Considera-se a importância da boa prática de exigir a certificação nos processos de aquisição de software, de acordo 
com a norma brasileira para a gestão de qualidade e garantia de qualidade no processo de desenvolvimento, 
fornecimento e manutenção de software. 
Importância da certificação oficial de qualidade 
Lembre-se de observar e exigir a certificação de qualidade. 
No setor de Tecnologia da Informação tem sido comum, especialmente em órgãos do governo, compradores 
exigirem dos fabricantes de computadores a certificação de qualidade. Tal fato garante que o fornecedor foi avaliado 
e julgado por um organismo certificador pertencente ao Sistema Brasileiro de Certificação. 
esta aula você aprendeu: 
 Sobre a qualidade de produto e processo de software. 
 A importância da percepção das necessidades implícitas dos usuários na aquisição de softwares para as 
organizações. 
 Que a qualidade aumenta a produtividade e reduz custos, trabalho e evita perdas. 
 A necessidade de obter a certificação oficial da qualidade de software como medida de atestar que um 
produto, serviço, sistema ou pessoal cumpre os requisitos de uma norma, especificação ou regulamento 
técnico. 
 
1. 
 Segundo Pressman (2002), a qualidade de software atende a determinadas condições de: 
 1) a) Conformidade com requisitos funcionais e sem adoção de normas de desenvolvimento explicitamente 
declarados. 
 2) b) Conformidade com requisitos funcionais e de desempenho explicitamente declarados, conformidade com 
características implícitas e adoção de normas de desenvolvimento explicitamente documentadas. 
 3) c) Não-conformidade com requisitos funcionais e de desenvolvimento explicitamente declarados. 
 4) d) Adoção de normas implicitamente documentadas e conformidade com requisitos funcionais. 
 2 
 2. 
 No gerenciamento da qualidade são esperadas algumas atividades, quais são: 
 1) a) Apenas garantia da qualidade. 
 2) b) Garantia, controle, custo e planejamento da qualidade. 
 3) c) Somente controle e custo da qualidade. 
 4) d) Apenas o planejamento da qualidade. 
 2 
 3. 
 As organizações normalizadoras da qualidade de produto e processo de software são: 
 
 I. ISO - International Organization for Standardization 
 II. IEEE - Instituto de Engenharia Elétrica e Eletrônica 
 III. ABNT - Associação Brasileira de Normas Técnicas 
 
 
 1) a) Somente I. 
 2) b) I e II estão corretas. 
 3) c) II e III estão corretas. 
 4) d) I, II e III estão corretas. 
 5) e) I e III são falsas. 
 4 
1. Apresentar uma visão geral dos fatores que afetam a qualidade 
de software. 
2. Abordar sobre aplicação de medidas indiretas de qualidade 
de software. 
3. Conceituar a garantia da qualidade de software (SQA). 
4. Apresentar as principais atividades da equipe de SQA. 
5. Enfatizar a importância da revisão de software como medida preventiva na descoberta de 
defeitos. 
6. Analisar a prática da revisão técnica formal (FTR) como meio efetivo para melhorar a qualidade 
de software. 
Existe uma imensa variedade de coisas diferentes que podem ser medidas sob vários aspectos. 
A medição ajuda a tornar visíveis características específicas de processos e produtos. Sendo assim, os fatores que 
afetam a qualidade de software podem ser categorizados em grupos de fatores que podem ser medidos 
diretamente (unidade de tempo) ou apenas indiretamente (usabilidade ou manutenibilidade). 
Imagine uma lata, dessas que são usadas para refrigerante. Você pode medir a sua altura, pode medir quanto pesa e 
pode medir quanto líquido pode comportar. Cada um desses aspectos (comprimento, massa, volume) implica uma 
grandeza física diferente. Altura =24 cm; Volume 350 ml; Peso = 300g; Diametro=7 cm. 
A intenção em cada um dos grupos de fatores é a medição e a comparação de software com algum dado e obter 
uma indicação de qualidade. 
A garantia da qualidade de software (Software Quality Assurance – SQA) trata-se de uma atividade “guarda-chuva”, 
aplicada ao longo de todo o processo de engenharia de software. 
Abrange uma série de tarefas vinculadas especificamente a sete atividades que compõem um plano que realiza 
avaliações, auditorias, revisões, define padrões para o projeto, procedimentos para relato, acompanhamento de 
erros, documentação necessária e realimenta a equipe com informações conclusivas do projeto. 
Aplicação de métodos e ferramentas técnicas: 
O estudo dos métodos e ferramentas técnicas de análise, projeto, codificação e teste são atribuídos aos princípios 
fundamentais da análise de requisitos de software de sistemas. Ajudam o analista e o projetista a produzirem um 
projeto de elevada qualidade. 
Atividade central de revisão técnica formal(Formal Techinal Review – FTR): 
Tem o propósito único de descobrir problemas de qualidade. Essa atividade é específica da equipe técnica e, em 
muitas situações, tem descoberto que as revisões são tão efetivas quanto os testes para detecção de problemas de 
qualidade. 
Atividade de teste de software: 
Conhecida como “rede de segurança” de garantia de software, combina uma série de métodos de projetos de casos 
de testes que auxiliam a garantir uma detecção de erros efetiva. As atividades de teste aplicadas de forma cuidadosa 
revelam a maioria dos erros, aliviando a necessidade de outras atividades de SQA. Porém, considera-se atualmente 
que não sejaa mais efetiva para todas as classes de erros. 
Padrões e procedimentos formais: 
São aplicados no processo de engenharia de software e validados pelos desenvolvedores quanto ao cumprimento 
dos padrões exigidos pelo software. Em alguns casos, o grupo de SQA pode realizar uma auditoria independente do 
atendimento aos padrões exigidos. 
Atividade de controle de mudanças: 
Formaliza pedidos de mudança, avalia a natureza da mesma e controla o respectivo impacto que ela pode causar. O 
controle de mudança é aplicado durante o desenvolvimento de software e após a manutenção do software. 
Medição de software: 
Coleta um conjunto de medidas técnicas e orientadas para a administração das especificações do software. 
Anotação e manutenção de registros(documentação): 
É essencial para a garantia da qualidade de software no que diz respeito à coleta e à disseminação de informações 
de SQA. Os resultados de revisões, auditorias, controle de mudanças, testes e outras atividades de SQA devem 
torna-se parte de um registro histórico de um projeto documentado. A documentação deve ser acessível a todos que 
participam da equipe de desenvolvimento de software. 
Fatores de qualidade de software 
Alguns fatores afetam a qualidade de software, por isso, determinados aspectos devem ser considerados em um 
software tais como: características operacionais, manutenibilidade de mudanças e adaptabilidade a novos 
ambientes. 
 
McCall (1977) considera as seguintes categorizações sobre os fatores que afetam a qualidade de software e podem 
ser descritos da seguinte forma: 
Revisão: 
• Manutenibilidade: capacidade de reparação de erros no programa de forma a torná-lo disponível para uso. 
• Flexibilidade: esforço para se modificar um programa operacional. 
• Testabilidade: tempo necessário para se testar um programa a fim de garantir que ele execute a função 
pretendida. 
Operação: 
• Corretitude: é o atendimento do programa às especificações e objetivos visados pelo cliente. 
• Confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida. 
• Eficiência: quantidade de recursos de computação e de código necessária para um programa executar a função 
desejada. 
• Integridade: controle de acesso ao software ou a dados de forma controlada. 
• Usabilidade: esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa. 
Transição: 
Portabilidade: demanda de esforço para transferir um programa de um ambiente de hardware e/ou software para 
outro. 
Reusabilidade: propriedade de reutilizar um programa ou partes de um programa em outras aplicações (refere-se ao 
empacotamento e escopo de funções que o programa executa). 
Interoperabilidade: esforço exigido para se acoplar um sistema a outro. 
Por outro lado, segundo Pressman (2002), existe a dificuldade de se desenvolver medidas diretas dos fatores de 
qualidade desenvolvidos por McCall (1997) por considerar que muitas das métricas só podem ser medidas 
subjetivamente. Cavano e MCCall (1978), citados por Pressman (2002), consideram importante a utilização de uma 
lista de verificação (checklist) para graduar outros atributos específicos do software. 
McCall (1977) considera relevante a utilização de uma escala padrão que varia de 0 (baixo) a 10 pontos (elevado), no 
estabelecimento de métricas de qualidade para cada fator que altera a qualidade de software. 
Para mais informações, leia no texto Métricas de qualidade, como Pressman (2002, pp. 727:729) apresenta as 
métricas usadas no esquema de graduação de McCall (1977). 
Métricas de qualidade 
• Auditabilidade: facilidade na verificação de conformidade aos padrões especificados. 
• Acurácia: precisão das computações e do controle dos padrões. 
• Comunidade de comunicação: o grau em que interfaces padrões, protocolos e larguras de banda são usados. 
• Inteireza: função implementada com sucesso de acordo com a forma requerida. 
• Concisão: programa compacto em termos de linha de código. 
• Consistência: uniformidade no uso de técnicas de projeto e documentação ao longo do projeto. 
• Comunidade de dados: padronização na estrutura e tipos de dados necessários. 
• Tolerância a erros: impacto do dado quando o programa detecta erro. 
• Eficiência de execução: desempenho fantástico na execução. 
• Expansibilidade: capacidade de ampliação da arquitetura, dos procedimentos e dos dados. 
• Generabilidade: aplicação ampla de componentes de programa. 
• Independência de hardware: desvínculo do software em relação ao hardware em que opera. 
• Instrumentação: monitoramento da própria operação do software e a capacidade de identificação rápida de erros. 
• Modularidade: independência funcional dos componentes do programa. 
• Operabilidade: facilidade de operação de um programa. 
• Segurança: mecanismos disponíveis para proteção de programas e dados. 
• Autodocumentação: documentação significativa do código-fonte. 
• Simplicidade: entendimento sem dificuldades de um programa. 
• Independência do software básico: o quanto um programa é independente de particularidades não-padronizadas 
de linguagens de programação. 
• Rastreabilidade: capacidade de rastrear componentes de programa até os requisitos. 
• Treinamento: o quanto o software auxilia novos usuários a aplicarem o sistema. 
Métrica dos fatores de qualidade 
Pressman (2002) comenta que os fatores e atributos da qualidade descritos anteriormente podem ser usados para 
estabelecer métricas de qualidade para cada etapa do processo de desenvolvimento de software. 
Além dos fatores evidenciados pelos autores citados, outros também interferem na aquisição de qualidade durante 
o processo de desenvolvimento de software, tais como: 
Falta de um modelo corporativo de qualidade. 
Ausência de procedimentos de testes automatizados. 
Ausência de profissionais capacitados em qualidade. 
Deficiência no planejamento e aplicação dos testes. 
Qualidade é aplicada tardiamente no processo. 
Em contrapartida, o predomínio da qualidade no processo de desenvolvimento de software traz alguns benefícios, 
como: 
Torna o ciclo de desenvolvimento de software confiável. 
Garante ações corretivas no ciclo de desenvolvimento. 
Evita a ingerência do projeto de software. 
Amplia as chances de sucesso do projeto de software. 
Amplia a produtividade do desenvolvimento. 
Evita a propagação de erros. 
Automação de testes reduz custos do projeto. 
Revisões de software 
As revisões são métodos de validação de qualidade de um processo ou produto amplamente usado pela equipe 
técnica do projeto. São consideradas como verdadeiros “filtros” de erros e inconsistências no processo de 
desenvolvimento de software. 
Qualquer revisão é uma maneira de usar a diversidade de um grupo de pessoas para apontar melhorias necessárias 
ao produto gerado por uma equipe, confirmar partes ou o todo de um produto que devem ser melhorados (ou não) 
e realizar um trabalho mais técnico com uma qualidade mais uniforme e previsível, de forma a tornar o trabalho 
técnico mais administrável. 
Alguns bons exemplos de revisões são levados em consideração a efeito de contribuírem na garantia da qualidade de 
software. Por exemplo, um encontro informal em torno da máquina de café é uma forma de revisão quando 
tratados problemas técnicos. Uma apresentação técnica do projeto a clientes, à administração e ao pessoal técnico 
também pode ser considerada uma forma de revisão. 
São tipos de revisão específicos do gerenciamento de qualidade, segundo Sommerville (2007, pg 431). 
Inspeções de projeto ou de programa - Detectar erros detalhados nos requisitos, projeto ou código. 
Revisões de progresso - Fornecer informações para a gerência sobre o progresso geral do projeto (revisão de 
processo, produto com foco em custos, planejamento e prazos). 
Revisões de qualidade - Conduzir análise técnica de componentes de produto ou documentação para encontrar 
inconsistências entre especificaçãoe projeto, código ou documentação; assegurar que padrões de qualidade 
definidos foram seguidos. 
Custos da qualidade 
Um outro aspecto importante é referente aos custos da qualidade. Vários são os estudos conduzidos por 
especialistas da área de qualidade intencionados em obter um referencial para os custos reais da qualidade, a fim de 
poderem identificar maneiras de reduzir custos da qualidade e fornecer uma base de comparação entre os demais 
custos envolvidos no processo de desenvolvimento de software. 
Os custos operacionais da função qualidade podem ser classificados em quatro categorias: prevenção, avaliação, 
falhas internas e falhas externas. Veja a seguir esses quesitos detalhadamente: 
 
Interessante ressaltar que na medida em que migramos dos custos de prevenção para os de detecção de falhas 
internas até os de falhas externas aumentamos significativamente os custos de identificação e reparo de um defeito. 
Uma análise numérica justifica o impacto de custo de detecção de erros feita precocemente. Considere que, na 
descoberta de um erro durante a fase de projeto, o custo seja de uma (1,0) unidade monetária para ser corrigido. 
Em relação a esse custo, o mesmo erro, descoberto logo antes que as atividades de teste se iniciem, custará 6,5 
unidades; durante os testes, 15 unidades; e, após o lançamento, entre 60 e 100 unidades (PRESSMAN, 2002). 
Como sugestão de prática da revisão, os especialistas recomendam não terem medo de assumir custos de prevenção 
significativos. Seu investimento terá excelente retorno. 
Revisões técnicas formais 
As revisões técnicas formais são consideradas como a principal atividade de um SQA. 
Conhecida como walkthroughs, inspeções, reuniões round - robin e outras avaliações técnicas de software, as 
revisões técnicas formais têm como objetivos: 
1. descobrir erros de função, lógica ou implementação do software; 
2. verificar se o software em revisão atende aos requisitos; 
3. garantir que o software está representado de acordo com padrões predefinidos; 
4. obter um software desenvolvido de forma uniforme; e 
5. tornar os projetos mais administráveis (SOMMERVILLE, 2007). 
Assim como a revisão de software, a revisão técnica formal (Formal Technical Review - FTR) deve contar com 
algumas etapas, segundo Pressman (2002): 
Reunião da revisão: entre três a cinco pessoas com preparação antecipada de 2 horas de trabalho de cada pessoa 
para uma duração de não mais que 2 horas. 
A reunião ocorre a partir da informação do produtor do software ao líder do projeto quanto a necessidade de 
revisão. 
O líder de projeto comunica ao líder de revisão que avalia o produto e demais materiais e os distribui aos revisores 
selecionados. 
Os revisores selecionados revisam o produto fazendo anotações devidas para efeito de posteriores reuniões. 
Por fim, o líder de revisão toma conhecimento das anotações e convoca nova reunião para tomadas de decisão 
quanto à aceitação com correção, rejeição devido a erros graves, solicitação de nova revisão ou aceitação provisória 
do produto. 
Comunicação e manutenção de registros de revisão: consiste na atividade de um revisor atuar durante a FTR para 
registrar todas as questões que foram levantadas para efeito de revisão do produto de software em estudo. No final 
da reunião, um relatório de revisão resumido simples é concluído e distribuído ao líder do projeto e a outras partes 
interessadas. 
O objetivo da lista de questões de revisão é identificar as áreas problemáticas do produto de software e servir de 
conferência de itens de ação que apóiem o produtor nas correções a serem feitas. 
Interessante enfatizar que a comunicação deve ser contínua durante o processo de revisão e por isso, requer um 
procedimento de resposta aos itens da lista de questões levantadas para efeito de confirmar a devida correção das 
questões levantadas. 
Diretrizes de revisão: estabelecida antecipadamente e distribuída a todos os revisores para a concordância de todos 
e assim ser encaminhada mantendo a organização no processo de revisão técnica formal. 
Requer um conjunto de diretrizes necessárias para a perfeita realização do processo: 
• Revisar o produto, não o produtor: responsabilidade do líder de revisão conduzir o encontro a fim de garantir que 
o tom e a atitude comportamental dos participantes sejam mantidos de forma cordial e respeitosa, mas, em situação 
oposta, deve interromper imediatamente uma revisão, caso tenha saído do controle. 
• Fixe e mantenha uma agenda: a orientação para o líder de revisão é evitar a divagação, o desvio no cumprimento 
do cronograma previamente definido para a reunião; caso isso aconteça, o líder de revisão é o responsável pela 
chamada de atenção dos participantes. 
• Limite ao debate e a refutação: questões levantadas que não obtenham concordância geral devem ser registradas 
para posterior discussão offline, ou seja, em outro momento à parte da reunião. 
• Foco nas áreas problemáticas: nem todos os problemas serão resolvidos em uma única sessão e, por isso, é 
interessante enunciar somente as áreas problemáticas, mas não tentar resolver cada problema anotado. A resolução 
de problemas deve ser transferida para depois do encontro da revisão. 
• Registre as anotações por escrito: a intenção é compartilhar a redação das anotações entre todos a fim de se 
avaliarem e se determinarem prioridades em conjunto. 
• Reduzir número de participantes: o líder de revisão deve manter o número de pessoas envolvidas ao mínimo 
necessário e solicitar a preparação antecipada de todos. 
• Definir uma lista de conferência (checklist) para cada produto revisado: uma lista de conferência ajuda o líder da 
revisão a estruturar o encontro de FTR e ajuda cada revisor a se concentrar em questões mais importantes. 
• Atribuir recursos e uma programação de tempo para as FTRs.: a efetividade das revisões requer a programação de 
tempo para as modificações que serão realizadas durante o processo de desenvolvimento de software e os 
resultados findos da FTR. 
• Realizar treinamento para os revisores: capacitar formalmente os revisores para melhor desempenho tanto em 
processos como em relações humanas. 
• Rever antigas revisões: as diretrizes da revisão devem ser revistas a fim de desvendar problemas gerados pelo 
próprio processo de revisão. 
Lista de conferência de revisão – cada etapa do processo de engenharia de software pode realizar uma FTR a partir 
de um produto derivado de outras FTRs anteriores. 
Dessa forma, importante considerar a lista de conferência como parâmetro ou ponto de partida para cada revisão. 
Algumas questões pertinentes a cada etapa do processo de desenvolvimento abrangem determinados 
questionamentos. As listas de conferência não pretendem ser abrangentes o suficiente, mas apenas oferecem um 
ponto de partida para cada revisão. 
Para mais informações, acesse agora uma lista com itens que o ajudarão na conferência da revisão. Você poderá 
utilizá-la em seu processo de revisão de software. 
 
 
Leia o capítulo 1 de Pfleeger (2004, p. 27-29). Referência sobre o tema “Métricas e Qualidade de Software”. 
 
Explorar conhecimentos sobre como usar as Sete Ferramentas Básicas do controle da Qualidade: Fluxograma, 
Histograma, Diagrama de Pareto, Carta de Controle, Diagrama de Dispersão, Lista de Verificação, Diagrama 
Ishikawa (Espinha-de-Peixe), para auxílio nos processos de ação corretiva e preventiva e solução de problemas. 
Nesta aula, você aprendeu: 
 A importância da aplicação de métricas orientadas à função, ou seja, que oferecem 
medidas indiretas à funcionalidade do software e não a leitura de linhas de código. Tais 
métricas destacam a valorização das funções executadas pelos programas. 
 A importância da aplicação de métricas orientadas às pessoas, as quais dão indicações 
sobre a forma como as pessoas desenvolvem os programas de computador. Quando não 
há a definição de métricas, ou quando os objetivospara o desenvolvimento de software 
não são claros, as pessoas tendem a criar produtos dentro das suas próprias visões, 
levando a projetos inadequados para a função de negócio a ser atendida. 
 Sobre a organização das métricas da qualidade, que permitem indicar o nível de resposta 
do software às exigências explícitas e implícitas do cliente. As pessoas são sensíveis aos 
estímulos externos e por meio de tais estímulos são influenciadas suas atitudes e 
pensamentos. 
 A garantia de qualidade de software consiste nas funções gerenciais de auditar e relatar. O 
objetivo é fornecer à gerência os dados necessários para que fique informada sobre a 
qualidade do produto, a fim de obter compreensão e confiança de que a qualidade do 
produto está satisfazendo as metas. 
 Revisões, embora tenham eficácia duvidosa, são simples e, se bem realizada, têm 
mostrado bons resultados. 
 As revisões visam promover a simplicidade da prática de técnicas para descoberta de 
erros e inconsistências. Promovem eficácia apesar de informais e tendem a encontrar o 
número significativo de defeitos. Se feitas por pessoas treinadas em aspectos formais 
podem ser muito mais eficazes. 
 O custo da revisão é amplamente compensado pela redução do retrabalho inútil e além do 
mais, é baixo a partir da remoção de problemas potenciais, defeitos e inconsistências. 
Porém, a qualidade das revisões depende excessivamente da habilidade de revisores 
quanto à proficiência, confiabilidade quanto ao rigor adotado pelo revisor em suas 
opiniões e diretrizes. 
 A importância de treinar e capacitar efetivamente os revisores nas práticas das revisões 
técnicas formais para amenizar os problemas decorrentes da informalidade. 
 É fato a dificuldade de se determinar com precisão a eficácia da revisão quanto à 
existência de defeitos desconhecidos e a gravidade e impacto destes nos produtos de 
software. 
 
1. 
 Um software de qualidade deve atender a determinadas características. Assinale aquelas que você considera pertinentes ao 
alcance da referida qualidade. 
 a) Inflexível 
 b) Confiável 
 c) Difícil de usar 
 d) Reutilizável 
 e) Portável 
 f) Correto 
As alternativas corretas são: 
 1) a), b), d), f) 
 2) b), d), e) e f) 
 3) a), b), c) e f 
 4) Todas as alternativas corretas 
 2 
2. 
O fator de qualidade “usabilidade” refere-se a: 
 1) quantidade de recursos de computação e de código necessário para um programa executar sua função 
 2) esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa 
 3) atendimento do programa às especificações e objetivos visados pelo cliente 
 4) controle de acesso ao software ou a dados de forma controlada 
 5) capacidade de reparação de erros no programa de forma a torná-lo disponível para uso 
 2 
3. 
Dentre as métricas apresentadas abaixo escolha as que são pertinentes no alcance de qualidade de software. 
 a) Retração 
 b) Auditabilidade 
 c) Pouca comunicação 
 d) Acurácia 
 e) Inteireza 
 f) Concisão 
 g) Inconsistência 
 h) Despadronização de dados 
 i) Intolerância a erros 
 j) Eficiência de execução 
Marque as alternativas corretas: 
 1) a), c), d), i) e j) 
 2) c), d), e), f) e j) 
 3) e), f), g), h) e i) 
 4) b), d), e), f) e j) 
 4 
4. 
Como conclusão do estudo, pode-se enfatizar que as medidas servem favorecer para determinadas atividades de qualidade. 
Marque as alternativas corretas: 
a) Analisar qualidade e produtividade do processo de desenvolvimento e manutenção bem como do produto de software 
construído, 
b) Qualificar o desempenho técnico dos produtos do ponto de vista do usuário 
c) Medidas funcionais são necessárias para qualificar o desempenho dos produtos pela perspectiva do usuário 
d) Devem ser dependentes das decisões do desenvolvimento técnico e de implementação 
 1) a), c) 
 2) c), d) 
 3) a), b) e d) 
 4) Todas as alternativas corretas 
 1 
Ao final desta aula, você será capaz de: 
1. Descrever os passos necessários para realizar a SQA estatística. 
 
2. Discorrer sobre a diferença entre confiabilidade de software e segurança de 
software. 
3. Abordar os princípios da ISO 9000 e suas vertentes. 
4. Discorrer sobre os modelos ISO 9000 para sistemas de garantia da qualidade. 
Aula 3: Garantia estatística da qualidade e a abordagem da NBR ISO 9000 
Nas aulas anteriores, enfatizou-se que a qualidade de software é responsabilidade de todos os participantes envolvidos no desenvolvimento de 
software. 
 
Qualidade de software  Pode ser conseguida através de análise, projeto, codificação e teste de componente, mas, 
com toda certeza, uma efetiva aplicação de revisões técnicas formais para controle de produtos de trabalho de 
software e de modificações feitas neles são consideradas técnicas eficientes de obtenção de qualidade de software. 
Garantia estatística de qualidade de software  Reflete uma tendência entre os profissionais da área de 
computação e apóia-se na questão quantitativa a respeito da freqüência de ocorrência de erros e inconsistências nos 
softwares rastreados ao longo de um período específico de tempo. 
Com o decorrer da industrialização acelerada, algumas questões relativas à padronização começaram a ser 
questionadas no sentido de estimular procedimentos quanto à gerência de processos e a obtenção de qualidade nos 
produtos fabricados. 
Ao iniciar o século XX, Frederick Taylor, se destacou nos estudos quanto a racionalização das etapas de produção 
visando a maior produtividade de seus funcionários. Logo após, seguiram os estudos de Henry Ford que apoiado pela 
idéia de racionalização no processo industrial implantou a linha de montagem com a implementação de processos 
padronizados. 
Desde então, criaram-se vários órgãos normativos que perseveraram no propósito da padronização e assim em 
1906, surge a International Electrotechnical Commission (IEC) com ênfase na eletrotécnica. 
Em 1926, surge a International Federation of the National Standardizing Associations (ISA), com ênfase na 
engenharia mecânica. 
Mais tarde, com o fim da II Guerra Mundial, em Londres, estabelece a nova organização, a Organização Internacional 
para Padronização, iniciando oficialmente as suas operações em 23 de fevereiro de 1947 com sede em Genebra, na 
Suíça. 
Com a acentuação da globalização na década de 1980, aumenta a necessidade de normas internacionais, 
nomeadamente a partir da criação da União Européia que suplantou a norma padrão internacional, a ISO 9000 
(International Organization for Standardization), através da criação de uma organização não-governamental, cuja 
função é a de promover a normatização de produtos e serviços, para que a qualidade dos mesmos seja 
permanentemente melhorada. 
ISO 9000  Grupo de normas técnicas que estabelecem um modelo de gestão da qualidade para organizações em 
geral, qualquer que seja o seu tipo ou dimensão. 
Passos para a SQA estatística 
Pressman (2004), destaca alguns passos necessários para realizar a SQA estatística e criar um processo adaptativo de 
engenharia de software no qual são feitas modificações para aprimorar os elementos do processo que promovem 
erro: 
Coletar e categorizar os defeitos de software encontrados. Rastrear o defeito até sua causa subjacente. 
Considerar que 20% do código têm 80% dos defeitos. Corrigir os problemas que causaram os defeitos. 
 
 
Concluindo... 
A Tabela indica que os erros I, II e V são as poucas causas vitais que correspondem 53% de todos os erros. 
Entretanto, os erros I, V, X e VIII seriam selecionados como as poucas causas vitais, se apenas fossem considerados 
erros sérios. 
Dessa forma, o importante é criar uma lista de possíveis causas e quantificar, por um determinado período de 
tempo, a incidência dos erros e assim desenvolver ações que eliminem os erros e inconsistências mais impactantes 
no desempenho do software. 
A ação corretiva focaliza principalmente as poucascausas vitais. Logo que as poucas causas vitais são corrigidas, 
novos erros despontam no topo da pilha. 
É certo que toda ação que visa eliminar e corrigir erros em softwares é suscetível a geração de novas causalidades 
mais ou menos graves que as anteriores, portanto, atente para o caso de realizar testes exaustivos para não 
comprometer de fato todo um sistema. 
Confiabilidade de software é: 
Em termos gerais, “a probabilidade de operação livre de falhas de um programa de computador num ambiente 
específico durante determinado tempo especificado”. Musa (1987) citado por Pressman(2002, pg. 768). 
Também considerar que um número mínimo de falhas ocorrerá na execução de um software dada garantia de que 
atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo. 
EXEMPLO: 
Suponha um software que tenha como confiabilidade de 0,98, por oito horas corridas de processamento. Significa 
dizer que, se o software for executado 100 vezes por um tempo de oito horas de tempo de execução, é provável que 
funcione corretamente 98 das 100 vezes. 
Confiabilidade de Software 
A confiabilidade consiste em considerar que um número mínimo de falhas ocorrerá na execução de um software 
dada a garantia de que atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo. 
O percentual de confiabilidade definido para cada processo na engenharia de software é muito relativo, pois 
dependerá da complexidade e importância do processo para o sucesso do sistema. Por exemplo, o sistema que 
monitora todo o processo de aquecimento da caldeira de uma siderúrgica precisa de um percentual de 
confiabilidade muito próximo a 100 %. Trata-se de um processo ininterrupto, ativo por 24 horas, pois, caso ocorra o 
desligamento da caldeira, o custo de reaquecimento será extremamente alto. Portanto, alguns processos 
automatizados precisam necessariamente de percentuais de confiabilidade altos e outros nem sempre. 
Alguns fatores são responsáveis pela presença de falhas nos softwares decorrentes de falhas de hardware devido a 
desgaste físico e não a defeitos. Exemplos comprovados desse fato estão presentes nos efeitos de temperatura, 
de corrosão e de choque térmico. Todavia, nos softwares, essas falhas não são justificadas plenamente, apesar de 
alguns estudiosos da área de qualidade considerarem a existência de uma relativa ligação irrefutável – confiabilidade 
de hardware e sua aplicabilidade ao software.Nesse contexto, ainda há de se considerar a questão da 
disponibilidade de software como a probabilidade de que um programa esteja operando de acordo com os 
requisitos em determinado ponto do tempo. Quando se tem uma medida de disponibilidade alta para um software, 
a razão torna-se inversamente proporcional à capacidade de manutenção do software. 
Segurança de software é: 
Uma atividade de garantia da qualidade de software que detecta e avalia riscos em potencial, que podem provocar 
falhas e impactar o desempenho de todo o sistema. 
É também considerada uma atividade de garantia de qualidade de software, que se concentra na identificação e 
avaliação de causalidades em potencial que possam exercer impacto negativo sobre o software e provocar falhas no 
sistema. 
Para a implementação da segurança, considera-se a necessidade de identificar a presença de riscos o mais cedo 
possível, de forma a possibilitar que estratégias sejam traçadas no projeto de software que eliminem ou controlem 
esses riscos em potencial. Atualmente, o hardware e o software de computador são usados regularmente para 
controlar sistemas de segurança críticos. O passo seguinte seria analisar, por meio de técnicas, a gravidade e a 
probabilidade de ocorrência. Algumas técnicas são aplicáveis tais como a análise da árvore de falhas e a lógica de 
tempo real. 
 
Após a identificação e análise das causalidades, uma lista de requisitos de segurança pode ser especificada para o 
software. A lista contém os requisitos indesejáveis e paralelamente, são elaboradas as respostas desejadas do 
sistema a esses eventos. A partir dessa ação, o software se encarrega de gerenciar os eventos indesejáveis. 
Princípios da ISO 9000 
Até aqui, conhecemos um pouco mais sobre a garantia estatística da qualidade. A partir de agora, trataremos da 
abordagem da norma ISO 9000. 
A ISO 9000 descreve os elementos de garantia em termos genéricos, que podem ser aplicados a qualquer negócio 
independentemente dos produtos ou serviços oferecidos. 
Dessa forma, um sistema de garantia da qualidade que promove a estrutura organizacional, define 
responsabilidades, cria procedimentos e processos, capacita recursos para implementar a gestão da qualidade em 
todo ciclo de vida de um produto, certamente, demanda de uma intervenção normativa para que materiais, 
produtos, processos e serviços satisfaçam as expectativas do cliente, de acordo com suas especificações. 
A adoção das normas ISO é vantajosa para as organizações, uma vez que lhes confere: 
Gestão: Prover confiança a própria administração de que seus produtos atenderão à satisfação dos clientes. 
Garantia: Prover confiança aos clientes de que os produtos atenderão à sua satisfação. 
O ganho para as organizações com a adoção das normas ISO está na produtividade e credibilidade aumentando a sua 
competitividade nos mercados nacional e internacional. 
Modelos da norma ISSO 9000: 
ISO 9001: Garantia da qualidade em projetos/desenvolvimento, produção, instalação e assistência técnica. 
ISO 9002: Garantia da qualidade em produção e montagem, instalação, prestação de serviço. 
ISO 9003: Garantia da qualidade em inspeção e testes finais. 
ISO 9004: Gestão da qualidade e elementos do sistema de qualidade – diretrizes. 
 
 
Princípios ISO 9000:2000 
• Foco no cliente. 
• Liderança. 
• Envolvimento das pessoas. 
• Abordagem de processo. 
• Abordagem sistêmica para a gestão. 
• Melhoria contínua. 
• Abordagem para tomada de decisões. 
• Benefícios mútuos nas relações com fornecedores. 
 
 
Segundo Pressman (2002), os modelos de garantia da qualidade ISO 9000 tratam uma empresa como uma rede de 
processos interconectados. Todos os processos organizacionais devem se referir às áreas identificadas na norma e 
devem ser documentados e praticados como descrito na imagem. Dessa forma, afirma-se que a organização dispõe 
de um sistema de qualidade que esteja em conformidade com a ISO. 
Nesta aula, você aprendeu: 
 Para conduzir adequadamente a garantia da qualidade de software, dados sobre o 
processo de desenvolvimento de software devem ser coletados, avaliados e disseminados. 
 SQA estatística ajuda a aperfeiçoar a qualidade do produto e o próprio processo de 
software. 
 Modelos de confiabilidade de software ampliam as medições, permitindo que dados de 
defeitos coletados sejam extrapolados para taxas projetadas de falha e previsões de 
confiabilidade. 
 A certificação ISO 9000 surge como uma alternativa à melhoria do processo produtivo, 
gerando produtos e serviços de alta qualidade para o cliente. 
 Atualmente, a certificação ISO 9000 é considerada como estratégia competitiva nas 
organizações empresariais para alcançar a diferenciação e galgar novas oportunidades em 
um mercado global cada vez mais competitivo. 
Na próxima aula, continuaremos com o estudo sobre a ISO 9000 com uma descrição mais detalhada das principais 
normas aplicadas a qualidade do produto de software ou a qualidade do processo de software. 
 
1. 
A garantia estatística de qualidade de software apóia-se na freqüência de ocorrência de erros e inconsistências nos 
softwares rastreados ao longo de um período específico de tempo. Escolha a alternativa que classifica o tipo de 
análise para a ocorrência de erros. 
 1) Qualitativa 
 2) Quantitativa 
 3) Descritiva 
 4) Subjetiva 
 5) Objetiva 
 2 
2. 
A confiabilidade consiste em considerar que um número de falhas ocorrerá na execução de um software dadagarantia de que atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo. A 
quantidade determinada de ocorrência de falhas é: 
 1) Máxima 
 2) Média 
 3) Mínima 
 4) Ponderada 
 3 
3. 
Em termos gerais, Musa (1987) citado por Pressman(2002, pg. 768), define a confiabilidade de um software como : 
 1) a probabilidade de operação livre de falhas de um programa de computador num ambiente específico durante 
determinado tempo especificado. 
 2) a probabilidade de operação com falhas de um programa de computador num ambiente aberto durante determinado 
tempo especificado”. 
 3) a probabilidade de operação com falhas de um programa de computador num ambiente aberto durante um tempo 
especificado e indeterminado”. 
 4) a probabilidade de operação sem falhas de um programa de computador num ambiente aberto durante determinado 
tempo especificado”. 
 1 
4. 
Trata-se de uma atividade de garantia da qualidade de software que detecta e avalia riscos em potencial, que podem 
provocar falhas e impactar o desempenho de todo o sistema. O conceito é pertinente a: 
 1) Confiabilidade de software 
 2) Gerência de risco 
 3) Qualidade de software 
 4) Segurança de software 
 4 
 
SQA Garantia de Qualidade de Software 
1. O que é e o que faz a ISO? 
• ISO=International Organization Standardization. 
• Orgão, de origem inglesa, que produz normas internacionais. 
• 150 países participantes e cerca de 50 mil especialistas(Mundo) 
2. O que é e o que faz a IEC? 
• IEC=International Eletrotechnical Commision 
3. O que é o o que faz a ABNT? 
• Orgão brasileiro responsável pelas normas de qualidade 
• Representa, no Brasil a ISO e a IEC 
• Cuida da preparação das normas técnicas, mas também pode verificar a implantação e uso das normas em empresas 
4. O que representa a adequação a uma norma, para uma empresa? 
• A adequação a uma norma consiste em colocar em prática, total ou parcialmente, a que ela se propõe. 
• A adequação pode ser obtida por consultoria ou de forma autônoma. 
5. O que representa a certificação em uma norma, para uma empresa? 
• Envolve a participação de organismo ou empresa externa, credenciada e que possa atestar que a empresa segue a resptiva 
norma, 
• Obviamente a adequação deve preceder a certificação. 
6. A certificação deve abranger todas as partes da norma? 
• Não. Normalmente a certificação é pontual, podendo ater-se a partes específicas da norma. 
7. O fato de uma empresa ter certificação ISO 9000, significa que seus produtos ou serviços possuem qualidade? 
• Não, Pode ser que apenas um determinado setor cumpra a norma. 
8. A certificação é válida para sempre, uma vez que foi obtida? 
• Não. A certificação vale por certo período de tempo, durante o qual há acompanhamento da certificadora: Testes com 
amostras (produtos) ou visitas e inspeções (gerenciamento e processos) 
• A empresa pode até perder seu certificado 
 
• SQA Estatístico é importante pois temos uma noção numérica de falhas, problemas e erros por CATEGORIAS. 
• Ajuda a aperfeiçoar Processo de Produto 
• Confiabilidade é uma métrica importante, mas dificil de mensurar  é um quesito base : confiar no resultado é fundamental. 
• Segurança é essencial ao SW moderno, levando a uma análise de riscos. 
• A ISO 9000 surge como alternativa para melhoria do processo produtivo das empresas, gerando produtos e servicos mais 
competiticos no mercado Nacional e Internacional. 
• A certificação ISO surge como diferencial competitivo, sendo estratégico para corporação atingir patamares diferenciados e 
oportunidades num mercado Global. 
Aula 4: NBR ISO/IEC 9126 (produto de software) e NBR ISO/IEC 12119 (pacote 
de software) 
Ao final desta aula, você será capaz de: 
 
1. Definir o modelo de qualidade do produto de software da Norma NBR ISO/IEC 9126. 
2. Descrever as características de qualidade internas e externas. 
3. Apresentar as métricas de softwares da Norma NBR ISO/IEC 9126. 
4. Definir o modelo de qualidade do produto de software da Norma NBR ISO/IEC 12119. 
5. Compreender o que significa um pacote de software a partir da definição de um conjunto de requisitos de 
qualidade. 
6. Definir as instruções de requisitos de qualidade para a realização de testes. 
Normas – Qualidade de Produto de Software 
A NBR ISO/IEC 9126-1, publicada em 1991, apresenta uma definição de qualidade como sendo a "totalidade de 
características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas" 
(2003, p.17). 
As necessidades explícitas (ou externas) dependem do que foi especificado nos requisitos referentes às condições 
em que o produto deva ser utilizado, seus objetivos, funções e o desempenho esperado. Já as implícitas (ou 
diretas) são necessidades que embora não estejam especificadas nos requisitos, devem ser levadas em 
consideração, pois se baseiam em princípios básicos e óbvios, necessários para que o usuário execute a sua tarefa. 
Essas duas necessidades são muito importantes, pois são elas que fornecem subsídios para a criação das validações 
e verificações que ocorrem durante todo o ciclo de vida do sistema. Dentre elas, pode-se citar o teste de software 
como uma grande ferramenta para garantir a qualidade do software. 
No entendimento da NBR ISO/IEC 9126 as necessidades explícitas e implícitas são entendidas como características 
e subcaracterísticas básicas de um produto de software que vise à presença da qualidade. As definições de 
características e subcaracterísticas de qualidade nos permitem perceber um possível universo de requisitos que se 
enquadram no conceito de qualidade. 
A Norma ISO/IEC 12119 é aplicável a pacotes de software, como por exemplo, pacotes de software voltados para 
funções administrativas, técnicas ou científicas, comunicação de escritórios e outras finalidades, tal como são 
produzidos. Outros exemplos, incorporados aos pacotes de software compreendem os processadores de texto, 
planilhas eletrônicas, bancos de dados, softwares gráficos, programas para funções técnicas ou científicas e 
programas utilitários. Aplicável à avaliação de pacotes de software na forma em que são oferecidos e liberados para 
uso no mercado e não aos processos de desenvolvimento e fornecimentos de software. 
Por pacotes de software entende-se como o conjunto completo e documentado de programas fornecidos a diversos 
usuários para uma aplicação ou função genérica. É conhecido também como software de prateleira. A norma 
estabelece um conjunto de requisitos de qualidade para pacotes de software, instruções em como executar testes 
em um pacote de software, em destaque para testes realizados por terceiros. 
Os requisitos de qualidade incluem que: i) cada pacote de software deve ter uma descrição do produto e 
documentação do usuário; ii) a descrição de produtos deve conter informações que sejam testáveis e corretas e, iii) 
requisitos para a documentação do usuário, programas e dados que façam parte do pacote. 
A descrição do produto inclui as principais propriedades do pacote. A documentação do usuário nada mais é que um 
documento que será avaliado em relação à sua completitude, correção, consistência, inteligibilidade, apresentação e 
organização. 
A garantia e controle de qualidade no desenvolvimento de software ao operarem simultaneamente, visam garantir 
que os artefatos de software sejam desenvolvidos e entregues com melhor aceitabilidade, menos defeitos e 
menores custos. 
Garantia de software  Promove a gerência sênior da organização uma melhor visibilidade apropriada sobre o 
processo de desenvolvimento. 
Controle de Qualidade  Objetiva testar os produtos de software de modo a encontrar, relatar e remover seus 
defeitos. 
Em contrapartida, na visão do usuário do software , são percebidas as necessidades de qualidade em uso do produto 
de software no contexto especificado para uso. Essas necessidades identificadas, por sua vez,podem ser usadas 
quando se especifica qualidade externa e interna usando características e subcaracterísticas de qualidade do 
produto de software. 
A qualidade do produto de software pode ser avaliada pela medição: dos atributos internos (tipicamente medidas 
estáticas de produtos intermediários); dos atributos externos (tipicamente medidas do comportamento do código 
quando executado); dos atributos de qualidade em uso. 
O objetivo é que o produto tenha o efeito desejado em um contexto particular de uso. 
Modelo de qualidade de software 
A qualidade de produto de software deveria ser avaliada utilizando um modelo de qualidade previamente definido. 
O modelo de qualidade deve ser usado quando se estabelecem metas de qualidade para produtos de software e 
produtos intermediários. A qualidade do produto de software deve ser hierarquicamente decomposta para um 
modelo de qualidade com características e subcaracterísticas que podem ser usadas como um checklist de assuntos 
relacionados à qualidade. 
É praticamente impossível medir todas as subcaracterísticas de todas as partes de um grande produto de software. 
Similarmente, não é prático medir qualidade em uso de todos os possíveis cenários de tarefas do usuário. Recursos 
para avaliação precisam ser alocados entre os diferentes tipos de medições dependendo dos objetivos do negócio e 
da natureza do produto e do processo. 
 Qualidade de uso e Qualidade Interna e Externa. 
A norma NBR ISO/IEC 9126 apresenta, de certa maneira, os instrumentos necessários para realizar uma avaliação, 
descrevendo de forma ampla como medir qualitativamente e quantitativamente a “presença” de qualidade, 
formando assim um modelo de qualidade para produto. De acordo com a Associação Brasileira de Normas Técnicas 
– ABNT, a série da NBR ISO/IEC 9126 se subdivide da seguinte forma: 
 
O modelo de qualidade para produto de software tem como público alvo desenvolvedores de software, adquirentes, 
equipe de qualidade assegurada e avaliadores. 
Por adquirente entende-se uma organização que obtém, adquire ou intermedia a compra de um sistema, produto de 
software ou serviço de software de um fornecedor. O adquirente pode ser um comprador, cliente, proprietário ou 
usuário. 
No âmbito da norma NBR ISO/IEC 9126-1, um modelo de qualidade cujo componente seja o produto de software 
deve estabelecer metas de qualidade tanto para produtos finais e intermediários. 
Assim, torna-se interessante considerar o uso de um modelo de qualidade composto de características e 
subcaracterísticas que podem ser usadas como uma lista de verificação (checklist) de assuntos relacionados à 
qualidade interna e externa de produtos. 
Para Pressman (2002), o uso de um modelo de qualidade apoia a categorização de fatores de McCall (1997), o 
contexto, a partir da qualidade interna e externa, passa a ser categorizado por seis características: 
 
São subdivididas em subcaracterísticas, conforme apresentado na Figura 1 que segue a especificação da NBR ISO/IEC 
9126-1. Cada subcaracterística pode ser medida por meio de métricas internas e externas. 
Para cada característica e subcaracterística, a capacidade do software é determinada por um conjunto de atributos 
internos que podem ser medidos. As características e subcaracterísticas atuam como fatores que alteram a 
qualidade de software interna e externa. Como veremos a seguir. 
 
Princípios da ISO 9000 
Até aqui, conhecemos um pouco mais sobre a garantia estatística da qualidade. A partir de agora, trataremos da 
abordagem da norma ISO 9000. 
A ISO 9000 descreve os elementos de garantia em termos genéricos, que podem ser aplicados a qualquer negócio 
independentemente dos produtos ou serviços oferecidos. 
Dessa forma, um sistema de garantia da qualidade que promove a estrutura organizacional, define 
responsabilidades, cria procedimentos e processos, capacita recursos para implementar a gestão da qualidade em 
todo ciclo de vida de um produto, certamente, demanda de uma intervenção normativa para que materiais, 
produtos, processos e serviços satisfaçam as expectativas do cliente, de acordo com suas especificações. 
 
Então, a avaliação e melhoria de um processo é um meio para melhorar a qualidade do produto, e a avaliação e 
melhoria da qualidade do produto é um meio de melhorar a qualidade em uso. Similarmente, a avaliação da 
qualidade em uso pode dar um feedback para melhorar o produto e a avaliação da qualidade do produto pode dar 
feedback para melhorar o processo. 
Pense nisso... 
Os atributos internos adequados do software tornam-se um pré-requisito para alcançar o comportamento externo 
desejado, que por sua vez, é um pré-requisito para alcançar a qualidade. Os requisitos de qualidade do produto de 
software geralmente incluem critérios de avaliação para qualidade interna, qualidade externa e qualidade em uso, 
para corresponder às necessidades dos desenvolvedores e usuários finais. 
Um processo pode ser avaliado indiretamente pela medição e avaliação do produto, e o produto pode ser avaliado 
indiretamente pela medição do desempenho da tarefa de um usuário (utilizando métricas de qualidade em uso). 
Interessante observar que um software nunca é executado sozinho, mas sempre como parte de um sistema maior, 
que tipicamente, consiste de outros produtos de software que tem sua interface, hardware, operadores e fluxo de 
trabalho. O produto de software completo pode ser avaliado pelos níveis de métricas externas escolhidas. 
Nos primeiros estágios de desenvolvimento somente recursos e processos podem ser medidos. 
Quando produtos intermediários se tornam disponíveis (especificações, código fonte, etc), eles podem ser avaliados 
pelas métricas internas escolhidas. Essas métricas podem ser usadas para prever valores de métricas externas. 
Considera-se que a qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de 
qualidade em uso, por métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por 
métricas deveriam ser usados como critério quando um produto é validado. 
É importante considerar que a qualidade em uso consiste na qualidade percebida pelo usuário e na aferição da 
qualidade do software em cada contexto específico de usuário. 
Essas métricas visam descrever a interação com o ambiente e são avaliadas pela observação do software em 
operação. Qualidade em uso pode ser medida pelo quanto um produto em uso atinge as necessidades do usuário 
em termos de efetividade, produtividade, segurança e satisfação. 
A qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de qualidade em uso, por 
métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por métricas deveriam ser 
usados como critério quando um produto é validado. 
A execução de um produto que satisfaça as necessidades do usuário normalmente requer uma abordagem interativa 
no desenvolvimento do software, com contínuo feedback da perspectiva do usuário. Para tanto, algumas 
características de qualidade são pertinentes à aquisição de qualidade de produto de software, na visão do usuário. 
Qualidade em Uso é a visão de qualidade que o usuário tem do software e é medida em termos do resultado da 
utilização do software. É a capacidade que o produto de software tem de atender aos anseios e às necessidades dos 
usuários em seu próprio ambiente de trabalho. É, portanto, a capacidade de software permitir a usuários específicos 
atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso 
especificado. 
Qualidade em uso 
A Norma ISO/IEC 9126-4 define as métricas de qualidade para as seguintes características: 
Eficácia: Usuários são capazes de atingir metas especificadas com acurácia e completitude. 
Produtividade: Usuários empregam quantidade adequada de recursos em relação à eficácia obtida. 
Segurança: Presença de níveis aceitáveisde riscos de danos a pessoas, negócios, software, propriedades ou ao 
ambiente. 
Satisfação: Satisfazer usuários de acordo com as especificações do produto de software. 
 
 
Métricas de qualidade de acordo com a Norma ISO/IEC 9126-1 
A precisão da qualidade depende, em grande parte, das métricas escolhidas. Para aumentar a confiabilidade dos 
resultados são necessárias algumas características que as métricas deveriam apresentar, de acordo com o requisitos 
especificados na NBR ISO/IEC 9126-1(item 6.4). 
Significância: As métricas relevantes devem agregar informações sobre o comportamento do software, porém as não 
relevantes devem ser descartadas. 
Custo e complexidade: Aplicação da métrica deve ser econômica e tecnicamente viável. Destaca-se que algumas 
métricas não satisfazem esse critério por demandarem um investimento acima do orçamento(laboratórios e 
usuários-teste) ou demandar técnicas sofisticadas como métodos estatísticos. 
Repetibilidade: Os resultados gerados devem ser idênticos ao aplicar a medição: i) no mesmo produto; ii) com a 
mesma especificação de requisitos; iii) com os mesmos avaliadores, usuários-testes e ambiente. 
Reprodutibilidade: s resultados gerados devem ser idênticos ao aplicar a medição: i) no mesmo produto; ii) com a 
mesma especificação de requisitos; iii) com diferentes avaliadores, usuários-testes e ambiente. 
Validade: Necessidade de demonstrar correção e precisão em todos os fatores que podem influir no resultado como: 
> característica de hardware como por exemplo, uma má conexão de cabos de rede; 
> característica de configuração de parâmetros do sistema operacional e do próprio software em desacordo ; 
> percepção dos avaliadores no processo de julgamento de definições de botões, janelas, menus em discordância; 
> utilização de modelos matemáticos passíveis de manipulação devem ser explicitados. 
Objetividade: Ausência de subjetividade dos resultados da medição, isto é, não devem sofrer influência de opinião 
de avaliadores, usuários-teste, etc. A medição estatística deve ser aplicada caso não seja possível manter a 
objetividade. 
Imparcialidade: A medição não deve ser tendenciosa, ou seja, preservar a publicação dos resultados na íntegra e, 
distribuir o resultado em um ambiente que seja o mais confiável possível. 
Considera-se que a aplicação das métricas de avaliação do software depende em grande parte do grau de 
sofisticação do processo de avaliação. 
Estrutura da ISO/IEC 12119 
Até aqui, tratamos de modelos de qualidade de produto de software focados na norma NBR ISO/IEC 9126. Agora , 
focaremos na norma NBR ISO/IEC 12119. IMPORTANTE: será iniciada uma outra norma 12119. 
 
Requisitos de Qualidade 
Descrição do produto: Consiste em um documento expondo as propriedades de um pacote de software, com o 
principal objetivo de auxiliar os potenciais compradores na avaliação da adequação do produto antes de sua 
aquisição. Fornece informações sobre a documentação do usuário, programas e, se existirem, sobre os dados. Inclui 
as principais propriedades do pacote e é um documento disponível ao usuário independente da aquisição do 
produto. As declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e 
portabilidade devem ser avaliadas. 
Documentação do Usuário: Trata-se de um conjunto completo de documentos disponível na forma impressa ou 
não, que é fornecido para a utilização de um produto, sendo também uma parte integrante do produto. Deve incluir 
todos os dados necessários para a instalação, para o uso da aplicação e para a manutenção do software produto. 
Deve fazer referência a completude, correção, consistência, inteligibilidade, apresentação e organização. 
Programas e dados: Os requisitos de qualidade para Programas e Dados utilizam as mesmas definições das 
características da norma ISO/IEC 9126. Descreve em detalhes cada uma das funções do software, incluindo 
declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 
Instruções para teste 
 
Os usuários da Norma ISO/IEC 12119 são em grande parte os fornecedores de software, órgãos de certificação, 
laboratórios de teste, auditores, compradores e usuários de software. 
Vamos ver todos esses conceitos na prática? 
Visite uma empresa de desenvolvimento de software e solicite uma participação na equipe de testes para o 
acompanhamento e levantamento de dados a respeito do tipo e dos tempos entre a ocorrência de falhas, a fim de 
mostrar se a confiabilidade está aumentando. 
 Elabore uma tabela de tipos e incidência de falhas, de acordo com a tabela apresentada para identificação dos 
passos para a SQA estatística (aula anterior). Elabore uma análise crítica da qualidade de software utilizando as 
características e subcaracterísticas pertinentes a NBR ISO/IEC 9126, tais como: 
Maturidade: capacidade de evitar defeitos no software. 
Tolerância a Falhas: capacidade de manter um nível de desempenho estabelecido em caso de defeito no software 
Recuperabilidade: capacidade de recuperar dados diretamente afetados no caso de falhas. 
Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à confiabilidade. 
Estude a questão que trata sobre as diferenças de confiabilidade de hardware e de software. 
Nesta aula você aprendeu que: 
 
Um dos grandes méritos desta norma está na profundidade com que são descritas cada uma das características e 
subcaracterísticas mencionadas na norma 9126. A norma inclui detalhes que devem estar presentes no produto, tais 
como: 
 Descrição do produto compreensível e completa para ajudar o usuário ou comprador em 
potencial na avaliação da adequação do produto a sua realidade e fornecer informações 
comerciais; 
 Documentação do usuário de fácil compreensão, permitindo uma visão geral do produto e 
de todas as suas funções, identificando conhecimento necessário para uso da aplicação; 
 Identificação do tipo de interface com o usuário: interface gráfica, linha de comando, 
menu de comandos, janelas, etc; 
 Instruções detalhadas sobre como instalar o produto, caso a instalação possa ser 
conduzida pelo usuário; 
 Possibilidade de verificar se a instalação foi bem sucedida; 
 Especificação de valores-limite para quantidade de registros e dados de entrada, como, 
por exemplo, precisão de casa decimal; 
 Operação normal, mesmo quando os dados informados estão fora dos limites 
especificados; 
 Consistência de vocabulário entre as mensagens e a documentação; 
 Função de auxílio (help) sensível ao contexto; 
 Mensagens de erro com informações necessárias para solucionar o problema; 
 Diferenciação de tipos de mensagem: confirmação, consulta, advertência e erro; 
 Clareza e padronização nos formatos de telas de entrada, relatórios e outras entradas e 
saídas; 
 Capacidade de reverter funções de efeito drástico; 
 Capacidade de recuperar dados após uma falha de hardware ou software, queda de 
energia ou erro fatal; 
 Alertas claros para o usuário das conseqüências de uma determinada confirmação; 
 Identificação dos arquivos utilizados pelo programa; 
 Identificação da função do programa que está sendo executada no momento; 
 Capacidade de interromper um processamento demorado. 
Também estão incluídos o teste de inspeção dos documentos e o teste funcional (caixa preta - 
considera se os dados de entrada e observa se a saída está de acordo com o esperado). 
O teste estrutural não é incluído por requerer a disponibilidade do código-fonte. Somente o 
produto, no seu ambiente de hardware e software, é testado. A avaliação ergonômica do 
ambiente de uso do sistema computacional não é considerada na Norma NBR 12119. 
Os anais da International Conference on Software Engineering geralmente contêm bons artigos sobre as mais 
recentes teorias de teste. Por exemplo, alguns casos de estudo examinam as diferenças entre os testes para 
aumentara confiabilidade e os testes para encontrar defeitos. Investigue também sobre o teste de usabilidade. 
Um sistema correto e confiável, mas difícil de ser utilizado, pode, na verdade, ser pior do que um que seja fácil 
de ser utilizado, mas não seja confiável. 
Na próxima aula será tratada a questão da usabilidade de software de acordo com os principais pressupostos da 
norma NBR ISO/IEC 9241. 
 
 
 
 
1. 
Segundo McCall (1977), muitas das métricas só podem ser medidas subjetivamente. Por isso, considera importante, mais uma 
vez, a utilização de uma técnica para graduar atributos específicos do software. Qual seria essa métrica? 
 1) Diagrama de Causa-Efeito 
 2) Gráfico de Pareto 
 3) Lista de Verificação (checklist) 
 4) Diagrama PERT-COM 
 5) Seis Sigma 
 3 
2. 
Segundo a ISO/IEC 9126-1, a precisão da qualidade depende, em grande parte, das métricas escolhidas para que se possa 
aumentar a confiabilidade dos resultados. Escolha a alternativa que melhor especifica todas as métricas necessárias para o 
alcance de resultados positivos na qualidade de produto de software. 
 1) significância, custo e complexidade, repetibilidade, reprodutibilidade, validade, objetividade, imparciabilidade. 
 2) complexidade, repetibilidade, significância, validade, imparciabilidade, continuidade 
 3) custo e complexidade, reprodutibilidade, validade, objetividade, significância 
 4) simplicidade, objetividade, custo, unicidade, subjetividade 
 5) significância, repetibilidade, reprodutibilidade, simplicidade, unicidade, validade, continuidade, imparcialidade. 
 1 
3. 
A ISO/IEC 9126 determina a especificação de qualidade interna, externa e em uso para os produtos de software. Escolha as 
alternativa que determina somente a qualidade externa. 
 1) Funcionalidade 
 2) Maturidade 
 3) Tolerância a erros 
 4) Recuperabilidade 
 1 
Aula 5: ISO/IEC 9241 – Usabilidade de Produto 
1. Entender a norma ISO/IEC 9241 com foco na parte que destaca as orientações para usabilidade de software. 
O objetivo de projetar e avaliar computadores buscando usabilidade consiste em proporcionar que os objetivos 
sejam alcançados pelos usuários bem como satisfaçam suas necessidades em um contexto particular de uso. 
Desta forma, a ISO/IEC 9241-11 esclarece os benefícios de medir usabilidade em termos de desempenho e 
satisfação do usuário, a usabilidade dos computadores depende do contexto de uso e afirma que o nível de 
usabilidade alcançado dependerá das circunstâncias específicas nas quais o produto é usado. 
Para tanto, a ISO/IEC 9241 consiste das seguintes partes, sob o título geral de Requisitos ergonômicos para 
trabalho de escritório com computadores: 
Parte 1: Introdução Geral 
Parte 2: Orientações sobre requisitos da tarefa 
Parte 3: Requisitos para apresentação visual 
Parte 4: Requisitos para teclado 
Parte 5: Requisitos posturais e de layout para posto de trabalho 
Parte 6: Requisitos para ambiente 
Parte 7: Requisitos para monitores quanto à reflexão 
Parte 8: Requisitos para apresentação de cores 
Parte 9: Requisitos para outros dispositivos de entrada que não o teclado 
Parte 10: Princípios de diálogo 
Parte 11: Orientações sobre usabilidade 
Parte 12: Apresentação da informação 
Parte 13: Orientações ao usuário 
Parte 14: Diálogos por menu 
Parte 15: Diálogos por linguagem de comando 
Parte 16: Diálogos por manipulação direta 
Parte 17: Diálogos por preenchimento de formulário 
Especificamente, nessa aula, o foco será dado a parte da norma 9241-11 que emprega o termo usabilidade 
algumas vezes para referenciar mais precisamente os atributos de um produto que o torna mais fácil de usar 
(hardware, software ou serviços), além das medidas relevantes de usabilidade. 
A orientação é mais na forma de princípios e técnicas gerais, em vez de requisitos para usar métodos específicos 
quando considerada as fases de aquisição, projeto, desenvolvimento, avaliação, e comunicação da informação 
sobre usabilidade. 
A ISO 9241-11 também explica como medidas de desempenho e satisfação do usuário podem ser usadas para 
medir como qualquer componente de um sistema afeta todo o sistema de trabalho em uso. 
Complementando, a ISO 9241, partes 12 a 17, fornece recomendações condicionais que são aplicadas em 
contextos de uso específico. As partes orientam para identificar a aplicabilidade de recomendações individuais. 
A ISO 9241-11 não cobre os processos de desenvolvimento de sistema. Os processos de projeto centrados no ser 
humano para sistemas interativos são descritos na ISO 13407. 
A seguir, definem-se alguns efeitos da norma: 
Usabilidade: Medida na qual um produto pode ser usado por usuários específicos para alcançar objetivos 
específicos com eficácia, eficiência e satisfação em um contexto específico de uso. 
Eficácia: Completude com as quais usuários alcançam objetivos específicos. 
Eficiência: Recursos gastos em relação à acurácia e abrangência com as quais usuários atingem objetivos. 
Satisfação: Ausência do desconforto e presença de atitudes positivas para com o uso de um produto. 
Contexto de uso: Usuários, tarefas, equipamento (hardware, software e materiais), e o ambiente físico e social no 
qual um produto é usado. Sistema, composto de usuários, equipamento, tarefas e o ambiente físico e social, com o 
propósito de alcançar objetivos específicos. 
Usuário: Pessoa que interage com o produto. 
Objetivo: Resultado pretendido. 
Tarefa: Conjunto de ações necessárias para alcançar um objetivo. 
Produto: Parte do equipamento (hardware, software e materiais) para o qual a usabilidade é especificada ou 
avaliada. 
Medida (substantivo): Valor resultante da medição e o processo usado para obter tal valor. 
A justificativa da usabilidade de produtos se faz pela incorporação de características e atributos conhecidos como 
capazes de beneficiar os usuários em um contexto particular de uso. A partir disso, para se determinar o nível de 
usabilidade alcançado junto ao usuário é necessário medir o desempenho e satisfação destes trabalhando com um 
produto. A medição possibilita visualizar a complexidade das interações entre o usuário, os objetivos, as 
características da tarefa e os outros elementos do contexto de uso. A cada circunstância ambiental, diferentes 
níveis de usabilidade podem ser definidos. 
 
Contexto de uso 
O nível no qual o objetivo global pretendido é estabelecido é uma função do limite do sistema de trabalho em 
consideração e que fornece o contexto de uso, no que diz respeito a determinados elementos. Veja os 
componentes que requerem uma especificação de características de uso. 
Usuários: Consiste em definir as características de conhecimento, habilidade, experiência, educação, treinamento, 
atributos físicos e capacidades sensoriais e motoras. As experiências individuais dos usuários também são levadas 
em consideração quando desempenha diferentes funções. 
Ambiente: As características relevantes do ambiente físico e social precisam ser descritas. Os aspectos que podem 
ser necessários, por exemplo, a rede de trabalho local, o local de trabalho, mobiliário, temperatura, umidade, 
práticas de trabalho, estrutura organizacional e atitudes. 
Tarefas: Necessita da descrição das características das atividades que visam o alcance de um objetivo e que podem 
influenciar a usabilidade, como por exemplo, a freqüência e a duração de uma tarefa. Convém que qualquer 
descrição das atividades e passos envolvidos no desempenho da tarefa estejam relacionados aos objetivos a serem 
alcançados. 
Equipamentos: As características relevantes do equipamento tais como o hardware, software e materiais 
associados com o computador precisam ser descritos. O conjunto de produtos podem ser o foco da especificação 
ou avaliação de usabilidade, ou um conjunto de atributos ou características de desempenho do hardware, software 
ou outros materiais. 
A escolha e o nível de detalhes de cada medida (eficácia, eficiência e satisfação)depende dos objetivos das partes 
envolvidas na medição. 
Deve-se considerar a importância relativa de cada medida para os objetivos. Por exemplo, caso o uso não seja 
freqüente, pode ser dada grande importância para as medidas de aprendizado e re-aprendizado. 
Caso não seja possível obter medidas objetivas de eficácia e eficiência, medidas subjetivas baseadas na percepção 
dos usuários podem fornecer uma indicação de eficácia e eficiência. 
Veja a seguir cada uma das especificações das características de medidas de uso: 
Acurácia: Grau de exatidão ou precisão demonstrado por uma tabela ou operação. 
Eficácia: Relacionam aos objetivos ou sub-objetivos do usuário quanto a acurácia e completude com que estes 
objetivos podem ser alcançados. 
Exemplo: Se o objetivo desejado for reproduzir com acurácia um documento de duas páginas em um formato 
específico, então a acurácia pode ser especificada ou medida pelo número de erros de ortografia e pelo número de 
desvios do formato especificado e a completude pelo número de palavras do documento transcrito dividido pelo 
número de palavras do documento de origem. 
Eficiência: Relacionam o nível de eficácia alcançada ao dispêndio de recursos. Recursos relevantes podem incluir 
esforço mental ou físico, tempo, custos materiais ou financeiros. 
Exemplo: Se o objetivo desejado for imprimir cópias de um relatório, então a eficiência pode ser especificada ou 
medida pelo número de cópias usáveis do relatório impresso, dividido pelos recursos gastos na tarefa tal como 
horas de trabalho, despesas com o processo e materiais consumidos. 
Satisfação: Pode ser especificada e medida pela avaliação subjetiva em escalas de desconforto experimentado, 
gosto pelo produto, satisfação com o uso do produto ou aceitação da carga de trabalho quando da realização de 
diferentes tarefas ou a extensão com os quais objetivos particulares de usabilidade (como eficiência ou capacidade 
de aprendizado) foram alcançados. 
Exemplo: Outras medidas de satisfação podem ser: número de comentários positivos e negativos registrados 
durante o uso; informação adicional como taxas de absenteísmo, observação de sobrecarga ou subcarga de 
trabalho físico ou cognitivo do usuário, problemas de saúde relatados, freqüência com que os usuários requerem 
transferência para outro trabalho. 
A generalização dos resultados de qualquer medição de usabilidade para outro contexto qualquer deve ser evitada, 
pois certamente existem diferenças significativas de tipos de usuários, tarefas ou ambientes. 
Portanto, se as medidas de usabilidade são obtidas em curtos períodos de tempo, os valores podem não levar em 
consideração os eventos pouco freqüentes os quais podem ter um impacto significativo sobre a usabilidade, por 
exemplo, erros intermitentes do sistema. Para um produto de uso geral, geralmente será necessário especificar ou 
medir usabilidade em alguns contextos representativos diferentes, os quais serão um subgrupo de possíveis 
contextos e de tarefas que podem ser realizadas. 
Nesta aula você aprendeu: 
Que a usabilidade definida em termos de qualidade de um sistema de trabalho em uso depende, necessariamente, 
de todos os fatores que podem influenciar no uso de um produto do mundo real, incluindo fatores organizacionais 
tais como práticas de trabalho e localização ou aparência de um produto, e diferenças individuais entre usuários 
incluindo aquelas devido a fatores culturais e preferências. Esta ampla abordagem tem a vantagem que é 
concentrada no propósito real do projeto de um produto – que ele encontra as necessidades de usuários reais 
desenvolvendo tarefas reais em um ambiente organizacional, técnico, fisicamente e real. Isto é consistente com os 
objetivos da ISO 9241 como descrito na ISO 9241-1. 
Na próxima aula veremos como descrever o processo de avaliação de produto de software segundo a norma 
ISO/IEC 14598. 
 
1. 
A ISO/IEC 9241 é consistida em partes sob o título geral de Requisitos ergonômicos para trabalho de escritório com 
computadores. Qual o número corresponde às partes da norma? 
 1) 15 
 2) 11 
 3) 18 
 4) 17 
 5) 16 
 4 
2. 
A parte da norma que faz referência à orientação da usabilidade é: 
 1) 15 
 2) 11 
 3) 18 
 4) 17 
 5) 16 
 2 
3. 
Com relação à definição de usabilidade, segundo a norma, pode-se afirmar que consiste: 
 1) na medida na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com eficácia, 
eficiência e satisfação em um contexto específico de uso. 
 2) na completude com as quais usuários alcançam objetivos específicos. 
 3) nos recursos gastos em relação à acurácia e abrangência com as quais usuários atingem objetivos. 
 4) na ausência do desconforto e presença de atitudes positivas para com o uso de um produto. 
 1 
4. 
Quanto à especificação de características de componentes de uso, considera-se: 
 1) Usuário, tarefa e equipe. 
 2) Tarefa, equipamento e ambiente. 
 3) Usuário, tarefa, equipamento e ambiente. 
 4) Usuário, atividades, processos e procedimentos. 
 5) Equipamento, auditor, tarefa e ambiente. 
 3 
Aula 6: ISO/IEC 14598 - Avaliação de produto 
Ao final desta aula, você será capaz de: 
 
1. Entender o processo de avaliação de produto de software segundo a norma ISO/IEC 14598. 
A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de software e fornece 
guias para a avaliação, baseados na utilização prática da norma ISO/IEC 9126. 
 
Veja a relação entre as Normas desta série: 
 
ISO/IEC 14598-1 – Visão geral – fornece uma visão completa das outras partes da norma, as relações entre si e com 
o modelo de qualidade da norma ISO/IEC 9126. 
 ISO/IEC 14598-2 – Planejamento e gestão - fornece requisitos, recomendações e diretrizes para uma função de 
suporte e apoio responsável pela gestão da avaliação de produto de software e pelas tecnologias necessárias para 
a avaliação de produto de software. 
 ISO/IEC 14598-3 – Processo para desenvolvedores – Seleção e registro de indicadores que possam ser medidos e 
avaliados a partir dos produtos intermediários obtidos nas fases de desenvolvimento para a tomada de decisões 
estratégicas e gerenciais. 
 ISO/IEC 14598-4 - Processo para adquirentes - contém requisitos, recomendações e orientações para a medição, 
julgamento e avaliação sistemática da qualidade de produto de software durante a aquisição de produtos de 
software de prateleira, produtos de software sob encomenda ou modificações em produtos de software 
existentes. 
 ISO/IEC 14598-5– Processo para avaliadores – descreve um processo para avaliação de produtos de software. 
 ISO/IEC 14598-6 – Documentação de módulos de avaliação – estabelece requisitos e instruções a respeito de 
como testar um pacote de software em relação aos requisitos estabelecidos para o pacote. 
A proposta da ISO/IEC 14598 
Avaliar a qualidade de um produto de software é: Verificar, através de técnicas e atividades operacionais, o 
quanto os requisitos são atendidos. Tais requisitos, de uma maneira geral, expressam as necessidades explicitadas 
em termos quantitativos ou qualitativos e apresentam como objetivo a definição das características de um 
software, a fim de permitir o exame de seu entendimento. 
 
Pontos relevantes das partes 
Segundo a ISO/IEC 14598-2, a função de apoio à avaliação deve fornecer um suporte abrangente à organização 
para projetos de desenvolvimento de software, aquisição de software e avaliação de software. Ela pode ser interna 
ou externa à organização que está avaliando o software. 
Alguns papéis são relevantes, tais como: 
 
A função suporte à avaliação pode ser pensada no setor da organização encarregada de desenvolver, adquirir ou 
avaliar o software. 
As responsabilidades de avaliação e de garantia da qualidade devem constar em um plano que vise ao uso e 
melhoria da tecnologia de avaliação, implementação, transferência e avaliação da tecnologia de avaliaçãousada e, 
por fim, o gerenciamento da experiência de avaliar. 
Por outro lado, a função pode ser direcionada para o projeto de avaliação suportado pela organização. 
O suporte incluiu o planejamento da avaliação quantitativa e a promoção desse plano de avaliação e tecnologia 
utilizadas para outros projetos dentro da organização. 
A estrutura de um plano de avaliação quantitativa deve conter : 
 
O plano pode ser divulgado por meio de palestras e reuniões técnicas. 
A ISO/IEC 14598-4 ao referenciar o processo de aquisição definido pela ISO/IEC 12207 ressalta a existência das 
seguintes atividades: 
Iniciação: O adquirente inicia o processo de aquisição ao considerar a necessidade de obter, desenvolver ou 
melhorar um sistema, produto ou serviço de software. 
Preparação do pedido de proposta: Elaboração dos documentos de requisitos de aquisição bem como 
determinados os pontos de controle para revisão e auditoria do progresso do fornecimento. 
Preparação e atualização do controle: Seleção de fornecedores e suas capacidades firmadas em contrato e, 
negociado o custo, cronograma de execução. As mudanças no contrato devem ser controladas pelo adquirente. 
Monitoração do fornecedor: Consiste em atividades de avaliação durante a execução do contrato levando à 
aceitação e entrega do produto de software. 
Aceitação e conclusão: Aceitação e entrega do produto de software final, obedecidos aos critérios de aceitação 
previamente definidos durante a atividade de iniciação. 
A ISO/IEC 14598-5 – processo para o avaliador que visa fornecer requisitos e recomendações para a correta 
implementação prática de avaliação de produto de software. Conta com a participação de avaliadores de 
laboratório, fornecedores e adquirentes de software, usuários e entidades certificadoras que defendem objetivos 
diferentes. 
 
Pode ser aplicada tanto para produto existente como para produtos em desenvolvimento. 
Além das partes envolvidas no processo, a norma descreve um procedimento passo a passo dos requisitos de 
avaliação expressos com as devidas características de qualidade. 
 
O processo de avaliação envolve um conjunto de atividades conduzidas pelo requisitante da avaliação e pelo 
avaliador que iniciam o trabalho a partir do uso dos dados fornecidos pelo requisitante, pelo avaliador ou por outros 
meios e atividades do conjunto. 
 
 
As atividades do processo de avaliação são as seguintes: 
Estabelecimento de requisitos de avaliação: Descrição dos objetivos da avaliação coerentes com o produto de 
software e possíveis riscos associados. As percepções dos usuários do produto, fornecedores, compradores, 
desenvolvedores, operadores e mantenedores do produto devem ser levados em consideração. 
Especificação da avaliação: Definição do escopo da avaliação e as medições a que o produto será submetido. 
Dependente dos requisitos de avaliação previamente definidos pelo requisitante. 
Projeto de avaliação: Preparo de um plano de ação de acordo com a especificação do avaliador e com base nos 
métodos a serem usados para a realização das medições estabelecidas na especificação. Um documento guarda, 
portanto, as especificações da avaliação, o cronograma, os recursos necessários e disponíveis para realizar a 
avaliação. 
Execução da avaliação: Consiste na inspeção, medição e teste dos produtos e de seus componentes aplicados de 
acordo com as orientações do plano. Aplicadas as ações de medição, segue-se para as interpretações dos resultados 
registrados e depurados durante a avaliação. Ao final da execução, uma versão preliminar é gerada do relatório de 
avaliação. 
Conclusão da avaliação: Revisão do relatório de avaliação e liberação dos dados de avaliação, bem como a 
devolução, pelo avaliador, do produto avaliado e seus componentes. 
No final do processo, os resultados esperados da avaliação de produto devem ser compreensíveis, aceitáveis e 
confiáveis por quaisquer partes interessadas nos papéis de requisitante de uma avaliação ou de avaliador. Dessa 
forma, espera-se obter um alto nível de objetividade da avaliação. 
De acordo com a ISO/IEC 14598-5, as características esperadas do Processo de Avaliação são: 
Repetitividade: Avaliação repetida de um mesmo produto, com mesma especificação de avaliação, realizada pelo 
mesmo avaliador, deve produzir resultados que podem ser aceitos como idênticos. 
Reprodutividade: A avaliação do mesmo produto, com mesma especificação de avaliação, realizada por um 
avaliador diferente, deve produzir resultados que podem ser aceitos como idênticos. 
Imparcialidade: A avaliação não deve ser influenciada frente a nenhum resultado particular. 
Objetividade: Os resultados da avaliação devem ser factuais, ou seja, não influenciados pelos sentimentos ou 
opiniões do avaliador. 
Considera-se que as avaliações de um mesmo produto podem ser executadas a partir de diferentes especificações 
e, portanto, não comparáveis e com resultados diferentes. 
A documentação do processo de avaliação de um produto de software, representado pela ISO/IEC 14598-5, deve 
englobar um conjunto de métricas que fornecem informações importantes sobre as propriedades do software e 
devem ser utilizadas de maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e 
entre avaliadores. Para tanto, requer que haja uma padronização na forma de documentação o que é feito pela 
aplicação de módulos de avaliação (M.A.). 
A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de 
software e fornece guias de requisitos para avaliação. Apesar de a norma possibilitar o uso de 
qualquer modelo de qualidade, a aplicação desse processo de avaliação se torna menos 
complexa se for utilizada em parceria com a norma ISO/IEC 9126, pois todas as normas da 
família 14598 estão ligadas a esse modelo. 
Na próxima aula, serão abordados os modelos que compõem a melhoria de processo de software e o modelo de 
garantia da qualidade em produção e instalação, de acordo com a ISO/IEC 9000-3. 
 
 
 
 
1. 
A Norma ISO/IEC constitui-se exatamente de quantas partes? 
 1) Duas. 
 2) Cinco. 
 3) Três. 
 4) Seis. 
 5) Quatro. 
 4 
2. 
A ISO/IEC 14598-2 aborda especificamente: 
 1) O processo para desenvolvedores quanto aos indicadores medidos na fase de desenvolvimento e, posteriormente, 
possibilitam tomadas de decisões estratégicas e gerenciais. 
 2) O processo para adquirentes de produtos de software de prateleira, produtos de software sob encomenda ou 
modificações em produtos de software existentes. 
 3) A visão geral das partes da norma. 
 4) O planejamento e gestão necessários para a avaliação de produto de software 
 5) O processo para avaliadores de produtos de software. 
 6) A documentação de módulos de avaliação de como testar um pacote de software em relação aos requisitos 
estabelecidos para o pacote. 
 4 
3. 
De acordo com a ISO/IEC 14598-5, as características esperadas do Processo de Avaliação são: 
 1) Repetitividade, imparcialidade, objetividade. 
 2) Reprodutividade, repetitividade, imparcialidade. 
 3) Repetitividade, reprodutividade, imparcialidade, objetividade. 
 4) Subjetividade, imparcialidade, reprodutividade, repetitividade. 
 3 
4. 
A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de software e fornece guias para a 
avaliação, baseados na utilização prática de qual outra norma? 
 1) ISO/IEC 12119 
 2) ISO/IEC 9241 
 3) ISO/IEC 12207 
 4) ISO/IEC 9126 
 5) ISO/IEC 15504 
 4 
 
Aula 7: Modelos de melhoria e avaliação de processo de software ISO 9000-3 
Ao final desta aula, você será capaz de: 
 
1. Abordar os modelos que compõem a melhoria de processo de software. 
2. Abordar o modelo de garantia da qualidade em produção e instalação, de acordo com a ISO 9000-3. 
 
Atualmente, a melhoria de processo de software faz parte da disciplina da engenharia de processo de software 
com uma forte tendência em atender concomitantementeaos sistemas. Inicialmente, dois conceitos são 
fundamentais para a melhoria de processo de software, tais como processo e capacidade de processo. 
Por processo considera-se a definição como sendo “o que as pessoas fazem, utilizando tecnologias, métodos e 
ferramentas para produzir um resultado desejado”. O conceito de processo de software fica, portanto, atrelado ao 
“o que as pessoas fazem, por meio de atividades, métodos, práticas e transformações para desenvolver, manter e 
melhorar software e produtos associados” (adaptado de Paulk (1993)). 
 
A capacidade de processo determina que uma organização tenha processos executados de forma que sejam 
gerenciados, definidos, medidos, controlados, efetivos e melhorados continuamente. 
Torna-se importante considerar que o grau de formalização do processo e a complexidade da comunicação em um 
projeto deve ser equilibrado, ou seja, uma formalização do processo adequada e uma comunicação correta para a 
efetividade de processo (capacidade). 
A estrutura do guia ISO 9000-3 
As normas da série ISO 9000 representam outro marco na utilização de processo. As normas foram desenvolvidas 
para apoiar organizações de todos os tipos e tamanhos, na implementação e operação de sistemas da qualidade 
eficazes. Especificamente a ISO 9000-3, interesse desse estudo, define diretrizes para facilitar a aplicação da norma 
ISO 9001 a organizações que desenvolvem, fornecem e mantém software. Destina-se a fornecer orientação 
quando um contrato entre duas partes exigir a demonstração da capacidade do fornecedor em desenvolver, 
fornecer e manter produtos de software. 
De fato, a ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção 
de software. As diretrizes propostas na ISO 9000-3 cobrem questões como: 
Entendimento dos requisitos funcionais entre contratante e contratado; 
Uso de metodologias consistentes para o desenvolvimento de software; 
Gerenciamento de projeto desde a concepção até a manutenção. 
Relevante destacar que uma das limitações da ISO 9000-3 é o fato de não tratar de aspectos como a melhoria 
contínua do processo de software (SPI – Software Process Improvement). Dessa forma, a ISO 9000-3 considera 
apenas quais processos a organização deve ter e manter, mas não orienta quanto aos passos que devem ser 
seguidos para chegar a desenvolvê-los e nem de como aperfeiçoá-los. 
A documentação do processo de avaliação de um produto de software, representado pela ISO/IEC 14598-5, deve 
englobar um conjunto de métricas que fornecem informações importantes sobre as propriedades do software e 
devem ser utilizadas de maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e 
entre avaliadores. Para tanto, requer que haja uma padronização na forma de documentação o que é feito pela 
aplicação de módulos de avaliação (M.A.). 
As diretrizes da ISO 9000-3 
A ISO 9001 baseia-se em 20 diretrizes (ou critérios) que englobam vários aspectos da garantia da qualidade. 
A ISO 9000-3 engloba somente 12 desses elementos. O ponto central dos critérios de um sistema de gestão da 
qualidade baseada nas normas ISO 9000 é a apropriada documentação desse sistema. 
A norma brasileira equivalente à ISO 9000-3 é a ISO 9000-3 de 1993, baseada na edição de 1991, e agrupa as 
diretrizes em três partes principais: 
 > Estrutura – descreve aspectos organizacionais relacionados ao sistema de qualidade. 
> Atividades do ciclo de vida: descreve atividades de desenvolvimento de software. 
> Atividades de suporte: descreve atividades que apoiam as atividades do ciclo de vida. 
A estrutura, nomenclatura e arranjo da atual ISO 9000-3, de 1997, seguem exatamente a estrutura da ISO 9001 e 
suas diretrizes têm o mesmo nome. 
A ISO 9000-3 apoia a aquisição da certificação da qualidade pelas organizações intensas no desenvolvimento de 
software, assim como as ISO 9001, 9002 E 9003. 
 
Responsabilidades da gerência 
A política de qualidade deve ser definida, documentada, comunicada, implementada e mantida por uma gerência. 
Por meio da política, o gerente descreve a atitude da organização em relação à qualidade. Define a estrutura 
organizacional necessária para o melhor gerenciamento da qualidade. No momento da definição, o gerente 
identifica as autoridades e atribui responsabilidades ao pessoal do sistema de qualidade que deve cumprir e 
assegurar que a interação entre as pessoas envolvidas esteja claramente especificada. 
Desta forma, o gerente assume as seguintes responsabilidades:
 
Além disso, o gerente designa um representante da administração para coordenar e controlar o sistema da 
qualidade. 
Requisitos do sistema de qualidade 
O sistema de qualidade deve ser documentado na forma de um manual e, assim, implementado. 
 Para tanto, o desenvolvimento de um Plano de Qualidade torna-se necessário sempre que for preciso controlar a 
qualidade de um projeto, de um produto, ou de um contrato específico com clientes. 
O plano deve especificar detalhadamente os procedimentos para controlar a gerência de configuração, a 
verificação do produto, a validação do produto, a não conformidade do produto e as ações corretivas. Os 
procedimentos devem ser consistentes com a política de qualidade. O plano deve mostrar como cumprir os 
requisitos do sistema de qualidade que, por sua vez, devem estar integrados às atividades do ciclo de vida, para 
assegurar que a qualidade está sendo construída ao longo de todo o projeto. 
O plano de qualidade aplica-se ao controle dos projetos de desenvolvimento de software. 
Revisão dos requisitos de contrato 
Nesse item, os requisitos contratuais precisam ser completos e bem definidos para garantir que a organização 
atenda às exigências contratuais. Deve ser feita uma cuidadosa análise crítica do contrato. 
 Procedimentos devem ser criados para que a coordenação de atividades de revisão do contrato de 
desenvolvimento de software possa ser feita junto ao cliente. A participação do cliente na revisão do contrato 
garante que os requisitos contratuais estabelecidos entre as partes são aceitáveis no correto fornecimento de 
produtos e/ou serviços. As revisões dos contratos firmadas junto ao cliente devem ser mantidas para consultas 
posteriores. 
Procedimentos devem ser desenvolvidos e especificados – como os contratos com os usuários devem ser 
corrigidos (emendados) – e que assegurem que as alterações serão comunicadas a toda organização. 
Assim, investigue se as partes envolvidas no contrato (contratada e contratante) concordam: 
Como os termos são definidos. 
Como será feita a aceitação dos produtos. 
Como o cliente irá participar. 
Como os usuários do software serão treinados. 
Como as atualizações de software (upgrades) serão feitas. 
Como os melhoramentos do software serão feitos. 
Como as mudanças nos requerimentos do cliente serão tratadas. 
Como os problemas serão tratados após a aceitação do produto. 
Que o projeto é viável. 
Que os direitos legais de terceiros serão respeitados. 
Que o cliente pode cumprir todas as obrigações contratuais. 
Que um cronograma apropriado para o projeto foi estabelecido. 
Que os riscos significativos e seus planos de contingência foram identificados. 
Que todas as obrigações contratuais e respectivas penalidades foram especificadas. 
Que os procedimentos de desenvolvimento de software foram definidos. 
Que os recursos estarão definidos quando necessário. 
Que a extensão das suas responsabilidades para com subcontratos foi definida. 
Requisitos da fase de projeto do produto 
As atividades referentes a projetos como planejamento, métodos para revisão, mudanças e verificações ocorridas, 
no decorrer do desenvolvimento do produto, devem ser documentadas para assegurar que todos os requisitos do 
produto foram cumpridos. 
 O desenvolvimento de planos de procedimentos na fase de elaboração do projeto de software sugere que seja 
executado de forma disciplinada, e o mesmo deve ocorrer durante o desenvolvimentode software com vistas a 
assegurar que é cumprido de forma sistemática. 
O plano deve conter alguns requisitos necessários com a devida documentação e aprovação dos envolvidos antes 
de ser implementado. O plano deve: 
 
 
Definir o projeto. 
Listar os objetivos do projeto. Apresentar o cronograma do projeto. Definir as entradas e saídas do projeto. 
Identificar planos e projetos relacionados. Explicar como o projeto será organizado. Discutir riscos de projeto 
assumidos. Identificar todas as estratégias de controle relevantes. 
Por outro lado, o plano de desenvolvimento de software precisa definir: 
 A responsabilidade dos participantes no desenvolvimento do software. 
Os meios como as informações técnicas serão compartilhadas e transmitidas entre todos os participantes. 
O comprometimento do cliente em aceitar, cooperar e dar suporte ao projeto de desenvolvimento de software. 
A agenda de revisões do projeto para avaliar as atividades e os resultados alcançados por todos os participantes. 
Desenvolver procedimentos para assegurar que todos os requisitos de entrada da fase de projeto são 
identificados, documentados e revistos, e que todas as falhas, ambiguidades, contradições e deficiências são 
resolvidas. 
 Os requisitos de entrada da fase de projeto devem ser especificados pelo cliente, apesar de ocorrer, em alguns 
casos, uma expectativa do cliente de que os mesmos sejam especificados pelos responsáveis da fase de projeto. 
Nesse caso, torna-se prudente trabalhar junto ao cliente de forma que evite um mau entendimento e, assim, 
assegure que a especificação está de acordo com as necessidades e expectativas do cliente. Uma validação durante 
a aceitação do produto é recomendada, bem como a aprovação do resultado da especificação das entradas da fase 
de projeto. 
 Da mesma forma, procedimentos padronizados devem ser especificados para controlar as saídas da cada estágio 
da fase de projeto e desenvolvimento do produto de forma assegurar que estão corretos e completos. As revisões, 
demonstrações e testes devem ser frequentes e devidamente mantidas e registradas na fase de projeto. 
 Por fim, manter o registro das validações da fase do projeto e do desenvolvimento que confirmam a avaliação do 
produto por parte do cliente. 
 Procedimentos devem também ser desenvolvidos para o garantir o controle das alterações no projeto do software 
que possam ocorrer durante todo o ciclo de vida. 
Controle de documentos e dados 
A ISO 9000-3, de 1994, classifica como Controle de documentos e dados toda geração, distribuição, mudança e 
revisão em todos os documentos. 
 O controle da norma orienta para que se desenvolvam procedimentos para identificar todos os documentos e 
dados que devam ser controlados e definir a forma de acesso dos funcionários da organização a esses documentos, 
assim como desenvolver procedimentos para revisar, aprovar e manter todos os documentos e dados do sistema 
de qualidade, mesmo que ocorram mudanças. 
Requisitos de aquisição(compra) 
Para esse item da norma, considera-se que todos os produtos e serviços adquiridos atendam às exigências 
especificadas (requisitos) e, para tanto, deve haver procedimentos para a avaliação de fornecedores tanto de 
produtos como de serviços. 
Os procedimentos devem visar: 
> à seleção, 
> à avaliação, 
> ao monitoramento, 
> ao controle dos subcontratados e fornecedores, bem como a verificação de produtos comprados. 
Os registros dos subcontratados tornam-se essenciais e devem ser acompanhados do aceite destes, além da 
certificação de que os documentos de compra descrevem corretamente o que de fato se deseja comprar. 
 
Produtos fornecidos por clientes ou fornecedores 
Procedimentos devem ser desenvolvidos para assegurar que os produtos fornecidos por clientes e/ou 
fornecedores sejam adequados ao uso e devidamente mantidos. 
 > ISO 9000-3:1991 - Produto de software incluído. 
> ISO 9000-3:1994 chama de Customer-supplied products 
Algumas preocupações relevantes: 
> Examinar o produto para confirmar se todos os itens estão presentes e não danificados. 
> Armazenar o produto de forma apropriada e segura para evitar perdas ou danos. 
> Registrar e comunicar ao cliente no caso de perda ou dano de qualquer produto. 
> Estabelecer quem é responsável pela manutenção e controle dos produtos enquanto eles estiverem em sua 
posse. 
> Controlar produtos, serviços, documentos e dados fornecidos pelo cliente. 
Identificação e controle de produtos 
Necessidade de procedimentos para a identificação do produto por item, série ou lote durante todos os estágios 
da produção, entrega e instalação. O produto deve poder ser rastreado através dessa identificação. 
A coerência nos procedimentos possibilita que todos os passos do caminho do produto (manipulação, 
armazenamento, produção, envio, instalação e serviço) sejam devidamente controlados por meio de 
identificadores únicos com o registro mantido apropriadamente. 
A identificação do produto de software ou de seus componentes pode ser mantida não só durante a fase de 
definição do produto, mas também durante todo o seu ciclo de vida. 
O acompanhamento do produto de software e seus componentes durante o ciclo de vida também se faz 
necessário. Para tanto, métodos de gerência de configuração (configuration management) podem ser usados para 
identificar e acompanhar o software e seus componentes. 
Processo de controle de requisitos 
Requer que todas as fases de processamento de um produto sejam controladas (por procedimentos, normas, etc.) 
e documentadas. Os procedimentos para planejar, monitorar e controlar seu processo de produção, instalação e 
manutenção devem ser devidamente documentados. 
 Um bom sistema pode manter registros que monitorem e controlem processos, pessoal e equipamentos. Da 
mesma forma, procedimentos desenvolvidos podem controlar os processos de reprodução, liberação e instalação 
do software (software replication, reliase and intallation). 
Testes e inspeções dos produtos 
Todas as atividades de teste e inspeção do produto devem ser devidamente controladas por meio de registros. 
Requer que as matérias-primas sejam inspecionadas (por procedimentos documentados) antes de sua utilização. 
Antes de utilizar matérias-primas, elabore procedimentos para inspecionar, testar e verificar se o produto cumpre 
todos os requisitos especificados. 
Os planos de teste do software (software test plans) devem ser documentados. 
No caso de produtos adquiridos por terceiros (fornecedores ou o próprio cliente) os requisitos devem ser 
verificados antes de disponibilizados para o uso no processo de desenvolvimento. 
O mesmo deve ser considerado para o produto final, ou seja, verificar se ele cumpre todos os requisitos antes de 
disponibilizado para o comércio. 
 
 
Controle de equipamentos de inspeção 
Requer o desenvolvimento de procedimentos para controlar, calibrar e manter equipamentos (hardware e 
software) de inspeção, medida e teste usados para demonstrar que seu produto cumpre os requisitos 
especificados. 
 Considera-se, também, o uso de ferramentas, técnicas e equipamentos para testar se o produto de software está 
de acordo com os requerimentos especificados. 
É interessante desenvolver procedimentos que assegurem que os equipamentos de medida são apropriados, 
efetivos e seguros. 
 
1. 
As normas da série ISO 9000, apoiam as organizações de todos os tipos e tamanhos, na implementação e operação de sistemas 
da qualidade eficazes. A norma que define diretrizes de qualidade para as organizações que desenvolvem, fornecem e mantém 
software por meio de contratos entre duas ou mais organizações é conhecido como: 
 1) ISO 9001. 
 2) ISO/IEC 12119. 
 3) ISO 9000-3. 
 4) ISO/IEC 9126. 
 5) ISO 9000-2. 
 3 
2. 
 As atividades referentes a projetos como planejamento, métodos para revisão, mudanças e verificações ocorridas, no decorrer 
do desenvolvimento do produto, devem ser documentadas para assegurar que todos osrequisitos do produto foram cumpridos. É 
necessário, por parte da equipe responsável pelo sistema de qualidade, validar alguns requisitos nessa fase, exceto: 
 
 1) Definição do projeto. 
 2) Lista dos objetivos do projeto. 
 3) Cronograma do projeto. 
 4) Definição das entradas e saídas do projeto. 
 5) Definição da portabilidade do projeto. 
 6) Identificação dos planos e projetos relacionados. 
 7) Explicar como o projeto será organizado. 
 8) Riscos de projeto assumidos. 
 9) Estratégias de controle relevantes. 
 5 
3. 
Segundo a norma 9000-3, somente produtos que tenham passado por todos os testes e inspeções são subsequentemente usados 
ou vendidos a clientes. Trata-se de qual requisito referenciado na norma? 
 1) Requisitos de treinamento. 
 2) Requisitos da auditoria de qualidade. 
 3) Requisitos de manutenção. 
 4) Requisitos de teste e inspeção. 
 5) Processo de controle de requisitos. 
 4 
4. 
Assinale a alternativa que não deve ser um procedimento executado no processo de auditoria da qualidade de software a ser 
realizado dentro de uma organização. 
 1) Os auditores devem ser internos à organização. 
 2) Identificação dos critérios para auditoria (processo, padrões, informações pertinentes). 
 3) Preparação adequada do material. 
 4) Preparação de um checklist que sirva de guia durante a execução da auditoria. 
 5) Identificação de possíveis auditados. 
 6) Apresentar os auditores aos auditados. 
 1 
Aula 8: Modelo de qualidade do processo de ciclo de vida do software NBR 
ISSO / IEC 12207 
1. Descrever os objetivos da Norma NBR ISO/IEC 12207 
2. Apresentar os critérios para definição dos seguintes processos na Norma NBR ISO/IEC 12207: 
 Processos fundamentais. 
 Processos de apoio. 
 Processos organizacionais. 
 Processos de adaptação. 
 
Qualidade em uso 
A NBR ISO/IEC 12207 – Processos de Ciclo de Vida de Software tem como objetivo o estabelecimento de uma 
estrutura comum para os processos de ciclo de vida de software como forma de ajudar as organizações a 
compreenderem todos os componentes presentes na aquisição e fornecimento de software e, assim, conseguirem 
firmar contratos e executarem projetos de forma eficaz. 
 As pesquisas em torno da engenharia de software mostram a relevância da resolução de problemas de falhas em 
projetos basear-se em modelos de melhoria e processo que permeiam três variáveis de suma importância e 
nenhuma mais importante que a outra, mas conjuntamente expressivas no contexto de desenvolvimento de 
software: 
Processo  Pessoas  Tecnologia  É evidente a influência de uma na outra, como os processos imaturos 
(Processo) que fazem com que se tenha uma deficiência no estabelecimento do perfil técnico adequado para 
exercer uma atividade (Pessoa) que, por sua vez, não consiga usufruir o melhor da tecnologia oferecida 
(Tecnologia).  Dessa forma, a comunidade de software entende, então, a importância de criar normas, modelos 
e métodos para regular e orientar a definição de processos de software. 
Vamos, então, concentrar nossos estudos em duas partes: 
1. O significado do processo 
2. Escopo da Norma NBR ISO/IEC 12207 
 
 
 
1. O significado do processo 
Quando é fornecido um serviço ou criado um produto, no caso específico de um software: 
 
Para Pfleeger (2004), um processo envolve um conjunto de métodos, técnicas, ferramentas e pessoas de forma a 
prescrever todas as suas principais atividades. Complementa que cada atividade do processo tem critérios de 
entrada e saída, de modo que seja possível saber quando o processo começa e termina. Quando se clica na caixa 
de entrada, a cor do fundo da caixa mudará da cor branca para a cor azul-claro. 
Considera-se que o processo de criação de um produto pode ser concebido como um ciclo de vida composto por 
procedimentos. Da mesma maneira, pode-se considerar que o processo de desenvolvimento de software 
constitui-se ser o ciclo de vida do software. 
 
Cada processo recebe entradas (matéria prima, informação, etc.). 
Entradas são transformadas por um processo. 
Os componentes de um processo incluem trabalho humano, tecnologia, métodos, materiais e gerenciamento. 
Um processo gera saídas (os produtos do processo). 
Clientes são receptores das saídas. 
Fornecedores são provedores de serviços ou matérias-primas (entradas do processo). 
Vantagens do gerenciamento por processos: 
Alinha estrategicamente a organização. 
Foca a organização no cliente. 
Obriga a organização a prestar contas pelo desempenho dos seus processos. 
Alinha a força de trabalho com os processos. 
Evidencia a necessidade de alocação de recursos. 
Melhora a eficiência. 
 
Modularidade e responsabilidade 
Os processos da ISO/IEC 12207 são fortemente coesos, ou seja, todas as partes de um processo são fortemente 
relacionadas. Porém, os processos são fracamente acoplados quanto à quantidade de interfaces entre os 
processos. 
Regras para identificação, escopo e estruturação dos processos: 
Um processo deve ser modular, ou seja, deve executar uma e somente uma função dentro do ciclo de vida com a 
menor incidência de interfaces entre dois processos. 
 Se um processo A é invocado por um processo B e somente por ele, então A pertence a B. 
 Se uma função é invocada por mais de um processo, então essa função torna-se um processo. 
 Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida. 
 A estrutura interna deve ser suficientemente definida para que possa ser executável. 
Atenção: Quanto à responsabilidade, segundo a ISO/IEC 12207, cada processo deve ser de responsabilidade de 
uma parte. A parte que executa tem a responsabilidade por todo o processo, mesmo que tarefas individuais 
possam ser realizadas por pessoas diferentes. 
2. Escopo da Norma NBR ISO/IEC 12207 
A NBR ISO/IEC 12207 estabelece uma arquitetura de ciclo de vida de software construída a partir de uma estrutura 
de processos e seus inter-relacionamentos descritos tanto em nível de propósito/saída como em termos de 
processos, atividades, tarefas, propósito e resultados que servem para ser aplicados: 
 durante a aquisição de software, de um produto de software independente ou de um serviço de software. 
 durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software. 
A proposta da norma é a sua utilização desde a concepção até a descontinuidade do produto de software 
ressaltando a importância do envolvimento de todos aqueles responsáveis pela produção, manutenção e operação 
do software tais como adquirentes, fornecedores, operadores, desenvolvedores, mantenedores, gerentes, 
profissionais de qualidade e usuários. 
Atenção: Uma observação importante refere-se ao fato da norma não especificar os detalhes de como 
implementar ou executar as atividades e tarefas incluídas nos processos, assim como não visa prescrever um 
modelo específico de ciclo de vida (cascata, incremental, evolucionário) ou método de desenvolvimento de 
software(orientação a objetos, análise estruturada). 
Cabe, portanto, as partes envolvidas a responsabilidade de adaptação dos processos, atividades e tarefas da norma 
a fim de atender ao modelo de ciclo de vida para o projeto de software. De acordo com a natureza dos processos 
esses se agrupam da seguinte forma: 
 
Fundamental: Os processos fundamentais iniciam o ciclo de vida do software e comandam a execução de todos os 
outros processos. Eles constituem um conjunto de cinco processos que são: 
• Aquisição – inicia o ciclo de vida de software 
• Fornecimento – responde pela execução dos processos de desenvolvimento, operação e manutenção 
• Desenvolvimento – contém as atividades e tarefas que devem ser executadas pelo desenvolvedor 
• Operação – contém as atividades e tarefas do operador com a cobertura do software e o suporte operacional dos 
usuários 
• Manutenção – torna-se ativo quando o produto de software é submetido a modificações no código e na 
documentação associadadevido a um problema, necessidade de melhoria ou adaptação. 
Atividades do desenvolvimento 
Algumas atividades importantes para o desenvolvimento de software serão descritas com base na norma ISO/IEC 
12207. São elas: 
• Implementação. 
• Levantamento de requisitos. 
• Análise dos requisitos do software. 
• Projeto da arquitetura do software. 
• Projeto detalhado do software. 
• Codificação e testes do software. 
• Integração do software. 
• Teste de qualificação do software. 
• Instalação do software. 
• Testagem e aprovação do software. 
Apoio: 
Os processos de apoio são de responsabilidade da organização que o executa. 
O objetivo é proporcionar qualidade aos outros processos, pois através de sua execução acredita-se que eles terão 
garantia de qualidade e uma maior organização. 
Podem ser utilizados pelos processos fundamentais de apoio organizacional. 
Atenção: O processo de desenvolvimento de software tem como foco entregar um produto de software. 
Se o processo de documentação do usuário não é empregado ou distribuído, pode ser que, mesmo assim, o código 
do software seja executado. ISO significa que o processo de apoio tem o propósito de contribuir para o sucesso e 
qualidade dos processos fundamentais e organizacionais, mas que não são necessariamente dependentes entre si, 
apenas relacionados uns aos outros. 
 
 
 
Organizacional: 
• Os processos organizacionais são chamados pelos outros processos e devem existir independentemente do 
projeto que está sendo executado. 
• As atividades e tarefas em um processo organizacional são de responsabilidade da organização que o utiliza. 
• Os processos organizacionais são instanciados nos processos fundamentais porque eles são gerenciados de 
forma diferente. 
Adaptação: 
O propósito do processo de adaptação é realizar a adaptação básica da norma para um projeto de software. 
 
Atenção: 
 Importante ressaltar que a ISO/IEC 12207 não se propõe a determinar métodos, ferramentas, 
treinamentos, métricas ou tecnologias empregadas. A razão se faz pelo fato de se constituir em uma norma que 
seja utilizada mundialmente e possa acompanhar a evolução da engenharia de software nas diversas culturas 
organizacionais. 
Dessa forma, a flexibilidade da norma permite que seja utilizada em qualquer modelo de ciclo de vida, 
método ou técnica de engenharia de software e linguagem de programação. 
• É interessante reforçar a característica da norma por meio das atividades e tarefas do processo de ciclo de vida 
do software; somente especificar “o que fazer” e não “como fazer”. 
• Outra característica que diz respeito à norma é possibilitar a modularidade do processo, a forte coesão entre os 
processos fundamentais de apoio e organizacionais. Isso significa que todas as partes de um processo estão 
fortemente relacionadas, porém a quantidade de interfaces entre os processos é mínima. 
Algumas regras são importantes para identificação, escopo e estruturação dos processos e devem ser seguidas. 
Um processo deve ser modular, isto é, convém que um processo execute uma e somente uma função dentro do ciclo 
de vida e é conveniente que as interfaces entre dois processos quaisquer sejam mínimas. 
Cada processo é invocado na arquitetura. 
Se um processo A é invocado por um processo B e somente por ele, então A pertence a B. 
Se uma função é invocada por mais de um processo, então essa função torna-se um processo. 
Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida. 
Convém que cada processo tenha uma estrutura interna suficientemente definida para que possa ser executável. 
 
 
Atividade proposta 
1. Visite uma empresa de desenvolvimento, manutenção ou operação de software ou através de sua própria 
experiência: 
 Liste quais as tarefas que a empresa executa do processo de fornecimento e qual o nível de formalismo 
associado? 
 Liste quais são os principais problemas vividos durante o fornecimento de software? 2. Entreviste um 
gerente de projeto e pergunte: 
 
 
 Quais são as dificuldades encontradas para se manter o software e discuta algumas possíveis soluções? - 
processo de manutenção 
 Solicite que o gerente descreva como é o suporte ao usuário. 
 No processo de desenvolvimento de software como é o conteúdo de uma documentação do usuário? 
Como é o processo de criação e de manutenção da documentação pensando em todos os aspectos levantados 
no processo de documentação? 
 Investigue se a empresa possui ferramentas disponíveis de gerência de configurações e analise suas 
funcionalidades em caso afirmativo. 
 Solicite ao gerente que descreva como é o processo de verificação do software. Pergunte se, na visão dele, 
é necessária a presença do cliente para validar se o produto está conforme requisitado. 
 Avalie se o gerente é favorável à revisão conjunta. 
 Descreva como o gerente considera as situações as quais um projeto de software demanda de auditoria. 
 
3. Qual o nível de envolvimento do cliente durante o desenvolvimento e manutenção de software? Quais 
são as dificuldades nessa relação? 
 
Nesta aula, você aprendeu: 
 A importância dos processos fundamentais, de apoio, organizacionais e de 
adaptação especificados de acordo com o propósito e resultados 
esperados, bem como as atividades e tarefas necessárias para a 
implementação e garantia da qualidade de software. 
 Com a correta aplicação dos processos da norma NBR ISSO/IEC 12207 
torna-se possível resolver falhas através de modelos de melhoria e 
processos baseados em três elementos: tecnologia, processos e pessoas. 
 
 
 
 
 
 
 
1. 
 De quem é a responsabilidade por aceitar o produto de software? 
 1) Adquirente. 
 2) Fornecedor. 
 3) Desenvolvedor. 
 4) Cliente. 
 1 
 2. 
 De quem é a responsabilidade de especificar os requisitos do produto? 
 1) Adquirente. 
 2) Fornecedor. 
 3) Desenvolvedor. 
 4) Cliente. 
 4 
 3. 
 Qual o modelo de ciclo de vida utilizado na norma NBR ISO/IEC 12207? 
 1) Cascata. 
 2) Incremental. 
 3) Evolucionário. 
 4) Todas as alternativas anteriores estão corretas. 
 5) Nenhuma das alternativas anteriores está correta. 
 4 
 
Aula 9: Modelos de Qualidade de Processo de Software ISO/IEC 15504 - (Spice - 
Avaliação), CMMI e MPS.BR 
1. Destacar a relevância do modelo de avaliação de processo (todos ou alguns). 
2. Enfatizar a utilização da norma como referência para melhoria contínua de processo de software. 
A ISO/IEC 15504, conhecida também como SPICE (Software Process Improvement and Capability Determination), 
consiste em uma norma para definição de processos de desenvolvimento de software. Os requisitos da norma são 
uma evolução da norma ISO/IEC 12207, porém apresenta níveis de capacidade para cada processo. Por muito 
tempo, a norma manteve-se em estudo e, somente em 1993, a ISO tornou pública a norma ISO/IEC 15504 (SPICE) 
para avaliação de processos de software. 
Trata-se de um modelo bidimensional com objetivo de realizar avaliações dos mesmos com foco na sua otimização 
no que tange aos pontos fortes e oportunidades de melhoria, e a determinação da capacidade dos processos por 
meio da avaliação de um fornecedor em potencial. 
A norma considera a avaliação de processo como uma investigação e análise organizada de processos selecionados 
de uma unidade organizacional em relação a um modelo de avaliação de processo. 
O modelo de avaliação de processo é organizado em uma arquitetura com dois níveis, sendo o primeiro composto 
por três categorias de processo: 
Fundamentais; Organizacionais e De apoio. 
O segundo nível é composto por dez grupos de processo que são alocados em cada uma das categorias de processo. 
Cada um é definido por seis níveis de capacidade sequenciais e cumulativos que podem ser utilizados como uma 
métrica para avaliar como uma organização está realizando um determinado processo. Também podem ser 
utilizados como um guia para a melhoriacuja utilização tem como referência um modelo de processo que enfatiza a 
realização de uma avaliação de processo. 
O guia apresenta oito etapas sequenciais que inicia com a identificação de estímulos para a melhoria e o exame das 
necessidades da organização. 
A norma ISO/IEC 15504 define, também, um ciclo de melhorias a fim de identificar novas melhorias, avaliar as 
práticas correntes em relação à melhoria realizada. 
O processo é composto por: 
 
Dimensão de Processos 
A norma ISO/IEC 15504 relaciona as três categorias, os dez grupos e quarenta e oito processos dos modelos de 
avaliação de processo. A tabela em pdf apresenta detalhadamente cada um desses componentes. 
Os seis níveis básicos para descrição de cada categoria de processo da norma ISO/IEC 12207 são: 
Identificação do processo (process identifier). 
Nome do processo (process name). 
Propósito (process purpose). 
Resultados (outcomes). - descreve os resultados esperados de uma implementação com sucesso deste processo 
(produção de um artefato; uma mudança significativa de estado; atendimentos aos requisitos e objetivos). 
Práticas base (base practice). atividade que, quando executada de forma consistente, contribui para o atendimento 
do propósito de um processo. Para cada prática base estão relacionados os resultados (outcomes) que a prática 
ajuda a alcançar. 
Produtos de trabalho (work-products). - Os produtos de trabalho de um processo são aqueles esperados de serem 
utilizados e/ou produzidos pela execução do processo. A lista de produtos de trabalho para cada processo deve ser 
utilizada como orientação para avaliação ou melhoria do processo. 
Veja a seguir, um exemplo prático da aplicação dos níveis básicos no Processo de Aquisição do grupo de categorias 
dos processos fundamentais: 
Identificação: ACQ.1 
 
Nome: Prepara para aquisição (Acquisition preparation ) 
Propósito: Estabelecer as necessidades e objetivos da aquisição e comunicá-los aos potenciais fornecedores. 
Resultados: 
R1 - O conceito ou a necessidade de aquisição, desenvolvimento ou melhoria é estabelecido. 
R2 - Os requisitos de aquisição necessários, definindo as necessidades do projeto, são definidos e validados. 
R3 - Os requisitos conhecidos do cliente são definidos e validados. 
R4 - Uma estratégia de aquisição é desenvolvida. 
R5 - Os critérios de seleção do fornecedor são definidos. 
Práticas Base: 
ACQ.1.BP1: Estabelecer a necessidade. Estabelecer uma necessidade de adquirir, desenvolver ou aprimorar um 
sistema, produto de software ou serviço. Resultado [1] 
ACQ.1.BP2: Definir os requisitos. Identificar o cliente / exigências das partes interessadas de um sistema e / ou 
produto de software ou serviço. [Resultados: 2, 3] 
ACQ.1.BP3: Regras de Revisão. Analisar e validar os requisitos definidos em relação às necessidades identificadas. 
Validar os requisitos para reduzir o risco de incompreensão por parte dos fornecedores potenciais. [Resultado: 3] 
ACQ.1.BP4: Desenvolver estratégia de aquisição. Desenvolver uma estratégia para a aquisição do produto de acordo 
com as necessidades de aquisição. [Resultado: 4] 
Nota 1: A estratégia pode incluir uma referência ao modelo de ciclo de vida, cronograma e critérios de seleção. 
Dimensão de Capacidade de Processo 
Em uma organização, vários processos podem ter níveis de capacidade diferentes. A ISO/IEC 15504 define 6 níveis 
de capacidade sequenciais e cumulativos. Os níveis podem ser usados para avaliar como uma organização está 
realizando um determinado processo e como um guia para a melhoria de processo. Cada nível de capacidade é 
descrito basicamente por um nome, definição e atributos. 
 
A escala representa a capacidade de crescimento do processo implementado, desde não atender ao propósito do 
processo até atender aos objetivos atuais e projetados do negócio. Trata-se, portanto, de uma métrica para 
avaliação e um roteiro para melhoria baseados na capacidade do processo. 
A medida da capacidade está baseada em atributos de processo que medem um aspecto específico da capacidade 
do processo requerida, conforme apresenta a tabela 2.2. 
 
 
Veja a seguir, uma descrição detalhada dos atributos de processos. 
 
 
 
 
 
 
 
 
Avaliação de Processo com a ISO/IEC 15504 
Para executar uma avaliação correta, uma organização deve selecionar um modelo de processo compatível (no caso 
aplicação da norma ISO/IEC 15504), definir um processo de avaliação, identificar o perfil de capacidade de processo 
(PCP) com os respectivos níveis de capacidade e, acima de tudo, escolher um bom avaliador. Com todas essas etapas 
realizadas tendo por base o alcance dos objetivos de negócio, a análise dos resultados visando à melhoria contínua 
deve gerar aspectos negativos e positivos, assim como os riscos associados aos processos. 
Com isso, a evidência do alcance dos objetivos de negócio será determinada pela efetividade da prática da avaliação 
do processo em conformidade com os processos da norma ISO/IEC 15504. A figura 3.1 ilustra a interação do 
processo de avaliação com outros elementos importantes. 
 
Todo processo de avaliação deve ser bem documentado e conter, no mínimo, as atividades de planejamento, coleta 
de dados, validação dos dados, pontuação dos atributos de processo e representação dos resultados. 
 
A coleta de dados deve ser de forma sistemática, utilizando o seguinte: 
A estratégia e técnica para seleção, coleta, análise dos dados e justificativas para atribuição de notas devem ser 
identificadas e demonstradas. 
Correspondência entre os processos das unidades organizacionais identificados no escopo da avaliação e os 
elementos do Modelo de Avaliação de Processo. 
Cada evidência objetiva deve satisfazer o escopo e objetivo da avaliação, bem como deve ser registrada e mantida 
para futuras verificações da medição dos atributos. 
A validação dos dados coletados de acordo com: 
Confirmação de que as evidências coletadas são objetivas. 
Garantia de que são suficientes e representativos para cobrir o escopo e propósito da avaliação. 
Garantia que os dados coletados são consistentes. 
A pontuação de atributo de processo a partir dos dados validados deve partir de um valor conferido a cada atributo 
de processo, baseado nos dados validados. Por exemplo: 
 
O ideal do nível de capacidade de processo é manter nota “L” ou “F” nos atributos do nível “F” em todos os atributos 
dos níveis anteriores. 
 
 
CMMI (Capability Maturity Model Integration) 
É intenso o desenvolvimento de softwares produzidos sem a orientação padronizada de uma norma. Isso acontece 
por conta de os fabricantes se preocuparem em atender às necessidades iniciais do cliente, negligenciando aspectos 
de manutenção e durabilidade. O resultado dessa visão é a produção de softwares de baixa qualidade. 
A partir desse contexto, foram criados os Modelos de Qualidade de Software que têm como objetivo garantir a 
qualidade do produto através da definição e normatização de processos de desenvolvimento. Os mais conhecidos 
são: ISO, CMM, CMMI. 
Desde então, muitos foram os problemas advindos de vários modelos com características diversificadas forçando 
novamente o SEI a desenvolver um modelo comum entre os disponíveis a fim de possibilitar a unificação com menor 
perda de custos. Surge, então, o CMMI. 
Inicialmente, o SEI (Software Engineering Institute) divulgou o CMM como o documento padrão de normas a serem 
seguidas e, logo após, outros tantos foram definidos, tais como: 
Engenharia de Sistemas (SE-CMM), Aquisição de Software (SA-CMM) e Gestão de Recursos Humanos de Empresas 
de Softwares (P-CMM). 
 
 
 
 
 
Representações do CMMI 
O CMMI possui duas representações que possibilitam que a organização utilize diferentes caminhos para a melhoria 
de acordo com seu interesse, que são: 
Contínua: Permite que uma organização selecione uma área (ou um grupo de áreas) de processo e melhore os 
processos relacionados.Ela usa níveis de capacidade para caracterizarmelhorias relativas a uma área de processo 
individual. 
O enfoque ou componentes principais são as áreas de processo. Existem metas e práticas de dois tipos: específicas a 
uma determinada área de processo e genéricas aplicáveis indistintamente a todas as áreas de processo. A partir da 
avaliação e do atendimento dessas práticas e metas, é possível classificar o nível de capacidade de cada área de 
processo em níveis de zero a cinco, conforme tabela 5.1. 
 
Estagiada: Usa conjuntos pré-definidos de áreas de processo (KPA's) para definir um caminho para uma organização, 
caracterizado por níveis de maturidade. A representação em estágios oferece uma abordagem estruturada e 
sistemática para a melhoria de um estágio por vez. Atingir um estágio significa que uma estrutura de processo 
adequada foi estabelecida como base para o próximo estágio. 
 As áreas de processo são organizadas por níveis de maturidade (1 a 5) que definem o caminho de melhoria que uma 
organização deve seguir do nível inicial ao nível otimizado. Dentro de cada nível, existem áreas de processo que 
contêm metas, características comuns e práticas. 
 Na representação em níveis, as práticas são caracterizadas pelos atributos: compromISO para execução (práticas 
que garantem que o processo seja estabelecido e apoiado); habilidade para execução (práticas que criam condições 
para que o processo seja estabelecido completamente) e atividade para execução (práticas que implementam 
diretamente o processo); controle e verificação de implementação. A transição entre os níveis resulta em melhorias 
incrementais e duradouras. A tabela 5.2 esquematiza as metas e práticas desse modelo. 
 
Atenção: Uma organização pode escolher melhorar o desempenho de um único ponto problemático de um 
processo, ou pode trabalhar em diversas áreas fortemente ligadas aos seus objetivos. 
MPS.BR 
O objetivo do MPS.BR sintetiza a descrição de Melhoria de Processo do Software Brasileiro. Participam da criação as 
universidades, os grupos de pesquisas e as empresas sob coordenação da SOFTEX. 
Para isso, o MPS.BR desenvolve uma série de atividades cobrindo a elaboração de modelos de referência (MRMPS), 
elaboração de métodos de avaliação (MA-MPS), elaboração de guia de negócios (MN-MPS) para aquisição, 
desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como 
implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras. A Figura 
6.1 demonstra os modelos MPS.BR. 
 
O MPS. BR baseia-se nas melhores práticas de engenharia de software, sendo compatível com o CMMI e em 
conformidade com as normas ISO/IEC 12207 e ISO/IEC 15504. 
A versão 1.0 do modelo MR-MPS define 23 processos baseados em processos selecionados da ISO/IEC 12207 e 
ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. Na estrutura do modelo são definidos sete níveis de 
capacidade ou maturidade de processo, expressos em termos de processos e de cinco atributos de processo (AP). 
Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores e, eventualmente, 
acrescenta novos atributos de processo a todos os processos. 
Exemplo: Para uma unidade organizacional atender ao nível F de maturidade, ela deve satisfazer aos atributos de 
processo anteriores: Gerência de Projeto (GPR), Gerência de Requisitos (GRE), Gerência de Configuração (GCO), 
Medição (MED), Garantia da Qualidade (GQA) e Aquisição (AQU). Quatro dos sete níveis de maturidade 
correspondem, respectivamente, aos quatro níveis de maturidade (2 a 5) do CMMI-SE/SW na representação 
estagiada. A Figura 6.2 demonstra a hierarquia dos níveis de maturidade do Modelo MPS.BR. 
A figura a seguir demonstra a hierarquia dos níveis de maturidade do Modelo MPS.BR. 
 
 
No contexto de micro e pequenas empresas de software, alguns métodos de avaliação para melhoria de processo 
estão sendo desenvolvidos, incluindo, por exemplo, QuickLocus [Kohan, 2003], RAPID [Rout 2000], MARES/15504, 
MPE [Anacleto, et. Al 2005], MA-MPS [SOFTEX 2005]. Basicamente, todos esses métodos enfocam em avaliações 
para orientar a melhoria usando vários modelos de referência, incluindo CMMI-SE/SW, ISO/IEC 15504 ou MR-MPS. 
Pesquise, em sites na internet, experiências de empresas públicas ou privadas que implementaram a norma ISO/IEC 
15504 e evoluíram para CMMI. Descreva os ganhos e as dificuldades encontradas no processo de melhoria contínua 
dos processos. 
 
Exemplo de Estudo de Caso disponível no trabalho "Melhoria de Processo de Software em uma empresa de pequeno 
porte: um estudo de caso". 
Nessa aula, você aprendeu: 
A ISO/IEC 15504 apresenta como a grande quantidade de formatos de apresentação dos resultados um conjunto de 
processos que apoiam o desenvolvimento de software. 
 
O CMM - Capability Maturity Model - é um modelo de desenvolvimento para aplicação específica ao software 
dentro de um contexto de qualidade total no âmbito de uma organização. É uma estrutura para avaliação e 
melhoria, aplicada somente ao processo de software. O modelo se baseia, principalmente, na experiência da 
comunidade de software da indústria americana, com a utilização de conceitos de gerenciamento de processos de 
autores consagrados cujos modelos foram largamente aplicados em outras áreas. 
 
Para obter a qualidade do processo e, consequentemente, a qualidade do produto, as organizações precisam optar 
por uma das normas de qualidade disponíveis no mercado, porém poucas delas têm aceitação. As mais usadas no 
mercado são o CMM e a ISO. 
 
O surgimento de várias tecnologias decorre da necessidade de mudança nos processos de produção e, a partir disso, 
a busca de um modelo de engenharias de software visou a formalizar uma unidade ao processo de desenvolvimento 
de sistemas. Os modelos CMMI (internacional) e a adaptação do MPS.BR (brasileiro) se enquadram atualmente como 
as melhores práticas para alcance da qualidade de produto e processos de software. 
Acesse o site do SOFTEX para conhecimento do observatório da SOFTEX e dos processos de desenvolvimento do 
modelo MPS.BR 
Disponível em http://www.softex.br/portal/softexweb/uploadDocuments/_mpsbr/Artigo_CLEI_2008_vFinal11.pdf 
Na próxima aula, será tratada a prática de atividades de identificação, análise, planejamento e monitoração de 
riscos (gerência de riscos) que devem ser realizadas de forma sistematizada e controlada durante todo o processo 
de desenvolvimento de software. 
 
 
 
1. 
A norma ISO/IEC 15504 relaciona as categorias, grupos e processos. Escolha a opção que determina, respectivamente, as 
quantidades exatas de cada um dos elementos abordados pela norma: 
 1) 2 categorias, 5 grupos e 30 processos. 
 2) 3 categorias, 10 grupos e 48 processos. 
 3) 4 categorias, 11 grupos e 47 processos. 
 4) 3 categorias, 9 grupos e 48 processos. 
 5) 4 categorias, 10 grupos e 45 processos. 
 2 
2. 
Em uma organização, vários processos podem ter níveis de capacidade diferentes. A ISO/IEC 15504 define 6 níveis de 
capacidade, sequenciais e cumulativos. Determine a ordem correta conforme o nível de prioridade dado a cada um. 
 1) Incompleto,executado, gerenciado, estabelecido, previsível, otimizando. 
 2) Executado, otimizando, gerenciado, incompleto, previsível, estabelecido. 
 3) Estabelecido, incompleto, previsível, otimizando, gerenciado, executado. 
 4) Incompleto, gerenciado, estabelecido, executado, previsível, otimizando. 
 5) Otimizando, executado, previsível, incompleto, gerenciado, estabelecido. 
 1 
3. 
O MPS.BR desmembra-se em três outros modelos que reforçam a implantação da melhoria no desenvolvimento de software. 
Assinale a alternativa que melhor especifica esses desmembramentos. 
 1) Modelos de referência (MR-MPS), métodos de avaliação (MA-MPS), guia de negócios (MN-MPS). 
 2) Modelo de consistência (MC-MPS), método deavaliação (MA-MPS), guia de negócios (NM-MPS). 
 3) Método de negócios (MN-MPS), guia de referência (MR-MPS), modelo de negócios(NM-MPS). 
 4) Método de referência (MR-MPS), modelo de avaliação (MA-MPS), guia de negócios (NM-MPS). 
 1 
 
Aula 10: A gerência de riscos na qualidade de software 
1. Proporcionar uma visão geral do processo de gerência de risco. 
2. Compreender as atividades da gerência de risco. 
3. Conhecer a aplicabilidade da gerência de risco nos modelos de qualidade de software. 
Neste estudo, pretende-se enfatizar que o gerenciamento de risco é fator de grande importância e utilidade no 
alcance da maturidade organizacional. 
 A prática de atividades de identificação, análise, planejamento e monitoração de riscos devem ser realizadas de 
forma sistematizada e controlada durante todo o processo de desenvolvimento de software. 
 Ressalta-se a necessidade de avaliações constantes e contínuas dos fatores e eventos associados a cada risco 
priorizado, como uma forma de implementar a melhoria e garantir a qualidade do processo de desenvolvimento de 
software. 
 Veremos, ainda, alguns dos riscos de software mais comuns de ocorrerem no ambiente organizacional. 
Conceito de Risco 
“Haverá um número maior de mudanças de requisitos do que o previsto”. 
“O hardware essencial ao projeto não será entregue dentro do prazo”. 
“O Pessoal experiente deixará o projeto antes do seu término”. 
“Haverá mudança na gerência da organização com diferentes prioridades”. 
“A tecnologia sobre a qual foi construído foi superada por uma nova tecnologia”. 
“Um produto concorrente foi lançado no mercado antes da conclusão do sistema”. 
“As ferramentas CASE que apoiam o projeto não funcionam conforme o previsto”. 
“As especificações das interfaces essenciais não estarão disponíveis dentro do prazo”. 
“O tamanho do sistema foi subestimado”. 
Esses exemplos são riscos? 
Um risco é qualquer evento ou condição em potencial que, se concretizando, pode afetar positivamente ou 
negativamente um objetivo do projeto, por exemplo, o software que está sendo desenvolvido ou a organização. 
 
 
 
Atividades de Risco 
O plano de gerenciamento de riscos é parte integrante e essencial do processo de desenvolvimento de software. 
Dessa forma, as atividades de gerenciamento de riscos, bem como seus custos, devem ser adequadas a cada projeto 
em particular. 
Identificação de riscos: descoberta dos riscos potenciais para o projeto, produto e negócios. 
Análise de riscos: capacidade de compreender, analisar, estimar e avaliar as dimensões de cada fator de risco 
individual e o seu peso para o conjunto. 
Planejamento de risco: elaboração de planos para cuidar dos riscos evitando-os ou minimizando seus efeitos no 
projeto. 
Monitoração de riscos: observação da efetividade dos planos de ação na execução do desenvolvimento do projeto 
de software. 
À medida que mais informações sobre os riscos se tornarem disponíveis, os riscos deverão ser analisados novamente 
e novas prioridades deverão ser estabelecidas. 
Na identificação de riscos, podem surgir até 6 (seis) tipos de riscos e, para auxiliar o processo de descoberta, pode 
ser aplicada uma abordagem de brainstorming ou a própria experiência. No momento de identificação dos tipos de 
risco, a técnica de checklist pode ser usada como apoio ao processo. 
 
Durante o processo de análise de riscos, você deve fazer uma avaliação de sua probabilidade e seriedade. As 
avaliações não precisam ser numéricas, mas devem basear-se em um número de faixas. 
 
Fatores de Risco 
Os efeitos do risco podem ser avaliados como catastróficos, sérios, toleráveis ou insignificantes, veja exemplos na 
tabela abaixo: 
 
Após análise e classificação dos riscos, você deve avaliar os mais significativos a partir da combinação da 
probabilidade da ocorrência do risco e de seus efeitos ou seriedades. 
 
O processo de planejamento de riscos requer estratégias para gerenciá-los. 
 
Mas o que devo fazer ao detectar os riscos? 
Veja a seguir a tabela de estratégias de gerenciamento de riscos, com alguns exemplos de riscos e como proceder 
caso ocorram: 
 
Atenção 
Lembre-se que as estratégias devem promover a confiabilidade, a proteção, a segurança e a qualidade reduzindo 
substancialmente, o impacto geral da ocorrência de um risco no projeto ou no produto. 
A monitoração de riscos envolve a avaliação regular daqueles que forem identificados para decidir se eles estão ou 
não se tornando mais ou menos prováveis e se os efeitos dos mesmos mudaram. Trata-se de um processo contínuo 
e, a cada revisão de progresso feita, é necessária a discussão sobre cada um dos principais riscos separadamente. 
 
O Instituto de Engenharia de Software (SEI) (1990) define o processo de gerência de risco de software através de um 
modelo contínuo de gerenciamento de riscos composto por seis fases distintas: 
 
Nesta aula, você aprendeu: 
 Sobre gerenciamento de riscos e alguns dos riscos que podem surgir em projetos 
de software. 
 Aplicabilidade da gerência de riscos nos modelos de qualidade de produto e processo 
de software. 
 Portanto, lembre-se sempre de identificar e avaliar os principais riscos de um projeto de 
desenvolvimento de software a fim de definir a probabilidade de riscos e as 
consequências para o projeto. Você deve elaborar planos para evitar gerenciar ou lidar 
com os prováveis riscos se ou quando eles ocorrerem. A cada reunião de progresso do 
projeto, os riscos devem ser explicitamente discutidos. 
 
 
 
1. 
 Marque a alternativa que melhor defina o conceito de riscos: 
 1) Possíveis eventos, com probabilidade de ocorrência e impacto conhecidos. 
 2) Possíveis eventos, favoráveis ou desfavoráveis para o projeto. 
 3) Possíveis eventos, inesperados ou desconhecidos pelo gerente do projeto. 
 4) Todas as respostas acima. 
 2 
 2. 
 O ambiente de um projeto de desenvolvimento de software caracteriza-se por eventos típicos da condição de: 
 1) Incerteza. 
 2) Certeza. 
 3) Relativa incerteza. 
 4) Instabilidade. 
 1 
 3. 
 Um nível de risco muito alto para um evento de risco implica uma probabilidade de ocorrência desse evento maior do 
que: 
 1) 90%. 
 2) 50%. 
 3) 10%. 
 4) Nenhuma das respostas anteriores. 
 4