UNIVERSIDADE REGIONAL DO NOROESTE DO
ESTADO DO RIO GRANDE DO SUL – UNIJUI
RICARDO WIESNER
MODELAGEM E CONSTRUÇÃO DE SOFTWARE PARA GESTÃO DE
PROJETOS
Santa Rosa - RS, 2014
RICARDO WIESNER
MODELAGEM E CONSTRUÇÃO DE SOFTWARE PARA GESTÃO DE
PROJETOS
Trabalho de Conclusão de Curso apresentada ao Curso de Ciências das Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUI, como requisito à obtenção do título de Bacharelado em Ciências da Computação.
Orientador: Professor Doutor Gerson Battisti
Santa Rosa - RS, 2014
MODELAGEM E CONSTRUÇÃO DE SOFTWARE PARA GESTÃO DE PROJETOS
RICARDO WIESNER
Trabalho de Conclusão de Curso apresentada ao Curso de Ciências das Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUI, como requisito à obtenção do título de Bacharelado em Ciências da Computação.
__________________________________________ Orientador: Prof. (Doutor) GERSON BATTISTI
BANCA EXAMINADORA
__________________________________________ Prof. (Mrs.) ROMÁRIO LOPES ALCÂNTARA
Santa Rosa - RS, 2014
AGRADECIMENTOS
Agradeço, primeiramente a Deus, pelas oportunidades que me foram oferecidas, por ter conhecido diversas pessoas, lugares.
Não posso deixar de agradecer a toda minha família, a minha irmã Karine Wiesner, especialmente aos meus pais, Egon Wiesner e Aristela Schroder Wiesner, por ter dado apoio e incentivo para mais essa conquista.
Também não poderia deixar de agradecer a uma pessoa muito especial, que sempre esteve do meu lado, apoiando e incentivando e muitas vezes me ajudando com algumas tarefas da graduação principalmente nas disciplinas que envolviam matemática. Muito obrigado pelo companheirismo e apoio minha esposa Arlete Kelm Wiesner.
Além dos familiares, agradeço muito aos professores que passaram os seus ensinamentos durante a graduação, de modo especial ao professor orientador Doutor
Gerson Battisti pela sua orientação, apoio, incentivo porque através dele, despertou em
mim o interesse e a persistência para superar desafios enfrentados durante a graduação e na vida profissional.
RESUMO
Atualmente em nosso cotidiano temos vários objetivos a serem alcançados todos em um determinado tempo. Para isso podemos utilizar conceitos de modelagem de projeto para organizar os passos a ser seguido para atingir o objetivo. Para a organização dos objetivos e os passos a serem precisamos utilizar algum mecanismo para organizarmos as atividades. Com este pressuposto trabalho visa realizar a modelagem de um software para auxiliar na organização das tarefas e objetivos a serem atingidos com o conceito de modelagem de projeto.
Para construção do software para modelagem utilizaremos como referência dos conceitos do instituto PMI (Project Management Institute) que consiste em uma associação a nível internacional de profissionais de gestão de projeto. A instituição disponibiliza um guia para modelagem e gestão de projeto conhecido como PMBOK no qual reúne um conjunto de normas e conceitos a serem seguidos para modelagem de projetos servindo como referência para os gestores de projetos.
ABSTRACT
Currently in our daily life we have several objectives to be achieved all at a given time. For this we can use modeling concepts of design to organize the steps to be followed to achieve the goal. For the organization of goals and steps need to be using some mechanism to organize activities. With this assumption work aims to conduct modeling software to help organize tasks and goals to be achieved with the concept of a modeling project.
To build the software will use as reference for modeling concepts of the institute PMI (Project Management Institute) consisting of an association of professional international project management. The institution provides a guide for modeling and managing project known as the PMBOK which meets a set of standards and concepts to be followed for modeling projects serving as a reference for project managers.
LISTA DE FIGURAS
FIGURA 1 REPRESENTAÇÃO DOS CONCEITOS DE PROJETO, SUBPROJETO E PORTFÓLIO ... 14
FIGURA 2 REPRESENTAÇÃO DO GRÁFICO DE GANTT ... 24
FIGURA 3 VISÃO GERAL DO SOFTWARE ... 26
FIGURA 4 DIAGRAMA ENTIDADE RELACIONAL ... 31
FIGURA 5 CASO DE USO CADASTRO DE USUÁRIO ... 32
FIGURA 6 CASO DE USO CADASTRO DE PROJETO ... 33
FIGURA 7 CASO DE USO DE CADASTRO DE RECURSO ... 34
FIGURA 8 CASO DE USO -CADASTRO DE ATIVIDADE ... 35
FIGURA 9 CASO DE USO -CADASTRO DE PRECEDÊNCIA ... 35
FIGURA 10 CASO DE USO -CADASTRO DE PARTICIPANTE NA ATIVIDADE ... 36
FIGURA 11 CASO DE USO -ALOCAÇÃO DE RECURSO ... 37
FIGURA 12 CASO DE USO -REMOVER RECURSO DA ATIVIDADE ... 37
FIGURA 13 CASO DE USO -REMOVER ATIVIDADE ... 38
FIGURA 14 CASO DE USO -REMOVER PROJETO ... 38
FIGURA 15 CASO DE USO -CONTROLE DE TEMPO ... 39
FIGURA 16 CASO DE USO -AJUSTE DE TEMPO GASTO ... 40
FIGURA 17 CASO DE USO -COMENTÁRIO/ANOTAÇÃO DA ATIVIDADE ... 40
FIGURA 18 FUNCIONAMENTO DO CONTAINER ... 46
FIGURA 19 TELA DE ACESSO AO SISTEMA... 47
FIGURA 20 TELA INICIAL DO SISTEMA ... 48
FIGURA 21 TELA INFORMAÇÕES DA ATIVIDADE ... 49
FIGURA 22 TELA INFORMAÇÃO DO PROJETO ... 50
FIGURA 23 TELA CADASTRO PROJETO ... 51
FIGURA 24 TELA CADASTRO DE ATIVIDADE... 52
FIGURA 25 TELA DE CADASTRO DE RECURSO ... 53
FIGURA 26 TELA DE CADASTRO DE USUÁRIO ... 53
FIGURA 27 TELA INICIAL DO SISTEMA ... 62
FIGURA 28 TELA DE CADASTRO DE PROJETO ... 62
FIGURA 29 TELA CADASTRO DE ATIVIDADE... 63
FIGURA 30 TELA DE CADASTRO DE USUÁRIO ... 63
LISTA DE TABELAS
TABELA 1 TABELA DE USUÁRIO ... 56
TABELA 2 TABELA USUÁRIO PASTA ... 56
TABELA 3 TABELA COMENTÁRIO PASTA ... 57
TABELA 4 TABELA PROJETO ... 57
TABELA 5 TABELA PASTA ATIVIDADE ... 58
TABELA 6 TABELA ATIVIDADE ... 58
TABELA 7 TABELA ATIVIDADE ... 59
TABELA 8 TABELA ATIVIDADE RECURSO ... 59
TABELA 9 TABELA RECURSO ... 59
TABELA 10 TABELA USUÁRIO ATIVIDADE CUSTO ... 60
TABELA 11 TABELA COMENTÁRIO ATIVIDADE ... 60
SUMÁRIO
1. INTRODUÇÃO ... 11
2. MODELAGEM DE PROJETOS ... 13
2.1 Definições de modelagem de Projeto ... 13
2.2 Ciclo de vida do projeto ... 15
2.3 Metodologia de gestão de drojetos ... 16
2.4 Áreas de conhecimento do gerenciamento de projetos ... 17
2.4.1 Gerenciamento de integração ... 18
2.4.2 Gerenciamento de escopo ... 19
2.4.3 Gerenciamento de tempo ... 19
2.4.4 Gerenciamento de custo ... 20
2.4.5 Gerenciamento de qualidade ... 20
2.4.6 Gerenciamento de recursos humanos ... 21
2.4.7 Gerenciamento das comunicações ... 22
2.4.8 Gerenciamento de riscos ... 22
2.4.9 Gerenciamento de suprimentos ... 23
3 FERRAMENTAS PARA GESTÃO DE PROJETOS ... 24
3.1 Desenvolvimento do software ... 25
3.2 Levantamento e análise de requisitos ... 26
3.3 Requisitos do software ... 26
3.3.1 Requisitos quanto os projetos ... 26
3.3.2 Requisitos quanto aos usuários ... 28
3.3.3 Requisitos quanto aos recursos ... 28
3.3.3 Requisitos quanto as atividades ... 29
3.5. Estrutura banco de dados ... 30
3.6 Projeto lógico das tabelas do sistema ... 31
3.7 Casos de uso ... 32
3.7.1 Cadastros de usuário ... 32
3.7.2 Cadastros de projeto ... 33
3.7.3 Cadastros de recurso ... 34
3.7.4 Cadastros de atividade ... 35
3.7.5 Precedências das atividades ... 35
3.7.7 Alocação de recursos nas atividades... 37
3.7.8 Remover recurso da atividade ... 37
3.7.9 Remover atividade ... 38
3.7.10 Remover projeto ... 38
3.7.11 Controles do tempo gasto na atividade pelo usuário ... 39
3.7.12 Ajustar tempo gasto na atividade ... 40
3.7.13 Comentários/anotações da atividade... 40 4 DESENVOLVIMENTO DO SOFTWARE ... 42 4.1 Tecnologia utilizadas ... 42 4.1.1 Linguagem Java ... 42 4.1.2 Framework Hibernate ... 43 4.1.3 Framework Vraptor ... 44
4.1.4 Framework Twiter Boostrap ... 45
4.1.5 Web container ... 46
4.2 Protótipos das telas do sistema ... 47
4.2.1 Acesso ao sistema ... 47
4.2.2 Tela inicial do sistema ... 47
4.2.3 Tela de informações da atividade ... 48
4.2.4 Tela de informações do projeto ... 49
4.2.5 Tela de cadastro de projeto ... 50
4.2.6 Tela de cadastro de atividade ... 51
4.2.7 Tela de cadastro de recurso ... 52
4.2.8 Tela de cadastro de usuário ... 53
5. CONSIDERAÇÕES FINAIS ... 54
6. REFERÊNCIAS ... 55
ANEXO A – PROJETO LÓGICO DAS TABELAS DO SISTEMA ... 56
1. INTRODUÇÃO
Em algum momento você já teve uma ideia para criar ou recriar um produto, serviço ou uma linha de trabalho de pesquisa, e chegou a se perguntar em como dar uma forma, como coloca-los em prática, para atingir o seu objetivo. Nesse contexto utilizamos duas palavras chaves, uma delas é a modelagem1 e a outra é projeto2. Juntando as duas palavras temos a Modelagem de Projetos que consiste em um conjunto de técnicas e procedimentos para termos mais clareza sobre o projeto de tal forma que seja possível dizer o tempo, o custo e o risco, entre outras. Isso tudo, para ter clareza que o projeto que vai ser feito seja viável e que tenha retorno, evitando desperdício de dinheiro e tempo.
Ao termos o objetivo do projeto claro é necessário definir um conjunto de passos e tarefas seguindo uma sequência a fim de atingirmos os objetivos. As tarefas podem ser realizadas sequencialmente ou paralelamente, pode ter tarefas dependente umas das outras e a quantidade de passos e tarefas depende do estudo do projeto. Para definirmos a sequência de passos, o que cada participante vai fazer dentro do contexto do projeto, para ajudar na organização e monitoramento temos uma ampla gama de softwares 3que auxiliam nessa fase. Além disso, realizam cálculos de custos do projeto envolvendo pessoas e recursos. Geralmente para auxiliar na gerencia e visualização do fluxo do projeto é utilizado o diagrama de Gantt.
Utilizar um software para modelar um projeto pode trazer inúmeros benefícios como ter um monitoramento preciso do andamento, otimizar o tempo de construção, ter o histórico das ocorrências, entre outros. Porém, apesar dessa ampla gama de softwares com interfaces coloridas e várias opções de configurações, acabam que os gerentes de projetos, tem grande dificuldade em transcrever o seu contexto do projeto para o software.
1 Modelagem é a ordenação lógica de projetos, a exposição fundamentada do que pretendemos ver realizado
(Thiry-Cherques, 2010, p. 20).
2 Projeto é definido como uma organização transitória, que compreende uma sequência de atividades dirigidas à
geração de um produto ou serviço singular em um tempo dado (Thiry-Cherques, 2010, p. 21).
3 Software é uma sequência de instruções escritas para serem interpretadas por um computador com o objetivo de
Utilizar software para gestão de projetos proporciona inúmeros benéficos, para isto, utilizaremos como referência na modelagem e construção do software o PMBOK que é um guia que contém um conjunto de diretrizes, normas técnicas e conceitos para modelagem e gestão de projetos mantido pelo instituto PMI. O PMI é um instituto a nível mundial formado por um conjunto com mais de 700.000 gestores de projetos do mundo inteiro com objetivo de documentar e aprimorar metodologias para a gestão de projetos (PMBOOK, 2004, p. 10).
Este trabalho propõem trazer e aproximar os conceitos de gestão projetos aos acadêmicos, gestores e a quem tenha interesse além de construir modelagem de software para gestão de projeto, baseando-se no guia PMBOK desenvolvido pelo instituto PMI.
Este trabalho está organizado como segue. O capítulo 1 apresenta introdução. O capítulo 2 contempla a revisão bibliográfica. O capítulo 3 descreve a modelagem do sistema e no capítulo 4 as considerações finais juntamente com propostas para continuidade na construção e aprimoramento do software para gestão de projeto.
2. MODELAGEM DE PROJETOS
Nesta sessão contempla a revisão bibliográfica, descrevendo detalhadamente o conceito de modelagem e gestão de projetos, utilizando o PMBOOK como uma das principais referências, além de outros autores renomados na área de gestão de projetos.
2.1 Definições de modelagem de projeto
O tempo não espera por ninguém, e em nenhum outro lugar isso é tão real quanto no gerenciamento de projeto (Jim MacTnyre). Atualmente vivemos em constante evolução da
sociedade e temos que estar em plena aprendizagem, que acaba aumentando de forma natural a competitividade entre os seres que habitam na sociedade. Para conseguirmos ser competidos e ajudar no crescimento da sociedade acabamos desenvolvendo técnicas para resolver alguma situação de forma rápida eficaz e tendo alta produtividade. Para isso podemos utilizar a modelagem de projeto.
O termo "modelagem de projeto" é composto por duas palavras importantíssimas uma delas é a modelagem, que para Thiry-Cherques (2010, p. 20) é a ordenação lógica de projetos, a exposição fundamentada do que pretendemos ver realizado. A outra é projeto que segundo Thiry-Cherques (2010, p. 21), é como uma organização transitória, que compreende uma sequência de atividades dirigidas à geração de um produto ou serviço singular em um tempo dado.
Segundo Vargas (2005, p. 7), projeto é um empreendimento não repetitivo caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.
A prática de modelagem tem grande importância para atingir os objetivos de forma organizada. Além disso, a prática de modelagem de projetos pode ser aplicada em diversas áreas como:
Engenharia e construção civil; Na construção de software;
No desenvolvimento de uma pesquisa; Em administração de empresas;
Por mais simples que seja o termo "modelagem de projeto" à primeira vista, a partir do momento que começamos verificar todo o contexto percebe-se que tem grande relevância para a gestão e controle de projetos. A gestão de projetos tem origens remotas, existe documentação sobre projetos há pelo menos 6.000 anos, na Mesopotâmia (Thiry-Cherques, 2010, p. 24).
De acordo com o contexto de gerenciamento podemos ter três situações: a) uma que já vimos que é o conceito de projeto; b) um subprojeto que para Savier e Chueri (2008) é um subconjunto de um projeto, onde serão utilizadas as mesmas técnicas e métodos para o gerenciamento de projeto; c) ainda o conceito de portfólio conforme (SAVIER E CHUERI e CHUER, 2008 apud PMI, 2004 p. 373) é um conjunto de projetos agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atender aos objetivos estratégicos do negócio. A figura 1 esquematiza os conceitos de projeto, subprojeto e portfólio.
Figura 1 - Representação dos conceitos de projeto, subprojeto e portfólio
Fonte: adaptado de PMBOOK, 2004, p. 14
A modelagem de projetos tem grande importância e aplicabilidade para atingir os objetivos, reduzindo custos e o tempo necessário o resultado. Segundo (Thiry-Cherques, 2010, p. 22) um projeto estará bem modelado quando for administrável e passível de avaliação.
2.2 Ciclo de vida do projeto
O entendimento sobre o ciclo de vida auxilia projetistas na configuração dos projetos, principalmente quando não tiver clareza dos objetivos. De acordo com a instituição que utiliza a metodologia de gestão de projeto pode ter diferenças, no ciclo de vida do projeto. (Kerzner, 2006, p. 45) define em cinco fases o ciclo de vida para a maturidade em gestão de projetos que são: embrionárias, aceitação pela gerencia executiva, aceitação pelos gerentes da área, crescimento, maturidade. (Vargas, 2005, p. 33) diz que para efeitos didáticos, consideram-se cinco fases: iniciação planejamento, execução, controle, finalização.
Kerzner (2006, p. 45) coloca a primeira fase como embrionária que consiste no reconhecimento das necessidades, benefícios que podem ser obtidos com a gestão de projetos, além de fazer com que as pessoas, gerentes, diretores tenham consentimento das vantagens ao adotar a metodologia da gestão de projetos. Já Vargas (2005, p. 33) descreve como fase de iniciação quando se tem claro a necessidade e a identificação de se transformar um problema em passos estratégicos a serem seguidos para atingir um determinado objetivo. Em outras palavras consiste em definir o objetivo e a missão do projeto.
A segunda fase de Kerzner (2006, p. 46) descreve como fase de aceitação pela gerência executiva, conseguir o apoio é um dos maiores obstáculos para conseguir atingir a maturidade na gestão de projeto. O apoio também é fundamental pois os executivos devem saber como orientar os seus colaboradores. Fase de planejamento colocada por Vargas (2005, p. 33) relata que é a fase na qual deve ser detalhado o que será realizado, juntamente com cronogramas, atividades, alocação de recursos, etc. Também devem ser planejados o controle de riscos, qualidade e outros detalhes necessários para evitar falhas durante a execução do projeto.
A terceira fase de apoio dos gerentes de área contempla a fase anterior. Assim como a gerencia executiva, os gerentes de área também devem apoiar e aceitar a gestão de projetos. Além disso, devem conhecer bem as técnicas de gerenciamento de projeto, pois eles vão trabalhar e motivar os colaboradores da empresa Kerzner (2006, p. 47). A terceira fase colocada por Vargas (2005, p. 34) é a fase de execução que consiste em materializar o que foi planejado anteriormente, sendo que qualquer falha cometida nas fases anteriores ficará evidente nessa fase.
O Kerzner (2006, p. 47) coloca a quarta fase de crescimento, que pode ter início juntamente com a fase embrionária porém para concluir esta fase todas as fases anteriores devem estar concluídas. Além disso, deve-se desenvolver uma metodologia de gestão de projetos e todos os colaboradores devem ter o comprometimento com a metodologia criada. Também nessa fase após ter definido a metodologia poderá ser escolhido um software para auxiliar no gerenciamento do projeto. Fase de controle abordada por Vargas (2005, p. 34) acontece paralelamente com a fase de execução, e tem como objetivo acompanhar e controlar o que está sendo realizado. Além de avaliar de tal forma que possam ser aplicadas melhorias.
Para Kerzner (2006, p. 50) a quinta fase, maturidade as empresas conseguem superar as fases anteriores num prazo de 12 a 24 meses. Nessa fase também deve se cria um programa de educação continuada.
Se não "documentar" as lições aprendidas, a empresa pode rapidamente regredir da maturidade para imaturidade em gestão de projetos. O conhecimento é perdido e os erros passados se repetem (KERZNER, 2006, p. 51).
Para Vargas (2005, p. 34) na fase de finalização são realizadas auditorias apontando falhas e melhorias no qual devem ser documentadas para que em projetos futuros não se repitam as falhas e os pontos seja usados.
O ciclo de vida pode variar de acordo com as necessidades. Os autores citados definem cinco fases, cada um com suas peculiaridades, porém necessariamente não precisa seguir essas fases ou ter apenas cinco fases, estas são colocadas como uma sugestão, uma linha que pode ser seguida. Kerzner (2006, p. 51) diz que praticamente todas empresas que seguiram essas fases atingiram algum grau de maturidade.
2.3 Metodologia de gestão de projetos
Assim como as fases do ciclo de vida do projeto a metodologia de gestão também pode ser várias formas de acordo com o contexto da empresa, dos objetivos a serem alcançados. A ordem aqui não é reinventar a roda; não desenvolva uma metodologia a partir
do zero Kerzner (2006, p. 104). Para criar uma metodologia você deve ter conhecimento, uma
componentes da metodologia que são Organização, Planejamento, Gestão, Relatórios (Kerzner, 2006, p. 105).
Organização é um "alicerce" para obter êxito nos projetos, as informações necessárias
para ter um controle durante todo o ciclo do projeto, os objetivos, a ideia, onde queremos chegar com o projeto e as partes envolvidas devem estar bem organizadas.
Planejamento é o momento de realizar a coleta de informações, de forma que fiquem o
menor número de duvidas possíveis. Deve-se definir custos, planos de controle de riscos, controle de qualidade. Em outras palavras, devemos coletar informações e definir pontos que serão aproveitados para realizar a gestão do projeto.
Gestão nesse ponto é o momento em que podemos avaliar desempenho, falhas, e
controlar o seu desenvolvimento que de acordo com a situação, pode-se aplicar alguma melhoria, a realizar algum ajuste no projeto, que em alguns casos pode ter algum desvio do objetivo inicial do projeto.
Relatórios é um mecanismo que completa a gestão, através deste consegue-se obter as
informações necessárias para realizar a gestão. Como por exemplo, produzir um relatório do rendimento de um determinado funcionário ou verificar o tempo que ele ficou trabalhando em determinada tarefa.
2.4 Áreas de conhecimento do gerenciamento de projetos
O PMBOK é um dos principais guias para gestão de projetos que coloca nove grandes áreas de gerenciamento que são: integração, escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos, suprimentos. Cada uma dessas áreas tem sua importância na gestão de projetos. As áreas são detalhas nas sessões 2.4.1 até 2.4.9.
2.4.1 Gerenciamento de integração
O processo de integração consiste em interligar todas as outras áreas de conhecimento do gerenciamento de projetos para conseguir sincronizar as tarefas, e outras dependências que podem surgir entre as áreas.
O processo de integração do projeto consiste em garantir que todas as demais áreas estejam integradas em um todo único. Seu objetivo é estruturar todo o projeto de modo a garantir que as necessidades dos envolvidos sejam atendidas, ou até mesmo superadas, pelo projeto(VARGAS, 2005, p.52).
Segundo o PMBOOK (2004, p. 44) gerenciamento de integração compreende processos que são:
1. Desenvolver o termo de abertura do projeto - é um termo formal que autoriza o início do projeto, no qual deve ser consignado ao um gerente de projeto, caso não tenha deve ser providenciado o quanto antes. Dependendo do caso ou algumas empresas antes da autorização realizam um levantamento das necessidades, viabilidade, entre outros quesitos que determinam se o projeto deve iniciar.
2. Desenvolver a declaração do escopo preliminar do projeto - tem por objetivo criar uma descrição de alto nível do escopo do projeto.
3. Plano de gerenciamento de projeto - é a documentação de como o projeto deve andar, definir as ações a serem tomadas durante a execução do projeto.
4. Orientar e gerenciar a execução do projeto - aqui são postas em pratica todas as ações definidas no plano de gerenciamento de projeto.
5. Monitorar e controlar o trabalho do projeto - nesta fase é avaliado o desempenho, se os objetivos estão sendo atendidos, detectar alguma falha, entre outros pontos que são detectados durante o andamento do projeto.
6. Controle integrado de mudanças - analisar as solicitações de mudanças, ter o controle de mudanças, ter o controle do impacto da mudança solicitada e dos processos ativos.
7. Encerrar o Projeto - consiste no encerramento de todas as atividades de todos os grupos participantes do projeto.
2.4.2 Gerenciamento de escopo
Consiste em controlar as tarefas realizadas guiando-as para atingir o objetivo que foi proposto, ou seja, manter o foco evitar, que as tarefas que estão sendo realizadas não consigam atingir o seu objetivo.
O gerenciamento de escopo tem como objetivo principal definir e controlar os trabalhos a serem realizados pelo projeto de modo a garantir que o produto, ou serviço, desejado seja obtido através de menor quantidade de trabalho possível, sem abandonar nenhuma premissa estabelecida no objetivo do projeto (VARGAS, 2005, p.56).
Vargas (2005, p. 60) também coloca que quanto mais detalhado o escopo do projeto menor a sua complexidade, e vai se aumentando a complexidade na medida em que não se consegue ter clareza do escopo.
2.4.3 Gerenciamento de tempo
O que se almeja nessa área é fazer com que o projeto seja concluído dentro do prazo estabelecido. O gerenciamento de tempo juntamente com o gerenciamento de custo são as duas áreas mais visadas pelos gerentes de projetos, porque são os dois pontos chaves para determinar o custo do projeto. Para realizar a representação do tempo e custo são confeccionados diagramas (Vargas, 2005, p. 66).
O PMBOOK (2004, p.112) define seis processos que ocorrem nessa área que são:
1. Definição da Atividade - consiste em identificar as atividades especificas que são necessárias para produzir as entregas do projeto.
2. Sequência de atividades - definição da sequência de atividades, quais atividades são dependentes, que podem ser diagramadas em um diagrama de rede ou rede de PERT, no qual podemos otimizar o tempo.
3. Estimativa de duração de atividade - consistem em uma estimativa de tempo necessário para a realização da atividade individual do cronograma.
4. Estimativa de recursos da atividade - estimativa das quantidades de recursos necessários para realizar a atividade.
5. Desenvolvimento do cronograma - consiste em analisar os recursos necessários, a sequência das atividades e as suas estimativas de tempo.
6. Controle do cronograma - processo destinado para controlar e evitar para que o projeto seja entregado fora do prazo previsto.
2.4.4 Gerenciamento de custo
O gerenciamento de custo tem como objetivo saber se o capital disponível é suficiente para a construção do projeto. Não devemos apenas considerar o custo já calculado no próprio projeto, pois muitas vezes podemos estar desenvolvendo um produto ou serviço de interesse comercial, que por sua vez o retorno do dinheiro investido, o lucro desejado dará na concepção do projeto (Vargas, 2005, p. 72).
Nesta área temos três processos de acordo com PMBOOK (2004, p. 141) que são:
1. Estimativa de custos - compreende-se em uma estimativa dos custos dos recursos necessários para realização do projeto ou seja construir um plano de custo.
2. Orçamentação - consiste em determinar as estimativas de custo de cada atividade ou de um pacote de trabalho estabelecendo uma linha de base dos custos, projetando o fluxo de caixa do projeto.
3. Controle de custos - controle dos fatores que criam variações de custos e controle das mudanças no orçamento do projeto.
2.4.5 Gerenciamento de qualidade
O principal foco dessa área é gerenciar a qualidade. Está caracteriza em concluir o projeto dentro da qualidade desejada, atingida pela satisfação das necessidades dos envolvidos no projeto. Sendo o principal responsável pelo gerenciamento de qualidade o seu gerente de projeto (Vargas, 2005, p. 77).
1. Planejamento da qualidade - consiste em identificar padrões de qualidade, que são relevantes ao projeto e determinar como satisfazê-los.
2. Realizar a garantia da qualidade - caracteriza-se no envolvimento de todas as atividades sistematicamente organizadas de acordo com o sistema de qualidade.
3. Realizar o controle da qualidade - processo de monitoramento dos resultados específicos do projeto para análise e averiguar se estão dentro dos padrões estabelecidos, identificar as falhas e elimina-las.
2.4.6 Gerenciamento de recursos humanos
Gerenciamento de Recursos consiste em processos para organizar e gerenciar as pessoas e as equipes e cada uma delas tem suas responsabilidades atribuídas, o sucesso ou
fracasso do projeto dependem diretamente do gerenciamento dos recursos humanos
(VARGAS, 2005, p.76).
Dependendo do caso podemos ter várias equipes para realização do projeto e esta tem pessoas que são responsáveis pela equipe e pelos processos de planejamento e controle e encerramento (PMBOOK, 2004, p. 181).
O PMBOOK (2004, p. 181) coloca quatro processos que são:
1. Planejamento de Recursos Humanos - realizar a identificação, documentação das funções, responsabilidades estabelecendo as relações hierarquias do projeto e construir plano de gerenciamento de pessoal.
2. Contratar ou mobilizar a equipe do projeto - consiste em obter os recursos humanos necessários para a realização do projeto.
3. Desenvolver a equipe do projeto - criar meios para melhorar a produtividade, competência e a sinergia dos membros da equipe a fim de aumentar o desempenho do projeto.
4. Gerenciar a equipe do projeto - ter um acompanhamento do desempenho das pessoas envolvidas, colaborar com o feedback, realizar melhorias no desempenho do projeto.
2.4.7 Gerenciamento das comunicações
Consiste em que as informações necessárias, desejadas para construção do projeto cheguem para às pessoas certas no tempo certo (Vargas, 2005, p. 87). A comunicação é a forma mais utilizada para manter todos os participantes do projeto sincronizados para atingir o objetivo proposto.
O guia PMBOOK (2004, p. 204) coloca os seguintes processos nessa fase:
1. Planejamento das Comunicações - determina a necessidade da informação das pessoas envolvidas e o grau de detalhamento da informação.
2. Distribuição das informações - expor as informações necessárias para as pessoas certas no momento adequado.
3. Relatório de desempenho - organizar e coletar as informações referentes ao desempenho.
4. Gerenciar as partes interessadas - consiste em gerenciar a comunicação para satisfazer os requisitos das partes interessadas no projeto e resolver problemas com ela.
2.4.8 Gerenciamento de riscos
Esta fase consiste no gerenciamento de riscos do projeto que busca o aumento da probabilidade do impacto positivo e diminuição do impacto negativo (PMBOOK, 2004, p. 226). Para Vargas (2005, p. 93), os riscos estão associados a empreendimentos maiores devido ao grande volume de dinheiro envolvido e também à reputação do time de patrocinadores.
O PMBOOK (2004, p. 226) subdivide em quatro processos o gerenciamento de riscos que são:
1. Planejamento do gerenciamento de riscos - consiste em planejar, abordar e executar ações para o gerenciamento de riscos de um projeto.
2. Identificação de riscos - processo que tem por objetivo identificar os possíveis riscos que possam afetar o projeto.
3. Análise quantitativa de risco - ter uma forma de análise numérica dos efeitos identificados no projeto.
4. Planejamento de respostas a riscos - consiste em desenvolver ações e opções para reduzir os riscos ao projeto.
5. Monitoramento e controle de riscos - processo tem por objetivo acompanhar os riscos identificados, observando surgimento de novos riscos, e executar ações de resposta a esses riscos.
2.4.9 Gerenciamento de suprimentos
Nesta área tem-se como objetivo dar uma garantia que os elementos externos necessários ao projeto evitando em surpresas durante o projeto como por exemplo a falta de um elemento ou atraso de entrega. O PMBOOK (2004, p.260 ) coloca os seguintes processos:
1. Planejar compras e aquisições - determinar o que comprar ou adquirir quando e como fazer isso.
2. Planejar contratações - realizar a documentação dos requisitos de produtos, serviços e resultado e identificar possíveis fornecedores.
3. Solicitar respostas de fornecedores - consiste na coleta de informações dos fornecedores como preços, ofertas, propostas entre outros itens de acordo com a necessidade.
4. Selecionar fornecedores - realizar uma análise dos fornecedores verificando melhores ofertas, credibilidade, confiabilidade.
5. Administração de contrato - tem como objetivo realizar uma análise dos fornecedores visando corrigir problemas de entrega, qualidade de serviço entre outros pontos que sejam necessários para ter êxito no gerenciamento de suprimentos.
6. Encerramento do contrato - neste processo visa realizar o termino formal do contrato em determinada fase ou no encerramento do projeto.
3 FERRAMENTAS PARA GESTÃO DE PROJETOS
Segundo Kerzner (2006, p. 148), no final da década de 80 os softwares para gestão de projeto eram projetados para organização de projeto utilizando os seguintes métodos (que são técnicas de avaliação e análise de programas) - PERT (Program Evaluation and Review
Technique), método de diagrama de flechas - ADM (Arrow Diagramming Method), método
de diagrama de precedência - PDM (Precedence Diagramming Method). Kerzner (2006, p. 148) coloca com três técnicas de gestão de redes e organização o que superou os gráficos da época.
A rede PERT tem sua origem no meio militar, com uma associação entre a marinha e as empresas Lockheed & Booz e Allen & Hamilton, em 1958, no desenvolvimento dos projetos de construção da série de submarinos atômicos
Polaris do governo norte-americano. (Vargas, 2005, p. 178).
Um dos softwares mais conhecidos para o gerenciamento de projetos é o Microsoft Project®. Existem gratuitos como open project, porem esses eles não trabalham sozinhos é necessário configura-los e colocar as informações dentro do software que tem por objetivo auxiliar na gestão de projetos.
Uma das principais ferramentas utilizadas nos softwares de modelagem de projetos é o diagrama de Gantt no qual se tem uma visualização de tarefas versus atividades versus tempo. A figura 2 abaixo mostra um exemplo do diagrama. Além do diagrama de Gantt os softwares têm outras vantagens como otimização do tempo, cálculo de custo, gerenciamento da gestão de recursos humanos entre outras vantagens.
Figura 2 - Representação do Gráfico de Gantt
3.1 Desenvolvimento do software
Dentro do contexto de modelagem de projetos um dos pontos mais importantes é controlar o andamento dos projetos. Saber quem é o responsável pela atividade e saber se o projeto está dentro do prazo, além disso temos as partes interessadas no projeto ou seja o cliente ou investidor e a equipe no qual vai desenvolver o projeto.
Para realizar um projeto, tem-se um conjunto de pessoas que estão focadas no objetivo proposto, também fundamental que todos estejam comprometidos com o que é proposto. O grupo envolvido no projeto deve interagir e compartilhar ideias e sugestões para obter êxito em atingir o objetivo proposto.
A figura 03 abaixo ilustra de forma mais abstrata o fluxo do software, temos quatro células:
Pessoas: Caracteriza pelo conjunto de pessoas envolvidas no projeto como por
exemplo investidores, clientes que tem interesse no resultado do projeto finalizado. Tem-se um ou mais grupos envolvidos que efetivamente participam na construção dos projetos "colocando a mão na massa" ou seja pessoas que de fato resolvem as atividades propostas no projeto.
Recursos: Pode ser caracterizado por algum objeto necessário para realização da
tarefa como por exemplo um retroprojetor ou uma sala de reunião que pode ser utilizado para realização de alguma tarefa.
Custos: Um dos pontos para gestão de um projeto é que precisamos na maioria dos
casos um valor a ser investido, e cada uma das células direta ou indiretamente gera custos, as pessoas têm o custo por hora de trabalho os recursos podem ter um custo por hora ou um custo fixo a atividade tem um custo gerado pelos recursos e pelas pessoas.
Software de Gestão: é o ponto central mecanismo que auxilia na gestão das células e
cada uma delas se relacionam temos então as setas nos dois sentidos que simbolizam a comunicação e o fluxo entre as células é gestado através do software.
Figura 3 - Visão Geral do software
Fonte: autor.
Nas próximas seções será realizado o levantamento e análises dos requisitos para construção do software.
3.2 Levantamento e análise de requisitos
Através da visão do sistema apresentada na figura 3 e a análise do conceito de gestão de projetos abordada na sessão 2, será realizada a análise de requisitos para construção do sistema. Sommerville define:
"o termo requisito não é utilizado pela indústria de software de modo consciente. Em alguns casos, um requisito é visto como uma declaração abstrata, de alto nível, de uma função do sistema que o sistema deve fornecer ou de uma restrição do sistema. No outro extremo, ele é uma definição detalhada, matematicamente formal, de uma função do sistema." (Sommerville, 2003, p. 82)
3.3 Requisitos do software
Nesta sessão, será aborda a análise de requisitos do sistema para gestão de projetos, com base na visão apresentada na figura 3.
3.3.1 Requisitos quanto os projetos
Descrição do caso de uso: Caso de uso permite ao usuário criar projetos e sub
projetos para organizar as atividades, podendo definir uma data de início e termino para o projeto o que significa que as atividades que estão dentro do projeto deve respeitar o intervalo
estabelecido no projeto. Nesta etapa também pode vincular participantes que podem ser usuários que apenas acompanham as atividades como por exemplo os investidores do projeto ou usuários no qual efetivamente trabalham na construção do projeto.
O controle de permissões dos projetos é definido de acordo com a vinculação de usuários a pasta tendo dois casos:
Caso o usuário esteja vinculado com visitante (investidor) vai poder visualizar o andamento de todas as atividades que estão no projeto.
Caso o usuário não seja visitante este vai poder criar atividades e sub projetos de acordo com o vínculo do usuário.
Requisitos quanto as informações sobre os projetos:
Data limite para início e termino das atividades que estão dentro do projeto.
Data de início e término que de fato foi iniciado a primeira atividade dentro do projeto.
Usuário que criou o projeto.
Data e hora que foi criada o projeto. Status do projeto.
Nome do projeto.
Descrição utilizada para descrever com maiores detalhes sobre o projeto. Custo estimado.
3.3.2 Requisitos quanto aos usuários
Descrição do caso de uso: Caso de uso permitirá o cadastro de novos usuários ao
sistema além de fornecer um mecanismo para poder redefinir a senha do usuário cadastrado. Outro ponto importante que o sistema deve permitir o bloqueio do acesso do usuário.
Requisitos quanto as informações sobre os usuários:
Nome. E-mail.
Senha de acesso. Data de nascimento.
Custo por hora utilizado calcular o custo do colaborador na atividade. Controle para indicar se o usuário tem acesso ao sistema.
3.3.3 Requisitos quanto aos recursos
Descrição do caso de uso: Caso de uso permitirá o cadastro de recursos que podem
ser utilizados nas atividades o sistema também deve controlar para que um recurso não possa ser alocado em mais de uma atividade ao mesmo.
Requisitos quanto as informações dos recursos:
Nome para identificar o recurso.
Código de patrimônio utilizado para identificar o equipamento através da sua etiquetagem.
Custo fixo ou custo por hora do recurso para estimativa o custo da atividade consequentemente do projeto.
3.3.3 Requisitos quanto as atividades
Descrição do caso de uso: Caso de uso permitirá cadastro de atividades podendo
definir data de início e termino para atividade vincular usuários, realizar anotações sobre as atividades permitindo assim construir o histórico da atividade. O sistema deve permitir criar relações entre as atividades.
O usuário que irá executar a atividade o sistema deve permitir um controle de tempo que o usuário gastou para executar a tarefa gerando assim um controle de tempo e custo do usuário na atividade.
Requisitos quanto as informações das atividades:
Possui uma data para seu início e término ou seja um determinado tempo de execução da atividade.
Possui uma data de início e término indicando quando que de fato foi iniciada a execução da atividade.
Possui relações entre elas ou seja uma atividade com a outra vai ter um vínculo que podem ser de quatro tipos: término a Inicio (TI), início a início (II), término a término (TT), início a término (IT).
Título para referenciar a atividade.
Descrição para descrever com mais detalhes a atividade.
Porcentagem de conclusão compreende-se em que ponto a atividade se encontra. Campo para adicionar estimativa de custo.
Colaboradores vinculados a atividade.
O colaborador vai ter um tempo de horas gastas para resolver a atividade ou seja quando o colaborador estiver trabalhando na atividade vai ter a opção de disparar um timer um relógio no qual vai controlar o tempo gasto pelo colaborador.
No decorrer da atividade permitir mecanismos para adicionar anotações referentes a atividade.
Permitir a alocação de recursos na atividade como por exemplo veículos, retroprojetores, sala de reuniões etc.
3.5. Estrutura banco de dados
Na construção do software foi utilizado banco de dados relacional PostgresSQL 9.3 por ser open source e atender as necessidades do projeto.
A figura 4 representa o diagrama de entidade relacional sem os atributos para facilitar na visualização tendo como objetivo ressaltar os relacionamentos entre as entidades os atributos de cada uma das tabelas serão detalhados logo a seguir.
Figura 4 - Diagrama Entidade Relacional
Fonte: autor.
3.6 Projeto lógico das tabelas do sistema
Para representação de chave primaria será utilizada a abreviatura PK e para chave estrangeira será utilizada abreviatura FK e para chave única será abreviado por UK, também será adicionado observações dos campos caso seja necessário. A tabela usuário será apresentada como exemplo, as demais tabelas estão no anexo A.
Tabela de Usuário
Chave Atributo Tipo Observações
PK id integer
UK nome Character varying
(100)
senha character varying (200)
data_nasc date Data de nascimento do usuário
custo_hr double precision Custo da hora do usuário data_criacao date Data qual o usuário foi criado data_ultimo_aces
so
date Data quando foi seu último
acesso ao sistema Fonte: autor.
3.7 Casos de uso
Casos de uso são técnicas baseadas em cenários para obtenção de requisitos, identificando agentes envolvidos (Sommerville, 2003, p. 82). Nesta sessão será aborda os casos de usos do sistema de gestão de projetos.
3.7.1 Cadastros de usuário
Figura 5 - Caso de Uso Cadastro de Usuário
Fonte: Autor.
Descrição do caso de uso: Neste caso de uso o sistema permite o cadastro de usuário
armazenando no banco para que este usuário posteriormente possa acessar o sistema.
Pré-requisitos: o usuário que irá fazer o castro deve ser autenticado no sistema além
disso o usuário que for cadastrado o e-mail para acesso do sistema deve ser único.
Cenários primários:
Antes da confirmação do cadastro verifica se o e-mail para acesso é único. Ativa o usuário cadastrado no sistema.
Cenários secundários:
Usuário não autenticado redireciona para tela de acesso ao sistema.
E-mail de acesso já está cadastrado, o sistema informa ao usuário que este e-mail já está cadastrado.
3.7.2 Cadastros de projeto
Figura 6 - Caso de Uso Cadastro de Projeto
Fonte: Autor.
Descrição do caso de uso: Permite ao usuário poder criar projeto e sub projeto,
definir participantes da pasta e definir prazos limites para que todas as atividades dentro do projeto terminem.
Pré-requisitos: Usuário estar autenticado no sistema e ter permissão para criar para
criar projeto. Ou existir a pasta caso queira criar uma sub pasta.
Cenários primários:
Usuário está autenticado e tem permissão para criar pasta. Cadastra a pasta e vincula os usuários a pasta.
Cenários Secundários:
Usuário não estar autenticado redireciona para tela de acesso ao sistema.
Não tem usuários para cadastrado no sistema. Sugestão finalizar o cadastro da pasta sem a vinculação dos usuários após realizar o cadastro do usuário.
3.7.3 Cadastros de recurso
Figura 7 - Caso de Uso de Cadastro de Recurso
Fonte: Autor.
Descrição do caso de uso: permite o cadastro de recursos para que possam ser
utilizadas nas atividades, juntamente o recurso pode ser definido custo por hora ou um custo fixo.
Pré-requisitos: Usuário estar autenticado. Cenários Primário:
Verifica se usuário está autenticado.
No momento do cadastro o sistema deve armazenar o usuário que está cadastrando o recurso.
Ativar o recurso no sistema para que esteja disponível para ser utilizado.
Cenários Secundários:
Usuário não estar autenticado redireciona para tela de acesso ao sistema. Caso o usuário não tenha permissão de cadastro bloquear o cadastro.
3.7.4 Cadastros de atividade
Figura 8 - Caso de Uso - Cadastro de Atividade
Fonte: Autor.
Descrição do caso de uso: permite ao usuário cadastrar atividade, definindo data de
início e termino para atividade, estimativa do custo da atividade.
Pré-requisito: Usuário estar autenticado no sistema e ter permissão para criar as
atividades.
Cenário Primário:
Verificar se o usuário está autenticado e tem permissão para criar atividade.
No momento do cadastro da atividade o sistema armazena o usuário que criou a atividade.
A data de início deve ser menor que a data de término da atividade.
Cenários Secundários
Usuário não estar autenticado redireciona para tela de acesso ao sistema. Caso o usuário não tenha permissão de cadastro bloquear o cadastro.
Data de início ser maior que a data de término da atividade, sistema avisa ao usuário para corrigir as datas.
3.7.5 Precedências das atividades
Fonte: Autor.
Descrição do caso de uso: caso de uso permite o cadastro de precedências das
atividades.
Pré-requisitos: As atividades já devem estar cadastradas. Cenários Primários:
Seleciona a atividade a ser vinculada; Define o tipo do vínculo com a atividade.
3.7.6 Cadastros de participantes da atividade
Figura 10 - Caso de Uso - Cadastro de Participante na Atividade
Fonte: Autor.
Descrição do caso de uso: permite o cadastro de participantes na atividade. Pré-requisitos: Atividade e o usuário devem estar previamente cadastradas. Cenários Primários:
Seleciona a atividade que deseje vincular os participantes. Seleciona os usuários que deseje vincular na atividade.
Cenários Secundários
Usuário não está cadastrado, sistema informa ao usuário para ir ao cadastro de usuários.
3.7.7 Alocação de recursos nas atividades
Figura 11 - Caso de Uso - Alocação de Recurso
Fonte: Autor.
Descrição do caso de uso: permite ao usuário alocar recursos na atividade. Pré-requisitos: Recursos e Atividade devem estar previamente cadastradas. Cenários Primários:
Seleciona a atividade que deseja alocar o recurso. Seleciona os recursos a ser vinculado a atividade.
Cenários Secundários:
O recurso não está disponível. Sugere avisar o seu superior para providenciar o recurso.
3.7.8 Remover recurso da atividade
Figura 12 - Caso de Uso - Remover Recurso da Atividade
Fonte: Autor.
Descrição do caso de uso: Permite ao usuário remover o recurso da atividade. Pré-requisito: Recurso deve estar alocado na atividade.
Cenários Primários:
Remover o recurso da atividade.
3.7.9 Remover atividade
Figura 13 - Caso de Uso - Remover Atividade
Fonte: Autor.
Descrição do caso de uso: Permite ao usuário remover a atividade do sistema. Pré-requisitos: Atividade deve existir.
Cenários Primários:
Selecionar atividade a ser excluída.
Sistema remove automaticamente os seus vínculos (usuários, recursos, precedência, pasta).
Cenários Secundários:
Erro ao remover a atividade. Avisar o usuário do erro para que posso analisar e entrar em contato com o suporte.
Erro ao remover os vínculos da atividade. Avisar o usuário do erro para que posso analisar e entrar em contato com o suporte.
3.7.10 Remover projeto
Figura 14 - Caso de Uso - Remover Projeto
Descrição do caso de uso: Permite ao usuário remover projeto do sistema. Pré-requisitos: Projeto deve estar cadastrada no sistema.
Cenários Primários:
Selecionar a projeto a ser excluída.
Sistema remove automaticamente os seus vínculos (usuários, atividades, sub pastas).
Cenários Secundários:
Erro ao remover a pasta. Avisar o usuário do erro para que posso analisar e entrar em contato com o suporte.
Erro ao remover os vínculos da pasta. Avisar o usuário do erro para que posso analisar e entrar em contato com o suporte.
3.7.11 Controles do tempo gasto na atividade pelo usuário
Figura 15 - Caso de Uso - Controle de Tempo
Fonte: Autor.
Descrição do caso de uso: Caso de uso permite ao usuário na qual está vinculado
pode disparar um cronometro no qual conta o tempo gasto para atender a atividade sendo que o cronometro pode ser iniciado e parado de acordo com a necessidade.
Pré-requisitos: Usuário está vinculado a atividade. Cenários Primários:
Seleciona a atividade e dispara o cronometro. Seleciona a atividade e para o cronometro.
3.7.12 Ajustar tempo gasto na atividade
Figura 16 - Caso de Uso - Ajuste de Tempo Gasto
Fonte: Autor.
Descrição do caso de uso: Permite ao usuário ajustar o tempo gasto na atividade
como inserir início e parada do cronometro ou remover registro do início e parada.
Pré-requisito: Ter permissão para ajuste de tempo gasto. Cenário Primário:
Seleciona a atividade.
Lista os tempos gastos pelo usuário.
Realiza o ajuste do tempo gasto pelo usuário.
Cenário Secundário:
Usuário não tenha tempo gasta registrado. Pode ser inserido um registro de início e parada do cronometro.
Erro calcular custo do usuário. Verificar o custo do usuário no cadastro.
3.7.13 Comentários/anotações da atividade
Figura 17 - Caso de Uso - Comentário/Anotação da atividade
Descrição do caso de uso: Permite ao usuário cadastrar comentários ou anotações
sobre o andamento da atividade.
Pré-requisito: Atividade deve já existir e o usuário estar vinculado a atividade. Cenário Primário:
Seleciona atividade
Realiza o apontamento de acordo com a necessidade.
Cenário Secundário
Usuário não estar vinculado a atividade. Solicitar ao superior para ser incluído na atividade.
Usuário não consegue adicionar a anotação. Solicitar ao superior para verificar as suas permissões.
4 DESENVOLVIMENTO DO SOFTWARE
Nesta sessão será abordado o desenvolvimento do software para gestão de projetos, de acordo com a modelagem apresentada na sessão 3, enfatizando as tecnologias utilizadas e o protótipo das telas descrevendo as suas funcionalidades.
Nas sessões 4.1.1 à 4.1.5 apresenta descrição detalhada das tecnologias e frameworks utilizados no processo de desenvolvimento do software.
4.1 Tecnologia utilizadas
O sistema para gestão de projetos é projetado na plataforma web, o que permite o acesso ao sistema de qualquer lugar do mundo desde que tenha um dispositivo com acesso à internet e um navegador moderno instalado.
No desenvolvimento do sistema foi utilizada linguagem Java, pois utiliza o paradigma de orientação a objeto, proporcionando inúmeras vantagem como por exemplo modularidade, hierarquia e polimorfismo, permitindo assim criar sistemas complexos bem estruturados. Para agilizar e facilitar a construção e manutenção do sistema foi utilizado frameworks que são:
Hibernate, Vrpator, Twitter bootstrap e o servidor de aplicação glassfish.
4.1.1 Linguagem Java
“A inovação nas linguagens de computador é impulsionada por dois fatores: melhorias na arte de programar e alterações no ambiente de computação” (Schildt, 2013, p. 3). Em função disso a linguagem Java proporciona recursos muito poderosos como: paralelismos, modularidade, fácil aprendizagem entre outras. Pelo fato de ser orientada a objeto a forma de programar em Java é mais próxima da realidade proporcionando uma curva de aprendizagem maior.
A Linguagem Java foi criada por James Gosling, Patrick Naughton, Chris Warth, Ed Frank e Mike Sheridan em 1991 na Sun Microsystems, primeiramente denominada “Oak” sendo renomeada em 1995 para “Java” tendo como principal objetivo a portabilidade do programa desenvolvido, ou seja, ter o mesmo programa para arquiteturas diferentes, porque na época as linguagens eram compiladas para uma arquitetura especifica (Schildt, 2013, p. 3).
Para facilitar a aprendizagem da linguagem Java, a sua sintaxe foi baseada nas linguagens de programação C/C++ por ser a mais utilizada na época. A linguagem C/C++ não tinha a portabilidade do programa, para podermos utilizar em outra arquitetura era necessário compilarmos novamente o código para o seu destino. Pensando nisso a linguagem Java possui uma Máquina Virtual Java (JVM, Java Virtual Machine), que é responsável em executar o código.
A compilação do código Java não gera um executável, invés disso é gerado um
bytecode, consiste em um conjunto de instruções otimizadas, projetado para ser executado na JVM, permitindo que o mesmo código seja executado em diversas arquiteturas, possibilitando
a portabilidade do código, ou seja, invés de compilarmos o código específico para cada arquitetura temos a JVM para cada arquitetura.
Java é uma linguagem de programação Orientada a Objeto (OO). Para representar um objeto define-se os seus atributos e comportamentos, os atributos são as características do objeto, e os comportamentos compreendem as ações do objeto. O objeto é representado através de uma classe, que contém toda a estrutura do objeto, e através da classe são criados os objetos que são alocados em memória.
Geralmente os sistemas orientados a objetos são menores mais fáceis de escrever e realizar manutenção do que as linguagens não orientadas a objetos, além de aumentar a produtividade através da reutilização de código (Schildt, 2013, p. 8).
4.1.2 Framework Hibernate
O hibernate é um framework de Mapeamento Objeto-Relacional (ORM) open source atualmente mantido pela JBoss, que auxilia para tirarmos proveito dos recursos presentes no modelo de objetos com a tecnologia Java e por outro lado conseguirmos tirar proveito do modelo relacional utilizado pelos sistemas de gerenciamento de banco de dados (SGDB).
Sendo assim podemos persistir os objetos para tabelas relacionais utilizando metadados o qual descrevem o mapeamento (Guruzu & Mak, 2011, p. 4).
Segundo (Neto, 2011, p. 4) a principal característica do hibernate é a transformação das classes e seus tipos de dados em Java para tabelas de dados. Sendo assim tirando do desenvolvedor o trabalho de mapeamento e conversão dos resultados de SQL para objeto.
Hibernate é um dos frameworks ORM mais amplamente usados no setor. Ele oferece todos os benefícios de uma solução ORM e implementa a Java Persistence API (JPA) definida na especificação Enterprise JavaBeans (EJB)3.0 (Guruzu & Mak, 2011, p. 4).
O framework possui vários benefícios como: a) aumento de produtividade, porque reduz a complexidade de desenvolvimento, consequentemente também reduz o tempo, b) facilita a manutenção, porque todo o mapeamento do banco de dados relacional é mapeado para objeto através de configurações utilizando anotações ou XML. Também temos desvantagens segundo (Neto, 2011) em determinados sistemas em que a complexidade de controle do banco de dados é maior é aconselhável analisar os requisitos do sistema porque o
framework pode não suprir as necessidades.
4.1.3 Framework Vraptor
O VRaptor é um framework open source brasileiro desenvolvido e mantido pela Caelum, com o objetivo de desenvolver aplicações web com base nos protocolos HTTP/REST. É um dos poucos frameworks mais extensível em Java por ser construído baseado no CDI que é a especificação de dependência do Java EE (Cavalcanti, 2014, p. 3).
O framework VRaptor foi criado pelos irmãos Paulo Silveira e Guilherme Silveira em 2004, na Universidade de São Paulo, com o objetivo de facilitar o desenvolvimento web em Java, porque na época a construção de sistemas web era uma tarefa árdua. A sua primeira versão estável definida como VRaptor 2, foi criado contando com a ajuda do Fabio Kung, Nico Steppat entre outros desenvolvedores, trazendo as boas ideias e práticas do Ruby on Rails para o framework.
Para versão 3 o VRaptor foi totalmente reformulado, tendo como base a experiência dos erros e acertos da versão anterior e de outros frameworks da época. Nesta versão os
conceitos e padrões de convenção e injeção de dependência foram levados ao extremo, além de utilizar ideias de serviços REST-full auxiliando a comunicação entre sistemas.
Com a grande facilidade e poder de programação do Java EE 7, o VRaptor em meados de 2013 foi novamente reformulado, porém com um grande diferencial sendo projetado com base na especificação do Java EE 7 utilizando CDI, validação de dados com base na especificação JPA e reduzindo a utilização de bibliotecas de terceiros. Sua versão estável VRaptor 4 ficou disponível em março de 2014.
Além da facilidade e agilidade no desenvolvimento web em Java o VRaptor permite adicionar outros frameworks para auxiliar no desenvolvimento como: JSF, Velocity e Freemarker. Também pode ser utilizado bibliotecas externas como jQuery e AngularJS permitindo criar interfaces mais ricas para o usuário (Cavalcanti, 2014, p. 5).
4.1.4 Framework Twiter Boostrap
Twitter bootstrap é um framework front-end open source mantido pelo Twitter. Considerado um dos primeiros com a finalidade de auxiliar no desenvolvimento de páginas responsivas, tendo como objetivo ter uma mesma página web, que é redimensionada de acordo com a tela do dispositivo, como por exemplo tablets, smartphones, entre outros.
O framework consiste basicamente em uma estrutura definida de estilos CSS, em que podem ser customizados de acordo com a necessidade do sistema, além disso o twitter
bootstrap¸ utiliza como dependência jQuery, que é um framework Java Script que auxilia no
redimensionamento automático da página para diversos tamanhos de tela.
O jQuery trata-se de uma biblioteca Java Script criada por John Resig que diz o seguinte: “O foco principal da biblioteca jQuery é a simplicidade. Por que submeter os desenvolvedores ao martírio de escrever longos e complexos códigos para criar simples efeitos?” (Silva, 2010, p. 23).
Profundo conhecedor de Java Script, o criador do jQuery atua na Corporação Mozilla. Iniciou os trabalhos em 22 de agosto de 2005, após descrever sua frustação com a forma verbosa de escrever códigos em Java Script para obter os resultados desejados, também
propôs formas técnicas para simplificar a escrita. Em janeiro de 2006 apresentou os primeiros resultados de seus estudos.
Segundo Maujor, o framework jQuery destina-se em propor interatividade e dinamismo às páginas web, proporcionando aos desenvolvedores funcionalidades necessárias para criar scripts de forma não obstrutiva a usabilidade e a acessibilidade, enriquecendo a experiência do usuário (Silva, 2010, p. 25).
4.1.5 Web container
O Glassfish é um container Java EE completo porque ele implementa toda especificação do Java EE, tendo vários detalhes que podem ser configurados e ajustados de acordo com a necessidade da aplicação. A sua configuração é feita através de um console que pode ser acessado na web via browser (Sampaio, 2011, p. 23).
Figura 18 - Funcionamento do Container
Fonte: Adaptada de (Neto, 2011, p. 89)
A figura acima demonstra o funcionamento do container, definido nos seguintes passos:
1. Web Browser solicita requisição ao servidor de aplicação.
2. O servidor de aplicação delega a requisição para a aplicação e aguarda o retorno.
3. A aplicação web devolve o retorno para o Glassfish.
4. O Glassfish devolve a resposta para o web browser.
Além da aplicação o container é de fundamental importância porque ele provê os recursos do sistema para os clientes terem acesso, facilitando o desenvolvimento de aplicações web.
4.2 Protótipos das telas do sistema
Esta sessão apresenta os protótipos de telas do sistema juntamente com a descrição de suas funcionalidades. No anexo B estão as telas capturadas do sistema de gestão de projetos desenvolvido.
4.2.1 Acesso ao sistema
O sistema de gerenciamento de projetos, tem várias atividades e projetos a serem realizados, cada uma delas tem alguém envolvido, sendo assim temos que ter o controle de acesso ao sistema. A figura 19 demonstra a tela de acesso ao sistema, este acesso sendo feito através de e-mail e senha.
Figura 19 - Tela de Acesso ao sistema
Fonte: Autor.
4.2.2 Tela inicial do sistema
O foco principal do sistema é auxiliar nas tarefas do dia-a-dia, pensando nisso, ao realizar o acesso. Primeiramente são apresentadas as tarefas e projetos no qual o usuário autenticado no sistema tem acesso. A figura 20 apresenta a tela inicial do sistema.
A tela está dividida em três colunas, a primeira coluna apresenta os projetos em que o usuário participa, a segunda coluna apresenta a listagem das tarefas delegadas ao usuário e na
terceira coluna é apresentado dois gráficos que representa a relação de tarefas concluídas, em atraso e em andamento.
Como apresentado na figura 20, para acessarmos as funcionalidades tem um link chamado “I”. Quando o usuário clica no link este apresenta uma caixinha com as possíveis funcionalidades que podem ser executadas.
Na parte superior estão localizadas as outras funcionalidades do sistema como: cadastro/listagem de usuário e recursos, além da funcionalidade para ajustar os horários das atividades.
Figura 20 - Tela inicial do Sistema
Fonte: Autor.
4.2.3 Tela de informações da atividade
A tela tem como objetivo apresentar as informações sobre a atividade de forma intuitiva sem precisar acessar o cadastro da atividade, proporcionado maior agilidade para visualizar as informações. Também pode ser adicionado comentários ou dicas sobre a atividade, a partir disso o sistema registra o autor e quando o comentário foi feito. Esse é um dos principais mecanismos de comunicação provido pelo sistema, permitindo maior fluxo de informações ente os colaboradores das atividades.
Figura 21 - Tela Informações da Atividade
Fonte: Autor.
4.2.4 Tela de informações do projeto
O objetivo da tela é fornecer informações sobre o projeto como por exemplo, a data de início e término de forma ágil sem ter a necessidade de acessar o cadastro do projeto, além disso permite adicionar comentários ao projeto.
Para adicionar o comentário segue a mesma ideia dos comentários das atividades, ou seja, o sistema registra o autor do comentário e a data e hora em que foi registrado, permitindo o fluxo de comunicação.
Figura 22 - Tela Informação do Projeto
Fonte: Autor.
4.2.5 Tela de cadastro de projeto
A tela tem como objetivo realizar o cadastro do projeto definindo alguns dados como por exemplo, o título e a descrição. Os campos que definem o início e término não é obrigatório, caso for preenchido os campos as atividades dentro do projeto não podem ultrapassar o início e término.
Para vinculação dos participantes como mostra a figura 23, é utilizada um campo que tem a função de auto complemento, ou seja, ao digitar o e-mail ou nome o sistema apresentará listagem dos usuários cadastrados. Também pode ser adicionado arquivos, como por exemplo, imagens e arquivos de texto entre outros.
Figura 23 - Tela Cadastro Projeto
Fonte: Autor.
4.2.6 Tela de cadastro de atividade
A figura 24 apresenta a tela de cadastro de atividades. Primeiramente é definido o título e a descrição da atividade, além do início e término da atividade, após definimos as precedências, recursos e participantes.
Os campos para cadastro de participantes, recursos e precedências tem a função de auto complemento, ou seja, ao digitar o sistema apresentará a listagem de acordo com o campo. Ao cadastrar as precedências é definido o tipo de vínculo com outra atividade, ou seja, define-se qual atividade vem antes ou depois, ou quais atividades terminam ou começam junto.
