Trabalho de Conclusão de Curso

Prévia do material em texto

CENTRO TECNOLÓGICO POSITIVO
DIEGO RAMOS DE PAULA
JAQUELINE SILVA DE OLIVEIRA
WILLIAN DOUGLAS GOBBI
CALLWORK - SISTEMA DE CONTROLE DE CHAMADOS
CURITIBA
2017
DIEGO RAMOS DE PAULA
JAQUELINE SILVA DE OLIVEIRA
WILLIAN DOUGLAS GOBBI
CALLWORK - SISTEMA DE CONTROLE DE CHAMADOS
Trabalho apresentado ao Programa de
Aplicação Profissional do Curso Superior de
Tecnologia em Analise e Desenvolvimento
de Sistemas do Centro Tecnológico da
Universidade Positivo.
Orientador: Prof. Evandro Zatti
CURITIBA
2017
TERMO DE ANUÊNCIA
Pelo presente Termo de Anuência, declaro estar de pleno acordo com as informações contidas neste projeto, o qual se apresenta apto a ser entregue à banca examinadora.
Orientador: Prof.° Evandro Zatti
Centro Tecnológico Positivo
_______________________________________
Assinatura do Professor Orientador
Curitiba, 01 de julho de 2017.
TERMO DE APROVAÇÃO
DIEGO RAMOS DE PAULA
JAQUELINE SILVA DE OLIVEIRA
WILLIAN DOUGLAS GOBBI
CALLWORK
Projeto de Intervenção Profissional apresentado ao Programa de Aplicação Profissional, do Curso de Tecnologia em Análise e Desenvolvimento de Sistemas, do Centro Tecnológico Positivo, pela seguinte banca examinadora:
Orientador:						__________________________
Prof.° Evandro Zatti
 Centro Tecnológico Positivo
__________________________
 Prof.ª Rafaela Otemaier
 Centro Tecnológico Positivo
Curitiba, 01 de julho de 2017.
AGRADECIMENTOS
	Gostaríamos de agradecer todos os nossos familiares que nos apoiaram e entenderam a importância que esse projeto terá em nossas vidas. Agradecemos também ao Jaime Markovicz, pela grande colaboração para este projeto, no qual acreditamos que não teria a sua realização sem a sua paciência e determinação em nós ajudar. Também devemos agradecer todos os professores que passaram nessa nossa jornada e que contribuíram para nossos conhecimentos e experiencias, em especial os professores Douglas Barcelos e Emmanuel Alencar, que nos forneceram informações de grande valor para toda a equipe, através de conversas construtivas. Não devemos esquecer do nosso orientador, o Evandro Zatti, que nos apoiou e colaborou em nossas necessidades.
RESUMO
Este documento visa apresentar o projeto de intervenção tecnológica, pertencente ao Programa de Aplicação Profissional do Centro Tecnológico Positivo, aonde a análise e o desenvolvimento de um sistema é demonstrado. O sistema deve atender a um órgão público, que precisa controlar os problemas ocorridos na organização, para que se possa tomar medidas de decisões. O órgão não possui qualquer sistema para esse fim e realizando a analise, a solução encontrada foi de um sistema web que gerencie e demonstre cada problema que ocorra, sendo assim organizando-os e apresentando aos usuários adequados para a resolução do mesmo. Com a análise e os requisitos do cliente, esse sistema foi modelado em diagramas e traduzido para uma linguagem que pudesse atender as necessidades da organização. Então desenvolveu-se um sistema simples e usual para sistematizar as ocorrências que aparecem diariamente, buscando atender com maestria uma situação antes precária.
Palavras-chave: Ocorrências; Órgão público; Analise; Sistematizar; Problemas; Gestão;
ABSTRACT
This document aims to present the project of technological intervention, belonging to the Professional Application Program of the Positivo Technological Center, where the analysis and development of a system is demonstrated. The system must attend to a public agency, which must control the problems that have occurred in the organization so that it can take decision measures. The organization does not have any system for this purpose and the analysis, the solution found was a web system that manages and demonstrates every problem that occurs, thus organizing and presenting to the appropriate users for the resolution of the same. With customer analysis and requirements, this system was modeled on diagrams and translated into a language that could meet the needs of the organization. Then a simple and usual system was developed to systematize the occurrences that appear daily, seeking to master in a precarious situation.
Keywords: Occurrences; Public Agency; Analysis; Systematize; Issues; Management
LISTA DE ILUSTRAÇÕES
FIGURA 1 – ETAPAS DO MODELO CASCATA.	15
FIGURA 2 – PROCESSO ATUAL DE CHAMADO	28
FIGURA 3 - DIAGRAMA DE CASOS DE USO	34
FIGURA 4 - CASO DE USO UC01	35
FIGURA 5 - PROTÓTIPO DE TELA DE NOVO CHAMADO	37
FIGURA 6 - CASO DE USO UC02	37
FIGURA 7 - PROTÓTIPO DE TELA DE CHAMADOS EM ABERTO	40
FIGURA 8 - PROTÓTIPO DE TELA DE CHAMADO EM ATENDIMENTO	41
FIGURA 9 - CASO DE USO UC04	41
FIGURA 10 - PROTÓTIPO DE TELA DE NOVO USÚARIO	43
FIGURA 11 - DIAGRAMA DE FLUXO DE DADOS - NIVEL 0	44
FIGURA 12 - DIAGRAMA DE FLUXO DE DADOS - NIVEIS 1 E 2	45
FIGURA 13 - DIAGRAMA DE ENTIDADE-RELACIONAMENTO	46
FIGURA 14 - DIAGRAMA DE IMPLANTAÇÂO	47
LISTA DE TABELAS
TABELA 1 - PAPÉIS DE CADA INTEGRANTE DA EQUIPE	30
TABELA 2 - FUNCIONALIDADE	32
TABELA 3 - USUALIDADE	32
TABELA 4 – CONFIABILIDADE	33
TABELA 5 - EFICIÊNCIA	33
TABELA 6 - PORTABILIDADE	33
TABELA 7 - MANUTENIBILIDADE	34
LISTA DE SIGLAS
ABPMP 	Associação de Profissionais de BPM
BPM 		Business Process Management
BPMN		Business Process Model and Notation
DFD		Diagrama de Fluxo de Dados
HTML		Hypertext Markup Language
IDE		Integrated Development Environment
SGDB 	Sistema Gerenciador de Banco de Dados
PHP		Hypertext Preprocessor
UML		Unified Modeling Language
INTRODUÇÃO
	Este trabalho visa apresentar o desenvolvimento e possível implantação de um sistema que contribua no controle de cada possível problema que possa ocorrer, de um determinado órgão público situada em Araucária, Paraná.
	O órgão público consiste em 11 vereadores com seus gabinetes contendo 4 assessores e 3 estagiários, além disso ainda possui concursados em diversas áreas e os vigilantes. A parte técnica fica responsável por manter os problemas, que aparecem no decorrer do expediente, solucionados para todas as pessoas e áreas envolvidas.
	Atualmente a organização não possui qualquer sistema ou controle em suas resoluções dos problemas ocorridos.
	A carência de um sistema de controle dos problemas acaba deixando sem saber quando que cada ação é tomada para a solução da ocorrência. Não se sabe o técnico que a realizou tão bem quem a solicitou. Um dos problemas ocorridos é de sobrecarga ao técnico, que as vezes recebe inúmeras requisições, e por ventura acaba que se esquecendo de algumas. E isso acaba gerando atrito entre solicitante e solucionador. Sem contar a questão de que pode haver casos de que uma determinada situação é mais prioritária que a outra.
