Resumo_QualidadeSoftware

Prévia do material em texto

AULA 1 
 
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. 
Existem diversas definições para qualidade e, na visão simples de algumas pessoas, estas a definem como 
sendo: 
 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. 
 
E ainda, segundo Pressman (1995, pg. 724): 
 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. Essas normas podem ser, no que 
diz respeito a sua origem: 
 Nivel Internacional - Normas como as da ISO e IEC, resultantes da cooperação e acordo 
entre determinado número de nações com interesses comuns. 
 Nivel 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: 
o Facilidade de uso; 
o Boa manutenção . 
Por outro lado, Sommerville (2007) estabelece que o gerenciamento de qualidade está estruturado em três 
atividades principais: 
 
GARANTIA DE PLANEJAMENTO DE CONTROLE DE 
Padrões que conduzem a um 
software de alta qualidade 
Seleção de procedimentos e 
padrões apropriados adaptados 
para um projeto de software 
específico. 
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: 
>>>>>>>>>>Influencia 
Qualidade 
de Processo 
Atributos de Qualidade Interna Atributos de Qualidade 
Externa 
Atributos de Qualidade em 
uso 
<<<<<<<<<Depende 
 
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, vamos considerar 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. 
 
AULA 2 
 
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). 
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 Technical 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 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 poderealizar uma auditoria independente do 
atendimento aos padrões exigidos. 
 Atividades 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 
o Manutenibilidade: capacidade de reparação de erros no programa de forma a torná-lo 
disponível para uso. 
o Flexibilidade: esforço para se modificar um programa operacional. 
o Testabilidade: tempo necessário para se testar um programa a fim de garantir que ele 
execute a função pretendida. 
 Operação 
o Corretitude: é o atendimento do programa às especificações e objetivos visados pelo 
cliente. 
o Confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida. 
o Eficiência: quantidade de recursos de computação e de código necessária para um 
programa executar a função desejada. 
o Integridade: controle de acesso ao software ou a dados de forma controlada. 
o Usabilidade: esforço para aprender, operar, preparar a entrada e interpretar a saída de um 
programa. 
 Transição 
o Portabilidade: demanda de esforço para transferir um programa de um ambiente de 
hardware e/ou software para outro. 
o 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). 
o 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. 
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 Sofware 
 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çã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-15%) - São controláveis e caracterizam investimento. 
o Atividades decorrentes: 
 planejamento da qualidade 
 revisões técnicas formais 
 equipamentos de teste 
 treinamento 
 Custos de Avaliação(remover do processo produtos com defeitos 20-25%)-São incontroláveis e 
caracterizam perdas e prejuízo. 
o Atividades decorrentes: 
 inspeção intra e interprocessos 
 calibração e manutenção do equipamento 
 teste 
 Custo de Falha Interna(defeito antes da entrega ao cliente 65-70%)-São incontroláveis e 
caracterizam perdas e prejuízo. 
o Atividades decorrentes: 
 trabalho para refazer 
 esforço para reparar 
 análise do modo como a falha ocorreu 
o Custos de Falha Externa(defeitos após a entrega ao cliente 65 -70%) - São incontroláveis e 
caracterizam perdas e prejuízo. 
 solução de queixas 
 devolução e substituição do produto 
 manutenção da linha de suporte 
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; duranteos 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. 
1. A reunião ocorre a partir da informação do produtor do software ao líder do projeto quanto a 
necessidade de revisão. 
2. 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. 
3. Os revisores selecionados revisam o produto fazendo anotações devidas para efeito de posteriores 
reuniões. 
4. 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. 
 
AULA 3 
 
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 conseguidos 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 apoia-se na questão quantitativa a respeito da frequê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 ideia de racionalização no processo industrial 
implantou a linha de montagem com a implementação de processos padronizados. 
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 Europeia 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. 
Alguns defeitos são descobertos e rastreados até uma (ou mais) das seguintes causas: 
1. Especificações incompletas ou mal formuladas. 
2. Distorção na interpretação da comunicação com o cliente. 
3. Desvio voluntário das especificações. 
4. Violação dos padrões de programação. 
5. Erro na apresentação dos dados. 
6. Inconsistência na interface de componente. 
7. Lógica do projeto inconsistente. 
8. Teste incompleto ou errôneo. 
9. Documentação imprecisa ou incompleta. 
10. Erro na tradução do projeto para a linguagem de programação. 
11. Interface entre homem-máquina ambígua ou inconsistente. 
12. Miscelânea. 
 
