Plano de Qualidade

Plano de Garantia de Qualidade

Índice Analítico

PLANO DE GARANTIA DE QUALIDADE

2
1 INTRODUÇÃO
2
1.1 PROPÓSITO
2
1.2 ESCOPO
3
1.3 MOTIVAÇÃO
3
2 OBJETIVOS PARA A QUALIDADE
3
3 GERENCIAMENTO
3
3.1 ORGANIZAÇÃO
3
3.2 TAREFAS E RESPONSABILIDADES
4
4 PADRÕES E DIRETRIZES
4
5 MÉTRICAS
5

Confidencial Plano de Qualidade

6 PLANO DE REVISÕES E AUDITORIA
5
6.1 REVISÃO DE ARQUITETURA
5
6.2 REVISÃO DE PROJETO
6
6.3 REVISÃO DE CÓDIGO
6
6.4 AUDITORIA DO PROCESSO
6
7 AVALIAÇÕES E TESTES
6

Introdução

1.1 Propósito
Este documento tem como propósito reunir todas as informações sobre qualidade para o projeto
Nome do Projeto, a fim de prover um ponto único de referência sobre o assunto.

1.2 Escopo
O Plano de Garantia de Qualidade é aplicável para o projeto Nome do Projeto, desenvolvido
para a Nome do Cliente, focando principalmente na unidade NOME DO CLIENTE. Este plano
contém os tópicos relacionados à qualidade para este projeto e destina-se, principalmente, aos
grupos abaixo:

 Gerente de Projetos da Nome do Cliente;

 Responsáveis por qualidade na Nome do Cliente;
 Gerente de Projetos da Uniminas;
 Responsáveis por Testes e Revisões Uniminas.

1.3 Motivação
Estatisticamente, defeitos de software são de 100 a 1000 vezes mais difíceis e caros de serem
encontrados e reparados depois da etapa de Deployment. Verificar e gerenciar a qualidade
durante o ciclo de vida do projeto é essencial para alcançar os objetivos desejados no tempo
correto.
2 Objetivos para a Qualidade
O produto deve satisfazer todos os requisitos funcionais e não-funcionais que perfazem o escopo
deste projeto. Os procedimentos de qualidade deverão abranger a aderência da arquitetura do
software a estes requisitos, bem como a adequação e melhoria do processo de desenvolvimento
aplicado.

A conformidade do produto aos requisitos será verificada através do Plano de Aceitação do

Produto (vide Plano de Desenvolvimento de Software), no qual está definido o critério para
avaliação da qualidade dos artefatos a serem entregues.

3 Gerenciamento

3.1 Organização
Os seguintes recursos do projeto atuarão, diretamente, para realizar este Plano de Qualidade:
Papel
Engenheiro de Processos
Gerente de Projetos
Revisor Técnico (Revisores
de Arquitetura e Projeto)
Implementador
Gerente de Testes
Projetista de Testes
Testador
Responsabilidade
Customizar e auditar o processo a fim de atingir os objetivos de qualidade para o
projeto.
Alocar e coordenar os recursos a fim de operacionalizar as atividades que
garantem a integridade e qualidade dos artefatos do projeto.
Revisar os artefatos gerados através das atividades de Arquitetura e Projeto.
Revisar, através de pares, os artefatos de implementação.
Definir objetivos dos testes, avaliar e alocar esforços para execução dos testes.
Definir abordagem dos testes, identificar testes e estruturar a implementação
destes.
Implementar os testes, executá-los, analisar e registrar falhas ocorridas na
execução.

3.2 Tarefas e Responsabilidades

As seguintes tarefas serão realizadas a fim de atingir os objetivos de qualidade para o projeto:
Tarefa Responsáveis Freqüência
Revisar Revisor Técnico A cada iteração da fase de elaboração.
arquitetura
Revisar projeto Revisor Técnico A cada iteração das fases de elaboração,
construção e transição.
Revisar código Implementador Ao final de cada build.
Realizar testes Gerente de Testes, Projetista de A cada iteração das fases de elaboração,
Testes e Testador construção e transição.
Auditar o Engenheiro de Processos Ao final de cada iteração.
processo
4 Padrões e Diretrizes
Os seguintes padrões e diretrizes serão utilizados para atingir a qualidade objetivada para o
produto:
 Padrão de Gerenciamento de Projetos: Será utilizado o PMI, o qual padroniza as
atividades de gerenciamento visando atingir os objetivos de prazo, custo, escopo e
qualidade;

 Padrões arquiteturais: É um conjunto de abordagens para estruturação da

arquitetura de software;

 Padrões de Projeto (design patterns): São modelos amplamente utilizados pela

