Resumo Qualidade de Software - Anotações Aulas

Prévia do material em texto

QUALIDADE DE SOFTWARE (CCT0247/2252337) 9001 
 
Aula 1: Conceito de Qualidade 
 
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: 
- Qualidade: Estar em conformidade com os requisitos dos clientes; Antecipar e satisfazer os desejos dos 
clientes; Escrever tudo o que se deve fazer e fazer tudo o que foi escrito. 
- Qualidade de Software: Conformidade a requisitos funcionais e de desempenho explicitamente 
declarados a padrões de desenvolvimento claramente documentados e a características implícitas que são 
esperadas de todo software profissionalmente desenvolvido. 
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. 
Por ser assim, Pressman (2002) complementa que: Os requisitos de software são a base da medição da 
qualidade; Os padrões especificados (standards) definem um conjunto de critérios de desenvolvimento; 
Existe um conjunto de características implícitas não mencionadas: Facilidade de uso; Boa manutenção. 
Por outro lado, Sommerville (2007) estabelece que o gerenciamento de qualidade está estruturado em 
três atividades principais: - Qualidade: Padrões que conduzem a um software de alta qualidade. – 
Planejamento: Seleção de procedimentos e padrões apropriados adaptados para um projeto de software 
específico. – Controle: Aprovação de processos que assegurem que o desenvolvimento de software tenha 
seguido corretamente os procedimentos e padrões de qualidade de projeto. 
 
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. 
 
O Aumento da Qualidade no PROCESSO acarreta: Garantia de estarmos fazendo o Software CERTO. 
Aumento de produtividade. Redução de Custos: Menos retrabalho e menos perdas. Menor prazo de 
entrega. O Aumento da Qualidade do PRODUTO acarreta: Reaproveitamento de código de programa. 
Programas mais eficientes. Menor custo e mais facilidade de manutenção. É mais fácil fazer software 
CORRETO do que consertá-lo (conclusão após longo período de remendo de software). 
 
Saiba mais 
Referência sobre o tema "Qualidade de Software: uma necessidade" 
http://www.unisalesiano.edu.br/salaEstudo/materiais/pd6952/material1.pdf 
"Qualidade de Software: uma necessidade" 
http://www2.unemat.br/rhycardo/download/qualidade_em_software.pdf 
 
Aula 2: Fatores, Métricas e Garantia da Qualidade de Software 
 
A medição ajuda a tornar visíveis características específicas de processos e produtos. Por que medir a 
qualidade? Para determinar um valor de grandeza. Mede e compara o SW com algum dado (padrão) e 
obtém uma indicação de qualidade. O que devemos medir? Processo e Produto. 
Fatores que afetam a qualidade: - Mensuráveis diretamente: Tempo, Custo, produtividade; - Mensuráveis 
indiretamente: Usabilidade, Manutenibilidade (subjetivos), Complexidade. 
A garantia da qualidade de software (Software Quality Assurance - SQA) trata-se de uma atividade 
“guarda-chuva”, aplicada ao longo de todo o processo de engenharia de software. Abrange uma série de 
tarefas vinculadas especificamente a sete atividades que compõem um plano que realiza avaliações, 
 
 
 
auditorias, revisões, define padrões para o projeto, procedimentos para relato, acompanhamento de 
erros, documentação necessária e realimenta a equipe com informações conclusivas do projeto. 
- Aplicação de Métodos e Ferramentas Técnicas: O estudo dos métodos e ferramentas técnicas de análise, 
projeto, codificação e teste são atribuídos aos princípios fundamentais da análise de requisitos de 
software de sistemas. Ajudam o analista e o projetista a produzirem um projeto de elevada qualidade. 
- Atividade Central de Revisão Técnica Formal (Formal Techinal Review - FTR): Tem o propósito único de 
descobrir problemas de qualidade. Essa atividade é específica da equipe técnica, tem descoberto que as 
revisões são tão efetivas quanto os testes para detecção de problemas de qualidade. 
- Atividade de Teste de Software: Conhecida como “rede de segurança” de garantia de software, combina 
uma série de métodos de projetos de casos de testes que auxiliam a garantir uma detecção de erros 
efetiva. As atividades de teste aplicadas de forma cuidadosa revelam a maioria dos erros, aliviando a 
necessidade de outras atividades de SQA. Porém, considera-se atualmente que não seja a mais efetiva 
para todas as classes de erros. 
- Padrões e Procedimentos Formais: São aplicados no processo de engenharia de software e validados 
pelos desenvolvedores quanto ao cumprimento dos padrões exigidos pelo software. Em alguns casos, o 
grupo de SQA pode realizar uma auditoria independente do atendimento aos padrões exigidos. 
- 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. 
 
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. 
- Revisão: Manutenibilidade: capacidade de reparação de erros no programa de forma a torná-lo 
disponível para uso. Flexibilidade: esforço para se modificar um programa operacional. Testabilidade: 
tempo necessário para se testar um programa a fim de garantir que ele execute a função pretendida. 
- Operação: Corretitude: é o atendimento do programa às especificações e objetivos visados pelo cliente. 
Confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida. Eficiência: 
quantidade de recursos de computação e de código necessária para um programa executar a função 
desejada. Integridade: controle de acesso ao software ou a dados de forma controlada.Usabilidade: 
esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa. 
- Transição: Portabilidade: demanda de esforço para transferir um programa de um ambiente de 
hardware e/ou software para outro. Reusabilidade: propriedade de reutilizar um programa ou partes de 
um programa em outras aplicações (refere-se ao empacotamento e escopo de funções que o programa 
executa). Interoperabilidade: esforço exigido para se acoplar um sistema a outro. 
 
