RESUMOQUALIDADEDESOFTWARE

Prévia do material em texto

Bibliografia 
 
Fique atento aos livros que servirão de base para o conteúdo das aulas, bem como para sua consulta: 
 
PFLEEGER, S. ​Engenharia de software ­ Teoria e Prática.​ 2ª Ed. São Paulo: Pearson/Prentice­Hall, 2004. 
 
SOMMERVILLE, Ian. ​Engenharia de software.​ 8ª ed. São Paulo: Pearson Education, 2007. 
 
PRESSMAN, R. ​Engenharia de software.​ 6ª Ed. São Paulo: McGraw­Hill Interamericana do Brasil, 2002. 
 
Bibliografia complementar 
 
ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves(Org.). ​Qualidade e 
Produtividade de software.​ São Paulo: Makron Books do Brasil, 1999. 
 
ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves(Org.). ​Qualidade de 
software: teoria e prática.​ São Paulo: Makron Books do Brasil, 2001. 303p. 
 
MOLINARI, Leonardo. ​Testes de software ­ Produzindo Sistemas Melhores e mais Confiáveis.​ São Paulo: 
Erica, 2003. 
 
Normas ABNT 
 
NBR ISO 9001: ​sistemas de qualidade – modelo para garantia da qualidade em projeto, desenvolvimento, 
instalação e assistência técnica (processo)​. ABNT. Rio de Janeiro, 1994. 
 
NBR ISO 9003: ​gestão da qualidade e garantia da qualidade – terminologia. Aplicação da norma ISO 9000 
para o processo de desenvolvimento de software.​ ABNT. Rio de Janeiro, 1994. 
 
NBR ISO/IEC 9126: ​engenharia de software – qualidade de produto. ​ABNT. Rio de Janeiro, 1991. 
 
NBR ISO/IEC 9126­1: ​engenharia de software – qualidade de produto. Parte 1: modelo de qualidade.​ ABNT. 
Rio de Janeiro, jun. 2003. 
 
NBR ISO/IEC 9241­11:​ engenharia de software – requisitos ergonômicos para trabalho de escritórios com 
computador. Parte 11 – Orientações sobre usabilidade.​ ABNT. Rio de Janeiro, 1998. 
 
NBR ISO/IEC 12207: ​engenharia de software – processos de ciclo de vida de software.​ ABNT. Rio de Janeiro, 
1991. 
 
NBR ISO/IEC 12119:​ tecnologia de informação – pacotes de software – testes e requisitos de qualidade. 
ABNT. Rio de Janeiro, out. 1998. 
 
NBR ISSO/IEC 13596:​ tecnologia de informação – avaliação de produto de software​ – 
 
NBR ISO/IEC 14598: ​tecnologia de informação – avaliação de produto de software.​ ABNT. Rio de Janeiro, ago. 
2001. 
 
NBR ISO/IEC 15504: ​engenharia de software – software Process,​ ISO/IEC JTC1 SC7. International Standard 
Organization – ISO/IEC.1993. 
 
 
 
Aula 2: Fatores, métricas e garantias de qualidade de ​software 
 
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). 
 
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. 
 
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 
 
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 seja a 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 REGISTRO (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. 
 
OUTROS FATORES QUE AFETAM A QUALIDADE DO SOFTWARE: 
 
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. 
 
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 errose 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ção e 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: 
 
CUSTOS DE PREVENÇÃO (prevenção de defeitos 5 a 15%) 
 
Atividades decorrentes: planejamento da qualidade, revisões técnicas formais, equipamentos de teste e 
treinamento. 
 
São controláveis e caracterizam investimento​. 
 
CUSTOS DE AVALIAÇÃO (remover do processo produtos com defeito ­ 20 a 25%) 
 
Atividades decorrentes: inspeção intra e interprocessos, calibração e manutenção do equipamento, e teste. 
 
São incontroláveis e caracterizam perdas e prejuízo. 
 
CUSTOS DE FALHA INTERNA (defeito antes da entrega ao cliente ­ 65 a 70%) 
 
Atividades decorrentes: trabalho para refazer, esforço para reparar, análise do modo como a falha ocorreu. 
 
São incontroláveis e caracterizam perdas e prejuízo. 
 
CUSTOS DE FALHA EXTERNA (defeito após a entrega ao cliente ­ 65 a 70%) 
 
Atividades decorrentes: solução de queixas, devolução e substituição do produto, manutenção da linha de suporte. 
 
São incontroláveis e caracterizam perdas e prejuízo. 
 
>>​ 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.  
 
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). 
 
