Qualidade de Software Estácio Aula 1 a 5

Prévia do material em texto

QUALIDADE DE SOFTWARE
AULA 1: Conceito de qualidade
O que é?
O conceito de qualidade de software pode ser considerado como um processo sistemático que focaliza todas as etapas e artefatos produzidos como o objetivo de garantir a conformidade de processos e produtos especificados, prevenindo e eliminando defeitos.
Décadas
Década 50: 
A preocupação da equipe centrava-se em detectar erros, que já eram previamente conhecidos, somente após o término do produto.
Década 70: 
O avanço nas práticas e processos da engenharia de software surge na década de 70, mas sem o consenso sobre testes, ou seja, a aplicação de ações para correção de erros antes da entrega do produto ao cliente.
Década 80:
Surgem os primeiros conceitos de qualidade de software considerados como os primeiros padrões mundiais de qualidade.
Década 90:
 O “bug do milênio” ocorre encadeamento da onda dos ajustes em programas antigos e complexos decorrentes de uma imprevisão nefasta de formatação de datas especificas. Com isso, surgem os primeiros processos de testes a fim de evitar a repetição do momento desafiador de virada de século.
Definições de qualidade, na visão mais simples de algumas pessoas:
Qualidade é:
Estar em conformidade com os requisitos dos clientes.
Antecipar e satisfazer os desejos dos clientes.
Escrever tudo o que se deve e fazer tudo o que foi escrito
E ainda, segundo Pressman (1995, pg. 724):
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.
Explicitamente
“explicitamente declarados a padrões de desenvolvimento claramente documentados”
Destaca-se que Pressman (2002), faz referência a padrões de desenvolvimento explicitamente documentados, ou seja, refere-se à aplicação por órgãos especializados, de normas conjuntas que registrem as próprias condições e objetivos propostos pelo desenvolvedor.
Implícitas
“características implícitas”
Da mesma forma, o autor cita as características implícitas, que significam aplicação de normas conjuntas com vistas a atender as diferenças entre os usuários, a evolução do tempo, as éticas, as questões de segurança e outras visões subjetivas do software desenvolvido.
Normas
Para ajudar nessa questão, a International Organization for Standardization – ISO e a International Electrotechnical Comission – IEC, orgãos normalizadores com importância internacionalmente reconhecida no setor de software, se uniram para editar normas internacionais conjuntas para os mais diversos setores, no mundo inteiro.
Essas normas podem ser, no que diz respeito a sua origem:
Nível internacional -> Normas como as da ISSO 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 mutuo e normas editadas após consenso dos interessados em um pais por uma organização nacional de normas que seja reconhecida como autorizada no respectivo país.
Por ser assim, Pressman (2202) complementa que:
Os requisitos de software são a base da medição da qualidade.
Os padrões especificados (Standards) definem um conjunto de critérios de desenvolvimento.
Existe um conjunto de características implícitas não mencionadas:
-	Facilidade de uso; 
-	Boa manutenção.
Por outro lado, Sommerville (2007) estabelece que o gerenciamento de qualidade está estruturado em três atividades principais: 
Garantia de padrões que conduzem a um software de alta qualidade.
Planejamento de seleção de procedimentos e padrões apropriadas adaptados para um projeto de software especifico.
Controle de aprovação de processos que assegurem que o desenvolvimento de software tenha seguido corretamente os procedimentos e padrões de qualidade de projeto.
Enfim, nesta visão, os padrões exigidos devem englobar boas práticas para que sejam gerados produtos de alta qualidade. Dessa forma, acredita-se que há muito mais gerenciamento de qualidade do que padrões e burocracia associada para assegurar que os padrões foram seguidos. Complementa o autor que a base do gerenciamento da qualidade advém de aspectos intangíveis tais como a elegância, a capacidade de leitura do código e da documentação de qualidade gerada ao longo da existência de um software. A documentação de qualidade deve variar de acordo com o tamanho do software tendo como propósito a comunicação entre a equipe que participa do desenvolvimento do software.
Qualidade de Produto X Qualidade de Processo de Software
A qualidade de um sistema de software pode ser entendida sob diversas formas e, utilizando-se diferentes abordagens.
Assim, um conjunto de normas que tratam deste assunto no âmbito da ISSO, 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 especifico de usuário.
Produto:
Compreende os atributos de qualidade e dividem-se em atributos internos e externos, que se diferenciam pela forma como são aferidos (interna ou externamente ao produto de software) e, em conjunto, compõem a qualidade do produto de software em si.
Destaca-se que a qualidade do processo contribui para a melhoria da qualidade do produto, que, por sua vez, contribui para a melhoria da qualidade em uso:
Através da adequação dos atributos internos do software atende-se a um pré-requisito para o alcance do comportamento externo desejado, que por sua vez, é um pré-requisito para o alcance da qualidade de uso.
Qualidade do software na visão do usuário:
Muitas vezes os desenvolvedores de software se esquecem das necessidades implícitas de seus cliente, questões tais como:
O cliente pode ter desejos e necessidades diferentes em relação ao mesmo tipo de produto?
E qual o interesse dos usuários de software?
O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de perdas.
No caso de software, isto pode significar 
Reaproveitamento de códigos de programa
Menor prazo de entrega,
Menor custo de manutenção 
Maior satisfação do cliente, que vai refletir em maior participação no mercado.
O INMETRO, Instituto Nacional de Metrologia, Normalização e Qualidade Industrial, é o órgão brasileiro responsável pelo credenciamento e supervisão de organismos de certificação, organismos de inspeção e laboratórios de ensaios, nas empresas nacionais.
 