As organizações precisam ter estratégias que facilitem o controle e gerenciamento de tudo que ocorrem. Com a necessidade da organização, foram realizada análise e proposto um sistema que permita gerenciar e monitorar cada situação problemática. O sistema busca permitir a inserção do problema de forma clara e concisa pelo solicitante, para que o solucionador saiba como ir até a causa raiz e soluciona-la. 
A implantação do sistema visa reduzir o tempo de espera e desentendimentos das situações corriqueiras. Também propõem designar os técnicos certo para o caso. 
FUNDAMENTAÇÃO TEÓRICA
Os benefícios das tecnologias da informação estão cada dia mais indispensáveis tanto para as empresas quanto para pessoas. E para desenvolver um sistema é preciso muito mais do que o conhecimento sobre a linguagem a ser utilizada, é preciso conhecer técnicas que lhe auxiliarão em sua elaboração. Pois para construir um sistema quese molde nas necessidades da empresa deve-se levar em conta todos os detalhes aonde o sistema irá ser implantado.
 CICLO DE VIDA
Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas em cada etapa. A definição dessas etapas e atividades possibilitam controle para avaliação da qualidade e gerência do projeto. Estes “modelos de ciclo de vida” ou “modelos de processos” são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um determinado processo.
Um dos modelos existente é o modelo em cascata, que foi escolhido para este projeto. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado, foi o primeiro modelo a ser conhecido em engenharia de software e está na base de muitos ciclos de vida utilizados nos dias de hoje. A adoção deste modelo requer os requisitos bem definidos, uma vez que o projeto segue pelas etapas e não pode haver retorno, sendo assim qualquer mudança pode ser prejudicial para o projeto. 
De acordo com Pressman (2011), o modelo em cascata pode ser dividido em 5 fases.
FIGURA 1 – ETAPAS DO MODELO CASCATA.
FONTE: ADAPTADO PRESSMAN(2011).
Essas fases que fazem parte do processo são:
Comunicação:
É a fase inicial do projeto, assim como o nome sugere, a comunicação com o cliente para levantar todos os requisitos possíveis.
Essa fase pode ser considerada a mais crucial de todas, aqui todos os requisitos devem ser detalhados e bem definidos, pois todas as etapas seguintes dependerão do que foi abordado aqui. Se assim não for, pode ocorrer sérios problemas na estrutura e conclusão do projeto.
Planejamento:
Após a etapa anterior com todos os requisitos prontos e definidos, é iniciado o planejamento. O planejamento consiste em abordar detalhes como o tempo de entrega final ao cliente e cronogramas de desenvolvimento. Aqui também podemos definir tecnologias utilizadas ao longo do projeto como a linguagem de programação e o ambiente de desenvolvimento. É abordado possíveis falhas que poderão ocorrer no processo do projeto.
Modelagem:
Nesta etapa é modela os requisitos levantados na primeira fase que ajudarão o cliente e o desenvolvedor a terem um melhor entendimento de como o sistema será em sua construção e conclusão.
Construção:
Esta etapa consiste na tradução de toda a modelagem criada na etapa anterior para uma linguagem. Também são feitos teste que revelam erros na codificação.
Implantação:
A última etapa é o funcionamento de todo o sistema planejado e já implantado para uso. Aqui é realizado o feedback do cliente quanto a sua satisfação do sistema que lhe foi entregue. Podemos também colocar ajustes a bugs e erros não detectados anteriormente.
 GESTÃO DE PROJETOS
Gestão de projetos, segundo o PMBOK (PMI, 2004), ”o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto afim de atender aos seus requisitos”.
Aplicando as técnicas de gestão, os riscos de fracasso que eventualmente ocorrem no processo de desenvolvimento do sistema acabam drasticamente diminuindo, quando se gerência todo o projeto, pois sem um planejamento adequado, o projeto tende a afundar em incerteza de como deve se seguir. Gerenciando o projeto ganha-se tempo, qualidade, redução de custos, uma vez que definido os processos, obtém-se a chance de sua conclusão.
De acordo com PMBOK (PMI, 2004, p.9), é citado nove áreas que podem ser gerenciados. Uma delas é gerência de requisitos, que define as necessidades que o sistema deve atender, e é de extrema importância, uma vez que um mal compreendimento das especificações transmitida pelo cliente pode acabar em um sistema sem o proposito que lhe foi concebido. Cada detalhe é minuciosamente, a modelagem de como o sistema se tornará em sua implantação. A gerência de requisitos pode ser incluída dentro do gerenciamento de escopo, que anseia determinar somente aquilo que se julga necessário para a conclusão do projeto, eliminando trabalhos que são desnecessários. Ainda há o gerenciamento do tempo levado para o desenvolvimento, assim como os custos que o cliente deverá arcar. Podemos também gerenciar a qualidade, especificando a performance e realização das necessidades do cliente. Aqui pode ser incluído a questão de cumprimentos de prazos e satisfação final do sistema. Entre as gerências, está também o de recursos humanos, que faz a gestão da equipe envolvida no projeto, delegando a produtividade para cada um. A gerência de comunicações descreve o objetivo em plantar todas as informações que ocorrem no projeto sendo por parte da equipe quanto a parte do cliente, havendo clareza e transparência. Como todo projeto tem riscos, é necessário gerencia-los, para se assegurar que possam ser tomadas decisões para evita-los. Com uma visão ampla para o desenvolvimento, o gerenciamento da integração foca no processo de identificação da estrutura do projeto como um todo. E por fim, tem a gestão de aquisições, que abrange as necessidades de aquisições de produtos que serão necessários para o andamento do projeto.
E com relação aos estudos das gerencias de projeto, optamos por adotar o uso das gerências descritas para que o projeto flua de forma que satisfaça o cliente e a equipe no final do mesmo.
 GERENCIAMENTO DE PROCESSOS
Para este projeto, aderimos o uso do Business Process Management (BPM) que segundo a Associação de Profissionais de BPM (ABPMP), a definição pode ser: 
BPM é uma abordagem metodológica para identificar, desenhar, executar, documentar, medir, monitorar e controlar processos, automatizados ou não, para alcançar resultados consistentes e alinhados com os objetivos estratégicos. Permite a melhoria tanto das atividades de uma determinada área, entre áreas ou entre organizações.
	O objetivo dessa modelagem, é tornar o processo mais eficiente, focando em melhorarias do negócio. Ou seja, analisando o processo atual como ele é (As Is), e como ele vai ser após a sua implantação (To Be). Sabendo como é agora, obtém-se a clareza para gerar um planejamento mais robusto para como será.
	O uso dessa modelagem irá beneficiar nas transparências em todas as etapas do processo, assim como um maior controle do que está sendo realizado, aumentando a produtividade e reduzindo os custos finais.
	Toda a modelagem do processo é feita por notações, o Business Process Modeling Notation (BPMN) ou Notação de Modelagem de Processo de Négocio.
 MODELAGEM UML
A UML (Unified Modeling Language) é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). Esta linguagem não é um método de desenvolvimento, ela apenas tem como papel auxiliar a visualizar o desenho e a comunicação entre objetos. Ela permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados, e é muito usada para criar modelos de sistemas de software.
A UML utiliza-se de um conjunto de técnicas de notação gráfica para criar modelos visuais de software de sistemas intensivos, combinando técnicas de modelagem de dados, negócios, objetos e componentes. É uma linguagem de modelagem única, comum e amplamente utilizável.
Embora com a UML seja possível representar o software através de modelos orientados a objetos, ela não demonstra que tipo de trabalho deve ser feito, ou seja, não possui um processo que define como o trabalho tem que ser desenvolvido. O objetivo então é descrever "o que fazer", "como fazer", "quando fazer" e "porque deve ser feito". É necessária a elaboração completa de um dicionário de dados, para descrever todas as entidades envolvidas, refinando, com isso, os requisitos funcionais do software.
A Linguagem Unificada de Modelagem possui diagramas que são usados em combinação, com a finalidade de obter todas as visões e aspectosdo sistema.
Os Diagramas da UML estão divididos em: 
Estruturais: Classe, Objeto, Componentes, implantação, Pacotes e Estrutura;
Comportamentais: Caso de Uso (Use Case), Máquina de Estados, Atividades e Interação.
 CASOS DE USOS
Tem como objetivo auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
O diagrama de Caso de Uso é representado por:
Atores:  é representado por um boneco e um rótulo com o nome do ator. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional.
Casos de uso: Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.
 DIAGRAMA DE FLUXO DE DADOS
O diagrama de fluxo de dados (DFD) tem o objetivo de apresentar o fluxo que os dados percorrem pela visão do sistema. Esses dados são demonstrados em entradas e saídas por seus caminhos que percorrem dentro da aplicação.
O DFD pode ter vários níveis de detalhamento conforme a complexidade do sistema e o nível mais alto é o nível 0, que apresenta as principais funções do sistema. Mas caso não fique claro a intenção de cada funcionalidade, níveis são criados para aperfeiçoar a função.
 LEVANTAMENTO DE REQUISITOS
