PIM VIII UNIP ADS – APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET

Prévia do material em texto

UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PIM VIII – APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET
São Paulo
2017
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PIM VIII – APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET
Curso: Tecnologia em Análise e Desenvolvimento de Sistemas
Semestre: 4º/2017
São Paulo
2017
RESUMO
Projeto Integrado Multidisciplinar (PIM) deste bimestre proposto pela universidade UNIP Interativa. Consiste no desenvolvimento de uma aplicação web utilizando a framework ASP.NET para gerenciamento de tarefas acadêmicas (trabalhos, provas, atividades complementares, DPs e etc). Na formatação do trabalho foram utilizados os conhecimentos adquiridos nas aulas dos módulos de Gerenciamento de Projetos de Software, Desenvolvimento de Software para Internet e Tópicos Especiais de Programação Orientada a Objetos. No desenvolvimento do mesmo foram abordadas às questões de escopo do projeto, elaboração da EAP (Estrutura Analítica de Projeto), desenvolvimento do cronograma, apresentação do plano de risco e definição dos padrões de qualidade da aplicação web. Em todos os tópicos serão consideradas as particularidades de um desenvolvimento de aplicação web bem como a exemplificação das principais atividades que devem ser seguidas para um bom gerenciamento de projeto, como prazos, métodos de desenvolvimento, testes e entrega do produto final, buscando sempre à proposta inicial e a entrega com qualidade. 
Palavras-chave: ASP.NET, Projeto, Aplicação, Web, Gerenciamento.
ABSTRACT
Integrated Multidisciplinary Project (IMP) of this two-month period proposed by UNIP Interactive University. It consists of the development of a web application using the ASP.NET framework for managing academic tasks (jobs, tests, complementary activities, DPs and etc). In the formatting of the work the knowledge acquired in the classes of the modules of Software Project Management, Software Development for Internet and Special Topics of Object Oriented Programming were used. In the development of the project, the issues of project scope, elaboration of the EAP (Project Analytical Structure), development of the schedule, presentation of the risk plan and definition of the quality standards of the web application were addressed. In all topics will be considered the particularities of a web application development as well as the exemplification of the main activities that must be followed for a good project management, such as deadlines, development methods, testing and delivery of the final product, always seeking the proposal initial delivery and quality delivery.
Key-words: ASP.NET, Design, Application, Web, Management.
SUMÁRIO
INTRODUÇÃO
Um bom gerenciamento de projeto resulta no desenvolvimento de um produto com qualidade. O gerenciamento de projetos no âmbito da engenharia de software tem aproximadamente 20 anos, onde a profissão de gerente de projetos vem aplicando e aperfeiçoando as ferramentas e técnicas, com base nas boas praticas de gestão de projetos publicadas a cada 4 anos no PMBOK (Project Management Body of Knowledge). 
No decorrer do gerenciamento e desenvolvimento de um projeto, precisamos seguir o que foi apresentado e aprovado pelo cliente, sempre deixando o mesmo informado através de meios de comunicação ricos. Como parte deste trabalho o desenvolvimento de uma aplicação web deve seguir um padrão de codificação, neste caso iremos utilizar a arquitetura MVC (Model, View, Controller) para tal padronização. Utilizando a linguagem ASP.NET que será apresentada no andamento deste trabalho, iremos enfatizar alguns pontos importantes do desenvolvimento de uma aplicação web. Pensar em desenvolvimento web é ter a noção básica de diversos artefatos e processos, com os protótipos, os conceitos de cores, telas, controles de navegação são provenientes de um bom planejamento, mas principalmente de analise bem efetuada. Conceitos e ideias podem ser conhecidos mundialmente por meio da internet, estar atento às essas tendências com ênfase na linguagem e nos layouts e utilizando os recursos de CSS, Javascript podem garantir o sucesso e a qualidade do desenvolvimento de uma aplicação.
 
REFERENCIAL TEÓRICO
 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Conforme nosso estudo seguindo pela linha de gerenciamento de projeto de software, um bom gerenciamento é fundamental para o sucesso ou fracasso de um projeto. 
Um Projeto é único e temporário, conforme citado por diversas vezes dentro do PMBOK. Diferente das atividades rotineiras que são permanentes e repetitivas, um projeto é um trabalho único com inicio e fim, sendo acompanhado e desenvolvido por pessoas para criação de um novo produto ou serviço. Caracterizado por (PMI, 2013): “Ter objetivo e requisitos claramente definidos, completar dentro do prazo esperado, estar dentro do orçamento definido”. 
Além da definição de projeto, existem outros conceitos importantes para entendimento relacionados às linhas que são executadas nos projetos. São divididos em 3 conceitos: Subprojeto é a divisão de um grande projeto em projetos menores com o objetivo de facilitar o gerenciamento ou para terceirizar suas partes. Programa é um grupo de projetos inter-relacionados, trata- se de tarefas repetitivas gerenciadas em conjunto, produzindo assim benefícios aos projetos. Portfólio é o conjunto de todos os projetos de um setor ou da empresa como um todo. Para atingir tais objetivos, o gerenciamento de projeto se baseia no cumprimento da tríplice restrição: escopo, prazo e custo.
Figura 1 – Tríplice restrição
Fonte: O Autor, 2017.
Em 2010 o PMI (2013) adicionou duas novas áreas de processo a esse trinômio subindo para seis áreas do conhecimento envolvidas na gestão. Foram incluídas: recursos humanos e riscos. Essa inclusão foi necessária porque de fato a gestão de riscos é extrema importância para o sucesso do projeto, pois com ela garante, a partir de medidas preventivas, a antecipação aos problemas que podem surgir evitando determinadas ocorrências e gerando economia de tempo e custo dentro do projeto. Na gestão dos recursos humanos o gerente de projetos deve ter um olhar voltado ao bem-estar da equipe de projeto mantendo assim todos motivados, envolvidos e comprometidos com o projeto a ser desenvolvido e concretizado. Com essas inclusões a visão moderna de gestão de projetos fez com que os gerentes dos projetos atuais se preocupassem com as seis áreas de conhecimento, conforme a figura 2:
Figura 2 – Visão Moderna de Gestão de Projetos
Fonte: O Autor, 2017.
 CONCEITOS BASICOS DO DESENVOLVIMENTO DE APLICAÇÕES WEB
