SlideShare ist ein Scribd-Unternehmen logo
1 von 21
Downloaden Sie, um offline zu lesen
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2013/2

Gustavo Souza Santos
Kevin Filipe Campos Matias
Onezino Gabriel Moreira
Tiago Oliveira Santos

PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW

São Cristóvão - Sergipe, Brasil
2014
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2013/2

Gustavo Souza Santos
Kevin Filipe Campos Matias
Onezino Gabriel Moreira
Tiago Oliveira Santos

PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW

Trabalho apresentado ao Prof. Dr.
Rogério

Patrício

Chagas

do

Nascimento como nota parcial para
disciplina Gerência de Projetos do
curso de graduação em Sistemas de
Informação

–

Bacharelado

Universidade Federal de Sergipe.

São Cristóvão - Sergipe, Brasil
2014

da
Sumário

1. INTRODUÇÃO ................................................................................................. 4
1.1 Âmbito do projeto ........................................................................................ 4
1.2 Principais funções do produto de software ................................................. 5
1.3 Requisitos comportamentais ou de performance ........................................ 6
1.4 Gestão e restrições técnicas ....................................................................... 6
2. ESTIMATIVAS DO PROJETO.......................................................................... 6
2.1 Dados históricos utilizados para as estimações .......................................... 6
2.2 Técnicas de estimação e resultados ........................................................... 7
2.2.1 Técnica de estimação........................................................................... 8
2.3 Resultados .................................................................................................. 8
2.4 Recursos do projeto .................................................................................... 9
2.4.1 Recursos humanos............................................................................... 9
2.4.2 Recursos de software ......................................................................... 11
2.4.3 Recursos de hardware ....................................................................... 11
3 ANÁLISE E GESTÃO DE RISCOS ................................................................. 12
3.1 Riscos do projeto ...................................................................................... 12
3.2 Tabela de riscos ........................................................................................ 13
3.3 Redução e gestão do risco ....................................................................... 14
4 Planejamento Temporal .................................................................................. 19
4.1 Conjunto de Tarefas do Projeto ................................................................ 19
4.2 Diagrama de Gantt .................................................................................... 20
5.0 ORGANIZAÇÃO DO PESSOAL ................................................................... 21
5.1 Estrutura da equipe ................................................................................... 21
5.2 Mecanismos de comunicação ................................................................... 21
5.3 Uso do Edu-blog como ferramenta de apoio............................................. 21
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE ............................................................. 21
1. INTRODUÇÃO
1.1 Âmbito do projeto
Um estudo realizado por alunos do curso de Sistemas de Informação da
Universidade Federal de Sergipe comprovou que não existem softwares nacionais
capazes de gerenciar um acervo de arte por completo e que a única forma de alcançar
tal objetivo, utilizando métodos atuais, seria através de ferramentas de propósitos
distintos que auxiliariam no processo de armazenamento e manipulação de
informações referentes ao acervo. Esse modo de proceder, obviamente, está sujeito a
uma infinidade de erros que podem prejudicar a qualidade, a disponibilidade e a
segurança do serviço prestado tanto ao fornecedor quanto aos seus clientes.
O sistema para Controle de Acervo de Arte (ControlArt) apresenta uma solução
definitiva para esta problemática. É por esse motivo, construir um ambiente único para
o gerenciamento de acervos, que o seu domínio é bastante extenso. A seguir serão
listados artefatos que descrevem de forma sucinta o contexto do problema e a solução
proposta:

Figura 1 - Descrição do problema
Figura 2 - Situação de posição do produto

1.2 Principais funções do produto de software
O diagrama abaixo apresenta as principais funcionalidades do sistema
ControlArt. Os casos de uso que envolvem manutenibilidade de determinado objeto
estão relacionados com as seguintes operações: Incluir, alterar e inativar. Os demais
itens tratam apenas de inclusão.

Figura 3 - Diagrama de casos de uso
1.3 Requisitos comportamentais ou de performance
Para atender seus usuários com eficiência e qualidade, o sistema ControlArt
deve:
1. Estar de acordo com a regra de negócio do ambiente para o qual foi
desenvolvido, o que resulta na similaridades de operações para os
usuários;
2. Ser fácil de usar, a fim de proporcionar agilidade e precisão na realização
dessas operações;
3. Disponibilizar informações íntegras a todo instante;
4. Restringir o acesso de pessoas não autorizadas, utilizando um processo
de autenticação por login, senha e tipo do usuário logado (administrador
ou usuário padrão);
5. Não permitir que os usuários excluam as informações armazenadas,
apenas inativando-as quando não forem mais necessárias;
6. Não permitir que os usuários editem transações.
1.4 Gestão e restrições técnicas
Abaixo serão listadas algumas restrições técnicas do sistema ControlArt:
1. O sistema deve ser desenvolvido utilizando arquitetura web;
2. O sistema deve ser desenvolvido utilizando a linguagem de programação
Java;
3. O sistema deve utilizar o PostgreSQL como banco de dados;
4. O acesso ao sistema deve ser feito através de um browser (navegador
web). Recomenda-se fortemente o uso do Google Chrome.
2. ESTIMATIVAS DO PROJETO
Nesta seção serão descritas as estimativas que permitem calcular custo, esforço
e tempo gastos durante a construção do projeto. Essas informações são úteis para
analisar e distribuir as atividades de acordo com um cronograma preciso de tempo e
recursos necessários para cada uma delas.
2.1 Dados históricos utilizados para as estimações
Por se tratar de um projeto didático novo, sob a responsabilidade de uma equipe
recém formada, não existem dados históricos utilizados para as estimações.
2.2 Técnicas de estimação e resultados
Abaixo serão listadas as técnicas utilizadas para as estimativas:
1. Métrica de Lorens & Kidd - Calcular o tempo total de duração do projeto. Utiliza o
diagrama de classes de domínio como fonte de informações.

Figura 4 - Diagrama de classes de domínio
2.2.1 Técnica de estimação
A métrica mencionada no item 1 da seção anterior foi utilizada de acordo com os
seguintes passos:
1. Determinar as classes-chave do projeto, através da análise do diagrama de
classes de domínio (apresentado na Figura 4);
2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo
com um dos itens da Tabela 1;
Interface

Multiplicador

Interface não gráfica

2

Baseada em texto

2,25

GUI

2,5

GUI Complexa

3
Tabela 1 - Valores Interface x Multiplicador

