Qualidade de Software

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.

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.
 Fatores, métricas e garantias de qualidade de software

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.

OPERACAO

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.

REVISÕES

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.

Custos da qualidade

Um outro aspecto importante é referente aos custos da qualidade. Vários são os estudos
conduzidos por especialistas da área de qualidade intencionados em obter um
referencial para os custos reais da qualidade, a fim de poderem identificar maneiras de
reduzir custos da qualidade e fornecer uma base de comparação entre os demais custos
envolvidos no processo de desenvolvimento de software.

Os custos operacionais da função qualidade podem ser classificados em quatro

categorias: prevenção, avaliação, falhas internas e falhas externas.

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).

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.

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
omunicaçã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.

A árvore de falhas consiste em construir um modelo gráfico das combinações

sequenciais e concorrentes de eventos que podem apresentar um evento ou estado de
sistema perigoso. Com a construção de uma árvore de falhas bem desenvolvida, pode-se
observar as conseqüências de uma seqüência de falhas inter-relacionadas que ocorram
em diferentes componentes do sistema.

A lógica de tempo real consiste no desenvolvimento de um modelo de eventos e ações

correspondentes, que é estudado por meio do uso de operações lógicas para testar as
pressuposições de segurança sobre os componentes do sistema e o tempo de ocorrência.

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.

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.
 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.

 NBR ISO/IEC 9126 (produto de software) e NBR ISO/IEC 12119 (pacote de
software)

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.

As necessidades explícitas (ou externas) dependem do que foi especificado nos

requisitos referentes às condições em que o produto deva ser utilizado, seus objetivos,
funções e o desempenho esperado. Já as implícitas (ou diretas) são necessidades que
embora não estejam especificadas nos requisitos, devem ser levadas em consideração,
pois se baseiam em princípios básicos e óbvios, necessários para que o usuário execute
a sua tarefa.

A garantia e controle de qualidade no desenvolvimento de software ao operarem

simultaneamente, visam garantir que os artefatos de software sejam desenvolvidos e
entregues com melhor aceitabilidade, menos defeitos e menores custos.

Garantia de Software

Promove a gerência sênior da organização uma melhor visibilidade apropriada sobre o

processo de desenvolvimento.

Controle de Qualidade.

Objetiva testar os produtos de software de modo a encontrar, relatar e remover seus

defeitos.

A qualidade de Software pode ser avaliada pela medição:

dos atributos internos (tipicamente medidas estáticas de produtos

intermediários);

dos atributos externos (tipicamente medidas do comportamento do código

quando executado);

dos atributos de qualidade em uso.

Segundo McCall (1977), muitas das métricas só podem ser medidas

subjetivamente. Por isso, considera importante, mais uma vez, a utilização de
uma lista de verificação (checklist) para graduar atributos específicos do
software.

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.

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 USUARIO:

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.

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.

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.

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.

Modelos de melhoria e avaliação de processo de software ISO 9000-3

Por capacidade de processo entende-se a habilidade do processo em ser

executado de forma eficiente e eficaz com a presença de algumas
A capacidade de processo determina que uma organização tenha processos executados
de forma que sejam gerenciados, definidos, medidos, controlados, efetivos e melhorados
continuamente.

Torna-se importante considerar que o grau de formalização do processo e a

complexidade da comunicação em um projeto deve ser equilibrado, ou seja, uma
formalização do processo adequada e uma comunicação correta para a efetividade de
processo (capacidade).

a ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento,

fornecimento e manutenção de software. As diretrizes propostas na ISO 9000-3 cobrem
questões como:

Entendimento dos requisitos funcionais entre contratante e contratado;

 Uso de metodologias consistentes para o desenvolvimento de software;

Gerenciamento de projeto desde a concepção até a manutenção.

Relevante destacar que uma das limitações da ISO 9000-3 é o fato de não tratar de
aspectos como a melhoria contínua do processo de software (SPI – Software Process
Improvement). Dessa forma, a ISO 9000-3 considera apenas quais processos a
organização deve ter e manter, mas não orienta quanto aos passos que devem ser
seguidos para chegar a desenvolvê-los e nem de como aperfeiçoá-los.

