PIM VIII Analise e desenvolvimento de sistemas

Prévia do material em texto

1 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar VIII 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
 
 
 
ANÁLISE E DESENVOLVIMENTO 
DE SISTEMAS 
APLICAÇÃO ASP.NET 
 
 
 
 
 
 
Este PIM - projeto integrado 
multidisciplinar VIII tem como objetivo 
demonstrar o desenvolvimento em 
ASP.NET de uma aplicação web para 
o gerenciamento das tarefas 
acadêmicas (trabalhos, provas, 
atividades complementares, DPs etc.) 
relacionado ao aprendizado das 
matérias Gerenciamento de Projetos 
de Software, Desenvolvimento de 
Software para Internet e Tópicos 
Especiais de Programação Orientada 
a Objetos, todos do Curso Superior de 
Tecnologia em Análise e 
Desenvolvimento de Sistemas. 
 
 
 
 
 
 
 
 
2 
 
 
 
POLO ARTUR NOGUEIRA 
2018 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar VIII 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ANÁLISE E DESENVOLVIMENTO 
DE SISTEMAS 
APLICAÇÃO ASP.NET 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 NOMES DOS ALUNOS / RA 
 
CRISTIANO FRANCISCO CONDE / RA:1765896 
3 
 
 
 
 
POLO ARTUR NOGUEIRA 
2018 
 
1. Resumo 
 
Projeto Multidisciplinar VIII. PIM VIII UNIP, 2018. 
 
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 chaves: gerenciamento, projetos, software, desenvolvimento, 
programação, tecnologia, análise e desenvolvimento de sistemas, ASP.NET, 
aplicação, web e tarefas. 
 
 
 
 
 
 
 
4 
 
 
 
2. Abstract 
 