3. Determinar o número de classes de suporte, efetuando o produto da quantidade
de classes-chave pelo multiplicador da interface escolhida anteriormente;
4. Determinar o total de classes do projeto, somando a quantidade de classes de
suporte com a quantidade de classes-chave;
5. Determinar a quantidade de dias que uma pessoa levaria para construir uma
classe. Quando não existem dados históricos a serem considerados, Lorens &
Kidd sugerem de 15 a 20 dias;
6. Determinar a quantidade total de dias que uma pessoa levaria para construir
todo o projeto, efetuando o produto do total de classes do projeto pela
quantidade de dias escolhida anteriormente;
7. Determinar a quantidade total de dias que a equipe levaria para construir todo o
projeto, efetuando a divisão da quantidade total de dias pela quantidade de
pessoas que a equipe possui.
2.3 Resultados
Abaixo será listado o passo-a-passo da execução da métrica descrita na seção
anterior:
1. Número de classes-chave encontradas após a análise do diagrama de classes
de domínio;
8 classes-chave
2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);
GUI
3. Número de classes de suporte encontrado;
8 (item 1) x 2,5 (multiplicador do item 2) = 20 classes de suporte
4. Número total de classes;
20 (item 1) + 8 (item 3) = 28 classes
5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única
classe (Valor retirado do intervalo sugerido por Lorens & Kidd);
15 dias
6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema;
15 (item 5) * 28 (item 4) = 420 dias
7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.
420 (item 6) / 4 (quantidade de integrantes) = 105 dias.

Sendo assim, de acordo com a métrica de Lorens & Kidd, o tempo necessário
para a construção do projeto deve ser de, aproximadamente, 105 dias. Levando em
consideração a quantidade de dias úteis no mês (geralmente 22), o projeto se
estenderá por, aproximadamente, 5 meses.
2.4 Recursos do projeto
Nas seções abaixo serão listados os recursos utilizados na construção do
projeto, divididos de acordo com a seguinte classificação: humanos, de software e de
hardware.
2.4.1 Recursos humanos
Para facilitar o trabalho realizado pela equipe, a duração total do projeto,
calculada na seção 2.3, foi dividida de acordo com as seguintes fases:
Fase

Porcentagem

Duração

Planejamento

10%

10 dias

Análise e Projeto

42%

45 dias

Codificação

28%

30 dias

Testes

20%

20 dias

Tabela 2 - Fases do projeto

Para gerenciar o projeto de software utilizamos a metodologia SCRUM. As
funcionalidades após serem definidas foram especificadas e divididas em tarefas,
essas tarefas, agrupadas e divididas entre os sprints. Ao final de cada sprint
entregaremos para os usuários uma parte funcional do software. A cada sprint fazemos
o planejamento, codificação e teste do projeto de software.
A cada sprint faremos o rodizio de funcionários nas posições de Scrum Master e
desenvolvedores, os testes serão feito pelos desenvolvedores. Cada desenvolvedor
será responsável pelos testes das implementações das atividade de outro
desenvolvedor. A tabela 3 mostra a divisão das funcionalidades dos sprints e a
indicação do Scrum Master do sprint.
Funcionalidades

Início

Término

Scrum Master

Manter tipos de pessoas;
Manter pessoas;
Manter usuários.

05/05/2014

30/05/2014

Onezino Moreira

Manter classificação;
Manter acervos.

02/06/2014

20/06/2014

Gustavo Souza

Manter peças;
Registrar transação.

23/06/2014

11/07/2014

Kevin Filipe

Tabela 3 - Definição dos Sprints
2.4.2 Recursos de software
Segue abaixo a lista de recursos de software utilizados no projeto:
Software

Descrição

Java Development Kit 7

Ambiente para desenvolvimento de
aplicações Java (linguagem utilizada
na codificação do projeto).

Apache Tomcat 7

Contâiner
web
utilizado
para
armazenar e distribuir o software
desenvolvido.

PostgreSQL 9

Banco de
software.

iReport 4

Ferramenta gráfica utilizada para a
criação de relatórios personalizados.

GIT

Sistema para controle de versão
utilizado no projeto.

IDE Eclise Kepler para Java EE

IDE utilizada
software.

Google Chrome

Navegador
web
utilizado
desenvolver o software.

StarUML

Ferramenta utilizada na modelagem
dos artefatos visuais do projeto.

Microsoft Word

Ferramenta utilizada para construir a
documentação do projeto.

dados

na

utilizado

codificação

pelo

do
para

Tabela 4 - Recursos de software

2.4.3 Recursos de hardware
Os computadores pessoais de cada integrante foram os únicos recursos
utilizados na construção do projeto. As ferramentas utilizadas por eles para a
integração das atividades fazem ligação direta com a nuvem, não existindo
necessidade de quaisquer recursos adicionais.
3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão analisados os riscos potenciais que são prejudiciais para o
andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo
possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a
acontecer.
3.1 Riscos do projeto
Segue abaixo tabela com os riscos identificados e sua respectiva classificação,
que visa determinar se a sua ocorrência é geral ou única do projeto:
Risco

Projeto

Ferramentas
de
testes
oferecem pouco suporte à
tecnologia
usada
na
codificação.

Técnico

Negócio

Comum

Especial

X

Tamanho e complexidade do
produto comprometem os
prazos de entrega.

X

Projeto construído sem o
contato
com
possíveis
usuários.

X

Curto
período
para
construção do projeto.

X

X

X

X

a

Equipe não possui tempo
integral disponível.
Funcionalidades codificadas
do zero, sem reutilização.
Equipe pequena.

constante

X

X
X

Equipe
com
pouco
conhecimento
acerca
da
tecnologia
usada
na
codificação.
Necessidade

X

de

X

X

X

X

X
aprimoramentos no software.
Dificuldade para solucionar
problemas
encontrados
durante a codificação.

X

X

Tabela 5 - Riscos x Classificação

3.2 Tabela de riscos
A tabela abaixo atribui a cada um dos riscos uma probabilidade, que determina o
grau de chance deste risco acontecer, e um impacto, que determina o nível de desastre
resultante após o efetivo acontecimento deste evento.
Risco

Probabilidade (%)

Impacto

Ferramentas
de
testes
oferecem pouco suporte à
tecnologia
usada
na
codificação.

90%

Catastrófico

Tamanho e complexidade do
produto comprometem os
prazos de entrega.

80%

Crítico

Projeto construído sem o
contato
com
possíveis
usuários.

80%

Crítico

Curto
período
para
construção do projeto.

80%

Crítico

Equipe não possui tempo
integral disponível.

70%

Moderado

Funcionalidades codificadas
do zero, sem reutilização.

70%

Moderado

Equipe pequena.

70%

Marginal

Equipe
com
pouco
conhecimento
acerca
da
tecnologia
usada
na
codificação.

60%

Moderado

a
Necessidade constante de
aprimoramentos no software.

50%

Moderado

Dificuldade para solucionar
problemas
encontrados
durante a codificação.

20%

Marginal

Tabela 6 - Análise Risco x Probabilidade x Impacto

3.3 Redução e gestão do risco

riscos

Os quadros abaixo apresentam estratégias para a redução e/ou gestão dos
estudados
anteriormente:

1 - Ferramentas de testes oferecem pouco suporte à tecnologia usada na
codificação.
Probabilidade: 90%.
Impacto: Catastrófico.
Descrição: Ferramentas de testes automatizadas oferecem pouco ou nenhum
suporte à tecnologia usada na codificação do produto.
Estratégia de redução: Minimizar o uso destas ferramentas através da implantação
de outros processos de testes.
Plano de contingência: Dividir os testes complexos em partes mais simples,
facilitando, quando possível, o uso das ferramentas já utilizadas.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 1 - Análise do risco 1

