Plano de Projeto de Software NutriBR

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Gerência de Projetos 2014.2
PLANO DO PROJETO DE SOFTWARE
para produtos da Lacertae SW
GRUPO 5
Affonso de Oliveira Souza Neto
Ana Rute Passos
Matheus Nascimento Oliveira
Thiers Menezes
Valdicélio Mendes
São Cristóvão – Sergipe
2014

Affonso de Oliveira Souza Neto
Ana Rute Passos
Matheus Nascimento Oliveira
Thiers Menezes
Valdicélio Mendes
PLANO DO PROJETO DE SOFTWARE
para produtos da Lacertae SW
Trabalho apresentado ao Prof. Dr.
Rogério Patrício Chagas do Nascimento
como parte avaliativa da disciplina
Gerência de Projetos do Curso de
Graduação em Sistemas de Informação
da Universidade Federal de Sergipe –
UFS.
São Cristóvão – Sergipe
2014

Sumário
1. Introdução ....................................................................................................................4
1.1 Âmbito do Projeto ..................................................................................................4
1.2 Funções principais do produto de software.......................................................4
1.3 Requisitos comportamentais ou de performance.............................................5
1.4 Gestão e Restrições Técnicas.............................................................................5
2. Estimativas do Projeto ................................................................................................6
2.1 Dados históricos utilizados para as estimativas ...............................................6
2.2 Técnicas de estimação e resultados ..................................................................6
2.2.1 Técnica de estimação........................................................................................6
2.3 Resultados..............................................................................................................7
2.4 Recursos do Projeto..............................................................................................8
2.4.1 Recursos Humanos .......................................................................................8
2.4.2 Recursos de Hardware..................................................................................8
2.4.3 Recurso de Software .....................................................................................9
3. Análise e Gestão de Riscos .....................................................................................10
3.1 Riscos do projeto .................................................................................................10
3.2 Tabela de riscos...................................................................................................12
3.3 Redução e Gestão do Risco ..............................................................................13
4. Planejamento Temporal............................................................................................22
4.1 Conjunto de Tarefas do Projeto ........................................................................22
4.2 Diagrama de Gantt ..............................................................................................24
5. Organização do Pessoal...........................................................................................25
5.1 Estrutura da equipe .............................................................................................25
5.2 Mecanismos de comunicação ...........................................................................26
5.3 Uso do Edu-blog como ferramenta de apoio ..................................................26
6. Precauções tomadas para assegurar e controlar a qualidade do produto de
SW....................................................................................................................................27
7. Anexos.........................................................................................................................28

1. Introdução
1.1 Âmbito do Projeto
O software NutriBR foi desenvolvido em 2013 com o objetivo de auxiliar o
HU (Hospital Universitário) na coleta de dados sobre alimentação de pacientes.
O Software gerencia uma base de dados para acompanhar a dieta de
pacientes com problemas cardíacos distribuídos em dois grupo (grupo
prevenção e grupo controle).
As entradas são dados antropométricos e dieta, as saídas são dados
armazenados no banco de dados organizados para consulta em um Sistema
Web e geração de relatórios.
1.2 Funções principais do produto de software
O sistema é composto por funcionalidades que permitem o controle dos
dados inseridos pelos usuários.
As principais funcionalidades e os respectivos usuários estão detalhados
na Tabela 1 abaixo.
Funcionalidade Usuário
Cadastrar pacientes Nutricionista
Cadastrar usuários Nutricionista
Cadastrar dados antropométricos Nutricionista
Cadastrar a dieta dos pacientes Nutricionista
Tabela 1 – Funcionalidades e Usuários do NutriBR.
Um diagrama de casos de uso está disponível na Figura 7.1, localizado
na seção 7(Anexos) deste documento. A figura apresenta de forma detalhada de
como será o uso do software.

1.3 Requisitos comportamentais ou de performance
Para que o NutriBR possa atender de forma eficiente aos seus usuários, o
sistema deve:
1. Ser fácil de usar, possuindo uma linguagem de acordo com o
ambiente do negócio.
2. Ser capaz de estar funcionando a todo momento (próximo às 24
horas do dia).
3. Os dados manipulados pelos usuário de um grupo (controle) não
podem ser visto pelos usuários do outro grupo (prevenção) e vice-versa.
4. As informações armazenadas pelo NutriBR deverão ser íntegras
para geração de dados concretos da pesquisa.
.
1.4 Gestão e Restrições Técnicas
As restrições técnicas que definem o escopo do NutriBR são:
1. O sistema de gerenciamento de banco de dados deverá ser o
PostgreSQL.
2. A linguagem de programação deverá ser Ruby.
3. Todas as máquinas do Hospital Universitário que serão usadas para
acesso do sistema devem possuir um Navegador Web.
4. O Framework de Desenvolvimento utilizado para o desenvolvimento
da ferramenta deverá ser o Ruby On Rails.
5. O funcionamento do NutriBR depende de uma infraestrutura de rede
intranet entre os diversos computadores que o utilizarão.