A certificação emitida pelo INMETRO, atende de forma criteriosa aos padrões de qualidade exigidos no desenvolvimento industrial e consequentemente,  atesta que um produto, serviço, sistema ou pessoal cumpre os requisitos de uma norma, especificação ou regulamento técnico.
Considera-se a importância da boa prática de exigir a certificação nos processos de aquisição de software, de acordo com a norma brasileira para a gestão de qualidade e garantia de qualidade no processo de desenvolvimento, fornecimento e manutenção de software.
Atividade 1
Marque a opção correta para a pergunta: ¿Um conjunto de tarefas devidamente realizadas e ordenadas representa¿?
R: Processo
Assinale a assertiva que descreve a relação entre qualidade de produto de software e qualidade de processo de software:
R: A qualidade do produto de software é afetada pela qualidade do processo de software
Em relação à relevância da qualidade de software, analise as assertivas a seguir: 
I - É importante estudar qualidade de software porque os computadores estão cada vez mais presentes na sociedade 
II - É importante estudar qualidade de software porque o aumento na produção de software teve como consequênciao aumento da exigência da qualidade 
III - A qualidade de software só pode ser medida no produto final, sendo impossível medir a qualidade do processo de produção do software 
Estão corretas as assertivas:
R: Apenas I e II
Na visão de Sommerville (2007), os padrões exigidos devem englobar boas práticas para que sejam gerados produtos de alta qualidade. Dessa forma, acredita que há muito mais gerenciamento de qualidade do que padrões e burocracia associada para assegurar que os padrões foram seguidos. A documentação de qualidade deve variar de acordo com o tamanho do software tendo como propósito a comunicação entre a equipe que participa do desenvolvimento do software. Sommerville (Engenharia de Software, 2007) diz ainda que o gerenciamento de qualidade está estruturado em três atividades principais. Quais são estas três atividades?
I. Garantia de qualidade - padrões que conduzem a um software de alta qualidade.
II. Planejamento de qualidade - seleção de procedimentos e padrões apropriados adaptados para um projeto de software específico.
III. 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.
IV. Custo de qualidade - custos envolvidos na procura da qualidade
R: Apenas I, II e III
Assinale a alternativa CORRETA para a lacuna do texto a seguir: ____________________ é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.
R: Qualidade de Software
O aumento de qualidade NÃO é acompanhado por...	
R: aumento do retrabalho
A responsabilidade da Qualidade de software é uma discussão que vem sendo travada há algum tempo. Podemos dizer que a responsabilidade pela garantia da qualidade de software cabe:
R: Todas as pessoas envolvidas no processo de desenvolvimento de software.
Em relação à qualidade, podemos afirmar que:	
R: Em relação à qualidade, podemos afirmar que:	
Aula 2 
Fatores, métricas e garantia da qualidade de software
A medição 
Ajuda a tonar visíveis características especificas de processos e produtos. Sendo assim, os fatores que afetam a qualidade de software podem ser categorizados em grupos de fatores que podem ser medidos diretamente (unidade de tempo) ou apenas indiretamente (usabilidade ou manutenibilidade).
A intenção em cada um dos grupos de fatores é a medição e a comparação de software com algum dado e obter uma indicação de qualidade.
A garantia da qualidade de software (Software Quality Assurance – SQA) trata-se de uma atividade “guarda-chuva”, aplicada ao longo de todo o processo de engenharia de software.
Abrange uma série de tarefas vinculadas especificamente a sete atividades que compõem um plano que realiza:
Avaliações
Auditorias
Revisões
Define padrões para o projeto
Procedimentos para relato
Acompanhamento de erros
Documentação necessária 
Realimentar a equipe com informações conclusivas do projeto.
Existem uma imensa variedade de coisas diferentes que podem ser medidas sob varios aspectos.
Aplicação de métodos e ferramentas técnicas
O estudo dos metodos e ferramentas técnicas de analise, projeto, codificação e teste são atribuidos aos principios fundamentais da analise 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 é especifica da equipe técnica e, em muitas situações, tem descoberto que as revisões são tão efetivas quanto os testes para detecção de problemas de qualidade.
Atividade de teste de software
Conhecida como “rede de segurança” de garantia de software, combina uma serie de métodos de projetos de casos de testes que auxiliam a garantir uma detecção de erros efetiva. As atividades de teste aplicadas de forma cuidadosa revelam a maioria dos erros, aliviando a necessidade de outras atividades de SQA. Porém, considera-se atualmente que não seja a mais efetiva para todas as classes de erros.
Padrões e procedimentos formais
São aplicados no processo de engenharia de software e validados pelos desenvolvedores quanto ao cumprimento dos padrões exigidos pelo software. Em alguns casos, o grupo de SQA pode realizar uma auditoria independente do atendimento aos padrões exigidos.
Atividade de controle de mudanças 
Formaliza pedidos de mudança, avalia a natureza da mesma e controla o respectivo impacto que ela pode causar. O controle de mudança é aplicado durante o desenvolvimento de software e após a manutenção do software.
Medição do software
Coleta um conjunto de medidas técnicas e orientadas para a administração das especificações do software.
Anotação e manutenção de registros (documentação)
É essencial para a garantia da qualidade de software no que diz respeito à coleta e à disseminação de informações de SQA. Os resultados de revisões, auditorias, controle de mudanças, testes e outras atividades de SQA devem torna-se parte de um registro histórico de um projeto documentado. A documentação deve ser acessível a todos que participam da equipe de desenvolvimento de software.
Fatores de qualidade de software
Alguns fatores afetam a qualidade de software, por isso, determinados aspectos devem ser considerados em um software tais como: características operacionais, manutenibilidade de mudanças e adaptabilidade a novos ambientes.  
Revisão:
Manutenibilidade: capacidade de reparação de erros no programa de forma a torná-lo disponível para uso.
 Flexibilidade: esforço para se modificar um programa operacional.
Testabilidade: tempo necessário para se testar um programa a fim de garantir que ele execute a função pretendida.
Operação:
Corretitude: é o atendimento do programa às especificações e objetivos visados pelo cliente.
Confiabilidade: o quanto um programa executa a função pretendida com a precisão exigida.
Eficiência: quantidade de recursos de computação e de código necessária para um programa executar a função desejada.
Integridade: controle de acesso ao software ou a dados de forma controlada.
 Usabilidade: esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa.
