SolarSex

1. Introdução
1. Finalidade
2. Escopo
3. Definições, Acrônimos e Abreviações
4. Referências
5. Visão Geral 
   
2. Objetivos de Qualidade
3. Gerenciamento
1. Organização
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

(confira também o relatorio gerado referente a essa atividade)

1.  Introdução

O Projeto SolarSex é um projeto diferente. Ele visa comparar dados de explosões solares com o comportamento sexual humano, afim de extrarir alguma afirmação científica do primeiro evento no segundo.

Para tornar esse desafio um grande triunfo, deve-se primar pela qualidade do desenvolvimento, pois se trata de uma aplicação que busca uma inferência científica.

Ao longo deste documento, ficaremos a par de todos mecanismos que julgamos essenciais utilizar para assegurar a qualidade desejada ao longo do projeto.

1.1  Finalidade

Esse Plano de Garantia tem como objetivo assegurar a qualidade do Projeto SolarSex, através de dispositivos em tempo de produção, de teste e treinamentos para melhor performance da equipe de usuários, de forma a alcançar o objetivo principal.

Seguindo os passos descritos ao longo do documento, alançar-se-á um nível mínimo de qualidade para que o mesmo possa ser aceito no mercado.

1.2  Escopo

O projeto SolarSex tem como objetivo fazer o estudo científico do comportamento sexual do ser-humano com a influência da radiação solar. Os dados serão provindos da [colocar o nome] 

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

• SolarSex: Sistema para controle de Serviços Gráficos
  

1.4  Referências

• Plano de Documentação
• Plano de Métricas
• Plano de Teste
• Plano de Desenvolvimento de Software
• Plano de Resolução de Problemas
• Plano de Gerenciamento de Configuração
• Plano de Gerenciamento de Subcontratantes
• Plano de Gerenciamento de Riscos

1.5  Visão Geral

Ao longo do Plano, vamos mostrar quais são nossos Objetivos de Qualidade, que norteiam nosso planejamento, junto com o planejamento da Documentação, os Padrões que pretendemos seguir e seus respectivas guias para alcançar a implementação dos padrões.

Para podermos medir o desempenho também de forma quantitativa, também proporemos um plano de Métricas para medir a qualidade geral do produto. Como precisamos sempre verificar se nossas metas estão sendo alcançadas, temos também a proposta de Revisão e Auditoria para ser aplicada ao longo do desenvolvimento, assim como planos de avaliação e teste, aplicados tanto pela equipe como pelos clientes e usuários. e já pensando nesse último grupo,visando melhorar ainda mais a Ssatisfação dos clientes SolarSex, propomos um plano de ação para Resolução de Problemas e Ações corretivas.

Iremos fazer um briefing sobre as Ferramentas e Metodologias aplicadas no projeto, seu Gerenciamento de Configurações, Controles de Fornecedor e de Subcontratante, Registros de Qualidade, Treinamento e Gerenciamento de Riscos.

Assim, previmos ter coberto o necessário para assegurar a qualidade de nosso produto e a satisfação de nosso clientes.

2.  Objetivos de Qualidade

Nosso objetivo principal é atender os Requisitos de Software especificados ao longo das reuniões com nosso cliente, e também atingir um nível de Satisfação do Cliente, de forma a garantir laços de confiança entre ambas as partes.

Assim, temos como Requisitos principais a serem atendidos:

• Nossos clientes precisam de um sistema online para controle dos arquivos que os clientes enviam para impressão, que permita saber exatamente quais arquivos devem ser impressos, em quais materiais, quantidades e tamanhos requisitados diretamente pelo cliente
• Ter um controle dos pedidos de forma que o sistema possa funcionar igualmente em qualquer horário, de forma autônoma. O cliente deve poder enviar arquivos do tipo .CDR, .PSD, .JPG, .PNG, .ZIP independente das máquinas da empresa estarem ligadas. A Solução é uma aplicação alocada num servidor na Internet.
• Cada pedido deverá ter seus dados coletados, e seja guiado dentro de um workflow que possibilite rastrear o status de cada pedido apenas informando o código do mesmo, e que tanto do lado da empresa quanto do cliente possa ser feito o rastreamento.
• Existem diversos níveis dentro da hierarquia das empresas, então o sistema deve ter um controle de permissões a nível de usuário, editável pela administração da empresa.

E uma série de sub-requisitos decorrente da expansão desses acima. Para conferir todos, confira esse outro documento: Especificação de Requisitos de Software.

3.   Gerenciamento

3.1  Organização