Métricas de Qualidade: - Auditabilidade: facilidade na verificação de conformidade aos padrões 
especificados. - Acurácia: precisão das computações e do controle dos padrões. Comunidade de 
comunicação: o grau em que interfaces padrões, protocolos e larguras de banda são usados. - Inteireza: 
função implementada com sucesso de acordo com a forma requerida. - Concisão: programa compacto em 
termos de linha de código. - Consistência: uniformidade no uso de técnicas de projeto e documentação ao 
longo do projeto. - Comunidade de dados: padronização na estrutura e tipos de dados necessários. - 
Tolerância a erros: impacto do dado quando o programa detecta erro. - Eficiência de execução: 
desempenho fantástico na execução. - Expansibilidade: capacidade de ampliação da arquitetura, dos 
procedimentos e dos dados. - Generabilidade: aplicação ampla de componentes de programa. - 
Independência de hardware: desvínculo do software em relação ao hardware em que opera. - 
Instrumentação: monitoramento da própria operação do software e a capacidade de identificação rápida 
de erros. - Modularidade: independência funcional dos componentes do programa. - Operabilidade: 
facilidade de operação de um programa. - Segurança: mecanismos disponíveis para proteção de 
programas e dados. - Autodocumentação: documentação significativa do código-fonte. - 
Simplicidade: entendimento sem dificuldades de um programa. - Independência do software básico: o 
quanto um programa é independente de particularidades não-padronizadas de linguagens de 
 
 
 
programação. - Rastreabilidade: capacidade de rastrear componentes de programa até os requisitos. - 
Treinamento: o quanto o software auxilia novos usuários a aplicarem o sistema. 
 
Revisões de Software: As revisões são métodos de validação de qualidade de um processo ou produto 
amplamente usado pela equipe técnica do projeto. São consideradas como verdadeiros “filtros” de erros e 
inconsistências no processo de desenvolvimento de software. São tipos de revisão específicos do 
gerenciamento de qualidade, segundo Sommerville (2007): 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 fornece 
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. 
 
As revisões Técnicas Formais - RTF: 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; 5. Tornar os projetos mais administráveis (Sommerville, 2007). 
 
Aula 3: Garantia Estatística da Qualidade e a Abordagem da NBR ISO 9000 
 
A qualidade de software é responsabilidade de todos os participantes envolvidos no desenvolvimento de 
software. Pode ser conseguida através de análise, projeto, codificação e teste de componente, mas, com 
toda certeza, uma efetiva aplicação de revisões técnicas formais para controle de produtos de trabalho de 
software e de modificações feitas neles são consideradas técnicas eficientes de obtenção de qualidade de 
software. 
- Garantia estatística de qualidade de software (Software Quality Assurance - SQA): 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. 
 
