PGQ Danielle Denis Guilherme Rodrigo

(1)

Orbital

Plano de Garantia de Qualidade

Versão 2.2

(2)

Histórico da Revisão

Data Versão Descrição Autor

20/09/2008 1.0 Criação do Plano de Garantia de Qualidade

Amanda Lamarca 07/10/2008 2.0 Alteração do Plano de Garantia de

Qualidade

Danielle de Assis 07/10/2008 2.1 Revisão do Plano de Garantia de

Qualidade

Denis Monteiro 07/10/2008 2.2 Revisão do Plano de Garantia de

Qualidade

(3)

Índice Analítico

1. INTRODUÇÃO 5

1.1 Finalidade 5

1.2 Escopo 5

1.3 Definições, Acrônimos e Abreviações 5

1.4 Referências 5 1.5 Visão Geral 5 2. OBJETIVOS DE QUALIDADE 6 3. GERENCIAMENTO 6 3.1 Organização 6 3.2 Tarefas e Responsabilidades 7 4. DOCUMENTAÇÃO 7 5. PADRÕES E GUIAS 7 6. MÉTRICAS 7

7. PLANO DE REVISÃO E DE AUDITORIA 8

7.1. Planejar auditoria 8

7.2. Definir o escopo da auditoria 8

7.3. Realizar a auditoria 8

7.4. Criar o relatório de auditoria 9

7.5. Aplicação dos resultados 9

7.5.1. Escalonamento 9

7.6. Status do Relatório 9

8. AVALIAÇÃO E TESTE 9

9. RESOLUÇÃO DE PROBLEMAS E AÇÃO CORRETIVA 9

10. FERRAMENTAS, TÉCNICAS E METODOLOGIAS 9

(4)

12. CONTROLES DE FORNECEDOR E DE SUBCONTRATANTE 9

13. REGISTROS DE QUALIDADE 10

14. TREINAMENTO 10

(5)

Plano de Garantia de Qualidade

1. Introdução

O objetivo da Garantia de Qualidade de Software (SQA) é possibilitar um melhor gerenciamento dos processos e produtos que são gerados no andamento do projeto. A SQA engloba também auditoria e revisão, verificando se estão sendo feitos de acordo com os padrões adotados.

1.1 Finalidade

Este documento tem a finalidade de propor um Plano de Garantia de Qualidade (SQA) para o projeto Orbital. Os detalhes da avaliação de qualidade são fornecidos no Plano de

Desenvolvimento de Software, Plano de Avaliação e no Plano de Teste.

Considera-se que o software tem garantia de qualidade quando a expectativa do cliente foi atingida.

1.2 Escopo

Serão apresentados neste Plano os pontos importantes para que seja garantida a qualidade de todo o projeto Orbital. Será mostrado também os objetivos de qualidade, padrões e atividades referentes a garantia de qualidade.

1.3

Definições, Acrônimos e Abreviações

Termo Significado

SQA Do inglês, Software Quality Assurance (Garantia de Qualidade de Software) NA Não se aplica.

CMMI Do inglês, Capability Maturity Model Integration Issues Qualquer não conformidade encontrada

Release Entrega formal de produtos de trabalho ao cliente, como o envio de um documento exigido por ele ou a implantação de uma nova versão do software.

SEPA Autoridade de Processo de Engenharia de Software TQM Do inglês Total Quality Management

PSP Do inglês Personal Software Process TSP Do inglês Team Software Process RUP Do inglês Rational Unified Process PDCA Do inglês PLAN – DO – CHECK – ACT 5 S’s Seiri, Seiton, Seiso, Seiketsu e Shitsuke.

1.4 Referências

Documento Localização

Plano de Métricas http://projetointer2.wordpress.com/. Plano de Teste http://projetointer2.wordpress.com/. Plano de Desenvolvimento de Software http://projetointer2.wordpress.com/. Plano de Resolução de Problemas http://projetointer2.wordpress.com/. Plano de Gerenciamento de Riscos http://projetointer2.wordpress.com/.

1.5 Visão Geral

Este documento visa apresentar todo o plano de garantia de qualidade de nossos software on-line, estando organizado nas seguintes seções:

Seção 02: Objetivos de Qualidade – verificar erros e falhas do sistema Orbital; Seção 03: Gerenciamento, organização e divisão de tarefas e responsabilidades;

