UNIP INTERATIVA PIM VIII

Prévia do material em texto

UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
PIM VIII 
SOFTWARE PARA GERENCIAMENTO DE TAREFAS ACADÊMICAS 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIP INTERATIVA – POLO BOQUEIRÃO 
2018 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
PIM VIIi 
SOFTWARE PARA GERENCIAMENTO DE TAREFAS ACADÊMICAS 
 
 
Hélio José Miguel de Andrade 
RA: 1773923 
Curso: Analise e Desenvolvimento de Sistemas 
Semestre: 04/2018 
 
 
 
 
 
 
UNIP INTERATIVA – POLO BOQUEIRÃO 
2018 
Resumo 
Este projeto tem o objetivo de apresentar o escopo, a EAP, o plano de risco 
e os padrões de qualidade de uma aplicação para gerenciamento de atividades 
acadêmicas e entregar o software produzido através desse gerenciamento em 
ASP.NET com banco de dados Microsoft Access. Durante o projeto foi contruído o 
escopo com os requisitos de negócio e do cliente, cronograma definido as atividades 
do projeto e distribuindo as responsabilidades, o plano de risco para tomar ações de 
mitigação e contingência diante dos riscos identificados no projeto e os padrões de 
qualidade esperados, responsabilizando membros da equipe por inspecionar e 
validar atividades do projeto. Desenvolveu-se a aplicação em ASP.NET inicando-se 
na fase de coleta de requisitos, seguindo com o projeto, implementação e teste 
dentro do processo de gerenciamento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras-chave: Sistema, controle, matricula, continuidade, projeto, fase, analise e 
design. 
Abstract 
In this project, the design phase was developed for a free course registration 
control system, following the assumptions that the design of the registration control 
system has already been initiated by a professional who does not continue. 
Therefore the continuity of the project form the analysis phase to the design phase, is 
the responsibility of the members of the multidisciplinary integrating project. 
 
. 
 
 
 
 
 
 
 
 
 
Key words: System, control, registration, continuity, design, phase and analysis. 
SUMÁRIO 
1. INTRODUÇÃO 7 
2. REFERENCIAL TEÓRICO 8 
 2.1 Gerenciamento de Projetos de Software 8 
 2.2 Conceitos Básicos do Desenvolvimento de Aplicações Web 9 
 2.2.1 HTML e XHTML 10 
 2.2.2 CSS 11 
 2.2.3 Server Scripting 11 
 2.2.4 Banco de Dados 11 
3 APLICAÇÃO WEB PARA TAREFAS ACADÊMICAS EM ASP.NET 12 
4. ESCOPO DO PROJETO 13 
5. EAP – ESTRUTURA ANALITICA DE PROJETOS 16 
 5.1 Dicionário EAP 18 
6. DESENVOLVENDO O CRONOGRAMA 21 
 6.1 Definir Atividades 21 
 6.2 Estimativa de duração das atividades 22 
 6.3 Sequenciar atividades 23 
 6.4 Estimar recursos 24 
 6.5 Desenvolver o cronograma 25 
7. PLANO DE RISCO 14 
8. PADRÕES DE QUALIDADE ESPERADOS 15 
9. MANUAL DE USO DO SISTEMA 22 
 9.1 Tela Inicial 23 
 9.2 Relatório de Tarefas 23 
 9.3 Adicionando uma Tarefa 23 
 9.4 Editando uma Tarefa 24 
 9.5 Excluindo uma Tarefa 25 
10. CONCLUSÃO 25 
13. REFERENCIAS BIBLIOGRAFICAS 26 
7 
 
1 - 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 em boas 
práticas de gestão de projetos. 
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 em detalhes. 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 de camadas, 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 a essas tendências com 
ênfase na linguagem e nos layouts e utilizando os recursos de C# para garantir o 
sucesso e qualidade do desenvolvimento de uma aplicação. 
 
 
 
 
 
 
 
8 
 
