Buscar

Plano de Projeto do Portfólio UNOPAR[ADS]

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 5 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

OBSERVAÇÕES IMPORTANTES
Todos os topicos abaixo descritos dizem respeito a Produção Textual Interdiciplinar da UNOPAR, servindo para qualquer dos semestrer que tenha a tarefa abaixo descrita como orientação. E servindo APENAS como orientação para o desenvolvimento adequado dos referidos topicos, já que são apenas exemplos para dar ideia do que é necessario para o desenvolvimento da tarefa pedida.
Com base no cenário “Oficina Mecânica Chave de Rodas”(Ou qualquer outro que esteja nesse mesmo contexto), desenvolva um plano de projeto para ajudar na definição dos vários artefatos que deverão ser considerados no projeto de desenvolvimento do software proposto, no mínimo os seguintes itens e seus subitens deverão fazer parte do plano:
a. Escopo do Projeto 
b. Justificativa 
c. Mapa Mental 
d. Mapeamento de Requisitos Funcionais e Não Funcionais 
e. Cronograma de Execução 
f. Definição de Ciclo de Vida e Metodologia de Desenvolvimento 
g. Definição de Arquitetura (Lógica e Física) 
h. Padrões de Projeto 
i. Frameworks 
j. Tecnologias Aplicadas 
k. Ferramentas
Escopo
Existem dois tipos de escopo, o de projeto e o de produto e conforme o PMBOK®, são definidos da seguinte forma:
Escopo do Projeto: “é o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas”. Ou seja, é tudo o que temos que fazer com que o projeto alcance o sucesso, como entregas, prazos, custos, requisitos e leis.
Escopo do produto: São as características que o produto entregue pelo seu projeto irá conter, como definições, especificações, medidas e etc. É aconselhável criar em conjunto com o escopo do produto, o seu critério de aceitação, que é uma medida mensurável para a validação da entrega do produto ou parte dele.
[Nesta seção do trabalho, o ideal é uma síntese dos dois conceitos, ou seja, uma breve descrição do escopo deste Plano de Desenvolvimento de Software; os Projetos aos quais ele está associado e tudo o que é afetado ou influenciado por este documento.] 
Exemplo.
Este Plano de Desenvolvimento de Software descreve o plano geral a ser usado pelo projeto <nome do projeto>, incluindo a implantação do produto e dos <componentes identificados a ser desenvolvidos>. 
Justificativa
Nessa seção, estão descritas as principais necessidades para a aplicação a ser desenvolvida.
<As necessidades dos clientes/usuários devem ser listadas na tabela abaixo e ordenadas por prioridade. Essas necessidades devem ter sido identificadas através de stakeholders, podendo ainda não se refletir necessariamente em soluções computacionais e aplicações. No futuro, as necessidades aqui levantadas poderão evoluir para casos de uso. Entretanto, o formalismo utilizado para descrever casos de uso não deve ser aplicado neste momento.>
Mapa Mental
Exemplo:
Mapeamento dos Requisitos
Funcionais
Não Funcionais
Atributos importantes para os usuários
Desempenho ("Ao registrar um item sendo vendido, a descrição e preço devem aparecer em, no máximo, 2 segundos").
Volume de utilização, incluindo número de usuários, número de transações, ... ("O sistema deverá suportar uma carga máxima de 2000 usuários simultâneos com degradação de desempenho de, no máximo, 10% em qualquer operação")
Integridade/segurança ("Apenas usuários com privilégios de acesso de Auditor poderão visualizar históricos de transações de clientes")
Atributos importantes para os desenvolvedores
Manutenabilidade ("Modificações a qualquer relatório deverão ser implementadas 24 horas após recepção de aviso de modificação de regulamentação pelo Ministério de Agricultura")
Portabilidade ("O produto deverá ser desenvolvido de forma a possibilitar a instalação em ambiente linux e/ou windows")
Cronograma de Execução
O ideal é uma tabela estabelecendo data para determinadas ações no plano geral de desenvolvimento.
Exemplo:
	Data
	Ações
	18/03/2018
	Reunião com o cliente, reunião com a equipe.
	28/03/2018
	Início da criação do projeto de software, criação do gráfico de gantt.
	09/04/2018
	Reunião com os desenvolvedores para definir o servidor de hospedagem que será utilizado.
	14/04/2018
	Entrega do documento de requisitos. Reunião com os programadores para definir a linguagem que melhor se encaixa no desenvolvimento deste projeto. É importante a opinião de todos.
	17/04/2018
	Reunião com a equipe, principalmente com o DBA para definição do melhor banco de dados para o desenvolvimento do projeto.