O levantamento de requisitos é o início e uma das partes mais cruciais em um projeto que levará no desenvolvimento de um sistema. Cada detalhe extraído, seja por pesquisas, entrevistas ou brainstorms é de vital importância e esses requisitos obtidos são uma leve descrição de como o sistema se moldará em seu desenvolvimento. Os requisitos devem ser detalhados e não se contradizer com outro.
Mas saber extrair os detalhes é fundamental para abranger com excelência as necessidades do cliente. Muitas vezes ele até sabe o que deseja, mas não sabe como transmitir com clareza para o analista. Que deve saber compreender e dominar o problema para que o projeto obtenha sucesso. Por isso o analista deve se submeter ao problema e aplicar uma solução viável para o mesmo.
Os requisitos são divididos em funcionais e não funcionais. Sendo funcionais aquelas que devem o sistema realizar competentemente, e os não funcionais aqueles que se referem a recursos como tempo de espera, espaço de armazenamento e afins. Ainda também existem os requisitos de produto, que apresentam estruturas técnicas como segurança e desempenho e os requisitos de negócio que definem os termos de negócio, tempo de entrega e outros.
	Como adotamos o modelo em cascata para o desenvolvimento do sistema, todos os requisitos foram levantados no início do projeto e detalhados de acordo com as necessidades do cliente.
 TECNOLOGIAS UTILIZADAS
Para o desenvolvimento deste projeto são necessárias algumas tecnologias, segue abaixo:
PHP 7
	As linguagens de programação são o meio de transmitir para computadores regras que eles devem executar. Cada linguagem tem suas características e diferenças em relação a outra, tornando-as ideias para cada situação. A linguagem adotada nesse projeto foi o PHP (Hypertext Preprocessor), uma das linguagens mais importante para desenvolvimento de sistema para internet, pois sua estrutura é bem simples para o desenvolvedor e possui recursos avançados. Os scripts em PHP são processados no servidor e enviados para o navegador através de arquivos HTML (HyperText Markup Language).
	Originalmente o PHP é uma linguagem procedural, mas com a sua evolução ela passou a suportar também a orientação a objetos. Mesmo com todos os benefícios de se utilizar uma linguagem orientada a objetos, foi optado usar o PHP na forma estruturada.
Netbeans IDE
Desenvolvido pela Oracle, é um ambiente de desenvolvimento open source para diversas linguagens (Java, C, C++, Ruby, PHP e outras). Sua interface é intuitiva e simples, mas com funções uteis e necessárias.
Foi adotada essa IDE pela familiaridade e sua facilidade na criação de projetos, além disso também por sua integração com a tecnologia GIT.
Bootstrap
Framework front-end desenvolvido pela equipe do Twitter que auxilia os desenvolvedores a criarem páginas web responsivo para todos os tipos de telas.
Github
GIT é uma ferramenta de controle de versão e gerenciamento de códigos fontes que pode ser compartilhado para que outros desenvolvedores contribuem com o projeto. Um desses sistema, é o GitHub, sua interface apesar de ser em inglês, é bem simples de usar. Os desenvolvedores vão atualizando cada arquivo que está no repositório e automaticamente todos são informados, assim todos trabalham sabendo o que cada um está realizando.
Astah Community
O Astah é um software para modelagem de diagramas UML. Foi desenvolvido no Japão e é utilizado por grandes empresas como Amazon, Oracle e Google.
Bizagi Modeler
É uma ferramenta de Business Process Model and Notation (BPMN) de criação de diagramas e fluxogramas. A ferramenta também permite trabalhar em colaboração nos projetos criados, ajudando ou recebendo conselhos de outros usuários.
Sistema gerenciador de banco de dados
Possuir uma base de dados atualmente se tornou indispensável, por mais indiferente que o tamanho da empresa seja, cada uma delas precisa armazenar informações e dados. E para que isso aconteça foi criado o sistema gerenciador de banco de dados, que segundo Date (2003, p.15), é “uma coleção de programas que permitem aos usuários criarem e manipularem uma base de dados. Um SGBD é, assim, um sistema de software de propósito geral que facilita o processo de definir, construir e manipular bases de dados de diversas aplicações. ”
E como neste projeto também possui a necessidade de persistir os dados, foi optado por usar um SGDB open source, o MySql que é altamente compatível com a linguagem PHP que é usada nesse projeto.
KanbanFlow
Ferramenta de gerenciamento de atividades, aonde pode-se definir tarefas para outros usuários usando o método Kanban, que consiste no conceito japonês de colocar cartões colado em um mural indicando seu status atual. E essa ferramenta aplica de modo online eficientemente esse conceito. Sua utilização é gratuita (Possui versão paga também) e corresponde com a necessidade de cada atividade para o modelo em cascata definido para o projeto.
ORGANIZAÇÃO CLIENTE
A organização cliente do projeto, é um órgão público com o nome fantasia de CMA, e está situada na cidade de Araucária, na Rua Irmã Elizabeth Werka, 55. Para contato pode usar o e-mail: cma@camaraaraucaria.pr.gov.br e o telefone: (41) 3641-5200.
O órgão público é responsável pela competência legislativa, onde estão os vereadores, que participam no processo de formação das leis do município. Ainda possui a parte fiscalizadora da administração municipal, a parte julgadora, que julgam as ações do prefeito e pôr fim a parte administrativa que garantem o funcionamento de todas os setores da organização. 
A CMA congrega 11 vereadores em seus gabinetes, aonde cada gabinete é de responsabilidade de 4 assessores, que por sua vez possuem 3 estagiários. Ainda compõem também a parte administrativa com concursados em diversas áreas. Podemos incluir a parte da diretoria e os parlamentares. 
Na estrutura da organização, possui a parte técnica que é responsável por solucionar os problemas técnicos que ocorrem. Os problemas são repassados aos técnicos, que buscam soluciona-los o mais rápido possível.
DIAGNÓSTICO DO AMBIENTE
Como especificado anteriormente, os problemas que eventualmente ocorrem na organização, não possuem qualquer controle, cada ação tomada pelo solucionador, não é de sabedoria das partes interessadas. Somente quem solicitou o técnico para o problema, saberá se foi sanado ou não.
A equipe de técnicos tem de solucionar todos osproblemas referentes aos componentes eletrônicos como computadores, audiovisual e telefonias, assim como os cabeamentos. Esses componentes estão distribuídos em todos os setores.
Todos os problemas que ocorrem, são descritos na forma de telefonemas ou diálogos pessoalmente. Somente quem solicitou e o técnicos ficam ciente do processo. Salvo exceções aonde um problema de larga escala é de sabedoria de todos os afetados. Com o problema descrito para o técnico, o mesmo tenta soluciona-lo o mais rápido possível.
Como informado, atualmente não possui nenhum meio de controle dos problemas, as informações ficam na mente do técnico podendo lembra-las ou não se foram solucionados. Nem é possível saber se o técnico é o mais indicado para a devida situação, pois o solicitante pode chamar quem lhe convém, sabendo por experiencia previa que o mesmo é capaz de solucionar.
Um dos problemas que pode ser identificado é da sobrecarga que um técnico pode ter, pois múltiplas requisições são feitas, além do tempo de espera por parte do solicitante. Outra importância notável, é por parte do chefe não saber quais os problemas que estão em ocorrência, tão pouco em quais cada técnico esta focado. Também não é possível saber por meios legais se o técnico está produtivo ou não, ficando difícil manter o controle para tomada de decisões. Outro problema comum é uma ocorrência não poder ser solucionado dentro do prazo do expediente, sendo passível de esquecimento no outro dia trabalhado e mais uma vez o solicitante tendo de repetir todo o processo de novo.
Levando em conta todos os problemas identificas, foi utilizado o gerenciamento de processos de negócios, o BPM, com analise e mapeamento no modelo 5W + 1H. Essa analise pode ser vista abaixo:
What? (O que?) – Sistema de controle de chamados; 
Who? (Quem?) – Administradores, Diretores, Coordenadores, Chefes de setores e seus funcionários pelo auxilio técnico, e os técnicos pela solução do problema;
Where? (Onde?) – Na CMA;
Why? (Por que?) – Para melhorar o processo de comunicação e agilidade dos problemas ocorridos, além do monitoramento e organização;
When? (Quando?) – Dependendo de cada situação problematica;
How? (Como?) – Os diretores, coordenadores, chefes de setores e os funcionários entram com um pedido de auxilio técnico, descrevendo com clareza o problema, para assim o técnico receber a solicitação e poder ir a raiz do problema e soluciona-lo.
Com base nesse levantamento, houve a elaboração dos seguinte fluxo de atividade:
FIGURA 2 – PROCESSO ATUAL DE CHAMADO
FONTE: Os autores (2017)
Na figura 2, foi apresentado o processo que atualmente é realizado, aonde podemos notar que o problema fica em espera até que o algum técnico atenda a ligação. Esse processo é bem simples e somente nos mostra o quanto é necessário ter um controle maior para a situação, para que o solicitante não fique preso na chamada do técnico.
OBJETIVOS
Com base em todo o levantamento junto ao cliente, o objetivo que deve ser alcançado com este projeto, é melhorar o processo de chamados aos problemas que eventualmente ocorrem.
Por meio do ciclo de vida em cascata, junto as técnicas de gestão de projeto e gerenciamento dos processos, será entregue um sistema que facilite a comunicação entre os solicitantes e os técnicos, bem como registrar cada ação do processo de atendimento.
Com o sistema implantado, busca-se diminuir o tempo de espera pelo atendimento, assim como detalhar o problema de forma clara para que o técnico especializado para aquela situação possa agir de forma correta. Também é notável dizer que os problemas terão um nível de prioridade, sendo resolvidos em primeira ordem.
Busca-se também o monitoramento por parte dos chefes responsáveis pelos técnicos, sabendo qual problema está sendo resolvido no momento e qual técnico está envolvido.
Mostrar rendimentos dos processos de atendimento em formas de gráficos e estáticas ajudará todos a terem uma noção de progresso por parte dos atendimentos.
Além de detalhes de funcionalidades, é desejável entregar um sistema que atenda os limites de hardware da organização. Além de que seu principal objetivo seja rodar em browsers de computadores, que rode de maneira fluida e visualmente agradável em navegadores de smartphones.
E por fim, o objetivo maior, é de que todos sintam-se confortáveis em usar o sistema e que satisfaça o cliente e todos os usuários que irão utiliza-lo.
DESENVOLVIMENTO
O planejamento deste projeto primeiramente iniciou em uma conversa por meio de brainstorm, abordando ideias e soluções para controlar o processo de chamado de eventuais problemas que ocorram. A equipe já possuía a ideia de desenvolver e implementar esse sistema em alguma corporação que necessitasse. No início de 2017, teve a optação por uma organização governamental que justamente tinha essa necessidade. Em uma reunião com o cliente, foi exposto a ideia do projeto, aonde o mesmo destacou a real necessidade que esse sistema e a sua importância teria para a organização. Com a reunião em andamento houve a coleta e granularidade de pontos para o levantamento de requisitos. Cada detalhe observado foi útil para entender e mapear o processo na sua atualidade.
Para o desenvolvimento do sistema, foi discutido e definido papeis para cada integrante da equipe, para que houvesse uma melhor organização e rendimento. Apesar da divisão, cada integrante auxiliou o outro em casos de necessidades. Essa divisão pode ser vista na tabela abaixo:
	NOME:
	PAPEL ATRIBUIDO
	Diego Ramos
	Gerente de projeto, Programador
	Jaqueline Silva 
	Analista de sistemas, Documentação
	Willian Douglas
	Analista de sistemas, Programador