2 – REFERENCIAL TEÓRICO 
2.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 do 
projeto. 
O projeto é único e temporário, 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 a criação de um novo produto ou 
serviço. 
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, são 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. 
2.2 Conceitos Básicos do Desenvolvimento de Aplicações WEB 
A W3C (World Wide Web Consortium ou Consórcio 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 do web sites, indo além do visual. O 
principal objetivo de seguir esses padrões da W3C é possibilitar a transferência de 
informações pelos sites, independente do visitante ou equipamento utilizado. A 
seguir veremos um resumo dos principais conceitos básicos para desenvolvimento 
de aplicações web. 
2.2.1 HTML e XHTML 
9 
 
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, como o bloco de notas do Windows por exemplo. 
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. 
2.2.2 CSS 
O CSS (Cascading Style Sheets) é uma linguagem de formatação simples e 
completa, ideal para desenvolver com eficiência e clareza. O CSS atua em conjunto 
com o XHTML, ou seja, o XHTML depende, em essência, da CSS para formatar a 
estrutura dos seus códigos nos Browsers. 
2.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 armazenadas em banco 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. 
2.2.4 Banco de Dados 
Para desenvolver em Server Scripting é necessário um conhecimento básico 
dos conceitos de Banco 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, armazenar cadastros e informações sobre clientes, 
produtos de sites de comercio são alguns exemplos. 
 
 
10 
 
3 – 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 der 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 possui ferramentas e características que ajudam os programadores, 
como por exemplos os componentes visuais para elaboração de formulários de 
paginas web. 
Por ser uma linguagem orientada a objeto, qualquer aplicação web 
desenvolvida em ASP.NET pode reutilizar uma parte ou um todo do código de um 
outro projeto, que tenha sido escrito na plataforma .NET, mesmo que o código esteja 
escrito em 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 o 
Framework.NET para rodar aplicações ASP.NET multiplataforma. 
 
 
 
 
11 
 
4 – 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 dos 
projetos, 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 que 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. 
 
 
 
 
 
 
 
 
 
12 
 
5 – 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. 
 
1 Fonte: Autor 
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; 
13 
 
 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 de cascata: 
14 
 
 
2 Fonte: Autor 
5.1 Dicionário EAP 
 1 – Viabilidade 
1.1 – Viabilidade Técnica 
Tópico que obedece às características tecnológicas e naturais envolvidas em 
um projeto. O estudo da viabilidade técnica costuma prender-se em questões 
de segurança e 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 
15 
 
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 
Análise 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 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 novasferramentas. 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 
16 
 
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 são evidenciados todos os 
aspectos referentes ao desempenho do sistema no inicio 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 continua. 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 continuo. 
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 já foram 
assim 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 
17 
 
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. 
 
 
 
 
 
 
 
6 – DESNVOLVENDO 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. 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. 
18 
 
 
3 Fonte: Autor 
6.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. 
6.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 linha de atividades, informações de outros projetos e conhecimentos 
técnicos da equipe. 
6.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. Existem três tipos 
básicos de dependência: 
19 
 
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 terceirizado. 
6.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. 
6.5 – Desenvolver o Cronograma 
O objetivo é determinar a data de inicio e termino 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), metodo utilizando o cronograma com data de 
inicio e fim com base na dependência término-inicio. 
Folga livre ou Free Slack, é o tempo livre que se pode atrasar dentro de 
uma atividade sem atrasar o inicio da próxima. 
Folga total ou Total Slack, que é o tempo livre que uma atividade pode 
atrasar sem atrasar o prazo final do projeto. 
20 
 
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. 
 
 
 
 
 
 
 
 
7 – PLANO DE RISCO 
 
Em todos os dias do nosso cotidiano existem riscos, por isso ele esta 
presente também 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 
21 
 
grande valia a analise de riscos, pois evita danos ao projeto e aumenta a 
produtividade e diminui o retrabalho. 
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 individuo 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. 
7.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 pró-atividade é a característica 
numero 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. 
 
Figura 4 Fonte: Autor 
 
 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, 
22 
 
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 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 controlados 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. 
7.2 – 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, pela equipe e também 
pelo 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 as 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, conflitos e metas irreais são alguns 
exemplos. 
 Riscos de Custos, riscos que podem afetar diretamente os custos estimados 
inicialmente, como custos não considerados. 
23 
 
 Riscos de Cronograma, Riscos que afetam o cronograma do projeto, uma 
estimativa errada ou uma má alocação dos recursos humanos. 
7.3 – Análise de Impacto dos Riscos 
 Após identificados estes riscos, o passo seguinte é a análise dos riscos 
listados, um a um, 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. 
 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 ficara entre um e quatro, 
pois é um problema grave. 
 Para dar andamento a fase de analise 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 
gerencia do projeto tenha pleno conhecimento sobre ele. 
 Fazem parte da etapa de analise, 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. 
7.4 – Análise Qualitativa de Riscos 
 Ao iniciar a análise qualitativa dos riscos em um projeto, o principal objetivo é 
obter a classificação dos riscos em categorias, bem como listas relacionando os 
riscos que precisam de uma resposta a 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. 
7.5 – Análise Quantitativa de Riscos 
24 
 
 Tem o objetivo de realizar uma análise quantitativa para obter uma 
probabilidade do projeto de software e também uma lista com as prioridades de cada 
risco e suas quantidades, pois estes números irão determinar as situações. 
7.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 tratar 
os 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 de ações para que os riscos não ocorram e 
a contingência são as ações a serem tomadas caso os riscos ocorram. 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. Redução de escopo para evitar atividades de alto risco, 
adicionar mais recursos ao projeto, adotar abordagem conservadora, 
evitar empresa desconhecida na terceirização são alguns exemplos. 
 Transferir o Risco, são ações tomadas com o objetivo de que o risco 