REVISÃO TÉCNICA FORMAL 
 
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. 
• Fixe e mantenha uma agenda. 
• Limite ao debate e a refutação. 
• Foco nas áreas problemáticas. 
• Registre as anotações por escrito. 
• Reduzir número de participantes. 
• Definir uma lista de conferência (checklist) para cada produto revisado. 
• Atribuir recursos e uma programação de tempo para as FTRs. 
• Realizar treinamento para os revisores. 
• Rever antigas revisões. 
 
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.  
 
>>>>> 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çãode 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 objetivos para 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. 
 
 
****!!! JUnit ­ procura erros no software. 
 
 
Aula 3: Garantia estatística da qualidade e a abordagem da NBR ISO 9000 
 
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. 
 
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: 
 
● 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. 
 
Alguns defeitos são descobertos e rastreados até uma (ou mais) das seguintes causas: 
 
Especificações incompletas ou mal formuladas.  
Distorção na interpretação da comunicação com o cliente. 
Desvio voluntário das especificações. 
Violação dos padrões de programação. 
Erro na apresentação dos dados. 
Inconsistência na interface de componente. 
Lógica do projeto inconsistente. 
Teste incompleto ou errôneo. 
Documentação imprecisa ou incompleta. 
Erro na tradução do projeto para a linguagem de programação. 
Interface entre homem­máquina ambígua ou inconsistente. 
Miscelânea. 
 
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 ​poucas causas 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”. 
 
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. 
 
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. 
 
A árvore de falhas consiste em construir um modelo gráfico das combinações sequenciais e concorrentes de 
eventos que podem apresentar um evento ou estado de sistema perigoso. Com a construção de uma árvore de 
falhas bem desenvolvida, pode­se observar as conseqüências de uma seqüência de falhas inter­relacionadas que 
ocorram em diferentes componentes do sistema. 
 
A lógica de tempo real consiste no desenvolvimento de um​ modelo de eventos e ações correspondentes​, que é 
estudado por meio do uso de operações lógicas para testar as pressuposições de segurança sobre os 
componentes do sistema e o tempo de ocorrência. 
 
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 
 
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.  
 
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. 
 
NORMA BASE 2000: 
ISO 9004: Sistemas de gestão da qualidade ­ diretrizes para melhoria de desempenho 
ISO 9001: Sistemas de gestão da qualidade ­ requisitos 
 
 
 
Aula 4: NBR ISO/IEC 9126 (produto de ​software​) e NBR ISO/IEC 12119 (pacote 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.  
 
Programas e dados, na verdade, são os requisitos de programas e dados que devem estar descritos, caso existam, 
para funcionamento do produto.  
 
Um pacote de software está em conformidade com esta Norma se atende a todos os requisitos de qualidade nela 
definidos. 
 
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. 
 
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​.  
 
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. 
 
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: 
 
ISO/IEC 9126­2: MÉTRICAS EXTERNAS 
ISO/IEC 9126­3: MÉTRICAS INTERNAS 
ISO/IEC 9126­4: MÉTRICAS DE QUALIDADE EM USO 
 
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: 
 
FUNCIONALIDADE 
CONFIABILIDADE 
USABILIDADE 
EFICIÊNCIA 
MANUTENIBILIDADE 
PORTABILIDADE 
 
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.  
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A ​ISO 9000​ descreve os elementos de garantia em termos ​genéricos​, quepodem 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. 
 
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). 
 
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. 
 
 
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áveis de 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. 
 
REPETITIBILIDADE: 
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. 
 
REPRODUZIBILIDADE:  
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 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. 
 
 
 
 
 
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, intelegibilidade, 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: 
 
 
 
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 energiaou 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. 
 
 
Aula 5: ISO/IEC 9241 – Usabilidade de Produto 
 
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 
 
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 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. 
 
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. 
 
Para especificar ou medir usabilidade, algumas especificações são necessárias: 
 
­ Descrição dos objetivos pretendidos; 
 
­ Descrição dos componentes do contexto de uso incluindo usuários, tarefas, equipamento e ambientes 
(contexto existente ou pretendido); 
 
