MatrigraniCF-RelPadCE235ListEx6-ProjFinaliii

(1)

INSTITUTO TECNOLÓGICO DE AERONÁUTICA

RELATÓRIO PADRONIZADO LISTEX6 CE-235

PROJETO FINAL

SISTEMAS EMBARCADOS DE TEMPO REAL

SMART METER CENTRAL

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 2011

(2)

SUMÁRIO

1 INTRODUÇÃO...4 1.1 Motivação...5 1.2 Contexto...5 1.3 Objetivo...6 1.4 Redução do Escopo...6 1.5 Especificação de Requisitos...6

1.5.1 Identificação dos Smart Meters da Rede...6

1.5.2 Localização dos Smart Meters da Rede...7

1.5.3 Envio e recebimento de Medições dos Smart Meters da Rede...7

1.5.4 Envio e Recebimento de Alertas para/ dos Smart Meters da Rede...7

1.5.5 Envio de Programação para Smart Meters da Rede...7

1.5.6 Detecção de Fraudes na Rede Energia...7

1.6 Organização deste Documento...7

2 DESENVOLVIMENTO...9

2.1 1a Fase – Sprint Backlog (SBK)...9

2.1.1 Estimativas utilizando Burndown Chart, e Planning Pocker ou outras ferramentas...9

2.1.2 Projeto e Alto Nível da Arquitetura...10

2.1.3 Modelagem Abrangente...11

2.2 2a Fase – 1º Sprint Development (SDV)...13

2.2.1 Modelagem Incremental...13

2.2.2 Desenvolvimento Incremental...15

2.2.3 Revisões e Ajustes SBK1...16

2.2.4 Agrupamento da Documentação...17

2.3 3a Fase – 2º Sprint Development (SDV) - Síntese da ListEx 4:...17

2.3.1 Modelagem Incremental;...17

2.3.2 Desenvolvimento Incremental, Integrações;...18

2.3.3 Revisões, Ajustes e Inicio do Fechamento do Projeto;...19

2.3.4 Agrupamento da Documentação e Lições Aprendidas...19

2.4 4a Fase – 3º Sprint Development (SDV)...20

2.4.1 Fechamento do Projeto e Integrações Gerais;...21

(3)

2.4.3 Lições Aprendidas...23

3 CONCLUSÃO...25

3.1 Conclusões...25

3.2 Recomendações...26

3.3 Sugestões para Trabalhos Futuros...26

REFERÊNCIAS BIBLIOGRÁFICAS...27

(4)

ANEXOS

ANEXO 1 – Gerenciamento de Projeto por Kanban Colaborativo. ANEXO 2 – Estimativas e Planning Poker

ANEXO 3 – Burndown Chart SBK1 ANEXO 4 – Diagramas SDV1 ANEXO 5 – Artefatos SDV1 ANEXO 6 - Diagramas SDV2 Estrutura SM Central SDV2 Estrutura UPC SDV2 Comportamento UPC SDV2.

Estrutura do SSG de Integração com Stub de Rede e Stubs de Comunicação SDV2. Comportamento capsula de atribuição de ID do SM-Central.

Comportamento capsula de medições do SM-Central. ANEXO 7 – Artefatos SDV2

ANEXO 8 – Gráfico Burndown Chart SDV2 Burndown Chart SDV2

ANEXO 9 – User Stories Pertencentes a cada Sprint ANEXO 10 - Diagramas SDV3

Estrutura do SM Central SDV3

Estrutura da Unidade de Processamento Central SDV3 Comportamento Unidade de Processamento Central SDV3 Estrutura Envio e Recebimento de Alertas

Comportamento Capsula Tabela Tarifas Estrutura SM CEN cenário final

Estrutura UPC cenário final Estados UPC cenário final

Capsula controle de Energia cenário final

Comportamento Capsula SM CENTRAL cenário final Interface SM CENTRAL para US 31 e 35.

Interface SM CENTRAL para US 35. ANEXO 11 – Artefatos SDV3

(5)

1 INTRODUÇÃO

Este projeto Final tem o objetivo de consolidar a aplicação dos principais conhecimentos teóricos adquiridos nas Disciplinas CES-63, CE-235 durante o processo de desenvolvimento do Protótipo do Sistema de Software Embarcado e de Tempo Real para o Projeto do Sistema Smart Grids (SSG), no segundo semestre de 2011, no Instituto Tecnológico de Aeronáutica, visando melhorar a eficiência e reduzir o desperdício de recursos envolvidos. A seção 1.1 mostra a motivação desta proposta, a 1.2 o contexto, a seção 1.3, o objetivo, a seção 1.4 a redução de escopo, a seção 1.5 apresenta os requisitos e a seção 1.6 apresenta a organização deste documento nos próximos capítulos.

