UNIP INTERATIVA

PROJETO INTEGRADO MULTIDISCIPLINAR

CURSO SUPERIOR DE TECNOLOGIA

APLICAO ASP.NET

POLO CAMPINAS
2016
 UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR
CURSO SUPERIOR DE TECNOLOGIA

APLICAO ASP.NET

Nome: Rafael de Camargo Donatto

RA : 1541725
Curso: Anlise e Desenvolvimento de Sistemas
Semestre : 3

POLO CAMPINAS
2016
 RESUMO

Este trabalho ser sobre desenvolvimento de uma aplicao MVC em asp.net para
gerenciamento de tarefas acadmicas . Ser mostrada as classes e as camadas de
controle , camada modelo e camada de apresentao
Ele ser feito em uma parte prtica que o sistema e uma parte terica , onde se
demonstrar a descrio do escopo do projeto , elaborao do EAP ,
desenvolvimento do cronograma , apresentao do plano de risco e definio dos
padres de qualidade esperados.
Sero aplicados os conhecimentos em gerenciamento de projeto , programao
orientada a objetos e desenvolvimento de software para internet.

Palavras-chave: MVC , EAP , ASP.NET , Gerenciamento de projetos .

 ABSTRACT

This work will be on developing an MVC application in asp.net for managing

academic tasks. It will show classes and control layers, layer model and presentation
layer
It will be done in a practical part which is the system and a theoretical part, where it
will demonstrate the description of the project scope, developing the WBS, schedule
development, risk plan presentation and definition of the expected quality standards.
knowledge will be applied in project management, object-oriented programming and
software development for internet

Key words: MVC , WBS , ASP.NET , Project Management.

 SUMRIO

RESUMO.................................................................................................................... III

ABSTRACT............................................................................................................... IV

1 INTRODUO ...................................................................................................... 7

2 APLICAO ASP.NET......................................................................................... 8

5 CONCLUSO ..................................................................................................... 28

REFERNCIAS ......................................................................................................... 29
 7

INTRODUO

Para a concluso do curso superior de anlise e desenvolvimento de sistemas foi

solicitado a criao de uma aplicao ASP.net , web , pelo framework .NET
utilizando o Visual Studio.
Essa aplicao web utiliza a arquitetura MVC e deve realizar o controle de tarefas
acadmicas . Ela deve conter nome da tarefa, descrio da tarefa, data da entrega e
conter um banco de dados Access.
Um requisito demandado criar o mtodo vencidas, para receber um aviso na tela
inicial a respeito da data de entrega .
Inicialmente a equipe de desenvolvimento de software composta por um gerente de
projetos , um arquiteto de software e um analista decidiram descrever o escopo do
projeto , elaborar a EAP ,desenvolver o cronograma , apresentar o plano de riscos
do projeto e definir os padres de qualidade esperados .
Nesse projeto era necessrio mapear os atores,objetivos do sistema ,identificar os
riscos e criar o cronograma e o EAP.
O desenvolvimento da aplicao se iniciou !
 8

APLICAO ASP.NET

Definir o escopo do projeto uma etapa de vital importncia, se no for feita de

forma correta o projeto est fadado ao fracasso, uma vez que o escopo que
determina o que ser feito/produzido/entregue e o que no ser tambm. Um
escopo mal estruturado levar inevitavelmente a falhas de cronograma e de
oramento, visto que os problemas decorrentes de m especificao se faro
presentes e a equipe ter que achar caminhos alternativos para execuo do
projeto.

Por fim, um escopo mal definido resulta em um cliente insatisfeito, uma vez que o
mesmo pediu X e recebeu Z, levando a uma insatisfao do executivo, do time do
projeto e do gerente. O efeito cascata disso pode ser terrvel, como uma caa s
bruxas para determinar de quem foi a culpa, quando na verdade a culpa foi do
escopo mal-definido.

Assegure-se de que todos sabem e entendem qual o objetivo do projeto e que haja
consenso sobre o resultado final do mesmo;
Oua com ateno o que seu cliente descreve;
Tente entender no o que ele lhe pede para fazer, mas sim o que ele precisa para
resolver o problema que lhe apresenta;

Descubra o que ele no quer. Muitas vezes um projeto no vai para frente por que o
escopo foca em coisas que no deveriam estar l;

