<Sistema Web>

Plano de Garantia de Qualidade

 

Versão <1.0>

 

 

Histórico da Revisão

Data	Versão	Descrição	Autor
27/08/2008	1.0	Primeira elaboração do plano de qualidade para sistemas Web de pequeno porte	Rafael Gomes Câmara

 

Índice Analítico

1.          Introdução         

1.1      Finalidade     

1.2      Escopo     

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

1.4      Referências     

1.5      Visão Geral     

2.          Objetivos de Qualidade     

3.          Gerenciamento       

3.1      Organização     

3.2      Tarefas e Responsabilidades     

4.          Documentação  

5.          Padrões e Guias     

6.          Métricas 

7.          Plano de Revisão e de Auditoria 

8.          Avaliação e Teste         

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

10.        Ferramentas, Técnicas e Metodologias

11.        Gerenciamento de Configuração

12.        Controles de Fornecedor e de Subcontratante         

13.        Registros de Qualidade         

14.        Treinamento

15.          Gerenciamento de Riscos

Plano de Garantia de Qualidade

 

1.                  Introdução

O plano de qualidade visa garantir que o software tenha um planejamento, avaliando pontos importantes no desenvolvimento e no produto desenvolvido.

1.1               Finalidade

Esse Plano tem a finalidade de garantir que o produto possa ser avaliado, e ter sua qualidade assegurada pela equipe desenvolvedora através de indicadores consistentes de qualidade.

1.2               Escopo

O escopo desse plano é avaliar a consistencia do software, verificando se ele está de acordo com as solicitações dos clientes. Além disso, é avaliado o precesso de desenvolvimento do software, para garantir que esse processo seja adequado para atender o tipo de software que será criado.

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

Abreviações existentes no documento e suas definições:

• RUP - Rational Unified Process

Métodologia de desenvolvimento de software sugerida pela Rational, para garantir um processo de qualidade na criação de um software. Possui vários artefatos para sugeridos para a utilização em todas as etapas de desenvolvimento, porém não é necessário a utilização de todas, apenas as que fazem sentido e gerem resultados para seu projeto.

• BUP - Basic Unifed Process

Uma versão enxuta do RUP criado pela IBM para a utilização de projetos pequenos, economizando o tempo que seria gasto ao análisar todos os artefatos e possibilidades do RUP, e avaliar quais seriam adequados para serem utilizados em um projeto pequeno.

• ISO - International Organization for Standardization

Organização Internacional presente em vários paises, com a finalizade de definir padrões a serem utilizados, facilitando assim a avaliação e comparação entre processos realizados entre as empresas.

1.4               Referências

Esse documento utilizou de padrões e templates apresentados nos seguintes documentos:

•          Plano de Métricas

•          Plano de Teste

•          Plano de Desenvolvimento de Software

1.5               Visão Geral

Esse documento esta estruturado para contemplar os seguintes tópicos:

• Objetivos de Qualidade (Itens que são considerados como principais para garantir a qualidade do software desenvolvido) ;
• Gerenciamento (Organização da equipe e da metodologia encarregada de avaliar a qualidade, e as tarefas e responsabildiades das partes envolvidas) ; Documentação (Todos os documentos necessários para a realização do projeto) ;
• Padrões e guias (Normas que deveram ser adotadas no projeto) ;
• Métricas (Caracteristicas que seão monitoras para gerar indicadores de qualidade) ;
• Plano de revisão e de autoria (Modo como a revisão de programação, recursos e procedimentos devem ser conduzida) ;

Depois serão realizados a avalição e testes, resolução de problemas e outras informações sobre o projeto.

2.                  Objetivos de Qualidade

De acordo com a certificação ISO 9001:2000 a Qualidade do Software deve atender:

Por se tratar de um projeto de menor escala, os pontos comentados acima serão buscados em menor escala, evitando que se tenha desperdicio de tempo em procedimentos muito detalhados.

3.                  Gerenciamento

3.1               Organização