SQA Estatística: Apoio Quantitativo. Base: Frequência da ocorrência de erros e inconsistências, ao longo 
do período de tempo. Objetivo: Aprimorar os elementos do processo que promovem erro. Segundo 
Pressman (2004) estes são os passos para realizar a SQA estatística: Coletar e categorizar os defeitos de 
software encontrados; Rastrear o defeito até sua causa subjacente; Considerar que 20% do código têm 
80% dos defeitos; Corrigir os problemas que causaram os defeitos. 
Alguns defeitos são descobertos e rastreados até uma ou mais das seguintes causas: Especificações 
incompletas ou mal formuladas; Distorção na interpretação da comunicação com o cliente; Desvio 
voluntário das especificações; Violação dos padrões de programação; Erro na apresentação dos dados; 
Inconsistência na interface de componente; Lógica do projeto inconsistente; Teste incompleto ou errôneo; 
Documentação imprecisa ou incompleta; Erro na tradução do projeto para a linguagem de programação; 
Interface entre homem-máquina ambígua ou inconsistente; Miscelânea. É certo que toda ação que visa 
eliminar e corrigir erros em softwares é suscetível a geração de novas causalidades mais ou menos graves 
que as anteriores, portanto, atente para o caso de realizar testes exaustivos para não comprometer de 
fato todo um sistema. 
 
- Confiabilidade de Software: consiste em considerar que um número mínimo de falhas ocorrerá na 
execução de um software dada a garantia de que atenderá ao estabelecimento de parâmetros de 
conformidade para o sucesso do processo. 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: é uma atividade de garantia da qualidade de software que detecta e avalia 
riscos em potencial, que podem provocar falhas e impactar o desempenho de todo o sistema. É também a 
atividade que se concentra na identificação e avaliação de causalidades em potencial que possam exercer 
impacto negativo sobre o software e provocar falhas no sistema. Passos para implementação da 
Segurança: Identificar a presença de riscos o mais cedo possível. Traçar as estratégias no projeto de 
software que eliminem ou controlem esses riscos em potencial. Identificar a avaliar casualidades que 
possam impactar, negativamente, o SW causando falhas, categorizar as falhas por criticidade e risco. 
Analisar a gravidade e probabilidade de ocorrência. Listar os requisitos de segurança para do Software 
- Análise: O passo seguinte seria analisar, por meio de técnicas, a gravidadee a probabilidade de 
ocorrência. Algumas técnicas são aplicáveis: - Á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; - 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. 
 
- 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. 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. Vantagens: 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. - Gestão: Prover confiança a própria administração de que seus produtos 
atenderão à satisfação dos clientes. - Garantia: Prover confiança aos clientes de que os produtos 
atenderão à sua satisfação. 
- Modelos da norma ISO 9000: - ISO 9001: Mais completa, Garantia da qualidade em 
projetos/desenvolvimento, produção, instalação e assistência técnica; - ISO 9002: Garantia da qualidade 
em produção e montagem, instalação, prestação de serviço; - ISO 9003: Garantia da qualidade em 
inspeção e testes finais; - ISO 9004: Gestão da qualidade e elementos do sistema de qualidade, 
diretrizes. 
- Princípios ISO 9000:2000: Foco no cliente. Liderança. Envolvimento das pessoas. Abordagem de 
processo. Abordagem sistêmica para a gestão. Melhoria contínua. Abordagem para tomada de decisões. 
Benefícios mútuos nas relações com fornecedores. Norma base 2000: - ISO 9004: Sistemas de gestão da 
qualidade - diretrizes para melhoria de desempenho. - ISO 9001: Sistemas de gestão da qualidade – 
requisitos. 
- ABNT: Orgão brasileiro responsável pelas normas de qualidade. Representa, no Brasil a ISO e a IEC 
(International Eletrotechnical Commision). Cuida da preparação das normas técnicas, mas também pode 
verificar a implantação e uso das normas em empresas. 
 
Saiba mais 
Consulte o site oficial da ISO - http://www.iso.org/iso/home.htm 
Consulte o site do INMETRO - http://www.inmetro.gov.br 
Consulte o site da ABNT - http://www.abnt.org.br 
 
OBS: Das opções abaixo, qual não representa norma certificadora do setor de software? R: ISO 14000 
- O modelo da série da norma ISO 9000 (edição 1994) apresenta a seguinte descrição: R: ISO 9001 
 
Aula 4: NBR ISO/IEC 9126 (produto de software) e NBR ISO/IEC 12119 (pacote de software) 
 