• Gerente de Projeto: Gutenberg Alves dos Santos
• Analista e Arquiteto de Software: Cicero Lourenço
• Desenvolvedor: Paulo Papoy
• Tester: Ismael Lopes Rodrigues
• Responsável pelo Controle de Qualidade: Thomas J. Lopes
• Avaliadores: Marcelo Honório, Rafael Rocha, Danilo Oliveira
  
• Avaliadores clientes: -- (não conhecidos ainda)
  

3.2  Tarefas e Responsabilidades

Revisões conjuntas: serão realizadas pela equipe completa quinzenalmente, tendo como responsável o Gerente de Projeto nomeado. Revisões nas equipes específicas serão feitas quando a equipe julgar necessário, com frequência mínima quinzenal, realizadas por membro nomeado pela própria equipe. Revisões junto ao cliente serão realizadas a cada entrega/ciclo concluído, guiadas pela equipe de avaliadores clientes.

Auditorias de Processo: o processo será auditado regularmente pelo Gerente de Projeto, e sua frequência será definida pelo mesmo durante seu andamento. Poderão ocorrer auditorias a qualquer momento.

Revisões de Processo: Revisões de Processo serão agendadas junto ao Gerente e Analistas, sempre que necessário, logo após o processo de Auditoria.

Auditorias do Cliente: o cliente poderá solicitar uma auditoria do projeto quando julgar necessário, e a data para o mesmo (caso se faça necessária uma auditoria presencial) será decidida pelo Gerente de comum acordo com o restante da equipe. O gerente de Projetos se encarregará de auditar os processos do cliente, tomando o devido cuidado para que o mesmo não se exceda em algum passo no andamento do projeto.

4.  Documentação

Toda a documentação do projeto será organizada e compilada pelo Gerente do Projeto e Analistas, em paralelo com o Projeto. Porém, já definimos aqui que o conjunto mínimo de documentação necessária será composto de:

• Plano de Desenvolvimento de Software
• Plano de Testes
• Plano de Iteração
• Especificação de Requisitos de Software
• Documento de Arquitetura de Software
• Documentação do usuário (Manual, FAQs e tutoriais)
• Plano de Gerenciamento de Configuração

Vide o Plano de Documentação para maiores detalhes, e também o Caso de Desenvolvimento

5.  Padrões e Guias

• Guia de caso de desenvolvimento:  Utilizando as guias de desenvolvido para ambiente .NET, Microsoft.
  
• Guia de Modelagem de negócio: utilizar cartões CRC para colher a primeira modelagem de negócio com os possíveis clientes. A seguir, utilizar diagramas IDEF0 para detalhar processos, ferramentas.
• Guia de Interface do usuário: para alcançar a interface ideal ao sistema, devemos criar protótipos em papel no primeiro nível, janelas fake navegáveis no segundo e protótipos usáveis no terceiro. A interface deve ser web-compliant e adaptada ao máximo para os padrões de acessibilidade básicos. Seguir as recomendações W3C para o design das páginas de interface e navegação, além de garantir que a solução funcione nos browser comerciais de maior visibilidade: Mozila Firefox, Internet Explore, Opera e Google Chrome. Pode ser utilizado flash, desde que não comprometa a acessibilidade do portal.
• Guia de modelagem de Caso de Uso: os casos de uso devem seguir o seguinte padrão:
  (aqui padrão caso de uso)
• Guia de Design: a aplicação deve seguir o padrão MVC: Model view controller, a fim de garantir a separação entre lógica, dados e interface. Isso permitirá que equipes separadas trabalhem esses três aspectos, tornando a manutenção do sistema mais fácil e rápida, além de permitir um alto grau de reusabilidade (o que é desejado alcançar como um objetivo secundário).
• Guia de programação: Utilizar as guias de programação da comunidade de desenvolvedores da plataforma .NET / Microsoft
  
• Guia de Testes: os testes deverão partir dos requisitos, e voltados principalmente para a satisfação do cliente nos aspectos: funcionalidade, praticidade e Segurança. Todos os testes devem ter um nome identificadore único, uma data limite para ser executado, a data da execução, um executor, um ou mais valor(es) de entrada previstos, e o(s) respectivo(s) valor(es) de saída. Toda essa informação deve estar disponível caso o cliente deseje solicitar.
• Manual de Guia de Estilo: utilizar o manual de estilo .NET / Microsoft.
  

6.  Métricas

As métricas servem para estimar valores, tempo e recursos para as tarefas do sistema. Essa estimativa pode ser usada em diversas finalidades, por exemplo: ao vender e projetar novos sistemas. Também serve para acompanhar a saúde do mesmo, se estipulado marcos e valores-base para isso. Iremos utilizar, inicialmente, as seguintes métricas nesse projeto:

