ListEx4_DCF_Plano de Garantia da Qualidade

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

ITA – Instituto Tecnológico de Aeronáutica

Divisão de Ciência da Computação

Pós Graduação – PG EEC-I

Plano de Garantia da Qualidade

Dispositivo de Controle de Fraude – DCF

SETRAIF

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

Controle de Revisão

Rev. Autor Descrição Data

1.0 Fábio Kfouri Criação do Plano de Controle da Qualidade 26/10/2012 2.0 Fábio Kfouri Inclusão do Item de Subprodutos 28/10/2012 3.0 Fábio Kfouri Revisão das Referências Normativas 29/10/2012 4.0 Fábio Kfouri Revisão do processo de auditoria 16/11/2012

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

Sumário

4 Definições, Acrônimos e Abreviações ... 6

5 Subprodutos ... 7 6 Gerenciamento ... 8 6.1 Organização ... 8 6.2 Tarefas e Responsabilidades ... 8 6.3 Controle de Mudanças ... 9 6.4 Auditoria ... 9 7 Documentação ... 9 8 Métricas ... 10 9 Testes de Verificação ... 10 10 Validação de Produtos ... 10 11 Ação Corretiva ...11 12 Treinamento ...11 13 Gerenciamento de Riscos ...11

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

1 Prefácio

O Instituto Tecnológico de Aeronáutica – ITA e a empresa privada 2RP estabeleceram um contrato de pesquisa e desenvolvimento de Tecnologia, visando reduzir o tempo de identificação e constatação de fraudes, combater e corrigir falhas de controle de acesso e reduzir a possibilidade de novos prejuízos em transações financeiras.

Esta parceria culminou na criação do Projeto SETRAIF – Sistema Embarcado de Tempo Real para Repressão contra Acessos Indevidos e Fraudes, que visa criar um protótipo em meio acadêmico para ser avaliado pela empresa 2RP quanto sua adequabilidade, praticabilidade e aceitabilidade.

O Projeto SETRAIF foi dividido nos seguintes Subprodutos:  DCF – Dispositivo de Controle de Fraudes  DCA – Dispositivo de Controle de Acessos  DCN – Dispositivo de Comunicações na Nuvem  DMT – Dispositivo Móvel de Transações

Para a criação destes Subprodutos, foram criados grupos com alunos do ITA das seguintes matérias:

 CES63/CE235 – Sistemas Embarcados em Tempo Real  CE230 – Qualidade, Confiabilidade e Segurança de Software  CE237 – Tópicos Avançados em Teste de Software

Este Plano de Garantia de Qualidade foi elaborado pelo Grupo responsável pelo DCF – Dispositivo de Controle de Fraudes, concebido para ter a seguinte visão de produto:

“Para sistemas que necessitam verificar e legitimidade de uma transação eletrônica, o SCF, é um serviço que baseado no histórico comportamental do usuário e as principais fraudes de transação, identifica de forma rápida e confiável as transações suspeitas.”

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

2 Introdução

2.1 Objetivo

O propósito do Plano de Garantia de Qualidade é fornecer um ponto de referência único sobre qualidade para o projeto e assim, garantir que o software gerado estará de acordo com as Normas e requisitos do cliente.

2.2 Escopo

Este plano se aplica para o ciclo de desenvolvimento iterativo e incremental de um protótipo acadêmico, que garanta que os requisitos do projeto e do cliente estejam sendo atendidos em sua totalidade e de forma contínua, produzindo resultados de valor aos interessados.

São considerados também como produtos entregáveis, além do software (executável e fontes), seus manuais e mídias (incrementos produzidos nas Iterações/Sprint).

Neste plano não são abordados os critérios de validação de produto, a validação do Product Backlog, definição de pontos por estórias e definição de pronto.

2.3 Conformidade

Para processos ágeis, o principal produto a ser auditado, verificado e validado é o incremento de software potencialmente liberável, produzido a cada Iteração/Sprint. Este produto inclui não somente o software funcional e verificado, mas normalmente também seu código fonte, sua documentação e mídias, podendo sofrer variação conforme a definição de "Pronto" (Done) estabelecido pelo Scrum Team e PO.

Excepcionalmente em algumas Iterações/Sprints iniciais, o PO pode dispensar a documentação e/ou mídias, modificando este conceito de "Pronto" padrão - neste caso em que o produto deve ser analisado em conformidade com esta variação.

2.4 Limitações

Este plano trata-se de um artefato acadêmico de desenvolvimento ágil, e não pretende entrar em conflito com quaisquer conjuntos normativos existentes seja para desenvolvimento de software, seja para controle de fraudes.

