• Nenhum resultado encontrado

relatorio projeto final V1

N/A
N/A
Protected

Academic year: 2021

Share "relatorio projeto final V1"

Copied!
15
0
0

Texto

(1)

Instituto Tecnológico de Aeronáutica

CE-245

Tecnologia da Informação

Prof. Dr. Adilson Marques da Cunha Prof. Dr. Luiz Alberto Vieira Dias

Projeto Final

José Luiz Moreira

(2)

Sumário

1. Introdução ... 4

1.1 Motivação ... 4

1.2 Contexto ... 4

1.3 Objetivo ... 4

1.4 Especificação de Requisitos do Protótipo de Aplicativo de BD ... 4

2. Desenvolvimento ... 5

2.1 Protótipo de Aplicativo de Banco de Dados Energia da Bateria Veicular ABD-ENB-VE ... 5

2.2 Metodologia Utilizada ... 5 2.3 Gerenciamento ... 5 2.4 Desenvolvimento ... 5 2.5 Infra-estrutura ... 5 2.6 SSC SSG ... 5 2.7 Setor Público ... 6 2.8 Veiculares(VE) ... 6

2.9 Energia da Bateria Veicular (ENB)... 7

2.10 Consulta Operacional 1 ... 8 2.11 Consulta Operacional 2 ... 8 2.12 Consulta Operacional 3 ... 8 2.13 Consulta Operacional 4 ... 9 2.14 Consulta Tática 1 ... 9 2.15 Consulta Tática 2 ... 10 2.16 Consulta Tática 3 ... 10 2.17 Consulta Tática 4 ... 10 3. Documentação ... 11

4. Exercício de Simulação de Jogos de Empresa ... 11

4.1 Cenário do Estudo de Caso de Jogos de Empresas com a SSG ... 11

(3)

4.3 Sprint ... 12 4.4 Tarefas ... 13 5. Conclusão ... 15

(4)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 4 of 15

1. Introdução

1.1 Motivação

No Brasil, os “apagões” que têm ocorrido na última década serviram como um alarme, mostrando aos cidadãos as limitações do sistema energético brasileiro.

Nos debates que se seguiram, as redes inteligentes (ou smart grids) ganharam cada vez mais espaço e, atualmente, recebem pesados investimentos como uma solução para o problema, proporcionando, entre outras coisas, diminuição de perdas de energia elétrica, diminuição de consumo nos horários de pico, previsão de possíveis falhas no fornecimento, recuperação automática e mecanismos contra o roubo de energia.

Aplicativos de banco de dados capazes de suportar tais redes representam a base para a implantação desse revolucionário conceito neste país.

1.2 Contexto

A fusão das Empresas SPR e SPU resultou na Holding denominada Empresa de Sistemas Smart Grids – SSG. Seus serviços abrangem a geração, distribuição, coleta e medição de energia, incluindo o controle de utilização de produtos elétricos diversos. Para isso, a SSG pretende utilizar um sistema inteligente de controle de energia que conta com uma vasta infra-estrtura, além de uma extensa base de dados georreferenciada contendo informações sobre seus clientes e produtos.

Aos funcionários da SSG coube o desafio de integrar os sistemas das empresas SPR e SPU, incorporando ainda as novas funcionalidades descritas nas diretrizes da nova empresa.

1.3 Objetivo

Propiciar à Empresa de Sistemas Smart Grids um sistema de software de computador que possibilite gerenciamento inteligente de consumo de energia, com aplicação de tarifas diferenciadas por períodos do dia, e rápida detecção de falhas de fornecimento de energia, até o final do primeiro semestre de 2011, visando aumentar a satisfação de seus clientes e coibir o consumo de energia nos horários de pico, diminuindo assim gastos desnecessários com aumento de infra-estrutura de geração e distribuição de energia.

1.4 Especificação de Requisitos do Protótipo de Aplicativo de BD

O Protótipo de Aplicativo de BD Holding SSG deverá ser capaz de propiciar:

• Medição de consumo automatizada, ocorrendo em momentos pré-determinados do dia; • Aplicação de tarifas diferenciadas por períodos do dia; e

(5)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 5 of 15

2. Desenvolvimento

2.1 Protótipo de Aplicativo de Banco de Dados Energia da Bateria Veicular

