UFPEif716/projetos/projetos20102/Projeto… · Web viewUniversidade Federal de Pernambuco – UFPECentro de Informática – CIn. Graduação em Ciência e Engenharia da Computação

Universidade Federal de Pernambuco – UFPECentro de Informática – CIn

Graduação em Ciência e Engenharia da Computação

UrbanautaEspecificação de Requisitos

Disciplina:Especificação de Requisitos e Validação de Sistemas

Professor:Jaelson Freire Brelaz de Castro

Equipe:Denys Lins de FariasLuiz Antônio Correia

Guilherme Ramalho MagalhãesHenrique Alexandre de Menezes Sabino Almeida

{dlf2, lac2, grm, hama}@cin.ufpe.br

Recife, 25 de Novembro de 2010

Urbanauta Versão 1.0Especificação de Requisitos – Urbanauta.doc Data da versão: 25/11/2010

Participação da equipe

Nome Esforço AssinaturaDenys Lins Farias 25%Luiz Antônio Correia 25%Guilherme Ramalho Magalhães 25%Henrique Alexandre de Menezes S. Almeida 25%

dlf2, lac2, grm, hama Página 1 25/11/2010


Sumário

1. Introdução.........................................................................................................................4

1.1. Motivação...................................................................................................................4

1.2. O problema identificado.............................................................................................4

1.3. Sobre a organização....................................................................................................4

1.4. Convenções para identificação de requisitos..............................................................5

1.5. Convenções para identificação dos casos de uso........................................................5

1.5.1. Estrutura dos casos de uso...................................................................................5

1.5.2. Prioridades dos casos de uso...............................................................................6

1.5.3. Descrição dos Atores............................................................................................6

2. Requisitos organizacionais.................................................................................................7

3. Requisitos funcionais.........................................................................................................8

3.1. Dispositivo Embarcado (módulo de detecção)........................................................8

3.2. Dispositivo Embarcado (módulo de comunicação).................................................8

3.3. Servidor...................................................................................................................9

3.4. Serviço de Mapa Online..........................................................................................9

4. Requisitos não-funcionais................................................................................................11

4.1. Requisitos de processo.............................................................................................11

4.1.1. Requisitos de implementação............................................................................11

4.1.2. Requisitos de padrões........................................................................................12

4.2. Requisitos de produto...............................................................................................12

4.2.1. Requisitos de usabilidade...................................................................................12

4.2.2. Requisitos de confiabilidade..............................................................................13

4.2.3. Requisitos de desempenho................................................................................13

4.2.4. Requisitos de segurança.....................................................................................14

4.3. Requisitos externos...................................................................................................14

4.3.1. Restrições legais.................................................................................................14

4.3.2. Restrições econômicas.......................................................................................15

4.3.3. Restrições de cronograma..................................................................................15

4.3.4. Requisitos de interoperabilidade.......................................................................15

5. Modelagem organizacional (i*)........................................................................................16

5.1. Modelo de Dependência Estratégica (Modelo SD)....................................................16

5.2. Modelo Estratégico de Razão (Modelo SR)...............................................................17

6. Modelagem funcional (casos de uso)...............................................................................18

7. Modelagem de requisitos não-funcionais (NFR framework)............................................19



8. Conclusão.........................................................................................................................20

Referência............................................................................................................................21

Anexo A – Técnicas utilizadas na coleta de dados...............................................................22

Entrevista narrativa..........................................................................................................22

Coleta de artefatos..........................................................................................................22

Anexo B – Entrevista narrativa.............................................................................................23

Anexo C – Artefatos coletados.............................................................................................25

Anexo D – Descrição dos casos de uso.................................................................................26

Dispositivo Embarcado....................................................................................................26

[UC01] Detectar Buraco...............................................................................................26

[UC02] Enviar Informações..........................................................................................27

Servidor............................................................................................................................28

[UC03] Inserir Buraco...................................................................................................28

Mapa Online....................................................................................................................29

[UC04] Cadastar Buraco...............................................................................................29

[UC05] Efetuar login.....................................................................................................30

[UC06] Efetuar logoff...................................................................................................31

[UC07] Exibir Mapa Demarcado...................................................................................31

[UC08] Agendar Reparação..........................................................................................32

[UC09] Remover Buraco...............................................................................................32

[UC010] Cadastrar Usuário..........................................................................................33

[UC11] Remover Usuário.............................................................................................34

[UC12] Alterar Usuário.................................................................................................35

Anexo E – Glossário.............................................................................................................36



1. Introdução

Este documento tem como objetivo descrever o problema identificado na fase do estudo de viabilidade e especificar e os requisitos para a solução identificada. Essa solução tem por foco um sistema de informação distribuído que deve funcionar a partir das informações capturadas pela utilização de algumas técnicas que serão descritas adiante.

O nosso objeto de estudo deste artefato é um sistema distribuído em diversos veículos de serviço público que utilizam módulos contendo acelerômetros e GPS para - analisando o padrão de trepidação - fornecer as coordenadas do buraco a um servidor online através de um sinal GPRS, a fim de mapear as áreas que apresentam maior trepidação (buracos).

1.1. Motivação

Anualmente acontecem cerca de 20.000 acidentes no Brasil por conta das más condições das estradas, sobretudo dos buracos. O processo para que o poder público possa consertar um buraco identificado em uma estrada ou até mesmo para que se possa obter uma indenização por um prejuízo no veículo causado por tal defeito é muito burocrático.