Estabelea o que no vai ser feito no projeto enquanto o cliente ainda estiver
disponvel. Se ele pedir X e Y, mas voc perceber que Z e W devem ser
providenciados, mas somente W da sua responsabilidade, deixe claro que Z est
fora do escopo do projeto;
Estabelea o que ser necessrio para que o projeto seja atingido, defina os
pressupostos, de forma que todos saibam de antemo quais as necessidades
bsicas do projeto antes que elas atrapalhem seu andamento;
Seja realista quanto ao que pode ou no ser realizado, quanto mais p-no-cho o
escopo, maior a chance de sucesso do projeto;
 9

Evite o GoldPlating. Se no faz parte do escopo do projeto, no adianta tentar

agradar o cliente com aplicaes/funes firula. Elas podem acabar acarretando em
um atraso no cronograma;
No tenho medo nem pena de fazer perguntas. Pode parecer bvio para voc, mas
se no estiver absolutamente claro, pergunte;
Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunio quando o
escopo for definido, assim qualquer problema tcnico ou dvida operacional poder
ser sanada na hora, em vez de descoberta posteriormente, causando problemas
para o projeto.

Isso no cobre todas as coisas que se pode fazer para assegurar um escopo
coerente, realista e dentro das expectativas do cliente, mas deve minimizar a
quantidade de problemas que costumam ocorrer durante a elaborao do mesmo.
Usar templates tambm pode ser uma boa idia, j que elas facilitam a visualizao
do contedo e servem como guia para o que deve ser observado no processo de
definio do escopo.
GoldPlating: A adio de funes e/ou entregas num projeto que no foram
requisitadas. O GoldPlating costuma desviar as atividades de seu foco e comumente
leva ao temido ScopeCreep.

ESCOPO
Nome do Projeto: iTarefas

Introduo:

Desnvolver em ASP.NET uma aplicao web para o gerenciamento das tarefas

acadmicas que um aluno precisar para entregar para concluir o Curso.
O escopo deste projeto inclui e exclui os seguintes itens.

No Escopo:
Anlise e especificao do sistema: Ser realizada uma analise nas informaes
coletadas e atravs deste procedimento ser gerada a especificao do sistema que
ser desenvolvido. A especificao do sistema ir conter os diagramas
UML, documento com a especificao tcnica, etc.
Reunies: Reunies semanais sero elaboradas para o acompanhamento do
projeto. Cada reunio realizada ir gerar uma ata de reunio.
 10

Desenvolvimento: Desenvolvimento do sistema.

Testes: Testes do sistema desenvolvido. Sero realizados testes no ambiente de
desenvolvimento e no ambiente de produo.
Procedimento de migrao: Ser realizada a migrao dos dados atuais para o
sistema que ser desenvolvido.
Treinamento: Ser realizado um treinamento a todos os usurios que utilizaro o
sistema e para os responsveis pela infraestrutura da empresa.
Instalao: Instalao do sistema no cliente.
Relatrios: Os relatrios do sistema basicamente mostraro informaes sobre
tempo gasto em tarefas, disponibilidade da equipe ou de um usurio, com vrios
tipos de filtros. Ser extensvel a ponto de aceitar novos relatrios desenvolvidos
separadamente.

Fora do Escopo:
Aquisio de novo servidor: Aquisio e instalao de um novo servidor para
instalao do sistema.
Dados e processos de controle financeiros ou de recursos humanos.
Disponibilizar infra-estrutura fsica e lgica para funcionamento do sistema. Neste
item inclui sistemas operacionais e aplicaes definidas nos requisitos do sistema.
O sistema no far controle de informaes como valores gastos em tarefas.

Premissas do Projeto

Para que se possa identificar e estimar as tarefas requeridas e seu tempo, algumas
premissas precisam ser feitas. Baseando-se no atual conhecimento, as suposies
do projeto esto listadas abaixo. Se uma suposio torna-se invlida no final do
projeto, ento as atividades e as estimativas deveriam ser ajustadas de acordo.

Aprovao pelo cliente da anlise inicialmente elaborada para desenvolvimento do

sistema.
Pagamento da parte inicial para iniciar-se o desenvolvimento.
Restries do Projeto
Para que se possa identificar e estimar as tarefas requeridas e seu tempo, algumas
restries precisam ser identificadas. Baseando-se no atual conhecimento, as
restries do projeto esto listadas abaixo. Se uma restrio torna-se invlida no
 11

final do projeto, ento as atividades e as estimativas deveriam ser ajustadas de