Confiabilidade de Software é: 
1. 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) citada por 
Pressman (2002, pg. 768). 
2. 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. 
 
Segurança de software é: 
1. 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. 
2. É 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 possamexercer 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. 
Análise: 
1. Árvore de Falhas - 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, podem-se observar as 
consequências de uma sequência de falhas inter-relacionadas que ocorram em diferentes 
componentes do sistema. 
2. Logica de tempo real - 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 
 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: 
1. Gestão - Prover confiança a própria administração de que seus produtos atenderão à satisfação dos 
clientes. 
2. 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. 
Os modelos da norma ISO 9000 
1. ISO 9001: Garantia da qualidade em projetos/desenvolvimento, produção, instalação e assistência 
técnica. 
2. ISO 9002: Garantia da qualidade em produção e montagem, instalação, prestação de serviço. 
3. ISO 9003: Garantia da qualidade em inspeção e testes finais. 
4. ISO 9004: Gestão da qualidade e elementos do sistema de qualidade – diretrizes. 
Série de normas NBR ISO 9000: edição 1994 
1. NBR ISO 8402 
1.1. Guia de seleção e Uso das Normas NBR ISO 9000: 1994 
1.1.1. Gestão da Qualidade (interna à organização) NBR ISO 9004:1994 – situação não contratuais 
1.1.2. Modelos de Garantia da Qualidade – situações contratuais 
1.1.2.1. NBR ISO 9001:1994 
1.1.2.2. NBR ISO 9002:1994 
1.1.2.3. NBR ISO 9003:1994 
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 - diretriz para melhoria de desempenho 
• ISO 9001: Sistemas de gestão da qualidade – requisitos 
Série de normas NBR ISO 9000: edição 2000 
1. Sistemas de gestão da qualidade – fundamentos e vocabulário NBR ISO 9000: 2000 
1.1. Sistema de Gestão da Qualidade (diretrizes) NBR ISO 9004:2000 - – situações não contratuais 
1.2. Sistemas de Gestão da Qualidade – requisitos situações contratuais 
1.2.1. NBR ISO 9001:2000 
 
AULA 4 
 
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 - Objetivatestar 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. 
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 
ISS/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. 
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. 
 
Características e Subcaracterísticas da Qualidade de Software 
Funcionalidade: capacidade de fornecer funções que correspondam às necessidades explícitas e implícitas 
do usuário quando o software é utilizado sob condições especificadas. 
 Adequação: capacidade de fornecer um conjunto apropriado de funções para tarefas específicas e 
objetivos do usuário. 
 Acurácia: capacidade de fornecer o resultado com o grau de precisão desejado. 
 Interoperabilidade: capacidade de interagir com um ou mais sistemas. 
 Segurança de Acesso: capacidade de proteger dados e informações de pessoas ou sistemas não 
autorizados. 
 Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à 
funcionalidade. 
 
Confiabilidade: capacidade do software de manter seu nível de desempenho quando utilizado em 
condições estabelecidas. 
 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. 
 
 
 Usabilidade: capacidade que o produto tem de ser entendido, aprendido, utilizado e ser atraente para o 
usuário. 
 Unteligibilidade: capacidade do produto de fazer o usuário entender se o software é adequado e 
como ele pode ser usado para tarefas particulares. 
 Aprendibilidade: capacidade que o produto deve ter de fazer o usuário entendê-lo. 
 Operacionalidade: capacidade que o produto deve ter para que o usuário possa aprendê-lo e 
controlá-lo. 
 Atratividade: capacidade do produto em ser atraente para o usuário. 
 Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à 
usabilidade. 
 
Eficiência: relacionamento entre o nível de desempenho do software e a quantidade de recursos utilizados, 
sob condições estabelecidas. 
 Comportamento em Relação ao Tempo: capacidade de fornecer tempos de resposta e 