A NBR ISO/IEC 9126-1, publicada em 1991, apresenta uma definição de qualidade como sendo a 
"totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades 
explícitas e implícitas" (2003, p.17). As necessidades explícitas (ou externas) dependem do que foi 
especificado nos requisitos referentes às condições em que o produto deva ser utilizado, seus objetivos, 
funções e o desempenho esperado. Já as implícitas (ou diretas) são necessidades que embora não 
estejam especificadas nos requisitos, devem ser levadas em consideração, pois se baseiam em princípios 
básicos e óbvios, necessários para que o usuário execute a sua tarefa. 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. 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. De acordo com a Associação Brasileira de Normas Técnicas - ABNT, a série da NBR 
ISO/IEC 9126 se subdivide da seguinte forma: ISO/IEC 9126-2 = Métricas Externas; ISO/IEC 9126-3 = 
Métricas Internas; ISO/IEC 9126-4 = Métricas da Qualidade em Uso. 
Os requisitos de qualidade incluem que: 1) cada pacote de software deve ter uma descrição do produto e 
documentação do usuário; 2) a descrição de produtos deve conter informações que sejam testáveis e 
corretas e, 3) requisitos para a documentação do usuário, programas e dados que façam parte do pacote. 
A descrição do produto inclui as principais propriedades do pacote. A documentação do usuário nada mais 
é que um documento que será avaliado em relação à sua completitude, correção, consistência, 
inteligibilidade, apresentação e organização. Programas e dados, na verdade, são os requisitos de 
programas e dados que devem estar descritos, caso existam, para funcionamento do produto. Um pacote 
de software está em conformidade com esta Norma se atende a todos os requisitos de qualidade nela 
definidos. 
 
A garantia e controle de qualidade no desenvolvimento de software ao operarem simultaneamente, visam 
garantir que os artefatos de software sejam desenvolvidos e entregues com melhor aceitabilidade, menos 
defeitos e menores custos. - Garantia de Software: Promove a gerência sênior da organização uma 
melhor visibilidade apropriada sobre o processo de desenvolvimento. - Controle de Qualidade: Objetiva 
testar os produtos de software de modo a encontrar, relatar e remover seus defeitos. 
A qualidade do produto de software pode ser avaliada pela medição: dos atributos internos (tipicamente 
medidas estáticas de produtos intermediários); dos atributos externos (tipicamente medidas do 
comportamento do código quando executado); dos atributos de qualidade em uso. O objetivo é que o 
produto tenha o efeito desejado em um contexto particular de uso. 
- Modelo de qualidade de Software: 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. 
 
Para Pressman (2002), o uso de um modelo de qualidade apoia a categorizaçãode 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, 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. (checklist). 
 
Princípios da ISO 9000: A ISO 9000 descreve os elementos de garantia em termos genéricos, que podem 
ser aplicados a qualquer negócio independentemente dos produtos ou serviços oferecidos. Dessa forma, 
um sistema de garantia da qualidade que promove a estrutura organizacional, define responsabilidades, 
cria procedimentos e processos, capacita recursos para implementar a gestão da qualidade em todo ciclo 
de vida de um produto, certamente, demanda de uma intervenção normativa para que materiais, 
produtos, processos e serviços satisfaçam as expectativas do cliente, de acordo com suas especificações. 
Então, a avaliação e melhoria de um processo é um meio para melhorar a qualidade do produto, e a 
avaliação e melhoria da qualidade do produto é um meio de melhorar a qualidade em uso. Similarmente, 
a avaliação da qualidade em uso pode dar um feedback para melhorar o produto e a avaliação da 
qualidade do produto pode dar feedback para melhorar o processo. 
 
 
 
 
Qualidade de 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 os requisitos especificados 
na NBR ISO/IEC 9126-1(item 6.4). - Significância: As métricas relevantes devem agregar informações 
sobre o comportamento do software, porém as não relevantes devem ser descartadas; - Custo e 
complexidade: Aplicação da métrica deve ser econômica e tecnicamente viável. Destaca-se que algumas 
métricas não satisfazem esse critério por demandarem um investimento acima do orçamento (laboratórios 
e usuários-teste) ou demandar técnicas sofisticadas como métodos estatísticos; - Repetibilidade: Os 
resultados gerados devem ser idênticos ao aplicar a medição: 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. 
 
- 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 independentemente da aquisição do produto. As declarações sobre funcionalidade, 
confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade devem ser avaliadas; - 
Documentação do Usuário: Trata-se de um conjunto completo de documentos disponível na forma 
impressa ou não, que é fornecido para a utilização de um produto, sendo também uma parte integrante 
do produto. Deve incluir todos os dados necessários para a instalação, para o uso da aplicação e para a 
manutenção do software produto. Deve fazer referência a completude, correção, consistência, 
intelegibilidade, apresentação e organização; - Programas e dados: Os requisitos de qualidade para 
Programas e Dados utilizam as mesmas definições das características da norma ISO/IEC 9126. Descreve 
em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, 
confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 
 