Transição
Portabilidade: demanda de esforço para transferir um programa de um ambiente de hardware e/ou software para outro.
Reusabilidade: propriedade de reutilizar um programa ou partes de um programa em outras aplicações (refere-se ao empacotamento e escopo de funções que o programa executa).
Interoperabilidade: esforço exigido para se acoplar um sistema a outro.
Por outro lado, segundo Pressman (2002), existe a dificuldade de se desenvolver medidas diretas dos fatores de qualidade desenvolvidos por McCall (1997) por considerar que muitas das métricas só podem ser medidas subjetivamente. Cavano e MCCall (1978), citados por Pressman (2002), consideram importante a utilização de uma lista de verificação (checklist) para graduar outros atributos específicos do software.
McCall (1977) considera relevante a utilização de uma escala padrão que varia de 0 (baixo) a 10 pontos (elevado), no estabelecimento de métricas de qualidade para cada fator que altera a qualidade de software.
Métrica dos fatores de qualidade
Pressman (2002) comenta que os fatores e atributos da qualidade descritos anteriormente podem ser usados para estabelecer métricas de qualidade para cada etapa do processo de desenvolvimento de software. 
Além dos fatores evidenciados pelos autores citados, outros também interferem na aquisição de qualidade durante o processo de desenvolvimento de software, tais como:
Falta de um modelo corporativo de qualidade.
Ausência de procedimentos de testes automatizados.
Ausência de profissionais capacitados em qualidade.
Deficiência no planejamentoe aplicação dos testes.
Qualidade é aplicada tardiamente no processo.
Em contrapartida, o predomínio da qualidade no processo de desenvolvimento de software traz alguns benefícios, como:
Torna o ciclo de desenvolvimento de software confiável.
Garante ações corretivas no ciclo de desenvolvimento.
Evita a ingerência do projeto de software.
Amplia as chances de sucesso do projeto de software.
Amplia a produtividade do desenvolvimento.
Evita a propagação de erros.
Automação de testes reduz custos do projeto.
Revisões de software:
As revisões são métodos de validação de qualidade de um processo ou produto amplamente usado pela equipe técnica do projeto. São consideradas como verdadeiros “filtros” de erros e inconsistências no processo de desenvolvimento de software.
Qualquer revisão é uma maneira de usar a diversidade de um grupo de pessoas para apontar melhorias necessárias ao produto gerado por uma equipe, confirmar partes ou o todo de um produto que devem ser melhorados (ou não) e realizar um trabalho mais técnico com uma qualidade mais uniforme e previsível, de forma a tornar o trabalho técnico mais administrável.
Alguns bons exemplos de revisões são levados em consideração a efeito de contribuírem na garantia da qualidade de software. Por exemplo, um encontro informal em torno da máquina de café é uma forma de revisão quando tratados problemas técnicos. Uma apresentação técnica do projeto a clientes, à administração e ao pessoal técnico também pode ser considerada uma forma de revisão.
São tipos de revisão específicos do gerenciamento de qualidade, segundo Sommerville (2007, pg 431):
Inspeções de projeto ou de programa - Detectar erros detalhados nos requisitos, projeto ou código.
Revisões de progresso - Fornecer informações para a gerência sobre o progresso geral do projeto (revisão de processo, produto com foco em custos, planejamento e prazos).
Revisões de qualidade - Conduzir análise técnica de componentes de produto ou documentação para encontrar inconsistências entre especificação e projeto, código ou documentação; assegurar que padrões de qualidade definidos foram seguidos.
Custos da qualidade
Um outro aspecto importante é referente aos custos da qualidade. Vários são os estudos conduzidos por especialistas da área de qualidade intencionados em obter um referencial para os custos reais da qualidade, a fim de poderem identificar maneiras de reduzir custos da qualidade e fornecer uma base de comparação entre os demais custos envolvidos no processo de desenvolvimento de software.
Custo de prevenção (prevenção de defeitos – 5 a 15%) atividades decorrentes:
- Planejamento da qualidade
- Revisões técnicas formais
- Equipamentos de teste
- Treinamento
São controláveis e caracterizam investimento.
Custo de avaliação (remover do processo de produtos com defeitos – 20 a 15%) atividades decorrentes:
- Inspeção intra e interprocessos
- Calibração e manutenção do equipamento
- Teste
São incontroláveis e caracterizam perdas e prejuízo.
Custo de falha interna (defeito antes da entrega ao cliente – 65 a 70%) atividades decorrentes:
- Trabalho para refazer
- Esforço para reparar
- Análise do modo como a falha ocorreu
São incontroláveis e caracterizam perdas e prejuízo.
Custos de falha externa (defeito após a entrega ao cliente – 65 a 70%) atividades decorrentes:
- Solução de queixas
- devolução E substituição do produto
- Manutenção da linha de suporte
São incontroláveis e caracterizam perdas e prejuízo.
Interessante ressaltar que na medida em que migramos dos custos de prevenção para os de detecção de falhas internas até os de falhas externas aumentamos significativamente os custos de identificação e reparo de um defeito.
Uma análise numérica justifica o impacto de custo de detecção de erros feita precocemente. Considere que, na descoberta de um erro durante a fase de projeto, o custo seja de uma (1,0) unidade monetária para ser corrigido. Em relação a esse custo, o mesmo erro, descoberto logo antes que as atividades de teste se iniciem, custará 6,5 unidades; durante os testes, 15 unidades; e, após o lançamento, entre 60 e 100 unidades (PRESSMAN, 2002).
Revisões técnicas formais:
As revisões técnicas formais são consideradas como a principal atividade de um SQA. 
Conhecida como walkthroughs, inspeções, reuniões round - robin e outras avaliações técnicas de software, as revisões técnicas formais têm como objetivos:
1. descobrir erros de função, lógica ou implementação do software; 
2. verificar se o software em revisão atende aos requisitos; 
3. garantir que o software está representado de acordo com padrões predefinidos; 
4. obter um software desenvolvido de forma uniforme; e 
5. tornar os projetos mais administráveis (SOMMERVILLE, 2007).
Assim como a revisão de software, a revisão técnica formal (Formal Technical Review - FTR) deve contar com algumas etapas, segundo Pressman (2002): 
Reunião da revisão: entre três a cinco pessoas com preparação antecipada de 2 horas de trabalho de cada pessoa para uma duração de não mais que 2 horas.
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.
Interessante enfatizar que a comunicação deve ser contínua durante o processo de revisão e por isso, requer um procedimento de resposta aos itens da lista de questões levantadas para efeito de confirmar a devida correção das questões levantadas.
Diretrizes de revisão: estabelecida antecipadamente e distribuída a todos os revisores para a concordância de todos e assim ser encaminhada mantendo a organização no processo de revisão técnica formal.
Requer um conjunto de diretrizes necessárias para a perfeita realização do processo:
Revisar o produto, não o produtor.
Fixe e mantenha uma agenda.
Limite ao debate e a refutação.
Foco nas áreas problemáticas.
Registre as anotações por escrito.
Reduzir número de participantes.
Definir uma lista de conferência (checklist) para cada produto revisado.
Atribuir recursos e uma programação de tempo para as FTRs.
Realizar treinamento para os revisores.
Rever antigas revisões.
Lista de conferência de revisão – cada etapa do processo de engenharia de software pode realizar uma FTR a partir de um produto derivado de outras FTRs anteriores.
Dessa forma, importante considerar a lista de conferência como parâmetro ou ponto de partida para cada revisão. Algumas questões pertinentes a cada etapa do processo de desenvolvimento abrangem determinados questionamentos. As listas de conferência não pretendem ser abrangentes o suficiente, mas apenas oferecem um ponto de partida para cada revisão.
Aula 2: Fatores, métricas e garantias de qualidade de software
Nesta aula, você aprendeu:
A importância da aplicação de métricas orientadas à função, ou seja, que oferecem medidas indiretas à funcionalidade do software e não a leitura de linhas de código. Tais métricas destacam a valorização das funções executadas pelos programas.
A importância da aplicação de métricas orientadas às pessoas, as quais dão indicações sobre a forma como as pessoas desenvolvem os programas de computador. Quando não há a definição de métricas, ou quando os objetivos para o desenvolvimento de software não são claros, as pessoas tendem a criar produtos dentro das suas próprias visões, levando a projetos inadequados para a função de negócio a ser atendida.
Sobre a organização das métricas da qualidade, que permitem indicar o nível de resposta do software às exigências explícitas e implícitas do cliente. As pessoas são sensíveis aos estímulos externos e por meio de tais estímulos são influenciadas suas atitudes e pensamentos.
A garantia de qualidadede software consiste nas funções gerenciais de auditar e relatar. O objetivo é fornecer à gerência os dados necessários para que fique informada sobre a qualidade do produto, a fim de obter compreensão e confiança de que a qualidade do produto está satisfazendo as metas.
Revisões, embora tenham eficácia duvidosa, são simples e, se bem realizada, têm mostrado bons resultados.
As revisões visam promover a simplicidade da prática de técnicas para descoberta de erros e inconsistências. Promovem eficácia apesar de informais e tendem a encontrar o número significativo de defeitos. Se feitas por pessoas treinadas em aspectos formais podem ser muito mais eficazes.
O custo da revisão é amplamente compensado pela redução do retrabalho inútil e além do mais, é baixo a partir da remoção de problemas potenciais, defeitos e inconsistências. Porém, a qualidade das revisões depende excessivamente da habilidade de revisores quanto à proficiência, confiabilidade quanto ao rigor adotado pelo revisor em suas opiniões e diretrizes.
A importância de treinar e capacitar efetivamente os revisores nas práticas das revisões técnicas formais para amenizar os problemas decorrentes da informalidade.
É fato a dificuldade de se determinar com precisão a eficácia da revisão quanto à existência de defeitos desconhecidos e a gravidade e impacto destes nos produtos de software.
Atividade 2
Os erros detalhados nos requisitos, projeto ou código são detectados por?	
R:Inspeções de projeto ou de programa.
Das afirmativas sobre métricas dinâmicas e estáticas, respectivamente, qual está correta?
R: São coletadas por meio de medições realizadas em um programa em execução e são coletadas por meio de medições realizadas em representações do sistema como projeto, programa ou documentação.
3) As afirmativas correspondem respectivamente à descrição de dois tipos de características de processo.
a. O processo definido é aceitável e usável pelos engenheiros responsáveis pelos produtos de software.
b. O processo pode continuar apesar do surgimento de problemas inesperados.
Quais são estas características?
R: Aceitabilidade e robustez.
4) Complete os espaços na afirmativa abaixo e assinale a alternativa que apresenta as respostas corretas. 
Com relação à qualidade do processo de software, podemos dizer que o processo deve estar ___, ser ____ e ____.
R: Documentado, Compreendido e Seguido.
5) As revisões de software são métodos de validação de qualidade de um processo ou produto amplamente utilizadas pela equipe técnica do projeto para detectar erros e inconsistências. Sobre as revisões de software, indique a afirmativa INCORRETA.
R: As revisões de software não garantem que o software seja desenvolvido de acordo com os requisitos definidos
6) Uma atividade própria da equipe técnica tem como propósito descobrir problemas de qualidade, muitas vezes tem provado que revisões são tão efetivas quanto testes para detectar problemas de qualidade. Você diria que estamos falando de:
R: Atividade central de revisão técnica formal.
7) De acordo com conceito de qualidade, os padrões especificados (standards):
R: Definem um conjunto de critérios de desenvolvimento.
Tendo em vista o primeiro grupo com algumas métricas de qualidade, numere o segundo grupo, formado por conceitos, de acordo com o primeiro.
 
