relatorio final de estágio supervisionado - lucas pinto e silva.pdf
Post on 12-Oct-2015
49 Views
Preview:
TRANSCRIPT
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAO DE ENSINO DE GRADUAO EM
CINCIA DA COMPUTAO
RELATRIO DE ESTGIO SUPERVISIONADOANLISE E PROJETO DE UM SISTEMA DE
ACOMPANHAMENTO PARA OS COORDENADORES DEPROJETOS DA FUNDAO UNISELVA
LUCAS PINTO E SILVA
CUIAB MT
2014
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAO DE ENSINO DE GRADUAO EM
CINCIA DA COMPUTAO
RELTORIO DE ESTGIO SUPERVISIONADOANLISE E PROJETO DE UM SISTEMA DEACOMPANHAMENTO PARA OS COORDENADORES DE
PROJETOS DA FUNDAO UNISELVA
LUCAS PINTO E SILVA
Relatrio apresentado ao Instituto de
Computao da Universidade Federal de
Mato Grosso, para obteno do ttulo deBacharel em Cincia da Computao.
CUIAB MT
2014
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAO DE ENSINO DE GRADUAO EM
CINCIA DA COMPUTAO
LUCAS PINTO E SILVA
Relatrio de Estgio Supervisionado apresentado Coordenao do Curso deCincia da Computao como uma das exigncias para obteno do ttulo deBacharel em Cincia da Computao da Universidade Federal de Mato Grosso
Aprovado por:
Prof. Dr. Joo Paulo Igncio Ferreira Ribas
Instituto de Computao
(Coordenador de Estgios)
Prof. MSc. Thiago Meirelles Ventura
Instituto de Computao
(Orientador)
Alberto Maral Figueiredo Tavares JuniorCoordenador do Ncleo de Processamento de Dados da Uniselva
(Supervisor)
Prof. Dr. Cristiano Maciel
Instituto de Computao
(Diretor da Fundao Uniselva)
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
DEDICATRIA
minha av, Zil da Silva Pinto, quedeve estar muito orgulhosa de mim pormais esta conquista, onde quer que elaesteja.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
AGRADECIMENTOS
Agradeo primeiramente a minha famlia, em especial aos meus pais Antnio
Silvestre da Silva e Eliana da Silva Pinto, que sempre lutaram para que eu tivesse o
necessrio para crescer e me ensinaram a fazer o mesmo para conquistar o que eu
quero. Agradeo a famlia Melo Ribeiro pelos 5 anos de apoio, durante toda a minha
graduao e tambm no meu intercmbio. Em especial, agradeo a minha namorada,
Ana Carolina de Melo Ribeiro, pela compreenso e pacincia ao sacrificar nosso
tempo juntos para a escrita deste relatrio. Ao professor Cristiano Maciel por apoiar
meu crescimento acadmico e profissional, desde o meu primeiro estgio at a
oportunidade de trabalhar na Uniselva e desenvolver este trabalho. Ao professor
Thiago Meirelles Ventura por ter sido meu orientador, no s na escrita deste
relatrio mas tambm durante todo o meu estgio na STI/UFMT, me ajudando a
construir minha carreira profissional desde o comeo. Ao meu supervisor Alberto
Maral Figueiredo Tavares Junior e meus colegas de trabalho pela colaborao na
execuo dos trabalhos aqui apresentados. E agradeo tambm a todas as outras
pessoas que, direta ou indiretamente, me ajudaram a chegar at aqui.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
SUMRIO
LISTA DE FIGURAS .......................................................................................................................... 7LISTA DE SIGLAS E ABREVIATURAS ..................................................... .................................... 8RESUMO .............................................................................................................................................. 91. INTRODUO ........................................................................................................................ 10
1.1 JUSTIFICATIVA........................................................................................................................ 111.2 OBJETIVO GERAL.................................................... ........................................................... ..... 111.3 OBJETIVOS ESPECFICOS................................................... ...................................................... 111.4 ORGANIZAO DO TRABALHO............................................................................................... 12
2. REVISO DE LITERATURA .................................................... ............................................ 132.1 ENGENHARIA DE SOFTWARE....................................................... ............................................ 13
2.1.1 Processos de software .................................................................................................. 132.1.2 Modelos de processo de software ........................................................ ......................... 162.1.3 Gerncia de projeto ...................................................................................................... 17
2.2 CONCEITO OPERACIONAL....................................................................................................... 192.3 ELICITAO DE REQUISITOS................................................................................................... 202.4 PROJETO DE SOFTWARE.......................................................................................................... 212.5 PROTOTIPAO....................................................... ........................................................... ..... 23
3. MATERIAIS, MTODOS E TCNICAS UTILIZADOS .................................................... 253.1 MODELO CASCATA DUPLA......................................................... ............................................ 253.2 SISTEMAS RELACIONADOS..................................................................................................... 263.3 CONOPS ...................................................... ........................................................... ............... 283.4 PROTTIPOS............................................................................................................................ 283.5 DOCUMENTO DE REQUISITOS.................................................................................................. 293.6 DOCUMENTO DE PROJETO....................................................................................................... 303.7 TECNOLOGIAS DE DESENVOLVIMENTO.......................................................... ......................... 32
4. RESULTADOS ......................................................................................................................... 334.1 DOCUMENTO CONOPS .......................................................................................................... 334.2 DOCUMENTO DE REQUISITOS.................................................................................................. 374.3 DOCUMENTO DE PROJETO....................................................................................................... 38
5. DIFICULDADES ENCONTRADAS .................................................... .................................. 426. CONCLUSES ......................................................... ........................................................... ..... 437. REFERNCIAS BIBLIOGRFICAS ........................................................... ......................... 44APNDICE I: DOCUMENTO CONOPS ...................................................... .................................. 46APNDICE II: DOCUMENTO DE REQUISITOS...................................... .................................. 85APNDICE III: DOCUMENTO DE PROJETO ................................................... ......................... 93
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
7
LISTA DE FIGURAS
FIGURA 1:DIAGRAMA DE CLASSES (PRESSMAN,2010,P.843) ......................................................... 22FIGURA 2:DIAGRAMA ENTIDADE-RELACIONAMENTO........................................................... ............... 23FIGURA 3:MODELO DE CASCATA DUPLO NA PRTICA (WAZLAWICK,2013,P.30) .......................... 26FIGURA 4:PGINA INICIAL DO UNISIG.................................................................................................. 27FIGURA 5:FERRAMENTA DE PROTOTIPAO BALSAMIQ...................................................................... 29FIGURA 6:FERRAMENTA BRMODELO................................................................................................... 31FIGURA 7:FERRAMENTA DIA.......................................................... ...................................................... 31FIGURA 8:EXTRATO DE PROJETO NO UNISIG...................................................... .................................. 35FIGURA 9:PROTTIPO DO NOVO EXTRATO DO PROJETO........................................................ ............... 36FIGURA 10:DERQUE REPRESENTA O BANCO DE DADOS DO NOVO SISTEMA......................................... 39FIGURA 11:DIAGRAMA DE CLASSES PARA REPRESENTAR O COMPORTAMENTO DO NOVO SISTEMA...... 40
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
8
LISTA DE SIGLAS E ABREVIATURAS
UFMT Universidade Federal de Mato Grosso
IFES Instituio Federal de Ensino Superior
IEEE Instituto de Engenheiros Eletricistas e Eletrnicos
RF Requisito Funcional
RNF Requisito No-Funcional
DER Diagrama Entidade-RelacionamentoMER Modelo Entidade-Relacionamento
UML Unified Modeling Language
PMI Project Management Institute
PMBOK Project Management Body of Knowledge
CONOPS Documento de Conceito Operacional
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
9
RESUMO
A Fundao Uniselva tem como um de seus grandes objetivos apoiar projetos de
pesquisa, ensino, extenso e desenvolvimento institucional da UFMT. Para isso, ela
precisa fornecer informaes e prestar contas sobre estes projetos para seus
respectivos coordenadores. Porm, o sistema atualmente em funcionamento,
chamado Unisig, no consegue atender todas as demandas de seus usurios. Este
trabalho visa descrever o processo de criao de um novo sistema para suprir as
necessidades dos coordenadores, desde a coleta de requisitos at a preparao para a
implementao. Com este novo sistema, espera-se que os coordenadores tenham uma
melhor viso da situao de seus projetos, bem como melhorar o gerenciamento dos
recursos financeiros. No decorrer deste trabalho, so revisadas as diretrizes da
Engenharia de Software, alm de mostrar como os mtodos envolvidos foram
empregados neste caso.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
10
1.INTRODUO
A Universidade Federal de Mato Grosso (UFMT) uma Instituio Federal
de Ensino Superior (IFES) que possui o objetivo de promover o ensino, a pesquisa e
a extenso nos diferentes ramos do conhecimento, bem como a divulgao cientfica,
tcnica e cultural (UFMT, 2014). Uma forma de alcanar este objetivo atravs de
projetos coordenados pelos prprios professores da UFMT, porm, o processo
burocrtico e no permite uma gerncia fcil dos recursos financeiros. Neste caso, o
coordenador pode optar por executar seu projeto por meio da Fundao Uniselva.
A Fundao de Apoio e Desenvolvimento da Universidade Federal de Mato
Grosso Fundao Uniselva segundo o estatuto da Uniselva (2014), uma
entidade de direito privado e sem fins lucrativos que tem como objetivos gerais
promover e subsidiar programas de pesquisa, prestar servios tcnicos, alm de
exercer outras atividades que contribuam com o desenvolvimento tcnico, cientfico
e assistencial da UFMT e de sua comunidade.
Portanto, a Fundao Uniselva cria uma ponte entre o projeto de um
coordenador com o rgo financiador e assume a responsabilidade de gerenciar a
comunicao entre as partes, tomando conta de todo o trabalho burocrtico e
gerenciando os recursos financeiros, permitindo que o coordenador possa ter um foco
maior na execuo de seu projeto. Alm disso, a Uniselva tambm controla a
inscrio de alunos e participantes em projetos que promovem cursos e eventos,
prestando assim servios no s para a comunidade acadmica da UFMT mas
tambm para a externa.
Para fornecer informaes sobre os projetos para seus respectivoscoordenadores, a Fundao Uniselva conta com um sistema chamado Unisig, que
fornece dados sobre o extrato financeiro do projeto, seu saldo oramentrio,
faturas/bloquetos, alm de informaes cadastrais, como rgo financiador, conta
bancria, vigncia, entre outras.
Infelizmente, ao longo dos anos em que o Unisig esteve (e ainda est) em
funcionamento, a Fundao Uniselva percebeu que, atravs das opinies e sugestes
dos coordenadores de projetos, o sistema no est conseguindo exercer de formasatisfatria sua funo, que dar uma viso completa da situao do projeto. H
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
11
ento, uma necessidade de um sistema com mais funcionalidades para que as
demandas dos usurios possam ser atendidas.
1.1Justificativa
Como pode ser visto anteriormente, h a necessidade de um sistema onde
informaes sobre receita, faturas, adiantamentos, entre outras, estivessem mais
detalhadas do que o sistema atual, alm de incluir uma funcionalidade de
acompanhamento do cronograma do projeto, fazendo a ligao entre as despesas e o
que foi previsto para um dado perodo.Faz-se necessrio tambm uma rea de alertas e notificaes, onde o
coordenador poderia ser informado sobre prazos e ocorrncias relacionadas ao
cronograma, para que no ocorram imprevistos e transtornos com vencimentos e
recursos financeiros gastos inapropriadamente.
Portanto, para resolver esse problema, um novo sistema deve ser proposto e
desenvolvido, seguindo, claro, as boas prticas de engenharia de software.
1.2Objetivo Geral
Tendo em vista as necessidades dos coordenadores citadas acima, este
trabalho tem como objetivo relatar os conhecimentos necessrios e as etapas do
processo de desenvolvimento de um novo sistema, chamado Portal do Coordenador,
que ir permitir um melhor acompanhamento do projeto por parte do coordenador e
reduzir os problemas relatados pelos usurios do sistema atual, o Unisig.
1.3Objetivos Especficos
Para executar o desenvolvimento do novo sistema, este trabalho conta com
os seguintes objetivos especficos:
Estudar os principais conceitos de engenharia de software.
Pesquisar sobre Conceito Operacional.
Analisar as necessidades dos usurios do sistema Unisig.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
12
Elaborar um documento de Conceito Operacional.
Elicitar os requisitos do Portal do Coordenador.
Escrever um documento de projeto.
Criar uma prototipao das funcionalidades do novo sistema.
1.4Organizao do Trabalho
Os captulos deste trabalho esto organizados da seguinte forma:
Captulo 2: Faz uma reviso literria dos temas abordados neste trabalho.
Captulo 3: Lista e descreve os materiais, mtodos e tcnicas utilizados.Captulo 4: Descreve os resultados obtidos, onde so descritos os
documentos gerados.
Captulo 5: So descritas as dificuldades encontradas durante a execuo
dos trabalhos.
Captulo 6: O ltimo captulo descreve as concluses obtidas com este
trabalho, fazendo uma reflexo sobre a importncia deste trabalho e citando os
prximos passos a serem realizados.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
13
2.REVISO DE LITERATURA
A necessidade de padronizar, automatizar e agilizar a execuo de tarefas e
processos por parte de organizaes, grupos e at indivduos explica o motivo de se
estudar e aplicar determinados conceitos, afim de se obter um produto que, mesmo
sendo algo intangvel, de grande importncia para que estes consigam atingir seus
objetivos.
Este captulo apresenta tais conceitos de engenharia de software e tambm
informaes sobre as principais tecnologias e metodologias utilizadas na realizao
deste trabalho.
2.1Engenharia de Software
Engenharia de Software a aplicao de uma abordagem sistemtica,
disciplinada e quantificvel para o desenvolvimento, operao e manuteno de
software (IEEE, apud PRESSMAN, 2010, p. 13). J para Sommerville (2007, p. 7),
ela uma disciplina da engenharia que se preocupa com todos os aspectos daproduo de software, desde os estgios iniciais da especificao do sistema at a
manuteno do mesmo depois de ter iniciado seu uso.
Sendo assim, pode-se entender que esta engenharia tem como objetivo
aplicar um processo de teorias, tcnicas, mtodos e ferramentas com o intuito de criar
um software que resolva um problema ou contribua com um processo ou trabalho.
2.1.1 Processos de software
No contexto da engenharia de software, um processo no uma prescrio
rgida de como construir um software de computador. Ao contrrio, uma
abordagem adaptvel que possibilita s pessoas (a equipe de software) realizar o
trabalho de selecionar e escolher o conjunto apropriado de aes e tarefas
(PRESSMAN, 2010, p. 14).
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
14
Deste modo, o processo de software visto como um guia para a criao de
um software, permitindo uma flexibilidade de sua execuo para se adequar s
necessidades e s condies do cliente e da equipe.Fazendo um agrupamento das aes e tarefas do processo, definimos as fases
de um processo. Uma fase um perodo de tempo no qual determinadas atividades
com objetivos bem especficos so realizadas (WAZLAWICK, 2013, p. 12).
Portanto, se uma, duas ou vrias tarefas so necessrias para se chegar a um ponto do
processo ou gerar algum documento, estas podem ser agrupadas e trabalhadas em
conjunto.
Mesmo que existam diversos processos de software, algumas fasesfundamentais so comuns dentre eles (SOMMERVILLE, 2007, p. 8):
1. Especificao de software: onde clientes e engenheiros definem o
software a ser produzido e suas regras de operao.
2. Desenvolvimento de software: onde o software projetado e
programado.
3. Validao de software: onde o software verificado para garantir que
ele faz o que o cliente solicitou.
4. Evoluo de software: onde o software modificado para se adaptar
s mudanas de necessidades dos consumidores e do mercado.
Uma vez definidas as fases do processo, possvel descer um nvel e dividir
cada fase em atividades. Para Pressman (2010, p. 31), em cada fase de um processo
de software definido, so executadas as atividades bsicas para que sejam atingidos
os objetivos propostos. Estas atividades constituem um conjunto mnimo para se
obter um produto de software.
Assim como as fases citadas acima aparecem frequentemente nos processos
de software, algumas atividades essenciais tambm esto presentes, mudando apenas
a ordem ou o nmero de vezes em que so executadas. De acordo com Sommerville
(2007, p. 75-82), elas podem ser listadas em cada fase desta maneira:
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
15
1. Especificao
i. Estudo de viabilidade: uma estimativa sobre se as necessidades
dos usurios sero atendidas usando as tecnologias de softwaree hardware atuais, para estudar se o sistema proposto ser
vivel do ponto de vista do negcio.
ii. Elicitao de requisitos e anlise: processo de derivao dos
requisitos do sistema atravs da observao de sistemas
existentes, conversas com usurios potenciais, anlise de
tarefas, entre outros. Este item abordado com mais detalhes
na seo 2.3.iii. Especificao de requisitos: atividade de traduzir as
informaes coletadas no item anterior para um documento
que define um conjunto de requisitos. A seo 3.5 mostra
como este documento foi elaborado no escopo deste trabalho.
iv. Validao de requisitos: verifica os requisitos em relao a
realismo, consistncia e integridade. Neste processo, alguns
erros no documento de requisitos so descobertos e devem ser
corrigidos.
2. Desenvolvimento
i. Projeto da arquitetura: os subsistemas que compem o sistema
e seus relacionamentos so identificados e documentados.
ii. Especificao abstrata: para cada subsistema, elaborada uma
especificao abstrata de seus servios e restries em que este
deve operar.
iii. Projeto da interface: para cada subsistema, projetada e
documentada sua interface com outros subsistemas.
iv. Projeto dos componentes: servios so alocados para
componentes e as interfaces destes componentes so
projetados.
v. Projeto da estrutura de dados: as estruturas de dados usados na
implementao do sistema so projetados em detalhes e
especificados.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
16
vi. Projeto de algoritmos: os algoritmos usados para fornecer
servios so projetados em detalhes e especificados.
3. Validaoi. Teste de componente: componentes individuais so testados
separadamente para garantir que eles operem corretamente.
ii. Teste de sistema: os componentes so integrados para criarem
o sistema. Este processo se preocupa em achar erros
provenientes de interaes no previstas entre os componentes.
iii. Teste de aceite: esta a ltima etapa do processo de testes,
antes do sistema ser aceito para uso, onde este testado comdados fornecidos pelo consumidor do sistema ao invs de
dados simulados.
4. Evoluo
i. Proposta de mudanas: aps o sistema estar em
funcionamento, novas propostas so feitas para adaptar o
sistema novas necessidades ou corrigir problemas,
reiniciando o ciclo.
As diferenas de como ou quando estas atividades sero realizadas ir
depender do modelo de processo de software a ser escolhido.
2.1.2 Modelos de processo de software
Para dar uma ordem s atividades do processo de software, so definidosmodelos de processo de software. Segundo Sommerville (2007, p. 8-9), um modelo
de processo de software uma descrio de um processo de software que apresenta
uma viso deste processo, podendo incluir atividades que fazem parte do processo de
software, de produtos de software e das funes das pessoas envolvidas na
engenharia de software.
A escolha de um modelo deve ser compatvel com a situao do sistema a ser
desenvolvido. A escolha errada pode trazer transtornos para o cliente e para a equipede desenvolvimento, podendo at comprometer a entrega do sistema.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
17
Existem vrios modelos de processo de software diferentes, cada um com
suas especificidades. Dentre eles, o mais comum o modelo de cascata (e suas
variaes). O modelo de cascata, algumas vezes chamado de ciclo de vida clssico,sugere uma abordagem sistemtica e sequencial para o desenvolvimento de software,
que inicia com a especificao dos requisitos do consumidor, passa pelo
planejamento, modelagem, construo e publicao, chegando no suporte do
software completo (PRESSMAN, 2010, p. 39).
Um dos motivos dele ser o mais comum a simplicidade de sua execuo, j
que o processo segue uma linha reta entre as etapas, sempre utilizando o trabalho
gerado em uma etapa como material para a prxima. Algumas de suas variaespermitem a alterao deste fluxo de trabalho, como o caso do modelo de cascata
dupla, em que, dependendo da necessidade ou da ocorrncia de algum imprevisto, o
processo pode voltar uma etapa atrs para refazer ou aperfeioar um trabalho. Esse
modelo que ser utilizado neste trabalho e mais informaes de como isso ser feito
podem ser encontradas na seo 3.1.
Escolher um modelo de processo de software essencial para garantir a
execuo correta das atividades do processo. Porm, tambm importante definir
como os trabalhos sero acompanhados, o tempo que estes levaro, o que fazer caso
algo inesperado acontea, entre outras questes. Para isso existe a gerncia de
projeto.
2.1.3 Gerncia de projeto
A gerncia de projeto pode ser entendida como uma disciplina dentro de umprocesso de engenharia de software, em geral exercida por um nico indivduo (o
gerente de projeto) cuja funo levar o projeto a alcanar os objetivos planejados
dentro dos prazos, com o custo e qualidade previstos (WAZLAWICK, 2013, p. 203).
Sendo assim, pode ser dito que o gerente de projeto tem a responsabilidade de manter
saudvel o andamento do projeto, verificando se os prazos esto sendo cumpridos
e se o trabalho est sendo feito como o esperado e com a qualidade prevista.
Para ser definido como ser guiada a gerncia do projeto, podem serreferenciadas fontes importantes como o Project Management Body of Knowledge
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
18
(PMBOK), publicado pelo Project Management Institute (PMI, 2014). De acordo
com Wazlawick (2013, p. 205), o PMBOK sugere dividir as atividades de
gerenciamento em nove reas, sendo elas:1. Gerenciamento de integrao: atividades que o gerente de projetos
executa de forma a garantir que todas as partes do projeto funcionem
juntas.
2. Gerenciamento do escopo: atividades necessrias para que o projeto
execute de fato o que for preciso para gerar o produto e somente isso.
3. Gerenciamento de tempo: atividades mais visveis em gerncia de projeto,
consistem em garantir que as atividades do projeto ocorram dentro dostempos previamente definidos.
4. Gerenciamento de custos: atividades que buscam garantir que o projeto
ocorra dentro do oramento definido.
5. Gerenciamento da qualidade: do ponto de vista externo, visa garantir que
o produto atenda s expectativas do cliente; do ponto de vista interno, visa
garantir que o produto seja suficientemente malevel para no dificultar
desnecessariamente o trabalho da equipe.
6. Gerenciamento de recursos humanos: atividades de aquisio, dispensa,
formao e motivao da equipe, bem como de alocao de funes e
relaes hierrquicas.
7. Gerenciamento das comunicaes: controle das comunicaes internas e
externas ao projeto.
8. Gerenciamento de riscos: uma das reas mais importantes da gerncia de
projetos, implica acompanhar o nvel de probabilidade e impacto dos
riscos e tomar medidas para diminu-los.
9. Gerenciamento de aquisies: atividades relacionadas aquisio de
produtos ou servios necessrios ao projeto que no sejam produzidos ou
fornecidos pela equipe de desenvolvimento.
Por meio da descrio destas reas, pode ser percebido que o PMBOK pode
ser aplicado para conduzir qualquer tipo de projeto, necessitando apenas do gerente
ter conhecimentos sobre este tipo, como o caso do gerente de projetos de software.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
19
2.2Conceito Operacional
Normalmente, o processo de software comea com elicitao de requisitos
para a elaborao do documento de requisitos. Porm, como ser mostrado na
prxima seo, os resultados desta etapa contm termos tcnicos e especficos da
engenharia de software, que podem ser de difcil compreenso por parte de alguns
dos envolvidos no projeto, principalmente o cliente e os consumidores. A elaborao
de um documento que descreva a proposta do sistema de uma forma a no necessitar
de conhecimentos tcnicos para a compreenso do assunto uma soluo para esteproblema.
O documento de Conceito Operacional (ConOps ou CONOPS) um
documento voltado ao usurio que descreve as caractersticas do sistema proposto
atravs do ponto de vista dos usurios. O documento CONOPS usado para
transmitir as caractersticas quantitativas e qualitativas gerais do sistema para o
usurio, cliente, desenvolvedor, e outros elementos organizacionais (IEEE 1362,
1998, p. 1). Por ser um documento bem estruturado e formalizado, seus componentespodem se encaixar em qualquer projeto de software, no importando a dimenso ou a
complexidade.
No CONOPS, os clientes e consumidores podem expressar suas ideias quanto
ao que esperam do sistema proposto sem se preocuparem com detalhes tcnicos
sobre os requisitos, como por exemplo se eles so testveis ou no. Ele permite
tambm que sejam discutidas vrias solues para os problemas apresentados, no se
limitando a apenas uma alternativa.
A estrutura de um documento CONOPS completo possui 9 captulos. Porm,
a ideia principal deste documento est nos captulos 3, 4 e 5. O captulo 3 fala sobre a
situao atual do sistema ou processo que o cliente queira substituir ou melhorar. No
captulo 4, so descritos os motivos e as justificativas para o desenvolvimento de um
novo sistema ou modificao do atual. J no 5, feita a proposta do novo sistema ou
modificao, estruturado de forma quase idntica ao contedo do captulo 3.
Atravs destes trs captulos, o cliente ou consumidor consegue ter uma viso
clara da situao em que se encontra o sistema ou processo; as razes que levaram
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
20
proposta de substituio ou melhoria; e como esta proposta ir solucionar os
problemas e/ou necessidades atuais.
Com o documento de CONOPS aprovado pelo cliente, pode-se ento partirpara a elicitao de requisitos da forma tradicional, agora tendo mais um documento
para se basear durante a coleta dos requisitos.
2.3Elicitao de requisitos
A elicitao de requisitos uma das atividades mais importantes do processo
de software. Ela a base para todo o trabalho de projeto e implementao do sistema,alm de servir como referncia na hora de validar o software criado. Pressman (2010,
p. 128) diz que a elicitao de requisitos combina elementos de soluo de
problemas, elaborao, negociao e especificao, e que, para encorajar uma
abordagem colaborativa e orientada a equipes para a coleta de requisitos, uma equipe
de interessados e desenvolvedores devem trabalhar em conjunto para identificar o
problema, propor elementos da soluo, negociar diferentes abordagens e especificar
um conjunto preliminar de requisitos da soluo. nesta fase de conversa e trabalho cooperativo que reside a dificuldade desta
atividade, pois normalmente as necessidades dos envolvidos no so descobertas
logo na primeira pergunta, sendo que muitas vezes nem os prprios clientes tem a
viso exata do que eles precisam. Isto um problema porque, se o que eles querem
no for claramente definido, o software criado no ir atender s necessidades e estes
estaro insatisfeitos, gerando transtornos e despesas para a equipe.
Por isso, a elicitao de requisitos no se prende apenas ao questionamento
sobre o que o cliente quer. Ela tambm deve ser baseadas em documentos que iro
interferir, restringir, ou suportar o sistema (por exemplo, o estatuto da empresa ou o
prprio documento CONOPS citado anteriormente), na observao da situao atual
do trabalho ou processo relacionado ao sistema, e na simulao de cenrios
operacionais.
Uma vez que a elicitao de requisitos tenha sido concluda e elaborado um
documento de requisitos (ver seo 3.5), temos uma viso clara das necessidades do
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
21
cliente e o que o sistema deve fazer. Devemos ento pensar como este deve operar e
qual ser sua estrutura atravs de um projeto de software.
2.4Projeto de software
O projeto de software um processo interativo em que os requisitos so
traduzidos em um desenho tcnico para a construo do software. Inicialmente, o
documento mostra uma viso holstica do software, ou seja, o projeto representado
em um alto nvel de abstrao nvel que pode ser diretamente relacionado ao
objetivo especfico do sistema e a requisitos mais detalhados de dados, funcionais e
comportamentais. medida que ocorrem as iteraes de projeto, os refinamentos
subsequentes levam a representaes de projeto em nveis de abstrao muito mais
baixos. Esses ainda podem ser relacionados aos requisitos, porm a conexo mais
sutil (PRESSMAN, 2010, p. 219).
Atravs desta definio, podemos entender que o papel do projeto de
software fazer a ligao entre os requisitos do cliente e dos consumidores com o
trabalho a ser realizado durante a implementao do software. Alm disso, o projetopermite que o desenvolvedor tenha uma viso completa de como o software deve ser
no sentido tcnico, o que no seria possvel caso o trabalho fosse feito diretamente
dos requisitos.
Para padronizar as representaes dos projetos e modelos de software, uma
das tecnologias mais utilizadas no momento a Unified Modeling Language (UML).
A UML uma linguagem padro para escrever desenhos tcnicos de software. Ela
pode ser usada para visualizar, especificar, construir e documentar os artefatos de umsistema baseado em software (PRESSMAN, 2010, p. 841).
Este padro foi desenvolvido por Grady Booch, Jim Rumbaugh e Ivan
Jacobson nos anos 90, unificando muitos modelos e notaes utilizadas na poca,
com a ajuda da prpria comunidade de desenvolvedores. Hoje, a UML j est em sua
segunda verso e conta com 14 diagramas diferentes para serem usados na
modelagem de software. Um deles o diagrama de classe, que se assemelha bastante
ao paradigma de programao orientada a objeto, fornecendo uma viso estrutural dosoftware.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
22
O diagrama de classe utiliza caixas para representar classes e interfaces,
divididos em partes horizontais. A parte de cima contm o nome da classe, a segunda
lista os atributos e a terceira contm as operaes e comportamentos. Orelacionamento entre as classes representado por linhas, onde a linha slida
significa associao, a flecha representa generalizao e, quando usada com uma
linha tracejada, d a ideia de realizao. Um exemplo do uso deste diagrama
mostrado na Figura 1.
Figura 1: Diagrama de Classes (PRESSMAN, 2010, p. 843)
Alm dos diagramas da UML, o projeto de software tambm construdo
utilizando outro diagrama, chamado Diagrama Entidade-Relacionamento (DER).Usado especificamente para dar uma viso do sistema em relao persistncia dos
dados, o DER, segundo Elmasri (2004, p. 49-50), uma notao diagramtica
associada ao Modelo Entidade-Relacionamento (MER), que por sua vez consiste em
um modelo de dados conceitual em alto nvel usado para o projeto conceitual de
sistemas que utilizam bancos de dados.
O DER utiliza uma notao similar ao diagrama de classes, porm, agora as
caixas representam entidades e os bales conectados a elas so os atributos. O
relacionamento entre as entidades representado por um losango e contm a
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
23
cardinalidade do relacionamento, que pode ser 1:1 (um-para-um), 1:N (um-para-
muitos) ou N:N (muitos-para-muitos). A Figura 2 ilustra um exemplo deste
diagrama.
Figura 2: Diagrama Entidade-Relacionamento
O projeto de software fornece uma viso grfica da estrutura do software para
o desenvolvedor. No entanto, tambm necessrio mostrar o mesmo para o cliente,
porm de uma forma menos tcnica e prxima do que ele receber ao fim do
desenvolvimento. Para isso, uma alternativa criar uma simulao de como o
software ir funcionar quando estiver pronto, utilizando a tcnica de prototipao.
2.5Prototipao
Um prottipo uma verso inicial de um software que usada para
demonstrar conceitos, experimentar opes de modelo e, geralmente, descobrir mais
sobre o problema e suas possveis solues (SOMMERVILLE, 2007, p. 409). Este
pode aparecer logo no incio da elicitao de requisitos, para tentar mostrar ao cliente
se as necessidades deste foram identificadas corretamente, durante o projeto do
sistema, para mostrar como os requisitos iro ser atendidos utilizando a estrutura
modelada nesta fase, e tambm no processo de testes, para verificar se o software
desenvolvido est de acordo com a viso que o cliente tinha.
Os prottipos podem ser classificados de trs formas, de acordo com sua
fidelidade ao produto final. Os prottipos de baixa fidelidade geralmente so
desenhados para se ter uma ideia inicial do software utilizando materiais simples,
como lpis e papel. J os de mdia fidelidade so desenvolvidos utilizando alguma
ferramenta computacional, como um editor de texto software de diagramao, e
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
24
apresentam um nvel de detalhamento maior. Por ltimo, os prottipos de alta
fidelidade so semelhantes ao produto final e so criados a partir de ferramentas
especializadas para prototipao ou usando as prprias tecnologias empregadas nodesenvolvimento do software.
No prximo captulo ser detalhado como a prototipao foi realizada para o
caso deste trabalho. Alm disso, ser detalhado tambm como foi feita a aplicao
dos outros conceitos citados neste captulo.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
25
3.MATERIAIS, MTODOS E TCNICAS UTILIZADOS
Uma vez definidos os conceitos necessrios no captulo anterior, as sees a
seguir iro descrever os materiais, mtodos e tcnicas utilizados no desenvolvimento
deste trabalho, mostrando o modo em que foram empregados e tambm as
adaptaes e escolhas feitas para o caso em estudo.
3.1Modelo Cascata Dupla
Como citado na seo 2.1.2, escolher um modelo de processo de software
um passo importante, pois este deve se encaixar no s nas condies do software,
mas principalmente nas condies da equipe de desenvolvimento para que seu uso
seja eficiente. Um dos modelos citados foi o modelo de cascata dupla, onde o fluxo
das atividades pode ser alterado de acordo com o resultado das atividades.
Sendo assim, este modelo foi escolhido para guiar as atividades deste trabalho
por ser um modelo de fcil compreenso, execuo, e por se enquadrar na
simplicidade do sistema a ser desenvolvido. Alm disso, ele tambm permite umaflexibilidade para que algumas fases possam ser revistas caso o resultado de outras
criem esta necessidade. Por exemplo, um requisito no identificado na fase de
elicitao que surgiu durante o teste de uma funcionalidade ou durante a aprovao
do cliente. Neste caso, a execuo do processo ter que retornar fase de elicitao e
incluir o novo requisito, alm de identificar outros requisitos que possam ter surgido
juntamente com este.
Este ltimo motivo fica mais claro quando observamos como as interaesentre as fases deste modelo acabam acontecendo na prtica, como mostra a Figura 3.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
26
Figura 3: Modelo de Cascata Duplo na prtica (WAZLAWICK, 2013, p. 30)
Na Figura 3, pode-se perceber que a mudana de fases neste modelo no se
limita fase adjacente, mostrando que a execuo de uma fase anterior no teria
efeito, j que a fonte do problema pode estar duas fases atrs da atual. Por exemplo, a
fase de teste poderia identificar um erro de entrada de dados que, mesmo executando
novamente a fase de codificao, no seria resolvido, uma vez que o modelo de
dados empregado no projeto no era o correto.
Tendo definido o modelo a ser utilizado, o prximo passo realizar o
levantamento dos requisitos do sistema. Para isso, algumas das maiores fontes de
informaes desta fase so os sistemas relacionados ao que ser desenvolvido.
3.2Sistemas Relacionados
A maior motivao para a realizao deste trabalho a substituio do
sistema atualmente utilizado na Fundao Uniselva, chamado Unisig, por outro que
atenda s necessidades dos usurios. No entanto, o prprio Unisig ser utilizado
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
27
como base para a criao do novo, j que este dever continuar oferecendo as
funcionalidades que o sistema atual oferece hoje.
O Unisig tem como objetivo fornecer informaes financeiras relacionadas execuo dos projetos da Uniselva para seus respectivos coordenadores. Ele foi
criado para agilizar o processo de disponibilizao de tais dados, visto que antes dele
os prprios funcionrios da Uniselva eram responsveis por coletar tais informaes
no sistema Gerencial (utilizado internamente na Fundao) e repassar para os
coordenadores atravs do telefone ou e-mail. Na Figura 4 representada a tela inicial
do sistema atualmente utilizado.
Figura 4: Pgina inicial do Unisig
Alm do Unisig, este trabalho ter influncia do novo sistema interno da
Uniselva que est sendo proposto juntamente com este e que tambm ir substituir o
sistema atual. Ambos iro ser desenvolvidos em conjunto para garantir o
compartilhamento correto das informaes entre eles, visto que as informaes
disponibilizadas para o coordenador sero alimentadas por este novo sistema interno.
Considerando ambos os sistemas correntes, a primeira atividade a ser
executada para a criao do novo sistema a elaborao do documento CONOPS.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
28
3.3CONOPS
Como citado na seo 2.2, o documento CONOPS faz parte da fase inicial dodesenvolvimento do sistema e tem grande importncia na comunicao das
necessidades identificadas e da soluo proposta para todos os envolvidos no projeto.
Sua estrutura se assemelha bastante com a proposta do padro IEEE 1362-98, porm,
as sees sobre o modo de operao e classe de usurio de ambos os sistemas em
estudo (atual e proposto) foram mescladas por conterem informaes sobrepostas,
alm do fato que estes sistemas no possurem estgios de funcionamento diferentes,
totalizando 7 captulos, ao contrrio dos 9 citados no padro. Alm disso, foi
adicionada uma pgina para a recomendao do documento por parte do chefe do
setor responsvel pela elaborao do projeto e a aprovao do Diretor da Uniselva.
Para a escrita deste documento, foram coletadas informaes de diferentes
fontes, sendo duas delas os sistemas relacionados citados na seo anterior. Na
descrio do Unisig, foram estudados documentos da Fundao Uniselva que citam
como este sistema deveria funcionar, porm sem adotar nenhum dos padres ou
metodologias de engenharia de software abordados neste trabalho. Por isso, tambm
foram realizadas entrevistas com os envolvidos no projeto para conseguir traar um
perfil deste sistema.
Uma vez definido como o sistema atual funciona, aconteceram outras
entrevistas com coordenadores de projetos, chefias dos setores de projeto e
financeiro, e tambm com a diretoria, desta vez para identificar os problemas e listar
os motivos de se criar um novo sistema. A partir da, foi elaborada a proposta citando
os mesmos tpicos abordados na descrio do sistema atual, como sugere o padro
seguido, com exceo das figuras da interface grfica, que foram substitudas por
prottipos.
3.4Prottipos
Considerando que o CONOPS tem como objetivo mostrar a proposta do novo
sistema de uma forma simples e compreensvel para o cliente, uma boa alternativa
para alcan-lo criar prottipos da interface grfica. Uma tima ferramenta paracriar tais prottipos o Balsamiq (BALSAMIQ, 2014).
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
29
Esta ferramenta foi escolhida por permitir uma rpida criao das telas do
sistema utilizando desenhos que se assemelham com um prottipo criado com lpis e
papel. No entanto, ela tambm possui componentes que correspondem aos elementosgrficos de programas de computador e pginas da Internet, o que d um visual
parecido com o produto final, como pode ser visto na Figura 5.
Figura 5: Ferramenta de Prototipao Balsamiq
Depois de criados os prottipos das funcionalidades do novo sistema e
anexados ao CONOPS, este j pode ser utilizado na prxima atividade da
especificao do sistema, que a escrita do documento de requisitos.
3.5Documento de Requisitos
Utilizando os conceitos de elicitao de requisitos citados na seo 2.3 e o
documento gerado na seo anterior, a escrita de um documento de requisitos servir
para listar as necessidades e funcionalidades de um modo mais formal e prximo da
linguagem do desenvolvedor, alm de ser usado como referncia para a realizao
dos testes.
Os requisitos levantados foram divididos entre duas categorias: funcionais eno-funcionais. Segundo Sommerville (2007, p. 119), requisitos funcionais so
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
30
afirmaes sobre servios que o sistema deve fornecer, como deve reagir a entradas
especficas e como se comportar em algumas situaes; os no-funcionais so
restries sobre tais servios e funcionalidades, incluindo restries de tempo, doprocesso de desenvolvimento e de padres.
Dessa forma, foi criado um documento contendo todos os requisitos do
sistema, identificados com a sigla da categoria (RF para funcionais e RNF para no-
funcionais) e um identificador numrico. Ainda, estes foram caracterizados de
acordo com a prioridade (funcionais) e complexidade (no-funcionais).
Portanto, com o CONOPS mostrando para o cliente e os usurios a proposta
do novo sistema e o documento de requisitos reforando esta viso para odesenvolvedor, resta agora definir a estrutura atravs do documento de projeto.
3.6Documento de Projeto
Existem vrias maneiras de se criar o documento de projeto de um sistema,
como pode ser percebido atravs do nmero de diagramas previstos pela UML na
seo 2.4. Tendo em vista que o objetivo do sistema a ser desenvolvido por este
trabalho de dar uma viso do andamento dos projetos para seus respectivos
coordenadores, no possuindo entrada e nem gerao de dados, foram escolhidos
dois diagramas para compor o documento de projeto: o diagrama de classes e o DER.
Os dois diagramas so bem semelhantes, porm, possuem finalidades
diferentes. O diagrama de classes possui todas as classes utilizadas no sistema e as
relaes entre elas, dando uma viso completa da estrutura e das operaes do
sistema. Algumas destas classes tambm estaro presentes no DER, mas
representadas por entidades. Este diagrama tem como nfase a estrutura lgica dobanco de dados, mostrando como os dados manipulados pelo sistema sero
armazenados.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
31
Figura 6: Ferramenta brModelo
A confeco dos diagramas foi realizada atravs de ferramentas especficas
para cada tipo. Para o DER, a ferramenta utilizada foi o brModelo (BRMODELO,
2014) em sua verso 2.0, desenvolvida por Carlos Henrique Cndido, que emprega a
notao de Entidade-Relacionamento criada por Peter Chen (CHEN, 2014), a mesma
citada na seo 2.4. Por outro lado, o Diagrama de Classes UML foi criado por meioda ferramenta chamada Dia, verso 0.97.2, criada por Alexander Larsson e mantida
por Hans Breuer (DIA, 2014).
Figura 7: Ferramenta Dia
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
32
Estes diagramas foram escolhidos porque so suficientes e executam bem o
papel de mostrar a fonte dos dados dos projetos e como eles sero representados no
sistema, o que engloba todas as funcionalidades do sistema.Aps definida a estrutura, iniciam-se enfim as atividades de implementao
do sistema.
3.7Tecnologias de Desenvolvimento
Com o intuito de transformar a estrutura idealizada no documento de projeto
em cdigo funcional, diversas tecnologias de desenvolvimento so empregadas, almde ferramentas para controle do cdigo e acesso ao banco de dados.
Primeiramente, ser utilizada a linguagem de programao C#, o ambiente de
desenvolvimento integrado Visual Studio 2013 e o sistema de gerenciamento de
banco de dados Microsoft SQL Server (SQL SERVER, 2014). Esta combinao foi
escolhida por j ser utilizada em outros projetos da equipe de desenvolvimento,
permitindo poupar tempo com aprendizado e aumentar a velocidade de produo de
cdigo, uma vez que os desenvolvedores j dominam as tecnologias.Para fazer a ponte entre o cdigo e o banco de dados, foi escolhida uma
biblioteca de mapeamento objeto-relacional chamada Nhibernate (NHIBERNATE,
2014), pois permite que o desenvolvedor tenha uma viso do banco de dados
utilizando classes e objetos do paradigma de programao orientada a objetos, alm
de simplificar o acesso e as operaes realizadas para a persistncia dos dados.
Ao trabalhar com a produo de cdigo, principalmente por mais de um
desenvolvedor, importante utilizar uma ferramenta para manter os arquivos
atualizados para cada um e tambm permitir o versionamento do sistema e a
possibilidade de recuperar cdigos antigos. Para tanto, foi empregado o uso da
tecnologia Subversion (SUBVERSION, 2014).
Por meio dos materiais, mtodos e tcnicas descritos at aqui, aliados aos
conceitos sobre engenharia de software mostrados no captulo 2, foi realizado um
trabalho de anlise e projeto de um novo sistema para a Fundao Uniselva, chamado
Portal do Coordenador. No prximo captulo so mostrados os resultados deste
trabalho e como este foi executado para obt-los.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
33
4.RESULTADOS
Conciliando os conceitos de engenharia de software descritos no captulo 2
com os materiais, mtodos e tcnicas citados no captulo 3, foi realizado um trabalho
de anlise e projeto de um sistema para o acompanhamento de projetos da Fundao
Uniselva por parte de seus respectivos coordenadores, aplicando as respectivas fases
do modelo de processo de cascata dupla descrito nas sees 2.1.2 e 3.1. Os
documentos gerados atravs deste trabalho, juntamente com uma definio do
sistema proposto, so detalhados a seguir.
4.1Documento CONOPS
O primeiro documento gerado foi o CONOPS. Nele, foi realizado um estudo
da situao do sistema Unisig atualmente em funcionamento, uma elaborao de
justificativas e motivos para a criao de um novo sistema, e mostrada a proposta do
Portal do Coordenador. Neste documento, o Portal do Coordenador definido como
um sistema para fornecer uma viso mais completa da situao dos projetos para seus
coordenadores do que o sistema Unisig fornece hoje.
Um dos grandes motivos para a criao deste novo sistema a necessidade de
acompanhar o andamento dos trabalhos atravs de um cronograma. Hoje, este
cronograma j fornecido pelo coordenador no plano de trabalho do projeto, porm,
no disponibilizado pelo Unisig para acompanhamento. Ainda sobre o cronograma,
outra funcionalidade do sistema a de alertar o coordenador sobre prazos das
atividades, com o intuito de prevenir o acmulo de recursos financeiros, que causa
transtornos tanto para a Uniselva quanto para o rgo financeiro e tambm para o
prprio coordenador.
No captulo 4 do CONOPS, so apresentadas todas as mudanas propostas
para o Portal do Coordenador em relao ao Unisig. So elas:
Adicionar Cronograma do Projeto.
Adicionar Notificaes e Avisos sobre o Cronograma.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
34
Adicionar Detalhamento de Receitas e Adiantamentos.
Reorganizar a Aparncia do Sistema.
Incluir rea do Diretor e das chefias de Projeto e Financeiro.
Integrar acesso com o Sistema de Boletos.
Utilizar senha nica de acesso.
Hospedar o sistema utilizando a infraestrutura da Uniselva.
Otimizar aparncia para acesso atravs de dispositivos portteis.
Dentre tais mudanas, algumas refletem os principais motivos para o
desenvolvimento de um novo sistema e so descritas a seguir.Uma funcionalidade exclusiva do Portal do Coordenador o cronograma do
projeto. Este ser disponibilizado por meio de uma tabela, da mesma forma que
apresentado no plano de trabalho, e tambm em um grfico Gantt. O cronograma
ser composto por metas, etapas/fases e itens, cada um com uma durao e previso
oramentria. Ainda, ser possvel detalhar um item selecionado, mostrando como o
oramento foi previsto para cada rubrica e o quanto j foi gasto at a data da
consulta. Para os projetos que possuem o formato de curso, como especializaes,mestrados, doutorados, entre outros, o sistema ir disponibilizar uma verso do
cronograma especfica para este caso, mostrando as atividades como disciplinas.
No novo sistema, o extrato do projeto incluir o detalhamento de receitas e
adiantamentos, o que no feito no sistema atual, como mostra a Figura 8.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
35
Figura 8: Extrato de Projeto no Unisig
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
36
As receitas sero divididas entre os investimentos do rgo financiador e as
faturas e bloquetos recebidos, enquanto os adiantamentos sero listados por completo
at a data da consulta, de acordo com a Figura 9.
Figura 9: Prottipo do novo Extrato do Projeto
Outra incluso a da rea do Diretor e dos Chefes de Financeiro e Projetos da
Uniselva. Nesta rea, estes usurios tero acesso a todos os projetos da mesma forma
que os coordenadores acessam. Alm disso, esta pgina tambm fornece estatsticas
dos totais de projetos em nmeros e grficos, possibilitando uma viso estratgica da
situao dos projetos da Uniselva.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
37
Uma das mudanas de usabilidade ser a seleo do projeto, que no Unisig
feita toda vez em que se seleciona uma funcionalidade, como extrato do projeto ou
saldo oramentrio. No Portal do Coordenador, esta seleo ser feita logo aps oacesso, para que todas as funcionalidades do sistema possam ser acessadas no escopo
do projeto selecionado.
A descrio e as imagens de todas as funcionalidades do Unisig e os
prottipos do Portal do Coordenador encontram-se no Apndice I.
4.2Documento de Requisitos
Por meio do documento CONOPS, foi realizado uma elicitao de requisitos
e gerado um documento de requisitos (ver Apndice II). J que o CONOPS j
executa a funo de passar para o cliente a ideia do sistema proposto, o documento
de requisitos foi elaborado neste caso para formalizar as necessidades identificadas
no CONOPS e servir como referncia para o desenvolvedor na hora de implementar
e testar o sistema.
No documento de requisitos, foi includa a descrio geral do sistemaproposto apresentada no CONOPS para definir o escopo do documento. A partir da,
foram listados os requisitos funcionais e no-funcionais, identificados com um sigla
(RF para os funcionais e RNF para os no-funcionais) seguida de um nmero
incremental e a classificao (P para prioridade e C para complexidade). Alguns
deles so:
[RF04] (P: Alta) O sistema deve, aps o login do diretor ou chefe,mostrar todos os projetos da Uniselva.
[RF05] (P: Alta) O sistema deve, junto com os projetos, mostrar os
totais de projetos por situao e tipo.
[RF08] (P: Mdia) O sistema deve permitir o chefe dar acesso ao
sistema para um coordenador.
[RF14] (P: Alta) O resumo financeiro deve conter os totais de receita,
despesas, faturas, adiantamentos, proviso e saldo para a data daconsulta.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
38
[RF19] (P: Alta) O sistema deve permitir a visualizao do
cronograma do projeto.
[RNF02] (C: Baixa) A aba do resumo financeiro na pgina principaldeve se expandir mediante interao com o mouse.
[RNF05] (C: Mdia) Os grficos do sistema devem ser mostrados
utilizando uma animao crescente.
Ao todo, foram elicitados 53 requisitos, sendo 42 funcionais e 11 no-
funcionais. Dos requisitos funcionais, 20 deles possuem prioridade Alta, enquanto 15
so de prioridade Mdia e 7 de Baixa. Para os no-funcionais, so 3 requisitos deAlta, 2 de Mdia e 6 de Baixa complexidade.
Com base nestes requisitos, a fase de desenvolvimento contar com todas as
informaes necessrias para permitir a implementao das funcionalidades,
incluindo a ordem em que estas devem ser implementadas. Alm disso, esta fase
tambm ter o apoio do documento de projeto, descrito a seguir.
4.3Documento de Projeto
Da mesma forma que o documento de requisitos, o documento de projeto tem
como pblico-alvo a equipe de desenvolvimento do Portal do Coordenador, porm,
trata de como os requisitos sero implementados no sistema por meio dos diagramas
de Entidade-Relacionamento e de Classes, confeccionados utilizando as ferramentas
brModelo e Dia, descritos na seo 3.6.
Partindo da finalidade de definir a estrutura do banco de dados do sistema, oDER mostrado na Figura 10 consiste numa viso que o Portal do Coordenador ter
das informaes do sistema interno da Fundao Uniselva, j que ambos iro
compartilhar tais dados. Ou seja, mesmo utilizando a mesma base de dados
fisicamente, o Portal do Coordenador ter acesso apenas s informaes contidas
neste diagrama.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
39
Figura 10: DER que representa o banco de dados do novo sistema
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
40
Uma vez definida a estrutura do banco de dados, o prximo passo foi o de
estruturar o software. Para isso, foi criado o Diagrama de Classes no modelo UML
para possibilitar ao desenvolvedor uma outra viso, agora de como as informaescontidas no DER sero representadas no sistema, como mostra a Figura 11. O
documento de projeto pode ser encontrado na ntegra no Apndice III.
Figura 11: Diagrama de Classes para representar o comportamento do novo sistema
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
41
Como citado anteriormente, o modelo de processo de cascata dupla foi
utilizado para guiar as atividades descritas neste relatrio. No entanto, mesmo
seguindo um modelo, algumas dificuldades e empecilhos foram encontrados durantea elaborao dos documentos. Tais transtornos so descritos no prximo captulo.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
42
5.DIFICULDADES ENCONTRADAS
Durante a execuo das tarefas descritas neste relatrio, foram encontradas
algumas dificuldades e obstculos que prejudicaram seu andamento. A principal
dificuldade foi a de coletar informaes sobre as necessidades dos coordenadores de
projetos, que geralmente um dos maiores problemas da engenharia de software. Os
motivos relatados variam da indisponibilidade para reunies at o desconhecimento
do prprio sistema Unisig atualmente em funcionamento.
Outra dificuldade foi identificada durante o estudo do sistema Unisig. Este
sistema no foi desenvolvido seguindo as prticas comuns de engenharia de
software, como foi mostrado neste trabalho. Desta forma, existem poucos
documentos que descrevem seu funcionamento, ainda de forma incompleta. Alm
disso, os prprios envolvidos em seu desenvolvimento e utilizao no souberam
descrever algumas funcionalidades presentes no sistema, j que estas caram em
desuso e no possuem influncia no objetivo do sistema.
Junto com o desenvolvimento do Portal do Coordenador, segue em paralelo a
criao do novo sistema interno da Fundao Uniselva. Como este ser a fonte das
informaes disponibilizadas pelo Portal do Coordenador, algumas decises,
principalmente na fase de projeto do sistema, foram afetadas no sentido de
dependerem de como o sistema interno ser implementado.
Um obstculo, tambm bastante comum no desenvolvimento de software, foi
o tempo. Como mostrado neste relatrio, o processo de coletar informaes, elicitar
requisitos, escrever documentos e projetar um novo sistema complexo e demanda
bastante tempo, especialmente quando afetado pelas dificuldades descritas at aqui.Mesmo tendo atingido os objetivos deste trabalho, o desejo era ter tambm a fase de
implementao concluda at o presente momento.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
43
6.CONCLUSES
Tento em vista o objetivo da Universidade Federal de Mato Grosso de
promover o ensino, a pesquisa e a extenso atravs de sua comunidade acadmica, a
Fundao Uniselva exerce um papel fundamental no apoio aos projetos e seus
coordenadores que buscam alcanar tal objetivo. Para isso, a Uniselva conta com
uma equipe de funcionrios dispostos a auxiliar o andamento dos projetos nas reas
relacionadas gerncia dos recursos financeiros, e tambm com o sistema Unisig,
encarregado de mostrar tal andamento de forma detalhada para os coordenadores.
Entretanto, este sistema no est suprindo todas as necessidades dos seus
usurios, principalmente por no permitir a visualizao de algumas informaes
financeiras e por no disponibilizar o cronograma do projeto. Alm disso, o sistema
precisa notificar os coordenadores quanto a prazos e ocorrncias relacionadas ao
cronograma, para evitar transtornos.
Sendo assim, este trabalho teve como objetivo aplicar os conceitos de
engenharia de software para projetar um novo sistema, chamado Portal do
Coordenador, que ter a misso de melhorar a viso que o coordenador tem sobre o
andamento de seus projetos, atendendo s necessidades citadas acima.
Por meio do documento CONOPS, foi realizado um estudo da situao
atual do sistema Unisig, elaborado um conjunto de motivos e justificativas para a
criao de um novo sistema, e criada uma descrio de como este dever funcionar,
sempre utilizando uma linguagem apropriada ao cliente. A partir deste documento,
foram escritos documentos de requisitos e de projeto que mostram o funcionamento
do sistema atravs da viso do desenvolvedor.Dados os resultados obtidos neste trabalho, os prximos passos sero a
implementao e validao do sistema. Na implementao, as tecnologias citadas na
seo 3.7 sero utilizadas para traduzir os requisitos identificados em funcionalidades
do sistema, enquanto a validao ir garantir que o produto gerado executa suas
funes corretamente e atendem s expectativas dos coordenadores. Aps estas
etapas, o Portal do Coordenador estar pronto para ser implantado e iniciar suas
operaes.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
44
7.REFERNCIAS BIBLIOGRFICAS
BALSAMIQ. Balsamiq Mockups. Disponvel por www em
http://balsamiq.com/products/mockups/ (acesso em 10 de fevereiro de 2014).
BRMODELO. Sobre a Ferramenta. Disponvel por www em
http://sis4.com/brModelo/ (acesso em 25 de fevereiro de 2014).
CHEN. Dr. Peter Chen. Disponvel por www em
http://www.csc.lsu.edu/~chen/ (acesso em 25 de fevereiro de 2014).
DIA. Development. Disponvel por www em
https://wiki.gnome.org/Apps/Dia/Development (acesso em 25 de fevereiro de 2014).
ELMASRI, Ramez. Fundamentals of database systems. 4. ed. Boston:
Pearson Edication, 2004.
IEEE. 1362-1998 - IEEE Guide for Information Technology - System
Definition - Concept of Operations (ConOps) Document. IEEE Computer Society,
1998.
NHIBERNATE.NHibernate Reference Documentation. Disponvel por www
em http://nhforge.org/doc/nh/en/index.html (acesso em 10 de fevereiro de 2014).
PRESSMAN, Roger S. Software engineering: a practitioners approach. 7.
ed. Nova York: McGraw-Hill, 2010.
PROJECT MANAGEMENT INSTITUTE. Sobre o PMI. Disponvel por
www em http://brasil.pmi.org/brazil/AboutUS.aspx (acesso em 22 de janeiro de
2014).
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. So Paulo: Pearson
Education do Brasil, 2007.SQL SERVER. About SQL Server. Disponvel por www em
http://www.microsoft.com/en-us/sqlserver/product-info.aspx (acesso em 10 de
fevereiro de 2014).
SUBVERSION. About Subversion. Disponvel por www em
http://subversion.apache.org/ (acesso em 10 de fevereiro de 2014).
UFMT. Institucional. Disponvel por www em
http://www.ufmt.br/ufmt/site/secao/index/Cuiaba/1 (acesso em 7 de fevereiro de2014).
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
45
UNISELVA. Estatuto Uniselva. Disponvel por www em
http://www.fundacaouniselva.org.br/sistema/downloads/estatuto_uniselva.pdf
(acesso em 7 de fevereiro de 2014).WAZLAWICK, Raul Sidnei. Engenharia de Software: conceitos e prticas.
Rio de Janeiro: Elsevier, 2013.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
46
Apndice I: Documento CONOPS
PORTAL DO COORDENADOR
Documento de Conceito Operacional(CONOPS IEEE 1362-98)
Verso 1.2
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
i
Histrico de Reviso
Data Verso Descrio Autor
02/01/2014 0.1 Criao do documento Lucas Pinto e Silva
13/01/2014 0.2 Adio das sugestes do Diretor Lucas Pinto e Silva
27/01/2014 1.0 Correo de informaes e formatao Lucas Pinto e Silva
06/02/2014 1.1 Adio da funcionalidade de envio de
relatrios na seo de no includas
Lucas Pinto e Silva
14/02/2014 1.2 Adio do Cronograma de Cursos Lucas Pinto e Silva
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
ii
CONCEITO OPERACIONAL (CONOPS)Aprovao do Documento
Senhor Diretor,
Recomendo a aprovao do documento de Conceito Operacional (CONOPS).
__________________________________Alberto Maral Figueiredo Tavares JuniorCoordenador do NPD da Uniselva
_____________________Data
Aprovado,
__________________________________Cristiano MacielDiretor Geral da Uniselva
_____________________Data
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
iii
SumrioHistrico de Reviso ....................................................................................................................... i
Aprovao do Documento ............................................................................................................ ii
Lista de Figuras ..............................................................................................................................iv
1. Escopo ....................................................................................................................................... 1
1.1. Identificao ....................................................................................................................... 1
1.2. Viso Geral do Documento ................................................................................................ 1
1.3. Viso Geral do Sistema ....................................................................................................... 1
2. Referncias ................................................................................................................................ 2
3. Sistema Atual (Unisig) ............................................................................................................... 2
3.1. Histrico, Objetivos e Escopo ............................................................................................. 2
3.2. Polticas e Restries Operacionais .................................................................................... 3
3.3. Descrio do Sistema Atual ................................................................................................ 3
3.4. Modos de Operao por Usurio ..................................................................................... 16
3.6. Ambiente de Apoio .......................................................................................................... 164. Justificativa e Natureza das Mudanas ................................................................................... 17
4.1. Justificativa das Mudanas ............................................................................................... 17
4.2. Descrio das Mudanas propostas ................................................................................. 17
4.3. Prioridades entre as Mudanas ........................................................................................ 19
4.4. Mudanas Vlidas mas no Includas ............................................................................... 20
5. Conceitos do Sistema Proposto (Portal do Coordenador) ...................................................... 20
5.1. Objetivos e Escopo ........................................................................................................... 21
5.2. Polticas Operacionais e Restries .................................................................................. 21
5.3. Descrio do Sistema Proposto ........................................................................................ 21
5.4. Modos de Operao por Usurio ..................................................................................... 32
5.6. Ambiente de Apoio .......................................................................................................... 32
6. Resumo dos Impactos ............................................................................................................. 33
7. Anlise do Sistema Proposto ................................................................................................... 33
7.1. Resumo das Melhorias ..................................................................................................... 34
7.2. Desvantagens e Limitaes .............................................................................................. 34
7.3. Alternativas e Escolhas consideradas ............................................................................... 34
http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/ -
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
iv
Lista de Figuras
Figura 1: Pgina inicial do Unisig ................................................................................................... 3
Figura 2: Pgina inicial do Extrato de Projetos .............................................................................. 4
Figura 3: Janela de seleo de meta e perodo ............................................................................. 5
Figura 4: Pgina de Extrato do Projeto.......................................................................................... 6
Figura 5: Pgina de Saldo Oramentrio ....................................................................................... 7
Figura 6: Resumo Financeiro do projeto ....................................................................................... 8
Figura 7: Pgina de Adiantamentos .............................................................................................. 9Figura 8: Relao de Faturas/Bloquetos ..................................................................................... 10
Figura 9: Informaes do Projeto ................................................................................................ 11
Figura 10: rea Administrativa .................................................................................................... 12
Figura 11: Cadastro de coordenador........................................................................................... 13
Figura 12: Liberao de acesso a projetos .................................................................................. 14
Figura 13: Envio de pacote de atualizao .................................................................................. 15
Figura 14: Seleo de Projeto ...................................................................................................... 22
Figura 15: Pgina do Diretor/Chefe ............................................................................................ 23
Figura 16: Pgina Principal do sistema ........................................................................................ 24
Figura 17: Informaes do Projeto .............................................................................................. 25Figura 18: Cronograma do Projeto .............................................................................................. 26
Figura 19: Detalhes do Cronograma ........................................................................................... 27
Figura 20: Cronograma de Curso ................................................................................................. 28
Figura 21: Extrato do Projeto ...................................................................................................... 29
Figura 22: Saldo Oramentrio ................................................................................................... 30
Figura 23: Faturas/Bloquetos ...................................................................................................... 31
http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/ -
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
1
1. Escopo
O documento de Conceito Operacional (CONOPS) do Portal do Coordenador descreve
as caractersticas desejadas do sistema atravs da viso do usurio. As sees abaixo
identificam o sistema Portal do Coordenador e fornecem uma viso geral do documento e do
sistema proposto.
1.1. Identificao
O sistema Portal do Coordenador, cuja anlise e desenvolvimento se do no ano de
2014, ser baseado no sistema Unisig atualmente em funcionamento, tomando seu lugar como
um sistema para a visualizao de informaes e acompanhamento dos projetos da Uniselva
por parte dos coordenadores.
1.2. Viso Geral do Documento
Este documento tem como objetivo mostrar as caractersticas quantitativas e qualitativas
do sistema em alto nvel para usurios, clientes, desenvolvedores e outras partes interessadas.
Adaptado do documento de padres IEEE 1362-98, as ideias expressadas neste CONOPS para
o desenvolvimento de um portal para o coordenador so resultado de uma anlise das
dificuldades e necessidades relatadas pelos prprios coordenadores e pelos funcionrios da
Uniselva, que no so supridas pelo sistema atual (Unisig).
Seo 1 descreve o intuito deste CONOPS e ao sistema que ele se aplica Seo 2 lista as referncias utilizadas na construo deste documento Seo 3 descreve a situao atual do sistema em funcionamento (Unisig) Seo 4 discute motivos e justificativas para a criao de um novo sistema Seo 5 fornece informaes sobre o novo sistema proposto (Portal do
Coordenador) Seo 6 lista os impactos operacionais, organizacionais e os que podem
ocorrer durante o desenvolvimento do sistema proposto Seo 7 faz uma anlise dos benefcios, limitaes, vantagens, desvantagens
e alternativas do sistema proposto1.3. Viso Geral do Sistema
O Portal do Coordenador uma proposta de sistema para fornecer uma viso mais
completa da situao dos projetos para seus coordenadores do que o sistema atual (Unisig)
fornece. Um grande motivo possibilitar o coordenador acompanhar o andamento do projeto,principalmente atravs de um cronograma, que criado a partir do plano de trabalho do projeto.
-
5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....
http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s
Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220www.fundacaouniselva.org.br
2
Alm do cronograma, outra grande finalidade do sistema informar e alertar o
coordenador sobre prazos no sentido de prevenir o acmulo de recursos, que causa transtornos
tanto para a Uniselva quanto para o coordenador e o rgo financiador do projeto. Com esta
funcionalidade, o coordenador poder gerenciar os recursos do projeto de uma maneira mais
eficiente e seguir o cronograma como planejado.
Este novo sistema ir trabalhar em conjunto com um outro sistema em desenvolvimento
que ir substituir o sistema Gerencial utilizado internamente na Uniselva, compartilhando o
mesmo banco de dados e seguindo as mesmas normas e regimentos das informaes utilizadas.
2. Referncias
Os padres e guias utilizados na preparao deste documento esto listados abaixo.
IEEE Computer Society. IEEE Std 1362-1998, IEEE Guide for Information Technology-
System Definition-Concept of Operations (ConOps) Document, 19 de maro de 1998
American Systems Corporation. Eletronic Records Archives Concept of Operations
(CONOPS v4.0), 27 de julho de 2004
Os seguintes documentos da Uniselva foram consultados para a elaborao deste documento.
Coordenao Financeira, Fundao Uniselva. Projeto Espao do Coordenador
Ilza Gervazoni, Fundao Uniselva. Sistema de Gesto, 23 de fevereiro de 2009
3. Sistema Atual (Unisig)
Esta seo trata sobre o Sistema Integrado de Gesto (Unisig), atualmente em
funcionamento. As subsees seguintes descrevem o histrico, objetivos e escopo do sistema
atual, suas polticas operacionais, restries, funcionamento, modos de operao, classes de
usurio e ambiente de apoio.
3.1. Histrico, Objetivos e Escopo
O sistema Unisig surgiu da necessidade da Fundao Uniselva de disponibilizar de forma
rpida e de fcil entendimento as informaes financeiras e detalhes da execuo dos projetos
aos coordenadores. Antes de sua implantao, os coordenadores solicitavam informaes
financeiras e oramentrias e as recebiam de forma impressa ou via e-mail. Isso gerava
transtornos tanto para a Uniselva quanto para o coordenador, uma vez que funcionrios eram
ocupados de atender s solicitaes dos coordenadores, j que estes no tinham acesso fcil e
rpido s informaes de seus projetos.
Tendo em vista estes problemas, o Unisig foi desenvolvido com o objetivo de possibilitar
o acompanhamento da situao financeira dos projetos por parte de seus coordenadores, tendo
-
5/21/2018 Relatorio Final de Est gio Supervision
top related