ABD-ENB-VE

Este Aplicativo de Banco de Dados de ENergia da Bateria VEicular (ABD-ENB-VE) deverá ser capaz de propiciar pelo menos as seguintes funcionalidades:

• Monitoramento do Nível de Energia da Bateria;

• Monitoramento da Carga do Alarme;

• Gerenciamento Operacional da Energia.

2.2 Metodologia Utilizada

2.3 Gerenciamento

Foi adotada a metodogia ágil de gerenciamento de projetos SCRUM.

2.4 Desenvolvimento

Não foi utilizada nenhuma metodologia para o desenvolvimento.

2.5 Infra-estrutura

Para a implementação do SSC SSG foi utilizada a seguinte infra-estrtura:

• Ferramenta de controle de versão Subversion (SVN); • Linguagem de programação Ruby;

• Framework de desenvolvimento Rails; e • SGBD Oracle 11g Spatial.

O projeto base do SSC SSG foi criado e disponibilizado no SVN pelo aluno Roberto Pepato Mellado. Cada aluno ficou responsável pela implementação das consultas operacionais associadas a sua USC, dentro do SSC.

2.6 SSC SSG

A página inicial do SSC SSG apresenta as consultas estratégicas e sub-menus direcionando a cada setor.

(6)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 6 of 15

2.7 Setor Público

A página destinada ao setor privado apresenta suas consultas táticas e sub-menus para seus componentes

2.8 Veiculares(VE)

A página destinada à indústria apresenta como opções de menu as unidades pertencente ao Componente de Software Veiculares

(7)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 7 of 15

2.9 Energia da Bateria Veicular (ENB)

Quando selecionado a USC será mostrada a tela abaixo:

Para esta Listex houve a necessidade de refazer as consultas para atender as mudanças a nível setorial. Abaixo são mostradas as consultas de minha USC - ENB no Banco Setorial.

(8)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 8 of 15

2.10 Consulta Operacional 1

2.11 Consulta Operacional 2

(9)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 9 of 15

2.13 Consulta Operacional 4

(10)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 10 of 15

2.15 Consulta Tática 2

2.16 Consulta Tática 3

(11)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 11 of 15

3. Documentação

Foi gerada a documentação do código-fonte do CSC e de cada USC que o compõe, utilizando uma ferramenta para geração de documentação de código-fonte específica para a plataforma Ruby on-Rails (RoR).Toda documentação gerada está disponível na minha home page.

Os screenshots do código fonte e da documentação gerada seguem abaixo:

Documentação gerada

4. Exercício de Simulação de Jogos de Empresa

4.1 Cenário do Estudo de Caso de Jogos de Empresas com a SSG

O Cenário deste Exercício de Jogos de Empresas, baseado nas Tecnologias da Informação, abrange o domínio de conhecimento dos Sistemas de Redes Inteligentes de Eletricidade (Sistemas

SmartGrids – SSG).

Este Exercício de Simulação de Jogos de Empresas contempla a situação de merge da Corporação de Serviços Públicos com a Corporação de Serviços Privados, formando a nova empresa “Holding de Redes Inteligentes de Eletricidade (Sistema Smart Grids – SSG)”. Esta Empresa sofrerá uma Reengenharia e deverá ser composta de Setores.

Esta nova empresa SSG revelou que adotará a seguinte política empresarial:

▪ Os ativos mais importantes da nova Empresa SSG deverão ser os seus Recursos Humanos. Dentre eles, em primeiro lugar, devem ser considerados sempre os seus Clientes;

▪ Seguindo o princípio da transparência, todos os Clientes da Empresa SSG deverão ser capazes de, através de relatórios, verificarem seus Extratos de Consumo no Tempo, assim como a Tarifa vigente no horário de cada medição;

▪ A iniciativa de Tarifação Diferenciada foi definida como um requisito de suma importância pelos executivos da Empresa SSG, pois inibe o consumo de energia elétrica nos “horários de pico”, diminuindo os riscos de “apagões” e a necessidade de investimentos desnecessários em ampliação de rede elétrica; ▪ Os Serviços da Empresa SSG deverão ser de “Qualidade Comprovada”;