A W3C (World Wide Web Consortium ou em português Consorcio da Teia Mundial) é o órgão responsável por definir os padrões de Desenvolvimento Web por classificar configurações e características técnicas dos web sites, indo além do visual. O principal objetivo de seguir esses padrões da W3C é possibilitar a transferência de informação pelos sites, independente do visitante ou equipamento utilizado. A seguir veremos um resumo dos principais conceitos básicos para desenvolvimento de aplicações web.
HTML e XHTML
O HTML (HyperText Markup Language) é uma das linguagens utilizadas para produzir páginas na Web que são interpretadas pelos navegadores. Os documentos HTML são arquivos de texto simples que podem ser criados, editados e manipulados em qualquer editor de textos, por exemplo, o Bloco de Notas do Windows.
Atualmente usa-se como base do Desenvolvimento Web o XHTML (Extensible Hypertext Markup Language). Ele passa a ser a estrutura de toda a informação que é visualizada na Internet, como textos, links, formulários entre outros.
CSS
A O CSS (Cascading Style Sheets) é uma linguagem de formatação simples e completa, ideal para desenvolver clara e eficiente. A CSS atua em conjuntocom a XHTML, ou seja, a XHTML depende, em essência, da CSS para formatar a estrutura dos seus códigos nos Browsers.
Server Scripting
Um dos artifícios da Internet são as Linguagens de Servidores (Server Scripting). A manipulação e o acesso dos dados armazenados em Bancos de Dados são uns dos seus principais recursos, amplamente utilizados na Internet.
Atualmente existem no mercado várias Linguagens de Servidores disponíveis. As mais populares são: ASP, JSP e PHP. Todas elas possuem suas particularidades bem como suas vantagens e desvantagens.
Banco de Dados
Para desenvolver em Server Scripting é necessário um conhecimento básico dos conceitos de Bancos de Dados Relacionais e Sistema de Gerenciamento de Banco de Dados (SGBD). Hoje os Bancos de Dados são utilizados das mais diversas formas no mundo digital, por exemplo, armazenar cadastros e informações sobre clientes, produtos de sites de Comércio Eletrônico entre outras aplicações.
APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET
Neste projeto iremos desenvolver uma aplicação web utilizando ASP.NET, um framework que utilizado pela plataforma da Microsoft, é o sucessor da linguagem ASP e permite criar páginas dinâmicas através da Framework .NET. 
O ASP.NET tem como base o Framework .NET, com todas as suas características legadas. Como toda aplicação .NET desenvolvidas para esta plataforma podem ser utilizadas várias linguagens, entre elas C# e VisualBasic.NET. Por ser uma plataforma “simples” que podem ser desenvolvidas aplicações utilizando somente um editor de texto e um compilador .NET. O Visual Studio.NET é o ambiente mais utilizado pelos desenvolvedores para construir suas aplicações em ASP.NET, pois já possui ferramentas e características que ajudam os programadores, como por exemplo os componentes visuais para elaboração de formulários de páginas web.
Por ser uma linguagem orientada a objeto, qualquer aplicação web desenvolvida em ASP.NET pode reutilizar uma parte ou todo o código de um outro projeto escrito na plataforma .NET, mesmo que o código esteja escrito em uma outra linguagem, por exemplo: uma página em ASP.NET escrita em VB.NET pode chamar os componentes escritos em C#. Ao contrário da tecnologia ASP, as aplicações desenvolvidas em ASP.NET são compiladas antes da execução, gerando um maior desempenho. Para a execução das aplicações web em ASP.NET é necessário a Framework.NET e do servidor de aplicações IIS, utilizada na plataforma Windows. Já existe um projeto em desenvolvimento de um modulo que será capaz de permitir que um servidor Apache HTTP trabalhe em conjunto com a Framework.NET para rodar aplicações ASP.NET multiplataforma.
ESCOPO DO PROJETO
O escopo do projeto é a descrição preliminar do projeto, rica em detalhes para maior abrangência e entendimento dos envolvidos, pois informa as funcionalidades esperadas além de confirmar as funções que devem fazer parte do escopo ou não. Deve identificar os riscos e pontos mais importantes do produto a ser desenvolvido. 
Esta declaração por assim dizer, deve conter os componentes detalhados a partir do escopo preliminar, que são elas: descrição detalhada do escopo, limites do projeto, entregas do projeto, premissas e restrições, organização da equipe, pontos de controle em relação a prazos, riscos iniciais identificados e as limitações financeiras. 
Quando finalizada esta declaração de escopo, deve ser apresentada ao cliente para validação. Assim compondo a linha de base de escopo do projeto, que é a formalização da compreensão do escopo entre a equipe do projeto e cliente, decidindo o será efetuado ou não dentro do projeto, as orientações básicas para realização do projeto e as referências para eventuais negociações de mudanças que possam acontecer dentro do projeto.
Abaixo podemos ver o escopo do projeto solicitado:
	UNIP Interativa 
	Nome do Projeto: Gerenciamento de Tarefas Acadêmicas
	Descrição do Escopo do Projeto (Scope Statement)
	Elaborado por: Alex do Nascimento Barbosa
 Thiago Rocha Soares
 Wanderley José da Silva
Data: 25/10/2017
Aprovado por: Diretor Executivo
 Diretor de TI
 Gerente de Projeto