3 Referências Normativas

 Norma: ABNT NBR ISO/IEC 9126-1:2003 - Qualidade de produto / Parte 1: Modelo de qualidade

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

 Norma: ABNT NBR ISO/IEC 12207:2009 - Processos de ciclo de vida de software.

 Norma: ABNT NBR ISO/IEC 25030:2008 - Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade.

 Norma: ISO/IEC TR 24772:2010 - Guidance to avoiding vulnerabilities in programming languages through language selection and use.

 PBL – SETRAIF Subproduto – DCF

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

 Defeito: Imperfeição, deformidade, mau funcionamento de um sistema.

 Iteração /Sprint : é a unidade básica de desenvolvimento em Scrum. Sprints tendem a durar entre uma semana e um mês, é um conjunto de esforços dentro de uma "caixa de tempo" (ou seja, restrito a uma duração específica) de comprimento constante, cujo objetivo é produzir um executável. Produzido para diminuir riscos e orientar o projeto para que seja liberado com sucesso.

 Product Backlog : é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo PO. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

 Product Owner (PO): é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. Responsável por realizar continuamente a validação durante os Sprints e nas reuniões formais de Sprint Review. O PO se compromete a não trazer novos requisitos para a equipe durante o Sprint.

 Scrum: é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil.

 Scrum Master: procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

 Sprint Backlog: é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo PO e a percepção da equipe sobre o tempo que será necessário para

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

completar as várias funcionalidades.

 Validação: Nesta área estão definidas as atividades de aceitações finais de um produto já verificado, normalmente realizadas pelo cliente (PO) e usuários finais (programas de validação) em seus diversos ambientes operacionais, conforme atributos definidos em artefatos do projeto (critérios de aceitação, tipicamente).

 Verificação: Nesta área estão definidas as atividades de averiguações e testes de diversas naturezas/aspectos sobre os produtos e sub-produtos, entrando em sua composição interna para verificar se estão corretos conforme atributos esperados definidos em artefatos do projeto (requisitos, tipicamente).

5 Subprodutos

São considerados Subprodutos todos aqueles artefatos produzidos durante o processo, desde a concepção de uma nova funcionalidade até sua concretização em um produto de software - e que não são entregáveis para o cliente. Eles são importantes para concepção do produto final, mas não são tratados como "produtos de primeira grandeza" e devem ser sempre auditados, verificados e validados como segunda prioridade:

 Theme Backlog (pilha de temas), criada pelo PO e validada pela Alta Gestão.

 Selected Backlog Proposto (segmento selecionado do Product Backlog, requisitos de maior granularidade), criada pelo PO e validada pelo Scrum Team

 Plano de Projeto, criado pelo PO e validado pelo Scrum Team

 Lista de Impedimentos, criado pelo Scrum Team rastreada para riscos e usada pelo Scrum Team e PO.

 Caso de Teste, criado pelo Scrum Team e testadores, rastreados para o Selected Backlog  Product/Release Backlog (Product Backlog como um todo, incluindo épicos), criada pelo PO

e elaborada pelo PO.

 Itens de Restrospectiva (WWW, WCBI), criados pelo PO e Scrum Team no Sprint Review  Modelos UML: Modelo conceitual para funcionalidades, criada pelo PO e refinada pelo Scrum

Team.

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

 Ativos Reutilizáveis - Componentes de Software, catalogados e atualizados pelo Grupo de Gerência de Reuso e utilizados pelo Scrum Team e PO.

 Problemas Recorrentes, catalogados e atualizados pelo Grupo de Reuso e utilizados pelo Scrum Team e PO.

 Base de Conhecimento, catalogados e atualizados pelo time de gestão do Conhecimento e utilizados pelo Scrum Team e PO.

 Matriz de Habilidades, mantida pelo Grupo de Gerência do Conhecimento e utilizada pelo Management, Scrum Team e PO.

Esses documentos devem ser armazenados na base de conhecimento do Scrum Team para efeito de rastreabilidade e registro. O registro por é aceitável desde que permita o mínimo de legibilidade.

6 Gerenciamento

6.1 Organização

Para garantir e manter o sistema de gerenciamento da qualidade do desenvolvimento do subproduto DCF do Setraif, os alunos do CE-230 assumirão a função de Time da Qualidade, que tem o objetivo de aferir Qualidade, Confiabilidade e Segurança do produto desenvolvido, garantir que os requistos do Cliente e os requisitos normativos estão sendo atendidos, e por fim, contribuir com o processo de desenvolvimento, para que o mesmo seja um ambiente criativo e ao mesmo tempo controlado.

6.2 Tarefas e Responsabilidades

O PO é o responsável por definir os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. Responsável por realizar continuamente a validação durante os Sprints e nas reuniões formais de Sprint Review. O PO se compromete a não trazer novos requisitos para a equipe durante o Sprint.

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O teste de software não deve ser realizado pelo mesma pessoa/time que foi responsável de desenvolvimento do mesmo.

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

interação/Sprint de produzir as tarefas definidas no Sprint Planning. Sempre que houver impedimentos e dificuldades com potencial de causar perturbação à continuidade e à qualidade do projeto, estas devem ser imediatamente externadas e discutidas com o Scrum Master e o PO.

6.3 Controle de Mudanças

Mudanças de requisitos de Produto devem ser avaliadas pelo PO, que terá a responsabilidade de programar junto com o Scrum Master para qual a Iteração/Sprint deverão ser aplicadas.

