Escolar Documentos
Profissional Documentos
Cultura Documentos
Pim Viii Rafa
Pim Viii Rafa
APLICAÇÃO ASP.NET
POLO CAMPINAS
2016
UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR
CURSO SUPERIOR DE TECNOLOGIA
APLICAÇÃO ASP.NET
POLO CAMPINAS
2016
RESUMO
Este trabalho será sobre desenvolvimento de uma aplicação MVC em asp.net para
gerenciamento de tarefas acadêmicas . Será mostrada as classes e as camadas de
controle , camada modelo e camada de apresentação
Ele será feito em uma parte prática que é o sistema e uma parte teórica , onde se
demonstrará a descrição do escopo do projeto , elaboração do EAP ,
desenvolvimento do cronograma , apresentação do plano de risco e definição dos
padrões de qualidade esperados.
Serão aplicados os conhecimentos em gerenciamento de projeto , programação
orientada a objetos e desenvolvimento de software para internet.
RESUMO.................................................................................................................... III
ABSTRACT............................................................................................................... IV
1 INTRODUÇÃO ...................................................................................................... 7
2 APLICAÇÃO ASP.NET......................................................................................... 8
5 CONCLUSÃO ..................................................................................................... 28
REFERÊNCIAS ......................................................................................................... 29
7
INTRODUÇÃO
APLICAÇÃO ASP.NET
Definir o escopo do projeto é uma etapa de vital importância, se não 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 não será também. Um
escopo mal estruturado levará inevitavelmente a falhas de cronograma e de
orçamento, visto que os problemas decorrentes de má especificação se farão
presentes e a equipe terá que achar caminhos alternativos para execução 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 insatisfação do executivo, do time do
projeto e do gerente. O efeito cascata disso pode ser terrível, como uma caça à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;
Ouça com atenção o que seu cliente descreve;
Tente entender não o que ele lhe pede para fazer, mas sim o que ele precisa para
resolver o problema que lhe apresenta;
Descubra o que ele não quer. Muitas vezes um projeto não vai para frente por que o
escopo foca em coisas que não deveriam estar lá;
Estabeleça o que não vai ser feito no projeto enquanto o cliente ainda estiver
disponível. 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;
Estabeleça o que será necessário para que o projeto seja atingido, defina os
pressupostos, de forma que todos saibam de antemão quais as necessidades
básicas do projeto antes que elas atrapalhem seu andamento;
Seja realista quanto ao que pode ou não ser realizado, quanto mais “pé-no-chão” é o
escopo, maior a chance de sucesso do projeto;
9
Evite o GoldPlating. Se não faz parte do escopo do projeto, não adianta tentar
agradar o cliente com aplicações/funções ‘firula’. Elas podem acabar acarretando em
um atraso no cronograma;
Não tenho medo nem pena de fazer perguntas. Pode parecer óbvio para você, mas
se não estiver absolutamente claro, pergunte;
Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunião quando o
escopo for definido, assim qualquer problema técnico ou dúvida operacional poderá
ser sanada na hora, em vez de descoberta posteriormente, causando problemas
para o projeto.
Isso não 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 elaboração do mesmo.
Usar templates também pode ser uma boa idéia, já que elas facilitam a visualização
do conteúdo e servem como guia para o que deve ser observado no processo de
definição do escopo.
GoldPlating: A adição de funções e/ou entregas num projeto que não foram
requisitadas. O GoldPlating costuma desviar as atividades de seu foco e comumente
leva ao temido ScopeCreep.
ESCOPO
Nome do Projeto: iTarefas
Introdução:
No Escopo:
Análise e especificação do sistema: Será realizada uma analise nas informações
coletadas e através deste procedimento será gerada a especificação do sistema que
será desenvolvido. A especificação do sistema irá conter os diagramas
UML, documento com a especificação técnica, etc.
Reuniões: Reuniões semanais serão elaboradas para o acompanhamento do
projeto. Cada reunião realizada irá gerar uma ata de reunião.
10
Fora do Escopo:
Aquisição de novo servidor: Aquisição e instalação de um novo servidor para
instalação do sistema.
Dados e processos de controle financeiros ou de recursos humanos.
Disponibilizar infra-estrutura física e lógica para funcionamento do sistema. Neste
item inclui sistemas operacionais e aplicações definidas nos requisitos do sistema.
O sistema não fará controle de informações 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 suposições
do projeto estão listadas abaixo. Se uma suposição torna-se inválida no final do
projeto, então as atividades e as estimativas deveriam ser ajustadas de acordo.
Deliverables Produzidas
EAP
EAP é o acrônimo de Estrutura Analítica do Projeto, um recurso que tem como
principal objetivo a divisão do projeto em partes menores (também chamadas de
tarefas ou pacotes de trabalho). Consequentemente, estas partes se tornam mais
fáceis 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 são posicionadas no topo e as mais específicas ficam na parte inferior,
agrupadas por níveis hierárquicos.
Junto à Estrutura Analítica, é preciso desenvolver, ainda, o dicionário da EAP, um
importante documento auxiliar que traz informações detalhadas sobre cada pacote
de trabalho e seus critérios de aceitação no momento da entrega.
Dizendo de uma forma bem prática, a criação da estrutura analítica do projeto se dá
a partir da identificação das principais entregas funcionais e com a subdivisão delas
em sistemas menores e subprodutos finais. Estes subprodutos são decompostos até
que possam ser atribuídos a uma única pessoa, por exemplo.
12
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 técnicas de gerenciamento de projetos.
Pode ser entendido como uma matriz que revela graficamente para cada item da
EAP, em uma escala de tempo, o período que deve ser realizado.A duração é o
intervalo entre o início e o término de uma tarefa específica, sem levar em conta o
número de pessoas necessárias para que isso aconteça.
Outra diferença importante entre as duas ferramentas é o seu uso durante o projeto.
A EAP rapidamente se torna um documento de consulta, a não ser que aconteçam
mudanças radicais nos requisitos durante a execução. Já o cronograma é uma
ferramenta mais viva, que pode sofre constantes alterações e revisões em função
das dificuldades encontradas durante o dia a dia de execução do projeto.
Vale ressaltar que o ideal é começar o processo pela criação 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 contribuirão para a correta confecção do
cronograma. Ou seja, com a EAP pronta, é mais fácil lançar as informações de
forma ordenada dentro do Cronograma do Projeto.
Por fim, também é válido um lembrete: o gerenciamento de projetos não é nenhum
bicho de sete cabeças e pode ser facilitado quando sua empresa conta com as
ferramentas tecnológicas e metodológicas adequadas para isso!
Logo, dispor de um bom software de gerenciamento de projetos, que as agregue
como recurso, é um grande facilitador. Uma boa solução ajuda o gestor a estruturar
todas as etapas, incluindo a definição da EAP e a elaboração e acompanhamento do
cronograma. Isso faz toda a diferença na hora de conduzir o desenvolvimento do
projeto e também para destacar indicadores que facilitem a mensuração dos
resultados.
Análise de riscos
Identificação de Eventos
A definição de um evento pode ser feita através de uma ocorrência que podem ser
originadas através de fontes internas ou externas que influenciam nos objetivos de
forma positiva, negativa ou ambas.
Os eventos em potenciais, internos ou externos, que trarão impacto negativo exigem
uma análise e um planejamento de uma resposta. Também podemos considerar os
eventos de impacto positivo, esses representam oportunidades para ajudar os
objetivos a serem alcançados.
Com o objetivo de melhorar a análise dos eventos, pode ser útil fazer o agrupamento
por categorias. Através dessas informações podemos formar uma base mais
consolidada de informações, é possível ter uma visão melhor sobre as semelhanças,
grau de completude de seus esforços e outras informações que irão facilitar a
identificação de riscos. As categorias podem ser feitas de acordo com as
necessidades do objetivo, alguns exemplo de classificação abaixo:
Econômicos
Meio Ambiente
Políticos
Sociais
Tecnológicos
19
Análise quantitativa
O objetivo de uma análise quantitativa é obter uma análise probabilística do projeto
de software e também uma lista priorizada de riscos quantificados, pois os números
em determinadas situações, dizem mais do que as palavras. 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 afirmam [ROCHA e BELCHIOR 2004].
Planejamento de resposta
O planejamento de resposta de risco é uma carta que o responsável 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 exatidão, não é possível 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 cabeça. É muito
importante que o cliente também esteja ciente dos possíveis problemas, isso pode
ser documentado já no contrato, para não haver discordâncias futuras. Nem tudo se
pode falar ao cliente, até por que ele não quer saber de tudo, explicando melhor,
pode-se citar o uso de uma tecnologia qualquer, o cliente não deseja saber se ela é
difícil de interpretar ou se a equipe não tem experiência com ela, o cliente quer o
produto ou serviço pronto o quanto antes e com a melhor qualidade possível. Alguns
tópicos abaixo podem ser usados para o planejamento de resposta:
Riscos Secundários
Podemos classificá-los como um efeito colateral de uma implantação de uma
resposta. O risco secundário tem origem após a implantação de um planejamento de
resposta onde gera outro(s) erro(s).
Riscos Residuais
São riscos que mesmo após a implantação de um plano de resposta continuam,
podem ser riscos sem importância que devem ser apenas mapeados e monitorados.
Temos como exemplo alguma lei que o governo alterou que não garante mais um
procedimento, não temos autoridade nenhuma para mudar o cenário, o mais correto
nesses casos é fazer o mapeamento e monitorar.
Monitoração e controle
Em muitos projetos acontecem mudanças de escopo, seja qual for o motivo, existem
diversos métodos para tentar minimizar o impacto e diminuir os riscos dessas
mudanças no projeto. A mudança de escopo tem como inicio a requisição de
mudança, que é feita de forma oral ou escrita, tem origem interna ou externa e
podem ser opcional ou imposta. Exemplos das principais mudanças são:
CONCLUSÃO
REFERÊNCIAS
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".