O ressarcimento por danos na estrada só pode ser solicitado quando há um dano real, substancial e mensurável; também é necessário que o interessado solicite ao menos três orçamentos por escrito, que especifiquem o que está danificado e qual é o valor gasto no conserto; fotos do local, testemunhas e informações como endereço do local do buraco são importantes para dar seguimento no seu pedido. Se o carro for utilizado como meio de trabalho, é possível requerer indenizações pelos dias perdidos enquanto o carro estava na oficina.

Ademais os buracos não deixam de surgir nos pavimentos e isso se deve a diversos fatores, tais como a falta de conservação adequada, ausências de galeria de águas pluviais, vida útil já ultrapassada, onde o asfaltamento foi feito de modo inadequado e, principalmente, o aumento do número de veículos que transitam pelas ruas da cidade.

1.2. O problema identificado

Devido à grande quantidade de estradas a ser monitoradas, a identificação dos buracos nas rodovias nem sempre acontece de maneira rápida. Isso atrapalha tanto a parte administrativa da EMLURB, que é a empresa responsável por fazer a manutenção das estradas, como também os usuários causando-lhes atrasos e danos aos veículos.

Este projeto surge diante da necessidade da EMLURB de tomar conhecimento dos buracos das rodovias de maneira rápida e barata a fim de que possa repará-los o mais rápido possível.

1.3. Sobre a organização

A EMLURB é uma Empresa Pública, constituída em 26 de abril de 1979, pelo executivo Municipal, com fundamento na Lei nº 13.535, dotada de personalidade jurídica de direito privado, com patrimônio próprio, autonomia administrativa e financeira, regida pelo seu Regimento Interno e Estatuto Social.



É vinculada à Secretaria de Serviços Públicos da Prefeitura do Recife, a qual é responsável pela infraestrutura urbana da cidade, pela administração do edifício-sede da Prefeitura do Recife e pelo comando da Guarda Municipal do Recife. Tem como objetivo, a prestação de serviços públicos de manutenção e conservação do sistema viário e das áreas verdes, a implantação e manutenção da rede de drenagem, pavimentação, iluminação pública, necrópoles e limpeza urbana.

A competência da EMLURB abrange apenas o território municipal, dividido em 6 regiões político-administrativas (RPA), mas cuja operação de manutenção das vias se dá em 4 áreas: RPA 1, RPA 2 e 3, RPA 4 e 5, e RPA 6.

A gestão dos serviços públicos de responsabilidade da empresa é dividida em 4 gerências principais: Gerência de Próprios e Obras Civis (GPO), Gerência de Iluminação Pública (GIP), Gerência de Necrópoles (GNE) e Gerência de Pavimentação e Drenagem (GPD), esta última responsável pelo serviço de manutenção das vias. Em relação à GPD, mais duas gerências estão diretamente relacionadas: uma Gerência Operacional de Planejamento e quatro Gerências Operacionais de Manutenção (cada uma relacionada a uma área de atuação diferente).

As três principais diretorias envolvidas com a GDP são: Diretoria Administrativa e Financeira (DAF), Diretoria de Manutenção Urbana (DMU) e a Diretoria de Limpeza Urbana (DLU). Além disso, o Centro de Controle (CCO) - que trata diretamente com a presidência - é responsável pela verificação, controle e exigência das gerências, inclusive da GPD.

1.4. Convenções para identificação de requisitos

Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados.

1.5. Convenções para identificação dos casos de uso

Por convenção, os casos de uso são indicados e referenciados por um indicador no formato [UCxx], onde xx se refere ao número do caso de uso.

1.5.1. Estrutura dos casos de uso

Cada caso de uso terá o seguinte formato:

Atores: Os modelos de usuários que utilizarão o caso de uso; Prioridade: Prioridade de implementação deste caso de uso; Entradas: Variáveis que serão passadas ao sistema; Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser

executado; Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso

seja concluído, podendo incluir fluxos de eventos secundários e/ou alternativos; Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for

executado;



Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser finalizado.

1.5.2. Prioridades dos casos de uso

Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o projeto perderá sua utilidade.

Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Contudo, essa utilização se dá de forma não satisfatória pelo cliente.

Desejável: Esse tipo de caso de uso poderá ser implementado em versões posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema atende as suas funcionalidades básicas.

1.5.3. Descrição dos Atores

Os atores são aqueles que interagem de alguma forma com o sistema. Eles são os funcionários da EMLURB responsáveis pelo monitoramento do sistema online.



2. Requisitos organizacionais

Os requisitos organizacionais devem satisfazer os objetivos da organização e definir a necessidade do sistema. Esses requisitos são:

Automatizar a detecção das condições das vias sem necessidade de um equipe de vistoria, realizando a manutenção das estradas e o reparo dos buracos a partir das informações coletadas.

Agilizar o processo de reportar as condições das vias e agendamento de reparos. Organizar de maneira mais eficiente a disposição de informações sobre pedidos de

reparo atendidos, facilitando a identificação dos buracos e tornando-a rápida e barata;



3. Requisitos funcionais

Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos estão agrupados de acordo com suas características.

3.1. Dispositivo Embarcado (módulo de detecção)

Esta seção descreve os requisitos para funcionamento do dispositivo embarcado que captura as informações sobre as condições das vias.