Versão 1.0
Justificativa do projeto
Fica evidente que cada vez mais a vida do povo brasileiro está atribulada e o tempo cada vez mais escasso para dedicar-se a outras práticas que não seja o trabalho. Soma-se a isso os estudantes que além do trabalho, precisa se desdobrar para conciliar a vida profissional e a vida acadêmica, dessa forma, tarefas simples como controlar e administrar prazos e tarefas tem se tornado um desafio maior que o imaginado. Pensando nisso, surgiu a ideia de criar um sistema que centralize todas as atividades acadêmicas e informe ao estudante o status das mesmas e o alerte quanto ao prazo de entrega.
Produto do projeto
O projeto deve prover uma solução que permita ao aluno o cadastro das tarefas acadêmicas (trabalhos, provas, atividades complementares, DPs, entre outros) por meio de um ambiente virtual de um sistema web. Faz parte do escopo do projeto o estudo de viabilidade correspondente, em que garanta que o investimento tenha o retorno financeiro correspondente em até 3 anos. Devem ser levantados os documentos envolvidos, arquitetura de TI disponível e requisitos legais. A tecnologia utilizada deveria ser de ponta, garantindo a integridade, autenticidade e segurança das interações feitas no sistema.
Premissas
Como fontes de consulta, será integrada a equipe alunos da instituição de ensino e profissionais da área de TI.
Serão utilizadas as unidades de ensino do estado do Paraná como implantação piloto, de forma a validar a implantação do sistema.
Marcos de projeto
Estudo de viabilidade
Viabilidade Técnica
Viabilidade Financeira
Viabilidade Operacional
Viabilidade Comercial
Pesquisa
Relatório de pesquisa
Aprovação do relatório de pesquisa
Implementação
Homologação do sistema
Implantação
Implantação-piloto
Implantação nas demais unidades
Fechamento
Relatório inicial do desempenho da solução implantada
Relatório de lições aprendidas
Relatório do projeto
Aceitação do sistema
Fechamento do projeto
Exclusões do escopo
Obter assinatura digital do usuário
Levantar a necessidade de mudança/ampliação da estrutura de rede da instituição de ensino, essa necessidade deve ser analisada pela própria instituição.
Objetivos do escopo
O projeto deve ser implantado em 3 meses, utilizando até R$ 100.000,00 (cem mil reais). No início da operação deverão estar utilizando o novo sistema todos os alunos matriculados em polos do estado do Paraná, iniciando-se pela capital Curitiba e posteriormente as demais cidades do estado.
Acompanhamento do projeto
Serão realizadas reuniões quinzenais, em nível de gerência, de acompanhamento do projeto. Nessas reuniões será apresentado pelo time de projeto um relatório do desempenho do projeto, até aquele dado momento, fazendo um comparativo entre tempo e custo estimado e mensurado. 
Serão realizadas reuniões semanais, com a equipe, para acompanhamento do projeto.
Equipe de projeto
A equipe de projeto é formada por:
Gerente de Projeto
Diretor de TI
Time de desenvolvedores
Consultor especializado em Gestão de Projetos
Consultor especializado em Análise de Riscos (FMEA)
Aprovação:
São Paulo, 25 e outubro de 2017
_________________________________
Gerente de Projeto
 
_________________________________
Diretor de TI
_________________________________
Diretor Executivo
 
EAP – ESTRUTURA ANALITICA DE PROJETOS
A EAP nos dá uma melhor definição do trabalho a ser feito através de fundamentos onde os objetivos do projeto estabelecem uma estrutura de gestão para o trabalho até o seu término. Dividindo as partes podemos entenderque:
Estrutura: é algo organizado em um padrão definido na organização.
Analítica: é dividida em partes, categorias ou dividido.
Projeto: é o esforço para se alcançar um objetivo ou resultado.
Ela também nos ajuda subdividindo o trabalho do projeto em partes menores que ficam mais fáceis de gerenciar, em cada parte dividida se detalha ainda mais o trabalho do projeto, como mostrado no exemplo abaixo: 
Figura 3 – Exemplo de uma EAP
Fonte: O Autor, 2017.
A EAP facilita a elaboração do cronograma, as estimativas de custos além de mostrar uma visão estruturada e gráfica de todo o escopo do projeto e seus controles de planejamento contidos nos componentes de nível mais baixo, os chamados pacotes de trabalho. Pacotes de trabalho são os itens no mais baixo nível da estrutura analítica do projeto que contem e representam:
Um produto de entrega ao usuário.
Um único responsável pela entrega.
Uma duração máxima de 10 dias.
Os recursos necessários para a execução.
Um custo pré-estabelecido.
Critérios de aceitação do trabalho
A elaboração da EAP deve ser feita pela equipe do projeto e pelo gerente de projeto onde deve constar as orientações referentes a entrega que o projeto deve fazer. Em seu primeiro nível deve ser definido levando em consideração a estratégia adotada e antes da divisão, este nível pode ser:
Por fase do projeto, se caso o processo seja em cascata, o nível será analise, projeto, implementação e testes.
Por incremento, caso o processo adotado seja o incremental, cada incremento será uma caixa no primeiro nível.
Por fase de implantação onde se divide o projeto em partes, considerando as entregas que serão implantadas (instaladas em produção).
Por grandes entregáveis ou subprojetos neste também se divide o projeto em partes, porém cada uma corresponde somente a um item entregável do projeto.
Abaixo segue o EAP por fase do projeto seguindo o modelo em cascata:
Figura 4 – Estrutura Analítica de Projeto (EAP)
Fonte: O Autor, 2017.
 Dicionário EAP
