UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO

Sistema de Informação Nutricional - SIN

Plano de Projeto de Software

Artur Frederico Figueira dos Santos, Crisnaldo Carvalho Santos, Everton Portela
Santos, Felipe Meneses dos Santos, Vinicius de Oliveira Sobral

Prof.° Dr.° Rogerio Patricio Chagas do Nascimento

São Cristóvão/SE
2019
 UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO

Artur Frederico Figueira dos Santos, Crisnaldo Carvalho Santos, Everton Portela
Santos, Felipe Meneses dos Santos, Vinicius de Oliveira Sobral

Sistema de Informação Nutricional - SIN

Plano de Projeto de Software do Sistema

de Informação Nutricional, para o Setor de
Nutrição do Hospital Universitário -
HU/UFS realizado para a matéria de
Gerência de Projetos do Departamento de
Computação da Universidade Federal de
Sergipe.

Prof.° Dr.° Rogerio Patricio Chagas do

Nascimento.

São Cristóvão/SE
2019
 SUMÁRIO

1 - INTRODUÇÃO 2
1.1 Âmbito do Projeto 2
1.2 Funções principais do produto de software 2
1.3 Requisitos comportamentais ou de performance 4
1.4 Gestão e Restrições Técnicas 5

2 - ESTIMAÇÕES DO PROJETO 6
2.1 Dados históricos utilizados para as estimações 6
2.2 Técnicas de estimação e resultados 6
2.2.1 Técnica de estimação 6
2.3 Resultados 7
3 - ANÁLISE E GESTÃO DE RISCOS 8
3.1 Riscos do projeto 8
3.2 Tabela de riscos 8
3.3 Planos de Redução e Gestão do Risco 9

4 - PLANEAMENTO TEMPORAL 13
4.1 Recursos do projeto 13
4.2 Conjunto de Tarefas do Projeto 13
4.2 Diagrama de Gantt 16

5 - ORGANIZAÇÃO DO PESSOAL 18
5.1 Estrutura da equipe 18
5.2 Mecanismos de comunicação 18
5.3 Uso do Edu-blog como ferramenta de apoio 19

6 - PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A

QUALIDADE DO PRODUTO DE SW 20

7 - REFERÊNCIAS BIBLIOGRÁFICAS 21
1 - INTRODUÇÃO

1.1 Âmbito do Projeto

O setor de Nutrição do Hospital Universitário - HU/UFS não dispõe de uma visualização dos
indicadores de qualidade do processo de atendimento. Os dados gerados pelas demandas
atendidas começaram a ser coletados pelas nutricionistas no final do ano de 2017 e por
enquanto estão sendo armazenados em planilhas eletrônicas. O impacto esperado pelo Setor
de Nutrição é que o sistema de informação fornecido, facilite o processo de coleta de dados
dos insumos administrados aos pacientes e em paralelo forneça indicadores de desempenho de
atendimento da equipe. Pretende-se também impactar de forma positiva, auxiliando na tomada
de decisão do Setor de Nutrição e da Gestão do Hospital, além de auxiliar em processos
licitatórios para aquisição de insumos, suplementos e dietas para o hospital, uma vez que terão
informações mais precisas sobre quantidades utilizadas, tempo de utilização por paciente, tipo
de tratamento que utiliza mais insumo de determinado tipo, e etc.

1.2 Funções principais do produto de software

As principais funções empregadas pelo software abrangem os tópicos a seguir:

A. Obter informações dos pacientes internados

Utilizando o Sistema AGHU para obter os dados dos pacientes internados. Eliminando o
retrabalho de digitar novamente as informações pessoais dos pacientes para posterior
acompanhamento. Uma vez que o mesmo deu entrada no hospital, os dados de prontuário
ficam armazenados;

B. Manter informações do acompanhamento nutricional

Manter informações sobre o paciente, tais como, triagem, avaliações, dados dietéticos, uso de
suplementos e tolerâncias;

C. Manter cadastro de insumos (Suplementos e Dietas)

Manter informações da quantidade de uso de suplementos, para posteriores compras dos

mesmos ou similares em licitações;

D. Prover indicadores em formato dashboard com dados estatísticos

Gerar informações estatísticas e gráficas relacionadas aos dados de acompanhamento dos

pacientes;

A seguir, para facilitar na compreensão das funcionalidades, temos um Diagrama de Caso de

Uso, na Figura 1, e um Diagrama de Classes de Domínio do Sistema, na Figura 2.