Multidisciplinary Project VIII. PIM VIII UNIP, 2018. 
 
 
Integrated Multidisciplinary Project (IMP) of this two-month period proposed 
by UNIP Interativa University. It consists of the development of a web application using 
the ASP.NET framework for managing academic tasks (works, 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. 
 
Keywords: management, projects, software, development, programming, 
technology, systems analysis and development, ASP.NET, application, web and tasks. 
 
 
 
 
 
 
 
 
 
 
5 
 
SUMÁRIO 
1. RESUMO...............................................................................................03 
2. ABSTRACT............................................................................................04 
3. INTRODUÇÃO.......................................................................................07 
4. REFERENCIAL TEÓRICO ....................................................................09 
 4.1. Gerenciamento de Projetos de software ........................................09 
 4.2. Conceitos básicos de desenvolvimento de aplicações web ............10 
 4.2.1. HTML e XMTML ..........................................................................11 
 4.2.2. CSS .............................................................................................11 
 4.2.3. Server Scripting ...........................................................................11 
 4.2.4. Banco de Dados ..........................................................................11 
5. APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP .NET .... 12 
6. ESCOPO DO PROJETO .......................................................................13 
7. EAP – ESTRUTURA ANALITICA DE PROJETOS.................................15 
 7.1. Dicionário EAP ...............................................................................16 
8. DESENVOLVENDO CRONOGRAMA ..................................................19 
 8.1. Definir atividades ............................................................................20 
 8.2. Estimativa de duração das atividades ............................................20 
 8.3. Sequenciar as atividades ...............................................................20 
 8.4. Estimar recursos ............................................................................21 
 8.5. Desenvolver Cronograma ..............................................................21 
 
6 
 
9. PLANO DE RISCOS..............................................................................22 
 9.1. Gerenciamento de Riscos .............................................................23 
 9.2. Identificando Riscos ......................................................................24 
 9.3. Análise de impacto de Riscos........................................................24 
 9.4. Análise qualitativa de Riscos...........................................................25 
 9.5. Análise Quantitativa de Riscos.......................................................26 
 9.6. Elaborando o plano de resposta ao risco .......................................25 
10. PADRÕES DE QUALIDADE ESPERADOS.........................................28 
 10.1. Antes de iniciar um Projeto...........................................................29 
 10.2. Ações para garantir a qualidade ...................................................29 
 10.3. Ações de controle de qualidade....................................................30 
11. MANUAL DE USO DO SISTEMA ........................................................31 
 11.1. Tela inicial ....................................................................................31 
 11.2. Relatório de tarefas ......................................................................32 
 11.3. Adicionando uma tarefa................................................................33 
 11.4. Editando uma tarefa......................................................................34 
 11.5.Excluindo uma tarefa....................................................................34 
 11.6. Tela sobre ....................................................................................34 
 
12. Conclusão............................................................................................35 
13. Referências..........................................................................................36 
 
 
 
7 
 
3. 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 práticas 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 é 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, as 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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
9 
 
4. REFERENCIAL TEÓRICO 
 
4.1. 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 início e fim, sendo acompanhado 
e desenvolvido por pessoas para criação de um novo produto ou serviço. 
Caracterizado por (PM l, 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 
10 
 
 
Em 2010 0 PMI (2013) adicionou duas novas áreas de processos 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. 
4.2. Conceitos bascos 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. 
 
 
 
11 
 
 4.2.1 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. 
 
4.2.2 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 
conjunto com a XHTML, ou seja, a XHTML depende, em essência, da CSS para 
formatar a estrutura dos seus códigos nos Browsers. 
 
4.2.3 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 PRP. Todas elas possuem suas 
particularidades bem como suas vantagens e desvantagens. 
 
4.2.4 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 
12 
 
cadastros e informações sobre clientes, produtos de sites de Comércio 
Eletrônico entre outras aplicações. 
 
 
5. 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 una 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, por exemplo os componentes 
visuais para elaboração deformulá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. 
 
 
 
13 
 
6. 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: 
 
14 
 
 
UNIP Interativa
Nome do Projeto: Gerenciamento de Tarefas Acadêmicas
descrição do Escopo do Projeto (Scope Statement)
Elaborado por: Cristiano Francisco Conde
Data: 25/10/2018
Aprovado por: Diretor Executivo - Diretor de TI- Gerente de Projeto
Versão 1.0
1. 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.
2. 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 segura nça das interações feitas no sistema 
3. 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.
4. 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
5.Relatório de lições aprendidas
 Relatório do projeto
 Aceitação do sistema
 Fechamento do projeto
6. 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.
7. Objetivos do escopo
O projeto deve ser implantado em 3 meses, utilizando até R$ 100.000 (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.
8. 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 (F MEA)
Aprovação:
Artur Nogueira, 30 de outubro de 2018.
Gerente de projetos
Diretor TI
Diretor Executivo
15 
 
7. 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 entender que: 
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, 2018 
 
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 
16 
 
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 ondese 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) 
 EAP – Estrutura analítica do Projeto. 
 
Fonte: O Autor, 2018. 
7.1. Dicionário EAP 
 
1 — Viabilidade 
 
1.1 — Viabilidade técnica 
17 
 
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. E 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 
E 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 
18 
 
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 ferra 
mentas 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 petição ou o nível de excelência 
desejado, é o alicerce para o aperfeiçoamento contínuo. 
19 
 
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 documentara 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). 
 
8. DESENVOLVENDO O CRONOGRAMA 
 
Para execução do projeto e detalhamento das atividades é 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: 
 
 
 
 
 
 
20 
 
Figura 5 – atividade de Planejamento do cronograma 
 
Fonte: O autor, 2018. 
 
8.1. 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. 
 
8.2. 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. 
 
 
8.3. 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: 
21 
 
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ção de 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. 
 
 
8.4. 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. 
 
8.5. 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 projetodeve 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. 
22 
 
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 critico, 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. 
 
 
9. 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, 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 
23 
 
 
9.1. 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 proatividade é a 
características 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, 2018. 
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, 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 não pode ser controlado pelo gerente de projeto. 
Escopo e Requisitos: falta de entendimento dos requisitos, 
gerenciamento inadequado das mudanças de escopo, podem ser altamente 
controlados pelo gerente de projetos. 
24 
 
Execução do projeto: recursos inadequados ou insuficientes, falta de 
metodologia, estimativas incorretas também podem ser controladas pelo gerente 
de projetos. 
 
9.2. Identificando 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ão gerados 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. 
 
9.3. 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 
25 
 
cada um dos riscos, isto é, inserir os riscos em uma nova listagem categorizando-
os e nivelando-os. 
Estas categorias irão variar de acoco com o escopo do projeto e os 
recursos que a emprese 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á necessidade de gerenciar 
todos, apenas os que realmente valerem a pena o estorço, essa decisão de 
escolha entre gerenciar um risco ou não, geralmente cabe ao gerente projeto, 
apoiado gela 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 custara mais se um determinado problema não for resolvido. 
 
9.4. 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 curtoprazo, 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 fracassa, isso 
ajuda a deixar mais claro o futuro da 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. 
26 
 
 
9.5. 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 BELCHlOR 2004]. 
 
9.6. 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 plana 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. 
27 
 
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 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: 
 
 
 
 
 
 
 
 
 
 
 
 
 
28 
 
Figura 8 — Plano de Risco 
 
 
Fonte: O Autor, 2017. 
 
10. 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. 
 
 
 
