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 IV– Plano de Garantia de Qualidade
Roberto Pepato Mellado
15 de Novembro de 2011Índice
1 Anexo I – Plano de Garantia da Qualidade ... 3
1.1 Papéis e Responsabilidades ... 4
1.2 Documentação ... 5
1.3 Padrões e Guias ... 5
1.4 Métricas ... 5
1.5 Plano de Revisão e de Auditoria ... 11
1.6 Avaliação e Teste ... 11
1.7 Resolução de Problemas e Ação Corretiva ... 12
1.8 Ferramentas, Técnicas e Metodologias ... 12
1.9 Gerenciamento de Configuração ... 13
1.10 Registros de Qualidade ... 13
1.11 Treinamento ... 13
4 Anexo IV – 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.
4.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 conseqüente certificaçã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.
4.2 Documentação
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.
4.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.
4.4 Métricas
NomeComplexidade 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
Responsabilidad es
Essa métrica deverá ser avaliada pelo auditor da qualidade
Resultado da Análise
Foram identificados arquivos e funções que ultrapassaram o limite definido e devem sofrer manutenção corretiva para aprovação. Abaixo é apresentada a lista de não conformidades, categorizada por desenvolvedor responsável:
1. Desenvolvedor Marcelo Paiva Ramos:
Item de Código V(g)
PortController_Actor::rtsBehavior 15
SMRED_Actor::_followOutV 61
SMRESCheck_Actor::rtsBehavior 12
UEI_Actor::rtsBehavior 12
URI_Actor::rtsBehavior 16
2. Desenvolvedor Dymitri Cardoso Leão:
Item de Código V(g)
HeartbeaterSMRES_Actor::rtsBehavior 14 PortController_Actor::rtsBehavior 40 SMRED_Actor::_followOutV 68 UCO_Actor::_followInV 11 UMO_Actor::rtsBehavior 26 URE_Actor::_followInV 13 URE_Actor::rtsBehavior 75
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
Resultado da
Análise
Foram identificados arquivos e funções que ultrapassaram o limite definido e devem sofrer manutenção corretiva para aprovação. Abaixo é apresentada a lista de não conformidades, categorizada por desenvolvedor responsável:
1. Desenvolvedor Marcelo Paiva Ramos:
Item de Código Aninhamento
PortController_Actor::rtsBehavior(int, int) 8 SMRESCheck_Actor::rtsBehavior(int, int) 8 UCO_Actor::rtsBehavior(int, int) 8 UEI_Actor::rtsBehavior(int, int) 8 UMO_Actor::rtsBehavior(int, int) 8
2. Desenvolvedor Dymitri Cardoso Leão:
Item de Código Aninhamento
UMO_Actor::transition2_report(const void *, Timing ::Base *) 9 HeartbeaterSMRES_Actor::rtsBehavior(int, int) 8 URE_Actor::rtsBehavior(int, int) 8 PortController_Actor::rtsBehavior(int, int) 8
SMRED_Actor::rtsBehavior(int, int) 8 UCO_Actor::rtsBehavior(int, int) UMO_Actor::rtsBehavior(int, int) SMRED_Actor::_followOutV(RTBindingEnd &, int, i nt, int) 6 URE_Actor::transition3_t1s(const void *, Timing::B ase *) 5 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
Responsabilida des
Essa métrica deverá ser avaliada pelo auditor da qualidade
Resultado da Análise
Foram identificados arquivos e funções que ultrapassaram o limite definido e devem sofrer manutenção corretiva para aprovação. Abaixo é apresentada a lista de não conformidades, categorizada por desenvolvedor responsável:
Item de Código Nr. De Linhas
URI.cpp 328
PortController.cpp 365
SMRED_Actor 420
SMRED.cpp 841
2. Desenvolvedor Dymitri Cardoso Leão:
Item de Código Nr. De Linhas
HeartbeaterSMRES.cpp 246 PortController.cpp 657 PortController_Actor 584 SMRED.cpp 746 SMRED_Actor 329 UCO.cpp 287 UMO.cpp 529 UMO_Actor 428 URE.cpp 1009 URE_Actor 858 URE_Actor::rtsBehavior 388 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
Utilizar ferramenta de apoio Rational Test Real Time (RTRT) para aplicação no código fonte do produto e extração de métricas
de análise
Responsabilida des
Essa métrica deverá ser avaliada pelo auditor da qualidade
Resultado da Análise
Foram identificados arquivos e funções que ultrapassaram o limite definido e devem sofrer manutenção corretiva para aprovação. Abaixo é apresentada a lista de não conformidades, categorizada por desenvolvedor responsável:
1. Desenvolvedor Marcelo Paiva Ramos:
Item de Código Classes Associadas
MessageProtocol::Base 7 MessageProtocol::Conjugate 7 MessageProtocol 7 UMO_Actor 8 UCO_Actor 10 UEI_Actor 6 SMRESCheck_Actor 14 URI_Actor 12 PortController_Actor 17
2. Desenvolvedor Dymitri Cardoso Leão:
Item de Código Classes Associadas
Control 6 HeartbeaterSMRES_Actor 13 MessageProtocol 7 MessageProtocol::Base 7 MessageProtocol::Conjugate 7 PortController_Actor 18 UCO_Actor 13 UMO_Actor 15 URE_Actor 16
4.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.
4.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.
4.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.
4.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
4.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.
4.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.
4.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.
4.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.