TABELA 1 - PAPÉIS DE CADA INTEGRANTE DA EQUIPE
FONTE: Os autores (2017).
As atribuições dos papeis, foi distribuída levando em conta as qualidades de cada integrante da equipe. Como observado na tabela os papeis, ficou a cargo do gerente de projeto (Diego) definir o escopo do projeto para que os analistas (Jaqueline e Willian) fizessem a análise e modelagem através de documentos que seriam indispensáveis para o desenvolvimento.
Como o projeto na sua essência é relativamente pequeno, foi definido a melhor solução para seu desenvolvimento e implementação, adotando o ciclo de vida em cascata. Como esse modelo é restrito em suas fases, reuniões constantes internas ou com o cliente, foram realizadas na medida que foram sendo necessárias, passando assim para a próxima fase quando a atual esteja de acordo com todos os envolvidos.
Para um aprofundamento melhor do projeto, veja o apêndice C.
ESPECIFICAÇÃO DOS REQUISITOS DO PROJETO
Os requisitos do sistema foram classificados como:
Funcionalidade – a finalidade do produto;
Usabilidade – facilidade de aprendizado por parte do usuário;
Confiabilidade – frequência de falhas e erros;
Eficiência – desempenho favorável em seu uso;
Portabilidade – facilidade de modificação;
Manutenibilidade – capacidade de migração para outros ambientes.
Com base nesses requisitos, a descrição é apresentada em cada tabela, a seguinte legenda:
Prioridade
ME 	– Média para baixa importância
MU 	– Muita importância
E 		– Essencial importância
Fonte de identificação de Requisitos
C 		– Cliente
A 		– Analista
Os requisitos do projeto podem ser vistos nas tabelas abaixo:
Características de qualidade – Funcionalidade
	#
	Descrição do requisito
	Prioridade
	Fonte
	F – 1
	Autenticar usuário
	E
	C
	F – 2 
	Cadastrar usuário
	E
	C
	F – 3
	Inserir chamado
	E
	C
	F – 4
	Listar chamados
	MU
	C
	F – 5
	Atender chamado
	E
	C
	F – 6 
	Gerar relatórios
	ME
	A
	F – 7
	Alterar senha
	ME
	A
	F – 8 
	Cadastrar setor
	E
	C
	F – 9
	Cadastrar especialidades
	E
	C
	F – 10
	Listar chamados atendidos
	MU
	C
	F – 11
	Atribuir chamado ao técnico
	ME
	C
	F – 12 
	Excluir usuários inativos
	MU
	A
TABELA 2 - FUNCIONALIDADE
FONTE: Os autores (2017)
Características dequalidade – Usualidade
	#
	Descrição do requisito
	Prioridade
	Fonte
	U – 1
	Facilidade de uso
	ME
	C
	U – 2
	Segurança
	E
	C
	U – 3
	Interface responsiva
	ME
	A
TABELA 3 - USUALIDADE
	FONTE: Os autores (2017)
Características de qualidade – Confiabilidade
	#
	Descrição do requisito
	Prioridade
	Fonte
	C – 1
	Permissão de acesso
	E
	C
	C – 2
	Redundância de dados
	MU
	A
	C – 3
	Disponibilidade
	E
	C
	
TABELA 4 – CONFIABILIDADE
FONTE: Os autores (2017)
Características de qualidade – Eficiência
	#
	Descrição do requisito
	Prioridade
	Fonte
	E – 1
	Manipulação de dados
	E
	C
	E – 2
	Tempo de resposta
	E
	C
	E – 3
	Múltiplos usuários
	E
	C
TABELA 5 - EFICIÊNCIA
FONTE: Os autores
Características de qualidade – Portabilidade
	#
	Descrição do requisito
	Prioridade
	Fonte
	P – 1 
	Adaptabilidade
	ME
	A
 	
TABELA 6 - PORTABILIDADE
	FONTE: Os autores (2017)
Características de qualidade – Manutenibilidade
	#
	Descrição do requisito
	Prioridade
	Fonte
	M – 2 
	Documentação detalhada
	E
	A
TABELA 7 - MANUTENIBILIDADE
	FONTE: Os autores (2017)
MODELAGEM E ARQUITETURA
A utilização dessa modelagem foi usada para demonstrar decisões do projeto e como as suas funcionalidades seriam implementadas.
Diagrama de Casos de Uso
O diagrama abaixo representa todas as funcionalidades do sistema:
FIGURA 3 - DIAGRAMA DE CASOS DE USO
FONTE: Os autores (2017)
 Documentação dos casos de uso