- 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: ISO/IEC 9241 - Usabilidade de Produto 
 
O objetivo de projetar e avaliar computadores buscando usabilidade consiste em proporcionar que os 
objetivos sejam alcançados pelos usuários bem como satisfaçam suas necessidades em um contexto 
particular de uso. Desta forma, a ISO/IEC 9241-11 esclarece os benefícios de medir usabilidade em 
termos de desempenho e satisfação do usuário, a usabilidade dos computadores depende do contexto de 
uso e afirma que o nível de usabilidade alcançado dependerá das circunstâncias específicas nas quais o 
produto é usado. 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. 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. 
 
 
 
- 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: Conjuntode 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. 
 
Para especificar ou medir usabilidade, algumas informações são necessárias: Descrição dos objetivos 
pretendidos; Descrição dos componentes do contexto de uso incluindo usuários, tarefas, equipamento e 
ambientes (contexto existente ou pretendido); Valores reais ou desejados de eficácia, eficiência e 
satisfação para os contextos pretendidos. 
- Contexto de uso: O nível no qual o objetivo global pretendido é estabelecido é uma função do limite do 
sistema de trabalho em consideração e que fornece o contexto de uso, no que diz respeito a determinados 
elementos. 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. 
1.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; 2.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. 3.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 frequê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. 4.Equipamentos: As características relevantes do equipamento tais como o hardware, 
software e materiais associados com o computador precisam ser descritas. 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. 
- Eficácia: Relacionam aos objetivos ou sub-objetivos do usuário quanto a acurácia e completude com que 
estes objetivos podem ser alcançados. Ex.: Se o objetivo desejado for reproduzir com acurácia um 
documento de duas páginas em um formato específico, então a acurácia pode ser especificada ou medida 
pelo número de erros de ortografia e pelo número de desvios do formato especificado e a completude pelo 
número de palavras do documento transcrito dividido pelo número de palavras do documento de origem. 
- Eficiência: Relacionam o nível de eficácia alcançada ao dispêndio de recursos. Recursos relevantes 
podem incluir esforço mental ou físico, tempo, custos materiais ou financeiros. Ex.: Se o objetivo 
desejado for imprimir cópias de um relatório, então a eficiência pode ser especificada ou medida pelo 
número de cópias usáveis do relatório impresso, dividido pelos recursos 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. Ex.: Outras medidas de 
satisfação podem ser: número de comentários positivos e negativos registrados durante o uso; 
informação adicional como taxas de absenteísmo, observação de sobrecarga ou subcarga de trabalho 
físico ou cognitivo do usuário, problemas de saúde relatados, frequência com que os usuários requerem 
transferência para outro trabalho. 
 
Avaliação de usabilidade durante o projeto: - Especificação do contexto pretendido de uso para um 
produto: pode ser informações sobre as características do usuário, seus objetivos e tarefas e os 
ambientes nos quais estas são realizadas fornecem subsídios importantes para uso na especificação dos 
requisitos globais do produto. - Especificação de requisitos de usabilidade para um produto: antes do 
desenvolvimento, uma organização que busca adquirir um produto especificamente adaptado para suas 
necessidades pode especificar requisitos de usabilidade onde o produto poderá adequar-se ou não, 
levando em consideração quais testes de aceitação poderão ser realizados. - Desenvolvimento de 
produto: equipes de desenvolvimento de produto podem estabelecer um entendimento comum do 
 
 
 
conceito de usabilidade determinando a abrangência das questões associadas à usabilidade do produto. 
Um desenvolvente pode usar a orientação da norma para ajudar a especificar os objetivos da usabilidade 
para o produto. - Especificação ou avaliação de atributos de produto: a orientação sobre o contexto de 
uso pode ser usada para identificar os usuários, tarefas e ambientes, de modo que possam ser feitos 
julgamentos mais precisos sobre as necessidades por atributos específicos do produto. - Medidas de 
usabilidade: a descrição das características dos usuários pode ajudar na seleção destes para participar na 
avaliação. A identificação dos objetivos do usuário pode ajudar na escolha de tarefas apropriadas para 
testes ou revisões de usabilidade. As características do ambiente no qual um produto provavelmente será 
usado precisam ser descritas se aquele ambiente tiver que ser simulado para assegurar a validade dos 
resultados dos testes. 
 