R: 3, 2, 4, 1
AULA 3
Garantia estatística da qualidade e a abordagem da NBR ISO900
Nas aulas anteriores, enfatizou-se que a qualidade de software é responsabilidade de todos os participantes envolvidos no desenvolvimento de software.
Qualidade de software
Pode ser conseguida através de análise, projeto, codificação e teste de componente, mas, com toda certeza, uma efetiva aplicação de revisões técnicas formais para controle de produtos de trabalho de software e de modificações feitas neles são consideradas técnicas eficientes de obtenção de qualidade de software.
Garantia estatística de qualidade de software
Reflete uma tendência entre os profissionais da área de computação e apóia-se na questão quantitativa a respeito da frequência de ocorrência de erros e inconsistências nos softwares rastreados ao longo de um período específico de tempo.
Com o decorrer da industrialização acelerada, algumas questões relativas à padronização começaram a ser questionadas no sentido de estimular procedimentos quanto à gerência de processos e a obtenção de qualidade nos produtos fabricados.
Ao iniciar o século XX, Frederick Taylor, se destacou nos estudos quanto a racionalização das etapas de produção visando a maior produtividade de seus funcionários. Logo após, seguiram os estudos de Henry Ford que apoiado pela idéia de racionalização no processo industrial implantou a linha de montagem com a implementação de processos padronizados.
Desde então, criaram-se vários órgãos normativos que perseveraram no propósito da padronização e assim em 1906, surge a International Electrotechnical Commission (IEC) com ênfase na eletrotécnica.
Em 1926, surge a International Federation of the National Standardizing  Associations (ISA), com ênfase na engenharia mecânica.  
Mais tarde, com o fim da II Guerra Mundial, em Londres, estabelece a nova organização, a Organização Internacional para Padronização, iniciando oficialmente as suas operações em 23 de fevereiro de 1947 com sede em Genebra, na Suíça.
Com a acentuação da globalização na década de 1980, aumenta a necessidade de normas internacionais, nomeadamente a partir da criação da União Européia que suplantou a norma padrão internacional, a ISO 9000 (International Organization for Standardization), através da criação de uma organização não-governamental, cuja função é a de promover a normatização de produtos e serviços, para que a qualidade dos mesmos seja permanentemente melhorada.
ISSO 9000 :
Grupo de normas técnicas que estabelecem um modelo de gestão da qualidade para organizações em geral, qualquer que seja o seu tipo ou dimensão.
Passos para 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:
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.
Confiabilidade de software é:
Em termos gerais, “a probabilidade de operação livre de falhas de um programa de computador num ambiente específico durante determinado tempo especificado”.
Também considerar que um número mínimo de falhas ocorrerá na execução de um software dada garantia de que atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo.
MAIS SOBRE A CONFIABILIDADE DE SOFTWARE
Confiabilidade de Software A confiabilidade consiste em considerar que um número mínimo de falhas ocorrerá na execução de um software dada a garantia de que atenderá ao estabelecimento de parâmetros de conformidade para o sucesso do processo.
 O percentual de confiabilidade definido para cada processo na engenharia de software é muito relativo, pois dependerá da complexidade e importância do processo para o sucesso do sistema. 
Por exemplo, o sistema que monitora todo o processo de aquecimento da caldeira de uma siderúrgica precisa de um percentual de confiabilidade muito próximo a 100 %. Trata-se de um processo ininterrupto, ativo por 24 horas, pois, caso ocorra o desligamento da caldeira, o custo de reaquecimento será extremamente alto.Portanto, alguns processos automatizados precisam necessariamente de percentuais de confiabilidade altos e outros nem sempre. 
Alguns fatores são responsáveis pela presença de falhas nos softwares decorrentes de falhas de hardware devido a desgaste físico e não a defeitos. Exemplos comprovados desse fato estão presentes nos efeitos de temperatura, de corrosão e de choque térmico. Todavia, nos softwares, essas falhas não são justificadas plenamente, apesar de alguns estudiosos da área de qualidade considerarem a existência de uma relativa ligação irrefutável – confiabilidade de hardware e sua aplicabilidade ao software.
 Nesse contexto, ainda há de se considerar a questão da disponibilidade de software como a probabilidade de que um programa esteja operando de acordo com os requisitos em determinado ponto do tempo. Quando se tem uma medida de disponibilidade alta para um software, a razão torna-se inversamente proporcional à capacidade de manutenção do software.