acordo.

O sistema envolver apenas a equipe de desenvolvimento, no afetar outros

setores como comercial, recursos humanos, etc.
Enquanto o sistema no estiver totalmente em uso, ser mantido o processo atual
de gerenciamento de tarefas.

Deliverables Produzidas

Anlise e especificao do sistema: Documento contendo a definio do sistema

que ser desenvolvido. Este documento ser composto por diagramas UML, scripts
de gerao da base de dados, documento com a especificao tcnica, etc.
Atas de reunies: Todas as atas elaboradas durante as reunies do projeto.
Documentos de testes: Documentos utilizados pela equipe de testes contendo os
bugs relatados e as correes feitas.
Manuais: Manual de instalao para a equipe de suporte interna e manual de
usurio para os usurios do sistema.

EAP
EAP o acrnimo de Estrutura Analtica do Projeto, um recurso que tem como
principal objetivo a diviso do projeto em partes menores (tambm chamadas de
tarefas ou pacotes de trabalho). Consequentemente, estas partes se tornam mais
fceis de serem compreendidas pelos membros da equipe e gerenciadas pelo gestor
do projeto.
A estrutura organizada como a raiz de uma rvore, onde as entregas mais
abrangentes so posicionadas no topo e as mais especficas ficam na parte inferior,
agrupadas por nveis hierrquicos.
Junto Estrutura Analtica, preciso desenvolver, ainda, o dicionrio da EAP, um
importante documento auxiliar que traz informaes detalhadas sobre cada pacote
de trabalho e seus critrios de aceitao no momento da entrega.
Dizendo de uma forma bem prtica, a criao da estrutura analtica do projeto se d
a partir da identificao das principais entregas funcionais e com a subdiviso delas
em sistemas menores e subprodutos finais. Estes subprodutos so decompostos at
que possam ser atribudos a uma nica pessoa, por exemplo.
 12

Neste nvel, os pacotes de trabalho especficos necessrios para produzir as

subentregas so identificados e agrupados. O pacote de trabalho representa a lista
de tarefas para produzir a unidade especfica.

A utilizao da Estrutura Analtica do Projeto traz uma srie de benefcios, alm de

definir e organizar o trabalho do projeto. Um oramento do projeto pode ser alocado
para os nveis superiores da estrutura e oramentos dos departamentos podem ser
rapidamente calculados com base na EAP. Ao alocar as estimativas de tempo e
custo para sees especficas, tanto o cronograma, quanto o oramento, podem ser
rapidamente desenvolvidos.
Alm disso, a EAP pode ser usada para identificar riscos potenciais em um
determinado projeto. Se uma estrutura de diviso de trabalho tem um ramo que no
est bem definido, em seguida, ele representa um risco na definio do escopo.
Estes riscos devem ser monitorados e avaliados durante toda a execuo do projeto.
Ao integrar a EAP com uma estrutura de diviso organizacional, o gerente de
projetos tambm pode identificar dificuldades comunicacionais e formular um plano
de comunicao eficaz.
De acordo com o Project Management Body of Knowledge , as seguintes diretrizes
devem ser consideradas ao criar uma Estrutura Analtica do Projeto:

O nvel superior representa o produto final do projeto;

As subentregas devem conter pacotes de trabalho que so atribudos ao
departamento ou unidade da organizao;
Todos os elementos da estrutura de diviso de trabalho no precisam ser definidos
para o mesmo nvel;
O pacote de trabalho define o trabalho, a durao e os custos para as tarefas
necessrias para produzir as subentregas;
Pacotes de trabalho no devem exceder 10 dias de durao;
Pacotes de trabalho devem ser independentes uns dos outros;
Os pacotes de trabalho so nicos e no devem ser duplicados em toda a estrutura
analtica do projeto.

Decomponha a EAP em fases e atividades em nveis, que sejam fceis de serem

gerenciados;
 13

Planeje as entregas, no as aes;

Quebre os pacotes de trabalho em duraes adequadas;
Utilize modelos de EAP de projetos j finalizados, para acelerar o trabalho e
aproveitar as lies aprendidas;
Tome cuidado para que o custo do gerenciamento no seja maior que o custo da
tarefa.

Abaixo a imagem do WBS :

 14

Fonte : Autor.
 15

Cronograma

O projeto seguir durante 10 dias e cada item do EAP ir consumir 1 hora/trabalho.O

