PR 02 SM IND 5.0 VISAO

(1)

L3GS Solutions

Smart Meter Industrial _{Versão: 5.0}

Visião (SM-IND) Data: 14/Nov /2011

PR_02_SM_IND_5.0_VISAO

Confidencial L3GS Solutions, 2011 Página 1

Smart Meter Industrial

Visão (SM-IND)

(2)

L3GS Solutions

Histórico da Revisão

Data Versão Descrição Autor

12/Ago/2011 1.0 Emissão Inicial. Giacomo de Lacerda

Luís Antonio Rodriguez Luiz Paulo Zanetti Luiz R. Lencioni Strauss Carvalho

15/Set/2011 2.0 Emissão 2.0. Giacomo de Lacerda

13/Out/2011 3.0 Emissão 3.0. Giacomo de Lacerda

31/Out/2011 4.0 Emissão 4.0. Giacomo de Lacerda

14/Nov/2011 5.0 Emissão 5.0. Giacomo de Lacerda

(3)

L3GS Solutions

Índice Analítico

1. Introdução ...4

1.1. Referências...4

2. Posicionamento...4

2.1. Descrição do Problema...4

2.2. Sentença de Posição do Produto...5

3. Descrições dos Envolvidos e Usuários ...5

3.1. Resumo dos Envolvidos ...5

3.2. Resumo dos Usuários...6

3.3. Ambiente do Usuário ...7

3.4. Resumo das Principais Necessidades dos Envolvidos ou Usuários...7

3.5. Alternativas e Concorrência ...8

4. Visão Geral do Produto...9

4.1. Perspectiva do Produto...9

4.2. Suposições e Dependências ...10

5. Recursos do Produto ...10

6. Outros Requisitos do Produto ...12

7. Arquitetura de software ...12

8. Release Backlog ...17

Sprint Backlog I ...24

Sprint Backlog II ...25

(4)

L3GS Solutions

Visão (SM-IND)

1. Introdução

O objetivo deste documento de Visão é coletar, analisar e definir as necessidades e características de alto nível do protótipo do Smart Meter Industrial – SM-IND, parte integrante do Sistema Smart Grids, que será desenvolvido na disciplina Sistema Embarcados de Tempo Real – CE-235 ministrada pelo Prof. Dr. Adilson Marques da Cunha no Instituto Tecnológico de Aeronáutica – ITA.

Ele enfoca os recursos que os envolvidos e usuários-alvo (Stakeholders) precisam, e descreve porque essas necessidades existem.

Este documento tem por finalidade principal propiciar a melhor definição possível dos requisitos de alto nível do protótipo do Smart Meter Industrial – SM-IND, em termos de necessidades dos usuários finais e as necessidades especificadas pelo professor na disciplina.

1.1. Referências

[1] Glossário – Documento que identifica alguns termos específicos utilizados.

[2] Product Backlog – Documento que identifica necessidades, requisitos, definição e priorização de tarefas e designação destas aos Stakeholders.

[3] Release Backlog – Documento que identifica as User Stories priorizadas para cada Sprint Backlog, e juntamente com as que serão implementadas no primeiro Sprint.

2. Posicionamento

2.1. Descrição do Problema

Esta subseção apresenta a descrição do problema e a alternativa de solução proposta representada pelo sistema.

O problema A medição atual do consumo de energia nas indústrias é realizado apenas de forma mecânica, e não leva em consideração a energia produzida pelas empresas.

afeta Indústrias, que necessitam comprar energia, e governo, para gerenciamento inteligente de recursos energéticos.

(5)

L3GS Solutions

cujo impacto é Gasto desnecessário de recursos e falta de

aproveitamento da energia gerada pelas empresas.

uma boa solução seria Desenvolvimento de um Smart Meter Industrial para a medição inteligente da energia produzida e consumida.

2.2. Sentença de Posição do Produto

Esta subseção descreve a Posição do Produto no mercado.

Para Indústrias

Quem Desejar uma maior economia de energia.

O SM-IND É um Item de Software de Computador.

Que Propicia a medição inteligente de energia elétrica.

Diferente de Demais produtos que realizam apenas medição mecânica. Nosso produto Realizará a medição e registro do comportamento da rede