1 – Viabilidade
1.1 – Viabilidade técnica
Tópico que obedece às características tecnológicas e naturais envolvidas num projeto. O estudo da viabilidade técnica costuma prender-se com questões de segurança e de controle.
1.2 – Viabilidade financeira
Tópico que está relacionado com os recursos financeiros existentes para executar um projeto, tendo em conta as receitas que, eventualmente, se esperam obter.
1.3 – Viabilidade operacional
Tópico que mede o grau de adequação da solução para a organização. É também uma avaliação de como as pessoas se sentem sobre o uso da solução ou do sistema.
1.4 – Viabilidade comercial
Tópico que mede o nível de engajamento da solução ou sistema no mercado e faz um estudo quanto ao retorno financeiro e se o produto tem de fato mercado para que o mesmo possa ser comercializado.
2 – Pesquisa
2.1 – Relatório de pesquisa
É o documento que mostra como o projeto foi executado, que dados foram coletados e como esses dados foram analisados e que resultados podemos extrair deles. Sendo assim, o projeto deve ser retomado no relatório, não mais como proposta de trabalho, mas como relato da realização desse trabalho.
2.2 Aprovação do relatório de pesquisa
Analise e aprovação do relatório de pesquisa. 
3 – Implementação
3.1 – Homologação do sistema
A homologação é a comprovação, pelo cliente e demais partes interessadas, de que o produto resultante do projeto de software atende aos critérios de aceite previamente estabelecidos com o cliente. Inclui elementos de verificação e de validação do produto todo ou de partes do produto selecionadas em comum acordo com o cliente e tem como meta principal a obtenção do aceite do produto. 
4 – Implantação
4.1 – Implantação piloto
Um projeto piloto ou implantação piloto é aquele no qual você experimenta novas ideias. No contexto da implementação de processos e ferramentas, significa que você experimenta um novo processo e novas ferramentas. Como consequência, você pode incluir recursos adicionais, usar pessoas chave e ajustar o orçamento e os planos de acordo. Além disso, implica uma monitoração mais cuidadosa do projeto, porque é a partir da avaliação e do estudo do projeto piloto que você começará a usar o novo processo e as ferramentas em projetos reais.
4.2 – Implantação nas demais unidades
Após a fase de implantação piloto e a aprovação de todos os requisitos dessa fase, faz-se a implantação efetiva, nesse caso específico, a implantação efetiva nas demais unidades ou estados, de acordo com o critério adotado.
5 – Fechamento
5.1 – Relatório inicial de desempenho
Normalmente, trata-se de um documento onde é evidenciado todos os aspectos referentes ao desempenho do sistema no início do seu ciclo de vida, com o intuito de levantar falhas ou melhorias a serem feitas após um período do produto em uso.
5.2 – Relatório de lições aprendidas
Lições Aprendidas é falar de qualidade e de melhoria contínua. As lições aprendidas é a base para alcançarmos a perfeição ou o nível de excelência desejado, é o alicerce para o aperfeiçoamento contínuo.
Só podemos ser melhores se aprendemos com nossos erros e nossos acertos. Eu faço e registro as Lições aprendidas em todos os meus projetos e me torno uma pessoa melhor a cada novo projeto.
5.3 – Relatório do projeto
Passadas as fases “Relatório Inicial do Projeto” e “Relatório de Lições Aprendidas”, entende-se que todos os aspectos referentes ao projeto foram assimilados e o sistema a essa altura foi devidamente refinado e ajustado. Esse é o momento de documentar a versão definitiva do projeto.
5.4 – Aceitação do sistema
Aceitação do sistema é independente do processo de desenvolvimento e é realizado por usuários finais e stakeholders antes de um produto entregue ser formalmente aceito.
5.5 – Fechamento do projeto
O fechamento de um projeto pode ser iniciado quando o controle do desempenho indicar que o escopo do projeto foi totalmente entregue, ou quando o patrocinador ou a gerência da organização solicitar o cancelamento do mesmo (se seus objetivos não forem mais pertinentes, necessários ou alcançáveis).
DESENVOLVENDO O CRONOGRAMA
Para execução do projeto e detalhamento das atividades faz é necessário e obrigatório o desenvolvimento de um cronograma, sendo ele vital para o sucesso do projeto. Seguindo o Guia PMBOK (PMI, 2013) de boas práticas, o cronograma deve ser desenvolvido em conjunto com a área ou equipe determinando as atividades com no máximo cinco dias de duração e utilizando o EAP elaborado como referência para isso. O Guia PMBOK destaca cinco atividades para auxiliar na elaboração do cronograma, conforme ilustrado na figura 5 abaixo:
Figura 5 – Atividades de Planejamento do Cronograma
Fonte: O Autor, 2017.
 Definir Atividades
Inicialmente é necessário identificar todas as atividades utilizando a EAP como base para definição das mesmas. Com a declaração de escopo e informações de projetos anteriores a ideia é de ter um conjunto de metas que atenda o escopo e os objetivos do projeto sendo além de tudo gerenciável.
 Estimativa de duração das atividades
Como o prazo é um dos grandes fatores e a base para o sucesso de um projeto, precisamos identificar cada atividade, estimando o tempo necessário para concluir cada uma, habitualmente são feitas estimativas em dias se baseando sempre na lista de atividades, informações de outros projetos e conhecimentos técnicos da equipe.
 Sequenciar as atividades
Aqui determinamos como as atividades estão pertencentes e vinculadas umas das outras, pois quanto mais vinculadas entre si, maior será a duração do projeto e será bem mais difícil controlar o prazo estimado, pois qualquer atraso em alguma das demandas pode gerar um atraso em todo o projeto. Abaixo veremos que existem três tipos básicos de dependência:
Mandatória: quando a atividade não pode ser realizada sem a conclusão da anterior.
Arbitrária: dependência atribuída pelo próprio gerente de projetos e baseia-se na limitaçãode pessoal ou nas melhores práticas para realizar tal atividade.
Externa: atividades que mesmo fora do projeto afetam diretamente a continuidade da atividade como, por exemplo, o recebimento de uma parte do software que foi terceirizada.
 Estimar recursos
Nesta fase da elaboração do cronograma, precisamos levantar e determinar quais recursos físicos (pessoal e material) será utilizado, e as quantidades de cada recurso que serão utilizadas para a realização de cada atividade do projeto. Neste caso o gerente de projetos deve analisar cada atividade para que seja alocado o recurso necessário, precisando considerar valores disponíveis dentro do projeto bem como as habilidades e conhecimentos técnicos necessários para cada recurso humano.
 Desenvolver o cronograma