1.1

Motivação

Este PBL – Problem Based Learning iniciado nas disciplinas CES-63, CE-235 e CE-230 no ITA – Instituto Tecnológico de Aeronáutica, com a temática de SmartGrids vem associar o desenvolvimento ágil aplicado na área de sistemas embarcados com uma temática de necessidade contemporânea, as redes inteligentes.

Neste projeto o Autor deste documento vem participando como Gerente de Projeto na função de SCRUM Master do módulo central (Smart-Meter Central do projeto Smart Grids – SSG), um dos seis módulos que compões o PBL SSG.

O SM Central é um módulo vital para a função do SmartGrids pois agrega uma das principais vantagens de ser ter uma rede energética, o gerenciamento das medições e recursos visando a tomada de decisão, e a execução de decisões interagindo com os demais módulos

1.2

Contexto

O Smart Meter central é um módulo que vem principalmente permitir a gerencia das informações de uma rede energética para auxiliar a tomada de decisões e identificação de problemas.

(6)

Para isso tem a funcionalidade de gerenciar medições considerando, envio, recebimento e armazenamento, gerenciar as trocas de energia entre os medidores considerando transferência, envio e recebimento de autorização para possibilitar uma possível detecção de fraudes, identificação dos medidores, localização, envio e recebimento de alertas e programação.

1.3

Objetivo

Implementar e documentar um Medidor Central para uma rede energética no Problem Based Learning das disciplinas CE-235 e CES-63 no Instituto Tecnológico de Aeronáutica – ITA que provenha recursos mínimos para o gerenciamento das informações de uma rede energética auxiliando a tomada de decisões por meio da detecção de falhas ou fraudes, durante o segundo semestre de 2011.

1.4

Redução do Escopo

Um gerenciador de medições para uma rede energética inteligente capaz de prover o controle de transferência de energia, detectar fraudes e enviar alertas e programação para os medidores da rede identificados.

1.5

Especificação de Requisitos

Esta seção apresenta os requisitos em auto nível do modulo central do projeto do PBL descrito neste documento.

1.5.1 Identificação dos Smart Meters da Rede

O Smart Meter Central, quanto Identificação de Smart Meter na Rede, deverá ser capaz de registrar um smart meter remoto no sistema por meio de uma identificação, e retornar a identificação para o smart meter remoto.

(7)

1.5.2 Localização dos Smart Meters da Rede

O Smart Meter Central, quanto localização de smart meter na rede, deverá ser capaz de armazenar, receber e enviar o georeferenciamento de um smart meter remoto.

1.5.3 Envio e recebimento de Medições dos Smart Meters da Rede

O Smart Meter Central, quanto ao envio e recebimento de medições dos smart meters remotos, deverá ser capaz de armazenar, receber e enviar medições de/para um smart meter remoto.

1.5.4 Envio e Recebimento de Alertas para/ dos Smart Meters da Rede

O Smart Meter Central, quanto ao envio e recebimento de alertas para/dos smart meters da rede, deverá ser capaz de armazenar, receber e enviar alertas de/para um smart meter remoto.

1.5.5 Envio de Programação para Smart Meters da Rede

O Smart Meter Central, quanto ao envio de programação para Smart Meters da Rede, deverá ser capaz de armazenar, receber e enviar Alertas de/para um smart meter remoto.

1.5.6 Detecção de Fraudes na Rede Energia.

O Smart Meter Central, quanto a detecção de fraudes na rede energia, deverá ser capaz de, por meio do armazenamento da identificação do smart meter remoto, dados de trocas energéticos e medições, ser capaz de identificar irregularidades ou fraudes de um smart meter remoto na rede.

1.6

Organização deste Documento.

Este capítulo apresentou a motivação, objetivo, redução de escopo e a especificação de requisitos do Módulo Central do protótipo de medidores de energia do SSG trabalhado no PBL descrito neste documento. O Capítulo 2 apresenta a descrição do desenvolvimento do Protótipo do Sistema de Software Embarcado e de Tempo Real para o Projeto Sistema Smart

(8)

Grids, por Fases do Processo de Desenvolvimento Ágil – SCRUM. Capítulo 3, as conclusões, recomendações e sugestões para trabalhos futuros.

(9)

2 DESENVOLVIMENTO

Este capítulo apresenta a descrição do desenvolvimento do Protótipo do Sistema de Software Embarcado e de Tempo Real para o Projeto Sistema Smart Grids, por fases do processo de desenvolvimento ágil SCRUM.

Na seção 2.1, é mostrado o primeiro ciclo de planejamento denominado sprint Backlog 1 – SBK1 considerando estimativas utilizando Burndown Chart, e Planning Pocker, projeto alto nível da arquitetura; e modelagem abrangente.