Cronograma de Projetos uma ferramenta bem mais conhecida inclusive pelos
profissionais com pouco conhecimento das tcnicas de gerenciamento de projetos.
Pode ser entendido como uma matriz que revela graficamente para cada item da
EAP, em uma escala de tempo, o perodo que deve ser realizado.A durao o
intervalo entre o incio e o trmino de uma tarefa especfica, sem levar em conta o
nmero de pessoas necessrias para que isso acontea.

Tambm podemos definir o Cronograma de Projetos como uma ferramenta de

comunicao que demonstra todo o trabalho que precisa ser feito, quais os recursos
da organizao que sero empregados e quais os prazos que precisam ser
cumpridos para que este trabalho seja realizado. Ele deve prever e refletir todos os
esforos para a entrega do projeto finalizado.
De forma extremamente visual, o cronograma exibe a sequncia de atividades que
precisa ser realizada e permite que o gestor verifique as interdependncias de
tarefas e construa seu caminho crtico para otimizar as entregas.
Dito de outra forma, com um bom cronograma possvel identificar os pontos de
tenso da iniciativa, verificar exatamente onde a equipe precisar redobrar a
ateno para no perder prazos e realizar as entregas conforme o que foi definido
no planejamento.
Alm disso, permite que o gerente possa cobrar o cumprimento de prazos e evite
conflitos com a equipe e entre os profissionais envolvidos no dia a dia do projeto.

Tanto no Cronograma de Projetos quanto na EAP, o nvel de diviso das tarefas

depender da necessidade ou da capacidade da empresa em gerenciar cada
detalhe. Um projeto de grande porte, por exemplo, no costuma ser quebrado em
tarefas muito pequenas, pois so tantas que podem se tornar impossveis de serem
controladas de perto. J projetos menores podem perfeitamente ser divididos em
pacotes menores, isso ajuda tanto na execuo quanto no controle dele.
 16

Outra diferena importante entre as duas ferramentas o seu uso durante o projeto.
A EAP rapidamente se torna um documento de consulta, a no ser que aconteam
mudanas radicais nos requisitos durante a execuo. J o cronograma uma
ferramenta mais viva, que pode sofre constantes alteraes e revises em funo
das dificuldades encontradas durante o dia a dia de execuo do projeto.

Vale ressaltar que o ideal comear o processo pela criao da EAP para que o
gerente e a equipe consigam analisar o projeto de forma mais abrangente. Isso,
porque os pacotes de trabalho da EAP contribuiro para a correta confeco do
cronograma. Ou seja, com a EAP pronta, mais fcil lanar as informaes de
forma ordenada dentro do Cronograma do Projeto.
Por fim, tambm vlido um lembrete: o gerenciamento de projetos no nenhum
bicho de sete cabeas e pode ser facilitado quando sua empresa conta com as
ferramentas tecnolgicas e metodolgicas adequadas para isso!
Logo, dispor de um bom software de gerenciamento de projetos, que as agregue
como recurso, um grande facilitador. Uma boa soluo ajuda o gestor a estruturar
todas as etapas, incluindo a definio da EAP e a elaborao e acompanhamento do
cronograma. Isso faz toda a diferena na hora de conduzir o desenvolvimento do
projeto e tambm para destacar indicadores que facilitem a mensurao dos
resultados.

Anlise de riscos

Identificao dos Riscos

A etapa de identificao dos riscos se encontra no planejamento do projeto, porm

tambm uma atividade a ser executada durante todo o desenvolvimento, s que
em menor grau de detalhe.
 17

Para uma boa identificao de riscos, pode

pode-se fazer uso de tabelas ou planilhas para
list-los,
los, h na literatura de engenharia de software abordagens que tm uma tabela
pronta de riscos externos (Tabela 1) e internos (Tabela 2), com os riscos ao
desenvolvimento de software, claro que cada organizao diferente e vai
identificar riscos particulares ao seu projeto, contudo bom ter uma boa base para
iniciar o processo de identificao.
1 causas/fenmenos naturais
2 crises polticas de uma regio ou pas
3 crises econmicas
4 Doenas
5 problemas do financiador do projeto ou do fornecedor de insumos/recursos;
6 alteraes na legislao
7 presses da organizao, da sociedade, do cliente
8 alteraes no mercado quanto s suas necessidades ou capacidade de compra
Tabela 1: Identificao dos riscos externos
1 equipamentos defeituosos
2 equipe despreparada para trabalho em grupo
3 falta de domnio tecnolgico
4 gastos excessivos
 18

