UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INF...
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INF...
Sumário

1. INTRODUÇÃO ................................................................................................. 4...
1. INTRODUÇÃO
1.1 Âmbito do projeto
Um estudo realizado por alunos do curso de Sistemas de Informação da
Universidade Fede...
Figura 2 - Situação de posição do produto

1.2 Principais funções do produto de software
O diagrama abaixo apresenta as pr...
1.3 Requisitos comportamentais ou de performance
Para atender seus usuários com eficiência e qualidade, o sistema ControlA...
2.2 Técnicas de estimação e resultados
Abaixo serão listadas as técnicas utilizadas para as estimativas:
1. Métrica de Lor...
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 passo...
de domínio;
8 classes-chave
2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);
GUI
3. Número de ...
Fase

Porcentagem

Duração

Planejamento

10%

10 dias

Análise e Projeto

42%

45 dias

Codificação

28%

30 dias

Testes...
2.4.2 Recursos de software
Segue abaixo a lista de recursos de software utilizados no projeto:
Software

Descrição

Java D...
3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão analisados os riscos potenciais que são prejudiciais para o
andamento do pr...
aprimoramentos no software.
Dificuldade para solucionar
problemas
encontrados
durante a codificação.

X

X

Tabela 5 - Ris...
Necessidade constante de
aprimoramentos no software.

50%

Moderado

Dificuldade para solucionar
problemas
encontrados
dur...
Estratégia de redução: Fazer uma análise apurada do escopo e do planejamento
definidos para o projeto.
Plano de contingênc...
Plano de contingência: Seguir a risca as informações e prazos detalhados na
especificação do projeto.
Responsável: Onezino...
Responsável: Tiago Oliveira Santos.
Status: Em andamento.
Quadro 6 - Análise do risco 6

7 - Equipe pequena.
Probabilidade...
8 - Equipe com pouco conhecimento acerca da tecnologia usada na
codificação.
Probabilidade: 60%.
Impacto: Moderado.
Descri...
10 - Dificuldade para solucionar problemas encontrados durante a codificação.
Probabilidade: 20%.
Impacto: Marginal.
Descr...
tabelas do sistema

- Desenvolvimento da regra de negócio e persistência das
entidades de usuário e segurança
- Gerar carg...
5.0 ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da equipe
●
●
●
●

Gerente de Projeto: Onezino Gabriel Moreira
Analista de Sistem...
Próximos SlideShares
Carregando em…5
×

plano_de_projeto_controlart_rascunho

459 visualizações

Publicada em

Publicada em: Educação
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

