Relatorio Final de Estágio Supervisionado - Lucas Pinto e Silva PDF

UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAO DE ENSINO DE GRADUAO EM

CINCIA DA COMPUTAO

RELATRIO DE ESTGIO SUPERVISIONADO
ANLISE E PROJETO DE UM SISTEMA DE
ACOMPANHAMENTO PARA OS COORDENADORES DE
PROJETOS DA FUNDAO UNISELVA

LUCAS PINTO E SILVA

CUIAB MT
2014

CINCIA DA COMPUTAO

RELTORIO DE ESTGIO SUPERVISIONADO
ANLISE E PROJETO DE UM SISTEMA DE
ACOMPANHAMENTO 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 de
Bacharel em Cincia da Computao.

CUIAB MT
2014

CINCIA DA COMPUTAO

LUCAS PINTO E SILVA

Relatrio de Estgio Supervisionado apresentado Coordenao do Curso de
Cincia da Computao como uma das exigncias para obteno do ttulo de
Bacharel 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
(Orientador)

Alberto Maral Figueiredo Tavares Junior
Coordenador do Ncleo de Processamento de Dados da Uniselva
(Supervisor)

Prof. Dr. Cristiano Maciel
(Diretor da Fundao Uniselva)

DEDICATRIA

minha av, Zil da Silva Pinto, que
deve estar muito orgulhosa de mim por
mais esta conquista, onde quer que ela
esteja.

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.

SUMRIO

LISTA DE FIGURAS .......................................................................................................................... 7
LISTA DE SIGLAS E ABREVIATURAS ......................................................................................... 8
RESUMO .............................................................................................................................................. 9
1. INTRODUO ........................................................................................................................ 10
1.1 JUSTIFICATIVA ........................................................................................................................ 11
1.2 OBJETIVO GERAL .................................................................................................................... 11
1.3 OBJETIVOS ESPECFICOS ......................................................................................................... 11
1.4 ORGANIZAO DO TRABALHO ............................................................................................... 12
2. REVISO DE LITERATURA ................................................................................................ 13
2.1 ENGENHARIA DE SOFTWARE ................................................................................................... 13
2.1.1 Processos de software .................................................................................................. 13
2.1.2 Modelos de processo de software ................................................................................. 16
2.1.3 Gerncia de projeto ...................................................................................................... 17
2.2 CONCEITO OPERACIONAL ....................................................................................................... 19
2.3 ELICITAO DE REQUISITOS ................................................................................................... 20
2.4 PROJETO DE SOFTWARE .......................................................................................................... 21
2.5 PROTOTIPAO ....................................................................................................................... 23
3. MATERIAIS, MTODOS E TCNICAS UTILIZADOS .................................................... 25
3.1 MODELO CASCATA DUPLA ..................................................................................................... 25
3.2 SISTEMAS RELACIONADOS ..................................................................................................... 26
3.3 CONOPS ................................................................................................................................ 28
3.4 PROTTIPOS ............................................................................................................................ 28
3.5 DOCUMENTO DE REQUISITOS.................................................................................................. 29
3.6 DOCUMENTO DE PROJETO....................................................................................................... 30
3.7 TECNOLOGIAS DE DESENVOLVIMENTO ................................................................................... 32
4. RESULTADOS ......................................................................................................................... 33
4.1 DOCUMENTO CONOPS .......................................................................................................... 33
4.2 DOCUMENTO DE REQUISITOS.................................................................................................. 37
4.3 DOCUMENTO DE PROJETO....................................................................................................... 38
5. DIFICULDADES ENCONTRADAS ...................................................................................... 42
6. CONCLUSES ......................................................................................................................... 43
7. REFERNCIAS BIBLIOGRFICAS .................................................................................... 44
APNDICE I: DOCUMENTO CONOPS ........................................................................................ 46
APNDICE II: DOCUMENTO DE REQUISITOS........................................................................ 85
APNDICE III: DOCUMENTO DE PROJETO ............................................................................ 93

7
LISTA DE FIGURAS

FIGURA 1: DIAGRAMA DE CLASSES (PRESSMAN, 2010, P. 843) ......................................................... 22
FIGURA 2: DIAGRAMA ENTIDADE-RELACIONAMENTO .......................................................................... 23
FIGURA 3: MODELO DE CASCATA DUPLO NA PRTICA (WAZLAWICK, 2013, P. 30) .......................... 26
FIGURA 4: PGINA INICIAL DO UNISIG .................................................................................................. 27
FIGURA 5: FERRAMENTA DE PROTOTIPAO BALSAMIQ ...................................................................... 29
FIGURA 6: FERRAMENTA BRMODELO ................................................................................................... 31
FIGURA 7: FERRAMENTA DIA ................................................................................................................ 31
FIGURA 8: EXTRATO DE PROJETO NO UNISIG ........................................................................................ 35
FIGURA 9: PROTTIPO DO NOVO EXTRATO DO PROJETO ....................................................................... 36
FIGURA 10: DER QUE REPRESENTA O BANCO DE DADOS DO NOVO SISTEMA ......................................... 39
FIGURA 11: DIAGRAMA DE CLASSES PARA REPRESENTAR O COMPORTAMENTO DO NOVO SISTEMA ...... 40

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-Relacionamento
MER Modelo Entidade-Relacionamento
UML Unified Modeling Language
PMI Project Management Institute
PMBOK Project Management Body of Knowledge
CONOPS Documento de Conceito Operacional

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.

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 respectivos
coordenadores, 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 forma
satisfatria sua funo, que dar uma viso completa da situao do projeto. H

11
ento, uma necessidade de um sistema com mais funcionalidades para que as
demandas dos usurios possam ser atendidas.

1.1 Justificativa

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.2 Objetivo 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.3 Objetivos 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.

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.4 Organizao 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.

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.1 Engenharia 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 da
produo 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).

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 fases
fundamentais 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:

15
1. Especificao
i. Estudo de viabilidade: uma estimativa sobre se as necessidades
dos usurios sero atendidas usando as tecnologias de software
e 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.

16
vi. Projeto de algoritmos: os algoritmos usados para fornecer
servios so projetados em detalhes e especificados.
3. Validao
i. 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 com
dados 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 definidos
modelos 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 equipe
de desenvolvimento, podendo at comprometer a entrega do sistema.

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 variaes
permitem 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 um
processo 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 ser
referenciadas fontes importantes como o Project Management Body of Knowledge

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 dos
tempos 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.

19

2.2 Conceito 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 este
problema.
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 componentes
podem 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

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 partir
para a elicitao de requisitos da forma tradicional, agora tendo mais um documento
para se basear durante a coleta dos requisitos.

2.3 Elicitao 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

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.4 Projeto 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 projeto
permite 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 um
sistema 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 do
software.

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. O
relacionamento 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

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.5 Prototipao

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

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 no
desenvolvimento 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.

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.1 Modelo 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 uma
flexibilidade 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 interaes
entre as fases deste modelo acabam acontecendo na prtica, como mostra a Figura 3.

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.2 Sistemas 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

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.

28
3.3 CONOPS