Aqui será abordado os casos de uso mais significativos. Pode-se observar mais casos de uso no apêndice E.
UC01 – Abrir chamado
FIGURA 4 - CASO DE USO UC01
FONTE: Os autores (2017)
	UC01 – Abrir chamado
	Atores: Solicitante
	Descrição: Inserção de descrição do problema
	Informações adicionais:
Pré-condições:
Solicitante necessita estar logado
Solicitante necessita estar na tela “Solicitar chamado”
Pós-condições de sucesso:
Solicitação gravado no banco de dados
	Requisitos atendidos:
RF3 – Inserir chamado
FLUXO PRINCIPAL
O ator decide abrir um chamado.
O sistema solicita as informações obrigatórias para abrir o chamado conforme a regra 2.1 RN – Chamado
O ator informa os dados do chamado.
O ator clica no botão para enviar
O sistema valida os dados do chamado.
O sistema salva o chamado no banco de dados (MSG4).
O caso de uso se encerra.
FLUXO ALTERNATIVO
Este caso de uso não possui fluxo alternativo.
FLUXO EXCEÇÃO 
O usuário não informa todas as informações necessárias ao sistema.
O sistema informa o erro ao ator (MSG2).
O fluxo retorna ao passo 2 do fluxo principal.
CRITÉRIOS DE ACEITE
O sistema deve receber todas as informações necessárias do usuário.
PROTÓTIPO DE TELA
FIGURA 5 - PROTÓTIPO DE TELA DE NOVO CHAMADO
		FONTE: Os autores (2017)
UC02 – Atender chamado
FIGURA 6 - CASO DE USO UC02
FONTE: Os autores (2017)
	UC02 – Atender chamado
	Atores: Técnico
	Descrição: Atendimento ao chamado solicitado
	Informações adicionais:
Pré-condições:
Técnico necessita estar logado
Técnico necessita estar na tela “Atender chamado”
Pós-condições de sucesso:
Alteração do status no banco de dados (2.1.9.	RN – Atendimento do chamado)
	Requisitos atendidos:
RF5 – Atender chamado
FLUXO PRINCIPAL
O técnico inicia um chamado.
O sistema altera o status do chamado conforme a regra 2.1.9 RN – Atendimento do chamado.
O técnico finaliza o chamado.
O sistema altera o status do chamado conforme a regra 2.1.10 RN – Finalização do chamado.
O caso de uso se encerra.
FLUXO ALTERNATIVO
Fluxo alternativo 1
O técnico coloca o chamado em espera.
O sistema solicita as informações necessárias.
O sistema altera o status do chamado conforme a regra 2.1.11 RN – Atendimento em espera.
O caso de uso se encerra;
Fluxo alternativo 2
O técnico transfere o chamado para outro técnico.
A mensagem 
O caso de uso se encerra.
FLUXO EXCEÇÃO
Fluxo de exceção 1
O técnico não informa os detalhes necessários ao colocar o chamado em espera.
O sistema retorna o erro MSG8.
O fluxo retorna ao passo 2 do fluxo alternativo 1.
Fluxo de exceção 2
O técnico não escolhe o técnico.
O sistema informa o erro (MSG19).
O fluxo retorna ao passo 2 do fluxo alternativo 2.
	
CRITÉRIOS DE ACEITE
O sistema deve receber todas as informações necessárias do técnico.
PROTÓTIPO DE TELA
FIGURA 7 - PROTÓTIPO DE TELA DE CHAMADOS EM ABERTO
		FONTE: Os autores (2017)
FIGURA 8 - PROTÓTIPO DE TELA DE CHAMADO EM ATENDIMENTO
FONTE: Os autores (2017)	
UC04 – Gerar acesso
FIGURA 9 - CASO DE USO UC04
FONTE: Os autores (2017)
	UC04 – Gerar acesso
	Atores: Administrador, Técnico
	Descrição: Gerar acesso para novos usuários
	Informações adicionais:
Pré-condições:
Administrador ou Técnico necessita estar logado
Administrador ou Técnico necessita estar na tela “Gerar acesso”
Pós-condições de sucesso:
Manter usuário no banco de dados
	Requisitos atendidos:
RF2 – Cadastrar usuário
FLUXO PRINCIPAL
O sistema solicita as informações obrigatórias para a criação de usuário conforme a regra 2.3.1 RN - Criação de acesso solicitantes.
O administrador informa os dados do usuário.
O sistema valida os dados.
O sistema retorna a mensagem MSG7.
O caso se encerra.
FLUXO ALTERNATIVO
	Não se aplica nesse caso de uso.
FLUXO EXCEÇÃO
Fluxo de exceção 1
O administrador ou técnico informa as credenciais erradas ao sistema.
O sistema informa o erro ao ator MSG2.
O fluxo retorna ao passo 1 do fluxo principal.
Fluxo de exceção 2
O usuário informado pelo administrador já existe na base de dados.
O sistema informa o erro ao ator MSG5.
O fluxo retorna ao passo 1 do fluxo principal.
	
CRITÉRIOS DE ACEITE
O sistema deve receber credenciais válidas do usuário.
PROTÓTIPO DE TELA
FIGURA 10 - PROTÓTIPO DE TELA DE NOVO USÚARIO 
FONTE: Os autores (2017)
MODELAGEM DE DIAGRAMAS DE FLUXO DE DADOS
A modelagem através dos diagramas de fluxo de dados, tem o objetivo de apresentar somente a parte indispensável do sistema, como o processo de abertura e atendimento do chamado.
Abaixo podemos ver a sua representação através do diagrama:
FIGURA 11 - DIAGRAMA DE FLUXO DE DADOS - NIVEL 0 
FONTE: Os autores (2017)
Este diagrama mostra de forma bem superficial, como as entidades (usuários) interagem com o sistema. 
Para um detalhamento mais aprofundado, é apresentado nos níveis 1 e 2 o seguinte diagrama:
	
FIGURA 12 - DIAGRAMA DE FLUXO DE DADOS - NIVEIS 1 E 2 
FONTE: Os autores (2017)
MODELO FÍSICO DE DADOS
O modelo físico de dados tem o objetivo de apresentar como será a implementação dos dados no banco.
Para observar 
 FIGURA 13 - DIAGRAMA DE ENTIDADE-RELACIONAMENTO 
 FONTE: Os autores (2017)