Na seção 2.2 é mostrado o desenvolvimento do primeiro ciclo denominado sprint development 1 – SDV1 considerando a modelagem Incremental, Desenvolvimento Incremental e as revisões e ajustes.

Na seção 2.3 é mostrado o desenvolvimento do segundo ciclo denominado sprint development 2 – SDV2, modelagem incremental; desenvolvimento incremental, integrações, revisões, ajustes e inicio do fechamento do projeto, agrupamento da documentação e lições aprendidas.

Na seção 2.4 é mostrado o desenvolvimento do terceiro ciclo denominado sprint development 3 – SDV3 considerando fechamento do projeto e integrações gerais, agrupamento da documentação, e lições aprendidas.

2.1

1a Fase – Sprint Backlog (SBK)

Esta seção mostra o primeiro ciclo de planejamento denominado sprint backlog 1 – SBK1 considerando estimativas utilizando Burndown Chart, e Planning Pocker, projeto alto nível da arquitetura; e modelagem abrangente.

2.1.1 Estimativas utilizando Burndown Chart, e Planning Pocker ou outras ferramentas.

Para o planejamento foram executadas reuniões na casa de integrantes discutindo os itens a serem selecionados no Sprint Backlog – SBK, e Release Backlog – RBK, além da participação online em discussões sobre o desenvolvimento do projeto. O Gerenciamento do

(10)

projeto foi controlado em uma planilha colaborativa online disponível no Anexo 1 no final deste documento.

Durante a fase do planejamento de como seria implementado o SM-Central, os integrantes da equipe fizeram estimativas por meio de votação, na qual cada um dos membros atribuía um valor entre os primeiros números da sequência de Fibonacci (1,2,3,5,8,13,20...) conforme prioridade e um outro valor entre os mesmos números conforme esforço de cada user story. Os resultados de cada uma dessas tabelas está no Anexo 2 ao final deste documento.

Através das prioridades, foram definidas as user stories que pertenceriam aos sprint backlogs que seriam desenvolvidos ao longo do tempo. Com as user stories definidas, utilizou-se os esforços para distribuir de forma mais uniforme as responsabilidades das uutilizou-ser stories entre os membros.

Um outro tipo de estimativa foi feita através da metodologia Burndown Chart. O resultado dessa estimativa está pode ser visto no Anexo 3 – Burndown Chart SBK1 no final deste documento.

2.1.2 Projeto e Alto Nível da Arquitetura.

Inicialmente, o projeto inicial do Smart Meter começou com a definição, em alto nível, da arquitetura do sistema. O resultado dessa análise pode ser visto na Figura 1:

Figura 1: Modelagem inicial, em alto nível, do Smart Grids

(11)

2.1.3 Modelagem Abrangente.

Durante a primeira fase da modelagem abrangente, os membros da equipe do Smart Meter Central concentraram-se em realizar os Warm Ups e Labs referentes ao tutorial do software IBM Rational Rose Real Time – RRRT disponibilizados pelos professores.

Com isso, os membros passaram a ter algum domínio sobre o sistema de funcionamento do desenvolvimento de Software Baseado em Modelo (Model Driven Archtecture – MDA) no ambiente RRRT e, assim, tornou-se possível usá-lo para implementação das user stories durante os sprints desacoplando o desenvolvimento do código fonte da sua plataforma de hardware.