Seção 04: Documentação – todos os documentos que serviram de referencia para a execução do

documento;

(6)

Seção 06: Métricas;

Seção 07: Plano de revisão e Auditoria; Seção 08: Avaliação e testes;

Seção 09: Resolução de problemas e Ações corretivas; Seção 10: Ferramentas, técnicas e metodologias; Seção 11: Gerenciamento de configuração;

Seção 12: Controle de fornecedor e de subcontratante; Seção 13: Registro de qualidade;

Seção 14: Treinamento; e

Seção 15: Gerenciamento de riscos.

2. Objetivos de Qualidade

A qualidade pode ser entendida como a conformidade com os requisitos declarados. A existência de padrões de desenvolvimentos bem documentados e características implícitas de um software profissionalmente desenvolvido.

As normas ISO 9000 definem o que é necessário e satisfatório em um sistema de qualidade. A última principal mudança desta norma incluiu a visão do foco do cliente que passou a ser um “integrante” da organização.

Além da ISO, podemos citar outros modelos do Software Engineering Institute (SEI), são eles:  Capability Maturity Model Integration (CMMI);

 Personal Software Process (PSP);

 Team Software Process (TSP);

A clareza destes objetivos é importante, pois, mediante seu conhecimento podemos reduzir a quantidade de retrabalho, diminuindo custo e tempo dos projetos.

Pensando nisto, este plano propõe abaixo apontar quais serão os requisitos básicos de qualidade a serem alcançados para o Projeto Orbital.

 Usabilidade – o quanto o sistema é fácil de ser utilizado;

 Confiabilidade – no armazenamento de informações pessoais, disponibilidade do sistema para acesso na internet;

 Desempenho:

o Tempo de resposta adequado – Por não se tratar de um sistema on-line, as informações deverão ter um “atraso” em sua publicação. Sincronizações entre documentos ocorrerão de acordo com o tempo pré-definido no documento XXX;

o Formato de acesso – multi-usuários (vários usuários acessando/consultando as informações ao mesmo tempo).

 Suportabilidade:

o Implementação – serão utilizadas bibliotecas já existentes para a implementação das atividades.

o Documentação – seguirá os modelos definidos pela equipe de projeto.  Restrições de Design:

(7)

o Linguagem – será utilizada uma linguagem já conhecida pelos desenvolvedores.

 Sistemas de Ajuda e de documentação de Usuários on-line  Componentes adquiridos

 Interfaces

o Do usuário – interface fácil e intuitiva; o De hardware:

 Do usuário – não suportada (iremos avaliar requisitos mínimos do hardware para esse caso);

 Servidor – Provedor com todos os requisitos máximos de segurança, desempenho e suportabilidade.

o De software – simples e amigável ao desenvolvedor. Os objetivos definidos:

 Satisfazer as necessidades e expectativas do cliente;  Cumprir de prazos de entrega;

 Entrega de acordo com requisitos;  Minimizar índice de erros;  Manter infra-estrutura adequada;  Garantir disponibilidade;

O principal objetivo da Qualidade é sem dúvidas, a garantia de um produto final que satisfaça as expectativas do cliente dentro do que foi acordado no inicio do projeto.

3. Gerenciamento

3.1 Organização

Dispomos de uma equipe de Autoridade de Processo de Engenharia de Software (SEPA) responsável pelo componente de processo de garantia da qualidade e uma equipe de garantia de qualidade (SQA)

responsável por preparar o plano de SQA, revisar atividades de engenheiros, documentar e acertar desvios, também gerencia mudanças e métricas do software.

Também temos uma equipe especializada em testes que atua individualmente sem contato com o programador responsável.

A equipe de auditoria é responsável verifica a conformidade dos procedimentos para que possamos atingir nosso objetivo.

Desta forma, procuramos atingir um gerenciamento total da qualidade (TQM) focando as necessidades do cliente, envolvendo todas as pessoas da organização e desenvolvendo um processo de melhoria continua.

3.2 Tarefas e Responsabilidades

A garantia da qualidade pode utilizar os resultados dos seguintes processos de apoio:

 Revisões Conjuntas: Antes de cada entrega é realizada uma revisão em conjunto com o cliente.

 Auditorias de Processo: Durante o início e o fim do projeto, se necessário, é contratada uma auditoria externa para garantir a transparência do projeto.