A documentação do processo de avaliação de um produto de software, representado

pela ISO/IEC 14598-5, deve englobar um conjunto de métricas que fornecem
informações importantes sobre as propriedades do software e devem ser utilizadas de
maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e
entre avaliadores. Para tanto, requer que haja uma padronização na forma de
documentação o que é feito pela aplicação de módulos de avaliação (M.A.).

O sistema de qualidade deve ser documentado na forma de um manual e, assim,

implementado.

Modelo de qualidade do processo de ciclo de vida do software NBR ISSO / IEC

12207

Qualidade em uso

A NBR ISO/IEC 12207 – Processos de Ciclo de Vida de Software  tem como objetivo
o estabelecimento de uma estrutura comum para os processos de ciclo de vida de
software como forma de ajudar as organizações a compreenderem todos os
componentes presentes na aquisição e fornecimento de software e, assim, conseguirem
firmar contratos e executarem projetos de forma eficaz.

modelos de melhoria e processo que permeiam três variáveis:

PROCESSOS

PESSOAS

TECNOLOGIAS

Considera-se que o processo de criação de um produto pode ser concebido como um

ciclo de vida composto por procedimentos. Da mesma maneira, pode-se considerar que
o processo de desenvolvimento de software constitui-se ser o ciclo de vida do software.
 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. São descritos os procedimentos,
métodos, ferramentas para que possam ser realizadas as atividades de forma adequada.

Os processos da ISO/IEC 12207 são fortemente coesos, ou seja, todas as partes de um

processo são fortemente relacionadas. Porém, os processos são fracamente acoplados
quanto à quantidade de interfaces entre os processos.

Regras para identificação, escopo e estruturação dos processos:

Um processo deve ser modular, ou seja, deve executar uma e somente uma função
dentro do ciclo de vida com a menor incidência de interfaces entre dois processos.

Se um processo A é invocado por um processo B e somente por ele, então A pertence a

B.
 Se uma função é invocada por mais de um processo, então essa função torna-se um
processo.

Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida.

A estrutura interna deve ser suficientemente definida para que possa ser executável.

A NBR ISO/IEC 12207 estabelece uma arquitetura de ciclo de vida de software

construída a partir de uma estrutura de processos e seus inter-relacionamentos descritos
tanto em nível de propósito/saída como em termos de processos, atividades, tarefas,
propósito e resultados que servem para ser aplicados:

durante a aquisição de software, de um produto de software independente ou de um

serviço de software.

durante o fornecimento, desenvolvimento, operação e manutenção de produtos de

software.

Modelos de Qualidade de Processo de Software ISO/IEC 15504 - (Spice -

Avaliação), CMMI e MPS.BR
A ISO/IEC 15504, conhecida também como SPICE (Software Process Improvement
and Capability Determination), consiste em uma norma para definição de processos
de desenvolvimento de software. Os requisitos da norma são uma evolução da norma
ISO/IEC 12207, porém apresenta níveis de capacidade para cada processo. Por muito
tempo, a norma manteve-se em estudo e, somente em 1993, a ISO tornou pública a
norma ISO/IEC 15504 (SPICE) para avaliação de processos de software.

Trata-se de um modelo bidimensional com objetivo de realizar avaliações dos mesmos

com foco na sua otimização no que tange aos pontos fortes e oportunidades de melhoria,
e a determinação da capacidade dos processos por meio da avaliação de um fornecedor
em potencial.

O modelo de avaliação de processo é organizado em uma arquitetura com dois níveis,

sendo o primeiro composto por três categorias de processo: FUNDAMENTAIS,
ORGANIZACIONAIS E DE APOIO

O processo é composto  por: planejamento da melhoria,

implementação,confirmação,manutenção, acompanhamento da melhoria