Através dos exercícios (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.

2.1.3.1 Utilização dos Labs e Warm-Ups (Know why).

Dos 8 warm-ups praticados e dos 7 Labs pertencentes aos tutoriais da IBM, para o desenvolvimento do sprint 1 de desenvolvimento, diversas funcionalidades foram extraídas do desenvolvimento destes exercícios, devidamente implementados e publicados na Listex2. A seguir são detalhadas cada uma das funcionalidades extraídas de cada warm-up ou lab, e aplicadas no projeto SM Central:

 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;

(12)

 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 agregação, herança e partes.

Os warm-ups serviram como base e exemplo. O próprio protótipo foi uma extensão do warm-up 7. Como cada warm-up influenciou diretamente no protótipo está melhor descrito abaixo.

2.1.3.2 Utilização dos Labs e Warm-Ups (Know How).

A utilização dos warm-ups ou labs na implementação técnica 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;

(13)

 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.

Esta seção mostrou o primeiro ciclo de planejamento denominado sprint Backlog 1 – SBK1 considerando estimativas utilizando Burndown Chart, Planning Pocker, projeto alto nível da arquitetura e modelagem abrangente.

Esta próxima seção mostrará o desenvolvimento do primeiro ciclo denominado sprint development 1 – SDV1.

2.2

2a Fase – 1º Sprint Development (SDV)

Esta seção mostra o desenvolvimento do primeiro ciclo denominado sprint development 1 – SDV1 considerando a modelagem Incremental, Desenvolvimento Incremental e as revisões e ajustes.

2.2.1 Modelagem Incremental

Logo no final do planejamento do primeiro sprint backlog, houve uma alteração na modelagem de alto nível do SSG, apresentada na Figura 2, o SM Central deixou de ter conexão

(14)

com todos os módulos, passando a se conectar com um (ou mais) SM de Rede que conectariam este aos demais SMs Remotos.

Aproveitando o escopo aberto da metodologia ágil aplicada em desenvolvimento de software embarcado, o projeto SM Central passou por sua primeira adaptação que modificou o planejamento inicial à nova realidade do cliente.

Figura 2: Alteração da modelagem alto nível, do Smart Grids

No início do primeiro sprint, foi desenvolvido uma idéia de modelagem do Smart Meter Central. Essa idéia consistia em mostrar, em alto nível, como seria o funcionamento do Smart Meter Central no contexto de implementação do mesmo no software Rational Rose Real Time. A base de todo funcionamento do Smart Meter Central foi uma cápsula chamada UPC (Unidade de Processamento Central) que foi a responsável por toda a comunicação entre o SM-Central e qualquer outro módulo interno (desacoplando intenamente as capsulas) seguindo um padrão de projeto denominado Façade. Além disso, a cápsula UPC foi responsável por distribuir corretamente a requisição que chega do SM Remoto para a cápsula que possa tratá-la corretamente.

Existem, também, outras cápsulas implementadas no SDV 1, todas as cápsulas possuem nomes que fornecem uma idéia clara de como elas funcionam. A Figura 3 mostra essa modelagem incremental inicial:

(15)

Figura 3: Modelagem inicial, em alto nível, do Smart Meter Central

2.2.2 Desenvolvimento Incremental.

Primeiramente foi desenvolvida uma instância que simula o dispositivo SM-Rede 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”.

Após esta fase que abstraiu o layout abrangente, a equipe implementou todas as user stories definidas para o primeiro sprint. Foram elas: Desenvolvimento da Unidade de Processamento Central (UPC); Recebimento Medições dos SM; Armazenamento de Medições; Atribuição de ID de SM; Recebimento de Alertas e Envio de Alertas.

2.2.2.1 User Stories Sprint Development 1

1 Desenvolvimento da Unidade de Processamento Central

(UPC) Gustavo 20

2 Recebimento Medições dos SM Alexandre 20

3 Armazenamento de Medições Armando 13

4 Atribuição de ID de SM Ciro 13

5 Recebimento de Alertas Paulo 20

6 Envio de Alertas Taynara 13

A user stories foram implementadas com sucesso, cumprindo os requisitos mínimos, suficientes e necessários para um funcionamento, com qualidade, do Smart Meter Central no

(16)

SDV1. Os diagramas e códigos fontes podem ser vistos no ANEXO 4 - Diagramas SDV 1 ao final deste documento.

A quantidade de linhas totais produzidas pelo desenvolvimento Sprint 1 do SM-Central são 1452 linhas de código, e os arquivos foram SMARTGIRDS.cpp, SMCEN.cpp e SMRED.cpp.

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.2.2.2 Interação interdisciplinar

A comunicação com a equipe de teste CE-237 e CE-230 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.3 Revisões e Ajustes SBK1.

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.

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, que embora não agregue um valor óbvio para o cliente, necessitou de recursos de mão de obra e se classificou como uma User Story para facilitar o gerenciamento, embora seja uma prática não recomendada pela metodologia SCRUM.

O Ajuste executado foi o adiamento da User Histories de envio de programação dando lugar a Unidade de Processamento Central. Assim, comparando a modelagem inicial com a

(17)

User Histories Estimadas 6 User Histories Desenvolvidas 6 User Histories Criadas 1 User Histories Adiadas 1

2.2.4 Agrupamento da Documentação.

Para devidamente documentar o Sprint de Desenvolvimento 1 – SDV 1 foram criados vários artefatos, entre eles, Visão, Glossário, PBK , RBK e SBK disponíveis nos link que podem ser vistos no ANEXO 5 - Artefatos SDV1 no final deste documento.

2.3

3a Fase – 2º Sprint Development (SDV) - Síntese da ListEx 4:

Esta seção mostra o desenvolvimento do segundo ciclo denominado sprint development 2 – SDV2, modelagem incremental, desenvolvimento incremental, integrações, revisões, ajustes e inicio do fechamento do projeto, agrupamento da documentação e lições aprendidas.

2.3.1 Modelagem Incremental;

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 tiveram que ser realizadas (escopo, prioridades, prazos, funcionalidades, etc.).

 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).

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