processamento adequados, bem como taxas de transferência. 
 Comportamento em Relação aos Recursos: capacidade de usar quantidade e tipos de recursos 
adequados. 
 Conformidade: capacidade de aderir a padrões e convenções relativas à eficiência. 
 
Manutenibilidade: esforço necessário para se fazer modificações específicas no software. 
 Analisabilidade: capacidade em diagnosticar deficiências e causas de defeitos. 
 Modificabilidade: capacidade que o produto tem de receber modificações. 
 
Estabilidade: capacidade de evitar efeitos inesperados a partir de modificações. 
 Testabilidade: capacidade de validar as modificações efetuadas no produto. 
 Conformidade: capacidade de aderir a padrões e convenções relativas a manutenibilidade. 
 
Portabilidade: capacidade que o produto tem de ser transferido de um ambiente para outro. 
 Adaptabilidade: capacidade de ser adaptado em diferentes ambientes sem intervenção. 
 Capacidade de Instalação: capacidade de ser instalado em um ambiente específico. 
 Coexistência: capacidade que o produto tem de coexistir com outro software independente em um 
ambiente comum, compartilhando recursos comuns. 
 Capacidade de Substituição: capacidade que o produto de software deve ter de ser usado no lugar 
de outro produto de software com o mesmo propósito no mesmo ambiente. 
 Conformidade: capacidade de aderir a padrões e convenções relativas à portabilidade. 
 
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. 
 
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 esatisfaçã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á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). 
 Significancia - 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:no mesmo 
produto;com a mesma especificação de requisitos; com os mesmos avaliadores, usuários-
testes e ambiente. 
 Reprodutibilidade - Os resultados gerados devem ser idênticos ao aplicar a medição: no 
mesmo produto; com a mesma especificação de requisitos; 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. 
 
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, intelegibilidade, apresentação e organização. 
 Programas de 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 
1. Pré-requisitos para teste: deve ser considerada a presença de itens de produto; de sistema 
necessário e treinamento quando mencionado na descrição do produto. 
2. Registro de teste: deve conter informações suficientes paia permitir a repetição do teste como a 
elaboração do plano de teste, casos de teste, registro de resultados com falhas e/ou sucessos e por 
fim, a identificação de pessoas envolvidas 
3. Atividades de teste: testar se estão de acordo com os requisitos de qualidade tais como a descrição 
do produto, a documentação do usuário e os programas de dados. 
4. Relatório de teste: contém a descrição do produto, o hardware e software utilizado no teste, os 
documentos usados, os resultados dos testes (descricões, documentação, programas e dados), a 
lista de não conformidades dos requisitosl a lista de não conformidades de recomendações e as 
datas do inicio e término do teste (horas gastas na atividade). 
 
Vamos ver todosesses 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. 
 
AULA 5 
 
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 
 
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. 
1. 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. 
2. 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. 
3. 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 informações são necessárias: 
1. Descrição dos objetivos pretendidos; 
2. Descrição dos componentes do contexto de uso incluindo usuários, tarefas, equipamento e 
ambientes (contexto existente ou pretendido); 
3. 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 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: 
 Eficacia - 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 serespecificada 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. 
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 
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. 
 
AULA 6 
 
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: 
1. Processo para Desenvolvedores 
2. Processo para Avaliadores 
3. Processo para Compradores 
 
Veja a relação entre as Normas desta série: 
 
 
Para tanto, a Norma apresenta-se constituída das seguintes partes: 
 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 é: 
1. Verificar, através de técnicas e atividades operacionais, o quanto os requisitos são atendidos. 
1.1. 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: 
1. 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; 
2. Comparar - Um produto com outro, mesmo que indiretamente; 
3. 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. 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 
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 de 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 e 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. 
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 
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. 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 
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. 
 
AULA 7 
 
Melhoria de processo de software 
Para o avanço das organizações intensivas em software (desenvolvimento/aquisição), a prática da 
melhoria de processo de software tem se mostrado viável, eficaz e eficiente. Consiste a abordagem na 
prática de ações orientadas para alteração dos processos aplicados para: 
 Aquisição 
 Fornecimento 
 Desenvolvimento 
 Manutenção e/ou suporte ao sistema de software 
 