2. Estimativas do Projeto
Serão descritas nesta seção as etapas utilizadas para calcular o tempo
total de execução deste projeto. A métrica utilizada foi a de Lorenz & Kidd, que
estima o esforço em termos de dias por pessoa.
2.1 Dados históricos utilizados para as estimativas
Como se trata do primeiro projeto da equipe, não há dados históricos para
auxiliar na estimação.
2.2 Técnicas de estimação e resultados
Será utilizada a métrica de Lorenz&Kidd para estimar o tempo de
consecução do projeto.
2.2.1 Técnica de estimação
A métrica de Lorenz&Kidd, orientada a classe, consiste em:
1. Identificar a quantidade de classes chave do projeto;
2. Encontrar a quantidade de classes suporte através da multiplicação da
quantidade de classes chave pelo fator correspondente ao tipo da
interface do projeto, conforme a Tabela 2 abaixo:
Tabela 2 - Interface x Multiplicador.
3. Calcular o total de classe por meio da soma entre a quantidade de
classes chave e quantidade de classes de suporte.

4. Multiplicar o total de classes pelo número médio de unidades de
trabalho (dias-pessoa) por classe, que seriam de 15 e 20 dias, segundo
a métrica.
5. Assim, calcula-se o tempo previsto para desenvolvimento do projeto.
2.3 Resultados
A seguir, os dados e cálculos do projeto:
1. Classes chaves: 6 classes. Um diagrama de classes está disponível
na Figura 7.2, localizado na seção 7(Anexos) deste documento. A
figura apresenta de forma detalhada as classes definidas no projeto.
Classes principais: Usuário, ProfissionalSaude, VisitaClinica, Paciente,
Recordatório e EventosClinicos.
2. Tipos de classes de suporte: GUI simples;
3. Fator multiplicador: 2,5;
4. Classes de suporte: 6 x 2,5 = 15 (Classes x Fator);
5. Total de classes: 6 + 15 = 21 (chave + suporte);
6. Como não há registros históricos anteriores, usa-se como base a
sugestão da técnica de Lorenz & Kidd (15 a 20 dias/pessoa). Assim,
determinou-se 17 dias/pessoa como número médio de unidades de
trabalho;
7. Tempo previsto: 21 x 17 = 357 (total de classes x unidade de trabalho)
dias por pessoa para construção das classes;
8. Como a equipe é formada por 05 componentes, resulta no total de 71
dias;
9. Levando-se em consideração os cerca de 22 dias úteis por mês,
chega-se ao tempo previsto de quase 3 meses para finalização do
Projeto.

Considerando os percentuais de distribuição de componentes essenciais
no projeto, sugeridas pelas diretrizes da Lacertae Software, os 71 dias
estimados para o desenvolvimento do projeto são distribuídos nas respectivas
fases do projeto, apresentadas na Tabela 3.
Fase Estimativa Dias de Trabalho
Planejamento 4% 71 x 4% = 3 dias
Análise e Projeto 20% 71 x 20% = 14 dias
Geração de Código 40% 71 x 40% = 28 dias
Testes 36% 71 x 36% = 26 dias
Tabela 3 – Estimativa dos dias de trabalho por fase do projeto.
2.4 Recursos do Projeto
Nesta seção são apresentados os Recursos Humanos, Recursos de
Software e Recursos de Hardware.
2.4.1 Recursos Humanos
● 01 Gerente de Projetos;
● 01 Gerente de Negócios;
● 01 Analista de Testes;
● 02 Engenheiros de Software.
2.4.2 Recursos de Hardware
03 Estações de Trabalho com as seguintes configurações:
● Processador Core I5 de 3,0GHZ ou similar
● 8 GB de Memória Ram
● 250GB de Armazenamento