(18)

simulação do SM-Rede foi capaz de criar várias instâncias de conexão e até mesmo possibilitar 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.

2.3.1.1 User Stories Sprint Backlog 2 – SDV2

7 Envio de Programação/Dados Gustavo 13

8 Armazenamento de Alertas Alexandre 13

9 Recebimento de coordenadas de localização do Smart Meter Armando 13 10 Implementação do sistema de recuperação da rede

inteligente (Smart Grid) Ciro 13

11 Recebimento de tabela de tarifas Gustavo 13

12 Atualização de tabela de tarifas Paulo 13

13 Stub de conexão com o SM-Rede (INTEGRAÇÃO) Todos 13 14 Stub de desacoplamento de conexões (INTEGRAÇÃO) Todos 13

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.

2.3.2 Desenvolvimento Incremental, Integrações;

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. Os diagramas desenvolvidos podem ser vistos no Anexo 6 - Diagramas SDV 2 ao final deste documento.

(19)

2.3.3 Revisões, Ajustes e Inicio do Fechamento do Projeto;

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º ciclo junto ao Cliente e, portanto, não foi detalhada como necessidade para o primeiro sprint de desenvolvimento.

A tabela 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.3.4 Agrupamento da Documentação e Lições Aprendidas.

Para devidamente documentar o Sprint de Desenvolvimento 2 – SDV 2 foram atualizados os vários artefatos existentes, e outros foram criados, entre eles, Visão, Glossário, PBK , RBK e SBK2 disponíveis nos link que podem ser vistos no ANEXO 7 - Artefatos SDV2 no final deste documento.

2.3.4.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

(20)

gráfico Burndown chart. 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. O gráfico Burndown Chart pode ser visto no Anexo 8 - Gráfico Burndown Chart SDV2 no final deste documento.

Buscando oferecer uma maior transparência para o Cliente sobre as questões que acercam o desenvolvimento do SM-Central, reuniões presenciais foram realizadas 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.

Esta seção mostrou o desenvolvimento do segundo ciclo denominado sprint development 2 – SDV2, considerando a modelagem incremental; desenvolvimento incremental, integrações, revisões, ajustes e inicio do fechamento do projeto e o agrupamento da documentação e lições aprendidas.

A seção 2.4 mostrará seção mostra o desenvolvimento do terceiro ciclo denominado sprint development 3 – SDV3.

2.4

4a Fase – 3º Sprint Development (SDV).

Esta seção mostra o desenvolvimento do terceiro ciclo denominado sprint development 3 – SDV3 considerando fechamento do projeto e integrações gerais, agrupamento da documentação, e lições aprendidas.

(21)

2.4.1 Fechamento do Projeto e Integrações Gerais;

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 de acordo com o cenário do projeto final e adaptou a prioridade das user stories cascateando-as para um quarto e quinto sprint de desenvolvimento. Diante de uma nova informação, definida pelo Cliente após o término do segundo sprint de desenvolvimento o qual o processo de integração de acordo com o cenário definido deverá ser prioridade para o terceiro sprint, diversas alterações estratégicas tiveram que ser realizadas (escopo, prioridades, prazos, funcionalidades, etc.).

Foram definidas 6 Users Stories principais priorizando o cenário para o projeto final proposto pelo cliente. O cenário que o cliente priorizou é descrito a segur.



SM-CEN:

o Conferência entre os valores armazenados localmente e valores registrados em cada Smart Meter. Resultado esperado: valores idênticos; e

o Identificação de possível roubo de energia, através da comparação entre energia consumida pela rede e energia registrada pelos smart meters da rede. Cenário previsto: roubo de energia na rede gerenciada por SM-RED1. Resultado esperado: identificação, por parte de SM-RED1, de possível roubo de energia.

Novamente foi utilizado o recurso de adaptação inerente às metodologias ágeis e de ecopo aberto visando agregar mais valor às entregas para o cliente. Foram definidas 6 Users Stories priorizando o cenário para o projeto final proposto pelo cliente, quatro criadas e duas verificadas nas existentes, são elas descritas na subseção 4.2.1.1:

2.4.1.1 User stories Sprint Development 3

1

5 Determinação da quantidade de energia a serenviada Alexandre 13 3

4 Solicitar medição local em Smart Meter remoto Paulo 13 3

5

Comparar valor armazenado localmente no

SM-CEN com o valor armazenado no SM remoto Taynara 13 3

6 Receber pedido de energia Armando 13

(22)

7 3

1 Detecção de fraudes de energia Ciro 8

2.4.1.2 Resumo das User Stories

Os sprints 1, 2 e 3 foram priorizados segundo o que mais oferecia de valor para o cliente segundo às adaptações às necessidades emergenciais como mostra a tabela, abaixo:

1 User Stories Sprint BackLog 1 – Principal Valor: Funcionalidades_Principais 2 User Stories Sprint BackLog 2 – Principal Valor: Integração

3 User Stories Sprint BackLog 3 – Principal Valor: Cenário proposto_pelocliente

Abaixo os possíveis sprints 4 e 5, com os itens faltantes, resultantes da priorização, ou que agregavam menos valor ao negócio do cliente.

4 User Stories Sprint BackLog 4 5 User Stories Sprint BackLog 5

Todas as user stories separadas por sprint podem ser vistas no Anexo 9 – Todas as User Stories no final deste documento.

O 3º sprint de desenvolvimento teve que ser reestruturado devido à do atendimento ao cenário proposto pelo cliente descrito no inicio desta seção, como cenário principal do projeto final, para avaliação da integração entre os dispositivos Smart Meters. Esta necessidade não foi totalmente esclarecida durante o processo de planejamento no 1º ou 2º ciclo junto ao Cliente e, portanto, não foi detalhada como necessidade para o primeiro e segundo sprint de desenvolvimento.

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.

(23)

Para a aferição das funcionalidades exigidas no cenário proposto, o projeto final, O Anexo 10 – Diagramas SDV3 mostra os diagramas gerados no terceiro ciclo de desenvolvimento visando agregar o maior valor ao negócio.

A partir do contexto citado acima, o sprint development 3 deste projeto (3º SDV) priorizou as funcionalidades de mais valia ao cliente que atendessem aos requisitos exigidos na nova realidade. A metodologia de desenvolvimento ágil se provou adequada a esta realidade por seu auto grau de adaptação a alterações das necessidades do cliente.

Para as user story 15, 36 e 37 foi criada uma capsula de controle e de energia que como que controla o recebimento, determinação da quantidade de energia a ser enviada e armazenamento dos envios.

Para as user story 31 e 35 foi criado uma comportamento diretamente na capsula SM CENTRAL, baseado no wrm-up 4, esta exibira uma interface esperando um comando (como no eletronic Lock). Este comando poderá direcionar a uma determinada rotina.

Este comportamento entraria em um estado “esperandoComando” qua aguardaria a entrada de um comando, assim como no warm-up 4, uma transição question mostraria as opções de comando da interface do SM CENTRAL. A inserção de um comando dispara uma outra transição que executa um determinado código e retorna para o estado inicial aguardando o próximo comando.

Varias outras rotinas podem ser adicionadas posteriormente, mas as primeiras seriam a de requisição de medições a um SM Remoto. A de detecção de fraudes, que basicamente comparariam os arquivos armazenados de medição e envio de autorização para aquisição de energia.

2.4.2 Agrupamento da Documentação;

Para devidamente documentar o Sprint de Desenvolvimento 3 – SDV 3 foram atualizados os vários artefatos existentes, e outros foram criados, entre eles, Visão, Glossário, PBK , RBK e

(24)

SBK3 disponíveis nos link que podem ser vistos no ANEXO 11 - Artefatos SDV3 no final deste documento.

2.4.3 Lições Aprendidas.

Este tópico apresentará as lições aprendidas durante o desenvolvimento dos sprints.

2.4.3.1 Lições Aprendidas SDV 1.

O desenvolvimento ágil se mostrou completamente compatível a desenvolvimento de sistemas embarcados, contudo, o adendo da implementação baseada em modelo, embora muito produtiva, transpareceu que é exigente de profissionais capacitados tão quanto a implementação “handcodded”, pois necessita de conhecimento técnico e arquitetural, por vazes até maior do que o exigido de um desenvolvedor de códigos fontes.

A problemática da integração foi um estudo de caso similar a situações mercadológicas reais, por que exigiu negociação, trabalho em equipe e dedicação. Neste sprint development, a maturidade adquirida na implementação baseada em modelo também ajudou a implementar funcionalidades de maior complexidade, além das focadas em integração

O cenário proposto não foi apenas desafiador ao modulo central, mas a todos os smart meter, e agregou uma seriedade ao PBL que deu projeções para vislumbrar trabalhos em potencial.

O conhecimento e as lições aprendidas durante este estudo de caso veio contribuir muito para a formação tanto para um profissional de TI entrante no mercado, quanto para aqueles com certa experiência, e sem duvida no nível de pós-graduação.

(25)

3 CONCLUSÃO

3.1

Conclusões