COD SEVERIDADE DESCRIÇÃO DO RISCO PROBABILIDADE IMPACTO DESCRÇÃO DO IMPACTO CATEGORIA AÇÃO DESCRIÇÃO DA AÇÃO RESPONSÁVEL PREVISÃO COMENTÁRIOS
1 10
Não conclusão da 
solução por 
imcapacidade ou 
inabilidade técnica
2-baixa
5-Muito 
alto
Não entrega do Sistema Técnico Previnir
Contratação de 
pessoas ou empresas 
que apresentem 
garantias e históricos 
de conclusão de 
solução idênticas ao 
proposto por nós
Cristiano 
F.Conde
07 dias
2 10
Não conclusão da 
solução por falta de 
material necesssário 
ou falta de tecnologia 
necessária para o 
andamento do 
projeto.
2-baixa
5-Muito 
alto
Não entrega do Sistema
Gestão do 
Projeto
Previnir
Contratação de 
pessoas que auxilie o 
corpo técnico do 
projeto no sentido de 
fornecer todo o 
material e tecnologia 
necessários para o 
andamento do 
projeto.
Cristiano 
F.Conde
07 dias
3 12
Não entrega so 
sistema na data 
prevista.
2-baixa 3-Médio Atraso na entrega
Gestão do 
Projeto
Assumir
O risco de não 
entregar a solução na 
data prevista 
acarretará em atraso 
do desenvolvimento 
da solução, esse risco 
deve ser assumido e 
o escopoassim como 
o cronograma devem 
ser revistos 
periodicamente para 
melhor adequação 
com o andamento do 
desenvolvimento.
Cristiano 
F.Conde
Durante todo o 
periodo de 
desenvolvimento
4 6
Dificuldade de 
comunicação devido 
a distribuição 
geográfica da equipe.
4-alta 3-Médio
Atraso no cronograma do 
devido a coordenação do 
trabalho
organizacional Mitigar
Utilização de 
ferramentas para 
compartilhamento de 
documentação e 
tenteraividade entre 
os membros do 
projeto.
Cristiano 
F.Conde
Durante todo o 
periodo de 
desenvolvimento
5 12
indisponibilidade dos 
usuários das áreas 
para levantamento 
de informações 
durante a fase de 
levantamento de 
requisitos
4-alta 4-Alto
Atraso no cronograma 
devido a dificuldade de 
agendamento e 
realizações de reuniões.
organizacional Mitigar
Definir um 
responsável pela 
agenda de 
entrevistas
Cristiano 
F.Conde
Durante todo o 
periodo de 
desenvolvimento
Plano de Risco
29 
 
10.1. 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. 
 
10.2 Ações para garantir a qualidade 
 
Para garantir a qualidade durante a execução do projeto, algumas 
apõ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 
• Testesunitários 
• Auditoria 
Estas ações em conjunto visam melhorar a qualidade durante a 
execução do projeto, mitigando retrabalho e a perda de tempo. 
 
 
30 
 
10.3. 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ção da 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á está 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. 
31 
 
 
11. MANUAL DE USO DO SISTEMA 
 
Neste tópico apresentaremos cm 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: wikipedia. 
 
 
11.1. 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 
32 
 
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: Autor, 2018. 
11.2. 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: Autor, 2018. 
33 
 
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. 
 
11.3. 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: Autor, 2018. 
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 
 
 
 
 
34 
 
11.4. Editando uma tarefa 
 
Á edição das tarefas é feitas na própria página onde as tarefas se 
encontram, porém aqui podemos editar uma tarefa já cadastrada no sistema, 
para isso apenas é possível modificar os campos que ali se encontram e após 
isso pressionar o botão "Atualizar”. No caso de Não desejar proceder as 
alterações pressionar o botão "Cancelar”. 
 
11.5. Excluindo uma tarefa 
 
Na mesma tela onde se encontra as tarefas, basta clicar no botão 
excluir e a tarefa será apagada. Não é possível retroceder, caso exclua de forma 
errada é necessário que seja feito nova inclusão. 
 
 
 
11.6. Tela Sobre 
 
Esta tela apenas contém informações sobre o sistema e o nome do 
programador que participou do desenvolvimento além dos agradecimentos por 
utilizar o sistema. 
Figura 15 — Tela com informações do sistema 
 
Fonte: O Autor 2018. 
 
 
35 
 
12. 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. 
Observamos 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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
36 
 
13. Referências 
 
 
 
1.Unip Manual pim VIII : Disponivel em: 
https://ava.ead.unip.br/webapps/blackboard/content/listContent.jsp?course_id=
_23121_1&content_id=_361256_1 
Acesso em: 19 outubro de 2018. 
 
 
2.Os 4 pilares da Programação Orientada a Objetos. Disponível em: 
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-
objetos/9264 
Acesso em: 19 outubro 2018. 
 
 
3.Tópicos Especiais de POO. Disponivel em: 
https://emilioparme.wordpress.com/topicos-especiais-de-poo/ 
Acessoem : 29 outubro de 2018. 
 
4.Gestão de Projetos de Software. Disponivel em: 
https://www.devmedia.com.br/gestao-de-projetos-de-software/9143 
Acesso em: 05 novembro de 2018. 
 
5.ASP.NET I The ASP.NET Disponível em: 
https://www.asp.net/ 
Acesso em: 08 de novembro de 2018. 
 
6.Informação utilização Dev C++ em: 
 https://pl.wikipedia.org/wiki/Responsive_web_design 
 Acesso em: 15 de Novembro de 2018.