2
 Figura 1​ - Diagrama de caso de uso

A figura apresenta o diagrama de caso de uso, com as principais usabilidades e o

escopo do sistema de informação proposto para o setor de nutrição do HU.

Onde os nutricionistas serão os principais usuários do sistema e irão:

A. Realizar login

Apenas pessoal autorizado poderá utilizar o sistema. Os profissionais terão credenciais de

acesso;

B. Adicionar paciente

Com os dados, uma vez fornecidos no preenchimento do prontuário, de forma integrada, os

pacientes que estão internados nas clínicas do hospital são automaticamente disponibilizados
ao Sistema de Informação Nutricional;

C. Acompanhar paciente

De forma integrada, os prontuários cadastrados na base de dados do hospital auxiliaram o

procedimento de identificação de cada paciente internado;

D. Gerenciar Insumos

3
Manter dados de Suplementos e Dietas disponíveis em estoque;

E. Gerar Indicadores

Utilizar as informações coletadas no Sistema de Informação Nutricional, tais como, triagem,

insumos e outros, para produzir indicadores e gráficos que serão apresentados em relatórios e
dashboards;
Figura 2​ - Diagrama de classes de domínio

A figura acima, apresenta o diagrama de classes de domínio do sistema contendo as

classes principais e seus respectivos atributos e métodos. Ainda descreve as associações
existente entre as classes. Este tipo de diagrama é fundamental e serve de base para todo o
desenvolvimento do sistema.

1.3 Requisitos comportamentais ou de performance

A seguir serão apresentados alguns dos requisitos para um bom funcionamento do software
em termos de desempenho, segurança, qualidade, usabilidade, e etc.

a) Segurança

O acesso ao sistema deve ser por meio de login de usuário e senha (pessoais e
intransferíveis) autenticados pelo sistema de autenticação <<Sistema AD>> do HU/UFS.

4
 b) Usabilidade

Utilizando-se das heurísticas de Nielsen (NIELSEN, 2007), o sistema deve apresentar

uma interface intuitiva, que facilite a navegação.

c) Hardware e Software

O sistema deve funcionar na rede intranet do HU/UFS, possibilitando que as

nutricionistas o utilizem nas diversas enfermarias do hospital

1.4 Gestão e Restrições Técnicas

A seguir algumas restrições técnicas que podem impactar no desenvolvimento, suporte e

manutenção não só do projeto como da aplicação de software desenvolvida:

a) Linguagem

O sistema deve adotar a Linguagem Java para o desenvolvimento, por ser a linguagem
de programação padrão adotada pelo Setor de Gestão de Processos e Tecnologia da
Informação do HU/UFS.

b) Banco de Dados

O SGBD a ser utilizado será o PostgreSQL, por também ser o padrão utilizado pelo
Setor de Gestão de Processos e Tecnologia da Informação do HU/UFS.

5
2 - ESTIMAÇÕES DO PROJETO
Esta seção fornece as estimações de esforço e tempo por cada membro da equipe. As
estimativas foram calculadas baseadas nas métricas da obra (Object-oriented software metrics,
de Lorenz & Kidd, 1994).

2.1 Dados históricos utilizados para as estimações

A equipe não dispõe de informações anteriores que forneça valores para uma estimação
baseada em dados históricos.

2.2 Técnicas de estimação e resultados

Este projeto utilizará a técnica orientada a classes de (Lorenz & Kidd, 1994). E segundo o
mesmo, o tamanho de um projeto é medido a partir da métrica Class Size (CS). Conforme
explicação da métrica detalhada a seguir.

2.2.1 Técnica de estimação

Essa métrica leva em conta o número total de operações e número de atributos que são
encapsulados dentro de uma classe. Grandes valores de Class Size podem significar
que uma classe possui grande responsabilidade, o que pode ocasionar baixa
reusabilidade, alta complexidade de implementação, manutenção e testes
(PRESSMAN, 2011).

A técnica de métrica de (Lorenz & Kidd, 1994) é caracterizada pelos seguintes passos:

1. Definir o número de classes ​Chave​.

2. Encontrar o número de classes de ​Suporte​, para isso temos que classificar o tipo de
Interface do Produto​ e desenvolver um ​Multiplicador​ para as ​Classes de Suporte.​

Quadro 1 - Multiplicador por tipo de interface do projeto

Interface Multiplicador