● 2 Monitores de 19 Polegadas
02 Notebooks com as seguintes configurações:
● Processador Core I3 de 2,4GHZ ou similar
● 4 GB de Memória Ram
● 250GB de Armazenamento
● Tela de 14 Polegadas
2.4.3 Recurso de Software
Para a construção do software serão utilizados alguns outros softwares
que auxiliarão no processo de desenvolvimento. Dentro de um conjunto de
softwares estão contidos editor de texto, servidor HTTP, máquina virtual, IDE de
Desenvolvimento, entre outros.
Apache 2.4 - Servidor HTTP produzido pela Apache e distribuído como software
livre.
Ruby - Linguagem de programação utilizada no desenvolvimento do projeto.
RubyMine 6 - IDE de codificação do software.
NetBeans - IDE de codificação do software.
Google Chrome - Navegador Web.
Mozilla Firefox - Navegador Web.
StarUML - Ambiente de modelagem dos diagramas UML.
Microsoft Office Word – Editor de texto para a documentação do software.
Open Project - Ambiente de gerenciamento e criação de cronogramas a serem
executados durante o processo de desenvolvimento do software.
Google Drive - Software de armazenamento em nuvem.
GIT - Sistema livre de controle de versão.
GitHub - Armazenamento em nuvem do controle de versão implementado pelo
GIT.

3. Análise e Gestão de Riscos
Nesta seção, serão analisados os riscos de acordo com as classificações
e com base na probabilidade de ocorrência dos mesmos. Isso permitirá definir
como será o impacto no projeto e formas de minimizar essas ocorrências.
3.1 Riscos do projeto
Os riscos de um projeto podem ser distinguidos em riscos gerais (comuns
a todo projeto) e riscos únicos do projeto.
Os riscos gerais são listados na Tabela 4 abaixo:
Risco Projeto Técnico Negócio Comum Especial
Equipamento não
disponível
X
Requisitos incompletos X X
Uso de metodologias
especiais
X X
Problemas na busca da
confiabilidade requerida
X X
Retenção de pessoas
chaves
X X
Subestimativas do
esforço
X X
Tabela 4 – Riscos gerais de um projeto de software.

Avaliação global dos riscos:
1. O Gestor de Software dá suporte ao projeto?
Sim. O gestor de software tem um papel importante e muito participativo,
o que contribui para o bom andamento do projeto.
2. Os Clientes estão entusiasmados com o projeto e o produto?
O cliente está muito interessado no produto pois o software permitirá
gerar um banco de dados rico em informações de dieta de pacientes.
3. Os Engenheiros de Software compreenderam bem os requisitos?
Sim, os engenheiros compreendem bem os requisitos do projeto.
4. Os Clientes estiveram envolvidos na definição dos requisitos?
Não. Foram muito solícitos na coleta de requisitos mas por serem muito
atarefados, os encontros com a equipe são raros.
5. O âmbito do projeto é estável?
Sim.
6. Os engenheiros de Software têm as competências requeridas?
Apesar de pouco experientes, os Engenheiros de Software foram bem
orientados na vida acadêmica e possuem base sólida para a função.

7. Os requisitos do projeto são estáveis?
Os requisitos foram bem definidos no início do trabalho e não foram
necessárias alterações posteriores.
8. A Equipe de Desenvolvimento tem experiência na tecnologia a
implementar?
Não, poucos membros da equipe têm boa experiência com a tecnologia
utilizada.
9. É adequado o número de pessoas da equipe de trabalho?
Sim. Mesmo com a falta de experiência com a tecnologia, a equipe está
fazendo grande progresso ao familiarizar-se com as ferramentas.
3.2 Tabela de riscos
A Tabela 5 demostra os riscos identificados no projeto com seus valores
de probabilidade associados. Um ponto de corte foi definido para agrupar e
destacar riscos que possuem probabilidade de 50% ou superior.
Nº Risco Categoria Probabilidade Impacto
1 O cliente não possui ideias claras
sobre os requisitos Cliente 80% 5 (catastrófico)
2 Disponibilidade de hardware no
servidor do HU Tecnologia 80% 5 (catastrófico)
3 Curto período para a construção do
projeto Equipe 80% 4 (crítico)
4 Defeito do produto Negócio 70% 4 (crítico)
5 Funcionalidades implementadas do Tecnologia 70% 4 (crítico)

