Smart Meter Industrial
Sprint Backlog (SM-IND)
Histórico da Revisão
Data Versão Descrição Autor
13/Out/2011 3.0 Emissão inicial – Sprint Backlog 1 Giacomo de Lacerda Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho
31/Out/2011 4.0 Sprint Backlog 2 Giacomo de Lacerda
Luis Antônio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho
Índice Analítico
1. Introdução ... 4
2. Sprint Backlog ... 4
3. Sprint Development I... 10
3.1 Projeto da Interface Gráfica ... 11
Sprint Backlog
1. Introdução
Este documento apresenta uma versão preliminar do Sprint Backlog do Projeto de desenvolvimento do sistema de software embarcado SM-IND. Ele contém a lista priorizada das quinze User Stories, retiradas do Product Backlog, de acordo com os maiores valores para o cliente, e agrupadas de forma que, ao final do primeiro Sprint Development, seja possível entregar ao cliente um produto completo, que permite ao mesmo fazer uso de todas as funcionalidades consideradas necessárias ao seu negócio.
2. Sprint Backlog
A Tabela 1 mostra a tabela com a priorização das User Stories:
Tabela 1 - Priorização 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 (US 3) 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
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
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 para implementação das User Stories
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 Development I
O objetivo do Sprint Development I é entregar ao cliente um produto completo, utilizável e que tenha as seguintes características e capacidades:
• O sistema é capaz de medir a demanda total de carga.
• O sistema é capaz de medir energia consumida nas áreas administrativa e operacional. • O sistema é capaz de medir energia eólica e solar produzida.
• O sistema é capaz de abrir um canal de comunicação com o sistema central e enviá-lo medições realizadas.
A tabela abaixo apresenta a distribuição dos trabalhos entre os membros do grupo para implementação segundo as User Stories:
Tabela 3 – Sprint Backlog I
Release Backlog I Zanetti Rodriguez Strauss Lencioni Giácomo
US 2 - Medir a demanda
total de carga X
US 4 - Manter comunicação
com o dispositivo central X US 10 - Medir a demanda
de energia da área operacional (fornos & motores)
X
US 12 - Medir a energia Eólica produzida pelos geradores
X
US 13 - Medir a energia Solar produzida pelos geradores
3.1 Projeto da Interface Gráfica
O Projeto da interface do projeto SM-IND foi realizado em linguagem Python e apresenta a seguinte interface com o Usuário:
4. Sprint Development II
O objetivo do Sprint Development II é entregar ao cliente um produto completo, utilizável e que tenha as seguintes características e capacidades:
• 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.
A tabela abaixo apresenta a distribuição dos trabalhos entre os membros do grupo para implementação segundo as User Stories:
Tabela 3 – Sprint Backlog II
Release Backlog I Zanetti Rodriguez Strauss Lencioni Giácomo
US 1 – Editar configurações
do sistema x
US 3 – Emitir relatório geral x
US 5 – Manter registro de outros SM x US 8 – Enviar medições ao SM-CEN x US 9 – Medir energia da aera administrativa x
