plano_de_projeto_controlart_final

473 visualizações

Publicada em

Publicada em: Educação, Negócios, Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
473
No SlideShare
0
A partir de incorporações
0
Número de incorporações
189
Ações
Compartilhamentos
0
Downloads
9
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

plano_de_projeto_controlart_final

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21 Figura 5 – Diagrama de Gantt.
  22. 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

×