zero, sem reutilização
6 Tecnologia nova Tecnologia 70% 3 (moderado)
7 Restrição governamental Negócio 60% 3 (moderado)
8 Atraso na entrega Negócio 60% 3 (moderado)
9 Integrantes não possuem as
habilidades necessárias Equipe 50% 2 (marginal)
Linha de corte
10 Restrição de interoperabilidade Negócio 40% 2 (marginal)
11 Sem experiência anterior com o
cliente Cliente 40% 2 (marginal)
12
Revisão técnica formal
Maturidade do
processo 40% 2 (marginal)
13 Cliente com pouca participação
nas revisões Cliente 40% 2 (marginal)
14 Equipe não foi devidamente
treinada Equipe 30% 2 (marginal)
15 Pessoas trabalhando apenas 1
turno Equipe 25% 1 (insignificante)
Tabela 5 – Tabela de riscos específicos.

3.3 Redução e Gestão do Risco
Ações para prever, reduzir ou gerir os riscos identificados:
1. O cliente não possui ideias claras sobre os requisitos
Probabilidade: 80% Impacto: Catastrófico
Descrição: O cliente não consegue exprimir exatamente quais são suas reais necessidades.
Estratégia de redução: Utilizar as técnicas de levantamento de requisitos (entrevistas,
questionários, etc)
Plano de contingência: Alocar a equipe para acompanhar a rotina do cliente com o objetivo
de ajudá-lo na identificação dos requisitos.
Responsável: Valdicélio Mendes
Status: Iniciado
2.Disponibilidade de Hardware no Servidor do HU
Probabilidade: 80% Impacto: Catastrófico
Descrição: Obsolescência do servidor de aplicação poderá prejudicar o desempenho do
sistema.
Estratégia de redução: Solicitar a revitalização do servidor.
Plano de contingência: Solicitar ao cliente a troca do servidor.
Status: Iniciado

3.Curto período para a construção do projeto
Probabilidade: 80% Impacto: Crítico
Descrição: A qualidade do projeto poderá ser comprometida por falta de tempo.
Estratégia de redução: Unir todos os recursos disponíveis para acelerar o processo de
construção do projeto.
Plano de contingência: Solicitar ao cliente extensão do prazo de entrega.
Status: Iniciado
4. Defeito do produto
Descrição: Produto com mal funcionamento.
Estratégia de redução: Criar um script de log automático de notificação de defeito.
Plano de contingência: Utilizar um SaSS de gerenciamento de falhas (bug tracker).
Responsável: Rute
Status: Iniciado

5. Funcionalidades implementadas do zero, sem reutilização
Descrição: Não há código de projetos anteriores para serem utilizados.
Estratégia de redução: procurar projetos open source que possamos reutilizar alguma
funcionalidade.
Plano de contingência: Criar as novas funcionalidades.
Responsável: Rute
Status: Iniciado
6. Tecnologia nova
Probabilidade: 70% Impacto: Moderado
Descrição: Tecnologia desconhecida pela equipe.
Estratégia de redução: Sugerir que os integrantes da equipe participem de cursos e
discussões em grupo.
Plano de contingência: Adotar uma tecnologia conhecida pela equipe.
Responsável: Rute
Status: Iniciado

7. Restrição Governamental
Descrição: O uso do software infligiu regras de uso em hospitais.
Estratégia de redução: Instruir a equipe sobre regras da área da saúde.
Plano de contingência: Corrigir imediatamente o motivo de impedimento do sistema.
Responsável: Affonso
Status: Iniciado
8. Atraso na entrega
Descrição: O produto não será entregue no prazo definido.
Estratégia de redução: Acompanhamento do desenvolvimento do projeto.
Plano de contingência: Parcerias com empresas de desenvolvimento terceirizadas.
Status: Iniciado

9. Integrantes não possuem as habilidades necessárias
Probabilidade: 50% Impacto: Marginal
Descrição: Equipe sem treinamento necessário
Estratégia de redução: Sugerir que os integrantes da equipe participem de cursos e
discussões em grupo.
Plano de contingência: Formar parcerias com centros de cursos especializados.
Status: Iniciado
10. Restrição de Interoperabilidade
Descrição: O sistema deverá possuir um canal de interação com outros sistemas
Estratégia de redução: Adicionar ao plano de projeto a documentação de desenvolvimento
de uma API para estabelecimento de comunicação de entrada e saída de dados através do
sistema.
Plano de contingência: Desenvolver uma API e a documentação da mesma para
comunicação com sistemas externos
Responsável: Matheus Oliveira
Status: Iniciado