3.1.1. Detectar Buraco

Identificação: [RF01] Detectar Buraco

Casos de Uso relacionados: [UC01]

Descrição:Utiliza o acelerômetro para detectar variações bruscas na altura do eixo do veículo indicando que ele passou por cima de um buraco.

Prioridade: Essencial Importante Desejável

3.2. Dispositivo Embarcado (módulo de comunicação)

3.2.1. Enviar Informações

Identificação: [RF02] Enviar Informações


Descrição:Utiliza o módulo de comunicação GPRS para enviar buracos detectados automaticamente para o servidor central da EMLURB.


3.3. Servidor



3.3.1. Inserir Buraco

Identificação: [RF03] Inserir Buraco


Descrição:Insere no Banco de Dados informações sobre a localização do buraco (Coordenadas GPS) para que o sistema possa representa-lo no mapa.


3.4. Serviço de Mapa Online

3.4.1. Cadastrar Buraco

Identificação: [RF04] Cadastrar Buraco

Casos de Uso relacionados: [UC 04]

Descrição: Permite que o operador possa inserir manualmente um buraco clicando nas coordenadas do mapa.


3.4.2. Fazer Login

Identificação: [RF05] Fazer Login


Descrição:Certifica que um usuário pré-cadastrado possa ter permissão de modificação nas informações do banco de dados. Para isso, o usuário deve informar login e senha, não devendo haver outra maneira de entrar no sistema diferente desta.


3.4.3. Fazer Logoff



Identificação: [RF06] Fazer Logoff

Casos de Uso relacionados: [UC06]Descrição: Permite que o usuário saia do sistema.


3.4.4. Exibir Mapa Demarcado

Identificação: [RF07] Exibir Mapa Demarcado


Descrição:Dispõe os buracos cadastrados no Banco de dados como pontos coloridos no mapa informando regiões com maior concentração de pontos.


3.4.5. Agendar Reparação

Identificação: [RF08] Agendar Reparação


Descrição: Agenda o reparo de um buraco informando data limite para o trabalho.


3.4.6. Remover Buraco

Identificação: [RF09] Remover Buraco


Descrição: Remove Buraco do Banco de Dados e elimina marcação no Mapa após confirmação de reparo.




3.4.7 Cadastar Usuário

Identificação: [RF10] Cadastar usuário


Descrição: Permitir que o administrador possa cadastra informaçõoes sobre os operadores que pode operar o sistema.


3.4.8 Remover Usuário

Identificação: [RF11] Remover Usuário

Casos de Uso relacionados: [UC11]Descrição: Remove um usuário previamente cadastrado no sistema.


3.4.9 Alterar Usuário

Identificação: [RF12] Alterar Usuário

Casos de Uso relacionados: [UC12]Descrição: Altera informações sobre um usuário cadastrado no sistema.




4. Requisitos não-funcionais

Os requisitos não-funcionais estão relacionados às restrições e aspectos de qualidade do sistema. Abaixo estão as descrições desses requisitos, classificados em requisitos de processo, requisitos de produto e requisitos externos.

4.1. Requisitos de processo

4.1.1. Requisitos de implementação

4.1.1.1. [NFR01] Utilização da linguagem Python para o servidor WEB

Identificação: [NFR01] Utilização da linguagem Python para o servidor WEBCasos de usos relacionados: -Descrição: A parte do sistema WEB deve ser desenvolvida utilizando a

linguagem Python, integrada ao servidor PostgreSQL.Prioridade: Essencial Importante Desejável

4.1.1.2. [NFR02] Utilização da linguagem Java J2ME para o módulo do modem GPRS

Identificação: [NFR02] Utilização da linguagem Java J2ME para o módulo do modem GPRS

Casos de usos relacionados: -Descrição: O módulo do modem GPRS deve ser desenvolvido utilizando a

linguagem Java J2ME.Prioridade: Essencial Importante Desejável

4.1.1.3. [NFR03] Utilização do banco de dados PostgreSQL

Identificação: [NFR03] Utilização do banco de dados PostgreSQLCasos de usos relacionados: -Descrição: Esse sistema de banco de dados possibilita o uso do PostGIS,

necessário para a aplicação de sensoriamento geográfico dos buracos.




4.1.2. Requisitos de padrões

4.1.2.1. [NFR04] Utilização do SCRUM como metodologia de desenvolvimento

Identificação: [NFR04] Utilização do SCRUM como metodologia de desenvolvimento

Casos de usos relacionados: -Descrição: O emprego da metodologia SCRUM permite agilidade e

melhor gerenciamento dos desenvolvedores.Prioridade: Essencial Importante Desejável

4.2. Requisitos de produto

4.2.1. Requisitos de usabilidade

4.2.1.1. [NFR05] Mensagens de erro

Identificação: [NFR05] Mensagens de erroCasos de usos relacionados: UC04, UC05, UC06, UC07, UC08, UC09, UC10, UC11, UC12Descrição: O sistema deve utilizar mensagens de erro claras e objetivas a

fim de orientar o usuário a selecionar o problema, sem gerar grandes impactos no fluxo do sistema.


4.2.1.2. [NFR06] Manual do usuário

Identificação: [NFR06] Manual do usuárioCasos de usos relacionados: UC04, UC05, UC06, UC07, UC08, UC09, UC10, UC11, UC12Descrição: O usuário deve ter acesso a um manual que bem estruturado

