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 V – Interações de Emails entre os alunos do Subproduto SSG SM-RED.
Roberto Pepato Mellado
Índice
5
Anexo V – Interações de Emails entre os alunos do Subproduto SSG SM-RED ... 3
5.1.
Perguntas Realizadas ao Grupo ... 3
5.2.
Réplicas do Grupo ... 4
5.3.
Treplica ao Grupo ... 5
5 Anexo V – Interações de Emails entre os alunos do Subproduto
SSG SM-RED
5.1.
Perguntas Realizadas ao Grupo
Abaixo o email enviado pelo Sr. Roberto Pepato questionando o grupo SM-RED da Disciplina
CE-235, afim de realizar uma auditoria sobre o desenvolvimento.
Prezados Srs,
Meu nome é Roberto Pepato, sou aluno da disciplina CE-230 - Qualidade, Confiabilidade
e Segurança de Software e estou atuando, junto com o aluno Robson Monteiro, em uma
auditoria nos componentes de softwares desenvolvidos pelos senhores para o sistema
de smart grids (SSG). O objetivo dessa auditoria é validar o trabalho que está sendo
realizado, bem como efetuar sugestões para adaptação quando oportuno. Para isso,
peço a gentileza de me responderem ao conjunto de 6 questões apresentadas abaixo.
Ao respondê-las, levem em consideração a aplicação desses questionamentos ao
primeiro sprint executado pelos senhores (primeiro sprint development):
1.
Durante o planejamento da sprint, vocês estão considerando a utilização de todo
o tempo disponível para implementação das funcionalidades ou existe algum tipo
de “reserva” de tempo sendo considerada
2.
Qual foi a velocidade esperada (em pontos) pela equipe para o primeiro sprint ?
Como ela foi determinada ?
3.
Como vocês pretendem garantir que as alterações da próxima sprint não gerem
defeitos nas funcionalidades que foram desenvolvidas nesta sprint ?
4.
Ao final do primeiro sprint, quais foram os pontos positivos e negativos
identificados na retrospectiva do sprint ?
5.
Como o time considera a qualidade dos modelos e do código gerado pela
ferramenta para o sprint 1, no que diz respeito à manutenção futura deste
modelo/código para as demais sprints ?
6.
Como o conhecimento dos modelos de cada componente foi compartilhado ? O
conhecimento sobre todo o sistema está equalizado no time ?
Att,
Roberto Pepato
5.2.
Réplicas do Grupo
Abaixo o email recebido pelo Sr. Robson Monteiro, representante dos alunos do grupo SM-RED.
Caro Roberto,
Interessante suas perguntas.
Abaixo seguem as respostas, em caso de duvidas estaremos a disposição.
1. Estamos consideram um tempo de reserva para que possamos nos adaptar em caso de um
desvio ou variável nao prevista durante a elaboração das sprints developements.
2. A velocidade determinada para equipe foi estipulada baseado na experiência de casa integrante
do grupo, Por ser a primeira Sprint, não tínhamos uma série histórica para comparação ou mensuração. Esperamos que para a próxima Sprint, teremos já uma base para realizar algum tipo de determinação da velocidade do time, isso nos ajudaram a calibrar e determinar um valor próximo do ideal.
3. Estamos implementando testes automatizados nos módulos do SM-RED e a fim de aferir falhar
em mudanças realizadas durante as sprints. Nosso time também definiu com os outros times um protocolo em comum para integração entre os outros módulos, propriciando uma maior facilidade na integração.
4. Os negativos foram a dificuldade de implementação da automatização de testes durante o
desenvolvimento. Os positivos foram a integração com do time, e com os outros times, foi bem mais fácil trabalhar dessa forma.
5. Estamos controlando a geração e manutenção do código fonte gerando através da ferramenta
RTRT e RQA. Com elas temos uma visão clara e instantânea de como está a saúde de nosso software e assim temos a capacidade de intervir no momento certo em caso de alguma variável estiver fora dos paramentos que determinamos.
6. O conhecimento foi compartilhado durante o planejamento das Sprint developement e intensa
equalizado por todo o time. Isso facilitou na definição do protocolo de integração entre o time e os outros times.
Cordialmente, Robson Monteiro
5.3.
Treplica ao Grupo
Abaixo o e-mail enviado pelo Sr. Roberto Pepato Mellado, contendo observações e
recomendações para o grupo responsável pelo componente SM-RED.
Srs,
Obrigado pelas respostas e atenção imediata. Seguem abaixo algumas observações e sugestões para aplicação em vosso trabalho:
1. É importante que vocês considerem uma reserva, principalmente nos sprints que seguem esse sprint inicial. Isso se deve em razão da possibilidade da descoberta de defeitos de um sprint enquanto o sprint seguinte encontra-se em desenvolvimento. Nossa sugestão é que vocês inicialmente reservem um esforço de 10 à 15% para tratamento de eventuais defeitos e, posteriormente, nas reuniões de retrospectiva, verifiquem e adaptem essa reserva à realidade do projeto;
2. A utilização de estimativas com base no conhecimento prévio (estimativas análogas) são válidas para quando não temos nenhuma outra forma de obter métricas reais da
velocidade do projeto. A recomendação é que vocês utilizem, para planejamento da próxima sprint, a velocidade obtida no desenvolvimento deste sprint;
3. Perfeito. É importante que os testes automatizados sejam executados constantemente, para garantir que mesmo pequenas alterações não introduzam defeitos no código. Se possível, avaliem a utilização de um ambiente de integração contínua para automatização completa da execução e relatório de execução dos testes;
4. Excelente. A idéia deste questionamento não foi obter respostas corretas ou erradas sobre pontos positivos ou negativos mas sim validar que a equipe está fazendo
retrospectiva de seu trabalho. Essa cerimônia, uma das mais importantes no projeto, é o momento que a equipe tem para refletir e promover melhoria contínua na sua forma de atuar.
5. Sugerimos a utilização das métricas reportadas pela ferramenta Rational Test Real Time para avaliação da qualidade do produto de software gerado. Em especial, sugerimos o acompanhamento das métricas de Halstead, pois estas indicam qual o nível de esforço
associado à manutenção futura do sistema e o nível de defeitos esperados para o mesmo;
6. Recomendamos a manutenção do trabalho descentralizado, para que todos os
componentes do grupo tenham condições de respnder de forma integral pela aplicação e não apenas localizada. Desta forma, a probabilidade da introdução de novos defeitos no código é reduzida, devido ao entendimento completo por todos.
Att,
Roberto Pepato Mellado
5.4.
Quadréplica ao Grupo
Abaixo o email enviado pelo Sr. Robson Monteiro, representante dos alunos do grupo
SM-RED.
Caro Roberto,
Obrigado pelas considerações referente a ao nosso trabalho. Esse apoio e cooperação tem enriquecido a execução do projeto no todo.
1- Ao longo da execução da terceira sprint development, realmente precisamos usar um
tempo extra para realizar as adaptações necessárias ao projeto e a reserva de tempo
sugerida realmente fui muito útil. Durante a nossa reunião de retrospectiva que será
realizada na próxima aula, iremos identificar o que pode ser melhorado para evitar o
uso da reserva e poder melhorar o nosso processo.
2- Nessa nova sprint development, a terceira pudemos utilizar uma métrica mais real
baseada em nossa velocidade nos sprint`s anteriores e a velocidade ficou bem mais
calibrada e real dessa vez. Foi interessante notar que os fatores de intimidade entre o
time e conhecimento das capacidade do time foram muito utilizadas para a realização
das estimativas.
3- Durante essa sprint development existiram várias mudanças da arquitetura a fim de
comportar novas integrações e funcionalidade, e o uso massivo dos testes
automatizados foi crucial para manutenção dos estados das funcionalidades. Não foi
possível setar um ambiente de integração continua para esse projeto, porem nos
sabemos da real importância
4- Realmente a cerimonia de retrospectiva tem nos ajudado a entender o fluxo do
projeto e os pontos positivos e negativos de nossas atividades, além de realizar uma
avaliação profunda do conhecimento adquirido na disciplina.
5- Estamos utilizando as métricas do RTRT tanto internalizamos em nosso time para
realização das nossas cerimonias para entendimento do andamento técnico do
projeto, como estamos acompanhando na entrega das listas de exercícios da
disciplinas que você está usado.
6- A partir de sprint development fizemos um trabalho para a descentralização do
conhecimento afim de que todos pudessem entender utilizando o conceito de teste
de contrato e compartilhando uma planilha com os conhecimentos. Foi muito
importante para a evolução da equipe.
Att,