Nome: Quantidade de casos de uso / semana.
Definição: Mede a quantidade de casos de uso implementados por semana.
Metas: Estipular quantos casos de uso a equipe consegue cumprir num prazo de tempo.
Procedimento de Coleta: Cada desenvolvedor marca os casos de uso como implementado, e o sistema de tracking fará a contagem por recurso.
Responsabilidades: Cada recurso deverá marcar a conclusão correta de cada implementação, e o sistema fará a contabilização

Nome: Contatos com o cliente / semana
Definição: Mede a quantidade de contatos necessários com o cliente por semana para
resolver questões não esclarecidas em algum passo do projeto.
Metas: Estipular se os processos de aquisição de requisitos estão satisfatórios.
Procedimento de Coleta: Cada contato com o cliente deve ser feito através dos meios estipulados entre ambas as partes, para que possam ser contabilizados.
Responsabilidades: o sistema fará a contabilização caso o passo anterior seja corretamente seguido.

Nome: Quantidade de artefatos entregues
Definição: Mede a quantidade de artefatos entregues ao cliente.
Metas: Quantificar a quantidade de entregas feitas a clientes por projeto.
Procedimento de Coleta/Responsabilidades: Cada entrega deve ser contabilizada pelo Gerente do Projeto.

Nome: Quantidade de linha de código
Definição: Mede a quantidade de linhas de código do projeto
Metas: Quantificar a quantidade de linhas de código para estimar horas de trabalho em futuros projetos/artefatos do mesmo. Também pode ser utilizado para estimar o Utilization de cada recurso do time.
Procedimento de Coleta/Responsabilidades: O Gerente de Projeto usurá softwares para automatizar o processo ao final do mesmo.

Nome: Feedback do Cliente
Definição: Soma os scores de feedback do cliente
Metas: Quantificar a satisfação do cliente em tempo de desenvolvimento
Procedimento de Coleta: O Cliente deve, a cada avaliação, informar uma nota sobre o resultado avaliado.
Responsabilidades: o Gerente do Projeto deve garantir que a cada avaliação seja requisitada a quantificação da satisfação do cliente.

Para mais detalhes, confira o Plano de Métricas

7. Plano de Revisão e de Auditoria

Tarefas de Revisão e de Auditoria
Serão revisados os casos de uso junto ao cliente antes da fase de desenvolvimento, de forma a assegurar que todas as funcionalidades e requisitos foram atendidos.

Antes da fase de implementação, os analistas se unirão aos desenvolvedores para revisar o plano de desenvolvimento, e com uma breve consulta aos casos de uso, verificar se os requisitos continuam sendo atendidos.

Revisões de Design devem ser agendadas com o cliente, assim que sejam possíveis realizá-las, pensando no quesito interface/navegabilidade.

Revisões Gerenciais serão realizadas a cada marco do projeto. Os marcos principais são cada uma das entregas feitas ao cliente, dos módulos que estiverem prontos a serem utilizados. Revisões e Auditorias de Processo serão realizadas sempre que o cliente ou a equipe julgarem necessário, bastando agendar previamente com o Gerente do Projeto , que alinhará com a equipe.

Programação
Revisão de Casos de Uso: Uma semana antes do começo do desenvolvimento
Revisão de Desenvolvimento: uma semana após a fase de desenvolvimento estar concluída.
Revisões

Organização e Responsabilidades
Cada revisão será realizada/encabeçada pelo Analista responsável pelo Módulo/Step, ou pelo Gerente de Projeto. Em alguns casos, o cliente poderá realizar essa tarefa, ou indicar alguém para.

Resolução de Problemas e Ação Corretiva
Cada problema detectado nas revisões e/ou Auditoria deverá ser comunicada ao Gerente de Projeto, que se encarregará de tomar as ações necessárias. Na maioria dos casos, um retorno ao plano de Requisitos será suficiente, e quando não, uma reunião com o Cliente poderá ser agendada para desmistificar o assunto ou renegociar requisitos.

8.  Avaliação e Teste

Os testes previstos devem ser executados seguindo seu planejamento. Cada marco prevê uma entrega ao cliente, e para que essa entrega seja feita, os testes relacionados devem estar completos, documentados e acessíveis ao cliente. A cada entrega, haverá os testes de Caixa Preta previstos em tempo de requisitos.