seja tratado ou minimizado por uma terceira parte, sem eliminá-lo. 
Seguros, garantias e terceirização. 
 Mitigar o Risco, são ações que visam reduzir a probabilidade ou 
impacto do risco no projeto. Exemplo 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. Formalizar com os envolvidos, estabelecer reservas de 
contingência e incluir mais tempo ou dinheiro são os exemplos. 
25 
 
Com todos os riscos identificados, sua classificação de prioridade e as 
respostas com ações e contingências de cada um ter um plano de 
respostas aos riscos, devem conter a descrição do risco, data limite para 
ser sanado, 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. 
 
 
 
 
 
 
 
 
 
8 – 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 satisfazer em relação ao que foi investido e os requisitos de qualidades 
esperados. 
8.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 
26 
 
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. 
 
8.2 – 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çãode 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. 
 
8.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: 
27 
 
 Testes integrados e medições, através de indicadores para medição da 
evolução da qualidade, é de suma importância para que o gerente de projetos possa 
verificar a evolução da qualidade em relação às metas estabelecidas. 
 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) 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 evolucionaria 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 dentro de um sistema de 
gerenciamento de projeto, o processo de construção de software é 
uma série de caixas pretas com pontos de verificação determinados. 
 Nível 3 – Deifinido: 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 quantitativos. 
 Nível 5 – Otimizado: Com foco na melhoria continua do processo, 
mudança disciplinada é um meio de vida. 
 
 
 
 
28 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
9 – MANUAL DE USO DO SISTEMA 
 
Neste tópico apresentaremos um breve manual de utilização do sistema 
solicitado no PIM VIII, mostrando todas as telas do sistema, suas funcionalidades e 
modo de utilização. 
9.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. 
 Temos o botão “inicio”, que envia o usuário de volta para a tela inicial, e o 
botão “tarefas”, que exibe o relatório de tarefas cadastradas. 
29 
 
 
Figura 5 Fonte: Autor 
 
9.2 – 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. 
 
 
 Após o preenchimento de todos os campos corretamente, basta pressionar o 
botão “Adicionar” para que a tarefa seja inserida. 
30 
 
 
Figura 6 Fonte: Autor 
 
9.3 – Editando uma Tarefa 
 Esta mesma tela possui onde é feito o cadastro das tarefas, pode editar a 
tarefa já cadastrada no sistema, para isso apenas é necessário clicar no botão com 
o desenho de um lápis e papel, modificar os campos que deseja que sejam 
alterados com as novas informações e após isso clicar no botão “Adicionar”. 
9.4 – Excluindo uma Tarefa 
31 
 
 Para excluir uma tarefa, basta clicar no botão com o desenho de uma lixeira 
vermelha na tela de tarefas, o sistema sem aviso prévio irá sumir com a tarefa, 
cuidado ao manusear, já que uma vez excluído não terá como desfazer. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 – CONCLUSÃO 
 
Com o exposto neste trabalho, concluí que um projeto bem gerenciado com 
certeza terá menos problemas de prazo e custo onde estes são os grandes “vilões”, 
32 
 
tanto para os que estão desenvolvendo quanto para o cliente final, já que tudo isso 
influenciará diretamente na entrega do produto. 
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 do 
software. 
Observei também a questão do framework .NET que é uma das mais 
utilizdas para o desenvolvimento de aplicações WEB, sendo muito prática por já 
seguir alguns padrões que auxiliam na qualidade da aplicação final. 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIAS BIBLIOGRAFICAS 
O QUE É GERENCIAMENTO DE PROJETOS. Disponível em: 
https://escritoriodeprojetos.com.br/o-que-e-gerenciamento-de-projetos Acessado em: 
01/11/2018. 
33 
 
GESTÃO DE PROJETOS: O QUE É E TUDO SOBRE COMO GERENCIAR 
PROJETOS. Disponível em: https://artia.com/blog/gestao-de-projetos-o-que-e-para-que-
serve/ Acessado em: 01/11/2018. 
GERENCIAMENTO DOS RISCOS DO PROJETO. Disponível em: 
https://escritoriodeprojetos.com.br/gerenciamento-dos-riscos-do-projeto Acessado 
em: 05/11/2018. 
GERENCIANDO PROJETOS DE SOFTWARE COM RUP E PMBOK. Disponível em: 
http://www.unibratec.edu.br/tecnologus/wp-content/uploads/2006/08/n1_castor2.pdf Acessado 
em: 17/11/2018. 
CMMI: UMA VISÃO GERAL. Disponível em: https://www.devmedia.com.br/cmmi-
uma-visao-geral/25425 Acessado em 07/11/2018. 
ASP.NET. Disponível em: https://www.asp.net/ Acessado em 01/11/2018.