NG - Não Gráfica 2

BT - Baseada em Texto 2,25

GUI - Simples (Graphical User Interface) 2,5

GUI - Complexa (Graphical User Interface) 3

Fonte: (Lorenz & Kidd, 1994)

3. Multiplicar a quantidade de Classes Chave pelo Multiplicador para obter uma

estimação do número de Classes de Suporte.
4. Em seguida, calcular a quantidade total de Classes, somando o número de Classes
Chave com o número de Classes de Suporte.
5. Multiplicar a quantidade total de Classes (Chave + Suporte) pelo número médio de
unidades de trabalho (Dias/Pessoas) por classe.
6. Determinar a quantidade de esforço estimada.

6
 7. Calcular tempo previsto para a elaboração do projeto.

2.3 Resultados

Aplicando os passos descrito no Seção 2.2, obtivemos o Quadro 2, que é mostrado a seguir
com o resultado de esforço estimado.
Visto que este é o primeiro projeto da equipe, foi estipulado como número médio de unidades
de trabalho de 18 Dias/Pessoa. Após cálculo dos pesos referente ao tipo de classe x a
quantidade, conforme Quadro 1. Chegamos a um total de 24,5 classes projetadas estipuladas,
conforme multiplicador apresentado no item 4 do Quadro 2. Enfim chegamos ao total de 441
dias de esforço estimado. O esforço estimado foi dividido igualmente entre os 5 membros da
equipe, resultando em 88,2 dias de trabalho por membro da equipe.

Quadro 2 - Resultado da técnica de Lorenz & Kidd

Resultado

1 Número de ​Classes Chave: 7

2 Projeto de natureza classificada como ​GUI

Simples​, conforme Quadro 2. 2,5
Sendo assim, o multiplicador definido é:

3 Número de ​Classes de Suporte​:

(7 x 2,5) = ​17,5
(Classes Chave x Multiplicador)

4 Total de Classes:
(7 + 17,5) = ​24,5
(Classes Chave + Classes de Suporte)

5 Médio de Unidades de Trabalho

18 Dias/Pessoas
Dias/Pessoa​ por Classe

6 Quantidade de Esforço Estimado:

(18 x 24,5) = ​441 dias
(Qtd de Classes x Unidade de Trabalho)

7 Dias de Trabalho da Equipe:

(441 / 5) = ​88,2 dias/membro
(Esforço Estimado / Qtd Pessoas Equipe)
Fonte: Autores

7
3 - ANÁLISE E GESTÃO DE RISCOS
Esta seção abrange os riscos do projeto, que ameaçam o plano de projeto, podendo atrasar o
cronograma e aumentar custos.

3.1 Riscos do projeto

Foram identificados e classificados os seguintes riscos apresentados no Quadro 3, agrupados

em Riscos Genéricos, que são ameaças gerais em todo projeto de software, e Riscos
Específicos, relacionados exclusivamente ao projeto e sua tecnologia descrito neste
documento:

Quadro 3 - Riscos Identificados

Riscos Genéricos Riscos Específicos

Deadline de entrega, Desempenho devido tamanho do banco,

Pessoas trabalhando em meio tempo,
Quantidade e qualidade da
documentação que deve ser entregue,
O cliente não ter uma idéia formada dos
requisitos,
Dificuldade em utilizar o software.
Restrições governamentais,
Falta de interoperabilidade,
Risco em relação a tecnologia: novos
métodos,
Falta de manutenibilidade pela equipe de
cliente

3.2 Tabela de riscos

Os riscos foram classificados de forma decrescente em primário pelo grau de impacto e,em
secundário, a chance de ocorrência. A passagem do último risco de impacto crítico para o
primeiro risco de impacto marginal é denominada ponto de corte, como demonstrado no
Quadro 4.
Quadro 4 - Riscos classificados e ordenados

Risco Chance de Ocorrência Impacto

Deadline de entrega curto 50% Catastrófico

Pessoas trabalhando em
meio tempo da jornada de 90% Crítico
trabalho

Quantidade e qualidade da
documentação que deve 50% Crítico
ser entregue

O cliente não ter uma

idéia formada dos 15% Crítico
requisitos

O tamanho do banco de 50% Marginal

8
 dados pode influenciar
negativamente no
desempenho

Restrições 10%
Marginal
governamentais

Dificuldade em utilizar o
8% Marginal
software

Risco de falta de
15% Desprezível
interoperabilidade

