Buscar

Qualidade de software resumo

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 18 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 18 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 18 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Aula 01
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.
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.
Qualidade é atuar em todas as fases – Verificando conformidade com os padrões e definições.
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.
Pressman (2002), 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.
ANOS 50: Erros conhecidos, APÓS término do programa.
ANOS 70: Análise/programação estruturada. Falta de consenso: teste ANTES do término.
ANOS 80: Primeiras preocupações e PADRÕES com QUALIDADE de software.
ANOS 90: Primeiros processos de testes. Motivação: Bug do milênio.
ANOS 2000: Estruturação dos procedimentos de testes dentro do processo de desenvolvimento. Surgem 
excelentes ferramentas de testes. QUALIDADE Total no processo de desenvolvimento e produto de 
software.
A REALIDADE DE PROJETOS DE SOFTWARES REGISTRAM QUE:
Mais de 30% dos projetos são cancelados antes de serem finalizados;
Mais de 70% dos projetos falham nas entregas das funcionalidades;
Os custos extrapolam em mais de 180% do orçamento inicial;
Os prazos excedem em mais de 200% os cronogramas originais.
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.
ONDE ESTÃO OS DEFEITOS DO SOFTWARE ?
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.
O erros de codificação em si, representam um % pequeno, mostrando que o foco do problema não é da 
Implementação.
NORMAS
ISO - International Organization for Standardization
IEC - International Electrotechnical Comission
Nível Internacional: Normas como as da ISO e IEC, resultantes da cooperação e acordo entre 
determinado número de nações com interesses comuns.
Nível Regional: Normas estabelecidas por um limitado grupo de países de um mesmo continente para 
benefício mútuo e normas editadas após consenso dos interessados em um país por uma organização 
nacional de normas que seja reconhecida como autoridade no respectivo país.
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 e Boa manutenção .
SOMMERVILLE (2007) ESTABELECE QUE O GERENCIAMENTO DE QUALIDADE ESTÁ ESTRUTURADO EM 
TRÊS ATIVIDADES PRINCIPAIS:
Garantia de: Padrões que conduzem a um software de alta qualidade.
Planejamento de: Seleção de procedimentos e padrões apropriados adaptados para um projeto de 
software específico.
Controle de Qualidade: Aprovação de processos que assegurem que o desenvolvimento de software 
tenha seguido corretamente os procedimentos e padrões de qualidade de projeto.
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:
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.
QUAIS AS DIFICULDADES EM SE PROVER QUALIDADE NO PROCESSO?
• Ausência de procedimentos claros, até mesmo de um processo definido
• Ausência de técnicas de desenvolvimento (análise, projeto e programação)
• Ausência de registro das decisões e modelos (documentação)
POR QUE DEVEMOS NOS PREOCUPAR COM QUALIDADE NO PROCESSO?
• Porque é através do processo que se gera o produto (PROCESSO MANUFATURADO).
• Para garantir que os produtos desenvolvidos por aquele processo tenham as mesmas características 
(minimiza a subjetividade)
POR QUE QUALIDADE É TER CONFORMIDADE COM OS REQUISITOS?
• Por que se não atender ao que o usuário precisa (requisitos), o SW não terá atingido o seu objetivo e 
sem isso, não há qualidade.
COMO A QUALIDADE SE REFLETE NO PROCESSO?
• Aumento de produtividade
• Redução de custos (menos re trabalho e menos perdas)
• Menor prazo de Entrega
COMO A QUALIDADE SE REFLETE NO PRODUTO?
• Reaproveitamento de código
• Código mais legível (entendimento de terceiros)
• Facilidade de manutenção
O INMETRO, Instituto Nacional de Metrologia, Normalização e Qualidade Industrial, é o órgão brasileiro 
responsável pelo credenciamento e supervisão de organismos de certificação, organismos de inspeção e 
laboratórios de ensaios, nas empresas nacionais.
Aula 02
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.
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.
ATIVIDADE CENTRAL DE REVISÃO TÉCNICA FORMAL (FORMAL TECHINAL REVIEW – FTR) - Tem o 
propósito único de descobrir 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. 
PADRÕES E PROCEDIMENTOS FORMAIS – São aplicados no processo de engenharia de software e 
validados pelos desenvolvedores quanto ao cumprimento dos padrões exigidos pelo software. Em alguns 
casos, o grupo de SQA pode realizar uma auditoria independente do atendimento aos padrões exigidos.
ATIVIDADE DE CONTROLE DE MUDANÇAS - Formaliza pedidos de mudança, avalia a natureza da mesma 
e controla o respectivo impacto que ela pode causar. O controle de mudança é aplicado durante o 
desenvolvimento de software e após a manutenção do software.
MEDIÇÃO DE SOFTWARE - Coleta um conjunto de medidas técnicas e orientadas para a administração 
das especificações do software.
ANOTAÇÃO E MANUTENÇÃO DE REGISTROS (DOCUMENTAÇÃO) - É essencial para a garantia da 
qualidade de software no que diz respeito à coleta e à disseminação de informações de SQA. Os resultados 
de revisões, auditorias, controle de mudanças, testes e outras atividades de SQA devem torna-se parte de 
um registro histórico de um projeto documentado.
McCall (1977) considera as seguintes categorizações sobre os fatores que afetam a qualidade de 
software e podem ser descritos da seguinte forma:
REVISÃO
Manutenibilidade: capacidade de reparação de erros no programa de forma a torná-lo disponível para 
uso.
Flexibilidade: esforço para se modificar um programa operacional.Testabilidade: tempo necessário para se testar um programa a fim de garantir que ele execute a função 
pretendida.
OPERAÇÃO
Corretitude: é o atendimento do programa às especificações e objetivos visados pelo cliente.
Confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida.
Eficiência: quantidade de recursos de computação e de código necessária para um programa executar a 
função desejada.
Integridade: controle de acesso ao software ou a dados de forma controlada.
Usabilidade: esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa.
TRANSIÇÃO
Portabilidade: demanda de esforço para transferir um programa de um ambiente de hardware e/ou 
software para outro.
Reusabilidade: propriedade de reutilizar um programa ou partes de um programa em outras aplicações 
(refere-se ao empacotamento e escopo de funções que o programa executa).
Interoperabilidade: esforço exigido para se acoplar um sistema a outro.
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.
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
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, 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
CUSTOS DE PREVENÇÃO (prevenção de defeitos – 5 a 15 %) - Planejamento da Qualidade, Revisões 
Técnicas Formais, Equipamentos de Teste, Treinamento. São controláveis e caracterizam investimento.
CUSTOS DE AVALIAÇÃO (remover do processo produtos com defeitos – 20 a 25%) - Inspeção Intra e 
Interprocessos, Calibração e Manutenção do Equipamento e Teste. São incontroláveis e caracterizam perdas 
e prejuízo.
CUSTOS DE FALHA INTERNA (defeito antes da entrega ao cliente – 65 a 70 %) - Trabalho para Refazer, 
Esforço para Reparar e Análise do Modo como a Falha Ocorreu. São incontroláveis e caracterizam perdas e 
prejuízo.
CUSTOS DE FALHA EXTERNA (defeito após a entrega ao cliente – 65 a 70 %) - Solução de Queixas, 
Devolução e Substituição do Produto e Manutenção da Linha de Suporte. São incontroláveis e caracterizam 
perdas e prejuízo.
REVISÃO TÉCNICA FORMAL - RTF
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. Cada RTF é 
conduzida como uma reunião. 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).
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.
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.
Aula 03
GARANTIA ESTATÍSTICA DE QUALIDADE SOFTWARE - Reflete uma tendência entre os profissionais da 
área de computação e apóia-se na questão quantitativa a respeito da freqüência de ocorrência de erros e 
inconsistências nos softwares rastreados ao longo de um período específico de tempo.
1906 - Desde então, criaram-se vários órgãos normativos que perseveraram no propósito da 
padronização e assim em 1906, surge a International Electrotechnical Commission (IEC) com ênfase na 
eletrotécnica.
1926 - Surge a International Federation of the National Standardizing Associations (ISA), com ênfase na 
engenharia mecânica. 
1947 - Mais tarde, com o fim da II Guerra Mundial, em Londres, estabelece a nova organização, a 
Organização Internacional para Padronização, iniciando oficialmente as suas operações em 23 de fevereiro 
de 1947 com sede em Genebra, na Suíça.
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.
ISO 9000 - Descreve os elementos de garantia em termos genéricos, que podem ser aplicados a qualquer 
negócio independentemente dos produtos ouserviços oferecidos.
ISO 9001: Garantia da qualidade em projetos/desenvolvimento, produção, instalação e assistência 
técnica.
ISO 9002: Garantia da qualidade em produção e montagem, instalação, prestação de serviço.
ISO 9003: Garantia da qualidade em inspeção e testes finais.
ISO 9004: Gestão da qualidade e elementos do sistema de qualidade – diretrizes.
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.
CONFIABILIDADE DE SOFTWARE - Em termos gerais, “a probabilidade de operação livre de falhas de um 
programa de computador num ambiente específico durante determinado tempo especificado”. Musa (1987) 
citado por Pressman(2002, pg. 768).
Também considerar que um número mínimo de falhas ocorrerá na execução de um software dada 
garantia de que atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo.
SEGURANÇA DE SOFTWARE - Uma atividade de garantia da qualidade de software que detecta e avalia 
riscos em potencial, que podem provocar falhas e impactar o desempenho de todo o sistema.
É também considerada uma atividade de garantia de qualidade de software, que se concentra na 
identificação e avaliação de causalidades em potencial que possam exercer impacto negativo sobre o 
software e provocar falhas no sistema.
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.
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.
SÉRIE DE NORMAS NBR ISO 9000: EDIÇÃO 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 - diretrizes para melhoria de desempenho
ISO 9001: Sistemas de gestão da qualidade - requisitos
SÉRIE DE NORMAS NBR ISO 9000: EDIÇÃO 2000
Aula 04
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).
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.
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 AVAIADA 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.
ISO/IEC 9126 -2 – Métricas Externas
ISO/IEC 9126 -3 – Métricas Internas
ISO/IEC 9126-4 – Métricas da Qualidade em Uso
QUALIDADE EM USO - é a visão de qualidade que o usuário tem do software e é medida em termos do 
resultado da utilização do software.
Aula 05
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.
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
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.
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.
Aula 06
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.
A norma 14598 possui relação com a norma 9126, que estabelece: Métricas externas, Métricas internas 
e Métricas de qualidade de uso.
Pela Norma, podem existir três enfoques diferentes para a avaliação da qualidade de produto:
Processo para Desenvolvedores, Processo para Avaliadores e Processo para Compradores.
A NORMA ISO/IEC 14598 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. 
O processo de Avaliação da Norma 14.598-5, que cuida da Avaliação do ponto de vista do Avaliador, 
possui 4 fases, que são, na ordem:
Estabelecer os requisitos, Especificar, Projetar e Executar a Avaliação.
Anorma 14598-3, esta voltada a avaliação dos produtos intermediários do processo de 
desenvolvimento e ciclo de vida do software, qualquer que seja a sua fase. A quem essa avaliação pode 
interessar:
Gerente de projeto, analistas de sistemas e equipe de manutenção.
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 ISO/IEC 14598-4 AO REFERENCIAR O PROCESSO DE AQUISIÇÃO DEFINIDO PELA ISO/IEC 12207 
RESSALTA A EXISTÊNCIA DAS SEGUINTES ATIVIDADES:
INICIAÇÃO - O adquirente inicia o processo de aquisição ao considerar a necessidade de obter, 
desenvolver ou melhorar um sistema, produto ou serviço de software.
PREPARAÇÃO DO PEDIDO DE PROPOSTA - Elaboração dos documentos de requisitos de aquisição bem 
como determinados os pontos de controle para revisão e auditoria do progresso do fornecimento.
PREPARAÇÃO E ATUALIZAÇÃO DO CONTROLE - Seleção de fornecedores e suas capacidades firmadas em 
contrato e, negociado o custo, cronograma de execução. As mudanças no contrato devem ser controladas 
pelo adquirente.
MONITORAÇÃO DO FORNECEDOR - Consiste em atividades de avaliação durante a execução do contrato 
levando à aceitação e entrega do produto de software.
ACEITAÇÃO E CONCLUSÃO - Aceitação e entrega do produto de software final, obedecidos aos critérios 
de aceitação previamente definidos durante a atividade de iniciação.
AS ATIVIDADES DO PROCESSO DE AVALIAÇÃO DE PRODUTO 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.
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.
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.
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 07
CONTEXTO DE USO DA NORMA ISO 9000-3 - Orientar um contrato entre duas partes que exige a 
demonstração da capacidade do fornecedor em desenvolver, fornecer e bem como, manter softwares. 
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.
ISO 9000-3 - 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.
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).
Considera apenas quais processos a organização deve ter e manter, 
Não orienta quanto aos passos que devem ser seguidos para chegar a desenvolvê-los e nem de como 
aperfeiçoá-los.
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 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.
Todas as atividades de teste e inspeção do produto devem ser devidamente controladas por meio de 
registros.
Aula 08
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.
Conjunto de tarefas ordenadas - 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.
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.
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.
MODULARIDADE E RESPONSABILIDADE - Os processos da ISO/IEC 12207 são fortemente coesos, ou seja, 
todas as partes de um processo são fortemente relacionadas. Porém, os processos são fracamente 
acoplados quanto à quantidade de interfaces entre os processos.
REGRAS PARA IDENTIFICAÇÃO. ESCOPO E ESTRUTURAÇÃO DOS PROCESSOS:
Um processo deve ser modular, ou seja, deve executar uma e somente uma função dentro do ciclo de 
vida com a menor incidência de interfaces entre dois processos.
Se um processo A é invocado por um processo B e somente por ele, então A pertence a B.
Se uma função é invocada por mais de um processo, entãoessa 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.
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.
APOIO - Os processos de apoio são de responsabilidade da organização que o executa.
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.
PROCESSOS DE ADAPTAÇÃO - Realizar a adaptação básica da norma para um projeto de software.
Aula 09
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.
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.
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:
Planejamento da Melhoria, Implementação, Confirmação, Manutenção e Acompanhamento da Melhoria.
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.
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).
Práticas base (base practice).
Produtos de trabalho (work-products).
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.
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.
Representações do CMMI
Contínua - Permite que uma organização selecione uma área (ou um grupo de áreas) de processo e 
melhore os processos relacionados. 
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.
O CMMI pode ser considerado: Um modelo de capacidade e Um modelo de maturidade. 
MPS.BR
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.
O MPS.BR desmembra-se em três outros modelos que reforçam a implantação da melhoria no 
desenvolvimento de software:
Modelos de referência (MR-MPS), Métodos de Avaliação (MA-MPS), Guia de Negócios (MN-MPS).
Aula 10
Conceito 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.
Riscos Negativos – AMEAÇAS
Riscos Positivos - OPORTUNIDADES
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 e Imprevisíveis.
A PROBABILIDADE DO RISCO PODE SER:
Muito baixa (< 10%)
Baixa (10-25%)
Média (25-50%)
Alta(50-75%)
Muito alta (> 75%)
Os efeitos do risco podem ser avaliados como catastróficos, sérios, toleráveis ou insignificantes.
O PROCESSO DE PLANEJAMENTO DE RISCOS REQUER ESTRATÉGIAS PARA GERENCIÁ-LOS:
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.
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.
GABARITO AV1
190809 – D
190824 – A
190834 – A
190860 – C
190866 – C
190876 – D
190880 – A
190885 – B
190898 – B
190901 – A

Outros materiais