contendo todas as informações relativas às funcionalidades do sistema de forma clara e objetiva.


4.2.1.3. [NFR07] Interface gráfica do sistema

Identificação: [NFR07] Interface gráfica do sistemaCasos de usos relacionados: UC04, UC05, UC06, UC07, UC08, UC09, UC10, UC11, UC12Descrição: O sistema deve possuir uma interface gráfica simples e

intuitiva, apresentando um mapa da cidade com as condições de superfície das vias. O usuário deve interagir com o mapa e



com os dados sem dificuldades.Prioridade: Essencial Importante Desejável

4.2.1.4. [NFR08] Indicação visual de buracos no mapa

Identificação: [NFR08] Indicação visual de buracos no mapaCasos de usos relacionados: UC04, UC07, UC08, UC09Descrição: Ao clicar nas indicações de buracos, devem ser apresentadas

informações dos mesmos, como data de detecção, status da reparação, tipo de asfalto, etc. Não deve haver dificuldades para gerenciar as indicações e os dados dos buracos.


4.2.2. Requisitos de confiabilidade

4.2.2.1. [NFR09] Disponibilidade

Identificação: [NFR09] DisponibilidadeCasos de usos relacionados: UC04, UC05, UC06, UC07, UC08, UC09, UC10, UC11, UC12Descrição: O sistema não poderá ficar indisponível por mais que 5% do

tempo de operação. Em caso de erros, o sistema deve se recuperar automaticamente, sem que se precise da intervenção do usuário.


4.2.3. Requisitos de desempenho

4.2.3.1. [NFR10] Tempo de resposta

Identificação: [NFR10] Tempo de respostaCasos de usos relacionados: UC04, UC05, UC06, UC07, UC08, UC09, UC10, UC11, UC12Descrição: O mapa, as indicações de buracos e os dados relativos aos

mesmos não devem demorar mais que 10 segundos para serem carregados.


4.2.3.2. [NFR11] Espaço de armazenamento

Identificação: [NFR11] Espaço de armazenamentoCasos de usos relacionados: UC03, UC04, UC08, UC09, UC10, UC11, UC12Descrição: Deve ser garantido um espaço de armazenamento livre de

pelo menos 30% da capacidade máxima de armazenamento



do servidor.Prioridade: Essencial Importante Desejável

4.2.4. Requisitos de segurança

4.2.4.1. [NFR12] Backup de dados

Identificação: [NFR12] Backup de dadosCasos de usos relacionados: UC03, UC04, UC08, UC09, UC10, UC11, UC12Descrição: Semanalmente devem ser executados backups de forma a

prevenir a perda de dados.Prioridade: Essencial Importante Desejável

4.2.4.2. [NFR13] Integridade

Identificação: [NFR13] IntegridadeCasos de usos relacionados: UC01, UC02, UC03, UC04, UC05, UC06, UC07, UC08, UC09,

UC10, UC11, UC12Descrição: Os dados armazenados devem estar corretos em relação aos

que detectados e transmitidos ao servidor.Prioridade: Essencial Importante Desejável

4.3. Requisitos externos

4.3.1. Restrições legais

4.3.1.1. [NFR14] Confidencialidade dos dados relativos ao governo

Identificação: [NFR14] Confidencialidade dos dados relativos ao governoCasos de usos relacionados:Descrição: Os dados da empresa e de seus funcionários devem ser

mantidos de forma sigilosa, acessíveis apenas aos seus respectivos detentores.




4.3.2. Restrições econômicas

4.3.2.1. [NFR15] Orçamento

Identificação: [NFR15] OrçamentoCasos de usos relacionados:Descrição: O custo com o desenvolvimento do sistema não deve

ultrapassar o custo estimado no estudo de viabilidade.Prioridade: Essencial Importante Desejável

4.3.3. Restrições de cronograma

4.3.3.1. [NFR16] Tempo de desenvolvimento

Identificação: [NFR16] Tempo de desenvolvimentoCasos de usos relacionados:Descrição: O tempo com o desenvolvimento do sistema não deve

ultrapassar em três meses o estimado no estudo de viabilidade.


4.3.4. Requisitos de interoperabilidade

4.3.4.1. [NFR17] Suporte aos principais navegadores

Identificação: [NFR17] Suporte aos principais navegadoresCasos de usos relacionados:Descrição: O sistema deve ser bem reproduzido ao menos nos

navegadores Internet Explorer, Mozilla Firefox, Google Chrome e Safari.




5. Modelagem organizacional (i*)

A modelagem organizacional utilizada é feita com base na notação i* (i estrela) [i*].

5.1. Modelo de Dependência Estratégica (Modelo SD)


Figura 1 - Modelo de Dependência Estratégica (Modelo SD)


5.2. Modelo Estratégico de Razão (Modelo SR)




Figura 2 - Modelo Estratégico de Razão (Modelo SR) com atores expandidos


6. Modelagem funcional (casos de uso)

Neste capítulo, os requisitos descritos anteriormente são modelados através de diagramas de caso de uso. O detalhamento dos casos de uso encontra-se no Anexo D deste documento.


Figura 3 - Modelagem dos requisitos funcionais (Casos de uso)


7. Modelagem de requisitos não-funcionais (NFR framework)