(8)

 Auditorias do Cliente: No início e antes de cada entrega e sempre que

solicitadas pelo cliente.

Papel Tarefas e Responsabilidades

Equipe SEPA - Organização do processo de garantia da qualidade. Equipe SQA - Preparação do plano de SQA;

- Revisão de atividades de engenheiro de software; - Documentar e consertar erros;

- Reportar erros aos gerentes;

- Gerenciar mudanças e métricas do software;

- Busca de conformidade com padrões de desenvolvimento; - Busca de melhoria continua.

Equipe de Testes - Revisão conjunta do cliente/desenvolvedor testando todas as possibilidades dentro do sistema;

Equipe de Auditoria - Responsável pela auditoria do processo em si e também do cliente. Gerente do Projeto - Analisar relatórios de erros recebidos da equipe de SQA e tomar devidas

providencias.

4. Documentação

Esta seção lista a documentação mínima que servirá de base para este plano. O conjunto mínimo de artefatos neste caso são os citados abaixo:

 Plano de Desenvolvimento de Software (SDP)  Plano de Teste

 Plano de Iterações

 Especificação de Requisitos de Software (SRS)  Documento de Arquitetura de Software

 Documentação do Usuário (por exemplo, manuais, guias)  Plano de Gerenciamento de Configuração

5. Padrões e Guias

A seguir, estão descritos os documentos de padrões e guias do projeto

Documento Localização

Caso de Desenvolvimento http://projetointer2.wordpress.com/. Guia de Modelagem de Negócios http://projetointer2.wordpress.com/. Guia de Interface do Usuário http://projetointer2.wordpress.com/. Guia de Modelagem de Caso de Uso http://projetointer2.wordpress.com/.

Guia de Design http://projetointer2.files.wordpress.com/2008/09/design.doc Guia de Programação

http://projetointer2.files.wordpress.com/2008/09/guia-de-programacao.doc

Guia de Teste http://projetointer2.wordpress.com/. Manual de Guia de Estilo http://projetointer2.wordpress.com/.

(9)

Plano de Métricas http://projetointer2.wordpress.com/.

6. Métricas

A seguir, serão descritas detalhadamente as métricas do projeto.

Nome Cronograma

Definição Fases, data inicio, data fim.

Metas Data de entrega do projeto respeitando as fases.

Procedimento de análise Analisar a cada finalização de fases se o prazo esta sendo cumprido ou estourado.

Responsabilidades Gerente do projeto.

Nome Orçamento

Definição Recursos humanos, horas trabalhadas. Baseado nestes itens será calculado o valor total do projeto.

Metas O custo total do projeto não pode exceder o valor acordado na proposta com o cliente

Procedimento de análise Verificar se a quantidade de recursos alocados é suficiente para a conclusão do projeto, se necessário alocar mais recursos sem ultrapassar o valor total estipulado.

Nome Tamanho do software

Definição Casos de uso, Pesos. Será estipulado o tamanho total do software para auxiliar o gerente na alocação de recursos e cumprimento de prazos.

Metas O tamanho do software deve possuir um número adequado para softwares de pequeno/médio porte (calculo ainda será efetuado).

Procedimento de análise Aplicação do cálculo de pontos de caso de uso.

Nome Defeitos por fase de desenvolvimento

Definição Quantidade de erros, fase do desenvolvimento.

Metas O número de erros por fase não pode ser maior 10% do desenvolvimento total da fase.

Procedimento de análise No final de cada fase o número de erros deve ser contabilizado e comparado com a quantidade total de itens desenvolvidos.

Nome Expectativa X Realizado

Definição Documentação inicial de requisitos de software, Software final. Será analisado o percentual do esperado e o realizado do projeto.

(10)

Procedimento de análise Analisar no final do projeto se todos os itens solicitados no inicio do mesmo foram atingidos.

7. Plano de Revisão e de Auditoria

As auditorias serão realizadas a cada iteração de desenvolvimento do projeto. A seguir estão os tópicos que serão auditados.

 Verificar se o software está sendo desenvolvido de acordo com o processo definido.  Verificar se os artefatos criados estão todos de acordo com o padrão definido pelo processo.  Verificar se a implementação está de acordo como os requisitos do sistema.

 Identificar melhorias no processo e incorpora-las nas próximas fases.