Saiba mais 
Acesse o link, veja o que é Usabilidade: http://www.youtube.com/watch?v=NSyEl7_pJ80&feature=related 
 
Revisão - Aula 1 a 5 
 
- ONDE ESTÃO OS DEFEITOS? A maior dificuldade esta na fase INICIAL, de entendimento do sistema - 
Requisitos – ALTO grau de ABSTRAÇÃO + Comunicação com pessoas. A segunda maior abrangência está 
na modelagem – ALTO Grau de ABSTRAÇÃO + domínio das técnicas. Os erros de codificação em si, 
representam um % pequeno, mostrando que o foco do problema não é da Implementação. 
- As Visões da Qualidade: - Usuário: Facilidade de uso, Desempenho, Confiabilidade dos Resultados, Preço 
do Software, etc.; - Desenvolvedor: Taxa de Defeitos, Facilidade de Manutenção e Conformidade em 
relação aos Requisitos dos Usuários, etc.; - Organização: Cumprimento de Prazo, Boa Previsão de Custos, 
Boa Produtividade. 
- Categoria Revisão: - Manutenibilidade; Capacidade de ajuste e melhorias do programa, mantendo-o 
atual. - Flexibilidade: Esforço para se modificar o programa. - Testabilidade: Tempo para teste de um 
programa, garantindo sua eficácia. 
- Categoria Operação: - Corretitude: Atende as especificações e objetivos do cliente? - Confiabilidade: 
Executa sempre da mesma forma? Com a precisão exigida. - Eficiência: Quantidade de recursos (Harware 
e Software) para um programa executar a função desejada. - Integridade: Controle de acesso ao software 
ou a dados de forma controlada. - Usabilidade: Esforço para aprender e operar, preparar a entrada e 
interpretar a saída de um programa. 
- Categoria Transição: - Portabilidade: Esforço para transferir um programa de um ambiente de hardware 
ou software para outro. - Reusabilidade: Usar programa ou partes de um programa em outras aplicações. 
- Interoperabilidade: Esforço exigido para se acoplar um sistema a outro, Integração de Soluções. 
- Métrica Confiabilidade: A probabilidade de um programa operar sem falhas, num ambiente específico 
durante determinado tempo especifico”. Alta Disponibilidade do software - Hoje. 
- MétricaSegurança: Problema: sistema de segurança crítico. Trata-se de uma Atividade SQA. Detecta e 
avalia riscos em potencial, que podem provocar falhas e impactar o desempenho. Identifica e avalia 
causalidades em potencial que possam exercer impacto negativo e provocar falhas. 
- Qualidade: Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as 
necessidades explícitas e implícitas. As 2 necessidades subsidiam as validações e verificações. - Explícitas 
(externas) = condições em que produto deve ser usado, objetivos, funções, desempenho esperado 
(depende de especificações de requisitos). - Implícitas (internas) = Não estão especificados nos 
requisitos, mas são características obvias e fundamentais. 
- Qual a importância da interface no software moderno: Esclarece os benefícios de medir usabilidade em 
termos de desempenho e satisfação do usuário. Emprega o termo usabilidade para referenciar mais 
precisamente aos atributos de um produto que o torna mais fácil de usar (hardware, software ou 
serviços), além das medidas relevantes de usabilidade não cobre os processos de desenvolvimento de 
sistema. 
 
Aula 6: ISO/IEC 14598 - Avaliação de Produto 
 
A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de software e 
fornece guias para a avaliação, baseados na utilização prática da norma ISO/IEC 9126. Pela Norma, 
podem existir três enfoques diferentes para a avaliação da qualidade de produto: Processo para 
Desenvolvimento, Processo para Avaliadores, Processo para Computadores. Avaliar a qualidade de um 
produto de software é: Verificar, através de técnicas e atividades operacionais, o quanto os requisitos são 
atendidos. Tais requisitos, de uma maneira geral, expressam as necessidades explicitadas em termos 
quantitativos ou qualitativos e apresentam como objetivo a definição das características de um software, 
 
 
 
a fim de permitir o exame de seu entendimento. Razões para Avaliar a qualidade do SW: Identificar e 
Entender: As razões técnicas para as deficiências e limitações do produto; Comparar: Um produto com 
outro, mesmo que indiretamente; Formular: Um plano de ação de como fazer o produto de software 
evoluir. 
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 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. 
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 levado 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; - Projetos 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. 
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. 
 