Atualmente, a melhoria de processo de software faz parte da disciplina da engenharia de processo de 
software com uma forte tendência em atender concomitantemente aos 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)). 
 
Por capacidade de processo entende-se a habilidade do processo em ser executado de forma eficiente 
e eficaz com a presença de algumas características importantes: 
 Execução consistente e sempre que necessária. 
 Flexibilidade no processo de execução para melhor adaptação das necessidades específicas. 
 Documentação com uma notação representativa de processo identificado por meio de texto, 
figuras, fluxos, etc. 
 Deve ser apropriado para que as pessoas possam realizar o trabalho. 
 Treinamento para as pessoas inseridas nas atividades do processo de forma a obterem 
conhecimento, habilidade e experiência. 
 Manutenção para garantir a evolução contínua. 
 Controle de mudanças para garantir a integridade e disponibilidade dos artefatos. 
 Apoio de equipes, ferramentas e recursos apropriados para realização do processo. 
 
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 equilibrados, 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ãotratar 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 ao 
passo 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. 
Diretrizes da ISO 900-3 
 
 
 
Responsabilidade da gerencia 
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: 
 Identificar e fornecer os recursos adequados para a execução do trabalho do sistema de 
qualidade 
 Indicar um executivo experiente com a devida autoridade para gerenciar o sistema de 
qualidade 
 Possibilitar que os gerentes possam usar os procedimentos e aprimorar a eficiência do 
sistema de qualidade 
 Revisar periodicamente o sistema de qualidade para o seu aprimoramento 
 Manter os registros de todas as revisões 
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 
eviteum 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 garanti-lo 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 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). 
 
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. 
 
AULA 8 
 
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 basearem-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: 
 
 
Vamos, então, concentrar nossos estudos em duas partes: 
1. O significado do processo 
2. Escopo da Norma NBR ISO/IEC 12207 
 
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 às 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. 
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. 
 
Elementos de um processo: 
1. Entradas – matérias primas, serviços, informações, requisitos, etc 
2. Processo – Pessoas utilizando recursos realizam um conjunto de atividades com o proposito de 
transformas as entradasem saídas atendendo os requisitos do cliente; 
3. Saída – produtos e serviços 
 
 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 a 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. 
 
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. 
 
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. 
 
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 Apoio Organizacional Adaptação 
 
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 associada devido 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. 
 
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. 
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. 
 
 
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çãotorna-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. 
 
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 
 
AULA 9 
 
 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 
 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 melhoria cuja 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: 
1. Planejamento da Melhoria 
2. Implementação 
3. Confirmação 
4. Manutenção 
5. Acompanhamento da melhoria 
 
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. 
NÍVEIS DEFINIÇÃO 
0 Incompleto: processo não existe ou geralmente falha. 
1 Executado: processo atinge os objetivos, porém sem padrão de qualidade e sem controle de 
prazos e custos. 
2 Gerenciado: processo planejado e acompanhado, e satisfaz requisitos definidos de qualidade, 
prazo e custos, e seus produtos de trabalho são gerenciados. 
3 Estabelecido: processo executado e gerenciado com uma adaptação de um processo padrão 
definido, eficaz e eficiente. 
4 Previsível: processo executado dentro de limites de controle definidos e com medições detalhadas 
e analisadas. 
5 Otimizando: processo melhorado continuamente de forma disciplinada. 
 
 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. 
 
