Listex4-RelatóriodeListadeExercíciosNúmero4

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

Listex 4

Relatório da Lista de Exercícios

Roberto Pepato Mellado

Índice

1   Introdução ... 3   2

1 Introdução

Este relatório apresenta informações sobre a Listex 4, bem como objetivos, principais passos realizados e principais conclusões e recomendações.

2 Principais Passos

Os principais passos para a conclusão da lista de exercícios número 3 foram: • Assistir as aulas da disciplina CE-230;

• Tomar contato com as práticas da metodologia Scrum;

• Tomar contato com sistemas embarcados de tempo real e ferramentas de Model Driven Architecture (MDA).

• Compor um grupo de até nove pessoas;

• Utilizar dos artefatos da Listex 1, Listex 2, Listex 3 e na Listex 4 da disciplina CE-235, para realizar aferição da qualidade de confiabilidade de software;

• Utilizar os artefatos previamente gerados na disciplina CE-230;

• Realizar a Segunda Versão da Adaptação (Tailoring) da Técnica de Burn down Chart; • Realizar a Segunda Versão de uma Adaptação (Tailoring) da Técnica de Planning

Poker;

• Uma análise de desempenho (benchmarking) do software embarcado desenvolvido nas ferramentas: a) RTRT da IBM; e b) UNDERSTAND da SCITOOLS.

• Realizar a geração da segunda versão do Artefato Plano de Garantia da Qualidade –

PGQ com Adaptação (Tailoring)para o Desenvolvimento Ágil do seu Sub-Produto do

SSG; e

• Pelo menos uma interação adicional, com o Grupo de Desenvolvedores do seu Sub-Produto do SSG, envolvendo aferições de Qualidade, Confiabilidade e Segurança (Safety).

A Listex 4 foi dividida em 5 itens:

A primeira parte envolveu a aferição da técnica de Burndown Chat do sub-produto SSG onde foram desenvolvidas 4 Users Stories do grupo da disciplina CE-235. Os alunos foram contatados a fim de garantir o controle e geração do Burn Down Chart.

Prioridade User Story Estimativa Justificativa Resposável 1 Receber confirmaçã o de pedido 1 SP Recebimento de pedido que a confirmação foi feita com sucesso.

Caio 2 Desabilita aresta 3 SP Em caso de necessidade pode-se manusear a rede Robson 3 Envia confirmaçã o 1 SP Envia a confirmação do pedido recebido. Marcelo 4 Verificar integridade da rede elétrica

5 SP Garante que rede está operando

dentro das

especificações.

Dymitri

As user stories totalizaram 10 Story Points que deveriam ser desenvolvidas dentro do período de 15 dias de 17/10 a 31/10.

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 4 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 levantados 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 indica um entendimento equalizado e um grau de habilidades específicas adequado à realização do trabalho. Abaixo é apresentado o relato das rodadas para as user stories.

Prioridade User Story Estimativa Entendimento Aluno

1 Receber confirmação de pedido

1 SP Recebimento de pedido que a confirmação foi feita com sucesso.

Caio

2 Desabilita aresta

3 SP Em caso de necessidade pode-se manupode-sear a rede

Robson

3 Envia

confirmação

1 SP Envia a confirmação do pedido recebido. Marcelo 4 Verificar integridade da rede elétrica

5 SP Garante que rede está operando dentro das especificações.

A primeira estória a ser votada foi “Receber confirmação de pedido”, que foi identificada como Simples e todos os alunos expuseram somente 1 Story Point para o desenvolvimento, pois o requisito ficou claro.

Rodada Caio Dymitri Robson Marcelo Argumento

1 1SP 1 SP 1SP 1SP Funcionalidade entendida no

todo.

A segunda estória a ser votada foi “Envia confirmação”, que dependia do entendimento total da estória monitorar voltagem. A estória “Receber confirmação de pedido” teve sua complexidade relativa avaliada como Média e foram realizadas 2 rodadas de votação para que as dúvidas fossem sanadas.

Rodada Caio Dymitri Robson Marcelo Argumento

1 3SP 8 SP 3SP 3SP Os alunos que colocaram maior

peso não estavam de acordo com a utilização de determinado protocolo e a simplicidade da conexão com outros módulos. Sendo assim as ideias foram expostas e o entendimento coletivo clareado.

2 1SP 1SP 2SP 1SP Nessa rodada os requisitos se

apresentaram mais claros, e todos concordaram que é possível a implementação da funcionalidade com simplicidade.

A terceira estória a ser votada foi “Verificar integridade da rede elétrica”, que dependia do entendimento total das estórias ” Envia confirmação” e “Receber confirmação de pedido”. A estória “Verificar integridade da rede elétrica” foi avaliada como simples porem trabalhosa 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 8SP 5SP 5SP 5SP Os integrantes entenderam que

essa funcionalidade terá boa parte de sua implementação reutilizada de outras estórias, pois os algoritmos são os mesmos.

A quarta e última estória a ser estimada foi “Desabilita aresta”, 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 essa estória não possuía dependência técnica de nenhuma outra estória.

2 3SP 3SP 3SP 3SP Todos os integrante entenderam

que, após as explanações, o esforço associado para implementação não seria tão grande quanto inicialmente imaginado.

A terceira etapa da Listex 4 consistiu em uma análise de desempenho (benchmarking) do software embarcado desenvolvido nas ferramentas: a) RTRT da IBM; e b) UNDERSTAND da

•

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGV

wYXRvfGd4OjQ5OTY3MjM2Y2ZmZWJlYQ&pli=1

A quarta etapa da Listex 4 consistiu na 2ª Versão da adaptação (tailoring) do Artefato Plano de

Garantia da Qualidade – PGQ ao Desenvolvimento Ágil, onde o autor realiza uma pesquisa e

adaptação do Plano de Garantia de Qualidade do RUP que foi adaptado para funcionar com o desenvolvimento ágil a fim de propiciar uma nova experiência para os alunos e para o professor da disciplina. O novo Plano de Garantia de Qualidade se encontra no Anexo I abaixo:

• https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVw

YXRvfGd4OjQ3MzI5NjA4YTU5MmYxYzQ

A quinta etapa da Listex 3 na realização de ao menos pelo menos uma interação adicional, com o Grupo de Desenvolvedores do SM-RED, envolvendo aferições de Qualidade, Confiabilidade e Segurança (Safety).

• https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVw

3 Conclusão

A realização da lista de exercícios número 4 (ListEx4) proporcionou a este aluno uma experiência similar à encontrada em um ambiente real, com foco na avaliação da qualidade de produto de software de uma integração de um grande sistema de um mercado vertical (distribuição de energia elétrica). A utilização de boas práticas do desenvolvimento ágil ajudou a integrar os times das três disciplinas envolvidas, mostrando os desafios que o time deveria enfrentar para garantir a qualidade e confiabilidade do SSG, a forma que o time deveria desenvolver e testar o produto e como o cliente é receptivo a mudanças e apoiador do time. O contato com ferramentas de análise de qualidade de produtos de software como Rational Rose Real Time (RTRT) e Understand propiciou a esse aluno um entendimento aprofundado sobre métricas e medidas de software e sobre como produzir um plano efetivo para aferição da qualidade do produto de software.

Como sugestão para as próximas Listex, o aluno sugere a utilização da linguagem Java, na plataforma JavaME para criação do sistema embarcado de tempo real. Além disso, o aluno sugere a utilização das ferramentas Sonar e JUnit para aferição de qualidade nesta plataforma.