Aula 7: Modelos de Melhoria e Avaliação de Processo de Software ISO 9000-3 
 
Melhoria de processo de software: 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 de 
sistemas de software. A prática da melhoria de processo de software tem se mostrado viável, eficaz e 
eficiente. 
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”. 
 
 
 
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çãocontí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. 
 
- A estrutura do guia ISO 9000-3: Destina-se a fornecer orientação quando um contrato entre duas partes 
exigir a demonstração da capacidade do fornecedor em desenvolver, fornecer e manter produtos de 
software. De fato, a ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, 
fornecimento e manutenção de software. As diretrizes propostas na ISO 9000-3 cobrem questões como: 
Entendimento dos requisitos funcionais entre contratante e contratado; Uso de metodologias consistentes 
para o desenvolvimento de software; Gerenciamento de projeto desde a concepção até a manutenção. 
Relevante destacar que uma das limitações da ISO 9000-3 é o fato de não tratar de aspectos como a 
melhoria contínua do processo de software (SPI – Software Process Improvement). Dessa forma, a ISO 
9000-3 considera apenas quais processos a organização deve ter e manter, mas não orienta quanto aos 
passos que devem ser seguidos para chegar a desenvolvê-los e nem de como aperfeiçoá-los. A 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 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) Prefácio e 
Introdução. B) Objetivo e abrangência. C) Referências. D) Termos e definições. E) Entradas e métricas. F) 
Interpretação de resultados. G) Anexo de procedimento de aplicação. 
 
- 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 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. 
- Requisitos do Sistema de Qualidade: Deve ser documentado na forma de um manual e, assim, 
implementado. 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: 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. 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 Projetos de 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 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. 
- Controle de Documento 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 controladose 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. 
- 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. 
- 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. 
 
Aula 8: Modelo de Qualidade do Processo de Ciclo de Vida do Software NBR ISO/IEC 12207 
 
A NBR ISO/IEC 12207 - Processos de Ciclo de Vida de Software tem como objetivo o estabelecimento de 
uma estrutura comum para os processos de ciclo de vida de software como forma de ajudar as 
organizações a compreenderem todos os componentes presentes na aquisição e fornecimento de software 
e, assim, conseguirem firmar contratos e executarem projetos de forma eficaz. As pesquisas em torno da 
engenharia de software mostram a relevância da resolução de problemas de falhas em projetos basear-se 
em modelos de melhoria e processo que permeiam três variáveis de suma importância e nenhuma mais 
importante que a outra, mas conjuntamente expressivas no contexto de desenvolvimento de software: 
Processo, Pessoas, Tecnologia. 
- Processo: Quando é fornecido um serviço ou criado um produto, no caso específico de um software: 
Uma sequência de etapas é sempre seguida para contemplar um conjunto de tarefas. As tarefas, por sua 
vez, são realizadas na mesma ordem todas as vezes. Por fim, considera-se um conjunto de tarefas 
ordenadas como sendo um processo: uma série de etapas que envolvem atividades, restrições e recursos 
para alcançar a saída desejada. Para Pfleeger (2004), um processo envolve um conjunto de métodos, 
técnicas, ferramentas e pessoas de forma a prescrever todas as suas principais atividades. Complementa 
que cada atividade do processo tem critérios de entrada e saída, de modo que seja possível saber quando 
o processo começa e termina. Elementos de um processo: Entrada – Processo – Saída --- 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. 
Os processos da ISO/IEC 12207 são fortemente coesos, ou seja, todas as partes de um processo são 
fortemente relacionadas. Porém, os processos são fracamente acoplados quanto à quantidade de 
interfaces entre os processos. Regras para identificação, escopo e estruturação dos processos: Um 
processo deve ser modular, ou seja, deve executar uma e somente uma função dentro do ciclo de vida 
com a menor incidência de interfaces entre dois processos. Se um processo A é invocado por um 
processo B e somente por ele, então A pertence a B. Se uma função é invocada por mais de um processo, 
então essa função torna-se um processo. Deve ser possível verificar qualquer função dentro do modelo de 
ciclo de vida. A estrutura interna deve ser suficientemente definida para que possa ser executável. 
 