Toda informação da auditoria será registrada no documento de auditoria e disponibilizada a equipe de desenvolvimento no repositório de trabalho da equipe (a especificar). O assunto da auditoria será definido pelo SQA.

A informação da auditoria será obtida através de observações no processo de desenvolvimento do sistema ou através de questionamentos via e-mail com os integrantes da equipe. Os tópicos a seguir descrevem os critérios para uma auditoria ser realizada.

 Mudanças em algum artefato.

 Indicação que um processo ou modelo não está sendo seguido.

 Métricas indicando a necessidade de uma auditoria, por exemplo, quando a métrica está refletindo uma deficiência no processo.

 Tarefas de Revisão e Auditoria

 Os requisitos iniciais do sistema serão revisados pelo cliente e desenvolvedor antes do inicio do mesmo.

 Todos os documentos serão revisados e suas versões controladas.  Revisões dos planos elaborados para o projeto,

 Auditorias dos processos criados para a fábrica.  Programação

 As revisões e auditorias serão realizadas em data acordada com o cliente.  Organização e responsabilidades

 Temos um especialista técnico responsável por fazer auditorias. Após a auditoria ser analisada por este funcionário, poderá ser encaminhada ao cliente, desenvolvedor ou gerente do projeto.

 Resolução de Problemas e Ação Corretiva

 Verificar seção 9.

7.1. Planejar auditoria

Identificar a necessidade de realização de uma auditoria com base nos critérios definidos na seção Auditorias e definir o planejamento para a auditoria.

7.2. Definir o escopo da auditoria

 Definir os produtos de trabalho a serem auditados.

 Selecionar e preparar o checklist apropriado para realizar a auditoria.  Definir os participantes da auditoria.

(11)

7.3. Realizar a auditoria

 Caso a auditoria seja realizada via e-mail, no corpo do e-mail deverá ser descrito o objetivo e a importância da auditoria. As questões serão abertas e um checklist pode ser utilizado como um guia.

 O auditor ao receber a resposta da auditoria, utilizará o julgamento profissional para decidir se as respostas têm algum sentido ou não. É necessária atenção as respostas e observar se há algum comentário que seja relevante para a melhoria do processo.

 Pergunte se alguém tem algum questionamento há fazer ou alguma observação relevante.

7.4. Criar o relatório de auditoria

 Resume o resultado da auditoria em algum relatório. Utilizar uma linguagem clara e concisa.  Informe como a auditoria foi realizada (via e-mail ou através de observações).

 Descrever as não conformidades encontradas.

 Descreva no relatório as recomendações necessárias tendo como base às respostas adquiridas nas inspeções.

 Sugerir oportunidades de melhoria.

 Publicar e comunicar aos participantes onde o relatório final está disponível.

7.5. Aplicação dos resultados

 Para cada falta encontrada durante a auditoria será aberto um chamado, e o status desta falta será acompanhado periodicamente até seu fechamento.

 Caso a ação corretiva não seja resolvida no tempo estimado, é de responsabilidade do SQA identificar porque o problema não foi resolvido e definir uma nova data.

7.5.1. Escalonamento

Para a resolução de problemas encontrados durante a auditoria será aberta uma tarefa, e atribuída a um membro do grupo . A data de resolução da falta deve ser definida pelo colaborador que abrir o chamado, obedecendo aos pontos a seguir.

 Se a tarefa não foi resolvida no prazo estabelecido inicialmente, a nova data de resolução do problema não deve ser superior a duas semanas, contados a partir da data estimada para a resolução do problema.

 Faltas críticas serão fechadas no máximo em 15 dias a partir da data de atribuição do chamado.  Faltas não críticas serão fechadas no máximo em 1 mês a partir da data de atribuição do

chamado.

7.6. Status do Relatório

 O SQA apresenta aos membros da equipe de desenvolvimento do projeto um status mensal do relatório de auditoria.

 O status do relatório será discutido via e-mail.

 Após a primeira entrega do projeto o responsável pelo sistema no cliente receberá uma cópia do status.

8. Avaliação e Teste

O objetivo das avaliações e testes é detectar problemas e riscos que interfiram na qualidade final do projeto e produto.