▪ A Confiabilidade dos Produtos ou Serviços da Empresa SSG deverá ser garantida através do monitoramento ativo das condições das Unidades atendidas, de forma a identificar, o mais rápido possível, a ocorrência de Falhas no Fornecimento;

(12)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 12 of 15 ▪ O Gerenciamento de todos os Sistemas de Informação da nova Empresa SSG deverá ser realizado por meio de “Um Sistema de Banco de Dados HOLDING-CORPORATIVO Integrado, Seguro, Confiável, Robusto e de Médio/Grande Porte”;

▪ Todos os Funcionários da nova Empresa SSG deverão adotar uma postura ágil, cooperativa, colaborativa, progressista, inovadora, simplificadora, propiciando um desenvolvimento iterativo e

incremental, convergindo sempre para a obtenção de lucros, colaborando desta forma para o sucesso da nova Empresa como um todo a curto, médio e longo prazo; e

▪ O Novo Conselho de Diretores eleito nas Assembleias de ontem, dia 22/05/2011, deseja a todos integrantes da nova Empresa muitas felicidades no novo Empreendimento, e aproveita esta

oportunidade para comunicar que o “sucesso da nova empresa que se forma a partir desta data dependerá do empenho de todos, e principalmente, do grau de profissionalismo e seriedade com que cada um dos integrantes participar e atuar na nova Empresa SSG.”

4.2 Product Backlog

Analisando o Cenário do Estudo de Caso de Jogos de Empresas com a SSG, o Product Owner, em conjunto com o cliente, identificou e especificou as seguintes User Stories, em ordem de prioridade, e os incluiu no Product Backlog.

4.2.1 User Story – Histórico de Consumo

Modelo: Como um <PERFIL> eu posso/gostaria/devo <FUNCTION> para <VALOR AO NEGÓCIO> Como um consumidor de energia eu devo verificar meu histórico de consumo do mês corrente para moldar meus hábitos de consumo de forma a diminuir meus gastos.

4.2.2

User Story – Detecção de Falhas de Abastecimento

Modelo: Como um <PERFIL> eu posso/gostaria/devo <FUNCTION> para <VALOR AO NEGÓCIO> Como um provedor de energia elétrica eu gostaria de detectar falhas de abastecimento de energia para enviar equipes de reparo proativamente, aumentando assim a satisfação do consumidor.

4.3 Sprint

4.3.1 Sprint Backlog

O time decidiu que apenas o item “Histórico de Consumo” será desenvolvido neste Sprint, incorporando-o aincorporando-o Sprint Backlincorporando-og.

4.3.2 Meta do Sprint

Este sprint possui como meta a conclusão do item “Histórico de Consumo”.

4.3.3 Definição de Done

Um item do Sprint Backlog será considerado done (finalizado) se, e somente se, apresentar as seguintes características:

• Programa funcionando; e

(13)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 13 of 15

4.4 Tarefas

Durante o Sprint Planning as seguintes tarefas foram criadas.

4.4.1 Modelagem do Aplicativo de Banco de Dados

Status: completa.

A modelagem do aplicativo de banco de dados já se encontra completa, como resultado de Sprints anteriores.

Modelo Entidade-Relacionamento

4.4.2 Criação de CRUD para entidade CE245_TARIFA

Status: completa.

Criação de uma interface de criação, leitura, alteração e exclusão (Create, Retrieve, Update and

Delete) para e entidade CE245_TARIFA.

A entidade CE245_TARIFA contém as tarifas vigentes para as 24 horas de um dia. Cada tarifa é composta por:

• Hora início: Horário a partir do qual a tarifa passa a ser válida • Hora fim: Horário a partir do qual a tarifa deixa de valer;

• Valor: Valor da tarifa para consumo entre os horários de início e fim.

Basicamente: se Hora início <= Horário Consumo <= Hora fim, então tarifa se aplica.

4.4.3 Criação de CRUD para entidade CE245_CONSUMIDOR

Status: completa..

Criação de uma interface de criação, leitura, alteração e exclusão (Create, Retrieve, Update and

Delete) para e entidade CE245_CONSUMIDOR.

A entidade CE245_ CONSUMIDOR contém o cadastro de consumidores de energia elétrica. 5

Modelo Entidade Relacionamento

Cada consumidor possui os seguintes atributos: • Id: Identificador do consumidor; e

(14)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 14 of 15 Tela do sistema