plano_de_projeto_controlart_rascunho

  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 Universidade Federal de Sergipe. São Cristóvão - Sergipe, Brasil 2014 da
  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 ....................................................................... 6 2. ESTIMATIVAS DO PROJETO.......................................................................... 6 2.1 Dados históricos utilizados para as estimações .......................................... 6 2.2 Técnicas de estimação e resultados ........................................................... 7 2.2.1 Técnica de estimação........................................................................... 8 2.3 Resultados .................................................................................................. 8 2.4 Recursos do projeto .................................................................................... 9 2.4.1 Recursos humanos............................................................................... 9 2.4.2 Recursos de software ......................................................................... 11 2.4.3 Recursos de hardware ....................................................................... 11 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 ................................................................... 21 5.1 Estrutura da equipe ................................................................................... 21 5.2 Mecanismos de comunicação ................................................................... 21 5.3 Uso do Edu-blog como ferramenta de apoio............................................. 21 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ............................................................. 21
  4. 4. 1. INTRODUÇÃ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: Figura 1 - Descrição do problema
  5. 5. 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. Figura 3 - Diagrama de casos de uso
  6. 6. 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 similaridades 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. 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.
  7. 7. 2.2 Técnicas de estimação e resultados Abaixo serão listadas as técnicas utilizadas para as estimativas: 1. Métrica de Lorens & Kidd - Calcular o tempo total de duração do projeto. Utiliza o diagrama de classes de domínio como fonte de informações. Figura 4 - Diagrama de classes de domínio
  8. 8. 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 Multiplicador Interface não gráfica 2 Baseada em texto 2,25 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, Lorens & Kidd sugerem de 15 a 20 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
  9. 9. 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 Lorens & Kidd); 15 dias 6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema; 15 (item 5) * 28 (item 4) = 420 dias 7. Quantidade total de dias que a equipe gastaria para construir todo o sistema. 420 (item 6) / 4 (quantidade de integrantes) = 105 dias. Sendo assim, de acordo com a métrica de Lorens & Kidd, o tempo necessário para a construção do projeto deve ser de, aproximadamente, 105 dias. Levando em consideração a quantidade de dias úteis no mês (geralmente 22), o projeto se estenderá por, aproximadamente, 5 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 Para facilitar o trabalho realizado pela equipe, a duração total do projeto, calculada na seção 2.3, foi dividida de acordo com as seguintes fases:
  10. 10. Fase Porcentagem Duração Planejamento 10% 10 dias Análise e Projeto 42% 45 dias Codificação 28% 30 dias Testes 20% 20 dias Tabela 2 - Fases do projeto Para gerenciar o projeto de software utilizamos a metodologia SCRUM. As funcionalidades após serem definidas foram especificadas e divididas em tarefas, essas tarefas, agrupadas e divididas entre os sprints. Ao final de cada sprint entregaremos para os usuários uma parte funcional do software. A cada sprint fazemos o planejamento, codificação e teste do projeto de software. A cada sprint faremos o rodizio de funcionários nas posições de Scrum Master e desenvolvedores, os testes serão feito pelos desenvolvedores. Cada desenvolvedor será responsável pelos testes das implementações das atividade de outro desenvolvedor. A tabela 3 mostra a divisão das funcionalidades dos sprints e a indicação do Scrum Master do sprint. Funcionalidades Início Término Scrum Master Manter tipos de pessoas; Manter pessoas; Manter usuários. 05/05/2014 30/05/2014 Onezino Moreira Manter classificação; Manter acervos. 02/06/2014 20/06/2014 Gustavo Souza Manter peças; Registrar transação. 23/06/2014 11/07/2014 Kevin Filipe Tabela 3 - Definição dos Sprints
  11. 11. 2.4.2 Recursos de software Segue abaixo 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 desenvolvido. PostgreSQL 9 Banco de software. 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 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. dados na utilizado codificação pelo do para Tabela 4 - 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.
  12. 12. 3 ANÁLISE E GESTÃO DE RISCOS Nesta seção serão analisados os riscos potenciais que são 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 Projeto Ferramentas de testes oferecem pouco suporte à tecnologia usada na codificação. Técnico Negócio Comum Especial X 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. constante X X X Equipe com pouco conhecimento acerca da tecnologia usada na codificação. Necessidade X de X X X X X
  13. 13. aprimoramentos no software. Dificuldade para solucionar problemas encontrados durante a codificação. X X Tabela 5 - Riscos x Classificação 3.2 Tabela de riscos A tabela abaixo atribui a cada um dos riscos uma probabilidade, que determina o grau de 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 codificação. 90% Catastrófico 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 a
  14. 14. Necessidade constante de aprimoramentos no software. 50% Moderado Dificuldade para solucionar problemas encontrados durante a codificação. 20% Marginal Tabela 6 - Análise Risco x Probabilidade x Impacto 3.3 Redução e gestão do risco riscos Os quadros abaixo apresentam estratégias para a redução e/ou gestão dos estudados 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. Estratégia de redução: Minimizar o uso destas ferramentas através da implantação de outros processos de testes. 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 a quantidade de informações que ele deve gerenciar, seu tamanho e complexidade crescem demasiadamente, prejudicando os prazos de entrega.
  15. 15. Estratégia de redução: Fazer uma análise apurada do escopo e do planejamento definidos para o projeto. Plano de contingência: Revisar a documentação escrita para tentar reverter, em conjunto os possíveis stackholders, os prazos definidos incorretamente. Uma explicação satisfatória sobre o ocorrido deve ser necessária. 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: Reverter a situação o mais rápido possível, procurando por 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 podem opinar a respeito do 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: Devido a grande carência do mercado, o prazo para construção do projeto é relativamente curto. Estratégia de redução: Divisão pertinente das atividades de acordo com com um planejamento preciso.
  16. 16. 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 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 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: Modificar as estruturas dos itens que precisam de reutilização para que se tornem reutilizáveis, evitando a necessidade de replicar código.
  17. 17. 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
  18. 18. 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. 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
  19. 19. 10 - Dificuldade para solucionar problemas encontrados durante a codificação. Probabilidade: 20%. Impacto: Marginal. Descrição: Devido a complexidade que envolve a tecnologia usada na codificação, os erros podem levar tempo considerável para serem resolvidos. Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a respeito da tecnologia utilizada. Plano de contingência: Planejar a solução das pendências em equipe, ao invés de individualmente. 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. O cronograma das tarefas está baseado na metodologia aplicada ao projeto e a mensuração das fases de do projeto de software conforme definimos no item 2.X.X 4.1 Conjunto de Tarefas do Projeto A definição do conjunto de tarefas de projeto utilizou o modelo iterativo incremental, como a metodologia encoraja a entrega rápida e constante para utilização do usuários fizemos marcos de liberação de módulos do produto de software para o usuário. O scrum define a divisão das funcionalidades em atividades menores que podem ser executadas pelo desenvolvedores. Na tabela abaixo está a listagem das atividades a serem executadas em cada funcionalidade. Funcionalidade Funcionalidade administração Atividades de -Desenvolvimento da tela de administração de segurança, de pessoa e usuários
  20. 20. tabelas do sistema - Desenvolvimento da regra de negócio e persistência das entidades de usuário e segurança - Gerar carga inicial dos objetos de segurança, pessoal, usuário Manutenção de - Telas de registro de acervos, de peças e de vinculação de acervos e peças peças com o acervo - Desenvolvimento das regras de negócio e persistência das entidades acervos e peças Registro transação classificação de - Tela para registro de transação, classificação de acervo e e peças - Desenvolvimento das regras de negócio e persistência das entidades de transação e classificação. Tabela 7 – Tabela de Atividades 4.2 Diagrama de Gantt O diagrama de Gantt nos permite visualizar de forma gráfica o avanço e planejamento das diferentes etapas de um projeto. A cada inicio e fim da atividade é mostrado em intervalos. O detalhamento de nossas atividades no diagrama de Gantt está disponível em: Figura 5 - Diagrama de Gantt
  21. 21. 5.0 ORGANIZAÇÃO DO PESSOAL 5.1 Estrutura da equipe ● ● ● ● Gerente de Projeto: Onezino Gabriel Moreira Analista de Sistema: Kevin Filipe Desenvolvedor: Tiago Oliveira Analista de Testes: Gustavo Souza 5.2 Mecanismos de comunicação Os mecanismos de comunicação utilizados serão: ● 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 é uma ferramenta interessante, pois permite que seja disseminado o conhecimento adquirido durante o projeto, tanto entre os integrantes do projeto quanto para outras pessoas. Também ajuda na catalogação das informações mais importantes, criando uma maneira rápida de se localizar dados importantes mesmo após o fim do projeto. 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ● Documentação - A cada etapa do projeto serão produzidos documentos. Estes serão importantes na elaboração dos testes. Também servirão para guiar o andamento do projeto. Deverão ser atualizados quando houverem mudanças; ● Testes - Serão elaborados com o auxílio da documentação e executados durante todas as fases do projeto; ● Controle de versão - Ferramenta que permitirá o rastreamento de alterações e identificarão os seus autores. Ajudam a manter os documentos atualizados; ● Reuniões diárias - Utilizando a idéia do SCRUM, reuniões diárias de curta duração serão realizadas para verificar o andamento do projeto.

×