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. Planejamento Temporal

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 para assegurar e controlar a 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

Education