4.4.4 Criação de CRUD para entidade CE245_CONSUMO

Status: completa..

Criação de uma interface de criação, leitura, alteração e exclusão (Create, Retrieve, Update and

Delete) para e entidade CE245_CONSUMO.

A entidade CE245_ CONSUMO contém os registros de consumo de energia, colhidos automaticamente por uma Plataforma de Coleta de Dados (PCD), para um determinado consumidor.

Cada registro de consumo é composto por: • Id consumidor: Identificador do consumidor;

• Data/Hora: Data e hora em que o consumo foi medido; e • Qtd: quantidade absoluta consumida até aquele momento.

4.4.5 Criação de um relatório de histórico de consumo por consumidor

Status: completa.

O relatório de histórico de consumo deve ser baseado no seguinte protótipo:

Protótipo

Funcionamento: uma vez selecionado um consumidor (sugestão: combobox com nomes de consumidores) seu histórico de consumo do mês corrente (a partir do dia 1) deve ser apresentado, ordenado inversamente em relação a sua data/hora (o registro mais recente é o primeiro da lista). Considerações importantes:

• Os dados devem ser retirados da entidade CE245_CONSUMO;

• A quantidade apresentada deve ser calculada subtraindo-se de seu atributo “Qtd” o atributo “Qtd” do registro seguinte.

(15)

Confidential ITA Instituto Tecnológico de Aeronáutica, Página 15 of 15 Exemplo: considerando-se os registros CE245_CONSUMO(1,‘05/06/2011 19:59’, 33872612) e

CE245_CONSUMO(1,‘05/06/2011 18:59’, 33872562), a quantidade seria 50 (33872612 – 33872562); • A tarifa é retirada da entidade CE245_TARIFA tomando por base a data/hora do registro. Os

recolhimentos dos registros de consumo de energia são agendados para sempre ocorrer de acordo com o atributo “Hora fim” das tarifas. Desta forma todo o período entre um registro e outro sempre estará contido dentro de uma única tarifa;

• O valor é calculado multiplicando-se a quantidade pela tarifa

5. Conclusão

Com a realização da CE-245, o aluno foi capaz de desenvolver os conhecimentos sobre desenvolvimento ágil de um Sistema de Software de Computador (SSC), e compreender os principais Artefatos do Processo Unificado Rational (Rational Unified Process – RUP) que foram aplicados para o seu componente de Software de Computador – Setor Público – Veiculares (SPU-VE), aumentando assim, o seu nível de eficiência na utilização dos recursos de informática para documentação.

A utilização da tecnologia Web Ruby on Rails, possibilitou, de uma forma padronizada e ágil, o desenvolvimento de uma aplicação com suas funcionalidades básicas (CRUD) no prazo desejado de uma maneira bastante tranquila.

Referências

Documentos relacionados

Curvas de rarefação (Coleman) estimadas para amostragens de espécies de morcegos em três ambientes separadamente (A) e agrupados (B), no Parque Estadual da Ilha do Cardoso,

Coniprclienilemlo que ao Brasil sò- monte falta o aperfeiçoamento da indu- stria, porquanto mais do que qualquer outro paiz dispõe do maioria prima de superior

afastamento para capacitação Stricto Sensu, até o limite de 4 pontos: 0,08 ponto por mês completo. Não tendo havido o afastamento do docente na instituição a contagem dos

Não podem ser deduzidas dos nossos dados quaisquer informações sobre uma dada característica específica, nem sobre a aptidão para um determinado fim. Os dados fornecidos não eximem

Os dois métodos possuem filosofias muito diferentes para a resolução do subproblema de região de confiança, pois o LSTRS é um método iterativo que só precisa usar

Um átomo do elemento químico x , usado como corante para vidros, possui número de massa igual a 79 e número de nêutrons igual a 45... UTILIZE AS INFORMAÇÕES A SEGUIR PARA

Então quando eu fui para esse primeiro curso eu pude refletir o que eu estava fazendo dentro da universidade, porque começava pela língua depois pela diversidade de alunos que a

• 3 noites no Hotel Atlas Medina (ou similar), em MARRAKESH, com café da manhã • 1 noite no Hotel Tour Hassan (ou similar), em RABAT, com café da manhã. CONDIÇÕES