Definição do Ciclo de Vida e Metodologia de Desenvolvimento
Um bom modelo neste item, seria usar o RUP como metodologia base na definição das etapas e dos procedimentos inerentes ao desenvolvimento de softwares. Por isso, a metodologia Rational Unified Process é abordada com mais detalhes adiante. Entretanto, a proposta apresentada poderá ser adequada para aplicação em quaisquer das metodologias de desenvolvimento de software que incorporem o ciclo de vida clássico da engenharia de software que, segundo Pressman (1995) inicia no nível de sistema e avança ao longo da análise, projeto, codificação, teste e manutenção.
Levando em consideração a argumentação do RUP, o tempo disponível para o desenvolvimento do projeto e o fator de não ser exigido completeza, requisitos estes especificados pelo coordenador de projeto, o que teremos como Release Final é apenas um Protótipo de Projeto que poderá ser utilizado como uma solução inicial para o problema proposto. Tendo em vista tais fatos, foi adotada apenas uma iteração para cada fase.
O Plano de Desenvolvimento de Software poderá ser inteiramente revisado antes do início de cada fase de Iteração. As datas podem ser observadas na tabela abaixo.
	Datas das Fases e Iterações das Linhas Base
	Fase RUP
	Iteração RUP
	Linha Base 
	Data Alvo
	Inception
	Iniciação
	Funcional
	17/08/06
	Elaboration
	Protótipo de Arquitetura
	Projeto
	05/09/06
	Contruction
	Release de Protótipo
	Produto
	19/09/06
	Transaction
	Release Final
	Produto
	03/10/06
Definição da Arquitetura
Arquitetura Lógica
O padrão Model-View-Controller separa o processamento da informação (funcionalidade) de sua representação (interface). Dessa forma, visa facilitar a resolução dos problemas que surgem quando usuários necessitam de mudança da interface, plataforma ou a criação de aplicações com interfaces diferentes (usuário, gerente). A utilização desse padrão aumenta a flexibilidade, portabilidade e a reusabilidade, pois divide a aplicação em três componentes: model que contém o núcleo dos dados e da funcionalidade; controller que manipula as entradas do usuário (cliques do mouse, interações de menus, etc); view que apresenta as informações aos usuários (PRIETO, 2001). 
Segundo Willemann (2007), componentes de modelo são responsáveis pelo armazenamento dos dados durante a sessão do usuário para a execução de regras de negócios, sendo que os componentes de visualização se encarregam da exibição final e de fornecer meios do usuário indicar as operações a serem realizadas pela aplicação. Componentes do controlador são responsáveis em fazer a ponte entre os outros dois tipos de componentes, interpretando os eventos gerados pelos componentes de visualização e disparando a execução do método correspondente ao Modelo. A figura abaixo apresenta a estrutura do padrão MVC.
Arquitetura Física
Representa a disposição física do sistema de software pelo hardware disponível. Uma apresentação desta organização com o Diagrama de Implantação da UML é o mais indicado.
Exemplo:
Padrões de Projeto
Os padrões de projeto tornam mais fácil a reutilização de projetos e arquiteturas bem-sucedidas, pois descrevem técnicas já testadas e aprovadas. Eles ajudam a escolher alternativas de projeto, evitando alternativas que poderiam comprometer a reutilização. Um exemplo aqui seria a arquitetura MVC fazer uso do Padrãode Projeto DAO(Data Access Object), O padrão DAO é um padrão de projeto que abstrai e encapsula os mecanismos de acesso a dados escondendo os detalhes da execução da origem dos dados e descoplando as regras de negocio da camada de acesso aos dados.
Frameworks
	Nome
	Versão
	Descrição
	Bootstrap
	3.0
	Layout
	Laravel
	5.0
	Estrutura do sistema
	
	
	
	
	
	
Tecnologias Aplicadas
	Nome
	Versão
	Aplicação
	PHP
	7.0
	Linguagem de back-end do sistema
	HTML
	5
	Linguagem de front-end
Ferramentas
	Nome
	Versão
	Aplicação
	Sublime Text
	3.0
	IDE Principal para desenvolvimento
	brModelo
	3.0
	Sistema para modelagem dos dados
	Apache
	2.0
	Servidor local para desenvolvimento

Continue navegando