Podemos concluir, que a integração das matérias CES-63, CE-235, CE-230 e CE-237 e o desenvolvimento de um único Projeto Smart Grids para tais matérias, facilitou o Desenvolvimento do Software, pois, desta forma nós tínhamos a certeza de ter em mãos um Código Fonte Testado(CE-237) e com Garantia de Qualidade(CE-230) do software como produto e como serviço. As equipes estiveram em constante comunicação, pois se tratava de um único produto (Smart Meter Central) e todos tinham o mesmo interesse e objetivo, desenvolver um produto com qualidade, confiável, seguro e testado utilizando os conhecimentos adquiridos em sala no segundo semestre de 2011.

O processo de desenvolvimento adotado utilizou a metodologia ágil o que aumentou a eficácia durante o desenvolvimento do Smart Meter Central. No primeiro Sprint houve um período de adaptação das novas técnicas ágeis de desenvolvimento, a maioria dos integrantes da equipe não obtiveram o sincronismo ideal em pouco tempo e não engrenados com as técnicas ágeis(SCRUM), já no segundo Sprint, com a equipe já acostumada e adaptada, o processo foi naturalmente seguido e executado, notamos que o processo estava mais maduro.

Para o segundo Sprint, com a experiência obtida do primeiro Sprint, algumas técnicas foram aperfeiçoadas para aumentar a agilidade e garantir a satisfação imediata do cliente para o produto Smart Meter Central.

O SCRUM foi a metodologia ágil adotado pelas equipes e suas boas práticas nos ajudaram na hora de verificar se os artefatos estavam sendo desenvolvidos adequadamente. Como trabalhamos com Sprints, a cada duas semanas, estavam entregando uma parte do projeto e caso tivesse algum ponto de melhoria no que se refere a qualidade, confiabilidade e segurança do produto, este ponto era rapidamente atualizado no próximo Sprint, ou seja, a cada 15 dias eram entregues um release do produto e realizado as auditorias previstas pela CE-230.

(26)

3.2

Recomendações

Foi percebido pela equipe de desenvolvimento que o tempo para internalizar o traquejo com o Software da IBM, o Rational Rose RealTime não foi o ideal, tendo em vista o curto tempo que tivemos para manipular uma grande quantidade de exercícios práticos. Tais exercícios são ideais para amadurecer a técnica de Programação Orientada a Modelo, até mesmo porque, para muitos, esta técnica simboliza um quebra de paradigmas, pois muitos nós fazemos parte da velha guarda(Escovadores de Bits e Bytes), desta forma recomendamos que para trabalhos futuros, que esta gama de exercício seja repassada aos alunos de forma fragmentada e antecipada(o mais breve possível).

Percebemos ainda que o tempo proposto para a integração de todos os módulos(Smart Meter) do Projeto Smart Grids, não foi o suficiente para aferir a qualidade, confiabilidade e segurança do conjunto Integrado de todos os outros módulos deste Sistema.

3.3

Sugestões para Trabalhos Futuros

Como sugestão para Trabalhos Futuros e Melhoria das disciplinas CES-63 e CE-235 ministrada neste semestre, acreditamos que poderia existir ListExes Integradas, ou seja, uma equipe de Desenvolvimento inicia o Processo, em seguida o trabalho fosse continuado pela equipe da CE-230 e então verificado pela CE-237, ae então, somente após a conclusão deste ciclo e com os devidos pareceres os desenvolvedores botariam as mãos novamente. Estas ListExes poderiam ser dadas no início do semestre, ou seja, o processo de desenvolvimento seria o mais breve possível e cada uma delas evoluindo paralelamente com o desenvolvimento das respectivas disciplinas.

Outra sugestão para Melhoria para aumentar a integração e comunicação das disciplinas seria a realização de encontros reais com todas as equipes e turmas, pelo menos um por bimestre, com data estipulada pelo professor.

(27)

REFERÊNCIAS BIBLIOGRÁFICAS

Cunha, Adilson Marques, Sistemas Embarcados de Tempo Real. Disponível em: <https://sites.google.com/site/ce235ita/>. Acessado em: 27 de novembro de 2011. Cunha, Adilson Marques, Sistemas Embarcados. Disponível em:

<https://sites.google.com/site/ces63ita/>. Acessado em: 27 de novembro de 2011. Cunha, Adilson Marques, Tópicos avançados em Teste de Software. Disponível em: <https://sites.google.com/site/ce237ita11/>. Acessado em: 27 de novembro de 2011.

Cunha, Adilson Marques, Qualidade, Confiabilidade e Segurança de Software. Disponível em: <https://sites.google.com/site/ce230ita>. Acessado em: 27 de novembro de 2011.

(28)

ANEXOS

ANEXO 1 – Gerenciamento de Projeto por Kanban Colaborativo.

(29)

ANEXO 3 – Burndown Chart SBK1

ANEXO 4 – Diagramas SDV1

Comportamento Stub do SM-Rede SDV1.

(30)

