MINISTÉRIO DA AERONÁUTICA
DEPARTAMENTO DE PESQUISAS E DESENVOLVIMENTO
CENTRO TÉCNICO AEROESPACIAL
Instituto Tecnológico de Aeronáutica
Programa de Pós-Graduação em
Engenharia Eletrônica e Computação - Informática
CE-230 - Qualidade, Confiabilidade e Segurança (Safety) de Software
Professor Doutor Adilson Marques da Cunha
Anexo I – Plano de Garantia de Qualidade
Roberto Pepato Mellado
Índice
1
Anexo I – Plano de Garantia da Qualidade ... 3
1.1
Papéis e Responsabilidades ... 4
1.2
Documentação ... 4
1.3
Padrões e Guias ... 5
1.4
Métricas ... 5
1.5
Plano de Revisão e de Auditoria ... 7
1.6
Avaliação e Teste ... 8
1.7
Resolução de Problemas e Ação Corretiva ... 8
1.8
Ferramentas, Técnicas e Metodologias ... 8
1.9
Gerenciamento de Configuração ... 9
1.10
Registros de Qualidade ... 9
1.11
Treinamento ... 10
1 Anexo I – Plano de Garantia da Qualidade
O plano de garantia de qualidade visa garantir que o projeto de desenvolvimento de software tenha um planejamento, avaliando pontos importantes no desenvolvimento e no produto desenvolvido. 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.
O escopo desse plano é avaliar a consistência do software, verificando se ele está de acordo com as solicitações dos clientes. No modelo de execução proposto, esse objetivo deve ser atingido da através de entregas constantes e incrementais, conforme indicado pelas melhores práticas oriundas do desenvolvimento ágil. Além disso, sistemicamente é avaliado o processo de desenvolvimento do software como um todo, para garantir que esse processo seja adequado para atender o tipo de software que será criado, focando o aspecto de adaptação, outro pilar do desenvolvimento ágil.
Esse anexo está estruturado para contemplar os seguintes tópicos:
• Objetivos de Qualidade;
• Gerenciamento, Organização da equipe e da metodologia encarregada de avaliar a
qualidade, e as tarefas e responsabilidades das partes envolvidas;
• Documentação;
• Padrões e guias (Normas que deveram ser adotadas no projeto) ; • Métricas;
De acordo com a certificação ISO 9001:2000 a Qualidade do Software deve atender:
1. Melhor planejamento e controle das rotinas de trabalho, eliminando passos desnecessários. 2. Padronização das tarefas e definição de responsabilidades, para maior segurança e agilidade aos trabalhos.
3. Criação de um Sistema de Controle para identificação e tratamento das anomalias verificadas durante o processo, evitando retrabalhos.
4. Realização dos trabalhos buscando melhorias na qualidade e aumento da satisfação dos clientes.
Considerando a aplicação de métodos ágeis, os pontos comentados acima serão buscados através da maneira mais simples e objetiva possível, evitando que se tenha desperdício de tempo em procedimentos muito detalhados, afim de ter uma adaptabilidade constante sobre as mudanças solicitadas pelo cliente e acordadas com o time. Isso faz com que o desenvolvimento
ágil seja feito de maneira eficiente e adaptativa.
1.1 Papéis e Responsabilidades
A organização da do sistema SSG – Sistema de Smart Grids está estruturada através dos seguintes papéis:
Scrum Master: Responsável por promover o entendimento mútuo sobre o processo, facilitar a comunicação do time e remover os impedimentos encontrados na realização dos trabalhos; ProductOnwer: Responsável pelo alinhamento de informações entre o cliente e a equipe. É o direcionador do trabalho que deve ser realizado no projeto para que o produto resultante seja considerado como um produto de sucesso. Deverá prover toda a documentação e
entendimentos necessários para que o time possa desenvolver o produto de software.
Tester: Responsável pelo desenvolvimento, execução e divulgação dos resultados dos testes realizados, com o intuito de validar a qualidade (conformidade com os requisitos) do produto construído;
Auditor de Qualidade e Confiabilidade: Será responsável pela aferição e controle de qualidade, reportando inconsistências quando necessário e indicando sugestões de aplicação de melhores práticas para maximização dos resultados.
Periodicamente irão ocorrer revisões do projeto com o cliente, para alinhar o avanço do projeto. Nestas reuniões, é esperado que sejam solicitadas possíveis alterações no escopo do projeto. O projeto, estruturado para execução através de técnicas de desenvolvimento ágil, necessita ser pró-ativo e responsivo à mudanças para que o cliente tenha condição de refinar o software da
melhor maneira a lhe entregar valor.
Dentro da equipe do projeto serão realizadas interações semanais, para que seja possível o entendimento e consequente certifição de que todos estão seguindo o acordado com o cliente durante as reuniões, e que a meta de sprint é compreendida e perseguida por todos como um grupo, e não somente em ações individuais desconexas. Revisões do processo serão feitas sempre que surgirem questionamentos e dúvidas no "por quê" da realização de alguns passos, e para novas sugestões de alterações a fim de adaptar o processo de uma maneira que satisfaça o time e o cliente.
Para o desenvolvimento deste produto de software, alguns documentos são exigidos, para que seja possível manter a qualidade. As user stories foram criadas em ricas sessões de comunicação junto ao cliente, visando extrair as necessidades do usuário para que o cliente pudesse se sentir satisfeito e complacente com o que o time irá produzir. Um documento de visão foi desenvolvido, deixando claro todas as etapas que a equipe pretende seguir 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.
1.3 Padrões e Guias
Para desenvolvimento deste produto de software, foi utilizado o guia do framework de processo SCRUM, para realizar junto ao cliente o levantamento e gerenciamento das user stories ou seja, das funcionalidades do software que será desenvolvido. Um guia de interface do usuário também será necessário, para assegurar que o produto tenha qualidade e usabilidade, atendendo as expectativas do cliente. Para testar as funcionalidades do produto, um guia de testes ágil será utilizado, certificando que todos os componentes necessários estarão funcionando como o esperado.
1.4 Métricas
Nome
Complexidade Ciclomática ou V(g)
Definição
Número de caminhos distintos possíveis de execução por um módulo de código.
Metas
Estar dentro do intervalo de 1 a 10
Procedimento de
análise
Utilizar ferramenta de apoio Rational Test Real Time (RTRT) para aplicação no código fonte do produto e extração de métricas
Responsabilidades
Nome
Nível de instruções aninhadas
Definição
Nível de aninhamento de blocos de código.
Metas
O nível máximo de aninhamento deve ser inferior a 4 para qualquer método de uma classe
Procedimento de
análise
Utilizar ferramenta de apoio Rational Test Real Time (RTRT) para aplicação no código fonte do produto e extração de métricas
Responsabilidades
Essa métrica deverá ser avaliada pelo auditor da qualidade
Nome
Linhas de Código
Definição
Número de linhas de código em um método ou classe, excluindo linhas de comentários e linhas em branco
Metas
Máximo de 40 linhas para elementos do tipo método e 300 linhas para elementos do tipo classe
Procedimento de
análise
Utilizar ferramenta de apoio Rational Test Real Time (RTRT) para aplicação no código fonte do produto e extração de métricas
Responsabilidades
Nome
Chamadas à componentes externos
Definição
Número de componentes externos à uma determinada classe utilizados por um elemento de código da classe
Metas
Máximo de 5 componentes
Procedimento de
análise
Utilizar ferramenta de apoio Rational Test Real Time (RTRT) para aplicação no código fonte do produto e extração de métricas
Responsabilidades
Essa métrica deverá ser avaliada pelo auditor da qualidade
1.5 Plano de Revisão e de Auditoria
Será necessário um acompanhamento constante do trabalho desenvolvido pelo time,
para que medidas corretivas sejam realizadas a tempo e a mudanças possam ser
aplicadas sem que haja maior impacto no projeto.
Algumas atividades e etapas do processo passarão por revisões afim de propiciar uma
evolução ao software. Após o desenvolvimento de todas as user stories, será realizada
uma análise para garantir que todos os pontos levantados com o cliente estejam
documentados afim de propiciar o melhor entendimento do valor entregue para o cliente,
além de validar 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 cliente será feita sempre antes de
iniciar uma nova Sprint Developement, evitando que informações incorretas sejam
direcionadas para os desenvolvedores. O P.O será o responsável pela realização dessa
tarefa.
Para os problemas que surgirem no meio do desenvolvimento, a equipe se reunirá para
avaliar a gravidade do problema e discutir possíveis soluções. Em última instancia, uma
reunião será realiza com o cliente, reportando o problema encontrado, e será discutido
um novo sprint, ou ajustes no sprint para que a funcionalidade com problema não seja
disponibilizada, ou então que tenha seu escopo reduzido, sugerindo assim uma
segunda versão do software.
Para garantir a qualidade do produto de software, todo o processo será acompanhado
de perto pelo time e pelo cliente, verificando se as técnicas e metodologias ágeis
definidas então sendo cumpridas de maneira correta e satisfatória.
1.6 Avaliação e Teste
A cada user story desenvolvida, testes serão realizados para garantir que os requisitos
foram atendidos e para que o time possa ter o feedback o mais rápido possível. Para
que novas funcionalidades não irão regredir o sistema, serão utilizadas técnicas de
testes automatizados, adequados ao tipo de componente objeto de teste, replicáveis e
re-executados de forma completa a cada novo ciclo de testes. A avaliação do resultado
do teste aplicado sobre o componente testado definirá se o projeto continuará com a
sprint prevista, ou se revisões no planejamento serão realizadas com o cliente e o time.
1.7 Resolução de Problemas e Ação Corretiva
Os problemas encontrado serão avaliados, terão seu impacto e complexidade
estimados, e uma ação junto ao cliente será disparada para definir se para resolver um
problema complexo, a sprint será adiada, ou se o projeto será entregue sem a user story
afetada. Neste último caso, uma nova versão do projeto será discutida e analisada, para
que a user story ausente seja entregue.
1.8 Ferramentas, Técnicas e Metodologias
Para construção do produto de software objeto deste projeto acadêmico, o seguinte conjunto de ferramentas, técnicas e metodologias foi originalmente definido:
• Ferramentas Utilizadas para Desenvolvimento e Testes: o Rational Rose Real Time
o Rational Test Real Time
• Ferramentas Utilizadas para Aferição da Qualidade o Rational Quality Architect;
o Rational Test Real Time;
• Ferramentas para Relatórios ou Registros de Evidência o Microsoft Word ou similar;
o Microsoft Excel ou similar;
o Acrobat Reader ou similar; • Gestão de configuração
o Subversion ou similar;
• Técnicas aplicadas:
o Desenvolvimento através de modelos, usando o paradigma MDA;
o Testes automatizados;
o Burndown Charting; o Planning Poker;
• Metodologias / Frameworks
o SCRUM – framework de processo de desenvolvimento iterativo e incremental
para gerenciamento de projetos e desenvolvimento ágil de software
1.9 Gerenciamento de Configuração
O ambiente de execução do produto de software gerado por este projeto é conhecido e
estável, de ampla utilização e baseado em plataforma de hardware x86. Desta forma,
não são esperadas alterações na plataforma de hardware. A gestão de configuração de
software será realizada através de versionamento do código fonte em um repositório
centralizado, compartilhado e disponível remotamente, utilizando a ferramenta
subversion ou similar.
1.10 Registros de Qualidade
Os registros da qualidade serão apresentados pelos auditores da qualidade, na forma de lista de exercício ou conclusão da mesma, ao fim de cada ciclo de avaliação, que deverá ser imediatamente após o final de cada sprint utilizado para desenvolvimento do projeto.
1.11 Treinamento
O treinamento necessário para construção do projeto foi aplicado através da execução de uma sequência de exercícios do tipo Warm-up bem como dos exercícios de laboratório. A equipe conta ainda com o apoio dos monitores do curso para sanar eventuais dúvidas sobre as ferramentas de desenvolvimento, se ncessário.
1.12 Gerenciamento de Riscos
Este projeto, por considerar um ambiente acadêmico e controlado, não apresenta riscos significativos que justifiquem o tratamento através de um artefato específico para o mesmo. A utilização de um framework de processo iterativo (SCRUM) já nos permite, através das técnicas associadas à transparência, inspeção e adaptação constantes, o gerenciamento e tratamento de riscos, assim que eles sejam identificados no projeto.