Como citado na seo 2.2, o documento CONOPS faz parte da fase inicial do
desenvolvimento 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.4 Prottipos

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 para
criar tais prottipos o Balsamiq (BALSAMIQ, 2014).

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 elementos
grficos 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.5 Documento 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 e
no-funcionais. Segundo Sommerville (2007, p. 119), requisitos funcionais so

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, do
processo 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 o
desenvolvedor, resta agora definir a estrutura atravs do documento de projeto.

3.6 Documento 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 do
banco de dados, mostrando como os dados manipulados pelo sistema sero
armazenados.

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 meio
da ferramenta chamada Dia, verso 0.97.2, criada por Alexander Larsson e mantida
por Hans Breuer (DIA, 2014).

Figura 7: Ferramenta Dia

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.7 Tecnologias de Desenvolvimento

Com o intuito de transformar a estrutura idealizada no documento de projeto
em cdigo funcional, diversas tecnologias de desenvolvimento so empregadas, alm
de 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.

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.1 Documento 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.

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.

35

Figura 8: Extrato de Projeto no Unisig

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.

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 o
acesso, 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.2 Documento 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 sistema
proposto 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 da
consulta.

38
[RF19] (P: Alta) O sistema deve permitir a visualizao do
cronograma do projeto.
[RNF02] (C: Baixa) A aba do resumo financeiro na pgina principal
deve 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 de
Alta, 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.3 Documento 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, o
DER 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.

39

Figura 10: DER que representa o banco de dados do novo sistema

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 informaes
contidas 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

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 durante
a elaborao dos documentos. Tais transtornos so descritos no prximo captulo.

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.

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.

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 de
2014).

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.

46
Apndice I: Documento CONOPS

PORTAL DO COORDENADOR

Documento de Conceito Operacional
(CONOPS IEEE 1362-98)

Verso 1.2

Avenida Fernando Corra da Costa 2367
Campus da UFMT - Bloco da Grfica
CEP: 78.060-900- Cuiab/MT
CNPJ: 04.845.150/0001-57
Telefone: 0xx65 3661-3900
Fax: 0xx65 3628-1220
www.fundacaouniselva.org.br

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

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

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

ii

CONCEITO OPERACIONAL (CONOPS)
Aprovao do Documento

Senhor Diretor,

Recomendo a aprovao do documento de Conceito Operacional (CONOPS).

__________________________________
Alberto Maral Figueiredo Tavares Junior
Coordenador do NPD da Uniselva
_____________________
Data

Aprovado,

__________________________________
Cristiano Maciel
Diretor Geral da Uniselva
_____________________
Data

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

iii

Sumrio

Histrico 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 .......................................................................................................... 16
4. 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

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

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 .............................................................................................. 9
Figura 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 .............................................................................................. 25
Figura 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

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

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 proposto

1.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.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

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

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

3

acesso informaes como: vigncia, despesas pagas, pendncias, saldos, extratos financeiros,
relao de boletos pagos, entre outras.

3.2. Polticas e Restries Operacionais

Para realizar suas funcionalidades, o sistema Unisig precisa ser alimentado com as
informaes do sistema Gerencial, sendo este processo realizado manualmente. Portanto, uma
restrio do Unisig que suas informaes no so disponibilizadas em tempo real, dependendo
da operao descrita acima.
Por ser um sistema disponvel na Web, este deve ser acessado atravs de um
computador conectado internet e com um navegador como Internet Explorer, Google Chrome,
Mozilla Firefox, entre outros.

3.3. Descrio do Sistema Atual

O sistema Unisig possui cinco reas principais: Extrato do Projeto, Saldo Oramentrio,
Resumo Financeiro, Faturas/Bloquetos e Sistema de Boleto. Este ltimo um sistema
independente e est incluso no Unisig apenas para facilitar o acesso para o coordenador.
Alm deles, o sistema tambm mostra um aviso de adiantamentos pendentes. Ao realizar
o acesso, o coordenador direcionado para a pgina principal abaixo.

Figura 1: Pgina inicial do Unisig

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

4

Extrato do Projeto
A rea de Extrato do Projeto possibilita a visualizao das despesas do projeto dentro
de um determinado perodo definido pelo coordenador. Ao abrir esta funcionalidade, o
coordenador tem acesso todos os projetos liberados para ele, sendo possvel ordenar pelo
cdigo do projeto. Nesta tabela tambm encontram-se o cone de Ativo (se o projeto est ativo
ou inativo), o cone de Extrato para abrir o extrato do projeto e o cone de Informaes.

Figura 2: Pgina inicial do Extrato de Projetos

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

5

Antes de visualizar o extrato do projeto, o usurio tem acesso uma janela que possibilita
selecionar a meta e o perodo desejado.

Figura 3: Janela de seleo de meta e perodo
Na pgina de Extrato do Projeto, o extrato dividido da seguinte maneira:

1. Informaes do Projeto
2. Relao de despesas pagas no perodo
3. Custo operacional UGR (Faculdade/Instituto)
4. Custos operacionais no apropriados no perodo
5. Adiantamentos pendentes na data atual
6. Provises pendentes no perodo
7. Saldo disponvel

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

6

Figura 4: Pgina de Extrato do Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

7

Saldo Oramentrio
O Saldo Oramentrio mostra a previso oramentria, as despesas e o saldo para cada
rubrica cadastrada, de acordo com o plano de trabalho do projeto, at a data solicitada. Sua
pgina inicial quase idntica pgina do Extrato de Projeto.

Figura 5: Pgina de Saldo Oramentrio

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

8

Resumo Financeiro
Atravs do Resumo Financeiro, o coordenador tem a viso geral da situao financeira
do projeto. Para cada meta listada a receita, despesa, fatura, adiantamento, proviso e saldo

Figura 6: Resumo Financeiro do projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

9

Adiantamentos
Caso exista algum adiantamento pendente, uma mensagem de alerta aparece na pgina
principal do Unisig. Ao clicar nela, o coordenador levado a outra pgina onde possvel
consultar estas pendncias, descritas com o cdigo do projeto, o nome do beneficirio, o nmero
de dias pendentes, a data da sada e o valor do adiantamento.

Figura 7: Pgina de Adiantamentos

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

10

Faturas/Bloquetos
A seo de Faturas/Bloquetos possibilita o coordenador listar as faturas e bloquetos de
um projeto, utilizando filtros como perodo, situao, tipo (fatura ou bloqueto), alm de ordenar
os resultados por clientes ou situao e export-los para arquivos Excel ou Word.

Figura 8: Relao de Faturas/Bloquetos

Informaes do Projeto
Dentro das sees de Extrato do Projeto, Saldo Oramentrio e Resumo Financeiro,
existe a opo de visualizar as informaes de um projeto. Nesta pgina, so mostradas vrias
informaes como o objetivo do projeto, justificativa, data de vigncia, resumo financeiro,
informaes bancrias, unidade executora, caractersticas do projeto, coordenador, telefone,
fora trabalho e adiantamentos pendentes.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

11

Figura 9: Informaes do Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

12