A organização da equipe será da seguinte maneira: Lider de Projeto: Responsável por coordenar as atividades de todos, e alinhamento de informações entre o cliente e a equipe.
Analista de Negócio: Realizará toda a documentação necessária para o desenvolvimento do software.
Analista/Desenvolvedor: Será responsável pelo controle de qualidade e desenvolvimentos dos testes necessários.
Desenvolvedor/Tester: Codificará o projeto e realizará os testes criados pelo arquiteto de software

3.2               Tarefas e Responsabilidades

Periodicamente irão ocorrer revisões do projeto com o cliente, para alinhar o avanço do projeto, e possiveis alterações no escopo.
Dentro da equipe serão realizadas o controle de etapas exigidas no processo, certificando de que todos estão seguindo o planejamento. Reviões serão feitas do processo sempre que surgirem questionamentos e dúvidas no "por quê" da realização de alguns passos, e para novas sugestões de alterações.

4.                  Documentação

Para o desenvolvimento do software alguns documentos são exigidos, para que seja possível manter a qualidade exigida do software. A Especificação de Requisitos de Software precisa ser criada junto ao usuário, certificando em extrair as necessidades do usuário. Um plano de desenvolvimento de software deverá ser desenvolvido, deixando claro todas as etapas que a equipe irá passar para a criação do produto. O plano de testes também será exigido, para garantir o funcionamento das funcionalidades do produto quando este for entregue ao cliente.

5.                  Padrões e Guias

Será utilizado um guia de modelagem de caso de uso, para realizar, junto ao usuário, as funcionalidades do software que será desenvolvido. Um guia de interface do usário também será necessário, para assegurar que o produto tenha um qualidade e usuabiidade, atendendo as solicitações do usário. Para testar as funcionalidades do produto, um guia de testes será usado, certificando que todos os componentes necessários estarão funcionando como o esperado.

6.                  Métricas

Nome	Segurança ao acesso dos dados
Definição	Verifica se, através da url, é possivel executar códigos indevidos, e extrair informações restritas que existem no banco de dados
Metas	- É possivel inserir códigos na url para serem executados? - Existe um controle para proteger as informações restritas no banco? - Todos as medidas de segurança de acesso ao banco foram realizadas?
Procedimento de análise	Será avaliado se é possivel inserir códigos executaveis nas paginas Caso sim, avaliar o tipo de código que pode ser executado Verificar se a página vulnerável faz acesso ao banco de dados Contabilizar o número de páginas vulneráveis
Responsabilidades	Essa métrica será avaliada pelo Tester

Nome	Usabilidade
Definição	Avaliação se o produto possui uma interface clara e de fácil localização das funcionalidades pelo usuário
Metas	- Os nomes das funcionalidades estão claras e são as mesmas que foram definidas com o usuário? - A localização das funcionalidades está clara? - A interface está poluida ou com opções diferentes que aparentam ser ambiguas?
Procedimento de análise	Será avaliado a curva de aprendizado do usuário. Verificar a existência de nomes ambiguos, que causarem confusão ao usuário Análisar a execução completa de guias de usabilidade (Top ten guidelines for home page usability, Jakob Nielsen)
Responsabilidades	Essa métrica será avaliada Análista que está com maior contato com o usuário

Nome	Padrões Web
Definição	Avaliar se os padrões de criação de paginas definidos pelo w3schools está sendo utilizado, possibilitando assim a navegação em qualquer browser do mercado
Metas	- Os padrões foram seguidos e todas as páginas foram definidas corretamente? - Quantos browsers do mercado acessam a todas as funcionalidades e a interface está igual em todos?
Procedimento de análise	Utilizar ferramentas de análise de webpages, verifcando se padrões de código foram seguindos. Testar todas as páginas nos brownsers disponiveis no mercado, verificando se toda a interface está sendo visualiza corretamente e se todas as funcionalidades estão disponiveis
Responsabilidades	Essa métrica será avaliada pelo Tester

7.                  Plano de Revisão e de Auditoria

Será necessário um acompanhamento constante do trabalho desenvolvido, para que medidas corretivas sejam realizadas a tempo.