Dimensão de Capacidade de Processo

Em uma organização, vários processos podem ter níveis de capacidade diferentes. A

ISO/IEC  15504 define 6 níveis de capacidade sequenciais e cumulativos. Os  níveis
podem ser usados para avaliar como uma organização está realizando um determinado
processo  e como um  guia para a melhoria de processo. Cada nível de capacidade é
descrito basicamente por um nome, definição e atributos.
 0 - Incompleto: processo não existe ou geralmente falha.

1 - executado: processo atinge os objetivos, porém sem padrão de qualidade e sem

controle de prazos e custos.

2 - Gerenciado: processo planejado e acompanhado, e satisfaz requisitos definidos de

qualidade, prazo e custos, e seus produtos de trabalho são gerenciados.

3 - Estabelecido: processo executado e gerenciado com uma adaptação de um processo

padrão definido, eficaz e eficiente.

4 - Previsível: processo executado dentro de limites de controle definidos e com

medições detalhadas e analisadas.

5 - Otimizando: processo melhorado continuamente de forma disciplinada.

Todo processo de avaliação deve ser bem documentado e conter, no mínimo, as

atividades de planejamento, coleta de dados, validação dos dados, pontuação dos
atributos de processo e representação dos resultados.

A ISO/IEC 15504 não pressupõe modelos de ciclo de vida de software, tecnologias de

software ou metodologias de desenvolvimento. Também não define um método
explícito de avaliação, mas define os requisitos para o Método de Avaliação de
Processos. Na prática, uma avaliação de processos de software é conduzida utilizando o
Modelo de Avaliação de Processos e não o Modelo de Referência de Processos.

CMMI (Capability Maturity Model Integration)

É intenso o desenvolvimento de softwares produzidos sem a orientação padronizada de

uma norma. Isso acontece por conta de os fabricantes se preocuparem em atender às
necessidades iniciais do cliente, negligenciando aspectos de manutenção e durabilidade.
O resultado dessa visão é a produção de softwares de baixa qualidade.

Inicialmente, o SEI (Software Engineering Institute) divulgou o CMM como o

documento padrão de normas a serem seguidas e, logo após, outros tantos foram
definidos, tais como:

Engenharia de Sistemas (SE-CMM), Aquisição de Software (SA-CMM) e Gestão de

Recursos Humanos de Empresas de Softwares (P-CMM).

Definição, Características e Objetivos do CMMI

Tomado como modelo de referência, o CMMI é capaz de fornecer uma orientação para
o desenvolvimento de processos de softwares.
 O objetivo do modelo é:

Eliminar as inconsistências.

Aumentar a clareza e entendimento.

Fornecer uma terminologia comum e um estilo consistente.

Afirma-se que o alcance do nível de maturidade de processos organizacionais se faz

quando os processos alcançam uma determinada capacidade, ou seja, tem mecanismos
que garantem a repetição sucessiva de bons resultados futuros relacionados
principalmente à qualidade, custos e prazos.

Representações do CMMI

CONTÍNUA:

Permite que uma organização selecione uma área (ou um grupo de áreas) de processo e
melhore os processos relacionados. Ela usa níveis de capacidade para
caracterizarmelhorias relativas a uma área de processo individual.

O enfoque ou componentes principais são as áreas de processo. Existem metas e

práticas de dois tipos: específicas a uma determinada área de processo e genéricas
aplicáveis indistintamente a todas as áreas de processo. A partir da avaliação e do
atendimento dessas práticas e metas, é possível classificar o nível de capacidade de cada
área de processo em níveis de zero a cinco

ESTAGIADA:

Usa conjuntos pré-definidos de áreas de processo (KPA's) para definir um caminho para
uma organização, caracterizado por níveis de maturidade. A representação em estágios
oferece uma abordagem estruturada e sistemática para a melhoria de um estágio por vez.
Atingir um estágio significa que uma estrutura de processo adequada foi estabelecida
como base para o próximo estágio. 

As áreas de processo são organizadas por níveis de maturidade (1 a 5) que definem o

caminho de melhoria que uma organização deve seguir do nível inicial ao nível
otimizado. Dentro de cada nível, existem áreas de processo que contêm metas,
características comuns e práticas. 

Na representação em níveis, as práticas são caracterizadas pelos atributos: compromISO

para execução (práticas que garantem que o processo seja estabelecido e apoiado);
habilidade para execução (práticas que criam condições para que o processo seja
estabelecido completamente) e atividade para execução (práticas que implementam
diretamente o processo); controle e verificação de implementação. A transição entre os
níveis resulta em melhorias incrementais e duradouras.
 MPS.BR

O objetivo do MPS.BR sintetiza a descrição de Melhoria de Processo do Software

Brasileiro. Participam da criação as universidades, os grupos de pesquisas e as empresas
sob coordenação da SOFTEX.

Para isso, o MPS.BR desenvolve uma série de atividades cobrindo a elaboração de

modelos de referência (MRMPS), elaboração de métodos de avaliação (MA-MPS),
elaboração de guia de negócios (MN-MPS) para aquisição, desenvolvimento e aplicação
de diversos cursos para capacitação, credenciamento de pessoas e instituições como
implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas
empresas, e outras. A Figura 6.1 demonstra os modelos MPS.BR.

O MPS. BR baseia-se nas melhores práticas de engenharia de software, sendo

compatível com o CMMI e em conformidade com as normas ISO/IEC 12207 e ISO/IEC
15504.

A versão 1.0 do modelo MR-MPS define 23 processos baseados em processos

selecionados da ISO/IEC 12207 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-
SE/SW. Na estrutura do modelo são definidos sete níveis de capacidade ou maturidade
de processo, expressos em termos de processos e de cinco atributos de processo (AP).
Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores
e, eventualmente, acrescenta novos atributos de processo a todos os processos.

As vantagens na prática do modelo se justificam pela compatibilidade com o CMMI e

com as demais normas, além de considerar uma implantação mais gradual e adequada a
pequenas e médias empresas, uma possiblidade de obtenção do certificado, uma
avaliação bienal das empresas e uma integração universidade-empresa.  

Por outro lado,  apesar do foco do MPS.BR ser um meio das médias e pequenas
empresas alcançarem a qualidade nos processos e nos produtos desenvolvidos, servindo
 como uma alternativa para o CMMI, a certificação não é competitiva o suficiente para
tornar a empresa competitiva internacionalmente.

A gerência de riscos na qualidade de software

Um risco é qualquer evento ou condição em potencial que, se concretizando, pode afetar
positivamente ou negativamente um objetivo do projeto, por exemplo, o software que
está sendo desenvolvido ou a organização.

Classificação de riscos de software

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

Imprevisiveis

A probabilidade é a chance de ocorrer e o impacto é o efeito sobre o

objetivo do projeto, caso o evento ou condição de risco venha se
manifestar.

O gerenciamento dos riscos do projeto tem por objetivo:

Maximizar os resultados.

Minimizar as consequências dos eventos negativos.

Identificação de riscos: descoberta dos riscos potenciais para o projeto,

produto e negócios.

Análise de riscos: capacidade de compreender, analisar, estimar e avaliar

as dimensões de cada fator de risco individual e o seu peso para o conjunto

Planejamento de risco: elaboração de planos para cuidar dos riscos

evitando-os ou minimizando seus efeitos no projeto.

Monitoração de riscos: observação da efetividade dos planos de ação na

execução do desenvolvimento do projeto de software.
 Fatores de Risco:

Os efeitos do risco podem ser avaliados como catastróficos, sérios,

toleráveis ou insignificantes, veja exemplos na tabela abaixo:

As estratégias podem ser categorizadas em:

De prevenção: a ocorrência de riscos é reduzida.

De minimização: o impacto do risco será reduzido.

De contingência: o efeito do risco é forte, mas existe uma alternativa para

lidar com o problema.