rea Administrativa
O Unisig conta com uma rea administrativa onde possvel realizar operaes
necessrias para funcionamento do sistema, como cadastrar usurios e coordenadores, e
tambm atualizar as informaes provenientes do sistema Gerencial. Seu acesso, no entanto,
feito atravs de uma pgina diferente do acesso do coordenador.
Alm destas operaes, existem tambm links para outras funes, porm no esto
diretamente ligadas administrao do Unisig e no so mais utilizadas.

Figura 10: rea Administrativa

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

13

Para um coordenador ter acesso ao Unisig, um administrador deve acessar a
funcionalidade de Cadastro de Coordenador e inserir as informaes necessrias, como mostra
a imagem abaixo. De modo semelhante ao cadastro de coordenador, existe tambm o cadastro
de usurio, para dar acesso a esta rea administrativa.

Figura 11: Cadastro de coordenador

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

14

Uma vez cadastrado o coordenador, possvel liberar o acesso para os projetos que
este coordena atravs do cone Liberar na tabela de coordenadores. Nesta pgina so listados
todos os projetos relacionados quele coordenador, com a caixa de seleo para liberar o
projeto. Os projetos liberados so ento copiados para a tabela abaixo, dando tambm a opo
de bloquear o acesso.

Figura 12: Liberao de acesso a projetos

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

15

Como mencionado anteriormente, o Unisig tem como fonte de informaes o sistema
Gerencial utilizado internamente na Uniselva. Porm, o compartilhamento de dados entre estes
dois sistemas no integrado, sendo necessrio o envio dirio de um pacote de atualizao para
o Unisig.

Figura 13: Envio de pacote de atualizao

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

16

3.4. Modos de Operao por Usurio

Por ser um sistema focado em prover informaes para os coordenadores, o Unisig
possui apenas duas classes de usurios: os prprios coordenadores e os administradores do
sistema.

Coordenadores
Os coordenadores so professores da UFMT que possuem projetos vinculados
Uniselva e so os principais usurios do Unisig, tendo acesso todas as cinco reas principais
do sistema descritos anteriormente. Para isso, eles devem ser cadastrados previamente por um
administrador e assinar um Termo de Compromisso, onde se comprometem a utilizar a senha
para a finalidade exclusiva visada pelo sistema e responsabiliza-se pela utilizao incorreta e/ou
imprecisa da mesma.
Cada coordenador possui uma lista de projetos liberados, que tambm so cadastrados
pelos administradores. Os coordenadores no possuem acesso s informaes de projetos que
no estejam liberados para seu usurio.

Administradores
Os administradores so funcionrios da Uniselva encarregados de manter o
funcionamento do Unisig. Estes possuem as permisses de criar novos administradores, criar
usurios para coordenadores, associar projetos aos usurios, bloquear acesso e realizar a
atualizao das informaes do sistema.

3.6. Ambiente de Apoio

O Unisig conta como fonte de dados o sistema Gerencial utilizado internamente na
Uniselva. Este operado pelos funcionrios para fazer o controle de todos os aspectos dos
projetos, e as informaes inseridas refletem nos dados mostrados pelo Unisig. Para isso, um
programa de coleta e compresso de dados acessa o repositrio do sistema Gerencial e prepara
o pacote para ser enviado. Este procedimento feito pelo mesmo responsvel de atualizar as
informaes atravs da rea administrativa.
Para disponibilizar acesso ininterrupto ao sistema, o Unisig hospedado em uma
empresa terceirizada, que tem como responsabilidade cuidar dos aspectos tcnicos para garantir
o funcionamento do servio.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

17

4. Justificativa e Natureza das Mudanas

Esta seo trata dos motivos e das justificativas para a criao de um novo sistema.
Tambm descreve as mudanas desejadas em relao ao sistema atual, alm de definir as
prioridades e as mudanas consideradas mas no includas na proposta do novo sistema.

4.1. Justificativa das Mudanas

Um dos grandes motivos para a criao do Portal do Coordenador a necessidade dos
coordenadores de visualizar e acompanhar o cronograma do projeto. Hoje, o sistema Unisig
dispe apenas informaes da situao financeira do projeto, sem fazer uma comparao com
o plano de aplicao, que definido durante a criao do projeto. Isso impossibilita o
coordenador de saber se o andamento dos trabalhos est de acordo com o planejado. Um
exemplo deste problema quando o prazo de vencimento do projeto est prximo e o
coordenador ainda no gastou todos os recursos financeiros que foram previstos at o momento,
causando transtornos para a Uniselva, para o rgo financeiro e at para o prprio coordenador.
Outro motivo a falta de detalhamento em algumas reas do Unisig. Atravs do Resumo
Financeiro possvel ter o total da receita, da despesa, da fatura, do adiantamento e da proviso,
porm apenas as despesas e provises so agrupadas em rubricas no Saldo Oramentrio e
somente as despesas sendo detalhadas por item no Extrato do Projeto.
Alm disso, hoje o Unisig no conta com uma rea para a diretoria e as chefia de projeto
e financeiro da Uniselva, o que impossibilita estas partes de terem uma viso estratgica da
situao dos projetos.
4.2. Descrio das Mudanas propostas

A partir dos motivos e justificativas mencionados na seo anterior, foram elaboradas
mudanas desejveis para um novo sistema em relao ao sistema atual. Os itens abaixo tratam
de novas funcionalidades, mudanas na aparncia e no funcionamento, baseados na situao
do Unisig descrita na seo 3. Sistema Atual (Unisig)

Adicionar Cronograma do Projeto
Esta uma das principais mudanas e uma grande motivao para a criao do Portal
do Coordenador. No Plano de Trabalho de um projeto recm-criado, j existe uma seo que
trata do cronograma, contendo metas, etapas e os itens que sero executados no decorrer dos
trabalhos, junto com os gastos previstos para cada perodo. Hoje estas informaes no so
inseridas no sistema Gerencial (usado internamente na Uniselva), porm passaro a ser
includos no novo sistema interno.
Sendo assim, o Portal do Coordenador ir trabalhar em conjunto com este novo sistema
Gerencial, disponibilizando as informaes de cronograma agora presentes para o coordenador.
Alm disso, este novo mdulo ir fazer uma ligao entre o oramento previsto e os gastos j
registrados para cada perodo do cronograma.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

18

Adicionar Notificaes e Avisos sobre o Cronograma
Com o intuito de notificar o coordenador sobre prazos e ocorrncias relacionadas ao
cronograma do projeto, o sistema ir apresentar notificaes e avisos na pgina principal, que
podero ser desativados pelo usurio.

Adicionar Detalhamento de Receitas e Adiantamentos
Para melhorar a compreenso da situao financeira do projeto por parte do
coordenador, o novo sistema ir possibilitar o detalhamento das receitas (junto com as faturas)
e adiantamentos da mesma forma que feito com as despesas no Extrato do Projeto no Unisig.

Incluir rea do Diretor e das chefias de Projeto e Financeiro
O novo sistema ir contar com uma rea especfica para a diretoria e as chefias de
projeto e financeiro, para que estes tenham uma viso estratgica da situao dos projetos da
Uniselva. Esta rea contar com uma lista de todos os projetos cadastrados, possibilitando a
visualizao, de uma forma resumida e grfica, da situao financeira e do andamento do
cronograma.