O objetivo é determinar a data de início e término de cada atividade do projeto, até chegar ao final do projeto. O gerente de projeto deve levar em consideração as limitações de recursos financeiros e humanos disponíveis dentro do projeto, faz parte deste cronograma os seguintes tópicos: 
Pontos de controle (Milestones), pontos de verificação utilizados dentro do cronograma para controlar o andamento das entregas das atividades. 
Critical path method (CPM) método utilizando o cronograma com data de início e fim com base na dependência término-início. 
Folga livre ou Free Slack é o tempo livre que se pode atrasar dentro de uma atividade sem atrasar o início da próxima. 
Folga total ou Total slack que é o tempo livre de uma atividade pode se atrasar sem atrasar o prazo final do projeto. 
Caminho crítico é o processo com a mais longa duração de todo o plano de atividades do projeto onde a folga é igual a zero, ou seja, as atividades se iniciam assim que a anterior termina. 
Temos também as melhorias de prazos do cronograma que tem o intuito de reduzir o tempo dentro do cronograma, para isso duas ações devem ser tomadas, o paralelismo de atividades que consiste em verificar quais as atividades podem ser executadas em paralelo assim reduzindo o tempo do projeto, e a alocação de mais recursos que basicamente é analisar as interações entre custo e prazo de cada atividade dentro do caminho crítico, para constatar qual das atividades pode-se reduzir o prazo alocando mais recursos e tendo o menor impacto financeiro dentro do projeto. Linha de base de prazo é avaliado pelo cliente e pelos envolvidos no final da criação do cronograma. 
Abaixo o cronograma do projeto, juntamente com o gráfico Gantt obtido no aplicativo on-line https://app.smartsheet.com :
	ID
	Nome da tarefa
	Duração
	Iniciar
	Terminar
	Antecessores
	Atribuído a
	
	1. ESTUDO DE VIABILIDADE
	
	
	
	
	
	2
	1.1 Viabilidade Técnica
	2d
	01/11/17
	02/11/17
	
	Gerente de Projeto e Gerente de Infraestrutura
	3
	1.2 Viabilidade Financeira
	1d
	03/11/17
	03/11/17
	2
	Gerente de Projetos e Gerente Financeiro
	4
	1.3 Viabilidade Operacional
	2d
	06/11/17
	07/11/17
	3
	Gerente de Projetos e Equipe de Desenvolvimento
	5
	1.4 Viabilidade Comercial
	1d
	08/11/17
	08/11/17
	4
	Gerente de Projetos e Gerente Comercial
	6
	2. PESQUISA
	
	
	
	
	
	7
	2.1 Relatório de Pesquisa
	3d
	03/11/17
	07/11/17
	2
	Gerente de Projetos e Equipe Técnica
	8
	2.2 Aprovação Relatório de Pesquisa
	2d
	08/11/17
	09/11/17
	7
	Gerente de Projetos, Gerente Comercial e Cliente
	9
	3. IMPLEMENTAÇÃO
	
	
	
	
	
	10
	3.1 Homologação do Sistema
	5d
	10/11/17
	16/11/17
	8
	Analista de Testes, Gerente de Projeto e Cliente
	11
	4. IMPLANTAÇÃO
	
	
	
	
	
	12
	4.1 Implantação Piloto
	7d
	17/11/17
	27/11/17
	10
	Analista, Coordenador de Implantação, Gerente de Projetos e Cliente
	13
	4.2 Implantação nas demais Unidades
	6d
	28/11/17
	05/12/17
	12
	Analista, Coordenador de Implantação, Gerente de Projetos e Cliente
	14
	4.3 Teste Integrado
	3d
	06/12/17
	08/12/17
	13
	Analista, Coordenador de Implantação, Gerente de Projetos e Cliente
	15
	5. FECHAMENTO
	
	
	
	
	
	16
	5.1 Relatório Inicial de Desempenho
	2d
	11/12/17
	12/12/17
	14
	Gerente de Projetos
	17
	5.2 Relatório de Ações Aprendidas
	2d
	13/12/17
	14/12/17
	16
	Gerente de Projetos
	18
	5.3 Relatório do Projeto
	3d
	15/12/17
	19/12/17
	17
	Gerente de Projetos
	19
	5.4 Aceitação do Sistema
	2d
	20/12/17
	21/12/17
	18
	Gerente de Projetos e Cliente
	20
	5.5 Fechamento do Projeto
	2d
	22/12/17
	25/12/17
	19
	Analista, Gerente de Projetos, Cliente
Figura 6 – Gráfico Gantt
Fonte: O Autor, 2017.
PLANO DE RISCO
Risco – evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, âmbito ou qualidade – PMI, PMBOK Guide 2004, pag. 238.
Sempre existem riscos todos os dias em nosso cotidiano, por isso ele está presente em todos os projetos independente da área, mas seu tratamento é na maioria das vezes intuitivas, devemos procurar sempre uma abordagem proativa para antecipar a correção ou diminuir o risco. Na gestão de projetos é de grande valia a análise de riscos, pois evita danos ao projeto e aumenta a produtividade e diminui o retrabalho. Com ações preventivas dos riscos, pode-se economizar tempo e dinheiro, evitando que eles se tornem problemas (DINISMORE, 2012).
 Podemos dividir em três níveis a forma que trataremos estes riscos:
Aversão ao risco: quando não se faz nada para resolver quando existe a possibilidade de algum problema surgir.
Tolerância ao risco: é grau, quantidade ou volume de risco que uma organização ou individua irá suportar, pode ser tratado e resolvido minimizando o impacto.
Busca por risco: é uma característica extrema de exposição ao risco, onde pode gerar mais problemas do que soluções dentro do projeto.
 Gerenciamento de riscos
