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
da
Universidade
Federal de Sergipe.
São Cristóvão - Sergipe, Brasil
2014
2

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 .................................................................. 7
2. ESTIMATIVAS DO PROJETO .................................................................... 7
2.1 Dados históricos utilizados para as estimações ..................................... 7
2.2 Técnicas de estimação e resultados ...................................................... 7
2.2.1 Técnica de estimação...................................................................... 8
2.3 Resultados ............................................................................................. 9
2.4 Recursos do projeto ............................................................................. 10
2.4.1 Recursos humanos........................................................................ 10
2.4.2 Recursos de software .................................................................... 11
2.4.3 Recursos de hardware .................................................................. 12
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 ............................................................. 22
5.1 Estrutura da equipe .............................................................................. 22
5.2 Mecanismos de comunicação .............................................................. 22
5.3 Uso do Edu-blog como ferramenta de apoio........................................ 22
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE ....................................................... 22
3

4. 1. INTRODUÇÃO
O produto de software descrito abaixo foi planejado e implementado no
decorrer das disciplinas Engenharia de Software I e II do curso de Sistemas de
Informação - Bacharelado da Universidade Federal de Sergipe.
Esse processo teve duração de, aproximadamente, nove meses e foi dividido
em dois intervalos principais: O primeiro, com duração de quatro meses, foi
direcionado a execução de atividades voltadas às fases de planejamento e análise e
definição de requisitos; o segundo, com duração de cinco meses, foi direcionado a
execução de atividades voltadas às fases de codificação e testes. Essas atividades
originaram a documentação do produto de software acompanhada de sua primeira
versão completa e executável.
Como resultado de última análise, as estimativas descritas neste documento
não coincidiram com o período anterior de execução devido aos seguintes fatores:
1. Equipe composta por poucos membros;
2. Longo intervalo entre a execução das atividades;
3. Não cumprimento de determinadas medidas estabelecidas na documentaçã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:
4

5. 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.
5

6. 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 similaridade 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

7. 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á listada a técnica utilizada nas estimativas:
1. Métrica de Lorenz & Kidd - Calcular o esforço por pessoa necessário para a
construção do projeto. Utiliza o diagrama de classes de domínio como fonte
de informações.
7

8. 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
Interface não gráfica
Baseada em texto
Multiplicador
2
2,25
8

9. 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, Lorenz
& Kidd sugerem de quinze a vinte 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 Lorenz & Kidd);
20 dias
9

10. 6. Quantidade total de dias que uma pessoa gastaria para construir todo o
sistema;
20 (item 5) * 28 (item 4) = 560 dias
7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.
560 (item 6) / 4 (quantidade de integrantes) = 140 dias
Sendo assim, de acordo com a métrica de Lorenz & Kidd, o tempo necessário
para a construção do projeto deve ser de, aproximadamente, cento e quarenta dias.
Levando em consideração a quantidade de dias úteis no mês (geralmente vinte e
dois), o projeto se estenderá por, aproximadamente, sete 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
A metodologia adotada para o gerenciamento do projeto foi o SCRUM. Os
Sprints das Tabelas 2, 3 e 4 definem a estrutura de organização e execução do
conjunto de tarefas classificados de acordo com uma disposição hierárquica das
funcionalidades a serem desenvolvidas e das datas disponíveis para a sua
construção, listadas na Tabela 8. O modelo adotado nesses Sprints prioriza, para
fins de aprendizado, a rotatividade dos membros nas funções que estão disponíveis.
Sprint 1
Funcionalidades: Manter tipos de pessoas; Manter pessoas; Manter usuários.
Período: 20/03/2013 à 30/04/2013.
Duração: 30 dias.
Scrum Master: Onezino Gabriel.
Desenvolvedor 1: Gustavo Souza.
Desenvolvedor 2: Kevin Filipe.
Testador: Tiago Oliveira.
Tabela 2 - Sprint 1
10

11. Sprint 2
Funcionalidades: Manter acervos; Manter classificação de peças.
Período: 01/05/2013 à 10/06/2013.
Duração: 29 dias.
Scrum Master: Gustavo Souza.
Desenvolvedor 1: Onezino Gabriel.
Desenvolvedor 2: Tiago Oliveira.
Testador: Kevin Filipe.
Tabela 3 - Sprint 2
Sprint 3
Funcionalidades: Manter peças; Registrar transação.
Período: 11/06/2013 à 19/07/2013.
Duração: 29 dias.
Scrum Master: Tiago Oliveira.
Desenvolvedor 1: Kevin Filipe.
Desenvolvedor 2: Gustavo Souza.
Testador: Onezino Gabriel.
Tabela 4 - Sprint 3
2.4.2 Recursos de software
Segue na Tabela 5 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
11

12. desenvolvido.
PostgreSQL 9
Banco de
software.
dados
utilizado
pelo
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 na codificação do
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.
para
Tabela 5 - 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 foram 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
Ferramentas
de
Projeto
testes
Técnico
Negócio
Comum
Especial
X
12