- Escopo da Norma 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. Cabe, portanto, as partes envolvidas a responsabilidade de adaptação dos processos, atividades 
e tarefas da norma a fim de atender ao modelode ciclo de vida para o projeto de software. De acordo 
com a natureza dos processos esses se agrupam da seguinte forma: Fundamental: Os processos 
fundamentais iniciam o ciclo de vida do software e comandam a execução de todos os outros processos. 
Eles constituem um conjunto de cinco processos que são: Aquisição – inicia o ciclo de vida de software. 
Fornecimento – responde pela execução dos processos de desenvolvimento, operação e manutenção. 
Desenvolvimento – contém as atividades e tarefas que devem ser executadas pelo desenvolvedor. 
 
 
 
Operação – contém as atividades e tarefas do operador com a cobertura do software e o suporte 
operacional dos usuários. Manutenção – torna-se ativo quando o produto de software é submetido a 
modificações no código e na documentação associada devido a um problema, necessidade de melhoria ou 
adaptação. Algumas atividades importantes para o desenvolvimento de software serão descritas com base 
na norma ISO/IEC 12207. São elas: Implementação. Levantamento de requisitos. Análise dos requisitos 
do software. Projeto da arquitetura do software. Projeto detalhado do software. Codificação e testes do 
software. Integração do software. Teste de qualificação do software. Instalação do software. Testagem e 
aprovação do software; Apoio: Os processos de apoio são de responsabilidade da organização que o 
executa. O objetivo é proporcionar qualidade aos outros processos, pois através de sua execução 
acredita-se que eles terão garantia de qualidade e uma maior organização. Podem ser utilizados pelos 
processos fundamentais de apoio organizacional; 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, Identificação do Ambiente do Projeto: 
modelo e atividades de ciclo de vida; requisitos do sistema; políticas, procedimentos e estratégias 
organizacionais; tamanho, e tipos de sistema, produto ou serviço de software; e quantidade de pessoas. 
Solicitações de Informações: Avaliar os impactos das informações nas decisões de adaptação dos 
usuários, pessoal de suporte, gerentes de contrato e potenciais proponentes. Seleção de Processos, 
atividades e tarefas: Definição de processos, atividades e tarefas que serão executadas com a devida 
documentação desenvolvida e seus respectivos responsáveis. Documentação de decisões e motivos de 
adaptação: Requer a documentação das decisões de adaptação juntamente com seus motivos. É 
interessante reforçar a característica da norma por meio das atividades e tarefas do processo de ciclo de 
vida do software; somente especificar “o que fazer” e não “como fazer”. Outra característica que diz 
respeito à norma é possibilitar a modularidade do processo, a forte coesão entre os processos 
fundamentais de apoio e organizacionais. Isso significa que todas as partes de um processo estão 
fortemente relacionadas, porém a quantidade de interfaces entre os processos é mínima. Algumas regras 
são importantes para identificação, escopo e estruturação dos processos e devem ser seguidas. Um 
processo deve ser modular, isto é, convém que um processo execute uma e somente uma função dentro 
do ciclo de vida e é conveniente que as interfaces entre dois processos quaisquer sejam mínimas. Cada 
processo é invocado na arquitetura. Se um processo A é invocado por um processo B e somente por ele, 
então A pertence a B. Se uma função é invocada por mais de um processo, então essa função torna-se 
um processo. Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida. Convém que 
cada processo tenha uma estrutura interna suficientemente definida para que possa ser executável. 
 
Saiba mais 
Norma NBR ISO/IEC 12207 no site www.abnt.org.br 
 
OBS: Os processos de apoio são de responsabilidade da organização que o executa. Eles constituem um 
conjunto de processos. A seguir, estão listados alguns destes processos. R: Documentação - Garantia da 
qualidade - Gerência de configuração de software 
 
Aula 9: Modelo de Qualidade do Processo de Software NBR ISO/IEC 15504 - (SPICE - 
Avaliação), CMMI e MPS.BR 
 
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: Planejamento da melhoria, Implementação, Confirmação, 
Manutenção, Acompanhamento da melhoria. 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. 
 
- 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 guiapara a melhoria de processo. Cada nível de capacidade é descrito basicamente por um 
nome, definição e atributos. 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. 
Descrição detalhada dos atributos de processos: Nível0: não tem atributos. Nível1: 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. Nível2: 
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. Nível3: 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. Nível4: 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. Nível5: 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. 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. 
- 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 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: Examina necessidades da organização, Inicia 
processo de melhoria, Avalia processo, Planeja melhoria, Implementa melhoria, Confirma melhoria, 
Mantém melhoria, Monitora desempenho. 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ícito de avaliação, mas define os requisitos