­ Valores reais ou desejados de eficácia, eficiência e satisfação para os contextos pretendidos. 
 
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ÁRIO:​ 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 reaprendizado. 
 
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. 
 
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. 
 
EX.: 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. 
 
EX.: 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 gastosna 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. 
 
EX.: 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 sub carga 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. 
 
!!!! ATENÇÃO: ​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. 
 
 
Para mais informações sobre o assunto de nossa aula, leia: 
o artigo “Usabilidade de Software”; 
 
o artigo “Avaliação da usabilidade de software em SI: o caso do SI Submarino”. 
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. 
 
Aula 6: ISO/IEC 14598 ­ Avaliação de produto 
 
 
 
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​.  
 
Pela Norma, podem existir três enfoques diferentes para a avaliação da qualidade de produto: 
 
­ Processo para Desenvolvedores 
­ Processo para Avaliadores 
­ Processo para Compradores 
 
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. 
 
Deve­se avaliar a qualidade do produto liberado por diversas razões:  
 
IDENTIFICAR E ENTENDER ​As razões técnicas para as deficiências e limitações do produto, que podem 
manifestar­se através de problemas operacionais e problemas de manutenção;  
COMPARAR ​Um produto com outro, mesmo que indiretamente; 
FORMULAR ​Um plano de ação de como fazer o produto de software evoluir. 
 
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: 
 
­ Criação de critérios para benchmark. 
­ Avaliação da eficácia e qualidade de qualquer aquisição.  
­ Obtenção de padrões e de informações técnicas. 
­ Desenvolvimento de padrões e ferramentas. 
­ Desenvolvimento de software. 
­ coleta e análise de resultados de avaliações 
­ distribuição dos resultados de avaliação 
­ facilitação da transferência de tecnologia e suporte a projetos de avaliação  
 
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ção usada 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.  
 
O plano pode ser divulgado por meio de palestras e reuniões técnicas. 
 
A estrutura de um plano de avaliação quantitativa deve conter : 
 
­ introdução 
­ objetivos 
­ características da qualidade aplicáveis 
­ lista de prioridades 
­ objetivos da qualidade 
­ cronograma 
­ definição de responsabilidades 
­ categorias de medição 
­ uso e análise de dados 
­ relatórios 
­ demais requisitos de interesse 
 
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 PEDIDO 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ériosde 
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.  
 
Os avaliadores podem ser especificamente: 
 
­ Os laboratórios de testes 
­ As equipes de testes integradas de organizações de produção ou de distribuição de software 
­ Os compradores ou usuários de software ou de integradoras de sistemas  
­ As organizações que realizam comparações de softwares 
 
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. 
 
São gerados vários documentos que passam a ser considerados como parte do produto de software, tais 
como: 
 
­ documentos de projeto 
­ relatórios de teste e validação 
­ código fonte  
­ documentação de usuário 
 
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.). 
 
Aula 7: Modelos de melhoria e avaliação de processo de software ISO 9000­3 
 
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 ISO9000­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 desenvolvimento de 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émda 
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 componetes. 
 
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). 
 
TESTE DE INSPEÇÃO E 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. 
 
Aula 8: Modelo de qualidade do processo de ciclo de vida do ​software​ NBR ISSO / IEC 
12207 
 
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: 
 
­ uma sequência de etapas é sempre seguida para contemplar um conjunto de tarefas. 
­ As tarefas, por sua vez, são realizadas na mesma ordem todas as vezes. 
­ Por fim, considera­se um conjunto de tarefas ordenadas como sendo um processo: uma série de etapas que 
envolvem atividades, restrições e recursos para alcançar a saída desejada. 
 
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.  
 
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. 
 
Um processo é descrito pela pertinência de um conjunto de atividades atreladas a um ​propósito​.   
 
Propósito/Resultado:​  reconhecimento do ​objetivo​, da necessidade de execução do processo (propósito) e o que 
ele ​deve produzir ​como saída (resultado). 
 
Atividade ou tarefa:​ descrição das ​atividades ​e suas inter­relações, bem como a ​sequência ​de ​execução ​de 
cada atividade ou tarefa. São descritos os procedimentos, métodos, ferramentas para que possam ser realizadas 
as atividades de forma adequada.  
 
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