VISÂO DE IMPLANTAÇÂO
O diagrama de implantação demonstra o ambiente físico que o sistema será implantado. Esse diagrama pode visualizado abaixo:
FIGURA 14 - DIAGRAMA DE IMPLANTAÇÂO 
FONTE: Os autores (2017).
REFERÊNCIAS
BEDANI, Janaina. Engenharia de Software 2 - Técnicas para levantamento de Requisitos. Disponível em: <http://www.devmedia.com.br/engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151> Acesso em: 16/01/2017.
PEREZ, Bruno. Engenharia de Requisitos – Técnicas. Disponível em: <https://brunobrum.wordpress.com/2011/04/27/principais-tecnicas-de-levantamento-de-requisitos-de-sistemas/> Acesso em: 16/01/2017.
MEDEIROS, Higor. Introdução ao Modelo Cascata. Disponível em: <http://www.devmedia.com.br/introducao-ao-modelo-cascata/29843> Acesso em: 20/02/2017.
NEPOMUCENO, Dênis. Modelo Cascata, Linear ou Clássico. Disponível em: <http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/fffrrrrr.html>. Acesso em: 20/02/2017.
Uma comparação entre os modelos ágil e cascata de desenvolvimento de software. Disponível em: <https://brainstormdeti.wordpress.com/2010/05/25/uma-comparacao-entremodelo-agil-e-cascata/>.Acesso em: 21/02/2017.
QUITERIO, Ana Paula. Análise de Requisitos. Disponível em: <http://www.infoescola.com/engenharia-de-software/analise-de-requisitos/>. Acesso em: 18/01/2017.
Ciclos de Vida do Software - Artigo Revista Engenharia de Software Magazine 36. Disponível em: <http://www.devmedia.com.br/ciclos-de-vida-do-software-artigo-revista-engenharia-de-software-magazine-36/21099>. Acesso em: 18/01/2017.
Metodologias e Padrões de Desenvolvimento de Software. Disponível em: <http://www.devmedia.com.br/metodologias-e-padroes-de-desenvolvimento-de-software/5219>. Acesso em: 20/01/2017.
ABILIO, Igor. Programação Orientada a Objetos versus Programação Estruturada. Disponível em: <http://www.devmedia.com.br/programacao-orientada-a-objetos-versus-programacao-estruturada/32813>. Acesso em: 22/01/2017.
PACIEVITCH, Yuri. PHP. Disponível em: <http://www.infoescola.com/informatica/php/>. Acesso em: 12/04/2017.
PHP, Disponível em: <https://secure.php.net/>. Acesso em 15/04/2017.
O que o PHP pode fazer?. Disponível em: <https://secure.php.net/manual/pt_BR/intro-whatcando.php>. Acesso em: 18/03/2017.
OLIBOLI, Daniel. O que é um SGBD?. Disponível em: <https://www.oficinadanet.com.br/post/16631-o-que-e-um-sgbd>. Acesso em: 20/02/2017.
MONTELEONE, Mark. Structuring AS-IS and TO-BE Process Improvement Discussions using the Fishbone Diagram. Disponível em: <http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1562/Structuring-AS-IS-and-TO-BE-Process-Improvement-Discussions-using-the-Fishbone-Diagram.aspx>. Acesso em: 20/02/2017.
Bootstrap 3 Tutorial. Disponível em: <https://www.w3schools.com/bootstrap/>. Acesso em: 21/04/2017.
Gestão de Projeto - O que é e para que serve?. Disponível em: <http://www.projectbuilder.com.br/blog-home/entry/conhecimentos/o-que-e-gestao-de-projetos-e-para-que-serve>. Acesso em: 08/03/2017.
UML - Unified Modeling Language e Visual Modeler (Visual Basic 6). Disponível em: <http://www.macoratti.net/uml_vb.htm>. Acesso em 08/03/2017.
CLAIR, Thânia. A história de UML e seus diagramas. Disponível em: <https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf>. Acesso em 08/03/2017.
Casos de Uso - Diagrama de Casos de Uso. Disponível em: <http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI-II/Uml/diagramas/usecases/usecases.htm>. Acesso em: 08/03/2017.
APÊNDICE A – REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS
REQUISITOS FUNCIONAIS
	Autenticar usuário
	Cadastrar usuário
	Inserir chamado
	Listar chamados
	Atender chamado
	Gerar relatórios
	Alterar senha
	Cadastrar setor
	Cadastrar especialidades
	Listar chamados atendidos
	Atribuir chamado ao técnico
	Excluir usuários inativos
REQUISITOS NÃO FUNCIONAIS
	O sistema deve rodar em ambiente Web de preferência o Firefox em sua versão 45.0.2
	O gerenciamento de banco de dados deve ser o MySql 5.6.7.
	O sistema deve operar em servidor Xampp 5.6.30.
	O sistema deve ser desenvolvido em PHP 7.1.0.
	O tempo limite para a adição do usuário ao banco de dados é de 30 segundos.
	O tempo para consultas de todos os chamados é de no máximo 30 segundos 
	O sistema deve possuir fácil migração para possíveis servidores futuros.
	A tela de chamado será composta de visual simples contendo a parte de adição de chamado e chamados adicionados.
	O status para cada chamado deve estar informado com uma cor única. 
	O tempo para desenvolvimento é de 6 meses.
	Cada fase do projeto no modelo cascata deve ser apresentado ao cliente.
	O sistema deve estar com as funcionalidades com prioridades críticas entregues no máximo em 5 meses.
	Cada funcionalidade do sistema deve estar documentada.
	O padrão adotado é estruturado, usando os padrões de desenvolvimento da linguagem PHP.
	Cada usuário deverá possuir seu acesso de modo único e intransferível.
	Após a criação do usuário, a senha provisória deve ser alterada. 
	As senhas devem ser criptografadas.
	Se o login ficar sem atividade por mais que 15 minutos, o acesso será encerrado
	Logins sem atividade por mais de 60 dias entram em estado inativo.
APÊNDICE B – DOCUMENTO DE MENSAGENS
MENSAGENS DO SISTEMA
	“Login Invalido” 
	“Preencha todos os campos”
	“Todas As informações devem ser preenchidas”
	“Chamado adicionado com sucesso”
	“Já existe um usuário com o nome informado”
	“As especialidades do técnico devem ser informadas”
	“O ‘TipoUsuario’ ’UsuárioNome’ foi adicionado”
	“O detalhe de espera deve ser inserido”
	“As senhas não conferem”
	“Senha alterada com sucesso”
	“Iniciado atendimento do chamado” 
	“Chamado encerrado”
	“Seu chamado foi encerrado pelo ‘TecnicoNome’ as 00:00”
	“Seu chamado está em espera até que uma solução esteja possível”
	“A especialidade já está cadastrada”
	“O setor informado já está cadastrado”
	“Especialidade adicionado”
	“Setor adicionado”
	“O técnico a ser transferido deve ser escolhido”
	“O acesso será excluído da base de dados”
	“Chamado transferido para ‘TecnicoNome’
	“Nenhum usuário selecionado, escolha um para prosseguir”
	“Os usuários selecionados foram excluídos”
	“Nenhum usuário inativo”
	“A nova senha não pode ser igual a atual”
APÊNDICE C – DOCUMENTO DE VISÃO
DOCUMENTO DE VISÃO DO PROJETO
HISTÓRICO DE VERSÕES 
	DATA
	VERSÃO
	DESCRIÇÃO
	AUTOR
	REVISOR
	APROVADO
	16/03/2017
	1.0
	Primeira versão
	Jaqueline
	Diego
	Sim
	23/03/2017
	1.1
	Mudanças gerais
	Willian
	Diego
	Sim
PARTES INTERESSADAS
Organização-Cliente
Jaime Markovicz 
Equipe de Desenvolvimento
Diego Ramos de Paula, Jaqueline Silva de Oliveira, Willian Douglas Gobbi.
Organograma de funções
DOCUMENTAÇÃO
Objetivo
A finalidade deste documento é coletar e definir as necessidades de alto-nível e características do projeto de software CallWork, focando nas funcionalidades requeridas pelas partes interessadas e usuários, bem em como estes requisitos serão abordados no projeto de software.
A visão do projeto documenta o ambiente geral de processos a ser desenvolvido para o sistema durante o projeto, fornecendo a todos os envolvidos uma descrição compreensível deste e de suas funcionalidades.
Este Documento de Visão documenta apenas as necessidades e funcionalidades do sistema que estarão sendo atendidas no projeto de software.
Cenário Atual
Atualmente a organização não possui qualquer sistema ou controle em suas resoluções dos problemas ocorridos.
A carência de um sistema de controle dos problemas acaba deixando sem saber quando que cada ação é tomada para a solução da ocorrência. Não se sabe o técnico que a realizou, tão bem quem a solicitou. Um dos problemas ocorridos é de sobrecarga ao técnico, que às vezes recebe inúmeras requisições, e por ventura acaba que se esquecendo de algumas. E isso acaba gerando atrito entre solicitante e solucionador.
Sem contar a questão de que pode haver casos de que uma determinada situação é mais prioritária que a outra.
Uma demonstração do fluxo de atividade pode ser vista no capitulo 4 sobre o Diagnóstico do Ambiente.
Descrição do Projeto
Com a implantação do sistema a solução dos problemas se tornará mais eficaz, pois os chamados serão ordenados por prioridade sendo os mais urgentes atendidos primeiro. Cada chamado terá um técnico, um usuário e local atribuído ao mesmo, facilitando a detecção e controle dos problemas ocorridos dentro da Câmara Municipal de Araucária.
O diagrama de atividade de como o sistema deverá ser operado pode ser visto abaixo:
Futuro processo de negócio
 Principais funcionalidades
Login;
Cadastro de novos usuários;
Alteração de senha;
Exclusão de acessos inativos;
Cadastro de setores e especialidades técnicas;
Abertura de chamados;
Atendimento de chamado;
Transferência de chamado;
Finalização de chamado;
Atribuição de chamado a técnico;
Listagem individual de chamados realizados;
Listagem hierárquica de chamados realizados;
Listagemindividual de chamados atendido;
Relatórios gerais.
Envolvimento
 Abrangência
O sistema CallWork será desenvolvido para o uso interno de órgãos públicos municipais.
 Papel das Partes Interessadas