Reorganizar a Aparncia do Sistema
O Portal do Coordenador ir contar com uma interface remodelada para melhorar a
experincia do usurio. A primeira ao do coordenador ao acessar o sistema ser escolher o
projeto ao qual deseja ter acesso s informaes. Depois, uma pgina ir trazer, em cones
grandes e representativos, todas as funcionalidades do sistema em relao quele projeto.

Integrar acesso com o Sistema de Boletos
O Unisig inclui um cone para acesso ao Sistema de Boletos, porm o coordenador
necessita fornecer novamente suas credenciais ou utilizar uma diferente para acessar este
sistema. Com o Portal do Coordenador, este acesso ser integrado de modo que de dentro dele
o coordenador poder ter acesso ao Sistema de Boletos apenas clicando em seu respectivo
cone, sem a necessidade de inserir outra senha.

Utilizar senha nica de acesso
Alm da integrao com o Sistema de Boleto citada acima, o Portal do Coordenador ir
utilizar a mesma base de dados que outros sistemas da Uniselva, inclusive os de uso interno,
para que todos os usurios possam utilizar a mesma senha ao acessar um sistema que use esta
base integrada.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

19

Otimizar aparncia para acesso atravs de dispositivos portteis
Para acompanhar a crescente popularidade dos smartphones, tablets e outros
dispositivos portteis com telas reduzidas, a aparncia do sistema ir ser modificada quando
acessado desta maneira, aumentando a visibilidade dos textos e reduzindo a largura da pgina.
cones devero ser agrupados e expandidos ao interagir e ambos o cabealho e o rodap
devero ser substitudo por suas respectivas verses menores.

Hospedar o sistema utilizando a infraestrutura da Uniselva
Hoje, a responsabilidade sobre os aspectos tcnicos da hospedagem do Unisig so de
uma empresa terceirizada contratada. Mesmo levando em considerao as vantagens desta
alternativa, a habilidade de resolver problemas quanto disponibilizao do servio fica limitada,
pois cria-se uma dependncia do trabalho realizado por esta empresa.
Utilizando a infraestrutura da prpria Uniselva, a performance do novo sistema poderia
ser controlada com mais preciso, alm de possibilitar uma ao mais imediata em casos de
problemas, j que o prprio setor competente estaria apto a resolv-los.

4.3. Prioridades entre as Mudanas

As mudanas descritas na seo anterior possuem prioridades de acordo com sua
urgncia e necessidade. Mudanas Essenciais so definidas como obrigatrias para a
finalizao do sistema e devem ser desenvolvidas. J mudanas Desejveis so consideradas
importantes, porm podem no serem includas no desenvolvimento para no comprometer o
cronograma, caso acordado com o cliente. Por ltimo, as mudanas Opcionais so aquelas que
podem ser includas no sistema caso todas as outras j tenham sido desenvolvidas e o
cronograma do projeto permita.
Sendo assim, a tabela abaixo categoriza as mudanas citadas na seo anterior de
acordo com suas prioridades:

Mudana Prioridade
Adicionar Cronograma do Projeto Essencial
Adicionar Notificaes e Avisos sobre o Cronograma Essencial
Adicionar Detalhamento de Receitas e Adiantamentos Essencial
Reorganizar a Aparncia do Sistema Essencial
Incluir rea do Diretor e das chefias de Projeto e Financeiro Desejvel
Integrar acesso com o Sistema de Boletos Opcional
Utilizar senha nica de acesso Opcional
Hospedar o sistema utilizando a infraestrutura da Uniselva Opcional
Otimizar aparncia para acesso atravs de dispositivos portteis Opcional

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

20

4.4. Mudanas Vlidas mas no Includas

As mudanas listadas abaixo foram discutidas com os envolvidos consideradas vlidas,
porm no foram includas na elaborao deste documento.

Cadastro de Projetos
Foi cogitada a ideia de permitir o cadastro de um novo projeto pelo prprio coordenador
pelo sistema para que suas informaes j estivessem na base de dados da Uniselva quando a
documentao chegasse no setor de projetos, alm de ajudar o coordenador no preenchimento
dos dados do projeto.
Porm, esta ideia no foi inclusa na proposta do novo sistema por ter um grande impacto
no processo de criao de um projeto, fazendo com que este necessitasse de uma remodelagem
e tanto os coordenadores quanto os funcionrios do departamento teriam que se adequar a esta
nova alternativa, o que traria mais transtornos do que benefcios.

Cadastro de Cronograma
Alm do cadastro dos projetos, outra proposta de permitir o cadastro do cronograma
do projeto pelo prprio coordenador em casos que este no esteja includo no plano de trabalho.
No entanto, este processo iria gerar um trabalho para o coordenador que alguns poderiam julgar
desnecessrio, enquanto outros poderiam se sentir pressionados a definir um cronograma para
a execuo de seus trabalhos.

Permitir o upload dos Relatrios Parciais e Final do Projeto
Durante a execuo e ao final de um projeto, o coordenador necessita enviar Fundao
Uniselva relatrios sobre o andamento dos trabalhos. Neste sentido, o Portal do Coordenador
poderia disponibilizar uma rea para o coordenador enviar tais relatrios, e assim as chefias de
Projeto e Financeiro teriam acesso a eles atravs da visualizao dos projetos no sistema.
Entretanto, os relatrios requerem a assinatura do coordenador e uma verso digital no
vivel no momento, j que os rgos financiadores ainda exigem o modelo tradicional. Portanto,
enquanto no existir um relatrio que no necessite de assinatura ou que a assinatura digital
seja aceita, esta funcionalidade no poder ser utilizada.

5. Conceitos do Sistema Proposto (Portal do Coordenador)

Esta seo trata sobre a proposta do novo sistema Portal do Coordenador, elaborado
a partir do estudo do sistema atual (Unisig) e das necessidades descritas na seo anterior.
Assim como na descrio do sistema atual, as subsees seguintes descrevem o histrico,
objetivos e escopo deste novo sistema, suas polticas operacionais, restries, funcionamento,
modos de operao, classes de usurio e ambiente de apoio.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

21

5.1. Objetivos e Escopo

O Portal do Coordenador tem como objetivo possibilitar um melhor acompanhamento de
projetos por parte do coordenador, quando comparado com o sistema atual. O novo sistema ir
fornecer um detalhamento no s das despesas e das provises, mas tambm das receitas e
adiantamentos, alm de alertar o coordenador sobre prazos e ocorrncias relacionados ao
cronograma do projeto.
Sendo assim, a rea de abrangncia das funcionalidades do sistema estar focada na
comunicao das informaes do projeto para o coordenador, servindo como uma ponte entre
este e os dados mantidos pelo sistema interno da Uniselva.

5.2. Polticas Operacionais e Restries