Risco em relação a
tecnologia: novos 10% Desprezível
métodos

Falta de manutenibilidade
8% Desprezível
pela equipe de cliente

3.3 Planos de Redução e Gestão do Risco

Para cada risco identificado e classificado no Quadro 4, é construído um plano que explana as
estratégias para redução do risco em questão e as ações de contingência na ocorrência desse
risco, demonstrado nas tabelas abaixo:

Tabela 1 - Plano Deadline de entrega curto

Risco: Deadline de Probabilidade: 50% Impacto: Catastrófico

entrega curto

Estratégia de redução:
Estipular prazos com pequenas entregas constantes para monitorar o andamento do
projeto.

Plano de contingência:
Entrega de uma versão mais estável,ou seja,a última versão com funcionalidades já
testadas e tentar negociar um novo prazo.

Tabela 2 - Plano Pessoas trabalhando em meio tempo da jornada de trabalho

Risco: Pessoas
trabalhando em meio
Probabilidade: 90% Impacto: Crítico
tempo da jornada de
trabalho

9
 Estratégia de redução:
Planejar tarefas abstraindo-as a nível atômico, indivisível e com boa comunicação
para obter o real desempenho do projeto

Plano de contingência:
Com base nas tarefas desenvolvidas pela equipe calcular a média de horas por dia
disponível pela equipe e atribuir como dia trabalhado este horário médio.

Tabela 3 - Plano Quantidade e qualidade da documentação que deve ser entregue

Risco: Quantidade e
qualidade da
Probabilidade: 50% Impacto: Crítico
documentação que deve
ser entregue

Estratégia de redução:
Documentação feita de forma incremental, e em determinada alteração ser
frequentemente corrigida

Plano de contingência:
Recuperar as informações que estão ausentes na documentação

Tabela 4 - Plano O cliente não ter uma idéia formada dos requisitos

Risco: O cliente não ter

uma idéia formada dos Probabilidade: 15% Impacto: Crítico
requisitos

Estratégia de redução:
Fazer uso de entrevistas, manter um contato constante com o cliente.

Plano de contingência: Utilizar de outra abordagem no levantamento de requisitos

ao qual o cliente esteja mais imersivo, como prototipação incremental

Tabela 5 - Plano O tamanho do banco de dados pode influenciar negativamente no

desempenho

Risco: O tamanho do
banco de dados pode
Probabilidade: 50% Impacto: Marginal
influenciar negativamente
no desempenho

10
Estratégia de redução:
Elaborar as consultas de uma forma que o desempenho seja mais eficiente

Plano de contingência:
Utilizar de outros artifícios como tabelas temporárias, escalonar o banco

Tabela 6 - Plano Restrições governamentais

Risco: Restrições
Probabilidade: 10% Impacto: Marginal
governamentais

Estratégia de redução:
Verificar previamente os requisitos impostos por leis nacionais referente aos dados.

Plano de contingência:
Parar o projeto e avaliar com o setor jurídico as mudanças que deverão ser
realizadas

Tabela 7 - Plano Dificuldade em utilizar o software

Risco: Dificuldade em
Probabilidade: 8% Impacto: Marginal
utilizar o software

Estratégia de redução:
Prover acesso à tutoriais e guias rápidos dentro da interface do sistema

Plano de contingência:
Promover treinamentos in loco para os usuários

Tabela 8 - Plano Risco de falta de interoperabilidade

Risco: Risco de falta de

Probabilidade: 15% Impacto: Desprezível
interoperabilidade

Estratégia de redução:
Analisar os sistemas legados e seus padrões de comunicação e tecnologia

Plano de contingência:
Criar mecanismo de comunicação entre sistemas: web service

11
 Tabela 9 - Plano Risco em relação a tecnologia:novos métodos

Risco: Risco em relação a

Probabilidade: 10% Impacto: Desprezível
tecnologia:novos métodos

Estratégia de redução:
Análise prévia do ambiente de produção, suas configurações e limitações

Plano de contingência:
Adotar a tecnologia predominante no ambiente de produção

Tabela 10 - Plano Falta de manutenibilidade pela equipe de cliente

Risco: Falta de
manutenibilidade pela Probabilidade: 8% Impacto: Desprezível
equipe de cliente

Estratégia de redução:
Entrega de documentação completa e revisada

Plano de contingência:
Estabelecer contato com a equipe do cliente para sanar dúvidas, opção de reporte de
bugs dentro do próprio sistema

