INSTITUTO TECNOLÓGICO DE AERONÁUTICA
RELATÓRIO PADRONIZADO LISTEX3 CE-235
SISTEMAS EMBARCADOS DE TEMPO REAL
VERSÂO DE:
CIRO FERNANDES MATRIGRANI
DEMAIS AUTORES:
ALEXANDRE LIMA POSSEBON RIBEIRO GUSTAVO MATUCK
JOSÉ ARMANDO BARBOSA FILHO PAULO ANDRE CARVALHO DE MELO TAYNARA ARAUJO SOARES
PROFESSORES: ADILSON CUNHA E VIEIRA DIAS
SÃO JOSÉ DOS CAMPOS
1
1
INTRODUÇÂO
Esta listex 3 tem por objetivo o relato padronizado da atuação do autor dentro de sua equipe (Smart Meter Central) nos requisitos enumerados abaixo.
1. No 1º Sprint Backlog, indicando as principais funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no seu Produto do SSG;
2. No 1º Sprint Development, indicando as principais funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no seu Produto do SSG;
3. Na atualização dos Artefatos necessários produzidos pelo seu Grupo (Visão, Glossário, Product Backlog, Release Backlog, Sprint Backlog, entre outros julgados necessários);
4. Na elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros); e
5. Na elaboração de uma Apresentação para o Cliente (Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente, descrevendo códigos-fonte gerados para o seu Produto, em C++, concentrando as suas execuções na máquina de desenvolvimento do LAB TEC da FCMF no ITA.
1.1
Motivação
A elaboração da ListEx3 teve como motivação uma iniciação no processo do primeiro sprint de desenvolvimento ágil do produto SM-Central. Esta lista de exercícios propiciou colocar em prática o aprendizado no desenvolvimento ágil de projetos utilizando Scrum para equipes geograficamente distribuídas, bem como colher resultados de um bimestre de trabalho.
2
2
PRINCIPAIS PASSOS REALIZADOS NO EXERCÍCIO
Este capítulo exibe as interações tanto em nível de grupo quanto em nível individual. A seção A seção 2.1 mostra a participação no 1º Sprint Backlog, indicando as principais funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no seu Produto do SSG; a seção 2.2, a participação no 1º Sprint Development, indicando as principais funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no seu Produto do SSG; a seção 2.3 na atualização dos Artefatos necessários produzidos pelo seu Grupo (Visão, Glossário, Product Backlog, Release Backlog, Sprint Backlog, entre outros julgados necessários); a seção 2.4, mostra a árticipção naa elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros); e, por fim, a seção 2.5 mostra a participação na elaboração de uma Apresentação para o Cliente (Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente, tanto em nível individual quanto em grupo.
2.1
Participação No 1º Sprint Backlog, indicando as principais
funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no
seu Produto do SSG;
2.1.1 Equipe.
Através dos warm-ups e labs foi possível constatar quais funcionalidades poderiam ser aplicadas no desenvolvimento do SM-Central, dimensionando em alto nível o tempo, esforço e escopo. Os impactos para o desenvolvimento dos requisitos do Cliente puderam ser mensurados e uma estimativa do potencial de todos os envolvidos na equipe de desenvolvimento.
A arquitetura do sistema foi feita com base no werm-up O documento gerado pelo grupo no 1º Sprint Backlog pode ser conferido no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/SMCentral.pptx?attredirects=0&d=1 2.1.2 Participação Individual.
Como SCRUM MASTER, a experiência adquirida durante a escolha das ferramentas que seriam utilizada nos processos, gerenciamento, participação nas definições dos itens que pertencem ao sprint 1 por ordem de prioridade e definição da arquitetura, o autor acredita ter atingido a meta deste posto no ponto de facilitador.
2.2
Participação no 1º Sprint Development, indicando as principais
funcionalidades aprendidas nos Warm-Ups e Labs e aplicadas no
seu Produto do SSG;
2.2.1 Equipe.
3 Para o desenvolvimento do sprint 1 de desenvolvimento diversas funcionalidades foram aprendidas através do desenvolvimento dos warm-ups e labs da ListEx 2 de desenvolvimento. A seguir são detalhadas cada uma das funcionalidades aprendidas:
• Warm-Up 1 (Hello World) - Foi possível comprovar o envio de mensagens através
de comandos printf, bem como a criação de modelos, capsulas e comportamentos. Também propiciou compilar, rodar e debugar o modelo do SM-Central;
• Warm-Up (Passive Class) 2 – Foi possível aplicar conceitos de cápsulas passivas,
bem como resolver problemas de desenvolvimento através de mudanças nos códigos gerados pelo Rational Rose Real Time e sincronização;
• Warm-Up 4 (Electronic Lock) – Foi possível adicionar máquinas de estado às
classes passivas criadas nos componentes do SM-Central, criação de operações de triggers para controle e adicionar código de transição;
• Warm-Up 5 (BattleShip) – Foi possível criação de modelos através de elementos
de modelo pré-existentes, utilização de serviços de Timing (biblioteca), exibição de mensagens das cápsulas utilizando serviços de Log. Também foi possível verificar todo o modelo dos componentes do SM-Central através do diagrama de seqüência durante o tempo de execução;
• Warm-Up 7 (Client/Server) – Foi possível criar modelos com cápsulas que são
encarnadas 9criadas dinamicamente em tempo de execução) e importadas (movidas dinamicamente em tempo de execução), propiciando modelar uma visão funcional do SM-Rede para comunicação com o SM-Central;
• WarmUp 8 (RQA-RT) – Foi possível criar a especificação e o test harness do
diagrama de sequência para o SM-Central.
• Lab 4 (Controller/Tester) – Introduziu os conceitos de agragação, herança e
partes.
2.2.1.2 Utilização dos Labs e Warm-Ups (Know How).
A utilização dos warm-ups na na participação individual foi:
• Warm-Up 1 (Hello World) – Conceitos deste warm-up, não foram aplicados na
aqrquitetura desenvolvida pelo autor, com exceção do comando “printf”.
• Warm-Up (Passive Class) 2 – Através desse warm-up, foi possível produzir a
classe passive Message utilizada no MessageProtocol padrão;
• Warm-Up 4 (Electronic Lock) – forneceu conceitos que tornaram possível o uso
dos nós “conditionals”;
• Warm-Up 5 (BattleShip) – Forneceu conceitos como o “timer” que auxiliou no
desenvolvimento do modelo de testes, além da biblioteca “Log” utilizada para persistência;
• Warm-Up 7 (Client/Server) – Foi aplicado na arquitetura de teste quase em sua
totalidade, introduziu o conceito incarnate utilizado na arquitetura de testes; • WarmUp 8 (RQA-RT) – Foi utilizado nos teste, mas não influenciou a arquitetura.
• Lab 4 (Controller/Tester) – Foi possível criar estruturas hierárquicas (cápsulas que
contém outras cápsulas), aplicar técnicas de agregação, replicação (cardinalidade)para cápsulas e portas.
4
2.2.1.3 Gráfico Burndown Chart – (CES-63/CE-230 e CE-230)
Através de uma comunicação ágil com a equipe CE-230 buscou-se aferir qualidade e confiabilidade de software para o SM-Central para o sprint 1 de desenvolvimento, iniciando com o gráfico burndown chart (figura 9). Conforme observado na figura, todo o processo de desenvolvimento ocorreu conforme planejado. A interação com a equipe CE-230 foi crucial para que o prazo fosse cumprido e que todas as funcionalidades fossem atendidas e que agregassem valor imediato ao Cliente.
Figura 9 – Burndown chart para o Sprint 1.
Período (dias) E sf o rç o
5 2.2.1.4 Testes do SM-Central – (CES-63/CE-230 e CE-237)
A comunicação com a equipe de teste CE-237 foi possível aferir como devem ser realizadas os testes para verificar a conformidade das funcionalidades desenvolvidas no SM-Central para o primeiro sprint de desenvolvimento.
2.2.2 Participação Individual.
O autor também participou ativamente do desenvolvimento do sprint development, como desenvolvedor, não apenas no item que lhe foi conferido (atribuição de IDs), mas também na implementação da arquitetura, stub para testes de integração e auxilio no desenvolvimento dos demais itens.
2.3
Participação na atualização dos Artefatos necessários produzidos
pelo seu Grupo (Visão, Glossário, Product Backlog, Release
Backlog, Sprint Backlog, entre outros julgados necessários);
2.3.1 Equipe.O documento gerado pela atualização do Artefato Visão está disponível no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/ArtefatoVIS%C3%83O-SM-CENTRAL2.0.pdf?attredirects=0&d=1 O documento gerado pela atualização do Artefato Glossário está disponível no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/ArtefatoGLOSS%C3%81RIO-SM-CENTRAL3.0.pdf?attredirects=0&d=1 O documento gerado pela atualização do Artefato PBK está disponível no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/ArtefatoPBK-SM-CENTRAL3.0.pdf?attredirects=0&d=1
O documento gerado pela atualização do Artefato RBK está disponível no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/ArtefatoRBK-SM-CENTRAL3.0.pdf?attredirects=0&d=1
2.3.2 Participação Individual.
Assim como a participação na definição do Sprint Backlog, o autor participou também das decisões que alteraram este documento, e geraram, por conseguinte, sua nova versão.
2.4
Participação na elaboração, no RRRT, dos Diagramas necessários
produzidos pelo seu Grupo (Casos de Uso, Sequência, Classes,
Estrutura, Estados; entre outros);
6 Para o início primeiro sprint de desenvolvimento do SM-Central foi observada a necessidade da criação de uma nova user story, o qual impactou em todo o cronograma para a entrega ao Cliente. Foi elaborada a user story chamada “Desenvolvimento da Unidade de Processamento Central (UPC)”, que realiza toda a comunicação e gerenciamento do dispositivo SM-Central. Para essa user story, foi atribuída a complexidade 20 através do planning poker e prioridade 1. A user story pode ser melhor vista na figura abaixo:
Figura 1 – Visão interna do SM-Central.
Devido a esta nova user story (UPC), a user story chamada “programação de dados” foi removida deste sprint 1 de desenvolvimento, buscando de forma ágil entregar o maior valor agregado ao Cliente dentro do escopo previsto. Essa troca de user story foi identificada como uma necessidade pelo grupo, embora ela seja condenada pela metodologia Scrum.
Primeiramente foi desenvolvida uma instância que simula o dispositivo SM-Rede (Figura 2), que deverá se comunicar inicialmente com o SM-Central. O SM-Rede criado é capaz de enviar comunicação do tipo “Alerta”, “Mensagem” e “Comunicação”.
7
Figura 2 – Visão do SM-Rede.
Já a figura 3 ilustra uma visão interna do dispositivo SM-Central, o qual realiza todas as funcionalidades propostas pela equipe de desenvolvimento.
8
Figura 3 – Visão interna do SM-Central.
Já a figura 4 ilustra uma visão operacional interna da Unidade de Processamento Central, o qual gerencia todos os tipos de informações recebidos pelo SM-Rede (user story 1). A UPC é capaz de controlar com eficiência e eficácia
Figura 4 – Visão interna da UPC.
A figura 5 mostra a user story 2 com a atribuição de ID (identificação) do Smart Meter do sinal que chega através do SM-Rede. Todas as comunicações recebidas pelo SM-Central
9 deverá passar pelo processo de identificação antes de prosseguir com as demais funcionalidades, garantindo a rastreabilidade de operação do SM-Central.
Figura 5 – Atribuição de ID.
A user story 3, armazenamento de medições, é ilustrada pela figura 6.
Figura 6 – Recebimento de Medições.
10
Figura 7 – Envio de Alertas
A figura 8 ilustra a quantidade de linhas totais produzidas pelo desenvolvimento Sprint 1 do SM-Central. Nela, pode-se ver que foram geradas, no total, 1452 linhas de código. Na figura 8, também, pode-se ver os principais arquivos gerados para a realização, com sucesso, do Sprint 1:
• SMARTGIRDS.cpp • SMCEN.cpp • SMRED.cpp
11 2.4.2 Participação Individual.
Assim como a participação do sprint development, o autor participou ativamente da implementação dos diagramas que deram suporte aos demais além do seu item, além dos diagramas dos casos de teste de integração como o Smart Meter de Rede.
2.5
Participação na elaboração de uma Apresentação para o
Cliente (Resultado Intermediário de Valor), envolvendo uma
documentação mínima, necessária e suficiente, descrevendo
códigos-fonte gerados para o seu Produto, em C++,
concentrando as suas execuções na máquina de
desenvolvimento do LAB TEC da FCMF no ITA.
2.5.1 Equipe.A equipe participou da apresentação durante argüição respondendo eventuais dúvidas correspondentes a sua parte que interagiu no desenvolvimento. Na elaboração da apresentação executiva, a equipe atuou com sugestões e auxilio na elaboração
2.5.2 Participação Individual.
O autor, além de ter participado da produção da apresentação do produto junto com o grupo, foi selecionado para ser o apresentador.A apresentação em Power Point pode ser baixada no link no link:
https://sites.google.com/site/cmatripgita/disciplinas/ce-235/listexes/listex3/SMCentral.pptx?attredirects=0&d=1
12
3
CONCLUSÕES, RECOMENDAÇÔES E SUGESTÔES.
Todas as funcionalidades propostas para o primeiro sprint de desenvolvimento foram desenvolvidas, com exceção da user story 4 (envio de programação). Mesmo assim toda a equipe de desenvolvimento já se preparou para integrar esta funcionalidade nos próximos sprints de desenvolvimento e assim garantir todas as necessidades acordadas com o Cliente para este dispositivo.
O desenvolvimento dos warm-ups e labs foi crucial para a compreensão da ferramenta Rational Rose Real Time e, desta forma iniciar o processo de desenvolvimento do produto SM-Central. Torna-se necessário destacar que, para um melhor aproveitamento de todo aprendizado no bimestre, seria interessante que os warm-ups fossem disponibilizados no primeiro dia de aula. Desta forma todos os integrantes teriam um conhecimento mais sólido sobre a ferramenta e uma melhor qualidade poderia ter sido alcançada neste sprint 1 de desenvolvimento.
A maior motivação da equipe foi observar o funcionamento real do SM-Central após passar o primeiro bimestre no processo de planejamento deste dispositivo, bem como averiguar que os resultados obtidos pode realmente garantir todo o escopo proposto para o Cliente ao final do projeto.
A comunicação com a equipe CE-230 foi de suma importância para aferir qualidade, confiabilidade e segurança (safety) para este dispositivo, permitindo uma maior visibilidade durante o andamento do processo de desenvolvimento (sprint). Já a comunicação com a equipe CE-237 foi importante para mostrar à equipe de desenvolvimento (CES-63/CE-235) análises de teste e métricas importantes para potenciais de melhoria no processo de implementação dentro da ferramenta do Rational Rose Real Time e pontos críticos a serem levados em consideração.
Esta listex três expos os estudantes à prática do desenvolvimento reunindo os fatores de arquitetura oriantada a modelos, desenvolvimento ágil e sistemas embarcados de tempos real. A primeira interação, (sprint backlog 1) já mostrou um resultado que provou que a integração multidisciplinar e a aplicação de uma metodologia ágil em um sistema crítico de tempo real, ainda que acadêmico, retornou resultados satisfatórios de todos os envolvidos, validando este tipo de metodologia para este tipo de sistema, geralmente desenvolvido utilizando o modelo cascata.