Algumas atividades passarão por uma revisão e algumas etapas do processo. Após o desenvolvimento de todos os requisitos, será feito uma análise para garantir que todos os pontos levantados com o usuário estão documentos, e certificar com o mesmo se as informações colhidas são aquelas que ele deseja ter no software. A programação das revisões com o usuário serão feitas sempre antes de iniciar o desenvolvimento do projeto, evitando chegar algum engano para os desenvolvedores. O lider de projetos será o responsável por essa tarefa.

Para os problemas que surgirem no meio do desenvolvimento, a equipe se reunirá para avaliar a gravidade do problema e discutir possiveis soluções. Em ultima instancia, uma reunião será realiaza com o usuario, reportando do problema encontrado, e será discutido se o prazo de entrega será adiado, ou se a funcionalidade com problema não seja disponibilizada, sugerindo assim uma segunda versão para o programa.

Para garantir um bom produto, todo o processo será acompanhado de perto, verificando se as técnicas e metodologias definidas então sendo cumpridas de maneira correta. As ferramentas utilizadas não precisam de um forte acompanhamento, apenas caso alguma funcionalidade que ela oferece que economize tempo e evite erros dos desenvolvedor não esteja sendo utilizada.

8.                  Avaliação e Teste

A cada funcionalidade desenvolvida, testes serão realizados para garantir que os requisitos foram atendidos. Em cada finalização será utilizada as técnicas de teste de caixa braca ou preta, de acordo com o tipo de componete que terminou seu desenvolvimento. A avaliação do componente testado definirá se o projeto continuará com as atividades previstas, ou se revisões no cornograma/escopo/orçamento serão necessárias para a continuação do trabalho.

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

Os problemas encontrado serão avaliados, analisando seu impacto e complexidade, e junto ao usuário será definido se, para resolver um problema complexo, o prazo será adiado, ou se o projeto seja entregue sem a funcionalidade afetada. Assim uma nova versão do projeto ser;a discutida e analisada, para que a funcionalidade ausente seja entregue como estava nos planos inicias do desenvolvimento do projeto.

10.             Ferramentas, Técnicas e Metodologias

• Ferramentas Utilizadas:

• Tecnicas:

• Metodologias

11.             Gerenciamento de Configuração

Por ser tratar de um projeto pequeno, não haverá um grande mudança de configuração no mesmo, sendo que esse controle pode ser realizado basicamente pelo lider do projeto, de maneira simples e discreta.

12.             Controles de Fornecedor e de Subcontratante

Esse item não se aplica nesse plano de qualidade pois o software esta sendo desenvolvido sem ajuda de terceiros, tendo já um própio servidor web, com o banco de dados e as licensas necessárias.

13.             Registros de Qualidade

Será util manter os registro de qualidade do software durante todo o projeto, para que seja possível avaliar se todo o processo de desenvolvimento está seguindo o padrão necessário para garantir a qualidade do software. Registros dos momentos em que os requisitos são adquiridos do usuário, e transmitidos para os desenvolvedores é o primeiro ponto chave. O segundo é a transição entre o desenvolvimento e o inicio dos testes.

14.             Treinamento

Nenhum treinamento será necessário, pois a equipe possui o conhecimento exigido para a realização de um projeto de interface Web, com comunicação com banco de dados em soluções Microsfot (.NET e SQL Server).

15.             Gerenciamento de Riscos

O risco que deve ser controlado de perto no desenvolvimento do projeto é o estouro de orçamento. Caso o planejamento não seja seguido, pode-se gastar tempo e dinheiro refazendo funcionalidades do software, que só serão notadas na fase de teste, exigindo assim um grande esforço e talvez a necessidade de a contratação de um novo recurso para ajudar na correções de erros comeditos devido a neguigencias do processo de desenvolvimento. Outro riscos técnicos não são preocupantes pela razão que o software ficará em um ambiente já conhecido pela equipe, cortando o risco de problemas que aparecem somente no ambiente em que o cliente utilizará o software.