O gerenciamento de riscos é constituído por medidas e ações a fim de identificar, analisar e responder aos riscos, aumentando os resultados positivos e diminuindo os impactos negativos. Com isso a pró-atividade é a característica número um do gerente de projetos para tomar ações preventivas e não ações reativas que são feitas somente quando o problema já aconteceu. Abaixo uma figura ilustrando isso:
Figura 7 – Atitudes frente ao risco
Fonte: O Autor, 2017.
Seguindo uma boa gestão de riscos, os componentes que devem ser observados pelo gerente de projetos são: o evento que pode desencadear um risco, a sua probabilidade de ocorrer, a gravidade do impacto, ou suas consequências e a análise do seu nível de controle. 
Este nível de controle de um risco se estabelece a partir de quatro quadrantes, dependendo do trato do risco e sua importância, são eles:
Envolvimento do cliente e da alta administração: falta de comprometimento da alta administração, envolvimento inadequado dos envolvidos e não podem ser controlado pelo gerente de projetos. 
Escopo e Requisitos: falta de entendimento dos requisitos, gerenciamento inadequado das mudanças de escopo, podem ser altamente controlados pelo gerente de projetos. 
Execução do projeto: recursos inadequados ou insuficientes, falta de metodologia, estimativas incorretas também podem ser controlados pelo gerente de projetos. 
 Identificando os Riscos
Determinar e documentar quais são os possíveis riscos e características dentro de um projeto é de suma importância, e deve ser feito do início ao fim de um projeto, nas reuniões de posicionamento e quando houver mudanças no projeto. Este processo deve ser efetuado pelo gerente de projeto a equipe e o cliente. Os riscos podem ser identificados e analisados através de suas categorias, permitindo assim a classificação da maioria deles dentro do projeto. Segue abaixo estas categorias:
Riscos técnicos: são riscos relacionados as tecnologias empregadas e o conhecimento técnico da equipe.
Riscos organizacionais: são aqueles relacionados à estrutura da empresa que está desenvolvendo o projeto, exemplo conflitos ou metas irreais.
Riscos externos: sãogerados por fatores externos como, por exemplo, motivo de força maior.
Riscos de custos: riscos que podem afetar diretamente os custos estimados inicialmente. Exemplo custos não considerados.
Riscos de cronograma: riscos que afetam o cronograma do projeto. Exemplo erro na estimativa ou má alocação dos recursos humanos.
O Guia PMBOK (PMI, 2013), mostra algumas técnicas que podem ser utilizadas para auxiliar na identificação destes riscos, são eles: Brainstorming, entrevistas, análise SWOT, análise das premissas, análise de causa e efeito.
 Análise de impacto dos riscos
Após identificados estes riscos o passo seguinte é a análise dos riscos listados, um a um detalhadamente, para se obter o grau de periculosidade de cada um dos riscos, isto é, inserir os riscos em uma nova listagem categorizando-os e nivelando-os. 
Estas categorias irão variar de acordo com o escopo do projeto e os recursos que a empresa possui, segundo [NAKASHIMA 2004]. As mais comuns são: técnica, programática, suporte, custo e cronograma. 
Os riscos e seus níveis estão relacionados com seu grau de impacto no projeto, o nível de um risco é inversamente proporcional ao quanto de impacto negativo ele pode causar, ou seja, se o problema for um atraso na entrega do projeto ou elevação do seu custo, provavelmente o nível ficará entre um e quatro, pois é um problema grave. 
Para dar andamento a fase de análise dos riscos é preciso realizar um planejamento detalhado o suficiente para tomar as medidas necessárias caso se torne uma realidade. O ideal é que esse planejamento esteja documentado e a gerência do projeto tenha pleno conhecimento sobre ele. Segundo [PRITCHARD 2001] é necessário identificar os riscos, mas não há a necessidade de gerenciar todos, apenas os que realmente valerem a pena o esforço, essa decisão de escolha entre gerenciar um risco ou não, geralmente cabe ao gerente de projeto, apoiado pela equipe de projeto. 
Fazem parte da etapa de análise, a investigação qualitativa e quantitativa, quando se busca saber como um problema pode afetar o andamento do projeto, é uma análise qualitativa, já a quantitativa é quando se busca saber o quanto o projeto vai atrasar por conta daquele problema, ou então quanto o projeto vai custar a mais se um determinado problema não for resolvido.
 Análise qualitativa de riscos
Ao iniciar a análise qualitativa dos riscos dentro um projeto, o principal objetivo principal é obter a classificação dos riscos em categorias, bem como listas relacionando tais riscos que precisam uma resposta de curto prazo, e os riscos com baixa prioridade. Se necessário, uma análise de tendências, onde faz necessário que se responda se o projeto tende a ter sucesso ou fracasso, isso ajuda a deixar mais claro o futuro do projeto, é uma informação simples, porém muito valiosa e de difícil aceitação se for negativa, pois o gerente de projetos não iria que não seria possível a entrega do seu projeto.
 Análise quantitativa de riscos
Tem por objetivo de realizar uma análise quantitativa para obter uma análise probabilística do projeto de software e também uma lista com as prioridades de cada de riscos e suas quantidades, pois estes números irão determinar as situações. A análise quantitativa é um processo que avalia a prioridade dos riscos identificados, usando sua probabilidade de ocorrência e o impacto correspondente nos objetivos do projeto, se os riscos ocorrerem afirma [ROCHA e BELCHIOR 2004].
 Elaborando o plano de respostas aos riscos