Segue abaixo o diagrama dos requisitos não-funcionais segundo o NFR framework, o qual descreve suas interdependências e operacionalizações.


Figura 4 - Modelagem dos requisitos não-funcionais (NFR framework)


8. Conclusão

Vimos neste documento uma descrição dos requisitos levantados para o desenvolvimento do sistema Urbanauta. Uma introdução ao problema, acompanhado de uma breve descrição, foi apresentada na seção 1.

Na segunda seção, foram expostos os requisitos organizacionais obtidos a partir da entrevista realizada junto à Gerência de Pavimentação e Drenagem (como apresentada no anexo B).

Em seguida foram apresentados todos os requisitos funcionais do sistema, isto é, todos os serviços que o Urbanauta deve oferecer aos seus usuários, segundo a definição do cliente.

Seguindo os requisitos funcionais, no capítulo 4 foram apresentados os requisitos não-funcionais, que irão definir restrições e aspectos de qualidade sobre como o sistema irá funcionar.

No capítulo 5, foi abordada a modelagem organizacional do sistema usando a notação i*, em que foram incluídos os modelos de dependência estratégica (SD) e o modelo estratégico de razão (SR) com os atores Urbanauta, GPD (Gerência de Pavimentação e Drenagem) e GOM (Gerência Operacional de Manutenção) expandidos. [i*]

No capítulo 6, dando continuidade à modelagem de requisitos funcionais, foi apresentado o diagrama de casos de uso, incluindo seus fluxos de eventos e dependências entre si. As descrições dos casos de uso se encontram no anexo D.

Finalmente, no capítulo 7, foi feita a modelagem dos requisitos não-funcionais utilizando o framework NFR, mostrando os refinamentos deles, explicitando operacionalizações e interdependências entre eles.



Referência