13. oferecem pouco suporte à
tecnologia
usada
na
codificação.
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.
X
X
X
X
Equipe
com
pouco
conhecimento
acerca
da
tecnologia
usada
na
codificação.
Necessidade constante de
aprimoramentos no software.
Dificuldade para solucionar
problemas
encontrados
durante a codificação.
X
X
X
X
X
X
X
Tabela 6 - Riscos x Classificação
3.2 Tabela de riscos
Na Tabela 7 foi atribuída a cada um dos riscos uma probabilidade que
determina o grau da 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
90%
Catastrófico
13

14. codificação.
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
Necessidade constante de
aprimoramentos no software.
50%
Moderado
Dificuldade para solucionar
problemas
encontrados
durante a codificação.
20%
Marginal
a
Tabela 7 - Análise Risco x Probabilidade x Impacto
3.3 Redução e gestão do risco
Os quadros a seguir, de 1 a 10 apresentam estratégias para a redução e/ou
gestão dos riscos identificados 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.
14

15. Estratégia de redução: Minimizar o uso destas ferramentas através da
implantação de outros processos de testes, buscando outras soluções.
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 à quantidade de informações que ele deve gerenciar, seu
tamanho e complexidade crescem demasiadamente, prejudicando os prazos de
entrega.
Estratégia de redução: Negociar entrega com o cliente, sempre mantendo o
escopo e planejamento definidos.
Plano de contingência: Negociar os prazos com os stakeholders revertendo os
prazos definidos incorretamente.
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: Buscar 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 possam opinar a respeito do
15

16. 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: O prazo para construção do projeto é relativamente curto.
Estratégia de redução: Divisão pertinente das atividades de acordo 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 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
16

17. 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: Buscar componentes reutilizáveis.
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.
17

18. 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 à complexidade que envolve a tecnologia usada na
codificação, os erros podem levar tempo considerável para serem resolvidos.
Estratégia de redução: Investir no treinamento da equipe para melhorar o
conhecimento e maturidade da mesma.
Plano de contingência: Planejar a solução das pendências em equipe, ao invés
de individualmente.
18

19. 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. A
mensuração do tempo para construção do projeto definido no item 2.3 foi utilizado
para dividir as fases do projeto. As fases tiveram a divisão do tempo conforme a
Tabela 8.
Fase
Porcentagem
Duração (dias)
Planejamento
3%
5
Análise e Projeto
40%
56
Codificação
20%
28
Testes
37%
51
Tabela 8 - Fases do projeto
4.1 Conjunto de Tarefas do Projeto
A definição do conjunto de tarefas do projeto utilizou o processo iterativo
incremental. O processo incremental faz entrega parciais do software facilitando
identificar antecipadamente mudanças, novas funcionalidades e erros.
O SCRUM define a divisão das funcionalidades em tarefas menores
executáveis pelos desenvolvedores. A Tabela 9 relaciona as tarefas com sua fase.
Fase
Tarefas
Planejamento
Definição de escopo;
Funcionalidades e restrições;
Documento de concepção.
Análise e Projeto
Especificação de Requisitos;
Especificação de Requisitos não funcionais;
Especificação dos diagramas de análise;
Documento de Analise;
19

20. Definição da arquitetura de Projeto;
Especificação dos diagramas de projeto;
Documento de Projeto;
Especificação e detalhamento de requisito.
Codificação
Desenvolvimento da interface gráfica;
Desenvolvimento da regra de negócio.
Teste
Teste e validação de documentação;
Teste e validação de software.
Tabela 9 - Distribuição das tarefas em fases
Durante há analise foram executados testes para validação dos documentos,
da fase de Teste. E a cada Sprint é realizado tarefas de especificação e
detalhamento de requisitos que pertencem a fase de Análise e Projeto.
4.2 Diagrama de Gantt
O diagrama de Gantt permite-nos visualizar de forma gráfica o avanço e
planejamento das diferentes etapas de um projeto. A Figura 5 mostra as tarefas
planejadas do projeto em forma de diagrama de Gantt.
20

21. 21
Figura 5 – Diagrama de Gantt.

22. 5.0 ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da equipe
A cada Sprint, uma pessoa diferente assumiu o papel de Scrum Master e a
responsabilidade dos testes. Os testes foram executados pelo próprio
desenvolvedor de cada tarefa e também pela pessoa responsável por aquele Sprint.
5.2 Mecanismos de comunicação
Os mecanismos de comunicação utilizados foram:
● 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 permite que o conhecimento adquirido durante o projeto seja
disseminado, tanto entre os integrantes do projeto quanto para outras pessoas. Por
se tratar de uma compilação das informações pesquisadas, torna-se uma maneira
de recuperá-las após o fim do projeto.
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR
QUALIDADE DO PRODUTO DE SOFTWARE
E
CONTROLAR
A
● Documentação - A cada etapa do projeto foram produzidos documentos.
Estes foram importantes na elaboração dos testes. Também serviram para
guiar o andamento do projeto. Deverão ser atualizados quando houver
mudanças;
● Testes - Foram elaborados com o auxílio da documentação e executados
durante todas as fases do projeto;
● Controle de versão - Ferramenta que permite o rastreamento de alterações,
identificando os seus autores. Ajudam 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.
22