O Portal do Coordenador no possui uma resoluo ou documentao que rege seu
funcionamento, porm, por ser um servio fornecido pela Fundao, este deve seguir seu
estatuto.
Em relao s tecnologias utilizadas, sendo um servio disponibilizado na Web da
mesma forma que o Unisig, o Portal do Coordenador necessita de um dispositivo conectado
internet e um navegador Web para ser acessado. Ainda, caso a mudana de hospedagem citada
no captulo anterior no puder ser executada, o sistema ainda ter a restrio de atualizao das
informaes, visto que ainda seria necessrio o envio dos dados do sistema interno para ele.

5.3. Descrio do Sistema Proposto

Esta seo ir mostrar a proposta das principais funcionalidades do novo sistema. Para
isso, foram criados prottipos das pginas do sistema para simular seu funcionamento. No
entanto, estes so apenas ilustraes que expressam as ideias de como as mudanas citadas
no captulo anterior poderiam ser includas, no restringindo e limitando o produto final.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

22

Seleo de Projeto
A primeira pgina que o coordenador ter acesso a de seleo de projeto. Ao contrrio
do Unisig, esta etapa acontece antes de acessar as funcionalidades do sistema, para que no
exista a necessidade de escolher o projeto a cada acesso.

Figura 14: Seleo de Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

23

Viso Estratgica
Quando o acesso realizado por um diretor ou chefe de do setor de projeto ou financeiro
da Uniselva, a mesma pgina anterior modificada para se adequar s necessidades destes
usurios. Esta d acesso a todos os projetos e permite a visualizao de todas as informaes
da mesma forma que o coordenador pode ver. Por trazer todos os projetos da Uniselva,
independentemente da situao, o sistema possibilita a busca de um determinado projeto atravs
do nome ou do cdigo.
Ainda, esta pgina mostra um resumo estatstico dos projetos em forma de nmeros e
grficos, estes sendo possvel alternar entre vrios tipos atravs das setas de Anterior e
Prximo. So informaes sobre totais de projetos em andamento, ativos, vencidos, alm da
diviso por rea.

Figura 15: Pgina do Diretor/Chefe

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

24

Pgina Principal
A Pgina Principal a rea em que o usurio, aps selecionar um projeto, tem acesso
s principais funcionalidades do Portal do Coordenador. Nela, ele encontra o resumo financeiro
do projeto na aba esquerda, dando acesso rpido situao financeira, como total de receita,
despesas, fatura, adiantamento, proviso e o saldo, alm de poder imprimir este resumo.
Atravs dos cones situados no centro da pgina, o usurio pode acessar as informaes
do projeto, o cronograma, consultar extrato do projeto, saldo oramentrio e faturas/bloquetos, e
tambm tem acesso ao Sistema de Boletos. O ltimo, agora, no requer mais outra senha para
ser acessado, uma vez que o usurio j se autenticou no acesso ao Portal do Coordenador.
Caso o usurio queira visualizar as informaes de outro projeto, ele pode clicar no link
de Alternar Projeto na parte superior da pgina e voltar seleo de projetos mencionada
anteriormente.

Figura 16: Pgina Principal do sistema

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

25

Informaes do Projeto
O Portal do Coordenador conta com uma seo sobre as informaes do projeto da
mesma forma que o Unisig, porm com sua aparncia remodelada. A pgina inicia com
informaes como cdigo do projeto, nome, data de vigncia, objetivo e justificativa.
Abaixo, o usurio encontra uma diviso, onde esquerda esto os dados da unidade
executora, nome do coordenador, telefone e algumas caractersticas do projeto. direita est
localizado um link com a quantidade da fora de trabalho, que abre uma seo de detalhes ao
ser clicado, alm das informaes sobre o contrato e os dados bancrios.

Figura 17: Informaes do Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

26

Cronograma
Esta a principal diferena entre o Portal do Coordenador e o Unisig. A funcionalidade
do cronograma permite que o coordenador visualize as metas, etapas e itens a serem
executados durante o andamento do projeto. Estas informaes sero inseridas no sistema
interno da Uniselva durante o cadastro do projeto, provenientes da proposta de trabalho do
projeto.

Figura 18: Cronograma do Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

27

Alm disso, alguns itens do cronograma possuem uma previso de gastos que, ao
visualizar os detalhes, dividem esta previso em rubricas para mostrar quanto o item ir gastar
para cada uma delas.

Figura 19: Detalhes do Cronograma

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

28

No caso dos projetos com formato de curso, como especializaes, mestrados,
doutorados, entre outros, o cronograma tambm permite a visualizao das atividades
relacionadas ao ensino, ou seja, como disciplinas.

Figura 20: Cronograma de Curso

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

29

Extrato do Projeto
Uma das consultas disponveis no sistema o Extrato do Projeto, onde o coordenador
tem acesso s informaes detalhadas da situao atual do projeto. Nele, possvel visualizar
a situao geral ou filtrar por receitas, despesas e adiantamentos.
Nas receitas, so mostrados os recursos obtidos atravs do investimento do rgo
financiador e tambm do recebimento de faturas e bloquetos. As despesas so divididas entre
as rubricas com um subtotal para cada rubrica e os adiantamentos entre os pendentes e os j
comprovados.

Figura 21: Extrato do Projeto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

30

Saldo Oramentrio
Pelo Saldo Oramentrio do projeto, o usurio tem a viso da previso e dos gastos
realizados at ento. Na tabela so mostrados, para cada rubrica, o que foi previsto, a receita
alocada para aquela rubrica (caso disponvel), as despesas e o saldo. O usurio tambm tem a
possibilidade visualizar estas informaes em grficos.

Figura 22: Saldo Oramentrio

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

31

Faturas/Bloquetos
A terceira consulta disponvel no Portal do Coordenador a relao de Faturas e
Bloquetos. Nesta pgina possvel visualizar as faturas e bloquetos do projeto atravs de filtros
como situao (em aberto, recebidas e estornadas) e de perodo, alm de habilitar apenas
faturas, bloquetos ou ambos. No topo da tabela de resultados da consulta possvel exportar os
registros para documentos em Word ou Excel, e aps ao tabela so mostrados os totais dos
resultados.

Figura 23: Faturas/Bloquetos

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

32

5.4. Modos de Operao por Usurio

Por ser um sistema na Web com o objetivo especfico de fornecer informaes sobre
projetos para seus usurios, o Portal do Coordenador possui apenas dois modos de operao
distribudos nas trs classes de usurios presentes no sistema.

Coordenador
Da mesma forma que o Unisig, o coordenador o professor da UFMT responsvel pela
coordenao de seu projeto. Atravs do sistema, este ter acesso s informaes relacionadas
a seus projetos, como extrato financeiro, resumo, saldo e cronograma.

Diretor
O diretor o professor da UFMT responsvel pela Diretoria Geral da Fundao Uniselva.
Portanto, este pode acessar o sistema para ter uma viso estratgica da situao dos projetos
atravs de um resumo estatstico, e tambm pode acessar as mesmas informaes dos projetos
que os coordenadores acessam.

Chefe de Projeto e Financeiro
Os chefes dos setores de Projeto e Financeiro so funcionrios da Uniselva que
gerenciam e auxiliam os projetos. Estes possuem a mesma viso que o diretor, alm de serem
responsveis por dar acesso ao sistema para os coordenadores.

5.6. Ambiente de Apoio

