INSTITUTO TECNOLÓGICO DE AERONÁUTICA
RELATÓRIO PADRONIZADO LISTEX4 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 4 tem por objetivo o relato padronizado da atuação do autor dentro de sua equipe (Smart Meter Central) nos requisitos enumerados abaixo:
1. Na Revisão do 2º Sprint Backlog (2º SBK) e na Elaboração do 2º Sprint Development (2º SDV), indicando as principais funcionalidades desenvolvidas no seu Produto do SSG, com ênfase nas funcionalidades de integração entre os Sub-Produtos do SSG ;
2. Na atualização dos Artefatos produzidos no 2º Sprint Development do seu Grupo (Visão, Glossário, Product Backlog, Release Backlog, Sprint Backlog, entre outros julgados necessários);
3. Na elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros também julgados necessários); e
4. Na elaboração de uma Apresentação Atualizada para o Cliente (contendo um 2º Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente, descrevendo códigos-fonte gerados para o seu Sub-Produto do SSG, em C++, com ênfase nas funcionalidades de integração, 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 ListEx4 teve como motivação uma iniciação no processo do segundo 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, proporcionando um know-how sobre integração dos dispositivos Smart Grids.
Um dos maiores impactos observados no desenvolvimento tradicional de projetos de sistemas embarcados de tempo real é a questão de integração entre dispositivos. A maioria dos projetos desta natureza possuem problemas de integração o qual implica na insatisfação do Cliente, perda de informações, funcionalidades implementadas que não são utilizadas, etc. Devido a este fato é que o Cliente do Smart Grids estipulou que o processo de integração deverá ser prioridade no segundo sprint de desenvolvimento do produto SM-Central.
2
2
PRINCIPAIS PASSOS REALIZADOS NO EXERCÍCIO
Este capítulo relata os principais passos realizados no exerciício. A seção 2.1 relata a participação individual e em grupo na revisão do 2º Sprint Backlog (2º SBK) e na Elaboração do 2º Sprint Development (2º SDV), a seção 2.2 mostra a Participação na Atualização dos Artefatos produzidos no 2º Sprint Development do seu Grupo (Visão, Glossário, Product Backlog, Release Backlog, Sprint Backlog, entre outros julgados necessários), a seção 2.3 relata a participação na elaboração, no RRRT, dos Diagramas necessários produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes, Estrutura, Estados; entre outros também julgados necessários) e, por fim, a seção 2.4, mostra a participação Na elaboração de uma Apresentação Atualizada para o Cliente (contendo um 2º Resultado Intermediário de Valor), envolvendo uma documentação mínima, necessária e suficiente, descrevendo códigos-fonte gerados para o seu Sub-Produto do SSG, em C++, com ênfase nas funcionalidades de integração, concentrando as suas execuções na máquina de desenvolvimento do LAB TEC da FCMF no ITA.
2.1
Participação na Revisão do 2º Sprint Backlog (2º SBK) e na
Elaboração do 2º Sprint Development (2º SDV), indicando as
principais funcionalidades desenvolvidas no seu Produto do
SSG, com ênfase nas funcionalidades de integração entre os
Sub-Produtos do SSG;
2.1.1 REVISÃO DO 2º SPRINT BACKLOG (2º SBK);
Pelo fato da ocorrência de re-trabalho no desenvolvimento do SM-Central focando em cápsulas e não em comportamento, as user stories (US) do segundo sprint de desenvolvimento foram alteradas. Esta alteração foi necessária para que a questão de integração pudesse ser realizada de acordo com as necessidades do Cliente. As funcionalidades implementadas no 1º sprint backlog para o dispositivo SM-Central são:
Desenvolvimento da Unidade de Processamento Central (UPC), que controla todos os sub-módulos do SM-Central (US1);
Recebimento e armazenamento de medições de outros Smart Meters (US2 e US3); Identificação de Smart Meters que necessitam comunicação com o SM-Central (US4); Recebimento e envio de alertas (US5 e US6).
As funcionalidades que fazem parte do 2º sprint backlog para o dispositivo SM-Central são:
Envio de programação/dados ao Smart Meter (US7); Armazenamento de alertas (US8);
Recebimento de coordenadas de localização de Smart Meters (US9); Implementação do sistema de recuperação (US10);
Recebimento e atualização de tabela de tarifas (US11 e US12); Stub de conexão com o SM-Rede (INTEGRAÇÃO) (US13); Stub de desacoplamento de conexões (INTEGRAÇÃO) (US14).
3 A funcionalidade “Stub de conexão com o SM-Rede“ surgiu da realidade do Cliente em ter uma integração com um modulo em desenvolvimento por outra equipe. O stub de simulação do SM-Rede será capaz de criar várias instâncias de conexão e até mesmo facilitar uma futura implementação de um teste de força bruta.
A funcionalidade “Stub de desacoplamento de conexões (INTEGRAÇÃO)” surgiu da realidade do Cliente em ter uma iminente necessidade do projeto funcionar remotamente sobre o protocolo TCP/IP. Desacopla a comunicação entre os Smart Meters para que uma atualização para sockets possa ser feita sem por em risco as funcionalidades que já estavam funcionando.
A tabela 1 abaixo descreve o status de todas as funcionalidades consideradas desde o início de desenvolvimento até o fim do 2º sprint de desenvolvimento do dispositivo SM-Central. As user stories em desenvolvimento são aquelas que já foram desenvolvidas, mas que ainda falta o teste de aceitação e homologação do Cliente. Somente após este processo é que a US poderá ser considerada como concluída. Duas US foram adiadas devido ao cronograma do projeto e às novas necessidades (2 novas US) identificadas como essenciais para a realização das tarefas pré-definidas com o Cliente. É importante ressaltar que 2 US foram mescladas devido ao comportamento produzido e complexidade avaliada pela equipe de desenvolvimento.
2.1.2 REVISÃO DO 2º SPRINT DEVELOPMENT (2º SDV);
O 2º sprint de desenvolvimento teve que ser reestruturado devido à necessidade de foco em integração entre os dispositivos Smart Meters. Esta necessidade não foi totalmente esclarecida durante o processo de planejamento no 1º bimestre junto ao Cliente e, portanto, não foi detalhada como necessidade para o primeiro sprint de desenvolvimento.
O planejamento inicial da equipe de desenvolvimento para o produto SM-Central levou em consideração o processo de integração com os demais Smart Meteres como necessidade somente para o terceiro e último sprint de desenvolvimento. Diante de uma nova informação, definida pelo Cliente após o término do primeiro sprint de desenvolvimento o qual o processo de integração deverá ser prioridade já para o segundo sprint, diversas alterações estratégicas teve que ser realizadas (escopo, prioridades, prazos, funcionalidades, etc.).
4
2.2
Participação na Atualização dos Artefatos produzidos no 2º Sprint
Development do seu Grupo (Visão, Glossário, Product Backlog,
Release Backlog, Sprint Backlog, entre outros julgados
necessários);
Os artefatos descritos abaixo foram atualizados de acordo com o status atual de desenvolvimento do dispositivo SM-Central pela equipe CES-63/CE-235:
• Documento VISÃO;
O Documento VISÃO pode ser visto em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/ArtefatoVIS%C3%83O-SM-CENTRAL4.0.pdf?attredirects=0&d=1
• Documento GLOSSÁRIO;
O Documento GLOSSÁRIO pode ser visto em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/ArtefatoGLOSS%C3%81RIO-SM-CENTRAL4.0.pdf?attredirects=0&d=1
• Documento PRODUCT BACKLOG (PBK); O Documento PRODUCT BACKLOG pode ser visto em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/ArtefatoPBK-SM-CENTRAL4.0.pdf?attredirects=0&d=1
• Documento RELEASE BACKLOG (RBK); O Documento RELEASE BACKLOG pode ser visto em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/ArtefatoRBK-SM-CENTRAL4.0.pdf?attredirects=0&d=1
• Documento SPRINT BACKLOG (SBK). O Documento SPRINT BACKLOG 2 pode ser visto em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/ArtefatoSBK2-SM-CENTRAL1.0.pdf?attredirects=0&d=1
2.2.1 Gráfico BurnDownChart;
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 2 de desenvolvimento, através do gráfico burndown chart (figura 8). 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.
Uma vez que a equipe de desenvolvimento é formada por integrantes distribuídos geograficamente, somente foi possível realizar poucas reuniões de desenvolvimento. Observado o gráfico burndown chart é possível observar que, devido a este fato, sempre o trabalho realizado está acima do esforço planejado.
5 Buscando oferecer uma maior transparência para o Cliente sobre as questões que acercam o desenvolvimento do SM-Central, somente uma reunião presencial foi realizada conforme a disponibilidade de todos os integrantes. Este fato não é o mais adequado para o desenvolvimento ágil, no entanto foi a única maneira encontrada por todos os integrantes da equipe de desenvolvimento do SM-Central.
2.3
Participação na elaboração, no RRRT, dos Diagramas necessários
produzidos pelo seu Grupo (Casos de Uso, Seqüência, Classes,
Estrutura, Estados; entre outros também julgados necessários); e
A reestruturação do dispositivo SM-Central definida como prioridade pela equipe de desenvolvimento não alterou a configuração interna do SM-Central conforme definido previamente. A figura 1 ilustra esta visão interna do dispositivo SM-Central.
6 A figura 2 a seguir ilustra os módulos desenvolvidos dentro do SM-Central.
Já a figura 3 ilustra as portas de comunicação da Unidade de Processamento Central (UPC), que integra todos os módulos funcionais dentro do dispositivo SM-Central.
A figura 4 ilustra a Unidade de Processamento Central que interliga todas as funcionalidades do dispositivo SM-Central e controle com eficiência e eficácia.
7 A figura 5 ilustra o processo computacional de integração do Central com o SM-Rede. É possível observar que caso o Cliente necessite a implantação do Smart Grids em computadores diferentes, basta somente trocar as duas unidades de integração entre os Smart Meters.
8 A figura 6 ilustra o processo de implementação de atribuição de ID do SM-Central.
A figura 7 ilustra o processo de implementação de medições do SM-Central.
O projeto e seus diagramas podem ser baixados em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/SMCENTRAL-ListEx4-31-10-2011.rar?attredirects=0&d=1
9
2.4
Participação na elaboração de uma Apresentação Atualizada para
o Cliente (contendo um 2º Resultado Intermediário de Valor),
envolvendo uma documentação descrevendo códigos-fonte
gerados para o seu Sub-Produto com ênfase nas funcionalidades
de integração, concentrando as suas execuções na máquina de
desenvolvimento do LAB TEC da FCMF no ITA;
A seguir são descritas a participações de todos os envolvidos durante o SEGUNDO sprint de desenvolvimento do SM-Central. É importante destacar que houve envolvimento de todos realizando as mesmas tarefas para que o escopo fosse obedecido e a entrega pudesse ocorrer com todas as funcionalidades definidas junto ao Cliente para este segundo sprint de desenvolvimento (“trabalho a 12 mãos”).
O desenvolvimento ágil emprega a filosofia de ser totalmente adaptável com as necessidades e obstáculos encontrados durante o processo de desenvolvimento de um determinado produto, visando sempre preservar o prazo, escopo, recursos e funcionalidades pré-estabelecidas com o Cliente.
Diante deste fato, todos os integrantes participaram no desenvolvimento de todas as user stories. O processo de desenvolvimento ágil mostrou que um esforço em conjunto de todos os integrantes para a necessidade em questão (integração) seria capaz de satisfazer o que foi proposto para este sprint de desenvolvimento. Abaixo são descritas a atuação do grupo de desenvolvimento:
• Ciro Matrigrani (SM), Alexandre Possebon (PO), Gustavo Matuck, Paulo André, Taynara Araújo e José Armando:
o Participação na reestruturação do SM-Central com foco em cápsulas e não em comportamento;
o Redefinição das user stories para o segundo sprint de desenvolvimento; o Criação e/ou adaptação (atualização) de todos os artefatos produzidos.
A apresentação pode ser vista em:
https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4/SmartMeterCentral.pptx?attredirects=0&d=1
10
3
CONCLUSÕES, RECOMENDAÇÔES E SUGESTÔES.
Torna-se necessário salientar que em nenhum momento foi definido pelo Cliente o modo como deveria ser implementado o SM-Central (ficou-se acordado um escopo aberto para a implementação).Diante deste cenário, a equipe de desenvolvimento focou no desenvolvimento do SM-Central através de comportamento e não de cápsulas. Mesmo assim todas as funcionalidades propostas para o primeiro sprint de desenvolvimento foram implementadas corretamente proporcionando o máximo de valor agregado ao Cliente.
A reunião ocorrida entre as equipes do SM-Central e também com as equipes de outros dispositivos ficou claro que a implementação do SM-Central deveria sofrer alterações baseada em cápsulas e não em comportamento. Ambas as maneiras estão corretas e proporcionam as funcionalidades definidas pelo Cliente, porém usando como base o foco em cápsulas o processo de integração será facilitado.
A motivação para que a equipe pudesse realizar o segundo sprint de desenvolvimento foi de absorver um know-how dos processos que norteiam a questão de integração entre os dispositivos. Como resultado foi possível observar um empenho maior para que as funcionalidades fossem implementadas corretamente conforme acordado com o Cliente.
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.