Com os riscos já identificados, priorizados e analisados, o plano de respostas aos riscos deve criar, determinar as opções e ações para diminuir o impacto e como tratar tais riscos. Este plano de respostas deve ser elaborado junto com a equipe do projeto e os riscos devem ter pelo menos uma estratégia principal ou ação preventiva e a contingência que seria o famoso “plano B”. 
A Principal estratégia é a tomada ações para que o risco não ocorra e a contingência são as ações a serem tomadas caso o risco ocorra. Deve-se atribuir também um responsável para cada um dos riscos com liberdade de ação para que tenha uma resposta rápida. Existem quatro ações possíveis para cada risco no sentido de tratar seu impacto no projeto, evitar risco, transferir o risco, mitigar o risco e aceitar o risco. 
Evitar o risco: são ações que visam desviar do risco em função da aversão a ele, não permitindo que haja nenhuma possibilidade de ocorrer. Exemplos de ações: redução de escopo para evitar atividades alto risco, adicionar mais recursos ao projeto, adotar abordagem conservadora, evitar empresa desconhecida na terceirização. 
Transferir o risco: são as ações tomadas com o objetivo de que o risco seja tratado ou minimizado por uma terceira parte, sem eliminálo. Exemplos de ações: seguros e garantias, terceirização. 
Mitigar o risco: são ações que visam reduzir a probabilidade ou impacto do risco no projeto. Exemplos de ações: adotar um processo de desenvolvimento conhecido, elaborar protótipos de telas, utilizar redundâncias. 
Aceitar o risco: são ações que, na impossibilidade de reduzir a probabilidade ou o impacto, visam proteger o projeto dos seus agravantes. Exemplos de ações: formalizar com os envolvidos, estabelecer reservas de contingência e incluir mais tempo ou dinheiro. 
Com todos os riscos identificados, sua classificação de prioridade e as respostas com ações e contingências de cada um têm o plano de respostas aos riscos, que deve conter: 
A Descrição do risco, data limite para ser sanado o risco, o responsável por monitorar o risco, a probabilidade e impacto deste risco no projeto, a criticidade, a prioridade e as ações necessárias para que o risco não ocorra e também a contingência, caso o risco ocorra.
Abaixo o plano de risco adotado para o projeto:
Figura 8 – Plano de Risco
Fonte: O Autor, 2017.
PADRÕES DE QUALIDADE ESPERADOS
Uma das preocupações do gerente de projetos é a criação dos padrões de processos para assim garantir que o projeto atenderá as necessidades do cliente bem como satisfazê-lo em relação ao que foi investido e os requisitos de qualidade esperados. Guia PMBOK (PMI, 2013), define a qualidade como a soma total de características de uma entidade que afeta sua habilidade em satisfazer necessidades declaradas ou implícitas do cliente.
 Antes de começar um projeto
Assim que fechado um projeto, existem algumas atividades que o gerente de projeto precisa se preocupar para garantir um processo com qualidade, levando em consideração o que for definido em conjunto com a equipe para que eles se comprometam a aplicar no projeto o que foi acordado. Abaixo as principais atividades que fazem parte da qualidade dentro de um projeto: 
O ambiente de desenvolvimento deve estar preparado de acordo com as particularidades do ambiente do cliente.
Garantia da qualidade esperada pelo cliente através dos padrões estabelecidos.
Definição de procedimentos e ferramentas que irão ajudar na verificação dos padrões estabelecidos.
Definição da equipe responsável pela revisão das atividades e inspeção dos artefatos do projeto.
Definir através do cronograma as atividades referentes à qualidade.
 Ações para garantir a qualidade
Para garantir a qualidade durante a execução do projeto, algumas ações são realizadas para atender aos padrões de qualidades esperados e as principais são:
Ferramentas e padrões de verificação de qualidade.
Listagem de verificação de qualidade.
Revisões formais, por pares.
Investigação
Testes unitários
Auditoria
Estas ações em conjunto visam melhorar a qualidade durante a execução do projeto, mitigando retrabalho e a perda de tempo.
 Ações de controle de qualidade
Controle de qualidade são as ações realizadas após o produto estar pronto e tem como objetivo principal o aceite final do cliente, as principais ações são:
Testes integrados e medições, através de indicadores para medição da evolução da qualidade, isto é de suma importância para que o gerente de projetos possa verificar a evoluçãoda qualidade em relação às metas estabelecidas. 
Abaixo os padrões de qualidade estabelecidos neste projeto:
Utilizamos como método para padronização do desenvolvimento da aplicação assim gerando qualidade no produto final o método CMMI (Capability Maturity Model Integration ou em português Modelo Integrado de Capacitação e Maturidade) Desenvolvido pelo SEI (Software Engineering Institute) é uma estrutura conceitual que descreve um a um os elementos chaves dentro de um processo de software. Utilizando um caminho de melhoria evolucionária de 5 níveis de maturidade que são eles:
Nível 1 – Inicial: Basicamente é uma caixa preta, a partir dos requisitos levantados será produzido através de um meio disforme e após seu desenvolvimento espera-se que o mesmo funcione.
Nível 2 – Repetível: Já esta em vigor um sistema de gerenciamento de projeto, o processo de construção de software é uma serie de caixas pretas com pontos de verificação determinados.
Nível 3 – Definido: O desenvolvimento do software segue um processo bem definido, as funções e responsabilidades no processo estão bem definidas e entendidas, a produção do produto de software é visível através do processo de software.
Nível 4 – Gerenciado: Produto e processo de desenvolvimento de software são gerenciados quantitativamente, a gerência tem bases objetivas para tomada de decisão e é capaz de prever o desempenho dentro de limites quantificados.
Nível 5 – Otimizado: Com foco na melhoria continua do processo, mudança disciplinada é um meio de vida.
 MANUAL DE USO DO SISTEMA
Neste tópico apresentaremos um breve manual de utilização do sistema solicitado no PIM, mostrando todas telas do sistema, suas funcionalidades e modo de utilização.
O layout do sistema é completamente responsivo, o que significa que o site automaticamente se encaixa no dispositivo que for usado (PC, smartphone, tablete, etc.), apesar da apresentação das informações em tela serem diferentes dependendo do dispositivo utilizado o caminho para efetuar qualquer ação no sistema é o mesmo, por isso para facilitar a apresentação do manual utilizaremos apenas as telas apresentadas em um computador. 
Figura 9 – Sistema Responsivo
Fonte: O Autor, 2017.
 Tela Inicial