[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>. Acesso em: 25 nov. 2010.

[Projeto] Documento de Estudo de Viabilidade. Disponível em: <http://www.cin.ufpe.br/~if716/projetos/projetos20102/EMLURB.pdf>. Acesso em: 25 nov. 2010.

[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and Techniques , John Wiley & Sons, 1998.

[i*] i* - An Agent-oriented Modelling Framework. Disponível em: <http://istar.rwth-aachen.de/>. Acesso em: 25 nov. 2010.

[Artefatos] Conjunto de Artefatos de Requisitos. Disponível em: <http://www.wthreex.com/rup/portugues/process/artifact/ars_req.htm>. Acesso em: 25 nov. 2010.



Anexo A – Técnicas utilizadas na coleta de dados

Entrevista narrativa

Em resumo de acordo com [Disciplina], “o engenheiro de requisitos ou analista discute o sistema com diferentes stakeholders e obtêm um entendimento dos requisitos”. Detalhes da entrevista que tivemos com funcionários da EMLURB encontram-se no anexo B.

Coleta de artefatos

Segundo [Artefatos], “o conjunto de artefatos de requisitos captura e apresenta informações usadas para definir os recursos necessários do sistema.” Foram coletados dados sobre um primeiro modelo de referência para a apresentação do mapa e dos dados no site, como também e-mails recebidos do gerente do centro de controle. Detalhes sobre os artefatos coletados encontram-se no anexo C.



Anexo B – Entrevista narrativa

Nosso objetivo foi visitar a EMLURB para coletar dados sobre como é o procedimento de identificação, avaliação e reparação de buracos, de sua responsabilidade.

Através do assistente Joselmo Lins, fomos atendidos inicialmente por Midiaran Ferreira, gerente de área da GPD. Ela nos explicou que a identificação de buracos se dá através do recebimento de notificações de pessoas que ligam para a central telefônica 156 e através de equipes responsáveis por rondas e vistorias de problemas notificados.

Soubemos que a partir de 2008, as centrais telefônicas da EMLURB para tratamento de diversos problemas foram unificadas em um só sistema de atendimento designado pelo número 156, sob responsabilidade da prefeitura. Nessa central, ao notificar algum problema de manutenção urbana, o usuário cria um cadastro, especifica a localização e informações adicionais relativas ao problema, gerando um registro mapeado dessas notificações. Além disso, uma equipe motorizada em carros circula pela cidade identificando possíveis problemas. Quanto à possiblidade de atendimento web, o único recebimento de notificações se dá através de avisos em blogs encaminhados para a GPD.

Os registros são disponibilizados em um sistema informatizado assim que efetuados na central 156 e pela equipe de vistoria, permitindo que a gerente de área da GPD possa checá-los, enviar uma equipe de vistoria para verificar o problema, para então criar uma ordem de serviço a ser repassada para a empresa de manutenção contratada.

Os buracos são avaliados principalmente quanto à origem e quanto ao tipo de composição da via. Dentre as possíveis origens, foram citados: infiltração de galerias, serviços de manutenção da Compesa (Companhia Pernambucana de Saneamento) e depreciação. Os tipos de composição de via citados foram paralelepípedos, asfalto e placas de concreto.

De acordo com Midiaran, o número médio de buracos reparados mensalmente fica em torno de 3100 durante inverno e 4500 durante o verão. A GPD opera com 3 caminhões por RPA por dia (um caminhão durante o dia e dois durantes a noite) que se revezam cobrindo as quatro áreas de atuação, cada um reparando em média 20 buracos diariamente. A única exceção é a RPA do Centro, região mais crítica para a realização da manutenção das vias.

O trabalho diário da GPD consiste na verificação de notificações, na programação, execução e acompanhamento tanto de vistorias quanto de reparos, envolvendo uma média de 150 pessoas.

Por fim, ela nos explicou que o maior problema encarado é a execução de vistorias e reparos dentro do prazo com baixa aplicação de verba. Fatores apontados que contribuem negativamente para a execução das obras são a alta demanda e a verba insuficiente (junto com outros problemas graves da cidade) para a área de cobertura. A meta da GPD é atender 70% das solicitações mensais.

Em seguida, fomos atendidos pelo assessor de presidência César Maia no CCO. Ele nos explicou que é responsável pela produção de relatórios mensais nos quais é apresentada a evolução do desempenho da GPD, não avaliando os serviços em si.

Esse acompanhamento é representado por dados, tabelas e gráficos que expressam quatro valores básicos: demanda de solicitações, solicitações atendidas no prazo, solicitações



atrasadas e solicitações não atendidas. As demandas se dividem entre as internas (criadas pela própria EMLURB) e as externas (oriundas das solicitações).

São apresentados também mais dois valores indicadores do desempenho: índice de conversão - que expressa a relação entre a demanda atendida dentro ou fora do prazo - e o índice de eficiência - que expressa a demanda atendida dentro do prazo.

O assessor também é responsável por elaborar uma apresentação mensal da situação dos problemas em mapas para o prefeito da cidade.

Por fim, ele nos mostrou as médias mensais de requisições cadastradas e atendidas deste ano na operação tapa-buraco. A primeira média é de 159.5 requisições cadastradas por mês, e a segunda média é de 488.25 requisições atendidas por mês. Como ele próprio explicou, a quantidade de requisições atendidas ultrapassar a quantidade de requisições cadastradas é devido ao trabalho interno das equipes que atuam nas ruas da cidade.

A última pessoa com quem conversamos foi Mônica Knecht de Miranda, assessora da Diretoria Administrativa e Financeira (DAF). Ela nos informou sobre a verba destinada para a execução das obras de reparação. Como também nos havia dito Midiaran, o custo médio estimado somente para a reparação de pavimentos (operação tapa-buraco) é de R$ 10 milhões.

A verba para esse custo é levantada de duas maneiras: através da verba própria da prefeitura - sendo o último valor publicado em torno de R$ 1.537.000,00 - e através do fundo de vias públicas - sendo o último valor publicado em torno de R$ 6.900.000,00 -, ambos publicados na Lei Orçamentária Anual no site da prefeitura. Como a soma desses valores não alcança o custo médio estimado, a DAF recorre à prefeitura ou a outras instâncias requerendo complementação de verba.

Além disso, ela nos explicou que os demais custos - envolvendo o call center da central 156, a equipe administrativa, as gerências operacionais de planejamento e manutenção - são considerados custos indiretos. Esse tipo de custo não é definido diretamente pela prefeitura, sendo competência do DAF, constituindo um custo fixo e recorrente.

Seguem os contatos:

Midiaran Ferreira3355.5602

César Maia Gerente / Centro de Controle - CCOAssessoria da Presidência3355.5746 / 9488.6221



Anexo C – Artefatos coletados


Figura 5 - Modelo inicial de referência para a apresentação do mapa no site - http://mapas.ipea.gov.br/

Figura 6 – E-mails recebidos do gerente do Centro de Controle Operacional


Anexo D – Descrição dos casos de uso

Dispositivo Embarcado

[UC01] Detectar Buraco

Identificador: [UC 01]

Descrição: Detecta um buraco pela trepidação.

Atores: GPS, Acelerômetro e Sistema Embarcado.

Prioridade: Essencial

Pré-condições: O GPS deve estar ligado e sincronizado com os satélites e conectado com o sistema embarcado através da RS232. O acelerômetro deve estar conectado ao sistema embarcado através da RS232. O sistema embarcado deve estar sendo alimentado por uma fonte de tensão de 12 Volts.

Pós-condições: O sistema embarcado deverá enviar as informações, via GPRS, da posição do buraco.

Fluxo de Eventos Principal

1. O sistema embarcado faz a leitura do Acelerômetro e verifica se ouve trepidação;

2. O sistema embarcado detecta que ouve uma trepidação e então faz a leitura da posição do GPS.

3. O sistema embarcado realiza o envio das informações através do GPRS.

Fluxo Secundário 1

1. No passo dois do fluxo principal, o sistema embarcado detecta que não ouve trepidação;

2. O sistema volta ao passo um do fluxo principal.

Requisitos Não Funcionais Específicos NFR13



[UC02] Enviar Informações


Descrição: Envia as informações do buraco detectado.

Atores: Sistema Embarcado, GPRS e Servidor.


Pré-condições: O sistema embarcado deve estar sendo alimentado por uma fonte de tensão de 12 Volts. Deve haver uma comunicação entre o sistema embarcado e o modem GPRS através da RS232. O modem GPRS deve estar sendo alimentado por uma fonte de 5 Volts e deve haver um cartão SIM dentro do mesmo com créditos válidos.

Pós-condições: O GPRS deverá ter feito uma requisição para o Servidor.


1. O sistema embarcado transmite as informações ao modem GPRS via RS232 para serem enviadas;

2. O modem GPRS realiza a leitura das informações.

3. O modem GPRS cria uma requisição e realiza o envio dessa requisição ao Servidor.

Requisitos Não Funcionais Específicos NFR13



Servidor

[UC03] Inserir Buraco


Descrição: Insere no Banco de Dados informações sobre a localização do buraco (Coordenadas GPS) para que o sistema possa representá-lo no mapa.

Atores: Servidor.


Pré-condições: Deve existir a ocorrência de uma requisição.

Pós-condições: As informações sobre o buraco estará inserida no banco de dados.


1. O Servidor recebe a requisição;

2. O Servidor confirma se a requisição é válida;

3. O Servidor realiza a inserção das informações do buraco no Banco de Dados;

Fluxo Secundário 1

1. No passo dois do fluxo principal, o Servidor verifica que a requisição não é válida;

2. O Servidor ignora essa requisição e espera a ocorrência de uma nova requisição;

Requisitos Não Funcionais Específicos NFR11, NFR12, NFR13

Mapa Online



[UC04] Cadastar Buraco

Identificador: [UC 04]Descrição: O operador cadastra um buraco manualmente no sistema.Atores: OperadorPrioridade: EssencialPré-condições: O ator deve estar logado no sistema no momento da execução dessa

operação.Pós-condições: O mapa deve exibir uma sinalização nas coordenadas do mapa

cadastrado.Fluxo de Eventos Principal

1. Na tela do sistema o ator deve selecionar a opção de cadastrar um buraco;

2. O ator preenche informações sobre a descrição do buraco e informações da requisição.

3. Um janela pede a confimarção da operação.

4. O ator aperta OK e o buraco é cadastrado no sistema e exibido no mapa.

Fluxo Secundário 1

1. No passo quatro, o ator aperta Cancelar.

2. A operação é cancelada e o usuário retoma à tela em que anterior.

Requisitos Não Funcionais Específicos NFR05, NFR06, NFR07, NFR08, NFR09, NFR10, NFR11, NFR12, NFR13

[UC05] Efetuar login




Descrição: Autentica o usuário no sistema.Atores: OperadorPrioridade: EssencialPré-condições: O usuário deve estar previamente cadastrado no sistema.Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem

respeito.Fluxo de Eventos Principal

1. Estando na tela inicial do sistema, o ator deve preencher os campos “login” e “senha”;2. O ator então clica no botão “OK”.

Fluxo Secundário 1

3. O ator fornece um login não cadastrado no sistema;

4. A mensagem “Usuário inexistente” é exibida.

Fluxo Secundário 23. O ator fornece um login e uma senha não correspondentes;

4. A mensagem “Senha incorreta” é exibida.

Requisitos Não Funcionais Específicos NFR05, NFR06, NFR07, NFR09, NFR10, NFR13

[UC06] Efetuar logoff




Descrição: Finaliza o acesso ao sistema.Atores: Operador.Prioridade: EssencialPré-condições: O ator deve estar logado no sistema no momento da execução dessa

operação.Pós-condições: O ator deixa de ter acesso às funcionalidades do sistema. O sistema

retorna à tela inicial.Fluxo de Eventos Principal

1. O ator clica no botão “Sair”;

2. O sistema finaliza todas as operações que estão em execução devido às requisições feitas por esse ator.

Requisitos Não Funcionais Específicos NFR05, NFR06, NFR07, NFR09, NFR10, NFR13

[UC07] Exibir Mapa Demarcado

Identificador: [UC 07]Descrição: Exibe todos os buracos cadastrados no sistema dispostos em um mapa.Atores: Operador.Prioridade: EssencialPré-condições: O ator deve estar logado no sistema no momento da execução dessa

operação.Pós-condições: O mapa deve ser exibido.


1. O ator seleciona a opção de ver o mapeamento dos buracos;

2. O sistema verifica os buracos cadastrados no banco de dados e marca pontos nas coordenadas correspondentes do mapa.

3. O mapa é exibido para o operador.

Requisitos Não Funcionais Específicos NFR05, NFR06, NFR07, NFR08, NFR09, NFR10, NFR13

[UC08] Agendar Reparação




Descrição: Agenda reparação de um buraco.Atores: OperadorPrioridade: EssencialPré-condições: O usuário deve estar previamente cadastrado no sistema.Pós-condições: O agendamento deve ser registrado no banco de dados.


1. Estando na tela de exibição do mapa o ator pode clicar em um dos buracos demarcados;

2. Quando clicar em um dos buracos demarcados surgirá uma janela com opções.3. O ator seleciona a opção para agendar reparo e informa a data do serviço.4. Uma janela aparece solicitando que o usuário confirme a operação.5. O agendamento do reparo é salvo no banco de dados pelo sistema.

Fluxo Secundário 1

1. O ator pode informar uma data inválida/ impossível para o agendamento;2. A mensagem “Data incorreta” é exibida.


[UC09] Remover Buraco

Identificador: [UC 09]Descrição: Remove um buraco selecionado que esteja cadastrado previamente

no sistema.Atores: OperadorPrioridade: EssencialPré-condições: O usuário deve estar previamente cadastrado no sistema.Pós-condições: O buraco deve ser removido do banco de dados.


1. Estando na tela de exibição do mapa o ator pode clicar em um dos buracos demarcados;

2. Quando clicar em um dos buracos demarcados surgirá uma janela com opções.3. O ator seleciona a opção remover o buraco.4. Uma janela aparece solicitando que o usuário confirme a operação.5. O buraco é removido do banco de dados pelo sistema e não é mais exibido no mapa.

Fluxo Secundário 1

1. No passo quatro, o ator aperta Cancelar.

A operação é cancelada e o usuário retoma à tela em que anterior.


[UC010] Cadastrar Usuário




Descrição: Cadastra um usuário (operador no sistema).Ator: Administrador do sistema.Prioridade: EssencialPré-condições: O ator deve estar logado no sistema. Não deve haver usuário com

mesmo login já cadastrado no sistema.Pós-condições: Haverá um novo usuário cadastrado no banco de dados do sistema.


1. O ator seleciona no menu principal a opção “Cadastrar Usuário”;

2. O sistema exibe o formulário de cadastro de umnovo usuário;

3. O ator informa os dados do usuário a ser cadastrado;

4. O ator clica no botão de Confirmação “OK”;

5. O sistema cadastra as informações na base de dados e retorna para o formulário de cadastro apresentando os campos limpos.

Fluxo Secundário 1

1. No passo três do fluxo principal, o ator informa uma login de usuário já cadastrado;

2. O sistema apresenta uma mensagem informando que já existe um usuário cadastrado com os dados fornecidos;

3. O sistema permanece na mesma tela com os campos preenchidos.

Requisitos Não Funcionais Específicos NFR05, NFR06, NFR07, NFR09, NFR10, NFR11, NFR12, NFR13

[UC11] Remover Usuário

Identificador: [UC 11]Descrição: Remove um usuário do sistema previamente cadastrado.



Ator: Administrador do sistema.Prioridade: EssencialPré-condições: O usuário que se deseja remover deve estar previamente cadastrado

no sistema.Pós-condições: O Usuário não terá acesso ao sistema com o login e senha da conta

removida.Fluxo de Eventos Principal

1. O ator seleciona no menu principal a opção “Remover Usuário”;

2. O sistema exibe uma lista de usuários cadastrados no banco de dados;

3. O ator seleciona o usuário que deseja remover;

4. O ator clica no botão “Excluir”;

5. O sistema exibe uma mensagem informando que o usuário será removido do sistema e pede a confirmação do ator e a colocação de sua senha;

6. O ator informa a senha e confirma a exclusão;

7. O sistema remove os registro daquele usuário no banco de dados

Fluxo Secundário 1

1. No passo cinco, o ator aperta Cancelar.

2. A operação é cancelada e o usuário retoma à tela em que estava anteriormente.


[UC12] Alterar Usuário

Identificador: [UC 12]Descrição: Atualiza as informações de usuário cadastrado no sistema.



Ator: Administrador do sistema.Prioridade: ImportantePré-condições: O usuário a ser alterado deve estar previamente cadastrado no

sistema.Pós-condições: Os dados do usuário informados na alteração serão gravados por

cima dos dados salvos anteriormenteFluxo de Eventos Principal

1. O ator seleciona no menu principal a opção “Atualiza Usuário”;

2. O sistema exibe uma lista de usuários cadastrados no banco de dados;

3. O ator seleciona o usuário que deseja Atualizar;

4. O ator clica no botão “Atualizar”;

5. O sistema exibe uma tela contendo um formulário com as informações do respectivo usuário que se deseja alterar e o botão “Alterar”;

6. O ator altera as informações desejadas;

7. O ator seleciona o botão “Alterar”;

8. O sistema persiste os novos dados do usuário e volta para a tela de listar turmas de formandos.

Fluxo Secundário 1

1. No passo seis do fluxo principal, o ator seleciona o botão “Cancelar”;

2. O sistema retorna para a tela de listar os usuários cadastrados.

Fluxo Secundário 2

1. No passo seis do do fluxo principal, o ator altera os dados do usuário tornado-os de alguma forma inválidos

2. O sistema exibe uma mensagem avisando quais os campos que contem erros atualiza os campos com as informações do usuário cadastrado previamente no banco.




Anexo E – Glossário

• Banco de dados MySQL: O programa 'MySQL' é um sistema de gerenciamento de banco de dados relacionais baseado em comandos SQL (Structured Query Language - Linguagem Estruturada para Pesquisas) que vem ganhando grande popularidade, sendo atualmente um dos bancos de dados mais populares, com mais de 4 milhões de instalações.

• Login: Trata-se de uma seqüência de caracteres utilizada para identificar um usuário de forma única.

• Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no sistema dom login e senha.

• Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do sistema.

• Notação i*: Abordagem criada por John Mylopoulos e EricYu, na Universidade de Toronto para descrição de requisitos organizacionais

SCRUM: Metodologia ágil de desenvolvimento

GPS: Tecnologia de geoposicionamento

GPRS: Tecnologia de comunicação via rede celular

EMLURB: Empresa Metropolitana de Limpeza Urbana

PostgreSQL: Banco de dados

Postgis: Ferramenta geoposicionamento do PostegreSQL

Python: linguagem de programação

JAVA J2ME: linguagem de programação para mobile


Documents

UFPEif716/projetos/projetos20102/Projeto… · Web viewUniversidade Federal de Pernambuco – UFPECentro de Informática – CIn. Graduação em Ciência e Engenharia da Computação