elétrica, auxiliando a tomada de decisões referentes às instalações e o gerenciamento do consumo.

3. Descrições dos Envolvidos e Usuários

Esta seção descreve os envolvidos e os usuários que constituem o SM-IND e as principais necessidades que poderão ser abordadas pela solução proposta.

3.1. Resumo dos Envolvidos

A descrição dos envolvidos no desenvolvimento do Componente de Software de Computador SM-IND pode ser observada na tabela a seguir:

(6)

L3GS Solutions

Nome Descrição Responsabilidades

Prof. Dr. Adilson Marques da Cunha

Docente do ITA, responsável neste 2º semestre de 2011, pelas disciplinas CES-325 Sistemas Embarcados de Tempo Real e CES-63 Sistemas Embarcados.

- Especificar as necessidades iniciais do SM-IND;

- Especificar a arquitetura do hardware e do cenário que será desenvolvido o SM-IND; e

- Verificar e validar os requisitos especificados. - GIACOMO de L. A. Alves - Luís A. RODRIGUEZ - Luis P. ZANETTI - Luiz LENCIONI - STRAUSS Cunha Carvalho Alunos de Pós-Graduação nível mestrado e matéria isolada no ITA, cursando a disciplina CES-235 Sistemas Embarcados de Tempo Real.

- Transformação das necessidades em Requisitos

- Transformação dos requisitos em User Stories

- Definição de tarefas;

- Desenvolvimento do produto; - Documentação do produto

3.2. Resumo dos Usuários

Encontra-se abaixo a lista dos usuários identificados do SM-IND:

Nome Descrição Responsabilidades Envolvido

Smart Meter Central (SM-CEN) Central de gerenciamento de medidas do Sistema Smart Grids.

Recebe e armazena medições, atribui IDs de Smart Meters, envia programação, recebe e armazena alertas

(7)

L3GS Solutions

3.3. Ambiente do Usuário

Smart Meter Central (SM-CEN)

Descrição Smart Meter Central (SM-CEN) é responsável por gerenciar os demais Smart Meters. O SM-CEN recebe e armazena as informações das medições, identifica os Smart Meters pelo seu tipo e gerencia mensagens de alerta.

Tipo Software / Hardware

Responsabilidades Identificar o SM-IND pelo tipo e definir ID. Receber medições, enviar e receber mensagens de alerta.

Critérios de Sucesso Capacidade de identificar o SM-IND e gerenciar as informações recebidas. Envolvimento Utilização de componentes para registrar e acompanhar a medição a ser

executada.

Comentários /

Problemas

O desempenho pode ser comprometido em períodos de pico onde vários Smart Meters podem estar se comunicando com o SM-CEN, como também a dependência do hardware que será fornecido.

3.4. Resumo das Principais Necessidades dos Envolvidos ou Usuários

Necessidade Prioridade Preocupações Solução Atual Soluções Propostas Medir a demanda de carga e energia produzida e processar essas informações.

Alta Cálculo correto do valor resultante de energia.

Especificação do

N/A Utilizar tecnologia e fórmulas adequadas para aquisição e processamento de

(8)

L3GS Solutions

Necessidade Prioridade Preocupações Solução

Atual Soluções Propostas hardware a ser utilizado. dados. Manter comunicação com o Smart Meter Central, disponibilizando seu registro de identificação, localização geográfica e dados processados. Alta Especificação concreta da tecnologia transmissão de dados remotos e do GPS para registro da localização geográfica.

N/A Dentre as Soluções

Tecnológicas

disponíveis, escolher aquelas que sejam mais apropriadas, com a melhor relação custo / benefício. Permitir a configuração das medições, dos intervalos de medição e dos alarmes. Baixa Especificação detalhada das possíveis configurações.

N/A Padronizar tipos de alarme e modelos de medições.

Emitir relatório geral contendo informações referentes à medição realizada.

Alta Especificação do tipo de relatório, periodicidade da emissão.

N/A Definir opções de

escolha para o tipo de dado e tempo de medição a ser exibido no relatório.

(9)

L3GS Solutions