PA 1.1 Atributo de Execução de Processo – os indicadores relevantes para o atributo são os 
indicadores de execução do processo, variáveis de processo para processo. Consiste n produtos de 
trabalho identificados como as entradas, os produzidos pelo processo e ações tomadas para transformar as 
entradas em saídas. 
PA 2.1 Atributo de Gerência de Execução – consiste na medida da extensão em que a execução do 
processo é gerenciada. O resultado do sucesso do processo contém: 
• Os objetivos para a execução do processo. 
• Planejamento e monitoramento do processo. 
• Ajuste da execução para adequar-se aos planos. 
• Definição das responsabilidades e de responsáveis pela execução, bem como a devida 
comunicação. 
• Os recursos e a informação necessária para a execução do processo. 
• As interfaces entre as partes envolvidas são gerenciadas para gerar uma comunicação efetiva.PA 2.2 Atributo de Gerência de Produto de Trabalho – uma medida de extensão é definida a fim 
de que o processo seja gerenciado para produzir resultados de trabalho. O resultado do sucesso do 
processo contém: 
• Definição de requisitos para produtos de trabalho. 
• Definição de requisitos para documentação e controle dos produtos de trabalho. 
• Produtos de trabalho corretamente identificados, documentados e controlados. 
• Previsão dos produtos de trabalho de acordo com o especificado, planejado e ajustado às 
necessidades dos requisitos. 
PA 3.1 Atributo de Definição de Processo – é medida a extensão pela qual um processo padrão é 
mantido para suportar a distribuição e uso do processo definido. Como resultado da obtenção completa 
desse atributo: 
• Processo padrão com guias de adaptação apropriados de elementos fundamentais ao processo 
definido. 
• Interação do processo padrão com os outros processos. 
• As competências necessárias, papéis, responsabilidades e autorizações para a execução de um 
processo ou parte dele. 
• A infraestrutura necessária e o adequado ambiente de trabalho. 
• Coleta de dados apropriados com a avaliação visando à possibilidade de melhoria contínua. 
PA 3.2 Atributo de Implementação de Processo – a medida define o quanto o processo foi 
efetivamente implementado como definido para alcance de resultados. Os resultados da obtenção 
completa desse atributo: 
• Processo implementado com base no processo padrão selecionado e/ou adaptado. 
• Designação e comunicação de papéis, responsabilidades e autorizações. 
• Responsáveis são apropriados quanto à educação, às habilidades e à experiência. 
• Recursos de informação são disponibilizados, alocados e usados. 
• A infraestrutura e ambiente de trabalho são disponibilizados, gerenciados e mantidos. 
• Dados coletados e avaliados são a base para o entendimento do comportamento do processo. 
PA 4.1 Atributo de Medição de Processo – mede o escopo no qual as medidas de produto e 
processo são usadas para garantir que o desempenho do processo alcance os objetivos de negócio. Como 
resultado do completo atendimento desse atributo: 
• Estabelecimento de objetivos quantitativos para o desempenho do processo de forma coerente 
com os objetivos do negócio. 
• Identificação de medidas de produto e de processo de acordo com os objetivos deste. 
• Coleta das medidas de produto e de processo com fins de monitorar o escopo deste. 
• A capacidade de processo é medida e mantida na unidade organizacional. 
PA 4.2 Atributo de Controle de Processo – mede o escopo no qual o processo é gerenciado 
quantitativamente para produzir um processo estável e capaz, bem como previsível dentro dos limites 
determinados. O resultado do atendimento desse atributo: 
• Aplicação de técnicas de análise e controle apropriadas. 
• Definição de requisitos para frequência da medição. 
• Estabelecimento de limites de controle de variação para o devido desempenho do processo 
normal. 
• Análise de dados para possíveis causas de instabilidade. 
• Aplicação de ação corretiva caso haja necessidade para restabelecimento de limites de controle. 
PA 5.1 Atributo de Inovação de Processo – medida das mudanças ocorridas no processo por meio 
da análise das causas comuns de variação e da investigação de abordagens inovadoras para 
implementação do processo. Os resultados obtidos desse atributo: 
• Definição de objetivos de melhoria de processo que suportem os objetivos do negócio. 
• Dados analisados para busca de oportunidades de inovação e melhores práticas. 
• Identificação de causas reais e potenciais variações na execução do processo. 
• Oportunidades advindas de novas tecnologias e novos conceitos de processo. 
• Estratégias de implementação visando atingir melhorias no processo. 
PA 5.2 Atributo de Otimização de Processo – visa medir o impacto das mudanças de definição, 
gerenciamento e execução do processo de forma eficaz e compatível com os objetivos de melhoria do 
processo. Destacam os resultados desse atributo: 
• Avaliação de impactos decorrentes das mudanças propostas. 
• Gerenciamento de todas as implementações de mudanças acordadas. 
• Avaliação da eficácia da mudança no processo de acordo com os requisitos definidos. 
 
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. 
 O planejamento deve contemplar os seguintes elementos: 
 As atividades a serem executadas na avaliação. 
 Os recursos e cronogramas referentes às atividades. 
 A identidade e as responsabilidades dos participantes da avaliação 
 Os critérios para verificar se os requisitos da norma foram atendidos. 
 Uma descrição dos resultados planejados. 
 
 
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: 
“N” – O atributo não foi atingido pelo processo 
“P” – o atributo foi atingido parcialmente pelo processo 
“L” – o atributo foi atingido largamente pelo processo 
“F” –o atributo foi atingido completamente pelo processo 
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. 
 
