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.