12
4 - PLANEAMENTO TEMPORAL
Nesta seção apresentamos as tarefas e as suas dependências.

Quadro 5 - Estimativas de dias de trabalho por fase do projeto

Etapa Projeto (%) Cálculo Dias de Trabalho

Planejamento 3% 88,2 x 3% 2,65

Analise 40% 88,2 x 40% 35,28

Codificação 20% 88,2 x 20% 17,64

Testes 37% 88,2 x 37% 32,63

Fonte: Autores

4.1 Recursos do projeto

Aqui estão listados os recursos humanos, de software e hardware, ferramentas de apoio e

outros recursos necessários:

4.1.2 Recursos humanos

A equipe deste projeto é composta por Artur Frederico, Crisnaldo Carvalho, Everton Portela,
Felipe Meneses, Vinicius de Oliveira Sobral, graduandos do curso de Sistemas de Informação
pela Universidade Federal de Sergipe (UFS).

4.1.2 Recursos de software

A. IDE para desenvolvimento do Sistema: NetBeans

B. Sistema de Gestão de Banco de Dados: PostgreSQL
C. Ambiente de Modelagem dos diagramas: AstahUML
D. Ferramenta de Comunicação da Equipe: WhatsApp Messenger
E. Ferramenta para controle de versão: Git
F. Ferramenta de Gerenciamento de Projetos: OpenProject

4.2 Conjunto de Tarefas do Projeto

O Modelo de Processo utilizado compõe-se das fases de Requisitos, Projeto, Implementação,

Verificação e Implantação. As tarefas do Projeto são mostradas abaixo:

Tabela 11 - Tarefas do Projeto

Tarefa Situação Responsável

Requisitos Fechado

Reunião inicial com nutricionista Fechado Everton Santos

13
Levantamento dos requisitos Fechado Everton Santos

Desenvolvimento Casos de Uso Fechado Everton Santos

Reunião 1 Requisitos Fechado Everton Santos

Reunião 2 Requisitos Fechado Everton Santos

Reunião 1 Casos de Uso Fechado Everton Santos

Reunião 2 Casos de Uso Fechado Everton Santos

Construção Modelo de Análise Fechado Everton Santos

Reunião 1 Modelo de Análise Fechado Everton Santos

Reunião 2 Modelo de Análise Fechado Everton Santos

Projeto Fechado

Definição da Arquitetura Fechado Everton Santos

Diagrama de Classes de Projeto Fechado Everton Santos

Diagrama de Componentes Fechado Everton Santos

Diagrama de Sequência Fechado Everton Santos

Reunião 1 - Arquitetura Fechado Everton Santos

Reunião 2 - Arquitetura Fechado Everton Santos

Reunião 1 - Classes de Projeto Fechado Everton Santos

Reunião 2 - Classes de Projeto Fechado Everton Santos

Reunião 1 - Componentes Fechado Everton Santos

Reunião 2 - Componentes Fechado Everton Santos

Reunião 1 - Sequência Fechado Everton Santos

Reunião 2 - Sequência Fechado Everton Santos

Codificação Fechado

Banco de dados Fechado Crisnaldo Santos

Classes auxiliares Fechado Crisnaldo Santos

14
 Classes de negócio Fechado Artur Santos

Interface de Usuário Fechado Artur Santos

Testes Fechado

Teste de Configuração Fechado Vinicius Sobral

Teste de Segurança Fechado Vinicius Sobral

Teste Funcional Fechado Vinicius Sobral

Teste de Performance Fechado Vinicius Sobral

Teste de Usabilidade Fechado Vinicius Sobral

Criação do Manual do Usuário Fechado Everton Santos

Reuniões Quinzenais Fechado

Reunião - Semana 1 Fechado Felipe Meneses

Reunião - Semana 3 Fechado Felipe Meneses

Reunião - Semana 5 Fechado Felipe Meneses

Reunião - Semana 7 Fechado Felipe Meneses

Reunião - Semana 9 Fechado Felipe Meneses

Reunião - Semana 11 Fechado Felipe Meneses

Reunião - Semana 13 Fechado Felipe Meneses

Reunião - Semana 15 Fechado Felipe Meneses

Reunião - Semana 17 Fechado Felipe Meneses

Reunião - Semana 19 Fechado Felipe Meneses

Fonte: Autores

4.2 Diagrama de Gantt