2 - Tamanho e complexidade do produto comprometem os prazos de entrega.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: O produto atende a uma necessidade que é bastante simples. No
entanto, devido a quantidade de informações que ele deve gerenciar, seu tamanho e
complexidade crescem demasiadamente, prejudicando os prazos de entrega.
Estratégia de redução: Fazer uma análise apurada do escopo e do planejamento
definidos para o projeto.
Plano de contingência: Revisar a documentação escrita para tentar reverter, em
conjunto os possíveis stackholders, os prazos definidos incorretamente. Uma
explicação satisfatória sobre o ocorrido deve ser necessária.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 2 - Análise do risco 2

3 - Projeto construído sem o contato com possíveis usuários.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: O projeto foi construído sem a presença de usuários que conhecem as
regras de negócio do ambiente.
Estratégia de redução: Reverter a situação o mais rápido possível, procurando por
possíveis clientes que estejam interessados no produto.
Plano de contingência: Disponibilizar versões de testes para usuários que
conhecem as regras de negócio do ambiente e que podem opinar a respeito do que
está sendo desenvolvido.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 3 - Análise do risco 3

4 - Curto período para a construção do projeto.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: Devido a grande carência do mercado, o prazo para construção do
projeto é relativamente curto.
Estratégia de redução: Divisão pertinente das atividades de acordo com com um
planejamento preciso.
Plano de contingência: Seguir a risca as informações e prazos detalhados na
especificação do projeto.
Responsável: Onezino Gabriel Moreira.
Status: Em andamento.
Quadro 4 - Análise do risco 4

5 - Equipe não possui tempo integral disponível.
Probabilidade: 70%.
Impacto: Moderado.
Descrição: Devido a outras atividades realizadas por cada integrante da equipe, o
tempo disponível para o projeto não é integral.
Estratégia de redução: Divisão pertinente das atividades de acordo com com um
planejamento de tempo preciso.
Plano de contingência: Rever as atividades realizadas por cada integrante a fim de
não sobrecarregá-lo. A divisão das tarefas entre os membros da equipe deve facilitar
o processo.
Responsável: Tiago Oliveira Santos.
Status: Em andamento.
Quadro 5 - Análise do risco 5

6 - Funcionalidades codificadas do zero, sem reutilização.
Probabilidade: 70%.
Impacto: Moderado.
Descrição: As funcionalidade do software foram desenvolvidas do zero, sem a
utilização/criação de nenhum componente reutilizável.
Estratégia de redução: Adotar medidas que priorizem o desenvolvimento de
componentes reutilizáveis sempre que possível e necessário
Plano de contingência: Modificar as estruturas dos itens que precisam de
reutilização para que se tornem reutilizáveis, evitando a necessidade de replicar
código.
Responsável: Tiago Oliveira Santos.
Status: Em andamento.
Quadro 6 - Análise do risco 6

7 - Equipe pequena.
Probabilidade: 70%.
Impacto: Marginal.
Descrição: A equipe responsável pela construção do projeto é relativamente
pequena.
Estratégia de redução: Divisão pertinente das tarefas da equipe de acordo com um
planejamento preciso, combatendo também a sobrecarga de funções.
Plano de contingência: Rever a distribuição de tarefas entre os membros da equipe.
O excesso de funções/atividades deve ser evitado a todo custo.
Responsável: Onezino Gabriel Moreira.
Status: Em andamento.
Quadro 7 - Análise do risco 7
8 - Equipe com pouco conhecimento acerca da tecnologia usada na
codificação.
Probabilidade: 60%.
Impacto: Moderado.
Descrição: A equipe não possui conhecimento aprofundado acerca da tecnologia
utilizada na codificação do projeto.
Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a
respeito da tecnologia utilizada.
Plano de contingência: Planejar o desenvolvimento de estruturas complexas em
equipe, ao invés de individualmente.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 8 - Análise do risco 8

9 - Necessidade constante de aprimoramentos no software.
Probabilidade: 50%.
Impacto: Moderado.
Descrição: Como o software foi desenvolvido sem a presença de um usuário em
potencial, a necessidade de modificações pode ser constante.
Estratégia de redução: Disponibilizar versões de testes para usuários que
conhecem as regras de negócio do ambiente e que podem opinar a respeito do que
está sendo desenvolvido, com o intuito de melhorar as regras de negócio.
Plano de contingência: Planejar as modificações de acordo com as necessidades e
obrigações da equipe.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 9 - Análise do risco 9
10 - Dificuldade para solucionar problemas encontrados durante a codificação.
Probabilidade: 20%.
Impacto: Marginal.
Descrição: Devido a complexidade que envolve a tecnologia usada na codificação,
os erros podem levar tempo considerável para serem resolvidos.
Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a
respeito da tecnologia utilizada.
Plano de contingência: Planejar a solução das pendências em equipe, ao invés de
individualmente.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 10 - Análise do risco 10

4 Planejamento Temporal
Nesta seção são definidas as datas de execução das tarefas, bem como seus
responsáveis. No planejamento temporal definimos os marcos e planos de ações. O
cronograma das tarefas está baseado na metodologia aplicada ao projeto e a
mensuração das fases de do projeto de software conforme definimos no item 2.X.X
4.1 Conjunto de Tarefas do Projeto
A definição do conjunto de tarefas de projeto utilizou o modelo iterativo
incremental, como a metodologia encoraja a entrega rápida e constante para utilização
do usuários fizemos marcos de liberação de módulos do produto de software para o
usuário.
O scrum define a divisão das funcionalidades em atividades menores que
podem ser executadas pelo desenvolvedores. Na tabela abaixo está a listagem das
atividades a serem executadas em cada funcionalidade.

Funcionalidade
Funcionalidade
administração

Atividades

de -Desenvolvimento da tela de administração de segurança,
de pessoa e usuários
tabelas do sistema

- Desenvolvimento da regra de negócio e persistência das
entidades de usuário e segurança
- Gerar carga inicial dos objetos de segurança, pessoal,
usuário

Manutenção
de - Telas de registro de acervos, de peças e de vinculação de
acervos e peças
peças com o acervo
- Desenvolvimento das regras de negócio e persistência das
entidades acervos e peças
Registro
transação
classificação

de - Tela para registro de transação, classificação de acervo e
e peças
- Desenvolvimento das regras de negócio e persistência das
entidades de transação e classificação.
Tabela 7 – Tabela de Atividades

4.2 Diagrama de Gantt
O diagrama de Gantt nos permite visualizar de forma gráfica o avanço e
planejamento das diferentes etapas de um projeto. A cada inicio e fim da atividade é
mostrado em intervalos.
O detalhamento de nossas atividades no diagrama de Gantt está disponível em:

Figura 5 - Diagrama de Gantt
5.0 ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da equipe
●
●
●
●

Gerente de Projeto: Onezino Gabriel Moreira
Analista de Sistema: Kevin Filipe
Desenvolvedor: Tiago Oliveira
Analista de Testes: Gustavo Souza