comunidade técnica a fim de solucionar problemas que se repetem em vários projetos
(ex.: transfer-object);

 Softwares open-source: Software de domínio público que oferecem serviços de uso

genérico. O artefato Documento de Arquitetura de Software descreve os softwares
open-source que poderão ser integrados ao produto;

 Ferramentas open-source: Ferramentas de domínio público que serão utilizadas nas

atividades de confecção do produto como, por exemplo: Eclipse, JUnit, etc.. Estas
ferramentas estão listadas no artefato Caso de Desenvolvimento.

5 Métricas
Para prover controle e possibilitar a medição dos objetivos de qualidade para o projeto serão
usadas as seguintes métricas:
Métrica Propósito Variáveis indicadoras
Progresso Planejamento e controle do Número de casos de uso
projeto analisados/projetados;
Número de subsistemas
projetados/implementados;
Número de casos de teste
projetados/implementados/executados.
Variação Avaliar a eficácia do Variação entre o cronograma (baseline) da
planejamento iteração e sua realização.
Funcionalidade Avaliar a aderência do Número de defeitos;
produto aos requisitos e
definir critério para Taxa de descoberta de defeitos;
liberação de releases; Densidade dos defeitos (ponderação entre
Avaliar o volume de importância e complexidade de correção);
retrabalho. Número de correções após as revisões (ver
item Revisões e Auditoria).
Modularidade Avaliar coesão dos Número de classes modificadas por alteração
elementos do sistema
Maturidade Avaliar Percentual de requisitos testados;
cobertura/adequação dos
testes Percentual de código testado.
 Métrica Propósito Variáveis indicadoras
Estabilidade da arquitetura Avaliar adequação da Quantidade de retrabalho gerado pelas
arquitetura mudanças, ponderando a
importância/complexidade das mudanças
solicitadas.
Estabilidade dos requisitos Avaliar Gestão de Quantidade de alterações nos requisitos.
Requisitos

6 Plano de Revisões e Auditoria

6.1 Revisão de Arquitetura

A revisão de arquitetura tem vários objetivos, entre eles destacam-se:

 Detectar violações trazidas pelos requisitos à arquitetura;

 Descobrir riscos não percebidos e refleti-los no planejamento do projeto;
 Verificar inconsistências entre os requisitos e a arquitetura: arquitetura atendendo
requisitos que na realidade não existem ou requisitos não atendidos;
 Avaliar as qualidades da arquitetura: performance, confiabilidade, segurança e
adaptabilidade a mudanças nos requisitos;

O Revisor Técnico é responsável por avaliar o Documento de Arquitetura de Software e escrever

a revisão inicial. A revisão é então encaminhada ao Arquiteto de Software e ao Analista de
Sistemas, os quais podem alterar a revisão, gerando uma nova versão do artefato. Em caso de
discordância entre as partes, é marcada uma reunião, onde eles discutirão a discordância e a
versão final do documento será o resultado desta reunião.

6.2 Revisão de Projeto

A atividade de Revisão de Projeto visa, entre outros, os objetivos abaixo listados:

 Verificar se o modelo de projeto realiza os requisitos do sistema e serve como

base adequada para o início da implementação;
 Assegurar que o modelo de projeto esteja consistente com os padrões e diretrizes
de projeto;
 Avaliar se as diretrizes de projeto atingiram seus objetivos.

O Revisor Técnico é responsável por avaliar o Modelo de Projeto e escrever a revisão inicial. A
revisão é então encaminhada ao Projetista, o qual pode alterar a revisão, gerando uma nova
versão do artefato. Em caso de discordância entre as partes, é marcada uma reunião, onde eles
discutirão a discordância e a versão final do documento será o resultado desta reunião.

6.3 Revisão de Código

Uma das formas de auditoria de código será a revisão feita entre pares de implementadores.
Esta atividade tem como principal objetivo verificar se o código implementa o que está projetado,
ou seja, não existe código não projetado e nem partes do projeto que não foram implementadas.
 6.4 Auditoria do Processo
A Auditoria do Processo visa avaliar se o projeto está sendo realizado de acordo como definido e
se os resultados do projeto certificam que o processo aplicado está adequado. Esta atividade
será realizada pelo Engenheiro de Processos ao final de cada iteração.

As não-conformidades serão registradas em formulário próprio e encaminhadas ao Gerente de

Projetos. As readequações do processo que se fizerem necessárias serão comunicadas ao
Gerente de Projetos, o qual determinará quando estas serão implementadas pelo Engenheiro de
Processos, promovendo, assim, uma constante melhoria nos processo de engenharia de
software aplicados.

7 Avaliações e Testes
Vide artefato Plano de Desenvolvimento de Software e Plano de Testes (este último será
definido na primeira iteração do projeto).