UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSO SUPERIOR DE TECNOLOGIA
APLICAÇÃO ASP.NET
POLO CAMPINAS 2016
UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSO SUPERIOR DE TECNOLOGIA
APLICAÇÃO ASP.NET Nome: Rafael de Camargo Donatto RA
: 1541725
Curso: Análise e Desenvolvimento de Sistemas Semestre : 3
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.
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.
SUMÁRIO
RESUMO.................................................................................................................... III ABSTRACT............................................................................................................... IV 1
INTRODUÇÃO ...................................................................................................... 7
2
APLICAÇÃO ASP.NET......................................................................................... 8
5
CONCLUSÃO ..................................................................................................... 28
REFERÊNCIAS ......................................................................................................... 29
7
INTRODUÇÃO
Para a conclusão do curso superior de análise e desenvolvimento de sistemas foi solicitado a criação de uma aplicação ASP.net , web ,
pelo framework .NET
utilizando o Visual Studio. Essa aplicação web utiliza a arquitetura MVC e deve realizar o controle de tarefas acadêmicas . Ela deve conter nome da tarefa, descrição da tarefa, data da entrega e conter um banco de dados Access. Um requisito demandado é criar o método 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 padrões de qualidade esperados . Nesse projeto era necessário mapear os atores,objetivos do sistema ,identificar os riscos e criar o cronograma e o EAP. O desenvolvimento da aplicação se iniciou !
8
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: Desnvolver em ASP.NET uma aplicação web para o gerenciamento das tarefas acadêmicas que um aluno precisará para entregar para concluir o Curso. O escopo deste projeto inclui e exclui os seguintes itens. 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
Desenvolvimento: Desenvolvimento do sistema.
Testes: Testes do sistema desenvolvido. Serão realizados testes no ambiente de desenvolvimento e no ambiente de produção.
Procedimento de migração: Será realizada a migração dos dados atuais para o sistema que será desenvolvido.
Treinamento: Será realizado um treinamento a todos os usuários que utilizarão o sistema e para os responsáveis pela infraestrutura da empresa.
Instalação: Instalação do sistema no cliente.
Relatórios: Os relatórios do sistema basicamente mostrarão informações sobre tempo gasto em tarefas, disponibilidade da equipe ou de um usuário, com vários tipos de filtros. Será extensível a ponto de aceitar novos relatórios desenvolvidos separadamente. 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.
Aprovação pelo cliente da análise inicialmente elaborada para desenvolvimento do sistema.
Pagamento da parte inicial para iniciar-se o desenvolvimento. Restrições do Projeto Para que se possa identificar e estimar as tarefas requeridas e seu tempo, algumas restrições precisam ser identificadas. Baseando-se no atual conhecimento, as restrições do projeto estão listadas abaixo. Se uma restrição torna-se inválida no
11
final do projeto, então as atividades e as estimativas deveriam ser ajustadas de acordo.
O sistema envolverá apenas a equipe de desenvolvimento, não afetará outros setores como comercial, recursos humanos, etc.
Enquanto o sistema não estiver totalmente em uso, será mantido o processo atual de gerenciamento de tarefas. Deliverables Produzidas
Análise e especificação do sistema: Documento contendo a definição do sistema que será desenvolvido. Este documento será composto por diagramas UML, scripts de geração da base de dados, documento com a especificação técnica, etc.
Atas de reuniões: Todas as atas elaboradas durante as reuniões do projeto.
Documentos de testes: Documentos utilizados pela equipe de testes contendo os bugs relatados e as correções feitas.
Manuais: Manual de instalação para a equipe de suporte interna e manual de usuário para os usuários do sistema. 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
Neste nível, os pacotes de trabalho específicos necessários para produzir as subentregas são identificados e agrupados. O pacote de trabalho representa a lista de tarefas para produzir a unidade específica. A utilização da Estrutura Analítica do Projeto traz uma série de benefícios, além de definir e organizar o trabalho do projeto. Um orçamento do projeto pode ser alocado para os níveis superiores da estrutura e orçamentos dos departamentos podem ser rapidamente calculados com base na EAP. Ao alocar as estimativas de tempo e custo para seções específicas, tanto o cronograma, quanto o orçamento, podem ser rapidamente desenvolvidos. Além disso, a EAP pode ser usada para identificar riscos potenciais em um determinado projeto. Se uma estrutura de divisão de trabalho tem um ramo que não está bem definido, em seguida, ele representa um risco na definição do escopo. Estes riscos devem ser monitorados e avaliados durante toda a execução do projeto. Ao integrar a EAP com uma estrutura de divisão organizacional, o gerente de projetos também pode identificar dificuldades comunicacionais e formular um plano de comunicação eficaz. De acordo com o Project Management Body of Knowledge , as seguintes diretrizes devem ser consideradas ao criar uma Estrutura Analítica do Projeto:
O nível superior representa o produto final do projeto;
As subentregas devem conter pacotes de trabalho que são atribuídos ao departamento ou unidade da organização;
Todos os elementos da estrutura de divisão de trabalho não precisam ser definidos para o mesmo nível;
O pacote de trabalho define o trabalho, a duração e os custos para as tarefas necessárias para produzir as subentregas;
Pacotes de trabalho não devem exceder 10 dias de duração;
Pacotes de trabalho devem ser independentes uns dos outros;
Os pacotes de trabalho são únicos e não devem ser duplicados em toda a estrutura analítica do projeto.
Decomponha a EAP em fases e atividades em níveis, que sejam fáceis de serem gerenciados;
13
Planeje as entregas, não as ações;
Quebre os pacotes de trabalho em durações adequadas;
Utilize modelos de EAP de projetos já finalizados, para acelerar o trabalho e aproveitar as lições aprendidas;
Tome cuidado para que o custo do gerenciamento não 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 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. Também podemos definir o Cronograma de Projetos como uma ferramenta de comunicação que demonstra todo o trabalho que precisa ser feito, quais os recursos da organização que serão empregados e quais os prazos que precisam ser cumpridos para que este trabalho seja realizado. Ele deve prever e refletir todos os esforços para a entrega do projeto finalizado. De forma extremamente visual, o cronograma exibe a sequência de atividades que precisa ser realizada e permite que o gestor verifique as interdependências de tarefas e construa seu caminho crítico para otimizar as entregas. Dito de outra forma, com um bom cronograma é possível identificar os pontos de tensão da iniciativa, verificar exatamente onde a equipe precisará redobrar a atenção para não perder prazos e realizar as entregas conforme o que foi definido no planejamento. Além 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 nível de divisão das tarefas dependerá da necessidade ou da capacidade da empresa em gerenciar cada detalhe. Um projeto de grande porte, por exemplo, não costuma ser quebrado em tarefas muito pequenas, pois são tantas que podem se tornar impossíveis de serem controladas de perto. Já projetos menores podem perfeitamente ser divididos em pacotes menores, isso ajuda tanto na execução quanto no controle dele.
16
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 dos Riscos A etapa de identificação dos riscos se encontra no planejamento do projeto, porém também é uma atividade a ser executada durante todo o desenvolvimento, só que em menor grau de detalhe.
17
Para uma boa identificação de riscos, pode pode-se fazer uso de tabelas ou planilhas para listá-los, los, há na literatura de engenharia de software abordagens que têm uma tabela pronta de riscos externos (Tabela 1) e internos (Tabela 2), com os riscos ao desenvolvimento de software, é claro que cada organização é diferente e vai identificar riscos particulares ao seu projeto, contudo é bom ter uma boa base para iniciar o processo de identificação. 1 causas/fenômenos naturais 2 crises políticas de uma região ou país 3 crises econômicas 4 Doenças 5 problemas do financiador do projeto ou do fornecedor de insumos/recursos; 6 alterações na legislação 7 pressões da organização, da sociedade, do cliente 8 alterações no mercado quanto às suas necessidades ou capacidade de compra Tabela 1: Identificação dos riscos externos 1 equipamentos defeituosos 2 equipe despreparada para trabalho em grupo 3 falta de domínio tecnológico 4 gastos excessivos
18
5 estouro de prazo devido a falhas de desenvolvimento 6
estouro de prazo devido a erros no gerenciamento necessidades tecnológicas desconsideradas durante o planejamento das etapas
7 a complexidade do sistema, não devidamente percebida nas etapas iniciais 8 alterações no escopo do projeto. Tabela 2: Identificação dos riscos internos Os riscos citados acima nas tabelas um e dois, que foram obtidos no livro de [FACCIONI 2011], são genéricos, servem para qualquer tipo de projeto de desenvolvimento de software, cabe á organização, na fase de planejamento, obter uma lista mais detalhada dos riscos de problemas que possam ocorrer dentro do seu contexto. 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 dos riscos Feita a identificação, o próximo 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 são: técnica, programática, suporte, custo e cronograma. Os níveis de risco estão relacionados com seu grau de periculosidade para o bom andamento do projeto, o nível 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 nível será entre um e quatro, pois este é um problema grave. Para dar continuação a fase de análise 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 gerência do projeto tenha pleno conhecimento sobre o mesmo. Segundo [PRITCHARD 2001] é necessário identificar os riscos, mas não há a necessidade de gerenciar todos, apenas os que realmente valerem a pena o esforço, essa decisão de escolha entre gerenciar um risco ou não, geralmente cabe ao líder, apoiado logicamente por sua equipe técnica. Fazem parte da etapa de análise, a investigação qualitativa e quantitativa, quando se busca saber como um problema pode afetar o andamento do projeto, é uma análise qualitativa, já a quantitativa é quando se busca saber o quanto o projeto vai atrasar por conta daquele problema, ou então quanto o projeto vai custar a mais se um determinado problema não for resolvido. Análise qualitativa Ao iniciar uma análise qualitativa dos riscos de um projeto de software, o principal objetivo é obter uma classificação dos riscos em categorias, bem como listas relacionando os riscos que exigirão uma resposta em curto prazo, e os com baixa prioridade. Se possível, uma análise de tendências, 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 informação simples, porém muito valiosa e de difícil aceitação se for negativa, afinal nenhum gerente de projetos gostaria de admitir que não fosse conseguir finalizar seu projeto.
20
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:
Identificar riscos, causas, descrição, categoria e como pode afetar o andamento do projeto;
Mapear o responsável por cada risco;
Documentar o resultado dos processos de análise quantitativa e qualitativa de riscos;
Para acordos de resposta são inclusos transferir, evitar, aceitar ou migrar, o acordo é feito para cada plano de resposta;
Qual ação específica deve ser tomada para implantar o planejamento de resposta;
Qual o orçamento e tempo para as respostas;
E, Planos de contingência e retrocedimento.
21
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 Os riscos não são estáticos, durante a fase de desenvolvimento de um projeto de software, pode haver mudança nos níveis de risco, um problema que no planejamento era aparentemente pequeno pode se tornar um impeditivo para alguma tarefa importante, por esse motivo existe a monitoração e controle. Em se tratando de software, pode-se dizer que a constante é a mudança, desde que são idealizados na cabeça de alguém até o momento em que caem em desuso, os softwares estão sempre mudando, sendo atualizados ou melhorados. Um programa de computador assim como um automóvel, precisa de manutenção, assim também é o gerenciamento de riscos, a cada marco do projeto faz-se necessário reavaliar a criticidade dos problemas presentes e futuros. Durante todo o projeto, o monitoramento e controle está presente (Figura 2), mesmo que não se tome uma posição 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 relatórios e análises muito importantes, um bom exemplo é o plano de contingência, o gerente de projetos precisa calcular através de métodos dinâmicos, o quanto de recurso irá precisar. No decorrer do desenvolvimento, o plano pode mudar, aumentando ou diminuindo a quantidade de recursos empenhados com a produção. Segundo [LOSS OSS 2007], as informações sobre o desempenho do trabalho, ações corretivas e relatórios de desempenho, são entradas importantes do monitoramento e controle de riscos, com isso pode pode-se se dizer que não basta ter os melhores profissionais trabalhando juntos, é preciso comandá-los los e sempre verificar se estão fazendo as coisas certas, tudo com o objetivo de finalizar o projeto com sucesso e no tempo planejado.
23
Controle de Mudança de Escopo 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:
Evento externo, que pode ser a mudança em uma lei.
Erro no detalhamento do escopo do projeto.
Implementação de um plano de contingência. Um ponto importante de ser analisado quando ocorre à mudança de escopo são as variações do escopo inicial, onde vai interferir diretamente na base do projeto e vai exigir uma ação corretiva. Dependendo da mudança, a base do projeto pode até ser modificada refletindo as alterações aprovadas. Para que a mudança 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 mudança de escopo deve estar também em todas as conformidades das cláusulas relevantes do contrato. Toda parte teórica descrita até o presente momento se fez presente para a criação a aplicação ASP.NET que será demonstrada no arquivo anexo com toda sua funcionalidade.
24
CONCLUSÃO
Concluiu-se que utilizando os recursos da gestão de projetos , aliado ao conhecimento prático de programação foi possível entregar a aplicação solicitada. Foi observado que se deve utilizar 80% do tempo em análise e desenvolvimento e apdenas 20 % na programação em si , visto que o gerenciamento de projeto reduz falhas, aumenta qualidade , evita o retrabalho e norteia o projeto.. Essa aplicação possibilita ao usuário cadastrar, excluir e alterar a tarefa, além de alertar o dia de sua entrega . A aplicação modifica a experiência do usuário, pois auxilia diretamente na vida acadêmica . Isso que é o principal objetivo da tecnologia, melhorar a vida de que a utiliza. O prazo para entrega da aplicação, 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 possível a criação da aplicação asp.net.
25
REFERÊNCIAS
Template Cronograma . Disponível em Acessado em 09/10/2016 ASP.NET. Disponível < https://www.asp.net/downloads>Acessado em 09/10/2016 Visual Studio. Disponível em . Acessado em 08/10/2016 Project builder. Disponível < http://www.projectbuilder.com.br/blogpb/entry/projetos/5-dicas-para-facilitar-a-criacao-de-uma-estrutura-analitica-deprojeto>Acessado em 09/10/2016 Softonic. Disponível em:Acessado em 13/10/2016 Estrutura Analítica do Projeto . Disponível em:Acessado em12/10/2016 WBS . Disponível em . Acessado em 10/10/2016. NAKASHIMA, D. T. V. (2004) "Identificação de riscos em projetos de TI". FACCIONI, M. F. (2011), Gerência de Projetos, 4ª edição. RAMIREZ, F. (2010), Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML, 5ª edição. 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) "Pós-Graduação em Segurança da Informação: Análise de Riscos".
LMDM (2008) "Gerenciamento de Riscos".