Dependendo da situao da infraestrutura de rede da Uniselva e caso aprovado, o Portal
do Coordenador poder ser hospedado nos servidores da Fundao, permitindo um maior
controle sobre seu funcionamento e o compartilhamento de dados com o sistema interno seria
em tempo real.
No entanto, caso mantida a hospedagem terceirizada, o sistema ir utilizar as
funcionalidades de atualizao entre banco de dados do Microsoft SQL Server, com a
desvantagem deste processo ser feito em horrios fora do expediente para no gerar transtornos
na utilizao de ambos os sistemas e no sobrecarregar a rede.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

33

6. Resumo dos Impactos

Este captulo ir descrever os impactos que o desenvolvimento do Portal do Coordenador
pode causar no modo de trabalho empregado atualmente no Unisig, quando transferido para
este novo sistema, alm dos impactos na organizao da Fundao Uniselva e os impactos
sofridos durante o prprio desenvolvimento do sistema.

Impactos Operacionais
Com a mudana do Unisig para o Portal do Coordenador, no existir mais a
necessidade de realizar as atualizaes manuais dos dados do sistema interno, uma vez que,
mesmo se o novo sistema ainda for hospedado por uma empresa terceirizada, ambos os
sistemas iro utilizar a mesma tecnologia de banco de dados, e a prpria ser encarregada de
automatizar este processo, no sendo mais necessria a interveno de um funcionrio.
Outra mudana ser no procedimento de visualizar as informaes de um projeto, j
que agora a escolha do projeto acontece antes de selecionar a funcionalidade, permitindo o
acesso a outras sem a necessidade de escolher o projeto novamente.
O acesso ao Sistema de Boleto tambm ser alterado, sendo que agora no ser mais
necessrio informar uma nova senha para entrar no sistema.

Impactos Organizacionais
Uma mudana que ir impactar na organizao da Uniselva do ponto de vista do sistema
a incluso do Diretor Geral e dos Chefes de Projeto e Financeiro no grupo de usurios que
podem ter acesso. Ainda, os chefes tero a responsabilidade de permitir o acesso dos
coordenadores ao sistema.

Impactos durante o Desenvolvimento
O desenvolvimento do Portal do Coordenador est diretamente ligado ao do novo
sistema interno da Uniselva, a ponto de ser influenciado por seu andamento. Isto , o Portal do
Coordenador ir utilizar o sistema interno como fonte das informaes disponibilizadas para seus
usurios, e, por isso, depender da base de dados e das informaes inseridas por este sistema
interno.

7. Anlise do Sistema Proposto

Uma vez definida a situao do sistema atual, descritos os motivos e as justificativas
para a criao de um novo, a apresentao da proposta e o estudo dos impactos, resta realizar
uma anlise desta proposta, resumindo as melhorias, listando as desvantagens e limitaes,
alm das alternativas proposta apresentada.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

34

7.1. Resumo das Melhorias

Com a proposta de melhorar o acompanhamento dos projetos por parte de seus
coordenadores, o Portal do Coordenador traz uma srie de melhorias em relao ao sistema
atual (Unisig), dentre elas:
Adio do cronograma
Adio da rea do Diretor e das Chefias de Projeto e Financeiro
Detalhamento das receitas e adiantamentos
Integrao do acesso, incluindo o Sistema de Boleto
Reformulao da aparncia e adequao a dispositivos mveis

7.2. Desvantagens e Limitaes

Supondo que o Portal do Coordenador seja hospedado utilizando a infraestrutura da
Uniselva, uma das desvantagens a responsabilidade de garantir o funcionamento do sistema
neste aspecto, j que, comparado com a soluo de hospedagem empregada com o Unisig
atualmente, no h nenhum esforo por parte da Fundao Uniselva em relao aos aspectos
tcnicos do ambiente de execuo do sistema.
Sobre limitaes, o Portal do Coordenador trabalha apenas com a visualizao das
informaes do projeto, j que a possibilidade de insero de dados ir causar um grande
impacto o processo empregado atualmente pelos setores da Uniselva.

7.3. Alternativas e Escolhas consideradas

Alm do desenvolvimento do Portal do Coordenador, foram consideradas algumas
alternativas para suprir as necessidades expostas por este documento. Uma delas a aquisio
de um sistema j existente no mercado, caso este atenda aos requisitos ou possibilite uma
adequao para alcanar este objetivo. Isto porque, dependendo do custo, esta escolha poderia
ser mais vivel e mais rpida do que implementar um sistema prprio.
Outra alternativa seria atualizar o sistema atual (Unisig) com as especificaes
solicitadas pelos usurios ao invs de refaz-lo. Este procedimento seria teoricamente mais
rpido e mais simples do que desenvolver um novo sistema, pois no seria necessrio
implementar as funcionalidades que j esto disponveis hoje. Na prtica, porm, o processo
pode ser mais demorado, pois o Unisig utiliza uma tecnologia que no possui tanta afinidade
com o novo sistema interno a ser desenvolvido em conjunto, alm de no ser dominada por todos
os integrantes da equipe de desenvolvimento.

85

Apndice II: Documento de Requisitos


Documento de Requisitos

Verso 1.1

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

i

Histrico de Reviso

10/02/2014 1.0 Adaptao da estrutura do documento Lucas Pinto e Silva
18/02/2014 1.1 Adio de requisitos de notificao e
cronograma de cursos
Lucas Pinto e Silva

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

ii

Sumrio

1. Introduo ............................................................................................................................. 1
1.1. Identificao .................................................................................................................. 1
1.2. Viso Geral do Documento ........................................................................................... 1
1.3. Convenes, termos e abreviaes ............................................................................... 1
1.4. Viso Geral do Sistema .................................................................................................. 2
2. Requisitos Funcionais ............................................................................................................ 3
3. Requisitos No-Funcionais .................................................................................................... 5

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

1

1. Introduo

O Documento de Requisitos do sistema Portal do Coordenador tem como objetivo
descrever os requisitos identificados atravs do levantamento das necessidades dos
coordenadores em relao ao acompanhamento de seus projetos. Este documento tem como
pblico-alvo a equipe de desenvolvimento do sistema, fornecendo uma lista dos requisitos de
uma maneira mais formal e direta para servir como base na implementao e como referncia
na fase de testes.
As subsees abaixo mostram a estrutura deste documento, as terminologias e os
padres empregados, alm de fazer uma breve descrio do sistema em questo.

1.1. Identificao

2014, ser baseado no sistema UNISIG atualmente em funcionamento, tomando seu lugar como


Este documento de requisitos foi estruturado atravs das seguintes sees:
Seo 1 descreve o intuito deste documento de requisitos e ao sistema que ele
se aplica.
Seo 2 lista os Requisitos Funcionais do sistema e suas respectivas
prioridades.
Seo 3 lista os Requisitos No-Funcionais do sistema e suas respectivas
complexidades.

1.3. Convenes, termos e abreviaes

