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 de Software
Professor Doutor Adilson Marques da Cunha
Relatório de Projeto Final da Disciplina
Grupo de Alunos:
Roberto Pepato Mellado
Robson Luis Monteiro Junior
Roberto Pepato Mellado
Índice
1.
Introdução ... 3
1.1.
Motivação ... 3
1.2.
Contexto ... 3
1.3.
Objetivação do Protótipo de Sistemas de Software ... 4
1.4.
Redução de Escopo ... 4
1.5.
Especificação de Requisitos ... 4
1.6.
Ordem de Apresentação do Projeto Final da Matéria ... 4
2.
Desenvolvimento ... 6
2.1.
Síntese das Listas de Exercício 3 e 4 ... 7
2.1.1.
Lista de Exercícios Número 3 ... 7
2.1.2.
Lista de Exercícios Número 4 ... 9
2.2.
Análise de Sensibilidade do Software produzido no SM-RED ... 11
2.3.
Parecer do tipo Auditoria sobre Aferição da Qualidade, Confiabilidade e Segurança de Software produzido ... 12
3.
Conclusão ... 13
1. Introdução
1.1. Motivação
Diante dos problemas encontrados no Brasil e no mundo relacionados ao uso não sustentável dos recursos naturais e ambientais, observa-se a real necessidade da geração, transmissão e distribuição de energia elétrica realizada de maneira otimizada e evitando desperdícios.
Esta necessidade gerou uma demanda que utiliza Sistemas Embarcados de Tempo Real e o objetivo do ITA é desenvolvê-la, implementá-la e validá-la quanto à qualidade, confiabilidade e segurança. Este projeto visa a melhor eficiência e redução do desperdício de recursos energéticos envolvidos.
No primeiro dia de aula, os professores da disciplina CE-230 propuseram aos alunos o Projeto Acadêmico SSG (Sistema de Smart Grids) que foi dividido em Unidades de Software de Computador (USCs). Os alunos da disciplina CE230 – Qualidade, Confiabilidade e Segurança de Software ficaram responsáveis pela auditoria de qualidade do projeto. O autor deste relatório participou com outro aluno de sua turma, na equipe que auditou a USC Smart Meter Rede ou simplesmente SM-RED.
1.2. Contexto
No projeto SSG, os Smart Meters, são aparelhos que estão presentes em casa unidade consumidora de energia e tem a função de monitorar o consumo e distribuição de energia. Neste contexto, insere-se o SM-RED, responsável pelo controle da rede de energia inteligente, onde são processados os pedidos de consumo e a habilitação e desabilitação de pontos de energia.
O SM-RED tem como função principal coordenar a comunicação de toda a rede de energia, servindo como intermediário entre os Smart Meters controladores de vários tipos de consumidores, desde casas até indústrias, passando por órgãos governamentais, e abrangendo o controle de distribuição e geração de energia de toda a sociedade.
O projeto acadêmico SSG, introduziu um conceito recente no meio acadêmico, provendo aos alunos a experiência de aprender e utilizar métodos ágeis de desenvolvimento de software aplicados a um problema real da indústria, aplicado através da técnica Problem-based learning ou PBL.
1.3. Objetivação do Protótipo de Sistemas de Software
Dotar o Sistema de Smart Grid com um mecanismo de controle de todas as áreas consumidoras da sociedade, independente da sua categoria, a fim de garantir a geração e distribuição efetiva de energia elétrica e evitar desperdícios na sua utilização.
1.4. Redução de Escopo
Esse trabalho acadêmico tem como objetivo demonstrar o desenvolvimento e a aferição de qualidade do Smart Meter Rede (SM-RED), bem como a participação desse aluno no âmbito do grupo que compõe e na utilização da aplicação das metodologias ágeis de desenvolvimento de software.
É demonstrada a evolução do trabalho desde a definição e aferição de qualidade dos artefatos iniciais, de seu processo de desenvolvimento e dos incrementos de produto realizados iterativamente. Uma análise sobre métricas de qualidade de produto e processo é realizada e o resultado destas análise comunicado aos desenvolvedores no intuito de prover insumos para obtenção de melhorias na qualidade. São demonstrados os resultados do projeto e como a utilização de métodos ágeis contribui no contexto.
1.5. Especificação de Requisitos
O Smart Meter Rede deverá ser capaz de propiciar: • Receber e Responder pedidos de consumo;
• Monitorar Voltagem que está sendo trafegada na rede; • Habilitar e Desabilitar Arestas;
• Verificar integridade da rede elétrica em um todo; • Receber e enviar alertas;
• Envio de coordenadas geográficas dos Smart Meters ligado a rede; .
1.6. Ordem de Apresentação do Projeto Final da Matéria
Na Seção 1, apresenta-se a Motivação, o Contexto, o Objetivo do SM-RED, a Redução do Escopo e a Especificação de Requisitos em forma de um Product Backlog deste Projeto Final sobre a aferição de qualidade do Smart Meter Rede.
Na Seção 2, descreve-se a aferição de qualidade durante o desenvolvimento do protótipo do SM-RED, baseando-se na metodologia ágil de desenvolvimento de software Scrum.
Finalmente, na Seção 3, são sintetizadas as principais Conclusões do Protótipo SM-RED, Recomendações para o Aperfeiçoamento do Protótipo e Sugestões para Trabalhos Futuros e a melhoria das disciplinas ministradas neste semestre.
2. Desenvolvimento
O protótipo SM-RED foi desenvolvido em um processo baseado na metodologia ágil de desenvolvimento SCRUM. Algumas boas práticas desta metodologia foram selecionadas e adaptadas ao contexto de execução do processo atual. De forma geral, as principais caraterísticas e cerimônias da metodologia SCRUM foram mantidas, definindo-se o processo com as seguintes principais atividades:
• Produção de um Product Backlog: Uma lista de funcionalidades a serem
implementadas para garantir que o produto atenda aos requisitos determinados para o
mesmo;
• Papéis: Cada USC possui um Scrum Master, um Product Owner e um time
designados. O papel de cliente é desempenhado pelo professor da disciplina;
• Planejamento de Iteração (Sprint Planning): Reunião de planejamento onde o Product
Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela
será capaz de implementar durante o Sprint (representado através de uma lista de
exercícios - Listex) que se inicia. As tarefas alocadas em um Sprint são transferidas do
Product Backlog para o Sprint Backlog;
• Ciclos de desenvolvimento de duração fixa (Sprints): Durante a execução de um
Sprint, todas as atividades necessárias para a produção do ativo de software planejado
para o ciclo atual são realizadas. Ao final do ciclo, um produto de software completo,
potencialmente implantável em produção deve ser entregue;
• Demonstração de resultados da iteração: Ao final de um Sprint, a equipe apresenta as
funcionalidades implementadas em uma Sprint Review Meeting que é uma reunião
envolvendo o cliente onde as estórias previamente selecionadas e implementadas
serão apresentadas para validação contra seus critérios de aceite, junto ao cliente.
• Restrospectiva da iteração: Nesta reunião a equipe reflete sobre o produto que
produziu e o processo de trabalho que utilizou, avalia as ações com resultados
positivos e/ou negativos e realiza ajustes no seu fluxo de trabalho visando a
maximização dos resultados positivos e eliminação/redução dos resultados negativos.
Figura 1 - Fluxo da metodologia Scrum
2.1. Síntese das Listas de Exercício 3 e 4
2.1.1. Lista de Exercícios Número 3
Durante a execução da lista de exercícios número 4 um conjunto de atividades foi realizado:
• Auditou-se a qualidade no processo de desenvolvimento utilizado e verificou-se
que o mesmo possuía qualidade. Os desenvolvedores do projeto realizaram
estimativas para desenvolvimento das estórias através da aplicação da técnica de
planning poker, auditava e validada pelos auditores da qualidade;
• O controle da evolução das atividades no tempo foi realizado através de gráficos
do tipo Sprint Burndow Chart. Verificou-se que o desenvolvimento do produto de
software discorreu de forma próxima à idealmente planejada, indicado uma
pequena variação esperada e controlada, no entorno da linha ideal. Isso representou
um alto nível de assertividade na definição das atividades das estórias (definição da
granularidade das mesmas) e nas estimativas realizadas pelos desenvolvedores,
pois o volume de esforço realizado foi próximo ao estimado;
• Produziu-se um plano de execução de testes, onde as atividades de planejamento
dos testes do produto de software que estaria produzido na próxima iteração foi
definido. Neste plano, foram definidas as atividades necessárias à identificação dos
testes, Construção e aplicação dos testes de instrumentação, exposição dos
8
• Foram realizadas três interações via e-mail com o grupo de desenvolvedores,
visando auditar e sugerir ações visando averiguar e, se cabível, aumentar os índices
de qualidade apresentados no projeto.
Figura 2 – Acompanhamento do Projeto Por Burndown Chart
Figura 3 – Exemplo de utilização da técnica de planning poker em uma das estórias do projeto
4
3. Habilitar Aresta
4. Enviar pedido de consumo
As user stories totalizaram 7 Story Points que deveriam ser desenvolvidas dentro do período de 15 dias de 3/10 a 17/10.
Avaliando a variação do trabalho realizado em relação a meta de sprint podemos perceber claramente uma pequena variação controlada em relação a linha ideal (linha em azul escuro), o que indica que a equipe realizou um bom trabalho iterativo consequente execução, sem grandes deslocamentos das linhas de execução ideal e progressão realizada. Outro aspecto importante a ser observado é que a execução do trabalho foi finalizada dois dias antes do planejado. Essa variação pode indicar um problema de calibragem de estimativas (a princípio esta folga poderia ser utilizada para produção de novas estórias) contudo como essa é a primeira medida de velocidade, recomenda-se a manutenção da técnica de planejamento atual, visando a determinação de uma tendência de consistência das estimativas após a aferição do terceiro
sprint.
A segunda parte da Listex 3 envolveu a adaptação da técnica de planing poker, visando realizar as estimativas das user stories dos alunos da disciplina CE-235. Durante o processo, foram levantandos os votos dos alunos, bem como o porquê da maior e menor pontuação. As dúvidas técnicas foram sanadas e uma nova rodada de estimativas foi realizada para equalização do entendimento e geração de um consenso com relação à esforço relativo aplicado. Vale notar que para esse grupo nenhuma user story teve mais que 2 rodadas de planing poker, o que Sendo assim as ideias foram expostas e o entendimento coletivo clareado.
2 2SP 2SP 3SP 2SP Nessa rodada os requisitos se
apresentaram mais claros, e todos concordaram que é possível a implementação da funcionalidade
A terceira estória a ser votada foi “enviar pedido de consumo”, que dependia do entendimento total das estórias ”monitorar voltagem” e “receber pedido de consumo”. A estória “enviar pedido de consumo” foi avaliada como simples e apenas 1 rodada de estimativas aconteceu para que as dúvidas fossem sanadas e o consenso atingido.
Rodada Caio Dymitri Robson Marcelo Argumento
1 2SP 1SP 1SP 1SP Os integrantes entenderam que
essa funcionalidade terá boa parte de sua implementação reutilizada da estória receber pedido de consumo, pois os algoritmos são os mesmos.
A quarta e última estória a ser estimada foi “habilitar arestas”, que foi avaliada como complexa não tinha nenhuma dependência com as outas user stories, porém representa o maior valor do produto, e gerou 2 rodadas de estimativas para que as dúvidas fossem esclarecidas.
Rodada Caio Dymitri Robson Marcelo Argumento
1 8SP 13SP 8SP 8SP Os integrantes não tinham a
clareza da funcionalidade e qual o valor para o cliente. Essas dúvidas foram sanadas e os argumentos apresentados. Foi exposto o valor da funcionalidade para o cliente e, além disso, demonstrado que
2.1.2. Lista de Exercícios Número 4
Durante a execução da lista de exercícios número 4 um conjunto de atividades foi realizado:
• Realizou-se uma nova comunicação via e-mail com os alunos da disciplina
CE235-Sistemas Embarcados de Tempo Real. Esta comunicação teve por objetivo
apresentar aos alunos daquela disciplina algumas observações relacionados aos
aspectos da qualidade envolvidos na integração suas USCs em um SSG. Os alunos
da disciplina CE-235 prontamente responderam aos questionamentos dos auditores
e demonstraram um bom entendimento e envolvimento na mitigação dos riscos
associados à arquitetura de integração da solução através da produção testes
automatizadas para mitigar este risco;
• O Plano de Garantia da Qualidade, construído inicialmente na lista de exercícios
número 3 foi revisado e aplicado. Foram identificados desvios em algumas
métricas do produto de software em relação às metas previamente estabelecidas e
os desenvolvedores foram notificados para providências em relação a estes
aspectos;
• Avaliou-se a qualidade no processo de desenvolvimento de software, através do
acompanhamento do andamento das atividades previstas x realizadas nos gráficos
de burndown chart e da assertividade das estimativas produzidas pela técnica de
planning poker. Os auditores ofereceram algumas sugestões para melhoria da
abordagem utilizada e direcionamento no sentido de melhor as práticas já
utilizadas.
• Avaliaram-se métricas de produto de software através da aplicação de duas
ferramentas distintas: Rational Test Real Time e Understand. Verificou-se que, no
aspecto relacionado à métricas, ambas apresentaram funcionalidades suficientes
para uma análise da qualidade, entretanto, nos aspectos relacionados a análise de
tempo de execução, a ferramenta Rational Test Real Time apresentou, no
entendimento deste autor, uma vantagem competitiva pois oferece uma série de
funções automatizadas e específicas ao contexto de aferição de qualidade em
sistemas embarcados de tempo real que não estão disponíveis na ferramenta
Understand. O resultado da análise de métricas apresentou valores idênticos nas
métricas em comum em ambas as ferramentas, o que foi importante para validar o
processo de avaliação. Algumas informações complementares, como
características da visualização de software, presentes unicamente na ferramenta
understand foram aplicados e revelaram alguns problemas relacionados ao aspecto
da manutenibilidade e modularização do sistema.
Figura 4 – Exemplo de Análise Realizada – Complexidade Ciclomática – V(g)
2.2. Análise de Sensibilidade do Software produzido no SM-RED
Nesta seção, é realizada uma análise de sensibilidade de métricas da qualidade, confiabilidade e segurança da USC de software SM-RED. Para produção desta análise de sensibilidade as seguintes métricas foram selecionadas:
• Métrica da qualidade: V(g) – Complexidade Ciclomática Média da USC
SM-RED. As medidas relacionadas à essa métrica foram obtidas através da utilização
da ferramenta RTRT. A meta para esta métrica é um valor menor ou igual a 10;
• Métrica da Confiabilidade: Falhas de Roteamento de Informações entre USC’s
(por milhar). Esta métrica objetiva avaliar se o USC SM-RED contém qualidade no
tempo, através aplicação e observação de resultados de um grande volume de
requisições de roteamento ao USC SM-RED. As medidas relacionadas à essa
métrica foram obtidas através da aplicação de um grande número de testes
automatizados de forma repetida e sistemática, e da observação de seus resultados.
A meta para essa métrica é um valor menor ou igual a 1 falha por mil operações
executadas;
• Métrica da Segurança: Tempo Máximo para Desligar o Sistema em Caso de
Sobrecarga. Essa métrica objetiva avaliar o tempo máximo para desligamento do
sistema em caso de sobrecarga, visando preservar a vida e bens dos seres humanos
atendidos pela rede de distribuição. As medidas relacionas à essa métrica foram
obtidas gerando sobrecargas no sistema e observando seu comportamento em
reação à esse tipo de evento. A meta para essa métrica é um valor menor ou igual a
15 milissegundos para desligar o sistema após a identificação da sobrecarga.
A tabela abaixo apresenta os valores de meta e medidos para as métricas estabelecidas nesta seção:
Tipo de Métrica Métrica Meta Valor Medido
Confiabilidade Falhas no Roteamento de Informações entre USCs (por milhar) 1 0,2 Segurança Tempo Máximo Para Desligar o Sistema Em Caso de Sobrecarga (em ms) 13 5
Qualidade V(g) do USC 10 2,3
Tabela 1 –Métricas da Qualidade, Confiabilidade e Segurança de Software
Os valores medidos na tabela 1 indicam conformidade com relação às metas definidas. Abaixo é apresentado um gráfico de Kiviat, com as informações representadas na tabela acima, indicando a conformidade dos valores medidos através do triângulo interno, contido no triângulo externo:
Figura 6 – Gráfico de Kiviat – Métricas da Qualidade, Confiabilidade e Segurança de Software
2.3. Parecer do tipo Auditoria sobre Aferição da Qualidade,
Confiabilidade e Segurança de Software produzido
A análise realizada pela equipe de auditoria da qualidade certifica o produto objeto de análise SM-RED, no tocante à suas características relacionadas a qualidade, confiabilidade e segurança. Certifica que o produto cumpre os requisitos para os quais foi especificado, ou seja, que possui qualidade, e considera os aspectos relacionados à confiabilidade e segurança como satisfatórios.
Apresenta-se uma ressalva quanto aos aspectos de manutenibilidade do sistema, que podem e devem ser melhorados para garantir que este produto possa ser evoluído e mantido em ambiente de produção. Um relatório completo com estas recomendações pode ser encontrado em : https://sites.google.com/site/rpepato/ce230/listex4
3. Conclusão
A execução das atividades propostas na disciplina CE230 – Qualidade, Confiabilidade e Segurança de Software propiciou à este aluno um entendimento abrangente sobre as principais técnicas, métodos e processos utilizados na aferição de qualidade de sistemas de software, especialmente aqueles da categoria de sistemas embarcados de tempo real.
Verificou-se qualidade no produto de software (SM-RED) construído pela equipe da qual este aluno fez parte, cumprindo o papel de avaliador. Foram verificadas e comunicadas algumas inconsistências de menor grau, relacionadas ao aspecto de manutenibilidade da solução, visando melhoria do produto de software gerado.
Verificou-se o sucesso na aplicação de métodos ágeis (neste caso, scrum) no contexto de resolução de um problema do mundo real através da aplicação da técnica de Problem Based Learning – PBL.
Para as próximas turmas, recomenda-se a geração de código do sistema em mais de uma plataforma de execução (por exemplo, J2ME) através da utilização do paradigma MDA (Model Driven Architecture) e a validação através de ferramentas aderentes ao contexto (ex.: Sonar, JDepend).
Referencias Bibliográficas
[1] CUNHA, A. M. Notas de Aula de CE-230 Qualidade, Confiabilidade e Segurança de Software. Segundo Semestre de 2011. ITA – Instituto Tecnológico de Aeronáutica.
Disponível em: https://sites.google.com/site/ce230ita Acesso em Novembro de 2011.
[2] MELLADO, R. P. ListEx 1, 2, 3 e 4 de CE-230 Qualidade, Confiabilidade e Segurança de Software. Segundo Semestre de 2011. ITA – Instituto Tecnológico de Aeronáutica.
Disponível em: https://sites.google.com/site/rpepato/ce230 Acesso em Novembro de 2011. [3] RAMOS, M. P. ListEx 1, 2, 3 e 4 de CE-235 Sistemas Embarcados de Tempo Real. Segundo Semestre de 2011. ITA – Instituto Tecnológico de Aeronáutica.
Disponível em: https://sites.google.com/site/marcelopaivaramos/ Acesso em Novembro de 2011. [4] LEAO, D. C. ListEx 1, 2, 3 e 4 de CE-235 Sistemas Embarcados de Tempo Real. Segundo Semestre de 2011. ITA – Instituto Tecnológico de Aeronáutica.
Disponível em: https://sites.google.com/site/dymitrileao/ Acesso em Novembro de 2011.
[5] SCHWABER, K., SUTHERLHAND, J. LThe Scrum Guide: The Definitive Guide to Scrum: The Rules Of The Game.
Disponível em: http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf Acesso em Novembro de 2011.