Segurança de software é:
Uma atividade de garantia da qualidade de software que detecta e avalia riscos em potencial, que podem provocar falhas e impactar o desempenho de todo o sistema.
É também considerada uma atividade de garantia de qualidade de software, que se concentra na identificação e avaliação de causalidades em potencial que possam exercer impacto negativo sobre o software e provocar falhas no sistema.
Para a implementação da segurança, considera-se a necessidade de identificar a presença de riscos o mais cedo possível, de forma a possibilitar que estratégias sejam traçadas no projeto de software que eliminem ou controlem esses riscos em potencial.
Atualmente, o hardware e o software de computador são usados regularmente para controlar sistemas de segurança críticos.
O passo seguinte seria analisar, por meio de técnicas, a gravidade e a probabilidade de ocorrência. Algumas técnicas são aplicáveis tais como a análise da árvore de falhas e a lógica de tempo real.
Princípios da ISO 9000
Até aqui, conhecemos um pouco mais sobre a garantia estatística da qualidade. A partir de agora, trataremos da abordagem da norma ISO 9000.
A ISO 9000 descreve os elementos de garantia em termos genéricos, que podem ser aplicados a qualquer negócio independentemente dos produtos ou serviços oferecidos.
Dessa forma, um sistema de garantia da qualidade que promove a estrutura organizacional, define responsabilidades, cria procedimentos e processos, capacita recursos para implementar a gestão da qualidade em todo ciclo de vida de um produto, certamente, demanda de uma intervenção normativa para que materiais, produtos, processos e serviços satisfaçam as expectativas do cliente, de acordo com suas especificações.
A adoção das normas ISO é vantajosa para as organizações, uma vez que lhes confere:
Gestão - > Prover confiança a própria administração de que seus produtos atenderão à satisfação dos clientes.
Garantia -> Prover confiança aos clientes de que os produtos atenderão à sua satisfação.
O ganho para as organizações com a adoção das normas ISO está na produtividade e credibilidade aumentando a sua competitividade nos mercados nacional e internacional.
Os modelos da norma ISSO 9000: 
ISO 9001: Garantia da qualidade em projetos/desenvolvimento, produção, instalação e assistência técnica.
ISO 9002: Garantia da qualidade em produção e montagem, instalação, prestação de serviço.
ISO 9003: Garantia da qualidade em inspeção e testes finais.
ISO 9004: Gestão da qualidade e elementos do sistema de qualidade – diretrizes.
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.
Visão de processo, satisfação do cliente e melhoria contínua
Segundo Pressman (2002), os modelos de garantia da qualidade ISO 9000 tratam uma empresa como uma rede de processos interconectados. Todos os processos organizacionais devem se referir às áreas identificadas na norma e devem ser documentados e praticados como descrito na imagem. Dessa forma, afirma-se que a organização dispõe de um sistema de qualidade que esteja em conformidade com a ISO.
Nesta aula, você aprendeu:
Para conduzir adequadamente a garantia da qualidade de software, dados sobre o processo de desenvolvimento de software devem ser coletados, avaliados e disseminados.
SQA estatística ajuda a aperfeiçoar a qualidade do produto e o próprio processo de software.
Modelos de confiabilidade de software ampliam as medições, permitindo que dados de defeitos coletados sejam extrapolados para taxas projetadas de falha e previsões de confiabilidade.
A certificação ISO 9000 surge como uma alternativa à melhoria do processo produtivo, gerando produtos e serviços de alta qualidade para o cliente.
Atualmente, a certificação ISO 9000 é considerada como estratégia competitiva nas organizações empresariais para alcançar a diferenciação e galgar novas oportunidades em um mercado global cada vez mais competitivo.
Atividade 3
Segurança de software é:
Detectar e avaliar riscos em potencial, que possam causar falhas no software.
 A garantia estatística de qualidade de software apoia-se na frequência de ocorrência de erros e inconsistências nos softwares rastreados ao longo de um período específico de tempo. Escolha a alternativa que classifica o tipo de análise para a ocorrência de erros.
Quantitativa
3- De uma maneira, geral podemos dizer que a ISO 9000 descreve os elementos de garantia em termos genéricos
que podem ser aplicados a qualquer negócio.
4- 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. Marque a opção que possui todos os elementos deste processo:
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.
5- Das opções abaixo, qual não representa uma norma certificadora do setor de software?
	
 IEC
	
	ISO 9001
	 
	ISO 14000
	
	ISO 9000
	
	ISO 9126
6- Sobre a certificação ISO 9000, analise as considerações abaixo e marque a opção correta.
	Garante que todos os produtos gerados a partir dos processos certificados terão as mesmas caracteristicas e consistências.
7- A garantia da qualidade de software (Software Quality Assurance - SQA) é uma atividade "guarda-chuva", aplicada ao longo de todo o processo de engenharia de software. Abrange uma série de tarefas vinculadas especificamente às atividades que compõem um plano de garantia da qualidade. O que este plano deve considerar?
I.        avaliações, auditorias, revisões, define padrões para o projeto.
II.      procedimentos para relato e acompanhamento de erros e documentação necessária.
III.    A alocação de recursos necessários para o desenvolvimento do software.
IV.   realimentação à equipe com informações conclusivas do projeto.
Apenas I, II e IV
8 - Segundo Pressman (2004), alguns passos são necessários para realizar a GARANTIA ESTATÍSTICA DA QUALIDADE (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. Alguns defeitos são descobertos e rastreados, tendo quais causas prováveis?
 
 I. Especificações incompletas ou mal formuladas
 II. Distorção na interpretação da comunicação com o cliente
 III. Desvio voluntário das especificações
 IV. Respeito aos padrões de programação 
Apenas I, II e III
Aula 4 –
NBR ISSO/IEC 9126 (PRODUTO DE SOFTWARE) E NBR ISSO/ IEC 12119 (pacote desoftware)
Normas de qualidade de produto de software
A NBR ISO/IEC 9126-1, publicada em 1991, apresenta uma definição de qualidade como sendo a "totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas" (2003, p.17).
Necessidades explicitas (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.
Necessidades implícitas (ou direta):
São necessidades que embora não estejam especificadas nos requisitos, devem ser levadas em consideração, pois se baseiam em princípios básicos e óbvios, necessários para que o usuário execute a sua tarefa.
Essas duas necessidades são muito importantes, pois são elas que fornecem subsídios para a criação das validações e verificações que ocorrem durante todo o ciclo de vida do sistema. Dentre elas, pode-se citar o teste de software como uma grande ferramenta para garantir a qualidade do software.
No entendimento da NBR ISO/IEC 9126 as necessidades explícitas e implícitas são entendidas como características e subcaracterísticas básicas de um produto de software que vise à presença da qualidade. As definições de características e subcaracterísticas de qualidade nos permitem perceber um possível universo de requisitos que se enquadram no conceito de qualidade.
A Norma ISO/IEC 12119 é aplicável a pacotes de software, como por exemplo:
Pacotes de software voltados para funções administrativas
Técnicas ou científicas,
Comunicação de escritórios e outras finalidades, tal como são produzidos.
 Outros exemplos, incorporados aos pacotes de software compreendem os processadores de texto, planilhas eletrônicas, bancos de dados, softwares gráficos, programas para funções técnicas ou científicas e programas utilitários. Aplicável à avaliação de pacotes de software na forma em que são oferecidos e liberados para uso no mercado e não aos processos de desenvolvimento e fornecimentos de software.
Por pacotes de software entende-se como o conjunto completo e documentado de programas fornecidos a diversos usuários para uma aplicação ou função genérica. É conhecido também como software de prateleira.
A norma estabelece um conjunto de requisitos de qualidade para pacotes de software, instruções em como executar testes em um pacote de software, em destaque para testes realizados por terceiros.  
Os requisitos de qualidade incluem que: 
i) cada pacote de software deve ter uma descrição do produto e documentação do usuário;
 ii) a descrição de produtos deve conter informações que sejam testáveis e corretas e,
 iii) requisitos para a documentação do usuário, programas e dados que façam parte do pacote.