Para interpretar corretamente as informaes dispostas neste documento, necessrio
ter conhecimento de algumas convenes, termos e abreviaes.
A identificao dos requisitos feita atravs de um cdigo composto pela sigla do tipo
do requisito (RF para requisitos funcionais e RNF para os no-funcionais) junto com um
identificador numrico sequencial, delimitados por colchetes (por exemplo, [RF01] ou [RNF01]).
Alm da identificao, os requisitos tambm possuem uma classificao para cada tipo.
Os requisitos funcionais so classificados de acordo com sua prioridade de entrega, enquanto

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

2

os no-funcionais possuem classificao por complexidade de execuo. As classificaes so
descritas da seguinte forma:
Prioridade (requisitos funcionais)
o Alta: o requisito necessrio para o funcionamento do sistema e este
no pode ser entregue sem sua implementao.
o Mdia: requisito que, se no implementado, no impede a entrega do
sistema, porm, so necessrios para permitir um funcionamento
satisfatrio.
o Baixa: requisito que no precisa ser includo na primeira verso do
sistema, caso no haja tempo hbil para sua implementao, j que no
impede a execuo das funcionalidades bsicas.
Complexidade (requisitos no-funcionais)
o Alta: o requisito demandar uma grande quantidade de recursos e tempo
para ser implementado.
o Mdia: requisito que tomar tempo e recursos considerveis da equipe
de desenvolvimento, porm, no tendo grande impacto no cronograma.
o Baixa: requisito de pouca necessidade de recursos e tempo, no
gerando impacto no cronograma.
A classificao aparecer no documento logo aps a identificao do requisito, dentro
de parnteses, com a sigla P para prioridade ou C para complexidade, seguido de dois pontos e
do nvel (alta, mdia, baixa). Por exemplo, um requisito funcional pode ser identificado e
classificado como [RF01] (P: Alta), enquanto um no-funcional pode ser visto como [RNF01] (C:
Baixa).


completa da situao dos projetos para seus coordenadores do que o sistema atual (UNISIG)
principalmente atravs de um cronograma, que criado a partir do plano de aplicao do projeto.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

3

2. Requisitos Funcionais

Esta seo lista todos os requisitos funcionais identificados para o desenvolvimento do
Portal do Coordenador, identificados com o prefixo e a classificao definidos na seo 1.3. Estes
so afirmaes sobre os servios que sero fornecidos pelo sistema, como deve reagir a
entradas especficas e como se comportar em algumas situaes.