Os testes são classificados como funcionais e não funcionais, como descreve a lista abaixo:  Testes Funcionais

o Cadastro; o Login no site;  Testes Não Funcionais

(12)

o Usabilidade; o Disponibilidade.

A seguir, detalharemos os testes mostrando seu objetivo, a técnica, critérios de êxito e

considerações especiais.

Teste Login no site

Objetivo do Tipo de Teste: Verificar se o site só permite acesso á usuários cadastrados

Técnica: Tentar entrar no sistema com usuário invalido.

Critérios de Êxito: Mostrar mensagem de erro.

Considerações Especiais: NA

Teste Usabilidade

Objetivo do Tipo de Teste: Verificar se a interface com o usuário esta adequada e simples.

Técnica: Simular de todos os testes anteriores.

Critérios de Êxito: Facilidade de uso.

Teste Disponibilidade

Objetivo do Tipo de Teste: Verificar se todos os campos obrigatórios estão sendo exigidos para um cadastro com sucesso do usuário.

Técnica: Simular cadastro tentado salvar sem preencher todos os campos obrigatórios.

Critérios de Êxito: Mostrar mensagem de erro.

O artefato gerado nos testes será um relatório de apontamento de resultados dos mesmos.

9. Resolução de Problemas e Ação Corretiva

Os problemas devem ser documentados e analisados assim que ocorram.

O gerente de projeto deve verificar o problema e encaminhar para uma pessoa responsável na fabrica de software possa corrigí-lo.

Para reportar os problemas encontrados durante o projeto a equipe que identificar o mesmo deverá classificá-lo como problema de:

- Produto; - Projeto; - Processo.

Após a classificação, o responsável deverá ser notificado. Os responsáveis estão listados

na tabela a seguir:

Problema Responsável

Produto Equipe de testes Projeto Coordenador do projeto Processo Gerente do projeto

(13)

O responsável irá analisar o caso e se necessária alguma alteração irá documentar o fato e em seguida reportar para a equipe responsável fazer a alteração.

10. Ferramentas, Técnicas e Metodologias

 Ferramentas

o MS Word – Elaboração dos Planos

o MS Project – Acompanhamento do Cronograma do Projeto

o COCOMO II - Usado para gerenciamento das métricas de forma geral.

o Tortoise SVN - Controle de versões de documentos e artefatos criados durante o projeto.

 Metodologias

o PDCA

A utilização do ciclo PDCA (Plan – Do- Check – Act) é usada para garantir a melhoria continua das atividades realizadas e consequentemente do produto final.

O PDCA é uma seqüência de atividades cíclica, onde: P (Plan – Planejar): Planejar o que será feito;

D (Do – Fazer): Tomar iniciativa sobre o planejado;

C (Check – Verificar): Analisar resultados obtidos continuamente e verificar se estão sendo executados de acordo com o planejado;

A (Act – Agir): Tomar ações corretivas caso necessário. o Programa de Qualidade 5 S’s

O programa de qualidade 5 S’s é um conjunto de técnicas japonesas que visam implantar um sistema de qualidade total. Os 5 S’s significam:

Seiri - Organização, utilização, liberação da área; Seiton - Ordem, arrumação;

Seiso - Limpeza;

Seiketsu - Padronização, asseio, saúde; Shitsuke - Disciplina, autodisciplina. o Reuniões de Scrum

Scrum é um método ágil para gerenciamento de projetos.

Breves reuniões diárias são realizadas aonde cada participante fala em pé sobre o progresso conseguido, o trabalho realizado, e se houver, fala também sobre o impedimento que tem em realizar seu trabalho.

Com essas reuniões conseguimos manter uma sintonia na equipe e trabalho sempre atualizado.

(14)

11. Gerenciamento de Configuração

Será utilizado o software Tortoise SVN para fazer o gerenciamento de configuração.

Sempre que existir a necessidade de incluir um documento no Tortoise SVN, deve ser inserida uma justificação que deixa claro qual a alteração feita no arquivo que foi alterado.

Os documentos gerados durante o projeto serão controlados por meio da ferramenta Tortoise SVN e estarão localizados no site http://projetointer2.wordpress.com/.