Por se tratar de um projeto inovador, em uma área de atuação que é de interesse de todos, centros de pesquisa ao redor do mundo estão com as atenções voltadas para o estudo da implantação de Smart Grids.

4. Visão Geral do Produto

Esta seção oferece uma visão de nível superior dos recursos do SM-IND, interfaces com outros aplicativos e configurações de sistema. Ela é constituída destas duas subseções:

• Perspectiva do Produto • Suposições e dependências

4.1. Perspectiva do Produto

O SM-IND é um Item de Software cujas funcionalidades requerem interfaces com o ambiente externo (sensores para coleta de dados), e com outro Item de Software (SM-CEN), para disponibilizar os dados coletados e, posteriormente processados, ao Sistema de Software.

O modelo de funcionamento do SM-IND, juntamente com suas interfaces pode ser observado na figura a seguir:

(10)

L3GS Solutions

Figura 1 – Perspectiva do Produto SM-IND.

Maiores detalhe sobre o funcionalidades do Item de Software SM-IND podem ser obtidas mediante consulta ao documento [2] Product Backlog desta versão.

4.2. Suposições e Dependências

Para a elaboração deste artefato de Visão assumiu-se que:

• Haverá um canal de comunicação entre o SM-IND e o SM-CEN;

• Sensores externos ao SM-IND serão utilizados para medição da energia consumida e produzida.

(11)

L3GS Solutions

O produto Smart Meter Industrial (SM-IND) tem o propósito de substituir medidores eletromecânicos presentes nas empresas atuais. As seguintes melhorias serão introduzidas com a utilização do produto SM-IND:

• Possibilidade de acompanhamento da energia consumida durante períodos do dia;

• Aproveitamento da energia produzida pela empresa, para abatimento na conta de energia elétrica consumida;

• Medida da qualidade da energia elétrica consumida e energia desperdiçada; • Configuração de alarmes para indicar problemas no sistema;

• Possibilidade de visualização remota da energia consumida e outras informações.

As funcionalidades específicas fornecidas pelo SM-IND estão descritas a seguir: 1) Medir a demanda total de carga

2) Medir a demanda de carga da área administrativa; 3) Medir a demanda de carga da área operacional; 4) Calcular o fator de carga;

5) Medir a energia eólica produzida; 6) Medir a energia solar produzida; 7) Manter comunicação com o SM-CEN; 8) Enviar medições ao SM-CEN;

9) Manter registro e posição geográfica; 10) Calcular energia resultante;

11Prover backup de informações; 12) Permitir configuração dos alarmes;

(12)

L3GS Solutions

14) Manter os registro de outros SM;

15) Emitir relatório geral.

6. Outros Requisitos do Produto

O Produto de Software deve utilizar-se ao máximo de softwares livres, de tal forma a obter alta flexibilidade e baixo custo na implementação do mesmo para o cliente. Sua interface de administração e operação deve ser simples e projetada de forma a facilitar o trabalho.

Desde o início, deve ser utilizado o modelo de desenvolvimento ágil, a fim de propiciar a constante evolução do sistema, de forma colaborativa, simplificando o desenvolvimento e a integração do SM-IND com o Sistema de Software Smart Grid.

Todo o desenvolvimento do Projeto deverá ser devidamente documentado.

Maiores detalhes das especificações, riscos e prioridades dos requisitos do Item de Software SM-IND poderão ser observados mediante consulta ao documento [02] Product Backlog desta versão.

7. Arquitetura de software

Para a definição da arquitetura de software do SM-IND, foi feita uma rastreabilidade das necessidades iniciais do cliente para um diagrama de domínio de classes.

A arquitetura do software do SM-IND é composta inicialmente por classes relacionadas entre si, que atendem as User Stories priorizadas para a implementação do primeiro Sprint Backlog.

Por se tratar de uma versão preliminar, o software do SM-IND deverá sofrer atualizações a cada Sprint Backlog. Conforme forem surgindo novas solicitações do cliente, o software terá seu escopo modificado, de acordo com as necessidades futuras.

Maiores detalhes sobre as definições das User Stories e suas respectivas priorizações podem ser obtidos mediante consulta ao documento Product Backlog [02] do projeto.

(13)