A figura 3 abaixo mostra o Diagrama de Gantt com as atividades do projeto e seus prazos.

15
Figura 3​ - Diagrama de Gantt

16
5 - ORGANIZAÇÃO DO PESSOAL
A seguir estão descritos a composição da equipe, algumas ferramentas de comunicação
utilizadas durante o projeto e também sobre a ferramenta EDU-BLOG abordada na
metodologia na disciplina de Gerência de Projeto.
5.1 Estrutura da equipe

A equipe é composta por cinco pessoas: Artur Frederico, Crisnaldo Carvalho, Everton
Portela, Felipe Meneses, Vinicius de Oliveira. No quadro, a seguir, é mostrado o papel
de cada integrante da equipe.

Integrante Papel Descrição

Planejar e controlar a
execução do projeto;
Definir papéis e funções
da equipe; Alocar
Felipe Meneses Gerente de Projetos
recursos e ajuste de
prioridades; Acompanhar
as atividades dos
envolvidos no projeto.

Mapear processos,
modelar dados, levantar
requisitos e regras de
Everton Portela Analista de Sistemas
negócio, elaborar
diagramas. Analisar e
desenvolver o sistema.

Implementar o produto,
Artur Frederico, codificar ou realizar
Desenvolvedores
Crisnaldo Carvalho manutenções nas rotinas
do sistema.

Elaborar e revisar os
manuais de qualidade,
procedimentos e
Vinicius de Oliveira Analista de Qualidade instruções do trabalho
visando à padronização
dos processos de
qualidade.

5.2 Mecanismos de comunicação

Os mecanismos para a comunicação neste projeto foram:

17
 A. Trello: ferramenta que permite o gerenciamento de projetos em lista, capaz de se
adequar às necessidades do usuário, que auxilia na divisão e organização das tarefas;
B. Whatsapp: aplicativo de mensagens instantânea que permite a comunicação de forma
ágil entre os componentes da equipe;
C. Google Drive: ferramenta colaborativa que facilita a produção de documentos, bem
como a troca destes.

5.3 Uso do Edu-blog como ferramenta de apoio

O Edu-blog proporcionou uma oportunidade de pesquisarmos mais e nos aprofundarmos

sobre o tema que nos foi confiado: Plataformas em Nuvem. Tanto aprendemos mais, como
levamos aos nossos colegas novos insights sobre mercado, tecnologias de nuvem, tendências
para os próximos anos e claro processos de gerenciamento de projetos.

Sem dúvida, uma forma diferente de agregar conhecimento e valor a nossa formação.

18
6 - PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
Visando a qualidade e a melhoria do nosso processo de desenvolvimento, percebemos alguns
pontos, que fazem jus de serem observados a fim de serem precavidos.

Reuniões periódicas para a equipe, possibilitando que o processo de desenvolvimento seja

transparente para todos os participantes envolvidos. Qualquer membro do time pode ser capaz
de dialogar com o cliente, se, de alguma forma assim ocorra. Além de atualizar a equipe sobre
os principais problemas encontrados, podendo todos interagir para tratar de uma resolução.
Caracterizando uma equipe com alta capacidade e eficiência.

Realizar testes ao longo do processo de desenvolvimento, com o intuito de entregar o sistema

com bom funcionamento, com o menor número possível de erros e comportamentos
inesperados.

Abordagem mais exigente com a documentação do sistema, para facilitar o entendimento

associações futuras no time do projeto.

A constante participação dos clientes, nas validações de cada etapa, desde o levantamento de
requisitos até a fase de testes. Sempre acompanhando, garantindo que o produto esteja
atendendo as expectativas do cliente.

19
7 - REFERÊNCIAS BIBLIOGRÁFICAS
LORENS, Mark. KIDD, Jeff. Object-oriented software metrics. Pearson Prentice Hall, 1994.

NASCIMENTO, Rogério P. C. do. Practice 4 :: Gestão de Projetos de SW OO :: Métricas,

Estimação e Planificações. Disponível em:
<https://www.slideshare.net/rogerio/practice-4-gesto-de-projetos-de-sw-oo-mtricas-estimao-e
-planificaes> 14 de Fevereiro de 2019

NIELSEN, Jakob. HORANGER, Hoa. Usabilidade na web. Rio de Janeiro. Elsevier, 2007.

PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. 7. ed. - Porto

Alegre. AMGH, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. - São Paulo. Pearson Prentice Hall,
2011.

20