[RF01] (P: Baixa) O sistema deve disponibilizar um link de ajuda sobre as funcionalidades
do sistema no topo de todas as pginas.
[RF02] (P: Baixa) O sistema deve, aps o login do usurio, disponibilizar um link para as
configuraes da conta no topo de todas as pginas.
[RF03] (P: Alta) O sistema deve, aps o login do coordenador, mostrar a lista de projetos
coordenados por ele.
[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.
[RF06] (P: Mdia) O sistema deve mostrar os totais de projetos em nmeros e em grficos.
[RF07] (P: Baixa) O sistema deve permitir a alternao entre os grficos mostrados.
[RF08] (P: Mdia) O sistema deve permitir o chefe dar acesso ao sistema para um
coordenador.
[RF09] (P: Mdia) O sistema deve permitir o chefe relacionar os projetos a seus
respectivos coordenadores no sistema.
[RF10] (P: Alta) O sistema deve, aps a seleo do projeto, mostrar a pgina principal.
[RF11] (P: Alta) A pgina principal deve ter os cones das funcionalidades do sistema
(Informaes do Projeto, Cronograma, Relatrios e Sistema de
Boletos).
[RF12] (P: Mdia) O cone de Relatrios deve conter os cones de Extrato do Projeto,
Saldo Oramentrio e Faturas/Bloquetos.
[RF13] (P: Mdia) O sistema deve mostrar, na pgina principal, uma aba contendo o
resumo financeiro do projeto.
[RF14] (P: Alta) O resumo financeiro deve conter os totais de receita, despesas, faturas,
adiantamentos, proviso e saldo para a data da consulta.
[RF15] (P: Mdia) O sistema deve permitir o usurio alternar de projeto, voltando na
pgina de seleo de projeto.
[RF16] (P: Alta) O sistema deve possuir uma pgina de informaes do projeto.
[RF17] (P: Alta) A pgina de informaes do projeto deve conter o cdigo do projeto,
nome, data de vigncia, objetivo, justificativa, unidade executora, nome
do coordenador, telefone, caractersticas, quantidade de fora trabalho,
contrato e informaes bancrias.
[RF18] (P: Mdia) A pgina de informaes deve conter um link para listar os nomes da
fora trabalho do projeto.
[RF19] (P: Alta) O sistema deve permitir a visualizao do cronograma do projeto.
[RF20] (P: Alta) O cronograma do projeto deve ser mostrado em uma tabela contendo
a meta, etapa/fase, especificao, quantidade/unidade, durao e
previso de gasto.
[RF21] (P: Mdia) O sistema deve permitir o detalhamento dos itens do cronograma.
[RF22] (P: Mdia) O detalhamento dos itens do cronograma deve conter os dados de
previso e despesa at a data da pesquisa para cada rubrica.
[RF23] (P: Baixa) O sistema deve fornecer uma verso do cronograma em grfico Gantt.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

4

[RF24] (P: Alta) O sistema deve disponibilizar uma verso do cronograma especfico
para projetos com formato de curso.
[RF25] (P: Alta) O cronograma de curso deve conter a data da disciplina, o nome, o
horrio e a carga horria.
[RF26] (P: Alta) O sistema deve notificar o usurio sobre o vencimento do projeto com
15 dias de antecedncia.
[RF27] (P: Alta) O sistema deve notificar o usurio caso uma atividade do cronograma
no tenha gasto no mnimo 90% do previsto at o seu fim com 5 dias
de antecedncia.
[RF28] (P: Alta) O sistema deve permitir a visualizao do extrato do projeto.
[RF29] (P: Alta) A pgina do Extrato do Projeto deve mostrar registros de receita,
despesas e adiantamentos.
[RF30] (P: Mdia) Cada tipo de registro deve possuir uma aba prpria, alm de estarem
contidos numa aba geral.
[RF31] (P: Baixa) Caso o tipo de registro tenha subtipos, os registros devem ser
agrupados de acordo com estes.
[RF32] (P: Mdia) O sistema deve permitir a impresso do Extrato do Projeto.
[RF33] (P: Alta) O sistema deve permitir a visualizao do Saldo Oramentrio do
projeto.
[RF34] (P: Alta) O Saldo Oramentrio deve conter a previso, a receita alocada, a
despesa e o saldo para cada rubrica.
[RF35] (P: Mdia) O sistema deve mostrar o Saldo Oramentrio atravs de tabela e
grfico.
[RF36] (P: Alta) O sistema deve disponibilizar a relao de faturas e bloquetos.
[RF37] (P: Alta) A relao de faturas e bloquetos deve conter o nmero do documento,
nome, vencimento, data do pagamento, valor da fatura, valor pago e
situao.
[RF38] (P: Mdia) O sistema deve permitir filtrar a relao de faturas e bloquetos por
perodo e situao.
[RF39] (P: Baixa) O sistema deve totalizar os valores das faturas e bloquetos em pagos,
a receber e estornados.
[RF40] (P: Baixa) O sistema deve permitir mostrar apenas faturas, bloquetos ou ambos.
[RF41] (P: Mdia) O banco de dados utilizado no login do sistema deve ser integrado com
os outros sistemas da Uniselva.
[RF42] (P: Mdia) O sistema deve permitir a integrao de acesso com o Sistema de
Boleto.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

5

3. Requisitos No-Funcionais

Esta seo lista todos os requisitos no-funcionais para o desenvolvimento do Portal do
Coordenador, identificados com o prefixo e a classificao definidos na seo 1.3. Estes so
caractersticas, qualidades e regras que devem ser seguidas pelo sistema, no necessariamente
relacionados s funcionalidades.

[RNF01] (C: Baixa) A aba do resumo financeiro na pgina principal deve se manter
fechada quando no houver interao.
[RNF02] (C: Baixa) A aba do resumo financeiro na pgina principal deve se expandir
mediante interao com o mouse.
[RNF03] (C: Baixa) O cone de Relatrios na pgina principal deve se ativar a visualizao
dos cones de Extrato de Projeto, Saldo Oramentrio e
Faturas/Bloquetos mediante interao com mouse.
[RNF04] (C: Baixa) Na pgina de informaes do projeto, quando um projeto estiver
vencido, uma nota em vermelho deve aparecer ao lado da data de
vigncia.
[RNF05] (C: Mdia) Os grficos do sistema devem ser mostrados utilizando uma animao
crescente.
[RNF06] (C: Mdia) O sistema deve ser compatvel com os browsers Internet Explorer 7,
Mozilla Firefox 3, Google Chrome 5, Opera 11 e Safari 5.
[RNF07] (C: Alta) O sistema deve ser compatvel com os sistemas operacionais
Windows (XP, Vista, 7 e 8), Linux (Ubuntu, Debian e Fedora), Mac OS
X (Snow Leopard, Lion, Mountain Lion, Mavericks), iOS (6 e 7),
Android (2.3.3, 4.0, 4.1, 4.2, 4.3 e 4.4) e Windows Phone (7, 7.5 e 8).
[RNF08] (C: Alta) O sistema deve ser compatvel com as resolues 240x320, 320x480,
480x640, 480x800, 800x600, 1024x600, 1024x768, 1280x800 e
1280x1024.
[RNF09] (C: Baixa) O sistema deve ser hospedado utilizando o Internet Information
Services (IIS).
[RNF10] (C: Baixa) O sistema deve utilizar o Microsoft SQL Server 2008 como banco de
dados.
[RNF11] (C: Alta) O sistema deve levar no mximo 10 segundos para processar uma
requisio.

93
Apndice III: Documento de Projeto


Documento de Projeto

Verso 1.0

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

i

Histrico de Reviso


CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

ii

Sumrio

Lista de Figuras ............................................................................................................................. iii
1. Introduo ............................................................................................................................. 1
1.1. Identificao .................................................................................................................. 1
1.2. Viso Geral do Documento ........................................................................................... 1
1.3. Ferramentas e Padres Utilizados ................................................................................ 1
1.4. Viso Geral do Sistema .................................................................................................. 2
2. Diagrama Entidade-Relacionamento .................................................................................... 2
3. Diagrama de Classes .............................................................................................................. 4

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

iii

Lista de Figuras

Figura 1: Diagrama Entidade-Relacionamento ...................................................................... 3
Figura 2: Diagrama de Classes UML ...................................................................................... 5

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

1

1. Introduo

O Documento de Projeto do sistema Portal do Coordenador tem como objetivo descrever
a estrutura do sistema, fazendo a ponte entre o contedo do Documento de Requisitos e a fase
de implementao. Este documento tem como pblico-alvo a equipe de desenvolvimento,
fornecendo uma viso grfica de como o sistema ir funcionar e qual ser sua fonte de dados.
As subsees abaixo mostram a estrutura deste documento, as ferramentas e os
padres empregados na criao dos diagramas, alm de fazer uma breve descrio do sistema
em questo.

1.1. Identificao

2014, ser baseado no sistema UNISIG atualmente em funcionamento, tomando seu lugar como


Este documento de requisitos foi estruturado atravs das seguintes sees:
Seo 1 descreve o intuito deste documento de projeto e ao sistema que ele
se aplica.
Seo 2 trata da representao do banco de dados utilizando um Diagrama
Entidade-Relacionamento.
Seo 3 mostra a estrutura do software em um Diagrama de Classes UML.

1.3. Ferramentas e Padres Utilizados

Para a criao dos diagramas apresentados neste documento, foram adotados os
padres e ferramentas descritos a seguir.
O Diagrama Entidade-Relacionamento (DER) foi elaborado utilizando uma ferramenta
chamada brModelo verso 2.0, desenvolvida por Carlos Henrique Cndido, que emprega a
notao de Entidade-Relacionamento criada por Peter Chen. Nesta notao, as entidades so
representadas por retngulos, os atributos por bales conectados s entidades com o nome do
atributo ao lado, as relaes por losangos conectando entidades, e especializaes
representadas por tringulos.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

2

Na criao do Diagrama de Classes, foi adotado o padro da Unified Modeling Language
(UML) em sua verso 2.0, e utilizada a ferramenta Dia (verso 0.97.2) para a construo do
diagrama. Nele, classes so representadas por caixas, contendo os atributos e os mtodos em
cada seo. Linhas conectando classes representam a associao entre elas, mostrando a
direo de leitura atravs de setas, e em alguns casos contendo diamantes vazios e cheios na
ponta, representando agregao e composio, respectivamente.


completa da situao dos projetos para seus coordenadores do que o sistema atual (UNISIG)
principalmente atravs de um cronograma, que criado a partir do plano de aplicao do projeto.

2. Diagrama Entidade-Relacionamento

Esta seo contm o Diagrama Entidade-Relacionamento (DER) do Portal do
Coordenador, que ser referenciado durante a criao do banco de dados utilizado por este
sistema. Pelo fato deste sistema ter como fonte de dados o sistema interno da Fundao
Uniselva, este diagrama representa a viso que o Portal do Coordenador ter do banco de dados
deste sistema interno. Isto , fisicamente, os dois bancos sero idnticos, porm, o sistema ir
acessar apenas as informaes representadas por este diagrama.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

3

Figura 1: Diagrama Entidade-Relacionamento

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

4

3. Diagrama de Classes

Nesta seo, apresentado o Diagrama de Classes UML. Este possui uma notao que
se assemelha bastante ao DER mostrado anteriormente, porm, com o objetivo de mostrar a
estrutura do software e como as informaes ilustradas no DER sero representadas no sistema.

CNPJ: 04.845.150/0001-57
Fax: 0xx65 3628-1220

5

Figura 2: Diagrama de Classes UML

Relatorio Final de Estágio Supervisionado - Lucas Pinto e Silva PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Relatorio Final de Estágio Supervisionado - Lucas Pinto e Silva PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDADE FEDERAL DE MATO GROSSO

COORDENAO DE ENSINO DE GRADUAO EM

También podría gustarte