5.2 Mecanismos de comunicação
Os mecanismos de comunicação utilizados serão:
● E-mail - facilidade de comunicação e permite manter o registro das discussões;
● Reuniões diárias - permitem a comunicação face-a-face e ajudam a verificar o
andamento do projeto;
● Ferramentas colaborativas - vários documentos foram editados através do
Google Drive, permitindo a colaboração de todos.
5.3 Uso do Edu-blog como ferramenta de apoio
O blog é uma ferramenta interessante, pois permite que seja disseminado o
conhecimento adquirido durante o projeto, tanto entre os integrantes do projeto quanto
para outras pessoas.
Também ajuda na catalogação das informações mais importantes, criando uma
maneira rápida de se localizar dados importantes mesmo após o fim do projeto.
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SOFTWARE
● Documentação - A cada etapa do projeto serão produzidos documentos. Estes
serão importantes na elaboração dos testes. Também servirão para guiar o
andamento do projeto. Deverão ser atualizados quando houverem mudanças;
● Testes - Serão elaborados com o auxílio da documentação e executados
durante todas as fases do projeto;
● Controle de versão - Ferramenta que permitirá o rastreamento de alterações e
identificarão os seus autores. Ajudam a manter os documentos atualizados;
● Reuniões diárias - Utilizando a idéia do SCRUM, reuniões diárias de curta
duração serão realizadas para verificar o andamento do projeto.

Weitere ähnliche Inhalte

Was ist angesagt?

Plano projeto(final)
Plano projeto(final)Plano projeto(final)
Plano projeto(final)Raul Vilar
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWMatheus Costa
 
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamentoOtavio Siqueira
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWLays Lopes
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONIocfelipe
 
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...Felipe Pontes
 
Plano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWPlano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWrafahreis
 
Plano de Projeto - Grupo Ajax
Plano de Projeto - Grupo AjaxPlano de Projeto - Grupo Ajax
Plano de Projeto - Grupo AjaxPre Amadeus
 
Gerenciamento De Projetos
Gerenciamento De ProjetosGerenciamento De Projetos
Gerenciamento De ProjetosHudson Augusto
 
Documentação do software
Documentação do softwareDocumentação do software
Documentação do softwarecifjovo02
 
Programacao php moodle
Programacao php moodleProgramacao php moodle
Programacao php moodleTiago
 
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...nvenanzoni
 
Trabalho final(25 03 2013)
Trabalho final(25 03 2013)Trabalho final(25 03 2013)
Trabalho final(25 03 2013)Augusto Arruda
 

Was ist angesagt? (20)

Plano projeto(final)
Plano projeto(final)Plano projeto(final)
Plano projeto(final)
 
Plano de Projeto de Software para CFCSYSTEM
Plano de Projeto de Software para CFCSYSTEMPlano de Projeto de Software para CFCSYSTEM
Plano de Projeto de Software para CFCSYSTEM
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 
Ferramentas de planejamento
Ferramentas de planejamentoFerramentas de planejamento
Ferramentas de planejamento
 
Plano do Projeto
Plano do ProjetoPlano do Projeto
Plano do Projeto
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano de projeto de software - SISCONI
Plano de projeto de software - SISCONIPlano de projeto de software - SISCONI
Plano de projeto de software - SISCONI
 
GESTÃO DA PRODUÇÃO
GESTÃO DA PRODUÇÃOGESTÃO DA PRODUÇÃO
GESTÃO DA PRODUÇÃO
 
Gerenciamento de projetos de sistemas 2012.1
Gerenciamento de projetos de sistemas   2012.1Gerenciamento de projetos de sistemas   2012.1
Gerenciamento de projetos de sistemas 2012.1
 
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
 
Plano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SWPlano de Projeto de Software para produtos da Lacertae SW
Plano de Projeto de Software para produtos da Lacertae SW
 
Plano de Projeto - Grupo Ajax
Plano de Projeto - Grupo AjaxPlano de Projeto - Grupo Ajax
Plano de Projeto - Grupo Ajax
 
Gerenciamento De Projetos
Gerenciamento De ProjetosGerenciamento De Projetos
Gerenciamento De Projetos
 
Documentação do software
Documentação do softwareDocumentação do software
Documentação do software
 
Programacao php moodle
Programacao php moodleProgramacao php moodle
Programacao php moodle
 
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...
FGV Bauru GPJ7 - Plano de Gerenciamento de Escopo v2 - Disciplina Concorrênci...
 
Trabalho final(25 03 2013)
Trabalho final(25 03 2013)Trabalho final(25 03 2013)
Trabalho final(25 03 2013)
 
Tcc carlos ribeiro luiz v02
Tcc   carlos ribeiro luiz v02Tcc   carlos ribeiro luiz v02
Tcc carlos ribeiro luiz v02
 
Tcc Redmini Software de Gestão de Projetos
Tcc Redmini Software de Gestão de ProjetosTcc Redmini Software de Gestão de Projetos
Tcc Redmini Software de Gestão de Projetos
 

Ähnlich wie plano_de_projeto_controlart_rascunho

Plano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisPlano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisMarcos Pessoa
 
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Urique Hoffmann
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRaffonsosouza
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWInstituto Federal de Sergipe
 
Plano de projeto cafis
Plano de projeto cafisPlano de projeto cafis
Plano de projeto cafisJonathas Silva
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de softwareDanilo Gois
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Controlazarael2607
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisadoJorge Barreto
 
Planode de Projeto - SIGEP
Planode de Projeto - SIGEPPlanode de Projeto - SIGEP
Planode de Projeto - SIGEPedsonpoderoso
 
Plano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebPlano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebJorge Roberto
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de softwareSigelman Araujo
 
Plano de Projeto - OUTLAY
Plano de Projeto - OUTLAYPlano de Projeto - OUTLAY
Plano de Projeto - OUTLAYJocelino Neto
 
Programa Redes de Comunicação - Ens. Profissional
Programa Redes de Comunicação - Ens. ProfissionalPrograma Redes de Comunicação - Ens. Profissional
Programa Redes de Comunicação - Ens. ProfissionalFilipe Mendonça
 
Redes de comunicaçao
Redes de comunicaçaoRedes de comunicaçao
Redes de comunicaçaoRui Raposo
 
Projeto Indiana
Projeto IndianaProjeto Indiana
Projeto Indianahellequin
 
Introdução à Engenharia de Software e UML
Introdução à Engenharia de Software e UMLIntrodução à Engenharia de Software e UML
Introdução à Engenharia de Software e UMLNatanael Simões
 
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de SoftwareQUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de SoftwareDiogo Rocha Ferreira de Menezes
 
Plano de projeto de software para o sistema MEA - monitoraemto de eventos ad...
Plano de projeto de software para o sistema  MEA - monitoraemto de eventos ad...Plano de projeto de software para o sistema  MEA - monitoraemto de eventos ad...
Plano de projeto de software para o sistema MEA - monitoraemto de eventos ad...Lucas Aquino
 

Ähnlich wie plano_de_projeto_controlart_rascunho (20)