Representação dos resultados 
Os resultados da avaliação, incluindo as saídas especificadas, precisam ser documentados e 
comunicados ao patrocinador da avaliação ou a um dos seus representantes. Os principais elementos dos 
resultados são: 
 A data de avaliação. 
 As entradas da avaliação. 
 A identificação das evidências objetivas utilizadas. 
 A abordagem da avaliação. 
 A identificação do processo documentado de avaliação. 
 O conjunto de perfis de processo resultantes da avaliação. 
 
Melhoria de processo com a ISO/IEC 15504 
 Trata-se de descrever um guia para orientação da melhoria de processo, tendo como referência um 
modelo de processo e como uma das etapas a realização de uma avaliação de processo. O guia sugere 8 
etapas sequenciais, conforme ilustra a figura 4.1. 
 
 
A ISO/IEC 15504 não pressupõe modelos de ciclo de vida de software, tecnologias de software ou 
metodologias de desenvolvimento. Também não define um método explícitode avaliação, mas define os 
requisitos para o Método de Avaliação de Processos. Na prática, uma avaliação de processos de software é 
conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos. 
 
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). 
 
Definição, Características e Objetivos do CMMI 
Tomado como modelo de referência, o CMMI é capaz de fornecer uma orientação para o 
desenvolvimento de processos 
de softwares. O objetivo do modelo é: 
 Eliminar as inconsistências. 
 Aumentar a clareza e entendimento. 
 Fornecer uma terminologia comum e um estilo consistente. 
 Estabelecer regras de construção uniformes e assegurar consistência com a ISO/IEC 15504. 
Assim como os demais modelos definem, não é proposta do CMMI definir como o processo deve ser 
implementado, mas determinar como as características estruturais e semânticas em termos de objetivos e 
de grau de qualidade devem ser realizadas no trabalho. 
 
Na concepção do modelo, o CMMI pode ser considerado um modelo de capacidade como um modelo 
de maturidade. Em uma organização, o sucesso do modelo aplicado pode ser conquistado em etapas 
consecutivas de maneira contínua. Afirma-se que o alcance do nível de maturidade de processos 
organizacionais se faz quando os processos alcançam uma determinada capacidade, ou seja, tem 
mecanismos que garantem a repetição sucessiva de bons resultados futuros relacionados principalmente à 
qualidade, custos e prazos. 
 
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 
 
 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 
 
 
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. 
A orientação do MPS.BR é entender e consolidar diversas boas experiências, nacionais e 
internacionais em melhoria do processo de software e estimular a sua melhor disseminação possível no 
Brasil e, pelo menos, em outros países da américa latina. 
 
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. 
 
AULA 10 
 
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çana gerência da organização com diferentes prioridades”. 
“A tecnologia sobre a qual foi construído foi superada por uma nova tecnologia”. 
“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”. 
“Um produto concorrente foi lançado no mercado antes da conclusão do sistema”. 
Esses são exemplos de risco??? 
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. 
 
Classificação de riscos de software 
Quanto à Natureza: 
 Riscos de projeto – pode comprometer o cronograma ou recursos do projeto. 
 Riscos de produto – afetam a qualidade ou desempenho do software desenvolvido. 
 Riscos de negócio – afetam a organização que desenvolve ou adquire o software. 
 