11. Sem experiência anterior com o cliente
Descrição: A equipe não possui experiência de trabalhos anteriores com o cliente.
Estratégia de redução: Incluir no Plano de Projeto reuniões semanais com o cliente.
Plano de contingência: Solicitar ao cliente para que faça uma apresentação de todo o
negócio e o contexto onde está inserido para a equipe.
Status: Iniciado
12. Revisão técnica formal
Descrição: É necessário realizar revisão técnica formal por parte do cliente.
Estratégia de redução: Solicitar ao cliente a participação das reuniões de modelagem do
processo para homologação dos mesmos.
Plano de contingência: Incluir no Plano de Projeto reuniões de modelagem de processos
com o cliente
Status: Iniciado

13. Cliente com pouca participação nas revisões
Descrição: A falta de interesse do cliente no andamento do projeto pode fazer com que a
equipe cometa erros, causando desistência do cliente.
Estratégia de redução: Motivar a participação constante do cliente no projeto.
Plano de contingência: Mostrar para o cliente que a participação dele é importante e mostrar
como o software pode ser, de fato, interessante para o negócio dele.
Responsável: Thiers
Status: Iniciado
14. Equipe não foi devidamente treinada
Descrição: Equipe sem capacidade para desenvolver o projeto na linguagem sugerida.
Estratégia de redução: Preparar a equipe disponibilizando cursos de capacitação.
Plano de contingência: Usar linguagem que a equipe domina e está acostumada a trabalhar.
Status: Iniciado

15. Pessoas trabalhando apenas um turno
Probabilidade: 30% Impacto: Insignificante
Descrição: Desenvolvedores que não trabalham integralmente ao projeto podem causar
atrasos.
Estratégia de redução: Motivar a equipe trabalhando inteiramente no projeto.
Plano de contingência: Considerar a adoção de incentivos financeiros referente à
produtividade.
Status: Iniciado

4. PlanejamentoTemporal
Nesta seção iremos definir todas as atividades relativas à execução do
projeto com suas respectivas data de execução e prazo. Para auxiliar a
visualização de todas as tarefas,em relação ao aspecto temporal faremos o uso
do gráfico de Gantt.
4.1 Conjunto de Tarefas do Projeto
A metodologia de desenvolvimento de software escolhida foi o RUP, que
se divide-se em quatro fases: Concepção/Iniciação, Elaboração,
Codificação/Construção e Transição/Testes.
Os detalhes do cronograma de tarefas são expostos na Tabela 6 abaixo.
Id Tarefa Duração Início Término
1 Concepção/Iniciação 3 dias 02/02/2015 04/02/2015
2 Realizar levantamento de requisitos 2 dias 02/02/2015 03/02/2015
3 Elaborar especificação dos requisitos 2 dias 03/02/2015 04/02/2015
4 Elaboração 20 dias 05/02/2015 24/02/2015
5 Elaborar Modelo de Caso de Uso 2 dias 05/02/2015 06/02/2015
6 Elaborar Diagrama de Classes 2 dias 09/02/2015 10/02/2015
7 Elaborar Diagrama de Estado 2 dias 11/02/2015 12/02/2015
8 Elaborar Diagrama de Componentes 4 dias 13/02/2015 16/02/2015
9 Elaborar Diagrama de Sequência 2 dias 17/02/2015 18/02/2015
10 Elaborar Diagrama de Implantação 1 dias 19/02/2015 19/02/2015
11 Projetar Interfaces 4 dias 20/02/2015 23/02/2015

12 Avaliar projeto de intefaces 1 dias 24/02/2015 24/02/2015
13 Codificação/Construção 38 dias 25/02/2015 03/04/2015
14 Cadastrar Paciente 3 dias 25/02/2015 27/02/2015
15 Consultar Paciente 3 dias 02/03/2015 04/03/2015
16 Alterar Paciente 5 dias 05/03/2015 09/03/2015
17 Excluir Paciente 2 dias 10/03/2015 11/03/2015
18 Cadastrar Especialista 5 dias 12/03/2015 16/03/2015
19 Consultar Especialista 3 dias 17/03/2015 19/03/2015
20 Alterar Especialista 5 dias 20/03/2015 24/03/2015
21 Excluir Especialista 2 dias 25/03/2015 26/03/2015
22 Manutenir Dieta 5 dias 27/03/2015 31/03/2015
23 Emitir Relatório 3 dias 01/04/2015 03/04/2015
24 Transição/Testes 23 dias 07/04/2015 29/04/2015
25 Especificar de Testes 3 dias 07/04/2015 09/04/2015
26 Executar Testes 8 dias 10/04/2015 17/04/2015
27 Analisar resultados 2 dias 20/04/2015 21/04/2015
28 Realizar testes de aceitação 6 dias 22/04/2015 27/04/2015
29 Entregar software 2 dias 28/04/2015 29/04/2015
Tabela 6 – Cronograma do diagrama de Gantt.