5 estouro de prazo devido a falhas de desenvolvimento

estouro de prazo devido a erros no gerenciamento necessidades tecnolgicas
6
desconsideradas durante o planejamento das etapas
7 a complexidade do sistema, no devidamente percebida nas etapas iniciais
8 alteraes no escopo do projeto.
Tabela 2: Identificao dos riscos internos
Os riscos citados acima nas tabelas um e dois, que foram obtidos no livro de
[FACCIONI 2011], so genricos, servem para qualquer tipo de projeto de
desenvolvimento de software, cabe organizao, na fase de planejamento, obter
uma lista mais detalhada dos riscos de problemas que possam ocorrer dentro do seu
contexto.

Identificao de Eventos

A definio de um evento pode ser feita atravs de uma ocorrncia que podem ser
originadas atravs de fontes internas ou externas que influenciam nos objetivos de
forma positiva, negativa ou ambas.
Os eventos em potenciais, internos ou externos, que traro impacto negativo exigem
uma anlise e um planejamento de uma resposta. Tambm podemos considerar os
eventos de impacto positivo, esses representam oportunidades para ajudar os
objetivos a serem alcanados.
Com o objetivo de melhorar a anlise dos eventos, pode ser til fazer o agrupamento
por categorias. Atravs dessas informaes podemos formar uma base mais
consolidada de informaes, possvel ter uma viso melhor sobre as semelhanas,
grau de completude de seus esforos e outras informaes que iro facilitar a
identificao de riscos. As categorias podem ser feitas de acordo com as
necessidades do objetivo, alguns exemplo de classificao abaixo:

Econmicos
Meio Ambiente
Polticos
Sociais
Tecnolgicos
 19

Anlise dos riscos

Feita a identificao, o prximo passo analisar os riscos listados, um por um

detalhadamente, a fim de obter o grau de periculosidade de cada risco, isto , inserir
os riscos em uma nova lista categorizando-os e nivelando-os.
Quanto s categorias, elas variam de acordo com o escopo do projeto e os recursos
que a empresa possui, segundo [NAKASHIMA 2004], as mais comuns so: tcnica,
programtica, suporte, custo e cronograma. Os nveis de risco esto relacionados
com seu grau de periculosidade para o bom andamento do projeto, o nvel de um
risco inversamente proporcional ao quanto de dano ele pode causar, ou seja, se o
problema for atrasar a entrega do projeto ou aumentar o seu custo, provavelmente o
nvel ser entre um e quatro, pois este um problema grave.
Para dar continuao a fase de anlise dos risos preciso realizar um planejamento,
abrangente o suficiente para saber o que fazer se caso um risco venha a se tornar
uma realidade. O ideal que esse planejamento esteja documentado e a gerncia
do projeto tenha pleno conhecimento sobre o mesmo. Segundo [PRITCHARD 2001]
necessrio identificar os riscos, mas no h a necessidade de gerenciar todos,
apenas os que realmente valerem a pena o esforo, essa deciso de escolha entre
gerenciar um risco ou no, geralmente cabe ao lder, apoiado logicamente por sua
equipe tcnica. Fazem parte da etapa de anlise, a investigao qualitativa e
quantitativa, quando se busca saber como um problema pode afetar o andamento do
projeto, uma anlise qualitativa, j a quantitativa quando se busca saber o
quanto o projeto vai atrasar por conta daquele problema, ou ento quanto o projeto
vai custar a mais se um determinado problema no for resolvido.
Anlise qualitativa
Ao iniciar uma anlise qualitativa dos riscos de um projeto de software, o principal
objetivo obter uma classificao dos riscos em categorias, bem como listas
relacionando os riscos que exigiro uma resposta em curto prazo, e os com baixa
prioridade. Se possvel, uma anlise de tendncias, que nada mais do que
responder se o projeto tende a ir bem ou mau, ajuda a deixar mais claro o futuro do
desenvolvimento, uma informao simples, porm muito valiosa e de difcil
aceitao se for negativa, afinal nenhum gerente de projetos gostaria de admitir que
no fosse conseguir finalizar seu projeto.
 20