Quanto à probabilidade e ao impacto: 
 Conhecidos 
 Previsíveis 
 Imprevisíveis 
A probabilidade é a chance de ocorrer e o impacto é o efeito sobre o objetivo do projeto, caso o evento ou 
condição de risco venha se manifestar. 
 
O gerenciamento dos riscos do projeto tem por objetivo: 
 Maximizar os resultados dos eventos positivos 
 Minimizar as consequências dos eventos negativos. 
 
No início do projeto, são maiores as incertezas e estas vão diminuindo à medida que avançamos no seu 
desenvolvimento. 
O impacto dos riscos, ao contrário, aumenta à medida que o tempo passa e se caminha para as fases finais 
do projeto. 
 
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. 
 Tecnologia - Componentes de software não devem ser reusados porque contêm defeitos que 
limitam sua funcionalidade. 
 Pessoal - É impossível recrutar pessoal com as habilidades necessárias. 
 Organizacional - Problemas financeiros na organização geram reduções no orçamento do projeto. 
 Ferramentas - O código gerado pelas ferramentas CASE é ineficiente. 
 Requisitos - Os clientes não compreendem o impacto das mudanças de requisitos. 
 Estimativas - O prazo necessário para desenvolver o software foi subestimado. 
 
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. 
A probabilidade do risco pode ser: 
 Muito baixa (< 10%) 
 Baixa (10-25%) 
 Média (25-50%) 
 Alta(50-75%) 
 Muito alta (> 75%) 
 
Fatores de Risco 
 Os efeitos do risco podem ser avaliados como catastróficos, sérios, toleráveis ou insignificantes, 
veja exemplos na tabe 
Risco Probabilidade Seriedade 
O tempo necessário para desenvolver o software foi subestimado. Acima da média Sérios 
As ferramentas CASE não podem ser integradas. Acima da média Toleráveis 
A taxa de reparo de defeitos foi subestimada. Média Toleráveis 
O código gerado pelas ferramentas CASE é ineficiente. Média Insignificante 
 
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. As estratégias podem 
ser categorizadas em: 
 De prevenção: a ocorrência de riscos é reduzida. 
 De minimização: o impacto do risco será reduzido. 
 De contingência: o efeito do risco é forte, mas existe uma alternativa para lidar com o problema. 
Mas o que devo fazer ao detectar os riscos? 
Leja a seguir a tabela de estratégias de gerenciamento de riscos, com alguns exemplos de riscos e como 
proceder caso ocorram: 
 
Risco Probabilidade 
Problemas financeiros 
na organização 
Preparar documento para a gerência superior informando a importância e a 
relevância do projeto para a empresa, a fim de conquistar a concordância e 
conscientização dos riscos encontrados. 
Problemas de 
recrutamento 
Devem ser comunicados ao cliente a fim de alertar sobre as dificuldades 
potenciais e a possibilidade de atrasos nas entregas. 
Doença de pessoal da 
equipe 
Suscita a necessidade de reorganizar a equipe de maneira que haja maior 
superposição de trabalho e compartilhamento de atividades. 
Componentes com 
defeito 
Devem-se substituir componentes parcialmente defeituosos por novos e de 
confiabilidade reconhecida. 
 
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. 
 
Risco Indicadores Potenciais 
Tecnologia Ocorre em detrimento do atraso na entrega de hardware ou software, muitas das vezes, 
apresentando problemas de tecnologia. 
Pessoal Identifica a questão de baixo moral do pessoal como também relacionamentos precários 
entre os membros da equipe. 
Requisitos Evidenciam muitas reclamações de clientes e muitas solicitações de mudança de requisitos. 
Estimativas Mostram as falhas no cumprimento do cronograma, falhas em eliminar defeitos relatados. 
 
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: 
 Planejar a gerência de riscos 
 Identificação de riscos 
 Análise de riscos 
 Plano de respostas aos riscos 
 Rastreamento de riscos 
 Controle de riscos 
Todas as fases estão ligadas através dos esforços de comunicação das equipes envolvidas no processo. 
 
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.