Plano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisPlano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiais
 
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBR
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano de projeto cafis
Plano de projeto cafisPlano de projeto cafis
Plano de projeto cafis
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
 
Projeto de sw revisado
Projeto de sw revisadoProjeto de sw revisado
Projeto de sw revisado
 
Planode de Projeto - SIGEP
Planode de Projeto - SIGEPPlanode de Projeto - SIGEP
Planode de Projeto - SIGEP
 
Plano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na WebPlano de projeto: Bichos do Campus na Web
Plano de projeto: Bichos do Campus na Web
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de software
 
Eng software
Eng softwareEng software
Eng software
 
Plano de Projeto
Plano de ProjetoPlano de Projeto
Plano de Projeto
 
Plano de Projeto - OUTLAY
Plano de Projeto - OUTLAYPlano de Projeto - OUTLAY
Plano de Projeto - OUTLAY
 
Programa Redes de Comunicação - Ens. Profissional
Programa Redes de Comunicação - Ens. ProfissionalPrograma Redes de Comunicação - Ens. Profissional
Programa Redes de Comunicação - Ens. Profissional
 
Redes de comunicaçao
Redes de comunicaçaoRedes de comunicaçao
Redes de comunicaçao
 
Projeto Indiana
Projeto IndianaProjeto Indiana
Projeto Indiana
 
Introdução à Engenharia de Software e UML
Introdução à Engenharia de Software e UMLIntrodução à Engenharia de Software e UML
Introdução à Engenharia de Software e UML
 
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de SoftwareQUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software
QUALIDADE DE SOFTWARE VT- Avaliação de Produto de Software
 
Plano de projeto de software para o sistema MEA - monitoraemto de eventos ad...
Plano de projeto de software para o sistema  MEA - monitoraemto de eventos ad...Plano de projeto de software para o sistema  MEA - monitoraemto de eventos ad...
Plano de projeto de software para o sistema MEA - monitoraemto de eventos ad...
 

Kürzlich hochgeladen

autismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderautismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderLucliaResende1
 
Verbos - transitivos e intransitivos.pdf
Verbos -  transitivos e intransitivos.pdfVerbos -  transitivos e intransitivos.pdf
Verbos - transitivos e intransitivos.pdfKarinaSouzaCorreiaAl
 
Ressonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxRessonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxPatriciaFarias81
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxLuzia Gabriele
 
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)profesfrancleite
 
Termo de audiência de Mauro Cid na ìntegra
Termo de audiência de Mauro Cid na ìntegraTermo de audiência de Mauro Cid na ìntegra
Termo de audiência de Mauro Cid na ìntegrafernando846621
 
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...Colaborar Educacional
 
aula 1.pptx Ementa e Plano de ensino Filosofia
aula 1.pptx Ementa e  Plano de ensino Filosofiaaula 1.pptx Ementa e  Plano de ensino Filosofia
aula 1.pptx Ementa e Plano de ensino FilosofiaLucliaResende1
 
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Colaborar Educacional
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxAntonioVieira539017
 
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXA CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXHisrelBlog
 
Como fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresComo fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresEu Prefiro o Paraíso.
 
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfItaloAtsoc
 
O-P-mais-importante.pptx de Maria Jesus Sousa
O-P-mais-importante.pptx de Maria Jesus SousaO-P-mais-importante.pptx de Maria Jesus Sousa
O-P-mais-importante.pptx de Maria Jesus SousaTeresaCosta92
 
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123JaineCarolaineLima
 
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdfRitoneltonSouzaSanto
 

Kürzlich hochgeladen (20)

autismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entenderautismo conhecer.pptx, Conhecer para entender
autismo conhecer.pptx, Conhecer para entender
 
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
 
Verbos - transitivos e intransitivos.pdf
Verbos -  transitivos e intransitivos.pdfVerbos -  transitivos e intransitivos.pdf
Verbos - transitivos e intransitivos.pdf
 
Ressonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxRessonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptx
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsx
 
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)
AS REBELIÕES NA AMERICA IBERICA (Prof. Francisco Leite)
 
Termo de audiência de Mauro Cid na ìntegra
Termo de audiência de Mauro Cid na ìntegraTermo de audiência de Mauro Cid na ìntegra
Termo de audiência de Mauro Cid na ìntegra
 
(42-ESTUDO - LUCAS) DISCIPULO DE JESUS
(42-ESTUDO - LUCAS)  DISCIPULO  DE JESUS(42-ESTUDO - LUCAS)  DISCIPULO  DE JESUS
(42-ESTUDO - LUCAS) DISCIPULO DE JESUS
 
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
 
aula 1.pptx Ementa e Plano de ensino Filosofia
aula 1.pptx Ementa e  Plano de ensino Filosofiaaula 1.pptx Ementa e  Plano de ensino Filosofia
aula 1.pptx Ementa e Plano de ensino Filosofia
 
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
 
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXA CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
 
Abordagem 1. Análise textual (Severino, 2013).pdf
Abordagem 1. Análise textual (Severino, 2013).pdfAbordagem 1. Análise textual (Severino, 2013).pdf
Abordagem 1. Análise textual (Severino, 2013).pdf
 
Como fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de GestoresComo fazer um Feedback Eficaz - Comitê de Gestores
Como fazer um Feedback Eficaz - Comitê de Gestores
 
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdfARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
ARTE BARROCA E ROCOCO BRASILEIRO-min.pdf
 
O-P-mais-importante.pptx de Maria Jesus Sousa
O-P-mais-importante.pptx de Maria Jesus SousaO-P-mais-importante.pptx de Maria Jesus Sousa
O-P-mais-importante.pptx de Maria Jesus Sousa
 
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdfAbordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
Abordagem 2. Análise temática (Severino, 2013)_PdfToPowerPoint.pdf
 
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
 
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
 