Anlise quantitativa
O objetivo de uma anlise quantitativa obter uma anlise probabilstica do projeto
de software e tambm uma lista priorizada de riscos quantificados, pois os nmeros
em determinadas situaes, dizem mais do que as palavras. A anlise quantitativa
um processo que avalia a prioridade dos riscos identificados, usando sua
probabilidade de ocorrncia e o impacto correspondente nos objetivos do projeto, se
os riscos ocorrerem afirmam [ROCHA e BELCHIOR 2004].

Planejamento de resposta

O planejamento de resposta de risco uma carta que o responsvel pelo projeto tem
na manga, se bem utilizada os problemas podem ser minimizados, o planejamento
nada mais do que se precaver para o caso de o risco se tornar realidade. Um item
importante do planejamento de resposta a exatido, no possvel prever tudo o
que pode acontecer durante o andamento do projeto, principalmente os riscos
externos relacionados a causas naturais, mas a resposta exata de o que fazer em
determinados casos ou tipos de casos pode evitar muita dor de cabea. muito
importante que o cliente tambm esteja ciente dos possveis problemas, isso pode
ser documentado j no contrato, para no haver discordncias futuras. Nem tudo se
pode falar ao cliente, at por que ele no quer saber de tudo, explicando melhor,
pode-se citar o uso de uma tecnologia qualquer, o cliente no deseja saber se ela
difcil de interpretar ou se a equipe no tem experincia com ela, o cliente quer o
produto ou servio pronto o quanto antes e com a melhor qualidade possvel. Alguns
tpicos abaixo podem ser usados para o planejamento de resposta:

Identificar riscos, causas, descrio, categoria e como pode afetar o andamento do

projeto;
Mapear o responsvel por cada risco;
Documentar o resultado dos processos de anlise quantitativa e qualitativa de riscos;
Para acordos de resposta so inclusos transferir, evitar, aceitar ou migrar, o acordo
feito para cada plano de resposta;
Qual ao especfica deve ser tomada para implantar o planejamento de resposta;
Qual o oramento e tempo para as respostas;
E, Planos de contingncia e retrocedimento.
 21

Riscos Secundrios
Podemos classific-los como um efeito colateral de uma implantao de uma
resposta. O risco secundrio tem origem aps a implantao de um planejamento de
resposta onde gera outro(s) erro(s).
Riscos Residuais
So riscos que mesmo aps a implantao de um plano de resposta continuam,
podem ser riscos sem importncia que devem ser apenas mapeados e monitorados.
Temos como exemplo alguma lei que o governo alterou que no garante mais um
procedimento, no temos autoridade nenhuma para mudar o cenrio, o mais correto
nesses casos fazer o mapeamento e monitorar.

Monitorao e controle

Os riscos no so estticos, durante a fase de desenvolvimento de um projeto de

software, pode haver mudana nos nveis de risco, um problema que no
planejamento era aparentemente pequeno pode se tornar um impeditivo para
alguma tarefa importante, por esse motivo existe a monitorao e controle.
Em se tratando de software, pode-se dizer que a constante a mudana, desde que
so idealizados na cabea de algum at o momento em que caem em desuso, os
softwares esto sempre mudando, sendo atualizados ou melhorados. Um programa
de computador assim como um automvel, precisa de manuteno, assim tambm
o gerenciamento de riscos, a cada marco do projeto faz-se necessrio reavaliar a
criticidade dos problemas presentes e futuros. Durante todo o projeto, o
monitoramento e controle est presente (Figura 2), mesmo que no se tome uma
posio imediata ao encontrar um problema ou enxergar um risco, importante
anotar e repassar para a equipe que est monitorando e controlando se houver.
 22

Figura 2: Monitoramento e controle em projetos de software. Fonte: [RAMIREZ 2010]

O processo de monitoramento e controle de riscos em projetos de software abrange
relatrios e anlises muito importantes, um bom exemplo o plano de contingncia,
o gerente de projetos precisa calcular atravs de mtodos dinmicos, o quanto de
recurso ir precisar. No decorrer do desenvolvimento, o plano pode mudar,
aumentando ou diminuindo a quantidade de recursos empenhados com a produo.
Segundo [LOSS
OSS 2007], as informaes sobre o desempenho do trabalho, aes
corretivas e relatrios de desempenho, so entradas importantes do monitoramento
e controle de riscos, com isso pode
pode-se
se dizer que no basta ter os melhores
profissionais trabalhando juntos, preciso comand-los
los e sempre verificar se esto
fazendo as coisas certas, tudo com o objetivo de finalizar o projeto com sucesso e
no tempo planejado.
 23