L3GS Solutions

Maiores detalhes sobre as User Stories definidas para o primeiro Sprint Backlog e os respectivos responsáveis pela implementação podem ser obtidos mediante consulta ao documento Release Backlog [03] do projeto.

A Figura 2 mostra o diagrama de classes definido para a implementação das User Stories priorizadas para a implementação do primeiro Sprint Backlog.

Figura 2 – Diagrama de domínio de classes do projeto SM-IND.

O diagrama de domínio da Figura 2 foi desenvolvido com o intuito de estabelecer objetos de domínio, a arquitetura do sistema e os atributos e operações das classes de objetos, de acordo com as regras de negócio estabelecidas com o cliente e em conformidade com normas.

Esse diagrama também tem a finalidade de orientar a ação dos programadores, permitindo, através da engenharia reversa, gerar código organizado e sincronizado com o Modelo da UML.

1

2

5

4

3

4

(14)

L3GS Solutions

Os grupos de classes foram divididos da seguinte forma:

Grupo 1 : Esse grupo de classes foi concebido para atender a característica da User Story I – Editar configurações do sistema“. Como um usuário autorizado a acessar o sistema, eu posso

modificar as configurações dos alarmes dos sistemas, assim como, do intervalo de tempo de medição.”.

A ideia mostrada no diagrama é a de uma “Interface”, ou, um tipo, que permite ser implementada por duas classes concretas, que são as interfaces gráficas, ou, o que vai ser mostrado no display do equipamento do usuário cadastrado. Uma “janela” serve para as configurações de tempo e outra para os alarmes. Ainda há a classe “Main”, que é a que aciona o software.

Grupo 2: Esse grupo de classes foi concebido para atender a característica da User Story II – Medir a demanda total de carga. “Como um interpretador de todo sinal elétrico que trafega pela rede, o

hardware do sistema deve armazenar o valor de toda a energia consumida pela empresa e transmitir esse valor ao sistema de software, para que o mesmo possa calcular o valor resultante ao final dos períodos de medição.” . Engloba todo o conjunto de classes e interfaces que realizam as operações de interpretar sinais recebidos relativos à quantidade de energia solicitada pela indústria em um determinado período de tempo.

Grupo 3: Esse grupo de classes foi concebido para atender a característica da User Story III –

Emitir relatório geral. “Como um usuário cadastrado e tendo acessado o sistema, posso acionar uma

funcionalidade que gere um relatório que contenha todos os dados processados pelo hardware do sistema, incluindo as modificações de configurações de sistema autorizadas com senha e a demanda por energia, detalhada por setor de cobertura.”. Engloba o conjunto de classes que aceita uma configuração de relatório e emite um relatório geral de atividades.

Grupo 4: Esse grupo de classes foi concebido para atender a característica da User Story IV –

Manter comunicação com o dispositivo central. “Como um usuário cadastrado e tendo acessado o

sistema, posso acionar uma funcionalidade que abra um canal de comunicação com o elemento central da rede de medidores, que servirá para a troca de mensagens entre os dispositivos comuns e o dispositivo central. Desejo, também, ter confirmação do canal aberto no display do hardware.”. Engloba o conjunto de classes que vai estabelecer a comunicação com o dispositivo central da rede, abrindo o canal e estabelecendo o tipo de protocolo que vai circular pela rede.

(15)

L3GS Solutions

Grupo 5: Esse grupo de classes foi concebido para atender a característica da User Story V –

Manter registro dos outros SM. “Como parte integrante de um conjunto de Smart Metters ligados em

rede, eu necessito saber informações de status de todos os outros equipamentos, incluindo seus Id’ s de rede, a fim de que, baseado nessas informações, possa ser executado o algoritmo de escolha para backup no caso de pane de algum equipamento.”. Engloba o conjunto de classes que permite que um dispositivo informe à sua rede onde ele está e receba dela o sinal de todos os outros dispositivos.

Os desenvolvedores utilizarão este diagrama como base para a implementação das User Stories definidas para o Sprint Backlog. A partir deste diagrama, a rastreabilidade para o desenvolvimento do código na ferramenta Rational Rose Real Time ficará mais clara para o desenvolvedor.