A tela inicial possui uma breve descrição do sistema, informando sua utilidade e o que ele se propõe a fazer. 
Nesta tela temos os botões “Saiba mais”, que envia o usuário a tela sobre, “Tarefas”, que exibe o relatório de tarefas cadastradas e outros dois botões, que avisam em tela ao utilizador quantas tarefas devem ser entregues no dia de hoje e quantas tarefas já passaram o dia programado para entrega (estão em atraso), que exibem o relatório de tarefas especificas do botão ao ser pressionados. 
 
Figura 10 – Tela Inicial
Fonte: O Autor, 2017.
Os botões de aviso mudam de cor baseados no atual momento em que as tarefas se encontram quando a tela é carregada, e informam a quantidade de tarefas que se encontram em determinado estado
Figura 11 – Avisos em Tela
Fonte: O Autor, 2017.
 Relatório de Tarefas
O sistema possui três relatórios diferentes, um que exibe todas as tarefas cadastradas, um que exibe apenas as tarefas com data de entrega no dia atual e outro para as tarefas que estão em atraso, porém layout de exibição desses relatórios é o mesmo, por isso neste manual mostraremos apenas o relatório que exibe todas as tarefas. 
Figura 12 – Relatório de Tarefas
Fonte: O Autor, 2017.
Nesta tela temos a possibilidade de adicionar, editar ou excluir uma tarefa no relatório. 
Para a inserção de tarefas, deve-se utilizar o botão “Adicionar tarefa”, e para excluir ou editar uma tarefa já cadastrada um dos botões ao lado da tarefa desejada, onde o botão com o desenho de um lápis é utilizado para editar uma tarefa e o botão com o desenho de uma lixeira é utilizado para excluir uma tarefa
 Adicionando uma tarefa
Nesta tela é onde adicionamos as informações da tarefa que desejamos cadastrar, sendo que todos os campos são obrigatórios e devem ser preenchidos ou o sistema não aceita a inserção da tarefa, exibindo um alerta de que o campo deve ser preenchido. 
Figura 13 – Formulário de cadastro de tarefas
Fonte: O Autor, 2017.
Após o preenchimento de todos os campos corretamente, basta pressionar o botão “Cadastrar” para que a tarefa seja inserida e o próprio sistema redireciona o usuário de volta para o relatório de tarefas onde já pode ser visualizada a tarefa recém adicionada. 
O botão “Voltar”, como o nome diz, serve para retornar ao relatório de tarefas sem efetuar nenhum novo cadastro. 
 Editando uma tarefa
Esta tela possui o mesmo layout da tela de cadastro, porém aqui podemos editar uma tarefa já cadastrada no sistema, para isso apenas é necessário modificar os campos que deseja que sejam alterados com as novas informações e após isso pressionar o botão “Salvar” 
 Excluindo uma tarefa
Após ser pressionado o botão com o desenho de uma lixeira vermelha na tela de relatório de tarefas o sistema redireciona o usuário para uma tela onde ele pode verificar a tarefa que ele selecionou para excluir e confirmar se deseja mesmo excluir esta informação do sistema. 
Figura 14 – Tela de confirmação para excluir uma tarefa
Fonte: O Autor, 2017.
Se o botão “Voltar” for pressionado a exclusão da tarefa é cancelada e o usuário é redirecionado de volta para o relatório de tarefas, porém se o botão “Deletar” for pressionado a tarefa selecionada é excluída não podendo mais ser restaurada. 
 Tela sobre
Esta tela apenas contém informações sobre o sistema e os nomes dos programadores que participaram do desenvolvimento além de nosso agradecimento por utilizar o sistema. 
Figura 15 – Tela com informações do sistema
Fonte: O Autor, 2017.
CONCLUSÃO
Com o exposto neste trabalho, concluímos que um projeto bem gerenciado com certeza terá menos problemas de prazo e custo onde estes são os grandes vilões, tanto para os que estão desenvolvendo quanto para o cliente final, já que tudo isso irá influenciar diretamente na entrega do produto e no valor, ultrapassando assim a cifra fechada inicialmente. 
O entendimento do que o cliente solicita, e o levantamento dos requisitos também ajuda nesta empreitada, o papel do gerente de projeto tem como principal função além é claro de gerenciar todo o projeto ser também a ponte entre o cliente e a equipe de projeto ajustando tudo sempre que for necessário, mantendo a equipe motivada a desenvolver um produto com qualidade sempre seguindo os padrões estabelecidos no escopo inicial bem como os padrões de processo de qualidade de software.
Obsevamos também a questão do framework .NET que é uma das mais utilizadas para o desenvolvimento de aplicações web, sendo muita pratica por já seguir alguns padrões que auxiliam na qualidade da aplicação final.
REFERÊNCIAS
ABRAHAMSSON, P. et al. New directions on agile methods: a comparative analysis. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 25, 2003, Portland. Proceedings of… Portland: IEEE, 2003
KERZNER, H. Gerenciamento de projetos: uma abordagem sistêmica para planejamento, programação e controle. São Paulo: Edgard Blucher, 2011
DINSMORE, P. C. Gerenciamento de projetos. Rio de Janeiro: Qualitymark, 2012
ROCHA, P. L.: Risk Management – Concepts and Guidance, ESI International, 2001. 
C, BELCHIOR, A. D (2004) "Mapeamento do Gerenciamento de Riscos no PMBOK, 
CMMI-SW e RUP"
RAMIREZ, F. (2010), Gerenciando Projetos de Desenvolvimento de Software com 
PMI, RUP e UML, 5ª edição. PRITCHARD, C
CMMI | CMMI. Disponível em <https://www.sei.cmu.edu/cmmi/index.cfm> Acesso em: 31 de outubro de 2017. 
ASP.NET | The ASP.NET Site. Disponível em <https://www.asp.net> Acesso em: 31 de outubro de 2017