Caso os testes ainda estejam incompletos devido a bugs não solucionados, o Gerente de Projeto deve ser comunicado, para que tome uma ação ou tente uma renegociação com o cliente.

Para maiores detalhes, confira o Plano de Desenvolvimento de Software, seção Plano de Avaliação e também o Plano de Teste.

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

Cada problema, seja em tempo de projeto ou de implementação/instalação, deve ser reportada através das ferramentas corretas ao Gerente do Projeto, para que o mesmo possa tomar as ações de coleta de métricas e aplicar Ações Corretivas. Algumas delas já estarão listadas junto a documentação de cada entrega/marco/módulo, então, junto ao procedimento anterior, procure referência na documentação.

Para maiores detalhes, confira o Plano de Resolução de Problemas

10.  Ferramentas, Técnicas e Metodologias

Ferramentas Utilizadas:
LAMP (Linux Apache, MySQL e PHP)
Eclipse SDK junto com Aptana PHP
CakePHP para implementar MVC
EXT JS para interface
Site www.thlopes.com para gestão da informação
OpenProj para gerencia do Projeto
Horde suite para comunicação e colaboração entre as equipes.

Técnicas:
Design MVC
Testes de Caixa Preta
Testes de Caixa Branca
Programação XP

Metodologias:
BUP: Basic Unified Process, baseado no RUP. Seu objetivo é utilizar da definição do RUP de como desenvolver um software, porém de um modo mais enxuto para projetos pequenos. Assim é possivel garantir as principais caracteristicas definidas no RUP de um modo mais eficiente para pequenos projetos.

11.  Gerenciamento de Configuração

As configurações do projeto estarão listadas na documentação do projeto em www.thlopes.com. Antes de cada etapa, o Gerente de Projeto irá definir a configuração necessária para cada cargo relacionado, de acordo com ambas as partes. Deve-se evitar ao máximo alterações nessa configuração para que seja mantido o nível de qualidade desejado, mas caso seja realmente necessário aplicar qualquer mudança, essa deve ser acordado junto ao Gerente do Projeto.

Confira mais detalhes no Plano de Gerenciamento de Configuração.

12.  Controles de Fornecedor e de Subcontratante

[Esta seção ainda não se aplica ao projeto]

13.  Registros de Qualidade

Todos os registros produzidos através dos processos listados neste plano estão disponiveis  documentados no site www.thlopes.com e no site do grupo do projeto http://codigo8.com.br/senac/projeto/objetivo.php na seção exclusiva destinada ao projeto. É importante manter registros de qualidade para que possam ser analisados novas propostas do cliente, e também para apresentar em propostas de novos projetos.

14.  Treinamento

Caso se faça necessário, tanto o cliente como a equipe do projeto poderá solicitar Treinamentos para o Gerente do Projeto. Esse irá analisar a relevância do mesmo ao projeto, de forma a alinhar as necessidades de ambas as partes com os recursos disponíveis. O projeto se dara no crusamento de dados proveniente de dois sistemas já esistentes. Os dados são referentes ao indice de radiação solar, e o número de acessos a um site de conteudo adulto. Logo a equipe, de inicio deve realizar treinamentos basicos em oracle para conseguir tratar de maneira correta os dados, e terem conhecimento dos ambientes de desenvolvimento.

O projeto será desenvolvido em asp.NET, logo deverá ser ministrado um curso básico desta linguagem, para capacitar a equipe de desenvolvimento à implementar o projeto com eficácia.

Após a implantação do sistema, será agendado junto ao usuário e o pessoal da equipe um Treinamento  da ferramenta, e esse será ministrado por membros da própria equipe, porém devemos lembrar que o cliente deve ter uma participação já nos testes para uma possivel solicitação de mudança de especificação.

15. Gerenciamento de Riscos

A seguir, alguns riscos aos quais o projeto SolarSex está exposto:

• Clientes solicitarem modificação nos requisitos: Após a implantação do sistema quando for ministrado o treinamento de utilização da ferramenta o cliente pode pedir para modificar algum requisito. Para isso pretendemos fazer com que o cliente participe da faze de teste para possibilitar que o cliente descubra alguma alteração nescessária antes da implantação. Caso mesmo assim ocorra deve-se estipular um novo prazo para a realização da modificação.

• Limitações do servidor: Devemos ter em mente que teremos um número muito alto de dados, devemos possivelmente limitar um periodo de tempo para análise para de certa forma haver um limite no número de dados a serem crusados.

Comentarios (0)

RSS feed Comments

Nome

Email

Website

Titulo

Comentario

Escreva os caracteres mostrados

Adicionar Comentario