Cliente
	Descrição
	Fornece as especificações que o sistema deverá atender
	Papel no desenvolvimento
	Descrever os requisitos do sistema
	Insumos ao projeto
	- Informações sobre o funcionamento do órgão público
- Requisitos
- Aprovação e implementação do projeto
	Representante
	Jaime Markovicz
Equipe de desenvolvimento
	Descrição
	É o time que desenvolve o sistema
	Papel no desenvolvimento
	Levantar e analisar o problema do cliente, projetar, desenvolver, testar e implantar o sistema
	Insumos ao projeto
	- Levantamento de requisitos
- Análise do projeto
- Projetar o sistema
- Desenvolver
- Testar
- Implantar
	Representante
	Diego Ramos
 Papel dos Atores
 
Solicitante
	Descrição
	É quem utilizará o sistema diariamente.
	Papel 
	O solicitante informar o problema ocorrido.
	Insumos ao sistema
	- Inserir problema
- Alterar senha
- Verificar problemas enviados
	Representante
	Solicitante
Administrador
	Descrição
	Gerenciará todo o sistema.
	Papel 
	O administrador criará acesso para todos os usuários que a solicitarem para que possa ter o acesso ao sistema de criação de chamados, bem como detalhes de todos os processos da ocorrência
	Insumos ao sistema
	- Criar acesso
- Excluir acesso
- Alterar senha
- Definir chamado a técnico especifico 
- Cadastrar setor
- Cadastrar especialidade
- Monitoramento por relatórios
	Representante
	Administrador
Técnico 
	Descrição
	Gerenciará todo o sistema.
	Papel 
	O técnico atenderá as ocorrências solicitadas especificando seu andamento
	Insumos ao sistema
	- Criar acesso 
- Alterar senha
- Cadastrar setor
- Cadastrar especialidade
- Atender chamado
- Transferir chamado
- Colocar chamado em espera
- Monitoramento por relatórios
	Representante
	Técnico
 Necessidades e Funcionalidades
	Definir acessos
	Prioridade
	Criar ou alterar acesso para todos
	Crítico
	Id Func. 
	Gerenciar os acessos / Administrador, Técnico 
	F1.1
	Gerar acesso
	
	Ator: Administrador, técnico 
	F1.2
	Excluir acesso
	
	Ator: Administrador
	Gerar relatórios
	Prioridade
	Exibir gráficos e relatórios
	Útil
	Id Func. 
	Processo de Relatórios/ Solicitante, Técnico, Administrador
	F1.1
	Relatório geral
	
	Ator: Administrador
	F1.2
	Relatório individual
	
	Ator: Administrador, Solicitante, Técnico
	F1.3
	Relatório de problemas
	
	Ator: Administrador, Solicitante, Técnico
	Solução do problema
	Prioridade
	Solucionar todos as eventualidades
	Crítico
	Id Func. 
	Processo para solução do problema / Solicitante, Técnico, Administrador
	F1.1
	Inserir chamado
	
	Ator: Solicitante 
	F1.2
	Atender chamado
	
	Ator: Técnico
	F1.3
	Finalizar chamado
	
	Ator: Técnico 
	F1.4
	Transferir chamado
	
	Ator: Técnico 
	F1.5
	Atribuir chamado
	
	Ator: Administrador
	F1.6
	Definir chamado em espera
	
	Ator: Técnico 
Restrições/Premissas
Restrições
Prazo;
Sistema operacional Linux;
Banco de dados MySQL;
Linguagem de programação PHP 7;
Servidor Xampp.
Premissas 
Acesso aos servidores;
Acesso aos computadores e recursos da câmara municipal de araucária;
Colaboração dos funcionários.
Expectativa de Entrega do Produto: julho de 2017
APÊNDICE D – DOCUMENTO DE REGRAS DE NEGÓCIO
DOCUMENTO DE REGRAS DE NEGÓCIO
HISTÓRICO DE VERSÕES 
	DATA
	VERSÃO
	DESCRIÇÃO
	AUTOR
	REVISOR
	APROVADO
	14/03/2017
	1.0
	Primeira versão
	Jaqueline
	Diego
	Sim
	23/03/2017
	1.1
	Mudanças gerais
	Diego
	Willian
	Sim
Objetivo
O objetivo da Especificação de Regras de Negócio é documentar as regras aplicáveis ao negócio. Essas regras, em geral, constituem declarações de políticas ou condições que devem ser satisfeitas pelo processamento da aplicação.
Regras de negócios
 CHAMADO
RN – Solicitante do chamado
	O nome do solicitante deve ser ligado ao chamado. 
RN – Descrição do problema
	A descrição do problema deve ser obrigatoriamente inserida (Campo de 200 caracteres).
RN – Setor da ocorrência 
	O setor do problema deve ser obrigatoriamente selecionado de uma lista existente.
RN – Nível prioritário
	O nível prioritário deve ser informado, se o nível hierárquico permitir, sendo estes, baixo, normal ou urgente.
RN – Status inicial
	Por padrão, o status inicial deve ser “Aguardando Início”.
RN – Chamados realizados
	Os solicitantes deverão ver o histórico de seus chamados adicionados independente do seu status. Sendo que os níveis hierárquicos, deverão ver os históricos de solicitantes de sua responsabilidade.
RN – Chamados atendidos
	Cada técnico poderá visualizar o histórico de seus atendimentos.
RN – Transferência de chamados
	O técnico poderá transferir o chamado sob sua atuação para outro técnico, informando o mesmo a sua transferência.
RN – Atendimento do chamado
	O técnico deverá iniciar um chamado, passando a ficar no status de “em atendimento”.
RN – Finalização do chamado
	O técnico após o seu atendimento, deverá finalizar o chamado, passando a ficar no status “Finalizado” e informando o solicitante sobre seu encerramento.
RN – Atendimento em espera
		O técnico deverá definir em espera quando o problema não puder ser solucionado de imediato, assim detalhando e informando o motivo da ocorrência não puder ter sido solucionado no momento. Também deverá informar o solicitante e seus superiores na hierarquia. 
RN – Controle de horário
		O horário de cada mudança de status (aguardando início, em andamento, em espera e finalizado) deve ser registrado.
RN – Auxílio técnico
		No momento da finalização da ocorrência, caso houve algum tipo de auxílio técnico, deverá ser informado todos os técnicos que participaram do processo de solução do problema.
RN – Definir chamado ao técnico
			Os administradores poderão atribuir a ocorrência para um determinado técnico. 
RN – Relevância por nível prioritário 
		Ocorrências que tiverem nível prioritário mais alto, devem ser mostradas antes das outras com níveis mais baixos, fazendo com que os técnicos deem as devidas atenções.
 LOGIN
RN – Acesso
	O sistema somente poderá ser utilizado por um usuário logado, obrigatoriamente informando os dados de acesso como o nome de usuário e senha que obteve cadastramento previamente.
RN – Usuários inativos
	O sistema deve deixar o usuário inativo quando o login não for realizado por mais de 60 dias, informando aos administradores, deixando-os a opção de exclusão ou não.
 MANTER USUÁRIO 
RN – Criação de acesso solicitantes
	A criação de acesso somente poderá ser realizada pelos técnicos e administradores, inserindo o nome de usuário, senha padrão, setor e o nível hierárquico.
RN – Criação de acesso técnicos
	Somente administradores e técnicos poderão adicionar técnicos, inserindo o nome, senha e as suas especialidades.
RN – Criação de acesso administradores
	Somente administradores podem adicionar outros administradores.
RN – Cadastro de senha
	A senha deverá ter no mínimo 6 e no máximo 10 caracteres e deverá estar criptografada conforme as regras MD5.
RN – Preenchimento obrigatório
	Todos os campos do usuário identificados por um asterisco devem ser obrigatoriamente preenchidos.
RN – Atribuição de nível hierárquico
	O nível hierárquico deve ser selecionado de uma lista para cada usuário. Os níveis são: Coordenadores, Diretores, chefes de gabinete e funcionários.
RN – Alteração de senha
	A senha poderá ser alterada posteriormente dentro do próprio sistema. Para o primeiro acesso deve ser obrigatório apresentar a tela de alteração de senha.
RN – Alteração de senha pelo administrador
	O administrador ou o técnico poderá resetar a senha para um padrão. 