plano_de_projeto_controlart_rascunho

  • 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO GERÊNCIA DE PROJETOS 2013/2 Gustavo Souza Santos Kevin Filipe Campos Matias Onezino Gabriel Moreira Tiago Oliveira Santos PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW São Cristóvão - Sergipe, Brasil 2014
  • 2. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO GERÊNCIA DE PROJETOS 2013/2 Gustavo Souza Santos Kevin Filipe Campos Matias Onezino Gabriel Moreira Tiago Oliveira Santos PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como nota parcial para disciplina Gerência de Projetos do curso de graduação em Sistemas de Informação – Bacharelado Universidade Federal de Sergipe. São Cristóvão - Sergipe, Brasil 2014 da
  • 3. Sumário 1. INTRODUÇÃO ................................................................................................. 4 1.1 Âmbito do projeto ........................................................................................ 4 1.2 Principais funções do produto de software ................................................. 5 1.3 Requisitos comportamentais ou de performance ........................................ 6 1.4 Gestão e restrições técnicas ....................................................................... 6 2. ESTIMATIVAS DO PROJETO.......................................................................... 6 2.1 Dados históricos utilizados para as estimações .......................................... 6 2.2 Técnicas de estimação e resultados ........................................................... 7 2.2.1 Técnica de estimação........................................................................... 8 2.3 Resultados .................................................................................................. 8 2.4 Recursos do projeto .................................................................................... 9 2.4.1 Recursos humanos............................................................................... 9 2.4.2 Recursos de software ......................................................................... 11 2.4.3 Recursos de hardware ....................................................................... 11 3 ANÁLISE E GESTÃO DE RISCOS ................................................................. 12 3.1 Riscos do projeto ...................................................................................... 12 3.2 Tabela de riscos ........................................................................................ 13 3.3 Redução e gestão do risco ....................................................................... 14 4 Planejamento Temporal .................................................................................. 19 4.1 Conjunto de Tarefas do Projeto ................................................................ 19 4.2 Diagrama de Gantt .................................................................................... 20 5.0 ORGANIZAÇÃO DO PESSOAL ................................................................... 21 5.1 Estrutura da equipe ................................................................................... 21 5.2 Mecanismos de comunicação ................................................................... 21 5.3 Uso do Edu-blog como ferramenta de apoio............................................. 21 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ............................................................. 21
  • 4. 1. INTRODUÇÃO 1.1 Âmbito do projeto Um estudo realizado por alunos do curso de Sistemas de Informação da Universidade Federal de Sergipe comprovou que não existem softwares nacionais capazes de gerenciar um acervo de arte por completo e que a única forma de alcançar tal objetivo, utilizando métodos atuais, seria através de ferramentas de propósitos distintos que auxiliariam no processo de armazenamento e manipulação de informações referentes ao acervo. Esse modo de proceder, obviamente, está sujeito a uma infinidade de erros que podem prejudicar a qualidade, a disponibilidade e a segurança do serviço prestado tanto ao fornecedor quanto aos seus clientes. O sistema para Controle de Acervo de Arte (ControlArt) apresenta uma solução definitiva para esta problemática. É por esse motivo, construir um ambiente único para o gerenciamento de acervos, que o seu domínio é bastante extenso. A seguir serão listados artefatos que descrevem de forma sucinta o contexto do problema e a solução proposta: Figura 1 - Descrição do problema
  • 5. Figura 2 - Situação de posição do produto 1.2 Principais funções do produto de software O diagrama abaixo apresenta as principais funcionalidades do sistema ControlArt. Os casos de uso que envolvem manutenibilidade de determinado objeto estão relacionados com as seguintes operações: Incluir, alterar e inativar. Os demais itens tratam apenas de inclusão. Figura 3 - Diagrama de casos de uso
  • 6. 1.3 Requisitos comportamentais ou de performance Para atender seus usuários com eficiência e qualidade, o sistema ControlArt deve: 1. Estar de acordo com a regra de negócio do ambiente para o qual foi desenvolvido, o que resulta na similaridades de operações para os usuários; 2. Ser fácil de usar, a fim de proporcionar agilidade e precisão na realização dessas operações; 3. Disponibilizar informações íntegras a todo instante; 4. Restringir o acesso de pessoas não autorizadas, utilizando um processo de autenticação por login, senha e tipo do usuário logado (administrador ou usuário padrão); 5. Não permitir que os usuários excluam as informações armazenadas, apenas inativando-as quando não forem mais necessárias; 6. Não permitir que os usuários editem transações. 1.4 Gestão e restrições técnicas Abaixo serão listadas algumas restrições técnicas do sistema ControlArt: 1. O sistema deve ser desenvolvido utilizando arquitetura web; 2. O sistema deve ser desenvolvido utilizando a linguagem de programação Java; 3. O sistema deve utilizar o PostgreSQL como banco de dados; 4. O acesso ao sistema deve ser feito através de um browser (navegador web). Recomenda-se fortemente o uso do Google Chrome. 2. ESTIMATIVAS DO PROJETO Nesta seção serão descritas as estimativas que permitem calcular custo, esforço e tempo gastos durante a construção do projeto. Essas informações são úteis para analisar e distribuir as atividades de acordo com um cronograma preciso de tempo e recursos necessários para cada uma delas. 2.1 Dados históricos utilizados para as estimações Por se tratar de um projeto didático novo, sob a responsabilidade de uma equipe recém formada, não existem dados históricos utilizados para as estimações.
  • 7. 2.2 Técnicas de estimação e resultados Abaixo serão listadas as técnicas utilizadas para as estimativas: 1. Métrica de Lorens & Kidd - Calcular o tempo total de duração do projeto. Utiliza o diagrama de classes de domínio como fonte de informações. Figura 4 - Diagrama de classes de domínio
  • 8. 2.2.1 Técnica de estimação A métrica mencionada no item 1 da seção anterior foi utilizada de acordo com os seguintes passos: 1. Determinar as classes-chave do projeto, através da análise do diagrama de classes de domínio (apresentado na Figura 4); 2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo com um dos itens da Tabela 1; Interface Multiplicador Interface não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI Complexa 3 Tabela 1 - Valores Interface x Multiplicador 3. Determinar o número de classes de suporte, efetuando o produto da quantidade de classes-chave pelo multiplicador da interface escolhida anteriormente; 4. Determinar o total de classes do projeto, somando a quantidade de classes de suporte com a quantidade de classes-chave; 5. Determinar a quantidade de dias que uma pessoa levaria para construir uma classe. Quando não existem dados históricos a serem considerados, Lorens & Kidd sugerem de 15 a 20 dias; 6. Determinar a quantidade total de dias que uma pessoa levaria para construir todo o projeto, efetuando o produto do total de classes do projeto pela quantidade de dias escolhida anteriormente; 7. Determinar a quantidade total de dias que a equipe levaria para construir todo o projeto, efetuando a divisão da quantidade total de dias pela quantidade de pessoas que a equipe possui. 2.3 Resultados Abaixo será listado o passo-a-passo da execução da métrica descrita na seção anterior: 1. Número de classes-chave encontradas após a análise do diagrama de classes
  • 9. de domínio; 8 classes-chave 2. Interface selecionada (De acordo com o modelo de arquitetura do sistema); GUI 3. Número de classes de suporte encontrado; 8 (item 1) x 2,5 (multiplicador do item 2) = 20 classes de suporte 4. Número total de classes; 20 (item 1) + 8 (item 3) = 28 classes 5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única classe (Valor retirado do intervalo sugerido por Lorens & Kidd); 15 dias 6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema; 15 (item 5) * 28 (item 4) = 420 dias 7. Quantidade total de dias que a equipe gastaria para construir todo o sistema. 420 (item 6) / 4 (quantidade de integrantes) = 105 dias. Sendo assim, de acordo com a métrica de Lorens & Kidd, o tempo necessário para a construção do projeto deve ser de, aproximadamente, 105 dias. Levando em consideração a quantidade de dias úteis no mês (geralmente 22), o projeto se estenderá por, aproximadamente, 5 meses. 2.4 Recursos do projeto Nas seções abaixo serão listados os recursos utilizados na construção do projeto, divididos de acordo com a seguinte classificação: humanos, de software e de hardware. 2.4.1 Recursos humanos Para facilitar o trabalho realizado pela equipe, a duração total do projeto, calculada na seção 2.3, foi dividida de acordo com as seguintes fases:
  • 10. Fase Porcentagem Duração Planejamento 10% 10 dias Análise e Projeto 42% 45 dias Codificação 28% 30 dias Testes 20% 20 dias Tabela 2 - Fases do projeto Para gerenciar o projeto de software utilizamos a metodologia SCRUM. As funcionalidades após serem definidas foram especificadas e divididas em tarefas, essas tarefas, agrupadas e divididas entre os sprints. Ao final de cada sprint entregaremos para os usuários uma parte funcional do software. A cada sprint fazemos o planejamento, codificação e teste do projeto de software. A cada sprint faremos o rodizio de funcionários nas posições de Scrum Master e desenvolvedores, os testes serão feito pelos desenvolvedores. Cada desenvolvedor será responsável pelos testes das implementações das atividade de outro desenvolvedor. A tabela 3 mostra a divisão das funcionalidades dos sprints e a indicação do Scrum Master do sprint. Funcionalidades Início Término Scrum Master Manter tipos de pessoas; Manter pessoas; Manter usuários. 05/05/2014 30/05/2014 Onezino Moreira Manter classificação; Manter acervos. 02/06/2014 20/06/2014 Gustavo Souza Manter peças; Registrar transação. 23/06/2014 11/07/2014 Kevin Filipe Tabela 3 - Definição dos Sprints
  • 11. 2.4.2 Recursos de software Segue abaixo a lista de recursos de software utilizados no projeto: Software Descrição Java Development Kit 7 Ambiente para desenvolvimento de aplicações Java (linguagem utilizada na codificação do projeto). Apache Tomcat 7 Contâiner web utilizado para armazenar e distribuir o software desenvolvido. PostgreSQL 9 Banco de software. iReport 4 Ferramenta gráfica utilizada para a criação de relatórios personalizados. GIT Sistema para controle de versão utilizado no projeto. IDE Eclise Kepler para Java EE IDE utilizada software. Google Chrome Navegador web utilizado desenvolver o software. StarUML Ferramenta utilizada na modelagem dos artefatos visuais do projeto. Microsoft Word Ferramenta utilizada para construir a documentação do projeto. dados na utilizado codificação pelo do para Tabela 4 - Recursos de software 2.4.3 Recursos de hardware Os computadores pessoais de cada integrante foram os únicos recursos utilizados na construção do projeto. As ferramentas utilizadas por eles para a integração das atividades fazem ligação direta com a nuvem, não existindo necessidade de quaisquer recursos adicionais.
  • 12. 3 ANÁLISE E GESTÃO DE RISCOS Nesta seção serão analisados os riscos potenciais que são prejudiciais para o andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a acontecer. 3.1 Riscos do projeto Segue abaixo tabela com os riscos identificados e sua respectiva classificação, que visa determinar se a sua ocorrência é geral ou única do projeto: Risco Projeto Ferramentas de testes oferecem pouco suporte à tecnologia usada na codificação. Técnico Negócio Comum Especial X Tamanho e complexidade do produto comprometem os prazos de entrega. X Projeto construído sem o contato com possíveis usuários. X Curto período para construção do projeto. X X X X a Equipe não possui tempo integral disponível. Funcionalidades codificadas do zero, sem reutilização. Equipe pequena. constante X X X Equipe com pouco conhecimento acerca da tecnologia usada na codificação. Necessidade X de X X X X X
  • 13. aprimoramentos no software. Dificuldade para solucionar problemas encontrados durante a codificação. X X Tabela 5 - Riscos x Classificação 3.2 Tabela de riscos A tabela abaixo atribui a cada um dos riscos uma probabilidade, que determina o grau de chance deste risco acontecer, e um impacto, que determina o nível de desastre resultante após o efetivo acontecimento deste evento. Risco Probabilidade (%) Impacto Ferramentas de testes oferecem pouco suporte à tecnologia usada na codificação. 90% Catastrófico Tamanho e complexidade do produto comprometem os prazos de entrega. 80% Crítico Projeto construído sem o contato com possíveis usuários. 80% Crítico Curto período para construção do projeto. 80% Crítico Equipe não possui tempo integral disponível. 70% Moderado Funcionalidades codificadas do zero, sem reutilização. 70% Moderado Equipe pequena. 70% Marginal Equipe com pouco conhecimento acerca da tecnologia usada na codificação. 60% Moderado a
  • 14. Necessidade constante de aprimoramentos no software. 50% Moderado Dificuldade para solucionar problemas encontrados durante a codificação. 20% Marginal Tabela 6 - Análise Risco x Probabilidade x Impacto 3.3 Redução e gestão do risco riscos Os quadros abaixo apresentam estratégias para a redução e/ou gestão dos estudados anteriormente: 1 - Ferramentas de testes oferecem pouco suporte à tecnologia usada na codificação. Probabilidade: 90%. Impacto: Catastrófico. Descrição: Ferramentas de testes automatizadas oferecem pouco ou nenhum suporte à tecnologia usada na codificação do produto. Estratégia de redução: Minimizar o uso destas ferramentas através da implantação de outros processos de testes. Plano de contingência: Dividir os testes complexos em partes mais simples, facilitando, quando possível, o uso das ferramentas já utilizadas. Responsável: Kevin Filipe Campos. Status: Em andamento. Quadro 1 - Análise do risco 1 2 - Tamanho e complexidade do produto comprometem os prazos de entrega. Probabilidade: 80%. Impacto: Crítico. Descrição: O produto atende a uma necessidade que é bastante simples. No entanto, devido a quantidade de informações que ele deve gerenciar, seu tamanho e complexidade crescem demasiadamente, prejudicando os prazos de entrega.
  • 15. Estratégia de redução: Fazer uma análise apurada do escopo e do planejamento definidos para o projeto. Plano de contingência: Revisar a documentação escrita para tentar reverter, em conjunto os possíveis stackholders, os prazos definidos incorretamente. Uma explicação satisfatória sobre o ocorrido deve ser necessária. Responsável: Gustavo Souza Santos. Status: Em andamento. Quadro 2 - Análise do risco 2 3 - Projeto construído sem o contato com possíveis usuários. Probabilidade: 80%. Impacto: Crítico. Descrição: O projeto foi construído sem a presença de usuários que conhecem as regras de negócio do ambiente. Estratégia de redução: Reverter a situação o mais rápido possível, procurando por possíveis clientes que estejam interessados no produto. Plano de contingência: Disponibilizar versões de testes para usuários que conhecem as regras de negócio do ambiente e que podem opinar a respeito do que está sendo desenvolvido. Responsável: Gustavo Souza Santos. Status: Em andamento. Quadro 3 - Análise do risco 3 4 - Curto período para a construção do projeto. Probabilidade: 80%. Impacto: Crítico. Descrição: Devido a grande carência do mercado, o prazo para construção do projeto é relativamente curto. Estratégia de redução: Divisão pertinente das atividades de acordo com com um planejamento preciso.
  • 16. Plano de contingência: Seguir a risca as informações e prazos detalhados na especificação do projeto. Responsável: Onezino Gabriel Moreira. Status: Em andamento. Quadro 4 - Análise do risco 4 5 - Equipe não possui tempo integral disponível. Probabilidade: 70%. Impacto: Moderado. Descrição: Devido a outras atividades realizadas por cada integrante da equipe, o tempo disponível para o projeto não é integral. Estratégia de redução: Divisão pertinente das atividades de acordo com com um planejamento de tempo preciso. Plano de contingência: Rever as atividades realizadas por cada integrante a fim de não sobrecarregá-lo. A divisão das tarefas entre os membros da equipe deve facilitar o processo. Responsável: Tiago Oliveira Santos. Status: Em andamento. Quadro 5 - Análise do risco 5 6 - Funcionalidades codificadas do zero, sem reutilização. Probabilidade: 70%. Impacto: Moderado. Descrição: As funcionalidade do software foram desenvolvidas do zero, sem a utilização/criação de nenhum componente reutilizável. Estratégia de redução: Adotar medidas que priorizem o desenvolvimento de componentes reutilizáveis sempre que possível e necessário Plano de contingência: Modificar as estruturas dos itens que precisam de reutilização para que se tornem reutilizáveis, evitando a necessidade de replicar código.
  • 17. Responsável: Tiago Oliveira Santos. Status: Em andamento. Quadro 6 - Análise do risco 6 7 - Equipe pequena. Probabilidade: 70%. Impacto: Marginal. Descrição: A equipe responsável pela construção do projeto é relativamente pequena. Estratégia de redução: Divisão pertinente das tarefas da equipe de acordo com um planejamento preciso, combatendo também a sobrecarga de funções. Plano de contingência: Rever a distribuição de tarefas entre os membros da equipe. O excesso de funções/atividades deve ser evitado a todo custo. Responsável: Onezino Gabriel Moreira. Status: Em andamento. Quadro 7 - Análise do risco 7
  • 18. 8 - Equipe com pouco conhecimento acerca da tecnologia usada na codificação. Probabilidade: 60%. Impacto: Moderado. Descrição: A equipe não possui conhecimento aprofundado acerca da tecnologia utilizada na codificação do projeto. Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a respeito da tecnologia utilizada. Plano de contingência: Planejar o desenvolvimento de estruturas complexas em equipe, ao invés de individualmente. Responsável: Kevin Filipe Campos. Status: Em andamento. Quadro 8 - Análise do risco 8 9 - Necessidade constante de aprimoramentos no software. Probabilidade: 50%. Impacto: Moderado. Descrição: Como o software foi desenvolvido sem a presença de um usuário em potencial, a necessidade de modificações pode ser constante. Estratégia de redução: Disponibilizar versões de testes para usuários que conhecem as regras de negócio do ambiente e que podem opinar a respeito do que está sendo desenvolvido, com o intuito de melhorar as regras de negócio. Plano de contingência: Planejar as modificações de acordo com as necessidades e obrigações da equipe. Responsável: Kevin Filipe Campos. Status: Em andamento. Quadro 9 - Análise do risco 9
  • 19. 10 - Dificuldade para solucionar problemas encontrados durante a codificação. Probabilidade: 20%. Impacto: Marginal. Descrição: Devido a complexidade que envolve a tecnologia usada na codificação, os erros podem levar tempo considerável para serem resolvidos. Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a respeito da tecnologia utilizada. Plano de contingência: Planejar a solução das pendências em equipe, ao invés de individualmente. Responsável: Gustavo Souza Santos. Status: Em andamento. Quadro 10 - Análise do risco 10 4 Planejamento Temporal Nesta seção são definidas as datas de execução das tarefas, bem como seus responsáveis. No planejamento temporal definimos os marcos e planos de ações. O cronograma das tarefas está baseado na metodologia aplicada ao projeto e a mensuração das fases de do projeto de software conforme definimos no item 2.X.X 4.1 Conjunto de Tarefas do Projeto A definição do conjunto de tarefas de projeto utilizou o modelo iterativo incremental, como a metodologia encoraja a entrega rápida e constante para utilização do usuários fizemos marcos de liberação de módulos do produto de software para o usuário. O scrum define a divisão das funcionalidades em atividades menores que podem ser executadas pelo desenvolvedores. Na tabela abaixo está a listagem das atividades a serem executadas em cada funcionalidade. Funcionalidade Funcionalidade administração Atividades de -Desenvolvimento da tela de administração de segurança, de pessoa e usuários
  • 20. tabelas do sistema - Desenvolvimento da regra de negócio e persistência das entidades de usuário e segurança - Gerar carga inicial dos objetos de segurança, pessoal, usuário Manutenção de - Telas de registro de acervos, de peças e de vinculação de acervos e peças peças com o acervo - Desenvolvimento das regras de negócio e persistência das entidades acervos e peças Registro transação classificação de - Tela para registro de transação, classificação de acervo e e peças - Desenvolvimento das regras de negócio e persistência das entidades de transação e classificação. Tabela 7 – Tabela de Atividades 4.2 Diagrama de Gantt O diagrama de Gantt nos permite visualizar de forma gráfica o avanço e planejamento das diferentes etapas de um projeto. A cada inicio e fim da atividade é mostrado em intervalos. O detalhamento de nossas atividades no diagrama de Gantt está disponível em: Figura 5 - Diagrama de Gantt
  • 21. 5.0 ORGANIZAÇÃO DO PESSOAL 5.1 Estrutura da equipe ● ● ● ● Gerente de Projeto: Onezino Gabriel Moreira Analista de Sistema: Kevin Filipe Desenvolvedor: Tiago Oliveira Analista de Testes: Gustavo Souza 5.2 Mecanismos de comunicação Os mecanismos de comunicação utilizados serão: ● E-mail - facilidade de comunicação e permite manter o registro das discussões; ● Reuniões diárias - permitem a comunicação face-a-face e ajudam a verificar o andamento do projeto; ● Ferramentas colaborativas - vários documentos foram editados através do Google Drive, permitindo a colaboração de todos. 5.3 Uso do Edu-blog como ferramenta de apoio O blog é uma ferramenta interessante, pois permite que seja disseminado o conhecimento adquirido durante o projeto, tanto entre os integrantes do projeto quanto para outras pessoas. Também ajuda na catalogação das informações mais importantes, criando uma maneira rápida de se localizar dados importantes mesmo após o fim do projeto. 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ● Documentação - A cada etapa do projeto serão produzidos documentos. Estes serão importantes na elaboração dos testes. Também servirão para guiar o andamento do projeto. Deverão ser atualizados quando houverem mudanças; ● Testes - Serão elaborados com o auxílio da documentação e executados durante todas as fases do projeto; ● Controle de versão - Ferramenta que permitirá o rastreamento de alterações e identificarão os seus autores. Ajudam a manter os documentos atualizados; ● Reuniões diárias - Utilizando a idéia do SCRUM, reuniões diárias de curta duração serão realizadas para verificar o andamento do projeto.