Comportamento do SM-Central SDV1.

(31)

Codificação Atribuição de ID.

(32)

Comportamento Envio de Alertas

ANEXO 5 – Artefatos SDV1

O Artefato GLOSSÁRIO pode ser baixado em:

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex3

O Artefato PBK pode ser baixado em:

O Artefato RBK pode ser baixado em:

O Artefato Sprint Backlog pode ser baixado em:

O Artefato VISÃO pode ser baixado em:

A apresentação executiva pode ser baixada:

O projeto e seus diagramas podem ser baixados em:

(33)

ANEXO 6 - Diagramas SDV2

Estrutura SM Central SDV2

(34)

Comportamento UPC SDV2.

(35)

Comportamento capsula de atribuição de ID do SM-Central.

Comportamento capsula de medições do SM-Central.

ANEXO 7 – Artefatos SDV2

O Documento VISÃO pode ser visto em:

O Documento GLOSSÁRIO pode ser visto em:

O Documento PRODUCT BACKLOG pode ser visto em:

O Documento RELEASE BACKLOG pode ser visto em:

O Documento SPRINT BACKLOG 2 pode ser visto em:

(36)

https://sites.google.com/site/cmatripgita/disciplinas/sist-embarcados-tempo-real---ce235/listexes/listex4=1

A apresentação pode ser vista em:

ANEXO 8 – Gráfico Burndown Chart SDV2

Burndown Chart SDV2

ANEXO 9 – User Stories Pertencentes a cada Sprint

1 User Stories Sprint BackLog 1 – Principal Valor: Funcionalidades_Principais 2 User Stories Sprint BackLog 2 – Principal Valor: Integração

3 User Stories Sprint BackLog 3 – Principal Valor: Cenário do projeto final_{descrito no item 1.2 deste documento} 4 User Stories Sprint BackLog 4

5 User Stories Sprint BackLog 5

1 Desenvolvimento da Unidade de Processamento_{Central (UPC)} Gustavo 20

2 Recebimento Medições dos SM Alexandre 20

3 Armazenamento de Medições Armando 13

4 Atribuição de ID de SM Ciro 13

5 Recebimento de Alertas Paulo 20

6 Envio de Alertas Taynara 13

(37)

8 Armazenamento de Alertas Alexandre 13 9 Recebimento de coordenadas de localização do_{Smart Meter} Armando 13 1

0

Implementação do sistema de recuperação da

rede inteligente (Smart Grid) Ciro 13

1

1 Recebimento de tabela de tarifas Gustavo 13

1

2 Atualização de tabela de tarifas Paulo 13

1

3 Stub de conexão com o SM-Rede (INTEGRAÇÃO) Todos 13 1

4 Stub de desacoplamento de conexões(INTEGRAÇÃO) Todos 13 1

5 Determinação da quantidade de energia a serenviada Alexandre 13 3

4 Solicitar medição local em Smart Meter remoto Paulo 13 3

5 Comparar valor armazenado localmente no SM-CEN com o valor armazenado no SM remoto Taynara 13 3

6 Receber pedido de energia Armando 13

3

7 Armazenar log do envio de energia Gustavo 8

3

1 Detecção de fraudes de energia Ciro 8

1

7 Bloqueio de recebimento de energia de formaremota Armando 8 1

8 Habilitação de recebimento de energia de formaremota Ciro 8 1

9 Criação de lista de conexões Gustavo 8

2

0 Atualização da lista de conexões Paulo 8

2

1 Implementação de sistema de backup Taynara 8 1

6 Determinação da quantidade de energia a serrecebida Alexandre 5 2

2 Restauração para as configurações originais Alexandre 5 2

4 Monitoramento da voltagem da rede Ciro 5

2 5

Configuração de cadastro de configurações do

sistema Gustavo 5

2 6

Configuração de remoção de configurações do

sistema Paulo 5

2

7 Configuração de edição de configurações dosistema Taynara 5 2

8 Configuração de procura de configurações dosistema Alexandre 3 2

(38)

3

0 Emissão de relatórios Ciro 5

3

2 Detecção de roubo de energia Paulo 5

3

3 Implementação do sistema de criptografia Taynara 3 2

(39)

ANEXO 10 - Diagramas SDV3

Estrutura do SM Central SDV3

(40)

Comportamento Unidade de Processamento Central SDV3

(41)

Estrutura Envio e Recebimento de Alertas

Comportamento Capsula Tabela Tarifas

Estrutura SM CEN cenário final

(42)

Estados UPC cenário final

(43)

Comportamento Capsula SM CENTRAL cenário final

Interface SM CENTRAL para US 31 e 35.

Interface SM CENTRAL para US 35.

ANEXO 11 – Artefatos SDV3