Maiores detalhes sobre as User Stories definidas para o primeiro Sprint Backlog e os respectivos responsáveis pela implementação podem ser obtidos mediante consulta ao documento Release Backlog [03] e ao Sprint Backlog [04].

A Figura 2 mostra o diagrama de Casos de Uso desenvolvido para a realização das User Stories priorizadas para o primeiro Sprint Backlog.

(16)

L3GS Solutions

Figura 3 – Diagrama de Casos de Uso do projeto SM-IND.

O diagrama de casos de uso foi desenvolvido com o intuito de estabelecer objetos de domínio, a arquitetura do sistema e os atributos e operações das classes de objetos, de acordo com as regras de negócio estabelecidas com o cliente e em conformidade com normas.

Esse diagrama também tem a finalidade de orientar a ação dos programadores, permitindo, através da engenharia reversa, gerar código organizado e sincronizado com o Modelo da UML.

Para atender ao diagrama de Casos de Uso criado, foram implementadas as seguintes classes e protocolos, :

• Classes Leitura e message: Classes responsáveis por manipular dados de leitura de sensores e, a estrutura de dados enviada ao SM-CEN, respectivamente.

• Protocolos MessageProtocol e ProtocoloSMIND: O protocolo MessageProtocol contém flags indicando o envio e o recebimento de uma mensagem. Já o ProtocoloSMIND

(17)

L3GS Solutions

contém flags para a indicação e mudança de estados do SM-IND, como: conexão, cálculo, medição, envio e recebimento de mensagem, escaneamento de SM.

• Cápsulas SMINDconexão, SMREDconexão e SMINDtestaConexão: Cápsulas que gerenciam a comunicação entre os SM-IND e SM-RED.

• Cápsula SMINDFacade: Cápsula responsável pelo gerenciamento da execução de tarefas do SM-IND. Inicializa o SM-IND, aguarda conexão, Lê arquivo de configuração, faz o escaneamento dos medidores, calcula o consumo e envia as medições.

8. 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 administrativa 5 SP

É necessária uma medição diferenciada daquela realizada no setor operacional. Isso inclui as

Implementada no Sprint Backlog 2

(18)

L3GS Solutions

Custo estimado em

horas

(US 9) 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 (US 13) 2 SP É necessário medir a quantidade de energia produzida pelas placas solares, a fim de abater da demanda total ou oferecer

(19)

L3GS Solutions

Custo estimado em horas 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

(20)

L3GS Solutions

horas atividades 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

Implementada

no Sprint

Backlog 3

(21)

L3GS Solutions

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. Implementada no Sprint Backlog 3 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. Implementada no Sprint Backlog 3 4 16

Ativar / desativar 1 SP É necessário que o sistema permita habilitar ou

Implementada no Sprint

(22)

L3GS Solutions

horas dispositivos desabilitar a medição de

equipamentos.

Backlog 3

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 US 16 – Ativar / desativar dispositivos

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

(23)

L3GS Solutions

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

(24)

L3GS Solutions

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.

(25)

L3GS Solutions

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

(26)

L3GS Solutions

Sprint Backlog III

Para esse Sprint Development, foi criada uma nova User Story (US16 - Ativar / desativar dispositivos), com o intuito de possibilitar investigações na rede elétrica e/ou instalação de novos equipamentos na indústria.

Sendo assim, o objetivo do Sprint Development III é entregar ao cliente um produto completo, utilizável e que tenha as seguintes características e capacidades:

• O Sistema é capaz de restaurar as configurações iniciais de funcionamento.

• O Sistema é capaz de informar o valor acumulado resultante da demanda e da produção de energia.

• O Sistema é capaz de editar as configurações do intervalo de medição a ser exibido. • O Sistema é capaz de calcular o fator de carga através das medições realizadas.

O Sistema é capaz de ativar / desativar dispositivos para medição

4.1 Distribuição da implementação

A implementação foi distribuída entre a equipe de acordo com a Tabela 3:

Tabela 3- Distribuição das User Stories para Sprint Backlog 3

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 US 16 – Ativar / Desativar dispositivos.

(27)

L3GS Solutions

(Scrum Master) 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