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

Embed Size (px)

Citation preview

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    UNIVERSIDADE FEDERAL DE MATO GROSSO

    COORDENAO DE ENSINO DE GRADUAO EM

    CINCIA DA COMPUTAO

    RELATRIO DE ESTGIO SUPERVISIONADOANLISE E PROJETO DE UM SISTEMA DE

    ACOMPANHAMENTO PARA OS COORDENADORES DEPROJETOS DA FUNDAO UNISELVA

    LUCAS PINTO E SILVA

    CUIAB MT

    2014

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    UNIVERSIDADE FEDERAL DE MATO GROSSO

    COORDENAO DE ENSINO DE GRADUAO EM

    CINCIA DA COMPUTAO

    RELTORIO DE ESTGIO SUPERVISIONADOANLISE E PROJETO DE UM SISTEMA DEACOMPANHAMENTO PARA OS COORDENADORES DE

    PROJETOS DA FUNDAO UNISELVA

    LUCAS PINTO E SILVA

    Relatrio apresentado ao Instituto de

    Computao da Universidade Federal de

    Mato Grosso, para obteno do ttulo deBacharel em Cincia da Computao.

    CUIAB MT

    2014

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    UNIVERSIDADE FEDERAL DE MATO GROSSO

    COORDENAO DE ENSINO DE GRADUAO EM

    CINCIA DA COMPUTAO

    LUCAS PINTO E SILVA

    Relatrio de Estgio Supervisionado apresentado Coordenao do Curso deCincia da Computao como uma das exigncias para obteno do ttulo deBacharel em Cincia da Computao da Universidade Federal de Mato Grosso

    Aprovado por:

    Prof. Dr. Joo Paulo Igncio Ferreira Ribas

    Instituto de Computao

    (Coordenador de Estgios)

    Prof. MSc. Thiago Meirelles Ventura

    Instituto de Computao

    (Orientador)

    Alberto Maral Figueiredo Tavares JuniorCoordenador do Ncleo de Processamento de Dados da Uniselva

    (Supervisor)

    Prof. Dr. Cristiano Maciel

    Instituto de Computao

    (Diretor da Fundao Uniselva)

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    DEDICATRIA

    minha av, Zil da Silva Pinto, quedeve estar muito orgulhosa de mim pormais esta conquista, onde quer que elaesteja.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    AGRADECIMENTOS

    Agradeo primeiramente a minha famlia, em especial aos meus pais Antnio

    Silvestre da Silva e Eliana da Silva Pinto, que sempre lutaram para que eu tivesse o

    necessrio para crescer e me ensinaram a fazer o mesmo para conquistar o que eu

    quero. Agradeo a famlia Melo Ribeiro pelos 5 anos de apoio, durante toda a minha

    graduao e tambm no meu intercmbio. Em especial, agradeo a minha namorada,

    Ana Carolina de Melo Ribeiro, pela compreenso e pacincia ao sacrificar nosso

    tempo juntos para a escrita deste relatrio. Ao professor Cristiano Maciel por apoiar

    meu crescimento acadmico e profissional, desde o meu primeiro estgio at a

    oportunidade de trabalhar na Uniselva e desenvolver este trabalho. Ao professor

    Thiago Meirelles Ventura por ter sido meu orientador, no s na escrita deste

    relatrio mas tambm durante todo o meu estgio na STI/UFMT, me ajudando a

    construir minha carreira profissional desde o comeo. Ao meu supervisor Alberto

    Maral Figueiredo Tavares Junior e meus colegas de trabalho pela colaborao na

    execuo dos trabalhos aqui apresentados. E agradeo tambm a todas as outras

    pessoas que, direta ou indiretamente, me ajudaram a chegar at aqui.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    SUMRIO

    LISTA DE FIGURAS .......................................................................................................................... 7LISTA DE SIGLAS E ABREVIATURAS ..................................................... .................................... 8RESUMO .............................................................................................................................................. 91. INTRODUO ........................................................................................................................ 10

    1.1 JUSTIFICATIVA........................................................................................................................ 111.2 OBJETIVO GERAL.................................................... ........................................................... ..... 111.3 OBJETIVOS ESPECFICOS................................................... ...................................................... 111.4 ORGANIZAO DO TRABALHO............................................................................................... 12

    2. REVISO DE LITERATURA .................................................... ............................................ 132.1 ENGENHARIA DE SOFTWARE....................................................... ............................................ 13

    2.1.1 Processos de software .................................................................................................. 132.1.2 Modelos de processo de software ........................................................ ......................... 162.1.3 Gerncia de projeto ...................................................................................................... 17

    2.2 CONCEITO OPERACIONAL....................................................................................................... 192.3 ELICITAO DE REQUISITOS................................................................................................... 202.4 PROJETO DE SOFTWARE.......................................................................................................... 212.5 PROTOTIPAO....................................................... ........................................................... ..... 23

    3. MATERIAIS, MTODOS E TCNICAS UTILIZADOS .................................................... 253.1 MODELO CASCATA DUPLA......................................................... ............................................ 253.2 SISTEMAS RELACIONADOS..................................................................................................... 263.3 CONOPS ...................................................... ........................................................... ............... 283.4 PROTTIPOS............................................................................................................................ 283.5 DOCUMENTO DE REQUISITOS.................................................................................................. 293.6 DOCUMENTO DE PROJETO....................................................................................................... 303.7 TECNOLOGIAS DE DESENVOLVIMENTO.......................................................... ......................... 32

    4. RESULTADOS ......................................................................................................................... 334.1 DOCUMENTO CONOPS .......................................................................................................... 334.2 DOCUMENTO DE REQUISITOS.................................................................................................. 374.3 DOCUMENTO DE PROJETO....................................................................................................... 38

    5. DIFICULDADES ENCONTRADAS .................................................... .................................. 426. CONCLUSES ......................................................... ........................................................... ..... 437. REFERNCIAS BIBLIOGRFICAS ........................................................... ......................... 44APNDICE I: DOCUMENTO CONOPS ...................................................... .................................. 46APNDICE II: DOCUMENTO DE REQUISITOS...................................... .................................. 85APNDICE III: DOCUMENTO DE PROJETO ................................................... ......................... 93

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    7

    LISTA DE FIGURAS

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

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    8

    LISTA DE SIGLAS E ABREVIATURAS

    UFMT Universidade Federal de Mato Grosso

    IFES Instituio Federal de Ensino Superior

    IEEE Instituto de Engenheiros Eletricistas e Eletrnicos

    RF Requisito Funcional

    RNF Requisito No-Funcional

    DER Diagrama Entidade-RelacionamentoMER Modelo Entidade-Relacionamento

    UML Unified Modeling Language

    PMI Project Management Institute

    PMBOK Project Management Body of Knowledge

    CONOPS Documento de Conceito Operacional

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    9

    RESUMO

    A Fundao Uniselva tem como um de seus grandes objetivos apoiar projetos de

    pesquisa, ensino, extenso e desenvolvimento institucional da UFMT. Para isso, ela

    precisa fornecer informaes e prestar contas sobre estes projetos para seus

    respectivos coordenadores. Porm, o sistema atualmente em funcionamento,

    chamado Unisig, no consegue atender todas as demandas de seus usurios. Este

    trabalho visa descrever o processo de criao de um novo sistema para suprir as

    necessidades dos coordenadores, desde a coleta de requisitos at a preparao para a

    implementao. Com este novo sistema, espera-se que os coordenadores tenham uma

    melhor viso da situao de seus projetos, bem como melhorar o gerenciamento dos

    recursos financeiros. No decorrer deste trabalho, so revisadas as diretrizes da

    Engenharia de Software, alm de mostrar como os mtodos envolvidos foram

    empregados neste caso.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    10

    1.INTRODUO

    A Universidade Federal de Mato Grosso (UFMT) uma Instituio Federal

    de Ensino Superior (IFES) que possui o objetivo de promover o ensino, a pesquisa e

    a extenso nos diferentes ramos do conhecimento, bem como a divulgao cientfica,

    tcnica e cultural (UFMT, 2014). Uma forma de alcanar este objetivo atravs de

    projetos coordenados pelos prprios professores da UFMT, porm, o processo

    burocrtico e no permite uma gerncia fcil dos recursos financeiros. Neste caso, o

    coordenador pode optar por executar seu projeto por meio da Fundao Uniselva.

    A Fundao de Apoio e Desenvolvimento da Universidade Federal de Mato

    Grosso Fundao Uniselva segundo o estatuto da Uniselva (2014), uma

    entidade de direito privado e sem fins lucrativos que tem como objetivos gerais

    promover e subsidiar programas de pesquisa, prestar servios tcnicos, alm de

    exercer outras atividades que contribuam com o desenvolvimento tcnico, cientfico

    e assistencial da UFMT e de sua comunidade.

    Portanto, a Fundao Uniselva cria uma ponte entre o projeto de um

    coordenador com o rgo financiador e assume a responsabilidade de gerenciar a

    comunicao entre as partes, tomando conta de todo o trabalho burocrtico e

    gerenciando os recursos financeiros, permitindo que o coordenador possa ter um foco

    maior na execuo de seu projeto. Alm disso, a Uniselva tambm controla a

    inscrio de alunos e participantes em projetos que promovem cursos e eventos,

    prestando assim servios no s para a comunidade acadmica da UFMT mas

    tambm para a externa.

    Para fornecer informaes sobre os projetos para seus respectivoscoordenadores, a Fundao Uniselva conta com um sistema chamado Unisig, que

    fornece dados sobre o extrato financeiro do projeto, seu saldo oramentrio,

    faturas/bloquetos, alm de informaes cadastrais, como rgo financiador, conta

    bancria, vigncia, entre outras.

    Infelizmente, ao longo dos anos em que o Unisig esteve (e ainda est) em

    funcionamento, a Fundao Uniselva percebeu que, atravs das opinies e sugestes

    dos coordenadores de projetos, o sistema no est conseguindo exercer de formasatisfatria sua funo, que dar uma viso completa da situao do projeto. H

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    11

    ento, uma necessidade de um sistema com mais funcionalidades para que as

    demandas dos usurios possam ser atendidas.

    1.1Justificativa

    Como pode ser visto anteriormente, h a necessidade de um sistema onde

    informaes sobre receita, faturas, adiantamentos, entre outras, estivessem mais

    detalhadas do que o sistema atual, alm de incluir uma funcionalidade de

    acompanhamento do cronograma do projeto, fazendo a ligao entre as despesas e o

    que foi previsto para um dado perodo.Faz-se necessrio tambm uma rea de alertas e notificaes, onde o

    coordenador poderia ser informado sobre prazos e ocorrncias relacionadas ao

    cronograma, para que no ocorram imprevistos e transtornos com vencimentos e

    recursos financeiros gastos inapropriadamente.

    Portanto, para resolver esse problema, um novo sistema deve ser proposto e

    desenvolvido, seguindo, claro, as boas prticas de engenharia de software.

    1.2Objetivo Geral

    Tendo em vista as necessidades dos coordenadores citadas acima, este

    trabalho tem como objetivo relatar os conhecimentos necessrios e as etapas do

    processo de desenvolvimento de um novo sistema, chamado Portal do Coordenador,

    que ir permitir um melhor acompanhamento do projeto por parte do coordenador e

    reduzir os problemas relatados pelos usurios do sistema atual, o Unisig.

    1.3Objetivos Especficos

    Para executar o desenvolvimento do novo sistema, este trabalho conta com

    os seguintes objetivos especficos:

    Estudar os principais conceitos de engenharia de software.

    Pesquisar sobre Conceito Operacional.

    Analisar as necessidades dos usurios do sistema Unisig.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    12

    Elaborar um documento de Conceito Operacional.

    Elicitar os requisitos do Portal do Coordenador.

    Escrever um documento de projeto.

    Criar uma prototipao das funcionalidades do novo sistema.

    1.4Organizao do Trabalho

    Os captulos deste trabalho esto organizados da seguinte forma:

    Captulo 2: Faz uma reviso literria dos temas abordados neste trabalho.

    Captulo 3: Lista e descreve os materiais, mtodos e tcnicas utilizados.Captulo 4: Descreve os resultados obtidos, onde so descritos os

    documentos gerados.

    Captulo 5: So descritas as dificuldades encontradas durante a execuo

    dos trabalhos.

    Captulo 6: O ltimo captulo descreve as concluses obtidas com este

    trabalho, fazendo uma reflexo sobre a importncia deste trabalho e citando os

    prximos passos a serem realizados.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    13

    2.REVISO DE LITERATURA

    A necessidade de padronizar, automatizar e agilizar a execuo de tarefas e

    processos por parte de organizaes, grupos e at indivduos explica o motivo de se

    estudar e aplicar determinados conceitos, afim de se obter um produto que, mesmo

    sendo algo intangvel, de grande importncia para que estes consigam atingir seus

    objetivos.

    Este captulo apresenta tais conceitos de engenharia de software e tambm

    informaes sobre as principais tecnologias e metodologias utilizadas na realizao

    deste trabalho.

    2.1Engenharia de Software

    Engenharia de Software a aplicao de uma abordagem sistemtica,

    disciplinada e quantificvel para o desenvolvimento, operao e manuteno de

    software (IEEE, apud PRESSMAN, 2010, p. 13). J para Sommerville (2007, p. 7),

    ela uma disciplina da engenharia que se preocupa com todos os aspectos daproduo de software, desde os estgios iniciais da especificao do sistema at a

    manuteno do mesmo depois de ter iniciado seu uso.

    Sendo assim, pode-se entender que esta engenharia tem como objetivo

    aplicar um processo de teorias, tcnicas, mtodos e ferramentas com o intuito de criar

    um software que resolva um problema ou contribua com um processo ou trabalho.

    2.1.1 Processos de software

    No contexto da engenharia de software, um processo no uma prescrio

    rgida de como construir um software de computador. Ao contrrio, uma

    abordagem adaptvel que possibilita s pessoas (a equipe de software) realizar o

    trabalho de selecionar e escolher o conjunto apropriado de aes e tarefas

    (PRESSMAN, 2010, p. 14).

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    14

    Deste modo, o processo de software visto como um guia para a criao de

    um software, permitindo uma flexibilidade de sua execuo para se adequar s

    necessidades e s condies do cliente e da equipe.Fazendo um agrupamento das aes e tarefas do processo, definimos as fases

    de um processo. Uma fase um perodo de tempo no qual determinadas atividades

    com objetivos bem especficos so realizadas (WAZLAWICK, 2013, p. 12).

    Portanto, se uma, duas ou vrias tarefas so necessrias para se chegar a um ponto do

    processo ou gerar algum documento, estas podem ser agrupadas e trabalhadas em

    conjunto.

    Mesmo que existam diversos processos de software, algumas fasesfundamentais so comuns dentre eles (SOMMERVILLE, 2007, p. 8):

    1. Especificao de software: onde clientes e engenheiros definem o

    software a ser produzido e suas regras de operao.

    2. Desenvolvimento de software: onde o software projetado e

    programado.

    3. Validao de software: onde o software verificado para garantir que

    ele faz o que o cliente solicitou.

    4. Evoluo de software: onde o software modificado para se adaptar

    s mudanas de necessidades dos consumidores e do mercado.

    Uma vez definidas as fases do processo, possvel descer um nvel e dividir

    cada fase em atividades. Para Pressman (2010, p. 31), em cada fase de um processo

    de software definido, so executadas as atividades bsicas para que sejam atingidos

    os objetivos propostos. Estas atividades constituem um conjunto mnimo para se

    obter um produto de software.

    Assim como as fases citadas acima aparecem frequentemente nos processos

    de software, algumas atividades essenciais tambm esto presentes, mudando apenas

    a ordem ou o nmero de vezes em que so executadas. De acordo com Sommerville

    (2007, p. 75-82), elas podem ser listadas em cada fase desta maneira:

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    15

    1. Especificao

    i. Estudo de viabilidade: uma estimativa sobre se as necessidades

    dos usurios sero atendidas usando as tecnologias de softwaree hardware atuais, para estudar se o sistema proposto ser

    vivel do ponto de vista do negcio.

    ii. Elicitao de requisitos e anlise: processo de derivao dos

    requisitos do sistema atravs da observao de sistemas

    existentes, conversas com usurios potenciais, anlise de

    tarefas, entre outros. Este item abordado com mais detalhes

    na seo 2.3.iii. Especificao de requisitos: atividade de traduzir as

    informaes coletadas no item anterior para um documento

    que define um conjunto de requisitos. A seo 3.5 mostra

    como este documento foi elaborado no escopo deste trabalho.

    iv. Validao de requisitos: verifica os requisitos em relao a

    realismo, consistncia e integridade. Neste processo, alguns

    erros no documento de requisitos so descobertos e devem ser

    corrigidos.

    2. Desenvolvimento

    i. Projeto da arquitetura: os subsistemas que compem o sistema

    e seus relacionamentos so identificados e documentados.

    ii. Especificao abstrata: para cada subsistema, elaborada uma

    especificao abstrata de seus servios e restries em que este

    deve operar.

    iii. Projeto da interface: para cada subsistema, projetada e

    documentada sua interface com outros subsistemas.

    iv. Projeto dos componentes: servios so alocados para

    componentes e as interfaces destes componentes so

    projetados.

    v. Projeto da estrutura de dados: as estruturas de dados usados na

    implementao do sistema so projetados em detalhes e

    especificados.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    16

    vi. Projeto de algoritmos: os algoritmos usados para fornecer

    servios so projetados em detalhes e especificados.

    3. Validaoi. Teste de componente: componentes individuais so testados

    separadamente para garantir que eles operem corretamente.

    ii. Teste de sistema: os componentes so integrados para criarem

    o sistema. Este processo se preocupa em achar erros

    provenientes de interaes no previstas entre os componentes.

    iii. Teste de aceite: esta a ltima etapa do processo de testes,

    antes do sistema ser aceito para uso, onde este testado comdados fornecidos pelo consumidor do sistema ao invs de

    dados simulados.

    4. Evoluo

    i. Proposta de mudanas: aps o sistema estar em

    funcionamento, novas propostas so feitas para adaptar o

    sistema novas necessidades ou corrigir problemas,

    reiniciando o ciclo.

    As diferenas de como ou quando estas atividades sero realizadas ir

    depender do modelo de processo de software a ser escolhido.

    2.1.2 Modelos de processo de software

    Para dar uma ordem s atividades do processo de software, so definidosmodelos de processo de software. Segundo Sommerville (2007, p. 8-9), um modelo

    de processo de software uma descrio de um processo de software que apresenta

    uma viso deste processo, podendo incluir atividades que fazem parte do processo de

    software, de produtos de software e das funes das pessoas envolvidas na

    engenharia de software.

    A escolha de um modelo deve ser compatvel com a situao do sistema a ser

    desenvolvido. A escolha errada pode trazer transtornos para o cliente e para a equipede desenvolvimento, podendo at comprometer a entrega do sistema.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    17

    Existem vrios modelos de processo de software diferentes, cada um com

    suas especificidades. Dentre eles, o mais comum o modelo de cascata (e suas

    variaes). O modelo de cascata, algumas vezes chamado de ciclo de vida clssico,sugere uma abordagem sistemtica e sequencial para o desenvolvimento de software,

    que inicia com a especificao dos requisitos do consumidor, passa pelo

    planejamento, modelagem, construo e publicao, chegando no suporte do

    software completo (PRESSMAN, 2010, p. 39).

    Um dos motivos dele ser o mais comum a simplicidade de sua execuo, j

    que o processo segue uma linha reta entre as etapas, sempre utilizando o trabalho

    gerado em uma etapa como material para a prxima. Algumas de suas variaespermitem a alterao deste fluxo de trabalho, como o caso do modelo de cascata

    dupla, em que, dependendo da necessidade ou da ocorrncia de algum imprevisto, o

    processo pode voltar uma etapa atrs para refazer ou aperfeioar um trabalho. Esse

    modelo que ser utilizado neste trabalho e mais informaes de como isso ser feito

    podem ser encontradas na seo 3.1.

    Escolher um modelo de processo de software essencial para garantir a

    execuo correta das atividades do processo. Porm, tambm importante definir

    como os trabalhos sero acompanhados, o tempo que estes levaro, o que fazer caso

    algo inesperado acontea, entre outras questes. Para isso existe a gerncia de

    projeto.

    2.1.3 Gerncia de projeto

    A gerncia de projeto pode ser entendida como uma disciplina dentro de umprocesso de engenharia de software, em geral exercida por um nico indivduo (o

    gerente de projeto) cuja funo levar o projeto a alcanar os objetivos planejados

    dentro dos prazos, com o custo e qualidade previstos (WAZLAWICK, 2013, p. 203).

    Sendo assim, pode ser dito que o gerente de projeto tem a responsabilidade de manter

    saudvel o andamento do projeto, verificando se os prazos esto sendo cumpridos

    e se o trabalho est sendo feito como o esperado e com a qualidade prevista.

    Para ser definido como ser guiada a gerncia do projeto, podem serreferenciadas fontes importantes como o Project Management Body of Knowledge

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    18

    (PMBOK), publicado pelo Project Management Institute (PMI, 2014). De acordo

    com Wazlawick (2013, p. 205), o PMBOK sugere dividir as atividades de

    gerenciamento em nove reas, sendo elas:1. Gerenciamento de integrao: atividades que o gerente de projetos

    executa de forma a garantir que todas as partes do projeto funcionem

    juntas.

    2. Gerenciamento do escopo: atividades necessrias para que o projeto

    execute de fato o que for preciso para gerar o produto e somente isso.

    3. Gerenciamento de tempo: atividades mais visveis em gerncia de projeto,

    consistem em garantir que as atividades do projeto ocorram dentro dostempos previamente definidos.

    4. Gerenciamento de custos: atividades que buscam garantir que o projeto

    ocorra dentro do oramento definido.

    5. Gerenciamento da qualidade: do ponto de vista externo, visa garantir que

    o produto atenda s expectativas do cliente; do ponto de vista interno, visa

    garantir que o produto seja suficientemente malevel para no dificultar

    desnecessariamente o trabalho da equipe.

    6. Gerenciamento de recursos humanos: atividades de aquisio, dispensa,

    formao e motivao da equipe, bem como de alocao de funes e

    relaes hierrquicas.

    7. Gerenciamento das comunicaes: controle das comunicaes internas e

    externas ao projeto.

    8. Gerenciamento de riscos: uma das reas mais importantes da gerncia de

    projetos, implica acompanhar o nvel de probabilidade e impacto dos

    riscos e tomar medidas para diminu-los.

    9. Gerenciamento de aquisies: atividades relacionadas aquisio de

    produtos ou servios necessrios ao projeto que no sejam produzidos ou

    fornecidos pela equipe de desenvolvimento.

    Por meio da descrio destas reas, pode ser percebido que o PMBOK pode

    ser aplicado para conduzir qualquer tipo de projeto, necessitando apenas do gerente

    ter conhecimentos sobre este tipo, como o caso do gerente de projetos de software.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    19

    2.2Conceito Operacional

    Normalmente, o processo de software comea com elicitao de requisitos

    para a elaborao do documento de requisitos. Porm, como ser mostrado na

    prxima seo, os resultados desta etapa contm termos tcnicos e especficos da

    engenharia de software, que podem ser de difcil compreenso por parte de alguns

    dos envolvidos no projeto, principalmente o cliente e os consumidores. A elaborao

    de um documento que descreva a proposta do sistema de uma forma a no necessitar

    de conhecimentos tcnicos para a compreenso do assunto uma soluo para esteproblema.

    O documento de Conceito Operacional (ConOps ou CONOPS) um

    documento voltado ao usurio que descreve as caractersticas do sistema proposto

    atravs do ponto de vista dos usurios. O documento CONOPS usado para

    transmitir as caractersticas quantitativas e qualitativas gerais do sistema para o

    usurio, cliente, desenvolvedor, e outros elementos organizacionais (IEEE 1362,

    1998, p. 1). Por ser um documento bem estruturado e formalizado, seus componentespodem se encaixar em qualquer projeto de software, no importando a dimenso ou a

    complexidade.

    No CONOPS, os clientes e consumidores podem expressar suas ideias quanto

    ao que esperam do sistema proposto sem se preocuparem com detalhes tcnicos

    sobre os requisitos, como por exemplo se eles so testveis ou no. Ele permite

    tambm que sejam discutidas vrias solues para os problemas apresentados, no se

    limitando a apenas uma alternativa.

    A estrutura de um documento CONOPS completo possui 9 captulos. Porm,

    a ideia principal deste documento est nos captulos 3, 4 e 5. O captulo 3 fala sobre a

    situao atual do sistema ou processo que o cliente queira substituir ou melhorar. No

    captulo 4, so descritos os motivos e as justificativas para o desenvolvimento de um

    novo sistema ou modificao do atual. J no 5, feita a proposta do novo sistema ou

    modificao, estruturado de forma quase idntica ao contedo do captulo 3.

    Atravs destes trs captulos, o cliente ou consumidor consegue ter uma viso

    clara da situao em que se encontra o sistema ou processo; as razes que levaram

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    20

    proposta de substituio ou melhoria; e como esta proposta ir solucionar os

    problemas e/ou necessidades atuais.

    Com o documento de CONOPS aprovado pelo cliente, pode-se ento partirpara a elicitao de requisitos da forma tradicional, agora tendo mais um documento

    para se basear durante a coleta dos requisitos.

    2.3Elicitao de requisitos

    A elicitao de requisitos uma das atividades mais importantes do processo

    de software. Ela a base para todo o trabalho de projeto e implementao do sistema,alm de servir como referncia na hora de validar o software criado. Pressman (2010,

    p. 128) diz que a elicitao de requisitos combina elementos de soluo de

    problemas, elaborao, negociao e especificao, e que, para encorajar uma

    abordagem colaborativa e orientada a equipes para a coleta de requisitos, uma equipe

    de interessados e desenvolvedores devem trabalhar em conjunto para identificar o

    problema, propor elementos da soluo, negociar diferentes abordagens e especificar

    um conjunto preliminar de requisitos da soluo. nesta fase de conversa e trabalho cooperativo que reside a dificuldade desta

    atividade, pois normalmente as necessidades dos envolvidos no so descobertas

    logo na primeira pergunta, sendo que muitas vezes nem os prprios clientes tem a

    viso exata do que eles precisam. Isto um problema porque, se o que eles querem

    no for claramente definido, o software criado no ir atender s necessidades e estes

    estaro insatisfeitos, gerando transtornos e despesas para a equipe.

    Por isso, a elicitao de requisitos no se prende apenas ao questionamento

    sobre o que o cliente quer. Ela tambm deve ser baseadas em documentos que iro

    interferir, restringir, ou suportar o sistema (por exemplo, o estatuto da empresa ou o

    prprio documento CONOPS citado anteriormente), na observao da situao atual

    do trabalho ou processo relacionado ao sistema, e na simulao de cenrios

    operacionais.

    Uma vez que a elicitao de requisitos tenha sido concluda e elaborado um

    documento de requisitos (ver seo 3.5), temos uma viso clara das necessidades do

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    21

    cliente e o que o sistema deve fazer. Devemos ento pensar como este deve operar e

    qual ser sua estrutura atravs de um projeto de software.

    2.4Projeto de software

    O projeto de software um processo interativo em que os requisitos so

    traduzidos em um desenho tcnico para a construo do software. Inicialmente, o

    documento mostra uma viso holstica do software, ou seja, o projeto representado

    em um alto nvel de abstrao nvel que pode ser diretamente relacionado ao

    objetivo especfico do sistema e a requisitos mais detalhados de dados, funcionais e

    comportamentais. medida que ocorrem as iteraes de projeto, os refinamentos

    subsequentes levam a representaes de projeto em nveis de abstrao muito mais

    baixos. Esses ainda podem ser relacionados aos requisitos, porm a conexo mais

    sutil (PRESSMAN, 2010, p. 219).

    Atravs desta definio, podemos entender que o papel do projeto de

    software fazer a ligao entre os requisitos do cliente e dos consumidores com o

    trabalho a ser realizado durante a implementao do software. Alm disso, o projetopermite que o desenvolvedor tenha uma viso completa de como o software deve ser

    no sentido tcnico, o que no seria possvel caso o trabalho fosse feito diretamente

    dos requisitos.

    Para padronizar as representaes dos projetos e modelos de software, uma

    das tecnologias mais utilizadas no momento a Unified Modeling Language (UML).

    A UML uma linguagem padro para escrever desenhos tcnicos de software. Ela

    pode ser usada para visualizar, especificar, construir e documentar os artefatos de umsistema baseado em software (PRESSMAN, 2010, p. 841).

    Este padro foi desenvolvido por Grady Booch, Jim Rumbaugh e Ivan

    Jacobson nos anos 90, unificando muitos modelos e notaes utilizadas na poca,

    com a ajuda da prpria comunidade de desenvolvedores. Hoje, a UML j est em sua

    segunda verso e conta com 14 diagramas diferentes para serem usados na

    modelagem de software. Um deles o diagrama de classe, que se assemelha bastante

    ao paradigma de programao orientada a objeto, fornecendo uma viso estrutural dosoftware.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    22

    O diagrama de classe utiliza caixas para representar classes e interfaces,

    divididos em partes horizontais. A parte de cima contm o nome da classe, a segunda

    lista os atributos e a terceira contm as operaes e comportamentos. Orelacionamento entre as classes representado por linhas, onde a linha slida

    significa associao, a flecha representa generalizao e, quando usada com uma

    linha tracejada, d a ideia de realizao. Um exemplo do uso deste diagrama

    mostrado na Figura 1.

    Figura 1: Diagrama de Classes (PRESSMAN, 2010, p. 843)

    Alm dos diagramas da UML, o projeto de software tambm construdo

    utilizando outro diagrama, chamado Diagrama Entidade-Relacionamento (DER).Usado especificamente para dar uma viso do sistema em relao persistncia dos

    dados, o DER, segundo Elmasri (2004, p. 49-50), uma notao diagramtica

    associada ao Modelo Entidade-Relacionamento (MER), que por sua vez consiste em

    um modelo de dados conceitual em alto nvel usado para o projeto conceitual de

    sistemas que utilizam bancos de dados.

    O DER utiliza uma notao similar ao diagrama de classes, porm, agora as

    caixas representam entidades e os bales conectados a elas so os atributos. O

    relacionamento entre as entidades representado por um losango e contm a

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    23

    cardinalidade do relacionamento, que pode ser 1:1 (um-para-um), 1:N (um-para-

    muitos) ou N:N (muitos-para-muitos). A Figura 2 ilustra um exemplo deste

    diagrama.

    Figura 2: Diagrama Entidade-Relacionamento

    O projeto de software fornece uma viso grfica da estrutura do software para

    o desenvolvedor. No entanto, tambm necessrio mostrar o mesmo para o cliente,

    porm de uma forma menos tcnica e prxima do que ele receber ao fim do

    desenvolvimento. Para isso, uma alternativa criar uma simulao de como o

    software ir funcionar quando estiver pronto, utilizando a tcnica de prototipao.

    2.5Prototipao

    Um prottipo uma verso inicial de um software que usada para

    demonstrar conceitos, experimentar opes de modelo e, geralmente, descobrir mais

    sobre o problema e suas possveis solues (SOMMERVILLE, 2007, p. 409). Este

    pode aparecer logo no incio da elicitao de requisitos, para tentar mostrar ao cliente

    se as necessidades deste foram identificadas corretamente, durante o projeto do

    sistema, para mostrar como os requisitos iro ser atendidos utilizando a estrutura

    modelada nesta fase, e tambm no processo de testes, para verificar se o software

    desenvolvido est de acordo com a viso que o cliente tinha.

    Os prottipos podem ser classificados de trs formas, de acordo com sua

    fidelidade ao produto final. Os prottipos de baixa fidelidade geralmente so

    desenhados para se ter uma ideia inicial do software utilizando materiais simples,

    como lpis e papel. J os de mdia fidelidade so desenvolvidos utilizando alguma

    ferramenta computacional, como um editor de texto software de diagramao, e

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    24

    apresentam um nvel de detalhamento maior. Por ltimo, os prottipos de alta

    fidelidade so semelhantes ao produto final e so criados a partir de ferramentas

    especializadas para prototipao ou usando as prprias tecnologias empregadas nodesenvolvimento do software.

    No prximo captulo ser detalhado como a prototipao foi realizada para o

    caso deste trabalho. Alm disso, ser detalhado tambm como foi feita a aplicao

    dos outros conceitos citados neste captulo.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    25

    3.MATERIAIS, MTODOS E TCNICAS UTILIZADOS

    Uma vez definidos os conceitos necessrios no captulo anterior, as sees a

    seguir iro descrever os materiais, mtodos e tcnicas utilizados no desenvolvimento

    deste trabalho, mostrando o modo em que foram empregados e tambm as

    adaptaes e escolhas feitas para o caso em estudo.

    3.1Modelo Cascata Dupla

    Como citado na seo 2.1.2, escolher um modelo de processo de software

    um passo importante, pois este deve se encaixar no s nas condies do software,

    mas principalmente nas condies da equipe de desenvolvimento para que seu uso

    seja eficiente. Um dos modelos citados foi o modelo de cascata dupla, onde o fluxo

    das atividades pode ser alterado de acordo com o resultado das atividades.

    Sendo assim, este modelo foi escolhido para guiar as atividades deste trabalho

    por ser um modelo de fcil compreenso, execuo, e por se enquadrar na

    simplicidade do sistema a ser desenvolvido. Alm disso, ele tambm permite umaflexibilidade para que algumas fases possam ser revistas caso o resultado de outras

    criem esta necessidade. Por exemplo, um requisito no identificado na fase de

    elicitao que surgiu durante o teste de uma funcionalidade ou durante a aprovao

    do cliente. Neste caso, a execuo do processo ter que retornar fase de elicitao e

    incluir o novo requisito, alm de identificar outros requisitos que possam ter surgido

    juntamente com este.

    Este ltimo motivo fica mais claro quando observamos como as interaesentre as fases deste modelo acabam acontecendo na prtica, como mostra a Figura 3.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    26

    Figura 3: Modelo de Cascata Duplo na prtica (WAZLAWICK, 2013, p. 30)

    Na Figura 3, pode-se perceber que a mudana de fases neste modelo no se

    limita fase adjacente, mostrando que a execuo de uma fase anterior no teria

    efeito, j que a fonte do problema pode estar duas fases atrs da atual. Por exemplo, a

    fase de teste poderia identificar um erro de entrada de dados que, mesmo executando

    novamente a fase de codificao, no seria resolvido, uma vez que o modelo de

    dados empregado no projeto no era o correto.

    Tendo definido o modelo a ser utilizado, o prximo passo realizar o

    levantamento dos requisitos do sistema. Para isso, algumas das maiores fontes de

    informaes desta fase so os sistemas relacionados ao que ser desenvolvido.

    3.2Sistemas Relacionados

    A maior motivao para a realizao deste trabalho a substituio do

    sistema atualmente utilizado na Fundao Uniselva, chamado Unisig, por outro que

    atenda s necessidades dos usurios. No entanto, o prprio Unisig ser utilizado

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    27

    como base para a criao do novo, j que este dever continuar oferecendo as

    funcionalidades que o sistema atual oferece hoje.

    O Unisig tem como objetivo fornecer informaes financeiras relacionadas execuo dos projetos da Uniselva para seus respectivos coordenadores. Ele foi

    criado para agilizar o processo de disponibilizao de tais dados, visto que antes dele

    os prprios funcionrios da Uniselva eram responsveis por coletar tais informaes

    no sistema Gerencial (utilizado internamente na Fundao) e repassar para os

    coordenadores atravs do telefone ou e-mail. Na Figura 4 representada a tela inicial

    do sistema atualmente utilizado.

    Figura 4: Pgina inicial do Unisig

    Alm do Unisig, este trabalho ter influncia do novo sistema interno da

    Uniselva que est sendo proposto juntamente com este e que tambm ir substituir o

    sistema atual. Ambos iro ser desenvolvidos em conjunto para garantir o

    compartilhamento correto das informaes entre eles, visto que as informaes

    disponibilizadas para o coordenador sero alimentadas por este novo sistema interno.

    Considerando ambos os sistemas correntes, a primeira atividade a ser

    executada para a criao do novo sistema a elaborao do documento CONOPS.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    28

    3.3CONOPS

    Como citado na seo 2.2, o documento CONOPS faz parte da fase inicial dodesenvolvimento do sistema e tem grande importncia na comunicao das

    necessidades identificadas e da soluo proposta para todos os envolvidos no projeto.

    Sua estrutura se assemelha bastante com a proposta do padro IEEE 1362-98, porm,

    as sees sobre o modo de operao e classe de usurio de ambos os sistemas em

    estudo (atual e proposto) foram mescladas por conterem informaes sobrepostas,

    alm do fato que estes sistemas no possurem estgios de funcionamento diferentes,

    totalizando 7 captulos, ao contrrio dos 9 citados no padro. Alm disso, foi

    adicionada uma pgina para a recomendao do documento por parte do chefe do

    setor responsvel pela elaborao do projeto e a aprovao do Diretor da Uniselva.

    Para a escrita deste documento, foram coletadas informaes de diferentes

    fontes, sendo duas delas os sistemas relacionados citados na seo anterior. Na

    descrio do Unisig, foram estudados documentos da Fundao Uniselva que citam

    como este sistema deveria funcionar, porm sem adotar nenhum dos padres ou

    metodologias de engenharia de software abordados neste trabalho. Por isso, tambm

    foram realizadas entrevistas com os envolvidos no projeto para conseguir traar um

    perfil deste sistema.

    Uma vez definido como o sistema atual funciona, aconteceram outras

    entrevistas com coordenadores de projetos, chefias dos setores de projeto e

    financeiro, e tambm com a diretoria, desta vez para identificar os problemas e listar

    os motivos de se criar um novo sistema. A partir da, foi elaborada a proposta citando

    os mesmos tpicos abordados na descrio do sistema atual, como sugere o padro

    seguido, com exceo das figuras da interface grfica, que foram substitudas por

    prottipos.

    3.4Prottipos

    Considerando que o CONOPS tem como objetivo mostrar a proposta do novo

    sistema de uma forma simples e compreensvel para o cliente, uma boa alternativa

    para alcan-lo criar prottipos da interface grfica. Uma tima ferramenta paracriar tais prottipos o Balsamiq (BALSAMIQ, 2014).

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    29

    Esta ferramenta foi escolhida por permitir uma rpida criao das telas do

    sistema utilizando desenhos que se assemelham com um prottipo criado com lpis e

    papel. No entanto, ela tambm possui componentes que correspondem aos elementosgrficos de programas de computador e pginas da Internet, o que d um visual

    parecido com o produto final, como pode ser visto na Figura 5.

    Figura 5: Ferramenta de Prototipao Balsamiq

    Depois de criados os prottipos das funcionalidades do novo sistema e

    anexados ao CONOPS, este j pode ser utilizado na prxima atividade da

    especificao do sistema, que a escrita do documento de requisitos.

    3.5Documento de Requisitos

    Utilizando os conceitos de elicitao de requisitos citados na seo 2.3 e o

    documento gerado na seo anterior, a escrita de um documento de requisitos servir

    para listar as necessidades e funcionalidades de um modo mais formal e prximo da

    linguagem do desenvolvedor, alm de ser usado como referncia para a realizao

    dos testes.

    Os requisitos levantados foram divididos entre duas categorias: funcionais eno-funcionais. Segundo Sommerville (2007, p. 119), requisitos funcionais so

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    30

    afirmaes sobre servios que o sistema deve fornecer, como deve reagir a entradas

    especficas e como se comportar em algumas situaes; os no-funcionais so

    restries sobre tais servios e funcionalidades, incluindo restries de tempo, doprocesso de desenvolvimento e de padres.

    Dessa forma, foi criado um documento contendo todos os requisitos do

    sistema, identificados com a sigla da categoria (RF para funcionais e RNF para no-

    funcionais) e um identificador numrico. Ainda, estes foram caracterizados de

    acordo com a prioridade (funcionais) e complexidade (no-funcionais).

    Portanto, com o CONOPS mostrando para o cliente e os usurios a proposta

    do novo sistema e o documento de requisitos reforando esta viso para odesenvolvedor, resta agora definir a estrutura atravs do documento de projeto.

    3.6Documento de Projeto

    Existem vrias maneiras de se criar o documento de projeto de um sistema,

    como pode ser percebido atravs do nmero de diagramas previstos pela UML na

    seo 2.4. Tendo em vista que o objetivo do sistema a ser desenvolvido por este

    trabalho de dar uma viso do andamento dos projetos para seus respectivos

    coordenadores, no possuindo entrada e nem gerao de dados, foram escolhidos

    dois diagramas para compor o documento de projeto: o diagrama de classes e o DER.

    Os dois diagramas so bem semelhantes, porm, possuem finalidades

    diferentes. O diagrama de classes possui todas as classes utilizadas no sistema e as

    relaes entre elas, dando uma viso completa da estrutura e das operaes do

    sistema. Algumas destas classes tambm estaro presentes no DER, mas

    representadas por entidades. Este diagrama tem como nfase a estrutura lgica dobanco de dados, mostrando como os dados manipulados pelo sistema sero

    armazenados.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    31

    Figura 6: Ferramenta brModelo

    A confeco dos diagramas foi realizada atravs de ferramentas especficas

    para cada tipo. Para o DER, a ferramenta utilizada foi o brModelo (BRMODELO,

    2014) em sua verso 2.0, desenvolvida por Carlos Henrique Cndido, que emprega a

    notao de Entidade-Relacionamento criada por Peter Chen (CHEN, 2014), a mesma

    citada na seo 2.4. Por outro lado, o Diagrama de Classes UML foi criado por meioda ferramenta chamada Dia, verso 0.97.2, criada por Alexander Larsson e mantida

    por Hans Breuer (DIA, 2014).

    Figura 7: Ferramenta Dia

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    32

    Estes diagramas foram escolhidos porque so suficientes e executam bem o

    papel de mostrar a fonte dos dados dos projetos e como eles sero representados no

    sistema, o que engloba todas as funcionalidades do sistema.Aps definida a estrutura, iniciam-se enfim as atividades de implementao

    do sistema.

    3.7Tecnologias de Desenvolvimento

    Com o intuito de transformar a estrutura idealizada no documento de projeto

    em cdigo funcional, diversas tecnologias de desenvolvimento so empregadas, almde ferramentas para controle do cdigo e acesso ao banco de dados.

    Primeiramente, ser utilizada a linguagem de programao C#, o ambiente de

    desenvolvimento integrado Visual Studio 2013 e o sistema de gerenciamento de

    banco de dados Microsoft SQL Server (SQL SERVER, 2014). Esta combinao foi

    escolhida por j ser utilizada em outros projetos da equipe de desenvolvimento,

    permitindo poupar tempo com aprendizado e aumentar a velocidade de produo de

    cdigo, uma vez que os desenvolvedores j dominam as tecnologias.Para fazer a ponte entre o cdigo e o banco de dados, foi escolhida uma

    biblioteca de mapeamento objeto-relacional chamada Nhibernate (NHIBERNATE,

    2014), pois permite que o desenvolvedor tenha uma viso do banco de dados

    utilizando classes e objetos do paradigma de programao orientada a objetos, alm

    de simplificar o acesso e as operaes realizadas para a persistncia dos dados.

    Ao trabalhar com a produo de cdigo, principalmente por mais de um

    desenvolvedor, importante utilizar uma ferramenta para manter os arquivos

    atualizados para cada um e tambm permitir o versionamento do sistema e a

    possibilidade de recuperar cdigos antigos. Para tanto, foi empregado o uso da

    tecnologia Subversion (SUBVERSION, 2014).

    Por meio dos materiais, mtodos e tcnicas descritos at aqui, aliados aos

    conceitos sobre engenharia de software mostrados no captulo 2, foi realizado um

    trabalho de anlise e projeto de um novo sistema para a Fundao Uniselva, chamado

    Portal do Coordenador. No prximo captulo so mostrados os resultados deste

    trabalho e como este foi executado para obt-los.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    33

    4.RESULTADOS

    Conciliando os conceitos de engenharia de software descritos no captulo 2

    com os materiais, mtodos e tcnicas citados no captulo 3, foi realizado um trabalho

    de anlise e projeto de um sistema para o acompanhamento de projetos da Fundao

    Uniselva por parte de seus respectivos coordenadores, aplicando as respectivas fases

    do modelo de processo de cascata dupla descrito nas sees 2.1.2 e 3.1. Os

    documentos gerados atravs deste trabalho, juntamente com uma definio do

    sistema proposto, so detalhados a seguir.

    4.1Documento CONOPS

    O primeiro documento gerado foi o CONOPS. Nele, foi realizado um estudo

    da situao do sistema Unisig atualmente em funcionamento, uma elaborao de

    justificativas e motivos para a criao de um novo sistema, e mostrada a proposta do

    Portal do Coordenador. Neste documento, o Portal do Coordenador definido como

    um sistema para fornecer uma viso mais completa da situao dos projetos para seus

    coordenadores do que o sistema Unisig fornece hoje.

    Um dos grandes motivos para a criao deste novo sistema a necessidade de

    acompanhar o andamento dos trabalhos atravs de um cronograma. Hoje, este

    cronograma j fornecido pelo coordenador no plano de trabalho do projeto, porm,

    no disponibilizado pelo Unisig para acompanhamento. Ainda sobre o cronograma,

    outra funcionalidade do sistema a de alertar o coordenador sobre prazos das

    atividades, com o intuito de prevenir o acmulo de recursos financeiros, que causa

    transtornos tanto para a Uniselva quanto para o rgo financeiro e tambm para o

    prprio coordenador.

    No captulo 4 do CONOPS, so apresentadas todas as mudanas propostas

    para o Portal do Coordenador em relao ao Unisig. So elas:

    Adicionar Cronograma do Projeto.

    Adicionar Notificaes e Avisos sobre o Cronograma.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    34

    Adicionar Detalhamento de Receitas e Adiantamentos.

    Reorganizar a Aparncia do Sistema.

    Incluir rea do Diretor e das chefias de Projeto e Financeiro.

    Integrar acesso com o Sistema de Boletos.

    Utilizar senha nica de acesso.

    Hospedar o sistema utilizando a infraestrutura da Uniselva.

    Otimizar aparncia para acesso atravs de dispositivos portteis.

    Dentre tais mudanas, algumas refletem os principais motivos para o

    desenvolvimento de um novo sistema e so descritas a seguir.Uma funcionalidade exclusiva do Portal do Coordenador o cronograma do

    projeto. Este ser disponibilizado por meio de uma tabela, da mesma forma que

    apresentado no plano de trabalho, e tambm em um grfico Gantt. O cronograma

    ser composto por metas, etapas/fases e itens, cada um com uma durao e previso

    oramentria. Ainda, ser possvel detalhar um item selecionado, mostrando como o

    oramento foi previsto para cada rubrica e o quanto j foi gasto at a data da

    consulta. Para os projetos que possuem o formato de curso, como especializaes,mestrados, doutorados, entre outros, o sistema ir disponibilizar uma verso do

    cronograma especfica para este caso, mostrando as atividades como disciplinas.

    No novo sistema, o extrato do projeto incluir o detalhamento de receitas e

    adiantamentos, o que no feito no sistema atual, como mostra a Figura 8.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    35

    Figura 8: Extrato de Projeto no Unisig

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    36

    As receitas sero divididas entre os investimentos do rgo financiador e as

    faturas e bloquetos recebidos, enquanto os adiantamentos sero listados por completo

    at a data da consulta, de acordo com a Figura 9.

    Figura 9: Prottipo do novo Extrato do Projeto

    Outra incluso a da rea do Diretor e dos Chefes de Financeiro e Projetos da

    Uniselva. Nesta rea, estes usurios tero acesso a todos os projetos da mesma forma

    que os coordenadores acessam. Alm disso, esta pgina tambm fornece estatsticas

    dos totais de projetos em nmeros e grficos, possibilitando uma viso estratgica da

    situao dos projetos da Uniselva.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    37

    Uma das mudanas de usabilidade ser a seleo do projeto, que no Unisig

    feita toda vez em que se seleciona uma funcionalidade, como extrato do projeto ou

    saldo oramentrio. No Portal do Coordenador, esta seleo ser feita logo aps oacesso, para que todas as funcionalidades do sistema possam ser acessadas no escopo

    do projeto selecionado.

    A descrio e as imagens de todas as funcionalidades do Unisig e os

    prottipos do Portal do Coordenador encontram-se no Apndice I.

    4.2Documento de Requisitos

    Por meio do documento CONOPS, foi realizado uma elicitao de requisitos

    e gerado um documento de requisitos (ver Apndice II). J que o CONOPS j

    executa a funo de passar para o cliente a ideia do sistema proposto, o documento

    de requisitos foi elaborado neste caso para formalizar as necessidades identificadas

    no CONOPS e servir como referncia para o desenvolvedor na hora de implementar

    e testar o sistema.

    No documento de requisitos, foi includa a descrio geral do sistemaproposto apresentada no CONOPS para definir o escopo do documento. A partir da,

    foram listados os requisitos funcionais e no-funcionais, identificados com um sigla

    (RF para os funcionais e RNF para os no-funcionais) seguida de um nmero

    incremental e a classificao (P para prioridade e C para complexidade). Alguns

    deles so:

    [RF04] (P: Alta) O sistema deve, aps o login do diretor ou chefe,mostrar todos os projetos da Uniselva.

    [RF05] (P: Alta) O sistema deve, junto com os projetos, mostrar os

    totais de projetos por situao e tipo.

    [RF08] (P: Mdia) O sistema deve permitir o chefe dar acesso ao

    sistema para um coordenador.

    [RF14] (P: Alta) O resumo financeiro deve conter os totais de receita,

    despesas, faturas, adiantamentos, proviso e saldo para a data daconsulta.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    38

    [RF19] (P: Alta) O sistema deve permitir a visualizao do

    cronograma do projeto.

    [RNF02] (C: Baixa) A aba do resumo financeiro na pgina principaldeve se expandir mediante interao com o mouse.

    [RNF05] (C: Mdia) Os grficos do sistema devem ser mostrados

    utilizando uma animao crescente.

    Ao todo, foram elicitados 53 requisitos, sendo 42 funcionais e 11 no-

    funcionais. Dos requisitos funcionais, 20 deles possuem prioridade Alta, enquanto 15

    so de prioridade Mdia e 7 de Baixa. Para os no-funcionais, so 3 requisitos deAlta, 2 de Mdia e 6 de Baixa complexidade.

    Com base nestes requisitos, a fase de desenvolvimento contar com todas as

    informaes necessrias para permitir a implementao das funcionalidades,

    incluindo a ordem em que estas devem ser implementadas. Alm disso, esta fase

    tambm ter o apoio do documento de projeto, descrito a seguir.

    4.3Documento de Projeto

    Da mesma forma que o documento de requisitos, o documento de projeto tem

    como pblico-alvo a equipe de desenvolvimento do Portal do Coordenador, porm,

    trata de como os requisitos sero implementados no sistema por meio dos diagramas

    de Entidade-Relacionamento e de Classes, confeccionados utilizando as ferramentas

    brModelo e Dia, descritos na seo 3.6.

    Partindo da finalidade de definir a estrutura do banco de dados do sistema, oDER mostrado na Figura 10 consiste numa viso que o Portal do Coordenador ter

    das informaes do sistema interno da Fundao Uniselva, j que ambos iro

    compartilhar tais dados. Ou seja, mesmo utilizando a mesma base de dados

    fisicamente, o Portal do Coordenador ter acesso apenas s informaes contidas

    neste diagrama.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    39

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

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    40

    Uma vez definida a estrutura do banco de dados, o prximo passo foi o de

    estruturar o software. Para isso, foi criado o Diagrama de Classes no modelo UML

    para possibilitar ao desenvolvedor uma outra viso, agora de como as informaescontidas no DER sero representadas no sistema, como mostra a Figura 11. O

    documento de projeto pode ser encontrado na ntegra no Apndice III.

    Figura 11: Diagrama de Classes para representar o comportamento do novo sistema

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    41

    Como citado anteriormente, o modelo de processo de cascata dupla foi

    utilizado para guiar as atividades descritas neste relatrio. No entanto, mesmo

    seguindo um modelo, algumas dificuldades e empecilhos foram encontrados durantea elaborao dos documentos. Tais transtornos so descritos no prximo captulo.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    42

    5.DIFICULDADES ENCONTRADAS

    Durante a execuo das tarefas descritas neste relatrio, foram encontradas

    algumas dificuldades e obstculos que prejudicaram seu andamento. A principal

    dificuldade foi a de coletar informaes sobre as necessidades dos coordenadores de

    projetos, que geralmente um dos maiores problemas da engenharia de software. Os

    motivos relatados variam da indisponibilidade para reunies at o desconhecimento

    do prprio sistema Unisig atualmente em funcionamento.

    Outra dificuldade foi identificada durante o estudo do sistema Unisig. Este

    sistema no foi desenvolvido seguindo as prticas comuns de engenharia de

    software, como foi mostrado neste trabalho. Desta forma, existem poucos

    documentos que descrevem seu funcionamento, ainda de forma incompleta. Alm

    disso, os prprios envolvidos em seu desenvolvimento e utilizao no souberam

    descrever algumas funcionalidades presentes no sistema, j que estas caram em

    desuso e no possuem influncia no objetivo do sistema.

    Junto com o desenvolvimento do Portal do Coordenador, segue em paralelo a

    criao do novo sistema interno da Fundao Uniselva. Como este ser a fonte das

    informaes disponibilizadas pelo Portal do Coordenador, algumas decises,

    principalmente na fase de projeto do sistema, foram afetadas no sentido de

    dependerem de como o sistema interno ser implementado.

    Um obstculo, tambm bastante comum no desenvolvimento de software, foi

    o tempo. Como mostrado neste relatrio, o processo de coletar informaes, elicitar

    requisitos, escrever documentos e projetar um novo sistema complexo e demanda

    bastante tempo, especialmente quando afetado pelas dificuldades descritas at aqui.Mesmo tendo atingido os objetivos deste trabalho, o desejo era ter tambm a fase de

    implementao concluda at o presente momento.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    43

    6.CONCLUSES

    Tento em vista o objetivo da Universidade Federal de Mato Grosso de

    promover o ensino, a pesquisa e a extenso atravs de sua comunidade acadmica, a

    Fundao Uniselva exerce um papel fundamental no apoio aos projetos e seus

    coordenadores que buscam alcanar tal objetivo. Para isso, a Uniselva conta com

    uma equipe de funcionrios dispostos a auxiliar o andamento dos projetos nas reas

    relacionadas gerncia dos recursos financeiros, e tambm com o sistema Unisig,

    encarregado de mostrar tal andamento de forma detalhada para os coordenadores.

    Entretanto, este sistema no est suprindo todas as necessidades dos seus

    usurios, principalmente por no permitir a visualizao de algumas informaes

    financeiras e por no disponibilizar o cronograma do projeto. Alm disso, o sistema

    precisa notificar os coordenadores quanto a prazos e ocorrncias relacionadas ao

    cronograma, para evitar transtornos.

    Sendo assim, este trabalho teve como objetivo aplicar os conceitos de

    engenharia de software para projetar um novo sistema, chamado Portal do

    Coordenador, que ter a misso de melhorar a viso que o coordenador tem sobre o

    andamento de seus projetos, atendendo s necessidades citadas acima.

    Por meio do documento CONOPS, foi realizado um estudo da situao

    atual do sistema Unisig, elaborado um conjunto de motivos e justificativas para a

    criao de um novo sistema, e criada uma descrio de como este dever funcionar,

    sempre utilizando uma linguagem apropriada ao cliente. A partir deste documento,

    foram escritos documentos de requisitos e de projeto que mostram o funcionamento

    do sistema atravs da viso do desenvolvedor.Dados os resultados obtidos neste trabalho, os prximos passos sero a

    implementao e validao do sistema. Na implementao, as tecnologias citadas na

    seo 3.7 sero utilizadas para traduzir os requisitos identificados em funcionalidades

    do sistema, enquanto a validao ir garantir que o produto gerado executa suas

    funes corretamente e atendem s expectativas dos coordenadores. Aps estas

    etapas, o Portal do Coordenador estar pronto para ser implantado e iniciar suas

    operaes.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    44

    7.REFERNCIAS BIBLIOGRFICAS

    BALSAMIQ. Balsamiq Mockups. Disponvel por www em

    http://balsamiq.com/products/mockups/ (acesso em 10 de fevereiro de 2014).

    BRMODELO. Sobre a Ferramenta. Disponvel por www em

    http://sis4.com/brModelo/ (acesso em 25 de fevereiro de 2014).

    CHEN. Dr. Peter Chen. Disponvel por www em

    http://www.csc.lsu.edu/~chen/ (acesso em 25 de fevereiro de 2014).

    DIA. Development. Disponvel por www em

    https://wiki.gnome.org/Apps/Dia/Development (acesso em 25 de fevereiro de 2014).

    ELMASRI, Ramez. Fundamentals of database systems. 4. ed. Boston:

    Pearson Edication, 2004.

    IEEE. 1362-1998 - IEEE Guide for Information Technology - System

    Definition - Concept of Operations (ConOps) Document. IEEE Computer Society,

    1998.

    NHIBERNATE.NHibernate Reference Documentation. Disponvel por www

    em http://nhforge.org/doc/nh/en/index.html (acesso em 10 de fevereiro de 2014).

    PRESSMAN, Roger S. Software engineering: a practitioners approach. 7.

    ed. Nova York: McGraw-Hill, 2010.

    PROJECT MANAGEMENT INSTITUTE. Sobre o PMI. Disponvel por

    www em http://brasil.pmi.org/brazil/AboutUS.aspx (acesso em 22 de janeiro de

    2014).

    SOMMERVILLE, Ian. Engenharia de Software. 8. ed. So Paulo: Pearson

    Education do Brasil, 2007.SQL SERVER. About SQL Server. Disponvel por www em

    http://www.microsoft.com/en-us/sqlserver/product-info.aspx (acesso em 10 de

    fevereiro de 2014).

    SUBVERSION. About Subversion. Disponvel por www em

    http://subversion.apache.org/ (acesso em 10 de fevereiro de 2014).

    UFMT. Institucional. Disponvel por www em

    http://www.ufmt.br/ufmt/site/secao/index/Cuiaba/1 (acesso em 7 de fevereiro de2014).

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    45

    UNISELVA. Estatuto Uniselva. Disponvel por www em

    http://www.fundacaouniselva.org.br/sistema/downloads/estatuto_uniselva.pdf

    (acesso em 7 de fevereiro de 2014).WAZLAWICK, Raul Sidnei. Engenharia de Software: conceitos e prticas.

    Rio de Janeiro: Elsevier, 2013.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    46

    Apndice I: Documento CONOPS

    PORTAL DO COORDENADOR

    Documento de Conceito Operacional(CONOPS IEEE 1362-98)

    Verso 1.2

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    i

    Histrico de Reviso

    Data Verso Descrio Autor

    02/01/2014 0.1 Criao do documento Lucas Pinto e Silva

    13/01/2014 0.2 Adio das sugestes do Diretor Lucas Pinto e Silva

    27/01/2014 1.0 Correo de informaes e formatao Lucas Pinto e Silva

    06/02/2014 1.1 Adio da funcionalidade de envio de

    relatrios na seo de no includas

    Lucas Pinto e Silva

    14/02/2014 1.2 Adio do Cronograma de Cursos Lucas Pinto e Silva

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    ii

    CONCEITO OPERACIONAL (CONOPS)Aprovao do Documento

    Senhor Diretor,

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

    __________________________________Alberto Maral Figueiredo Tavares JuniorCoordenador do NPD da Uniselva

    _____________________Data

    Aprovado,

    __________________________________Cristiano MacielDiretor Geral da Uniselva

    _____________________Data

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    iii

    SumrioHistrico de Reviso ....................................................................................................................... i

    Aprovao do Documento ............................................................................................................ ii

    Lista de Figuras ..............................................................................................................................iv

    1. Escopo ....................................................................................................................................... 1

    1.1. Identificao ....................................................................................................................... 1

    1.2. Viso Geral do Documento ................................................................................................ 1

    1.3. Viso Geral do Sistema ....................................................................................................... 1

    2. Referncias ................................................................................................................................ 2

    3. Sistema Atual (Unisig) ............................................................................................................... 2

    3.1. Histrico, Objetivos e Escopo ............................................................................................. 2

    3.2. Polticas e Restries Operacionais .................................................................................... 3

    3.3. Descrio do Sistema Atual ................................................................................................ 3

    3.4. Modos de Operao por Usurio ..................................................................................... 16

    3.6. Ambiente de Apoio .......................................................................................................... 164. Justificativa e Natureza das Mudanas ................................................................................... 17

    4.1. Justificativa das Mudanas ............................................................................................... 17

    4.2. Descrio das Mudanas propostas ................................................................................. 17

    4.3. Prioridades entre as Mudanas ........................................................................................ 19

    4.4. Mudanas Vlidas mas no Includas ............................................................................... 20

    5. Conceitos do Sistema Proposto (Portal do Coordenador) ...................................................... 20

    5.1. Objetivos e Escopo ........................................................................................................... 21

    5.2. Polticas Operacionais e Restries .................................................................................. 21

    5.3. Descrio do Sistema Proposto ........................................................................................ 21

    5.4. Modos de Operao por Usurio ..................................................................................... 32

    5.6. Ambiente de Apoio .......................................................................................................... 32

    6. Resumo dos Impactos ............................................................................................................. 33

    7. Anlise do Sistema Proposto ................................................................................................... 33

    7.1. Resumo das Melhorias ..................................................................................................... 34

    7.2. Desvantagens e Limitaes .............................................................................................. 34

    7.3. Alternativas e Escolhas consideradas ............................................................................... 34

    http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/
  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    iv

    Lista de Figuras

    Figura 1: Pgina inicial do Unisig ................................................................................................... 3

    Figura 2: Pgina inicial do Extrato de Projetos .............................................................................. 4

    Figura 3: Janela de seleo de meta e perodo ............................................................................. 5

    Figura 4: Pgina de Extrato do Projeto.......................................................................................... 6

    Figura 5: Pgina de Saldo Oramentrio ....................................................................................... 7

    Figura 6: Resumo Financeiro do projeto ....................................................................................... 8

    Figura 7: Pgina de Adiantamentos .............................................................................................. 9Figura 8: Relao de Faturas/Bloquetos ..................................................................................... 10

    Figura 9: Informaes do Projeto ................................................................................................ 11

    Figura 10: rea Administrativa .................................................................................................... 12

    Figura 11: Cadastro de coordenador........................................................................................... 13

    Figura 12: Liberao de acesso a projetos .................................................................................. 14

    Figura 13: Envio de pacote de atualizao .................................................................................. 15

    Figura 14: Seleo de Projeto ...................................................................................................... 22

    Figura 15: Pgina do Diretor/Chefe ............................................................................................ 23

    Figura 16: Pgina Principal do sistema ........................................................................................ 24

    Figura 17: Informaes do Projeto .............................................................................................. 25Figura 18: Cronograma do Projeto .............................................................................................. 26

    Figura 19: Detalhes do Cronograma ........................................................................................... 27

    Figura 20: Cronograma de Curso ................................................................................................. 28

    Figura 21: Extrato do Projeto ...................................................................................................... 29

    Figura 22: Saldo Oramentrio ................................................................................................... 30

    Figura 23: Faturas/Bloquetos ...................................................................................................... 31

    http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/http://0.0.0.0/
  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    1

    1. Escopo

    O documento de Conceito Operacional (CONOPS) do Portal do Coordenador descreve

    as caractersticas desejadas do sistema atravs da viso do usurio. As sees abaixo

    identificam o sistema Portal do Coordenador e fornecem uma viso geral do documento e do

    sistema proposto.

    1.1. Identificao

    O sistema Portal do Coordenador, cuja anlise e desenvolvimento se do no ano de

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

    um sistema para a visualizao de informaes e acompanhamento dos projetos da Uniselva

    por parte dos coordenadores.

    1.2. Viso Geral do Documento

    Este documento tem como objetivo mostrar as caractersticas quantitativas e qualitativas

    do sistema em alto nvel para usurios, clientes, desenvolvedores e outras partes interessadas.

    Adaptado do documento de padres IEEE 1362-98, as ideias expressadas neste CONOPS para

    o desenvolvimento de um portal para o coordenador so resultado de uma anlise das

    dificuldades e necessidades relatadas pelos prprios coordenadores e pelos funcionrios da

    Uniselva, que no so supridas pelo sistema atual (Unisig).

    Seo 1 descreve o intuito deste CONOPS e ao sistema que ele se aplica Seo 2 lista as referncias utilizadas na construo deste documento Seo 3 descreve a situao atual do sistema em funcionamento (Unisig) Seo 4 discute motivos e justificativas para a criao de um novo sistema Seo 5 fornece informaes sobre o novo sistema proposto (Portal do

    Coordenador) Seo 6 lista os impactos operacionais, organizacionais e os que podem

    ocorrer durante o desenvolvimento do sistema proposto Seo 7 faz uma anlise dos benefcios, limitaes, vantagens, desvantagens

    e alternativas do sistema proposto1.3. Viso Geral do Sistema

    O Portal do Coordenador uma proposta de sistema para fornecer uma viso mais

    completa da situao dos projetos para seus coordenadores do que o sistema atual (Unisig)

    fornece. Um grande motivo possibilitar o coordenador acompanhar o andamento do projeto,principalmente atravs de um cronograma, que criado a partir do plano de trabalho do projeto.

  • 5/21/2018 Relatorio Final de Est gio Supervisionado - Lucas Pinto e Silva.pdf - slidepdf....

    http:///reader/full/relatorio-final-de-estagio-supervisionado-lucas-pinto-e-s

    Avenida Fernando Corra da Costa 2367Campus da UFMT - Bloco da Grfica

    CEP: 78.060-900- Cuiab/MTCNPJ: 04.845.150/0001-57Telefone: 0xx65 3661-3900

    Fax: 0xx65 3628-1220www.fundacaouniselva.org.br

    2

    Alm do cronograma, outra grande finalidade do sistema informar e alertar o

    coordenador sobre prazos no sentido de prevenir o acmulo de recursos, que causa transtornos

    tanto para a Uniselva quanto para o coordenador e o rgo financiador do projeto. Com esta

    funcionalidade, o coordenador poder gerenciar os recursos do projeto de uma maneira mais

    eficiente e seguir o cronograma como planejado.

    Este novo sistema ir trabalhar em conjunto com um outro sistema em desenvolvimento

    que ir substituir o sistema Gerencial utilizado internamente na Uniselva, compartilhando o

    mesmo banco de dados e seguindo as mesmas normas e regimentos das informaes utilizadas.

    2. Referncias

    Os padres e guias utilizados na preparao deste documento esto listados abaixo.

    IEEE Computer Society. IEEE Std 1362-1998, IEEE Guide for Information Technology-

    System Definition-Concept of Operations (ConOps) Document, 19 de maro de 1998

    American Systems Corporation. Eletronic Records Archives Concept of Operations

    (CONOPS v4.0), 27 de julho de 2004

    Os seguintes documentos da Uniselva foram consultados para a elaborao deste documento.

    Coordenao Financeira, Fundao Uniselva. Projeto Espao do Coordenador

    Ilza Gervazoni, Fundao Uniselva. Sistema de Gesto, 23 de fevereiro de 2009

    3. Sistema Atual (Unisig)

    Esta seo trata sobre o Sistema Integrado de Gesto (Unisig), atualmente em

    funcionamento. As subsees seguintes descrevem o histrico, objetivos e escopo do sistema

    atual, suas polticas operacionais, restries, funcionamento, modos de operao, classes de

    usurio e ambiente de apoio.

    3.1. Histrico, Objetivos e Escopo

    O sistema Unisig surgiu da necessidade da Fundao Uniselva de disponibilizar de forma

    rpida e de fcil entendimento as informaes financeiras e detalhes da execuo dos projetos

    aos coordenadores. Antes de sua implantao, os coordenadores solicitavam informaes

    financeiras e oramentrias e as recebiam de forma impressa ou via e-mail. Isso gerava

    transtornos tanto para a Uniselva quanto para o coordenador, uma vez que funcionrios eram

    ocupados de atender s solicitaes dos coordenadores, j que estes no tinham acesso fcil e

    rpido s informaes de seus projetos.

    Tendo em vista estes problemas, o Unisig foi desenvolvido com o objetivo de possibilitar

    o acompanhamento da situao financeira dos projetos por parte de seus coordenadores, tendo

  • 5/21/2018 Relatorio Final de Est gio Supervision