Smart Meter Industrial
Release Backlog (SM-IND)
Histórico da Revisão
Data Versão Descrição Autor
21/Ago/2011 1.0 Emissão inicial. Giacomo de Lacerda Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho 18/Set/2011 2.0 Emissão 2.0 Giacomo de Lacerda
Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho 13/Out/2011 3.0 Emissão 3.0 Giacomo de Lacerda
Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho 31/Out/2011 3.0 Emissão 4.0 Giacomo de Lacerda
Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho
Índice Analítico
1. Introdução ... 4
2. Release Backlog ... 4
3. Sprint Backlog I ... 10
4. Sprint Backlog II ... 15
Tabelas
Tabela 1 - Priorização e detalhes das User Stories ... 4
Tabela 2 - Distribuição de User Stories pelos componentes ... 9
Release Backlog
1. Introdução
Este documento apresenta uma versão preliminar do Release Backlog do Projeto de desenvolvimento do sistema de software embarcado SM-IND. Ele contém a lista das quinze User Stories, retiradas do Product Backlog, que foram priorizadas, de acordo com os maiores valores para o cliente, e agrupadas de forma que, ao final dos Sprint Backlogs, seja possível entregar ao cliente, de forma incremental, produtos completos, que permitem ao mesmo fazer uso de todas as funcionalidades necessárias ao seu negócio.
2. Release Backlog
A Tabela 1 mostra a tabela com a priorização das User Stories:
Tabela 1 - Priorização e detalhes das User Stories
Prioridade User Story Estimativa Justificativa Status
Custo estimado em horas 1 Manter comunicação com o dispositivo central (US 4) 3 SP É necessário informar as medições realizadas ao dispositivo central e, para isso, é necessário estabelecer um protocolo de comunicação. Implementada no Sprint Backlog 1 32 2 Medir a demanda de energia da área 5 SP
É necessária uma medição diferenciada daquela realizada no setor Implementada no Sprint Backlog 2 24
Prioridade User Story Estimativa Justificativa Status Custo estimado em horas administrativa (US 9)
operacional. Isso inclui as divisões em subseções e medição da energia demandada pelas mesmas separadas. 3 Medir a demanda de energia da área operacional (fornos & motores) (US 10) 5 SP A medição do setor operacional lida com três fases e inclui os motores e os fornos da empresa. Implementada no Sprint Backlog 1 16 4 Medir a energia Eólica produzida pelos geradores (US 12) 2 SP É necessário medir a quantidade de energia produzida pelos moinhos de vento da empresa, a fim de abater da demanda total ou oferecer energia á concessionária. Implementada no Sprint Backlog 1 16 5 Medir a energia Solar produzida pelos geradores 2 SP É necessário medir a quantidade de energia produzida pelas placas solares, a fim de abater da
Implementada no Sprint Backlog 1
Prioridade User Story Estimativa Justificativa Status
Custo estimado em
horas
(US 13) demanda total ou oferecer
energia á concessionária. 6 Enviar medições ao SM – CEN (US 8) 3 SP É necessário que o conjunto de medições realizadas seja informado ao Smart Metter CENTRAL.
Implementada no Sprint Backlog 2 8 7 Medir a demanda total de carga (US 2) 1 SP
A medição desse valor é necessária para o cálculo do valor resultante e para proporcionar possíveis desvios em horários de maior demanda. Implementada no Sprint Backlog 1 24 8 Editar configurações do sistema (US 1) 2 SP
Para interagir com o hardware do sistema é necessária a criação de uma interface homem-máquina que permita a troca de informações. Implementada no Sprint Backlog 2 16 9 Emitir relatório geral de atividades 3 SP
Neste ponto o sistema pode ser configurado, já executa a medição da demanda total por energia e necessita mostrar todas as atividades
Implementada no Sprint Backlog 2
Prioridade User Story Estimativa Justificativa Status
Custo estimado em
horas
(US 3) realizadas e os valores
registrados, para que sejam utilizados. 10 Manter registro dos outros SM (US 5) 5 SP
É necessário que todos os equipamentos tenham conhecimento do registro dos outros da rede, a fim de que o algoritmo de substituição seja acionado em caso de queda de um dos equipamentos. Implementada no Sprint Backlog 2 40 11 Implementar sistema de backup (US 6) 8 SP
É necessário que o sistema de software faça uma intervenção no sentido de determinar que um dos Smart Metters assuma a medição daquele que, porventura, sair de operação. Em especificação 32 12 Manter registro da posição geográfica 2 SP
É necessário que o sistema conheça a posição geográfica do SM em que está embarcado, visando
Em
Prioridade User Story Estimativa Justificativa Status
Custo estimado em
horas
(US 7) fornecer essa informação a
um nível mais alto do grande sistema onde está embutido. 13 Calcular o Fator de Carga (US 11) 3 SP É necessário o cáculo do fator de carga a fim de registrar as perdas de energia devido a campos eletromagnéticos Em especificação 8 14 Informar o Valor resultante (US 14) 1 SP É necessário calcular o valor resultante do processamento das energias produzida e demandada, para verificar o saldo devedor. Em especificação 8 15 Restaurar configurações originais (US 15) 1 SP
É necessário que haja uma funcionalidade que permita restaurar as configurações originais do sistema com um simples acionamento.
Em
especificação 4
Com a lista priorizada, é necessário atribuí-las aos componentes da Equipe de Desenvolvimento. A Tabela 2 mostra como ficou a divisão:
Tabela 2 - Distribuição de User Stories pelos componentes
Componente Description
Strauss
(Product Owner)
US 4 - Manter comunicação com o dispositivo central US 8 - Enviar medições ao SM – CEN
US 6 - Implementar sistema de backup
Rodriguez
(Scrum Master)
US 2 - Medir a demanda total de carga US 3 - Emitir relatório geral de atividades US 15 – Restaurar configurações originais
Lencioni
(Development Team)
US 9 - Medir a demanda de energia da área administrativa US 13 - Medir a energia Solar produzida pelos geradores US 11 - Calcular o Fator de Carga
Giácomo
(Development Team)
US 12 - Medir a energia Eólica produzida pelos geradores US 5 - Manter registro dos outros SM-IND
US 7 - Manter registro da posição geográfica
Zanetti
(Development Team)
US 10 - Medir a demanda de energia da área operacional (fornos & motores)
US 1 - Editar configurações do sistema US 14 - Informar o Valor resultante
3. Sprint Backlog I
O objetivo do Sprint Backlog I é entregar ao cliente um produto completo, utilizável e que tenha as seguintes características e capacidades:
• Capacidade de oferecer GUI (Graphical User Interface) que permitem que um usuário cadastrado no sistema execute-as para:
• Configurar os alarmes;
• Configurar o intervalo de tempo de medição de energia, com entradas de início e fim; • Solicitar a emissão de um relatório geral de informações.
• O sistema mantém um registro dos outros equipamentos da rede. • O sistema é capaz de medir a demanda total de energia
• O sistema é capaz de emitir um relatório geral de informações.
• O sistema é capaz de abrir um canal de comunicação com o sistema central.
3.1 Diagrama de domínio
A Figura 1 mostra o diagrama de domínio estabelecido para este Sprint Backlog. O projetista teve em mente que esta é uma abstração de alto nível, que depende de um projeto de Classes individual para cada característica que será implementada, segundo a Tabela 1, destinados a cada desenvolvedor, com a finalidade de permitir que o mesmo trasnforme a abstração do projeto em classes no Rational Rose Real-time.
A finalidade deste diagrama, imaginada pelo grupo, não é a de documentar o projeto, mas, sim, produzir artefatos que servirão de apoio ao desenvolvimento, estabelecer pontos de partida que tenham comprometimento de todos da equipe, executando boas práticas de desenvolvimento, neste caso, a geração automática de código através de diagramas UML. Ele serve de apoio procedimental aos programadores.
Figura 1 – Diagrama de domínio
Este diagrama de classes representa o domínio que é envolvido a partir das cinco User Stories escolhidas para o release. Ele mostra uma abstração da qual são retiradas as classes a serem implementadas pela equipe. Dessas classes é possível gerar código automaticamente, agilizando a organização e orientando o programador no desenvolvimento. A finalidade deste diagrama é gerar e organizar o código, ele não foi construído a título de documentação.
Após terminada a abstração do domínio do conjunto completo, que compõe o primeiro produto a ser entregue, foi feito o projeto individual, onde foram criadas as classes que serão efetivamente implementadas e, delas, é realizada a geração automática de código. A Figura 2 mostra a parte sob responsabilidade individual de cada aluno que será realizada no RRRT.
Figura 2 – Classes a serem implementadas em C++ na ferramenta RRRT
A parte individual que ficou sob responsabilidade deste autor, consiste na implementação de um conjunto de classes que permite que um dispositivo informe à sua rede onde ele está e receba dela o sinal de todos os outros dispositivos.
3.2 Projeto de Interfaces
O Projeto das interfaces ficou definido da seguinte forma:
Figura 3 – Menu principal
2. As configurações principais do sistema podem ser editadas.
Figura 4 - Configurações
Figura 5 – Medições de energia
As Interfaces Gráficas dão uma idéia da simplicidade da abordagem, visto que o display do equipamento é monocromático e de tamanho reduzido.
4. Sprint Backlog II
A idéia reservada como premissa para cada Sprint Backlog é entregar ao cliente um
produto que seja utilizável, considerando este termo como algo que ele possa, de imediato,
implantar e agregar valor para o funcionamento de seu negócio.
O objetivo do Sprint Backlog II é complementar a etapa anterior, aumentando o
número de funcionalidades disponibilizadas ao cliente do software SM - IND, fornecendo
capacidades que o tornam completo para o negócio. Na etapa anterior, o software estava
executando as seguintes funcionalidades:
• O Sistema é capaz de detectar equipamentos conectados e solicitando energia e,
acumular esses valores.
• O Sistema é capaz de manter um registro de status dos outros equipamentos da rede.
• O Sistema é capaz de registrar a energia solicitada e produzida pela indústria.
• O Sistema é capaz de medir a energia demandada pelos equipamentos.
• O Sistema é capaz de abrir um canal de comunicação com o Sistema SM – RED.
As novas User Stories implementadas em funcionalidades neste Sprint Development II
são:
US 1 - Editar configurações do sistema
US 3 - Emitir relatório geral
US 5 - Manter registro dos outros Smart Meters Industriais
US 8 - Enviar medições ao SM-CEN
4.1 Distribuição da implementação
A implementação foi distribuída entre a equipe de acordo com a Tabela 1:
Tabela 3- Distribuição das User Stories para Sprint Backlog 2
Componente Description
Strauss
(Product Owner)
US 1 - Editar configurações do sistema
Rodriguez
(Scrum Master)
US 3 - Emitir relatório geral de atividades
Lencioni
(Development Team)
US 5 - Manter registro dos outros SM-IND
Giácomo
(Development Team)
US 8 - Enviar medições ao SM – CEN
Zanetti
(Development Team)