A descrição do produto inclui as principais propriedades do pacote.
A documentação do usuário nada mais é que um documento que será avaliado em relação à sua completitude, correção, consistência, inteligibilidade, apresentação e organização.
Programas e dados, na verdade, são os requisitos de programas e dados que devem estar descritos, caso existam, para funcionamento do produto. 
Um pacote de software está em conformidade com esta Norma se atende a todos os requisitos de qualidade nela definidos.
A garantia e controle de qualidade no desenvolvimento de software ao operarem simultaneamente, visam garantir que os artefatos de software sejam desenvolvidos e entregues com melhor aceitabilidade, menos defeitos e menores custos.
Garantia de software -> Promove a gerência sênior da organização uma melhor visibilidade apropriada sobre o processo de desenvolvimento.
Controle de qualidade -> Objetiva testar os produtos de software de modo a encontrar, relatar e remover seus defeitos.
Em contrapartida, na visão do usuário do software, são percebidas as necessidades de qualidade em uso do produto de software no contexto especificado para uso. Essas necessidades identificadas, por sua vez, podem ser usadas quando se especifica qualidade externa e interna usando características e subcaracterísticas de qualidade do produto de software.
A qualidade do produto do software pode ser avaliada pela medição:
Dos atributos internos (tipicamente medidas estáticas de produtos intermediários);
Dos atributos externos (tipicamente medidas do comportamento do código quando executado);
Dos atributos de qualidade em uso.
O objetivo é que o produto tenha o efeito desejado em um contexto particular de uso.
Modelo de qualidade de software
A qualidade de produto de software deveria ser avaliada utilizando um modelo de qualidade previamente definido. O modelo de qualidade deve ser usado quando se estabelecem metas de qualidade para produtos de software e produtos intermediários. A qualidade do produto de software deve ser hierarquicamente decomposta para um modelo de qualidade com características e subcaracteristicas 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.
Dessa forma, a norma NBR ISSO/IEC 9126 – 1 descreve um modelo de qualidade do produto de software, composto de duas partes:
Qualidade de uso
Qualidade interna externa
A norma NBR ISO/IEC 9126 apresenta, de certa maneira, os instrumentos necessários para realizar uma avaliação, descrevendo de forma ampla como medir qualitativamente e quantitativamente a “presença” de qualidade, formando assim um modelo de qualidade para produto. De acordo com a Associação Brasileira de Normas Técnicas – ABNT, a série da NBR ISO/IEC 9126 se subdivide da seguinte forma:
ISSO/IEC 9126-2			ISSO/IEC 9126-3			ISSO/IEC 9126-4
								 Métricas externas			Métricas internas			Métricas da Qualidade em uso
Para Pressman (2002), o uso de um modelo de qualidade apoia a categorização de fatores de McCall (1997), o contexto, a partir da qualidade interna e externa, passa a ser categorizado por seis características:
Funcionalidade
Confiabilidade
Usabilidade
Eficiência
Manutenibilidade
Portabilidade
São subdivididas em subcaraterísticas, confirme apresentado na figura acima que segue a especificação da NBR ISO/IEC 9126-1. Cada subcaracterística pode ser medida por meio de métricas internas e externas.
Para cada característica e subcaracterística, a capacidade do software é determinada por um conjunto de atributos internos que podem ser medidos. As características e subcaracterísticas atuam como fatores que alteram a qualidade de software interna e externa. Como veremos a seguir.
SAIBA MAIS:
Características e Subcaracterísticas da Qualidade de Software
A seguir, a especificação das características e subcaracterísticas medidas externamente pelo grau da capacidade do sistema contendo o software:
.Funcionalidade: capacidade de fornecer funções que correspondam às necessidades explícitas e implícitas do usuário quando o software é utilizado sob condições especificadas.
Adequação: capacidade de fornecer um conjunto apropriado de funções para tarefas específicas e objetivos do usuário.
Acurácia: capacidade de fornecer o resultado com o grau de precisão desejado.
Interoperabilidade: capacidade de interagir com um ou mais sistemas.
Segurança de Acesso: capacidade de proteger dados e informações de pessoas ou sistemas não autorizados.
Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à funcionalidade. 
Confiabilidade: capacidade do software de manter seu nível de desempenho quando utilizado em condições estabelecidas.
Maturidade: capacidade de evitar defeitos no software.
Tolerância a Falhas: capacidade de manter um nível de desempenho estabelecidoem caso dedefeito no software.
– Recuperabilidade: capacidade de recuperar dados diretamente afetados no caso de falhas.
– Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares
relativas à confiabilidade.
. Usabilidade: capacidade que o produto tem de ser entendido, aprendido,
utilizado e ser atraente para o usuário.
– Inteligibilidade: capacidade do produto de fazer o usuário entender se o software é
 adequado e como ele pode ser usado para tarefas particulares.
– Aprendibilidade: capacidade que o produto deve ter de fazer o usuário entendê-lo.
– Operacionalidade: capacidade que o produto deve ter para que o usuário possa
aprendê-lo e controlá-lo.
– Atratividade: capacidade do produto em ser atraente para o usuário.
– Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares
relativas à usabilidade.
. Eficiência: relacionamento entre o nível de desempenho do software e a
quantidade de
recursos utilizados, sob condições estabelecidas.
– Comportamento em Relação ao Tempo: capacidade de fornecer tempos de resposta
 e processamento adequados, bem como taxas de transferência.
– Comportamento em Relação aos Recursos: capacidade de usar quantidade e tipos de
 recursos adequados.
– Conformidade: capacidade de aderir a padrões e convenções relativas à eficiência.
. Manutenibilidade: esforço necessário para se fazer modificações específicas no
software.
– Analisabilidade: capacidade em diagnosticar deficiências e causas de defeitos.
– Modificabilidade: capacidade que o produto tem de receber modificações.
2/3
– Estabilidade: capacidade de evitar efeitos inesperados a partir de modificações.
– Testabilidade: capacidade de validar as modificações efetuadas no produto.
– Conformidade: capacidade de aderir a padrões e convenções relativas a
 manutenibilidade.
. Portabilidade: capacidade que o produto tem de ser transferido de um
ambiente para outro.
– Adaptabilidade: capacidade de ser adaptado em diferentes ambientes sem
 intervenção.
– Capacidade de Instalação: capacidade de ser instalado em um ambiente específico.
– Coexistência: capacidade que o produto tem de coexistir com outro software
 independente em um ambiente comum, compartilhando recursos
comuns.
– Capacidade de Substituição: capacidade que o produto de software deve ter de ser
 usado no lugar de outro produto de software com o mesmo propósito
no mesmo
 ambiente.