4.2 Diagrama de Gantt
A figura 1 representa o Diagrama de Gantt de acordo com o cronograma
de tarefas apresentado na Tabela 6.
Figura 1 – Diagrama de Gantt.

5. Organização do Pessoal
Nesta seção será apresentada a forma de distribuição dos recursos
humanos no projeto e qual a função de cada papel.
5.1 Estrutura da equipe
Gerente de Projetos:
Responsável pela alocação de recursos, ajuste de prioridades,
coordenação das interações entre clientes e usuários.
Gerente de Negócios:
Busca maximizar as oportunidades para a empresa e para o projeto,
entendendo sobre os desejos e necessidades dos seus clientes.
Analista de Testes:
Será o responsável por identificar e definir os testes, monitorar a
abrangência dos testes e avaliar a qualidade obtida após os testes.
Engenheiro de Software:
Terá a responsabilidade de liderar e coordenar a equipe na identificação
de requisitos e na modelagem de casos de uso, delimitando o sistema e
definindo sua funcionalidade.
A Tabela 7 mostra, de forma geral, como ficou a distribuição de funções
entre os integrantes da equipe.
Papel Integrante
Gerente de Projetos Matheus Oliveira
Gerente de Negócios Affonso Souza
Engenheiro de Software Valdicélio Mendes

Engenheiro de Software Thiers Menezes
Analista de Testes Ana Rute Passos
Tabela 7 – Distribuição de papéis.
5.2 Mecanismos de comunicação
A comunicação entre a própria equipe e os clientes será feita pelos
seguintes meio:
● E-mail: ferramenta mais utilizada, principalmente pelo alcance entre os
participantes e com o cliente.
● Google Hangout: poderoso software de comunicação que permite de
conversas de texto a conferências.
● Reuniões presenciais: recurso que permite, de forma rápida, identificar
a situação do projeto e solucionar problemas locais.
5.3 Uso do Edu-blog como ferramenta de apoio
A utilização do Edu-blog incentiva a pesquisa dos temas propostos pela
disciplina. Permite que cada equipe se aprofunde no assunto designado pelo
Professor, compartilhando o conhecimento com os demais colegas ao longo e
ao final do semestre e com qualquer usuário da Internet.
Essa ferramenta deveria ser utilizada em outras disciplinas, pois, forçaria
que os alunos estudassem os assuntos e depois haveria a compilação dos
principais tópicos para apresentação ao final da disciplina.

6. Precauções tomadas paraassegurar e controlara qualidade
do produto de SW
Com a finalidade de garantir a qualidade de todas as fases do projeto,
algumas preocupações foram tomadas:
Documentação: durante todo o ciclo de vida do software, foram
produzidos documentos. A produção de documentação fornece um parâmetro
para avaliar o que foi feito na prática em comparação com o que foi descrito.
Essa documentação é importante na elaboração dos testes, a fim de que o
sistema esteja totalmente de acordo com as especificações. Também serve para
guiar o andamento do projeto. A documentação deverá ser atualizada quando
houver mudanças.
Testes: A fim de garantir a qualidade final ao produto e minimizar as
eventuais falhas que viessem a ocorrer, os testes de software foram elaborados
e colocados em prática durante todo o ciclo de desenvolvimento do projeto.
Desde o levantamento de requisitos até possíveis manutenções no produto
depois de ele ter sido entregue. A contínua aplicação de testes permite que os
defeitos sejam descobertos o mais cedo possível, causando assim um menor
impacto nos custos de modificações do software.
Controle de versão: ferramenta que permite o rastreamento de
alterações, identificando os seus autores. Ajuda a manter os documentos
atualizados.
Reuniões diárias: utilizando a ideia do SCRUM, reuniões diárias de curta
duração foram realizadas para verificar o andamento do projeto.
Acompanhamento do projeto: as atividades desenvolvidas durante todo
o ciclo de desenvolvimento são acompanhadas constantemente e todos os
requisitos são validados com os clientes.

7. Anexos
Figura 7.1 - Diagrama de casos de uso

Figura 7.2 - Diagrama de classes do projeto

Plano de Projeto de Software NutriBR

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Plano de Projeto de Software NutriBR

Último

Plano de Projeto de Software NutriBR