SETOR
RN – Adicionarsetor
	Somente os administradores e os técnicos podem adicionar setores, como um nome.
RN – Inserir duplicata
	O sistema não poderá inserir um setor que já esteja cadastrado.
RN – Exclusão de setor
	O sistema deve permitir excluir o setor. Caso o setor já esteja em ligação com algum usuário, o sistema deve informar se realmente deseja excluir. Assim é alterado todos os usuários que possuem essa ligação.
 ESPECIALIDADE
RN – Adicionar especialidade
	As especialidades de cada técnico devem ser inseridas pelos administradores e técnicos, como o nome da especialidade.
RN – Inserir duplicata
	O sistema não poderá inserir uma especialidade que já esteja cadastrada.
RN – Exclusão de especialidade
	O sistema deve permitir excluir a especialidade. Caso a especialidade já esteja em ligação com algum técnico, o sistema deve informar se realmente deseja excluir. Assim é retirado de todos os técnicos que possuem essa ligação.
 RELATÓRIOS
RN – Tipos de relatórios 
	Os solicitantes com níveis de hierarquia elevada e os administradores poderão visualizar através de gráficos e estáticas a produtividade de cada subordinado.
RN – Produtividade individual
	Cada técnico deverá poder observar o seu rendimento (diário, semanal e mensal) através de um relatório gerado pelo sistema.
APÊNDICE E – DOCUMENTO DE ESPECIFICAÇÃO DE CASOS DE USO
DOCUMENTO DE ESPECIFICAÇÃO DE CASOS DE USO
HISTÓRICO DE VERSÕES 
	DATA
	VERSÃO
	DESCRIÇÃO
	AUTOR
	REVISOR
	APROVADO
	27/03/2017
	1.0
	Primeira versão
	Willian
	Diego
	Sim
	05/04/2017
	1.1
	Adição
	Diego
	Willian
	Sim
Casos De Uso
Para casos de uso significativos, veja o capitulo de desenvolvimento.
UC03 – Login	
Caso de uso para logar.
	UC03 – Logar
	Atores: Solicitante, Técnicos, Administradores
	Descrição: Acessar recursos do sistema
	Informações adicionais:
Pré-condições:
Usuário precisa entrar na tela de login
Pós-condições de sucesso:
Acesso as telas do sistema
	Requisitos atendidos:
RF1 – Autenticar usuário
FLUXO PRINCIPAL
O ator decide entrar no sistema.
O sistema solicita as informações obrigatórias para garantir acesso ao sistema conforme a regra RN – Acesso.
O ator informa os dados do acesso.
O ator clica no botão para entrar
O sistema valida os dados do acesso.
O sistema redireciona para tela inicial para o tipo de usuário.
O caso de uso se encerra.
FLUXO ALTERNATIVO
O acesso é realizado pela primeira vez
O usuário digita uma nova senha.
O usuário digita a senha de conferência.
O sistema valida os dados do acesso.
O sistema altera a senha padrão para a nova no banco de dados.
O sistema redireciona para tela inicial para o tipo de usuário.
O caso de uso se encerra.
FLUXO EXCEÇÃO
Fluxo Exceção 1
O usuário digita informações inexistente ou erradas
O sistema informa a MSG1.
O fluxo retorna ao passo 2 do fluxo principal.
Fluxo Exceção 2
O usuário digita a senha de conferência diferente da principal
O sistema informa a MSG9
O fluxo retorna ao passo 2 do fluxo alternativo.
Fluxo Exceção 3
O usuário não preenche todos os campos.
O sistema informa a MSG2
O fluxo retorna ao passo 2 do fluxo alternativo.
CRITÉRIOS DE ACEITE
O sistema deve receber todas as informações necessárias do usuário.
PROTÓTIPO DE TELA
PROTÓTIPO DE TELA DE LOGIN
PROTÓTIPO DE TELA DE PRIMEIRO ACESSO
UC05 – Exclusão de usuários inativos
Caso de uso para exclusão de usuários inativos.
	UC05 – Excluir Usuários Inativos
	Atores: Administradores
	Descrição: Excluir usuários inativos
	Informações adicionais:
Pré-condições:
Administrador precisa estar logado.
Administrador precisa estar na tela de exclusão de acessos
Pós-condições de sucesso:
Acesso de usuário eliminado do banco de dados
	Requisitos atendidos:
RF12 – Excluir usuários inativos
FLUXO PRINCIPAL
O ator decide excluir acesso do usuário conforme a regra 2.2.2. RN – Usuários inativos
O ator seleciona os usuários na lista.
O ator clica no botão para excluir.
O ator escolhe “Sim” na caixa de diálogo. 
O caso de uso se encerra.
FLUXO ALTERNATIVO
O sistema não retorna nenhum usuário.
O sistema informa a MSG23.
O caso de uso se encerra.
FLUXO EXCEÇÃO
O ator não selecionou nenhum usuário.
O sistema mostra a MSG22.
CRITÉRIOS DE ACEITE
O sistema deve receber excluir todos os usuários selecionados do banco de dados.
PROTÓTIPO DE TELA
PROTÓTIPO DE TELA DE EXCLUSÃO DE ACESSOS
PROTÓTIPO DE TELA DE EXCLUSÃO DE ACESSOS
UC06 – Adicionar Especialidades
Caso de uso para adição de especialidades.
	UC06 – Adicionar Especialidades
	Atores: Administradores, Técnicos
	Descrição: Adicionar nova especialidade
	Informações adicionais:
Pré-condições:
Administrador precisa estar logado.
Administrador precisa estar na tela de adição de especialidades
Pós-condições de sucesso:
Especialidade adicionado no banco de dados
	Requisitos atendidos:
RF9 - Cadastrar especialidades
FLUXO PRINCIPAL
O ator decide adicionar nova especialidade conforme a regra RN – Adicionar especialidade.
O ator insere os dados necessários.
O sistema valida os dados.
O ator retorna a mensagem MSG17 - Especialidade_Adicionado.
O caso de uso se encerra.
FLUXO ALTERNATIVO
Não se aplica nesse caso de uso.
FLUXO EXCEÇÃO
Fluxo de exceção 1
O administrador ou técnico não informa nenhum dado
O sistema informa o erro ao ator MSG2 - Campos_Vazios.
O fluxo retorna ao passo 2 do fluxo principal.
Fluxo de exceção 2
O administrador ou técnico informa uma especialidade já existente.
O sistema informa o erro ao ator MSG15 - Erro_Adicionar_Especialidade
O fluxo retorna ao passo 2 do fluxo principal.
CRITÉRIOS DE ACEITE
Adição da especialidade.
Tratamento da exceção.
PROTÓTIPO DE TELA
PROTÓTIPO DE TELA DE ADICIONAR ESPECIALIDADE
UC07 – Adicionar Setores
Caso de uso para adição de setores.
	UC07 – Adicionar Setores
	Atores: Administradores, Técnicos
	Descrição: Adicionar novo setor
	Informações adicionais:
Pré-condições:
Administrador precisa estar logado.
Administrador precisa estar na tela de adição de setores
Pós-condições de sucesso:
Setor adicionado no banco de dados
	Requisitos atendidos:
RF8 - Cadastrar setores
FLUXO PRINCIPAL
O ator decide adicionar nova especialidade conforme a regra RN – Adicionar Setor.
O ator insere os dados necessários.
O sistema valida os dados.
O ator retorna a mensagem MSG18 - Especialidade_Adicionado.
O caso de uso se encerra.
FLUXO ALTERNATIVO
Não se aplica nesse caso de uso.
FLUXO EXCEÇÃO
Fluxo de exceção 1
O administrador ou técnico não informa nenhum dado
O sistema informa o erro ao ator MSG2 - Campos_Vazios.
O fluxo retorna ao passo 2 do fluxo principal.
Fluxo de exceção 2
O administrador ou técnico informa uma especialidade já existente.
O sistema informa o erro ao ator MSG16 - Erro_Adicionar_Setor
O fluxo retorna ao passo 2 do fluxo principal.
CRITÉRIOS DE ACEITE
Adição da especialidade.
Tratamento da exceção.
PROTÓTIPO DE TELA
PROTÓTIPO DE TELA DE ADICIONAR SETOR