A nomenclatura dos documentos deverá obedecer a seguinte regra: NOME_DO_CRIADOR_NOME_DO_DOCUMENTO.DOC.

As baselines do projeto serão definidas no final de cada fase de Iniciação, Elaboração, Construção e Transição.

Todos os participantes do projeto podem fazer uma solicitação de mudança no sistema, porém somente o gerente do projeto pode autoriza - lá.

Os releases do projeto serão disponibilizados no site http://projetointer2.wordpress.com/.

12. Controles de Fornecedor e de Subcontratante

Na eventual utilização de fornecedores eles deverão se adequar aos padrões mínimos de qualidade exigido por esse documento.

13. Registros de Qualidade

Serão mantidos todos os documentos de Auditorias com seus checklist pelo período de 1 ano a contar da data de publicação do site na internet. Após esse período os mesmos serão reavaliados, buscando uma atualização dos status dos documentos e do próprio site.

Serão coletadas informações de tempo e esforço planejado x tempo e esforço realizado, para cada pessoa envolvida no projeto.

Essas informações ficaram armazenadas para servir como base histórica, podendo ser utilizada para estimar esforço e tempo em projetos futuros.

14. Treinamento

Aos técnicos e desenvolvedores do sistema:

 Os treinamentos nos processos e ferramentas necessárias serão ministrados para que toda a equipe do projeto fique no mesmo nível de conhecimento, e seja possível atender a todos os requisitos do Plano de Garantia de Qualidade.

Aos usuários do sistema:

 Será disponibilizado um manual do usuário para execução de todas as funcionalidades do software. Este manual será apresentado em duas partes:

o Para usuários já cadastrados, com informações da área interna (administração de perfil); o Para futuros usuários, com informações de como o software funciona e como poderá

passar a utilizar o mesmo.

15. Gerenciamento de Riscos

A seguir, será apresentada uma listagem de riscos que podem interferir no resultado final do projeto:

Risco Saída de um recurso da equipe durante o projeto

Importância Alta

(15)

andamento do mesmo, pois precisaremos exigir dos demais participantes um esforço maior enquanto um outro recurso não é encontrado.

Impactos Atraso no projeto e restante da equipe desmotivada.

Indicadores Podemos considerar como indicador a motivação da equipe no projeto. Em uma equipe motivada é muito mais raro a saída de um recurso.

Estratégia de diminuição Realizar encontros fora do expediente ou até mesmo aumentar o número de benefícios.

Plano de contingência Manter contatos com empresas de RH caso necessite

rapidamente de um recurso ou poder dar uma contraproposta ao funcionário para que fique pelo menos até o final do projeto.

Risco Exceder o prazo previsto

Descrição Assim que divulgamos ao cliente a data de entrega do projeto o mesmo já começa a divulgar o lançamento do site, portanto, entrega-lo dentro do prazo estipulado é um fato crucial no projeto.

Impactos Entregar o projeto fora do prazo pode prejudicar não só nosso cliente, mas também a nossa empresa que perde credibilidade.

Indicadores Acompanhar o desenvolvimento das fases no cronograma do projeto.

Estratégia de diminuição Procurar antecipar o maior número de atividades para não trabalhar em cima do prazo.

Plano de contingência Estender o prazo ou retirar itens requisitados.

Risco Exceder o orçamento previsto

Descrição Não extrapolar valores do projeto significa que conseguimos trabalhar com os recursos envolvidos do inicio ao fim, sem precisar envolver mais pessoas de última hora.

Impactos Perda de credibilidade com o cliente.

Indicadores Acompanhar o cronograma do projeto.

Estratégia de diminuição Deixar com que os recursos mais envolvidos se dediquem somente aos itens mais complexos, pois caso o orçamento estiver apertado poderemos substituí-los.

Plano de contingência Contratar recursos mais baratos como estagiários.

Risco Falta ou níveis diferentes de conhecimento da equipe

Importância Média

Descrição Caso a equipe tenha pouco conhecimento ou conhecimentos muito diferenciados o produto final é prejudicado. Os que sabem menos questionam os que sabem mais atrapalhando a

(16)

Impactos Atrasos no projeto.

Indicadores Fazer testes constantemente para analisar o nível de conhecimento dos integrantes.

Estratégia de diminuição Aplicar cursos e treinamentos de aperfeiçoamento.