– Conformidade: capacidade de aderir a padrões e convenções relativas à portabilidade
Até aqui, conhecemos um pouco mais sobre a garantia estatística da qualidade. A partir de agora, trataremos da abordagem da norma ISO 9000.
A ISO 9000 descreve os elementos de garantia em termos genéricos, que podem ser aplicados a qualquer negócio independentemente dos produtos ou serviços oferecidos.
Dessa forma, um sistema de garantia da qualidade que promove a estrutura organizacional, define responsabilidades, cria procedimentos e processos, capacita recursos para implementar a gestão da qualidade em todo ciclo de vida de um produto, certamente, demanda de uma intervenção normativa para que materiais, produtos,processos e serviços satisfaçam as expectativas do cliente, de acordo com suas especificações.
Qualidade de processo -> contribui para a melhoria da qualidade do produto -> contribui para a melhoria da qualidade de uso.
Pense nisso...
Os atributos internos adequados do software tornam-se um pré-requisito para alcançar o comportamento externo desejado, que por sua vez, é um pré-requisito para alcançar a qualidade.
Os requisitos de qualidade do produto de software geralmente incluem critérios de avaliação para qualidade interna, qualidade externa e qualidade em uso, para corresponder às necessidades dos desenvolvedores e usuários finais.
Um processo pode ser avaliado indiretamente pela medição e avaliação do produto, e o produto pode ser avaliado indiretamente pela medição do desempenho da tarefa de um usuário (utilizando métricas de qualidade em uso).
Interessante observar que um software nunca é executado sozinho, mas sempre como parte de um sistema maior, que tipicamente, consiste de outros produtos de software que tem sua interface, hardware, operadores e fluxo de trabalho. O produto de software completo pode ser avaliado pelos níveis de métricas externas escolhidas.
Nos primeiros estágios de desenvolvimento somente recursos e processos podem ser medidos.
Quando produtos intermediários se tornam disponíveis (especificações, código fonte, etc), eles podem ser avaliados pelas métricas internas escolhidas. Essas métricas podem ser usadas para prever valores de métricas externas.
Considera-se que a qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de qualidade em uso, por métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por métricas deveriam ser usados como critério quando um produto é validado.
É importante considerar que a qualidade em uso consiste na qualidade percebida pelo usuário e na aferição da qualidade do software em cada contexto específico de usuário.
Essas métricas visam descrever a interação com o ambiente e são avaliadas pela observação do software em operação. Qualidade em uso pode ser medida pelo quanto um produto em uso atinge as necessidades do usuário em termos de efetividade, produtividade, segurança esatisfação.
A qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de qualidade em uso, por métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por métricas deveriam ser usados como critério quando um produto é validado.
A execução de um produto que satisfaça as necessidades do usuário normalmente requer uma abordagem interativa no desenvolvimento do software, com contínuo feedback da perspectiva do usuário. Para tanto, algumas características de qualidade são pertinentes à aquisição de qualidade de produto de software, na visão do usuário.
Qualidade em Uso é a visão de qualidade que o usuário tem do software e é medida em  termos do resultado da utilização do software. É a capacidade que o produto de software tem de atender aos anseios e às necessidades dos usuários em seu próprio ambiente de trabalho. É, portanto, a capacidade de software permitir a usuários específicos atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado.
Qualidade em uso
A Norma ISO/IEC 9126-4  define as métricas  de qualidade para as seguintes características:
Eficácia -> Usuários são capazes de atingir metas especificadas com acurácia e completitude.
Produtividade -> Usuários empregam quantidade adequada de recursos em relação à eficácia obtida.
Segurança -> Presença de níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente.
Satisfação -> Satisfazer usuários de acordo com as especificações do produto de software.
Métricas de qualidade de acordo com a Norma ISO/IEC 9126-1
A precisão da qualidade depende, em grande parte, das métricas escolhidas. Para aumentar a confiabilidade dos resultados são necessárias algumas características que as métricas  deveriam apresentar, de acordo com o requisitos especificados na NBR ISO/IEC  9126-1(item 6.4).
Significância -> As métricas relevantes devem agregar informações sobre o comportamento do software, porém as não relevantes devem ser descartadas.
Custo e complexidade-> Aplicação da métrica deve ser econômica e tecnicamente viável. Destaca-se que algumas métricas não satisfazem esse critério por demandarem um investimento acima do orçamento(laboratórios e usuários-teste) ou demandar técnicas sofisticadas como métodos estatísticos.
Repetibilidade -> Os resultados gerados devem ser idênticos ao aplicar a medição:
i) no mesmo produto; 
ii) com a mesma especificação de requisitos; 
iii) com os mesmos avaliadores, usuários-testes e ambiente.Reprodutibilidade -> Os resultados gerados devem ser idênticos ao aplicar a medição:
i) no mesmo produto;
ii) com a mesma especificação de requisitos;
iii) com diferentes avaliadores, usuários-testes e ambiente.
Validade-> Necessidade de demonstrar correção e precisão em todos os fatores que podem influir no resultado como:
> característica de hardware como por exemplo, uma má conexão de cabos de rede;
> característica de configuração de parâmetros do sistema operacional e do próprio software em desacordo ;
> percepção dos avaliadores no processo de julgamento de definições de botões, janelas, menus em discordância; 
> utilização de modelos matemáticos passíveis de manipulação devem ser explicitados.
Objetividade -> Ausência de subjetividade dos resultados da medição, isto é, não devem sofrer influência de opinião de avaliadores, usuários-teste, etc. A medição estatística deve ser aplicada caso não seja possível manter a objetividade.
Imparcialidade-> A medição não deve ser tendenciosa, ou seja, preservar a publicação dos resultados na íntegra e, distribuir o resultado em um ambiente que seja o mais confiável possível.
considera-se que a aplicação das métricas de avaliação do software depende em grande parte do grau de sofisticação do processo de avaliação.
Estrutura da ISO/IEC  12119
Até aqui, tratamos de modelos de qualidade de produto de software focados na norma NBR ISO/IEC 9126. Agora , focaremos na norma NBR ISO/IEC 12119. IMPORTANTE: será iniciada uma outra norma 12119.
Requisitos de Qualidade
Descrição do produto -> Consiste em um documento expondo as propriedades de um pacote de software, com o principal objetivo de auxiliar os potenciais compradores na avaliação da adequação do produto antes de sua aquisição. 
Fornece informações sobre a documentação do usuário, programas e, se existirem, sobre os dados.Inclui as principais propriedades do pacote e é um documento disponível ao usuário independente da aquisição do produto. As declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade devem ser avaliadas.
Documentação do usuário -> Trata-se de um conjunto completo de documentos disponível na forma impressa ou não, que é fornecido para a utilização de um produto, sendo também uma parte integrante do produto. 
Deve incluir todos os dados necessários para a instalação, para o uso da aplicação e para a manutenção do software produto. Deve fazer referência a completude, correção, consistência, intelegibilidade, apresentação e organização.
Programas e dados -> Os requisitos de qualidade para Programas e Dados utilizam as mesmas definições das características da norma ISO/IEC 9126. 
Descreve em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
Instruções para teste
Os usuários da Norma ISO/IEC 12119 são em grande parte os fornecedores de software, órgãos de certificação, laboratórios de teste, auditores, compradores e usuários de software.
Vamos ver todos esses conceitos na prática?
Visite uma empresa de desenvolvimento de software e solicite uma participação na equipe de testes para o acompanhamento e levantamento de dados a respeito do tipo e dos tempos entre a ocorrência de falhas, a fim de mostrar se a confiabilidade está aumentando.  
 