Controle de Mudana de Escopo

Em muitos projetos acontecem mudanas de escopo, seja qual for o motivo, existem
diversos mtodos para tentar minimizar o impacto e diminuir os riscos dessas
mudanas no projeto. A mudana de escopo tem como inicio a requisio de
mudana, que feita de forma oral ou escrita, tem origem interna ou externa e
podem ser opcional ou imposta. Exemplos das principais mudanas so:

Evento externo, que pode ser a mudana em uma lei.

Erro no detalhamento do escopo do projeto.
Implementao de um plano de contingncia.

Um ponto importante de ser analisado quando ocorre mudana de escopo so as

variaes do escopo inicial, onde vai interferir diretamente na base do projeto e vai
exigir uma ao corretiva. Dependendo da mudana, a base do projeto pode at ser
modificada refletindo as alteraes aprovadas. Para que a mudana de escopo
ocorra com sucesso, ela precisa ser planeja. Isso tudo implica em custo, prazo,
qualidade e outros objetivos do projeto, um ponto importante que precisa de cuidado
quando um projeto est sobre contrato, a mudana de escopo deve estar tambm
em todas as conformidades das clusulas relevantes do contrato.
Toda parte terica descrita at o presente momento se fez presente para a criao a
aplicao ASP.NET que ser demonstrada no arquivo anexo com toda sua
funcionalidade.
 24

CONCLUSO

Concluiu-se que utilizando os recursos da gesto de projetos , aliado ao

conhecimento prtico de programao foi possvel entregar a aplicao solicitada.
Foi observado que se deve utilizar 80% do tempo em anlise e desenvolvimento e
apdenas 20 % na programao em si , visto que o gerenciamento de projeto reduz
falhas, aumenta qualidade , evita o retrabalho e norteia o projeto..
Essa aplicao possibilita ao usurio cadastrar, excluir e alterar a tarefa, alm de
alertar o dia de sua entrega . A aplicao modifica a experincia do usurio, pois
auxilia diretamente na vida acadmica . Isso que o principal objetivo da tecnologia,
melhorar a vida de que a utiliza.
O prazo para entrega da aplicao, follow-up do escopo do projeto , respeito ao
cronograma e ao EAP foram rigorosamente observados com o acompanhamento do
gerente de projetos . Ele orienta o arquiteto de software , que por sua vez coordenou
o analista e juntos tornaram possvel a criao da aplicao asp.net.
 25

REFERNCIAS

Template Cronograma . Disponvel em

<https://drive.google.com/previewtemplate?id=0Ahx3m_vevRObdG1BMEtwaHY5dzk
5SWlFalFNQ2t0VEE&mode=public&ddrp=1#> Acessado em 09/10/2016
ASP.NET. Disponvel < https://www.asp.net/downloads>Acessado em 09/10/2016
Visual Studio. Disponvel em <https://www.microsoft.com/en-
us/download/confirmation.aspx?id=34673 >. Acessado em 08/10/2016
Project builder. Disponvel < http://www.projectbuilder.com.br/blog-
pb/entry/projetos/5-dicas-para-facilitar-a-criacao-de-uma-estrutura-analitica-de-
projeto>Acessado em 09/10/2016
Softonic. Disponvel em:<http://www.projectbuilder.com.br/blog-
pb/entry/projetos/passo-a-passo-como-construir-do-zero-um-modelo-de-projeto-
eficiente>Acessado em 13/10/2016
Estrutura Analtica do Projeto . Disponvel
em:<https://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto
l>Acessado em12/10/2016
WBS . Disponvel em <http://www.wbstool.com/> . Acessado em 10/10/2016.
NAKASHIMA, D. T. V. (2004) "Identificao de riscos em projetos de TI".

FACCIONI, M. F. (2011), Gerncia de Projetos, 4 edio.

RAMIREZ, F. (2010), Gerenciando Projetos de Desenvolvimento de Software com

PMI, RUP e UML, 5 edio. PRITCHARD, C.

L.: Risk Management Concepts and Guidance, ESI International, 2001. ROCHA, P.
C, BELCHIOR, A. D (2004) "Mapeamento do Gerenciamento de Riscos no PMBOK,
CMMI-SW e RUP".

LOSS, L. (2007) "Ps-Graduao em Segurana da Informao: Anlise de Riscos".

LMDM (2008) "Gerenciamento de Riscos".