Todo o código gerado pelo Scrum Team deverão ser armazenados em repositório controlado e deverão ter informações de ratreabilidade quanto ao projeto, user story, iteração/sprint, descrição de mudança e o autor da modificação.

6.4 Auditoria

O time de desenvolvimento e os testadores devem garantir que o produto desenvolvido e o processo de desenvolvimento possam gerar atributos “externamente verificáveis” para que possam ser auditadas baseado em requisitos normativos e requisitos do cliente.

Como o time da qualidade não tem conhecimento dos atributos técnicos esperados pelo cliente, ela se limita a garantir que o "fluxo de trabalho" esteja sendo conduzido conforme o processo e gerando produtos de trabalho que possuem "sinais externos" conforme esperados pela documentação das auditorias.

Por sua vez, o processo deve buscar atributos que evidenciem, em uma auditoria, sinais de integridade e qualidade perceptíveis por um auditor leigo na tecnologia.

7 Documentação

Está seção lista a documentação mínima que servirá de base para o cumprimento deste plano são:

 Plano de Desenvolvimento de Software  Plano de Testes

 Termo de Confidencialidade  Modelo de Arquitetura UML  Road Map/Cronograma

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

8 Métricas

As métricas de produto, projeto e processo, que serão utilizadas, deverão ser coletadas ao longo do ciclo de desenvolvimento.

Para o desenvolvimento de software embarcado, serão considerados as métricas que estão disponíveis no IBM – Rational Test RealTime e no IBM – Rational Quality Architect.

9 Testes de Verificação

Os testes de verificação devem seguir as orientações específicas passadas pelo PO como critérios de aceitação ou aspectos de teste. Quando aspectos específicos não forem informados pelo PO, o Scrum Team pode assumir os seguintes aspectos padrões, em conformidade com cada item de Product Backlog:

 Sistema – Funcional (testes em novas funcionalidades – Caixa Preta)  Sistema – Usabilidade (testes de ergonomia, aspecto visual, mensagens)  Regressão – Funcional (para erros e manutenções evolutivas)

 Integração – Funcional (ponta a ponta, interface entre módulos)  Sistema – Documentação, Sistema - Instalação (mídia)

 Unitário (teste de lógicas e implementação de módulos)

 Aceitação (realizado por usuários chaves finais do sistema, simulação)

A prática de Test-Driven Design (TDD) e criação de testes unitários são desejáveis e devem ser aplicadas sempre que possível.

Os aspectos de "Aceitação" nunca são realizados pelo Scrum Team, sendo apenas possíveis de serem realizados com a presença do cliente (PO).

10 Validação de Produtos

As práticas de validação são fundamentais para a validação de incrementos de software potencialmente liberáveis (principal produto), pois estes devem ser aceitos a cada iteração. As práticas de validação deste principal produto são, portanto, aceleradas na linha de tempo do processo, para que aconteçam "tão breve quanto possível", conforme também ocorre com a verificação.

Documento: Plano de Garantida de Qualidade

Projeto: Dispositivo de Controle de Fraudes – DCF / SETRAIF

Revisão: 4.0

Ass.:

Data: 16/11/2012

Página

de

As atividades de validação são:

 Contínua: O PO é um representante dos clientes continuamente alocado no mesmo ambiente do Scrum Team, e deve ser acessado pelo Scrum Team sempre que uma antecipação de validação for julgada válida, principalmente nos casos de requisitos críticos, resolução de dúvidas e ou quando uma definição e necessária.

 Sprint Review: Nesta reunião, o Scrum Team apresenta na forma de "demo" cada funcionalidade ou trabalho técnico (refactoring, documentação, etc.) prometida no Sprint Planning, e pode ser instigada pelo PO a realizar cenários para comprovar o correto funcionamento, em conformidade com seus objetivos descritos nos critérios de aceitação resumidamente e complementados em conversas com toda a equipe.

 Ambiente de Quality Assurance: Disponibilizar um ambiente de validação para que o cliente possa realizar experimentos quanto a funcionalidade, simulação de ambiente multi-usuários e multi cenários.

11 Ação Corretiva

Ações corretivas devem ser tomadas com a finalidade de eliminar as Causas, bem como os Sintomas ou Efeitos Adversos dos Defeitos.

O Scrum Master deve identificar, monitorar e registrar os impedimentos levantados durante as reuniões diárias, podendo quando necessário acionar o PO para discutir/negociar sobre as próximas etapas do projeto.

Os defeitos identificados pelo cliente devem ser tratados primeiramente pelo PO e em seguida, internalizada ao Scrum Team. Neste caso deverão ser revistos os processos de verificação e validação.

12 Treinamento

Não Aplicável para o Plano de Garantia da Qualidade, por se tratar de um projeto acadêmico.

13 Gerenciamento de Riscos

O Gerenciamento de Riscos deve seguir as recomendações dos artefatos: Plano de Desenvolvimento e Plano de Gerenciamento de Riscos.