Elabore uma tabela de tipos e incidência de falhas, de acordo com a tabela apresentada para identificação dos passos para a SQA estatística (aula anterior). Elabore uma análise crítica da qualidade de software utilizando as características e subcaracterísticas pertinentes a NBR ISO/IEC 9126, tais como:
Maturidade: capacidade de evitar defeitos no software.
Tolerância a Falhas: capacidade de manter um nível de desempenho estabelecido em caso de defeito no software
Recuperabilidade: capacidade de recuperar dados diretamente afetados no caso de falhas.
Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à confiabilidade.
Atividade 4
Segundo McCall (1977), muitas das métricas só podem ser medidas subjetivamente. Por isso, considera importante, mais uma vez, a utilização de uma técnica para graduar atributos específicos do software. Qual seria essa métrica?
Lista de Verificação (checklist).
"A Ausência do desconforto e presença de atitudes positivas para com o uso de um produto". Este contexto está falando sobre?
Satisfação
No âmbito da norma NBR ISO/IEC 9126-1, um modelo de qualidade cujo componente seja o produto de software deve estabelecer metas de qualidade para produtos finais e intermediários. O uso de um modelo de qualidade passa a ser categorizado por seis características.
Funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, portabilidade.
De acordo com a norma ISO/IEC 9126 a categoria Manutenibilidade significa:	
Capacidade do software ser modificado (correções, melhorias ou adaptações).
Para Pressman (2002), o uso de um modelo de qualidade apoia a categorização de fatores de McCall (1997). Para o autor, o contexto a partir da qualidade interna e externa passa a ser categorizado por algumas características. Uma delas é a Funcionalidade, que significa:
Capacidade de fornecer funções que correspondam às necessidades explícitas e implícitas do usuário quando o software é utilizado sob condições especificadas.
Com o intuito de gerar produtos de software com níveis de qualidade, é fundamental que se crie medição de processos. Estas medições representam:
Dados quantitativos sobre o processo de software.
Quanto à avaliação de software, analisabilidade, modificabilidade e estabilidade são quesitos de:	
Manutenibilidade
Diferentemente de um processo de software caótico, o processo controlado e gerenciado com eficiência apresenta robustez, velocidade, aceitabilidade, confiabilidade e manutenibilidade. Assinale a assertiva que melhor descreve o atributo robustez.
O processo continua a despeito de eventos inesperados
Aula 5
ISSO/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.
Complementando, a ISO 9241, partes 12 a 17, fornece recomendações condicionais que são aplicadas em contextos de uso específico. As partes orientam para identificar a aplicabilidade de recomendações individuais.
A ISO 9241-11 não cobre os processos de desenvolvimento de sistema. Os processos de projeto centrados no ser humano para sistemas interativos são descritos na ISO 13407.
A seguir, definem-se alguns efeitos da norma:
Usabilidade
Medida na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com eficácia, eficiência e satisfação em um contexto específico de uso.
Eficácia
Completude com as quais usuários alcançam objetivos específicos.
Eficiência
Recursos gastos em relação à acurácia e abrangência com as quais usuários atingem objetivos.
Satisfação
Ausência do desconforto e presença de atitudes positivas para com o uso de um produto.
Contexto de uso
Usuários, tarefas, equipamento (hardware, software e materiais), e o ambiente físico e social no qual um produto é usado. Sistema, composto de usuários, equipamento, tarefas e o ambiente físico e social, com o propósito de alcançar objetivos específicos.
Usuário
Pessoa que interage como produto.
Objetivo
Resultado pretendido.
Tarefa
Conjunto de ações necessárias para alcançar um objetivo.
Produto
Parte do equipamento (hardware, software e materiais) para o qual a usabilidade é especificada ou avaliada.
Medida (substantivo)
Valor resultante da medição e o processo usado para obter tal valor.
A justificativa da usabilidade de produtos se faz pela incorporação de características e atributos conhecidos como capazes de beneficiar os usuários em um contexto particular de uso.
A partir disso, para se determinar o nível de usabilidade alcançado junto ao usuário é necessário medir o desempenho e satisfação destes trabalhando com um produto.
A medição possibilita visualizar a complexidade das interações entre o usuário, os objetivos, as características da tarefa e os outros elementos do contexto de uso. A cada circunstância ambiental, diferentes níveis de usabilidade podem ser definidos.
Para especificar ou medir usabilidade, algumas 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
Usuários 
Consiste em definir as características de conhecimento, habilidade, experiência, educação, treinamento, atributos físicos e capacidades sensoriais e motoras. As experiências individuais dos usuários também são levadas em consideração quando desempenha diferentes funções.
Ambiente 
As características relevantes do ambiente físico e social precisam ser descritas. Os aspectos que podem ser necessários, por exemplo, a rede de trabalho local, o local de trabalho, mobiliário, temperatura, umidade, práticas de trabalho, estrutura organizacional e atitudes.
Tarefas 
Necessita da descrição das características das atividades que visam o alcance de um objetivo e que podem influenciar a usabilidade, como por exemplo, a freqüência e a duração de uma tarefa. Convém que qualquer descrição das atividades e passos envolvidos no desempenho da tarefa estejam relacionados aos objetivos a serem alcançados.
Equipamentos 
As características relevantes do equipamento tais como o hardware, software e materiais associados com o computador precisam ser descritos. O conjunto de produtos podem ser o foco da especificação ou avaliação de usabilidade, ou um conjunto de atributos ou características de desempenho do hardware, software ou outros materiais.
A escolha e o nível de detalhes de cada medida (eficácia, eficiência e satisfação) depende dos objetivos das partes envolvidas na medição.
Deve-se considerar a importância relativa de cada medida para os objetivos. Por exemplo, caso o uso não seja freqüente, pode ser dada grande importância para as medidas de aprendizado e re-aprendizado.
Caso não seja possível obter medidas objetivas de eficácia e eficiência, medidas subjetivas baseadas na percepção dos usuários podem fornecer uma indicação de eficácia e eficiência.
Atividade 5
Criada em 1998 pela International Standard Organization, a norma ISO 9242-11 foi adotada pela ABNT em agosto de 2002 na forma da NBR 9241-11. Esta norma definiu oficialmente o conceito de usabilidade, e estabeleceu, de forma ampla, diretrizes para sistemas computacionais a fim de permitir que o usuário atinja seu objetivo e a satisfação de sua necessidade em um contexto particular.
Esta norma definiu alguns efeitos como o da USABILIDADE.
De acordo com as definições, assinale a resposta que represente corretamente o efeito citado:
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.
Assinale o componente que define as seguintes características: Os aspectos que podem ser necessários a rede de trabalho local, mobiliário, temperatura, estrutura organizacional e atitudes.
Ambiente
Assinale o componente que define as seguintes características: Os aspectos que podem ser necessários a rede de trabalho local, mobiliário, temperatura, estrutura organizacional e atitudes.
Ambiente
Quando a norma ISO/IEC 9241 especifica as características de componentes no uso de software, ela leva em consideração:
I. Tarefas
II. Eficiência
III. Satisfação
IV. Eficácia
Apenas II, III e IV
Pela ISO/IEC 9241-11 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 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 é definida por:
Usabilidade
Criada em 1998 pela International Standard Organization, a norma ISO 9242-11 foi adotada pela ABNT em agosto de 2002 na forma da NBR 9241-11. Esta norma definiu oficialmente o conceito de usabilidade, e estabeleceu, de forma ampla, diretrizes para sistemas computacionais a fim de permitir que o usuário atinja seu objetivo e a satisfação de sua necessidade em um contexto particular.
Esta norma definiu alguns efeitos como o da SATISFAÇÃO.
De acordo com as definições, assinale a resposta que represente corretamente o efeito citado:
Ausência do desconforto e presença de atitudes positivas para com o uso de um produto.
7 - A ISO/IEC 9241-11 esclarece que determinados elementos requerem uma especificação de características de uso e o nível no qual o objetivo global pretendido e estabelecido. Podemos considerar que é uma função do limite do sistema de trabalho em consideração e que fornece o contexto de uso. 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.
De acordo com as características listadas no texto em destaque, identifique o elemento citado:
	Tarefas.