Plano de Projeto de Software do​ Residents Control

910 visualizações

Publicada em

Plano de Projeto de Software feito durante o período 2014.2 para a matéria de Gerência de Projetos

Publicada em: Software
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
910
No SlideShare
0
A partir de incorporações
0
Número de incorporações
79
Ações
Compartilhamentos
0
Downloads
17
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Plano de Projeto de Software do​ Residents Control

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE  CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA  DEPARTAMENTO DE COMPUTAÇÃO  Gerência de Projetos 2014.2                PLANO DO PROJETO DE SOFTWARE  para produtos da Lacertae SW              GRUPO 4     Christiano Santana  Leonardo Finato  Manoela Oliveira  Ricardo Souza         São Cristóvão – Sergipe  2014 
  2. 2. Christiano Santana  Leonardo Finato  Manoela Oliveira  Ricardo Souza               PLANO DO PROJETO DE SOFTWARE  para produtos da Lacertae SW                 Trabalho apresentado ao Prof. Dr.          Rogério Patrício Chagas do        Nascimento como parte avaliativa        da disciplina Gerência de Projetos          do Curso de Graduação em          Sistemas de Informação da        Universidade Federal de Sergipe        – UFS.                    São Cristóvão – Sergipe  2015 
  3. 3. PLANO DO PROJETO DE SOFTWARE OO  para produtos da Lacertae SW      1.0 INTRODUÇÃO    Foi verificado no ​condomínio Sergipe Del Rey ​a necessidade de controlar a                        entrada e saída de visitantes, assim como o ponto dos seus funcionários. E                          então, manutenir um cadastro de moradores para auxiliar o porteiro na                      identificação do bloco e apartamento que será visitado. O ​Residents Control foi                        desenvolvido para suprir a necessidade do condomínio, tendo por objetivo                    prover maior segurança, agilidade e controle.    1.1 Âmbito do Projeto    O Residents Control apresenta uma solução satisfatória para a deficiência                    detectada no condomínio. O ​software foi desenvolvido objetivando controlar a                    entrada e saída dos visitantes, manutenir todo o cadastro de moradores,                      funcionários, usuários, visitantes e visitas. Além de prover o controle de ponto                        dos funcionários e agregar uma interface em que o usuário possa interagir com                          o sistema de acordo com suas necessidades e permissões.  Todos os funcionários realizarão a leitura biométrica e o sistema registrará a sua                          entrada e sua saída, inclusive horário de almoço. Todos os moradores serão                        registrados para controle quantitativo, todos os visitantes necessitam realizar o                    cadastro biométrico e por conseguinte, auxiliando o porteiro na identificação do                      bloco e apartamento, tanto para as visitas quanto para os moradores. O sistema                          ainda oferece relatórios estatísticos e quantitativos referentes as visitas e                    relatórios mensais de ponto dos funcionários.   
  4. 4. 1.2 Funções principais do produto de​ software  O sistema desenvolvido é composto de diversas funcionalidades. Todas                  elas com maior ou menor importância dentro do projeto, mas que juntas formam                          o software necessário para as atividades do cliente  São elas:  ● Manter Funcionários;  ● Manter Moradores;  ● Manter Usuários;  ● Manter Condômino;  ● Manter Apartamento;  ● Manter Visitantes;  ● Manter Visitas;  ● Registrar o ponto do funcionário a partir da digital;  ● Gerar relatório;  ● Gerar gráfico.  Também especificadas no diagrama de caso de uso (do inglês ​Use Case​) como                          pode ser visto na ​Figura 1. ​O diagrama de caso de uso é um diagrama que                                documenta as ​funcionalidades do sistema, ​relacionadas aos "atores". Um ator é                      um humano ou entidade máquina que interage com o sistema para executar um                          significante trabalho. 
  5. 5.   Figura 1 ­ Diagrama de Caso de Uso    O sistema deve disponibilizar as funções de acordo com os seguintes papéis:  Gestor:  ● Gerenciar Usuários;  ● Gerenciar Funcionários;  ● Visualizar e alterar ponto do funcionário;  ● Visualzar relatório;  ● Visualizar gráfico.   
  6. 6. Funcionário:  ● Gerenciar Moradores;  ● Gerenciar Condômino;  ● Gerenciar Apartamento;  ● Gerenciar Visitantes;  ● Gerenciar Visitas;  ● Registrar seu ponto.    1.3 Requisitos comportamentais ou de ​performance  Dentre os requisitos comportamentais e de​ performance​ temos :  Usabiidade  ● Ser fácil de usar, possuindo uma linguagem de acordo com o                      ambiente do negócio.  Compatibilidade  ● O sistema funcionará em ambiente Windows (Windows XP ou                  superior na versão​ desktop​).  ● O sistema deverá gerar relatório em PDF.  ● O sistema deverá gerar gráfico em PDF.  Disponibilidade  ● O sistema deve estar disponível sete dias por semana, 24 horas                      por dia.  Segurança  ● Todos os usuário do sistema deverão ter um ​login e uma senha de                          acesso.  ● O sistema não deve permitir o acesso de pessoas não autorizadas.  ● O sistema só deve permitir alterações no ponto do funcionário para                      o papel de gestor.  Performance 
  7. 7. ● Em condições normais o sistema não deve demorar mais de dez                      segundos para responder às requisições.    1.4 Gestão e Restrições Técnicas  As restrições técnicas que definem o escopo do projeto são:  ● O sistema de gerenciamento de banco de dados utilizado no projeto será                        PostgreSQL.  ● O ​software​ será desenvolvido utilizando a linguagem Delphi.  ● O bom funcionamento do ​software​ depende da infraestrutura de rede.    2.0 ESTIMAÇÕES DO PROJETO  Serão descritas nesta seção, as etapas utilizadas para calcular o tempo total de                          execução deste projeto. Para isso, a métrica de Lorenz & Kidd será aplicada ​a                            fim de estimar o esforço em termos de dias por pessoa.    2.1 Dados históricos utilizados para as estimações  Não serão utilizados dados históricos na mensuração do projeto, uma vez que é                          o primeiro projeto da equipe.    2.2 Técnicas de estimação e resultados  Como descrito anteriormente, neste projeto será utilizada a métrica de Lorenz &                        Kidd para o cálculo do tempo de execução do projeto. Esta técnica leva em                            consideração as classes que serão construídas no projeto.     2.2.1 Técnica de estimação  As seguinte etapas serão utilizadas para essa estimação: 
  8. 8. 1. Definir quais e quantas serão as classes chave do projeto podendo utlizar                        para isso o diagrama de classes de domínio.  2. Para definir o número de classes de suporte, classificar qual interface                      será utilizada no produto e de acordo com essa interface utilizar os                        multiplicadores correspondentes, especificados na ​Tabela 1​:    INTERFACE  MULTIPLICADOR  Não gráfica  2  Baseada em texto  2,25  GUI  2,5  GUI complexa  3  Tabela 1 ­ Valores Interface x Multiplicador    3. Multiplicar a quantidade de classes­chave pelo multiplicador              correspondente para estimar o número de classes de suporte.  4. Calcula­se o total das classes do projeto (classes de domínio + classes de                          suporte).  5. Multiplicar o total de classes (chave + suporte) pelo número médio de                        unidades de trabalho (dias­pessoa) por classe.  6. Calcular o tempo previsto para a realização do projeto.    2.3 Resultados  Com base no diagrama de classes de domínio, como pode ser visto na ​Figura 2​,                              fez­se a estimativa. O diagrama de classes fornece uma r​epresentação da                      estrutura e relações d​as ​classes​ que servem de modelo para ​objetos​. 
  9. 9.   Figura 2 ­ Diagrama de Classe.  1. Quantidade de classes­chave: 5. São elas: Visita, Visitantes, Condomino,                  Funcionário e Ponto. Enquanto que as classes Apto, Morador e Usuário                      são classes secundárias.  2. Tipo de interface das classes de suporte: GUI simples;   3. Valor multiplicador: 2,5;  4. Quantidade das classes de suporte: 5 (classes­chave) x 2,5 (Valor                    multiplicador) = 12,5 classes de suporte;  5. Total de classes: 5 (classes­chave) + 12,5 (classes de suporte) = 17,5;  6. Número médio de unidades de trabalho: 15 dias­pessoa;  7. Tempo previsto: 17,5 (total de classes) x 15 (dias­pessoa) = 262,5 dias                        por pessoa para a construção das classes;  8. Tendo em vista que a equipe é formada por 4 integrantes chegasse ao                          total de: 262,5 (total previsto) / 4 (número de integrantes) = 65,625 dias ou                            aproximadamente 66 dias. 
  10. 10. Sendo assim, como um mês possui em média 22 dias úteis então o projeto se                              estenderia por aproximadamente 3 meses.    2.4 Recursos do projeto  Nas seções abaixo serão explanados os recursos utilizados no projeto.                    Subdivididos em Recursos Humanos, Recursos de ​Software e Recursos de                    Hardware​.    2.4.1 Recursos Humanos  Para subsidiar todo o desenvolvimento e projeto do nosso produto utilizamos                      metodologias ágeis em virtude dos benefícios que estas proporcionam. Para o                      gerenciamento do projeto utilizamos a metodologia ágil Scrum pois possibilita                    uma iteração diária e uma boa colaboração da equipe. Como metodologia ágil                        de desenvolvimento utilizamos o XP, portanto, reafirma a integração entre os                      componentes da equipe com sua rotatividade de papéis e sua programação em                        pares. Todo o planejamento adotado no Scrum está descrito na seção 4 que fala                            sobre o planejamento temporal do desenvolvimento do projeto de ​software​.    2.4.2 Recursos de ​software  No desenvolvimento do projeto foram utilizados ​softwares ​que subsidiaram o                    processo:    Delphi XE7 ­ Ferramenta utilizada na modelagem do Diagrama de Classe                      e para a codificação do sistema.  SVN​ ­ Ferramenta para controle de versão.  PostgreSQL​ ­ Banco de dados utilizado. 
  11. 11. Google Docs ­ ​Software de armazenamento em nuvem que foi utilizado                      para construir a documentação do projeto.  Redmine ­ ​Ferramenta utilizada no gerenciamento das fases do projeto.  GanttProject ­ Ferramenta utilizada na modelagem do diagrama de                  Gantt.    2.4.2 Recursos de​ Hardware  Como utilizamos serviços de armazenamento em nuvem para promover um                    processo centralizado e mais eficiente e o controle de versão apoiado pelo SVN,                          então os computadores pessoais de cada integrante foram os únicos recursos                      físicos utilizados na construção do projeto. Totalizando dessa forma 4                    notebooks.  ● Primeiro Notebook  ○ Disco rígido de 1 Tb;  ○ 6 gb de memória ram;  ○ Processador Intel i5.    ● Segundo Notebook  ○ SSD 256 GB;  ○ 8 gb de memória ram;  ○ Processador Intel i7.    ● Terceiro Notebook  ○ Disco rígido de 500 GB;  ○ 8 gb de memória ram;  ○ Processador Intel i7.   
  12. 12. ● Quarto Notebook  ○ Disco rígido de 500 GB;  ○ 6 gb de memória ram;  ○ Processador Intel i3.      3.0 ANÁLISE E GESTÃO DE RISCOS  Entende­se como análise e gerência de riscos o processo de planejar, organizar,                        dirigir e controlar os recursos humanos e materiais dentro de um projeto, com o                            intuito de minimizar os efeitos dos riscos ao mínimo possível. Nesta seção serão                          apresentados os riscos que poderiam vir a prejudicar o andamento do projeto.     3.1 Riscos do projeto  Segue a ​Tabela 6 com todos os riscos identificados e sua respectiva                        classificação para distinção entre riscos gerais e específicos. Os riscos                    específicos são os riscos de projeto enquanto que os riscos gerais são todos os                            outros, técnicos, negócio, comum e até mesmo especial.      Risco  Projeto  Técnico  Negócio  Comum  Especial  1  Tecnologia  desconhecida pela    equipe    X        2  Pouco treinamento da  equipe    X        3  O produto não cumprir  o tamanho esperado  X      X    4  Grande quantidade de  usuários      X  X   
  13. 13. 5  Acesso lento ao  banco de dados    X        6  Sistema ficar fora do  ar    X        7  Saída de um dos  integrantes da equipe  X        X  8  Mau uso do sistema      X  X    9  Documentação  incompleta  X          10  Demora na  identificação  biométrica    X        11  Equipe insuficiente  X        X  12  Requisito mal  especificado pelo  cliente  X      X    Tabela 6 ­ Riscos do projeto    Nota­se que dos 12 riscos encontrados, aproximadamente 83% assumem a                    classificação de projeto e/ou técnico, sendo assim foi necessário focar num                      projeto bem especificado e em condições tecnológicas favoráveis ao                  desenvolvimento do projeto.    3.2 Tabela de riscos  Segue a ​Tabela 7 com os riscos identificados, a sua probabilidade de ocorrência                          e impacto esperado.    Risco  Probabilidade (%)  Impacto  O produto não cumprir o tamanho  65%  Catastrófico 
  14. 14. esperado  Sistema ficar fora do ar  40%  Catastrófico  Pouco treinamento da equipe  50%  Crítico  Tecnologia desconhecida pela equipe  45%  Crítico  Saída de um dos integrantes da equipe  30%  Crítico  Requisito mal especificado pelo cliente  45%  Crítico  Grande quantidade de usuários  70%  Marginal  Acesso lento ao banco de dados  60%  Marginal  Mau uso do sistema  60%  Marginal  Documentação incompleta  40%  Marginal  Demora na identificação biométrica  60%  Marginal  Equipe insuficiente  20%  Marginal  Tabela 7 ­ Probabilidade e impacto dos ricos    3.3 Redução e Gestão do Risco  Levando em consideração os riscos identificados, os quadros numerados de 1 à                        12 apresentam as estratégias para a redução e/ou gestão dos mesmos.    1 ­ Tecnologia desconhecida pela equipe  Probabilidade​: 45%  Impacto​: crítico  Descrição​: a tecnologia escolhida é desconhecida pelos desenvolvedores  Estratégia de redução​: cursos presenciais ou ​online  Plano de Contingência​: adotar a tecnologia C# pois entende­se que os  integrantes da equipe possuem conhecimento prévio.  Responsável​: Christiano Santana 
  15. 15. Status​: em andamento  Quadro 1 ­ Análise do risco 1    2 ­ Pouco treinamento da equipe  Probabilidade​: 50%  Impacto​: crítico  Descrição​: devido à falta de experiência com projetos anteriores a equipe                      possui pouco treinamento  Estratégia de redução​: oferecer treinamento aos desenvolvedores  Plano de Contingência​: contratar alguém experiente para auxílio e                  acompanhamento do desenvolvimento em tempo real.  Responsável​: Leonardo Finato  Status​: em andamento  Quadro 2 ­ Análise do risco 2    3 ­ O produto não cumprir o tamanho esperado   Probabilidade​: 65%  Impacto​: catastrófico  Descrição​: devido à complexidade do projeto pode acontecer de não                    conseguir concluir o esperado  Estratégia de redução​: negociar entregas parciais e novas datas com o                      cliente  Plano de Contingência​: negociar os prazos com o cliente revertendo os                      prazos definidos incorretamente  Responsável​: Manoela Oliveira  Status​: em andamento  Quadro 3 ­ Análise do risco 3 
  16. 16.   4 ­ Grande quantidade de usuários  Probabilidade​: 70%  Impacto​: marginal  Descrição​: ​em alguns momentos, o acesso simultâneo pode sobrecarregar a                    infraestrutura adotada  Estratégia de redução​: investir em alta disponibilidade do sistema  Plano de Contingência​: adotar sistema de ​logoff automático com tempo                    definido  Responsável​: Ricardo Souza  Status​: em andamento  Quadro 4 ­ Análise do risco 4    5 ­ Acesso lento ao banco de dados  Probabilidade​: 60%  Impacto​: marginal  Descrição​: com a grande quantidade de acessos o banco pode ficar                      sobrecarregado  Estratégia de redução​: investir na alta disponibilidade do banco  Plano de Contingência​: investir na replicação do banco de dados, fazendo                      com que, caso um banco sobrecarregue ainda tenhamos outro dispónivel                    oferecendo segurança e estabilidade.  Responsável​: Christiano Santana  Status​: em andamento  Quadro 5 ­ Análise do risco 5    6 ­ Sistema ficar fora do ar 
  17. 17. Probabilidade​: 40%  Impacto​: catastrófico  Descrição​: ocorrer algum problema da rede ou algum problema com o                      software​ e o sistema ficar inacessível  Estratégia de redução​: ter sempre alguém disponível para manutenção  Plano de Contingência​: contratar suporte a distância  Responsável​: Leonardo Finato  Status​: em andamento  Quadro 6 ­ Análise do risco 6    7 ­ Saída de um dos integrantes da equipe  Probabilidade​: 30%  Impacto​: crítico  Descrição​: ​há apenas 4 pessoas envolvidas no projeto e não há garantia que                          todos permaneçam até o final do projeto.  Estratégia de redução​: dividir entre a parte da equipe restante as                      funcionalidades que faltam  Plano de Contingência​: ​caso um integrante saia, deve­se identificar as                    prioridades do projeto, negociar um prazo maior com a promessa de entregar                        incrementos neste período  Responsável​: Manoela Oliveira  Status​: em andamento  Quadro 7 ­ Análise do risco 7    8 ­ Mau uso do sistema  Probabilidade​: 60%  Impacto​: marginal 
  18. 18. Descrição​: os usuários do sistema podem não usar corretamente o sistema  Estratégia de redução​: oferecer treinamento aos usuários  Plano de Contingência​: oferecer acompanhamento presencial aos usuários                para treinamento  Responsável​: Ricardo Souza  Status​: em andamento  Quadro 8 ­ Análise do risco 8    9 ­ Documentação incompleta  Probabilidade​: 40%  Impacto​: marginal  Descrição​: pelo curto tempo para o desenvolvimento do projeto a                    documentação pode acabar sendo deixada com baixa prioridade.  Estratégia de redução​: investir tempo em documentar o sistema  Plano de Contingência​: negociar prazo com o cliente para entrega da                      documentação completa  Responsável​: Christiano Santana  Status​: em andamento  Quadro 9 ­ Análise do risco 9    10 ­ Demora na identificação biométrica  Probabilidade​: 60%  Impacto​: marginal  Descrição​: a digital pode ter dificuldade em ser colhida  Estratégia de redução​: cadastrar todos os dedos para que haja outras                      opções de colheita  Plano de Contingência​: permitir identificação através do nome e cpf 
  19. 19. Responsável​: Leonardo Finato  Status​: em andamento  Quadro 10 ­ Análise do risco 10      11 ­ Equipe insuficiente  Probabilidade​: 20%  Impacto​: marginal  Descrição​: o número de programadores no desenvolvimento do projeto deste                    software​ é pequeno  Estratégia de redução​: investir na contratação de novos desenvolvedores  Plano de Contingência​: fazer com que os programadores tenham dedicação                    exclusiva a esse projeto  Responsável​: Manoela Oliveira  Status​: em andamento  Quadro 11 ­ Análise do risco 11    12 ­ Requisito mal especificado pelo cliente  Probabilidade​: 45%  Impacto​: crítico  Descrição​: diferentes clientes com diferentes pensamentos solicitam os                requisitos.  Estratégia de redução​: padronizar o uso das mais diversas técnicas de                      elicitação no processo de descoberta dos requisitos  Plano de Contingência​: analisar com todos os clientes os artefatos oriundos                      da elicitação dos requisitos e encontrar o ponto comum  Responsável​: Ricardo Souza 
  20. 20. Status​: em andamento  Quadro 12 ­ Análise do risco 12      4.0 PLANEJAMENTO TEMPORAL  Nesta seção iremos definir todas as atividades relativas à execução do projeto                        com suas respectivas data de execução e prazo. Para auxiliar a visualização de                          todas as tarefas, em relação ao aspecto temporal fez­se o uso do gráfico de                            Gantt​.    4.1 Conjunto de Tarefas do Projeto  Segue a ​Tabela 8 onde é mostrada a relação entre as tarefas macro, os dias de                                trabalho e a porcentagem a qual faz parte.    Dias de Trabalho  Porcentagem  Tarefas Macro  3  4,55%  Planejamento  15  22,73%  Requisitos, Análise e  Desenho  40  60,60%  Codificação  8  12,12%  Testes  Tabela 8 ­ Relação entre tarefas, dias de trabalho e a porcentagem    A justificativa da escolha dessa divisão temporal ser diferente da sugerida pelo                        Lacertae é o fato de utilizarmos Scrum e XP no nosso desenvolvimento pois                          ambos tem um foco maior em desenvolvimento e entregas incrementais e um                        foco menor em documentação. 
  21. 21. Segue a divisão do cronograma que foi seguido, segundo a metodologia Scrum,                        sendo composto por quatro Sprints que está respectivamentes explicitadas nas                    Tabelas 2, 3, 4 e 5​.  Na ​Tabela 2 ​temos a ​Sprint número 1 com duração de 14 dias e responsável                              pela entrega das funcionalidades de Manter Morador e Manter Funcionário.                    Tendo como Scrum Master, Manoela Oliveira.  Na ​Tabela 3 ​temos a ​Sprint número 2 com duração de 14 dias e responsável                              pela entrega das funcionalidades de Manter Visitante, Manter Usuário e Manter                      Condômino. Tendo como Scrum Master, Christiano Santana.  Na ​Tabela 4 ​temos a ​Sprint número 3 com duração de 14 dias e responsável                              pela entrega das funcionalidades de Manter Apartamento, Manter Visita e                    Registrar o ponto do funcionário a partir da digital. Tendo como Scrum Master,                          Ricardo Souza.  Na ​Tabela 5 ​temos a ​Sprint número 4 com duração de 14 dias e responsável                              pela entrega das funcionalidades de Gerar relatório e Gerar gráfico Tendo como                        Scrum Master, Leonardo Finato.      Sprint 1  Período​: 15/12/2014 à 28/12/2014  Funcionalidades  Manter Morador  Manter Funcionário  Scrum Master  Manoela Oliveira  Desenvolvedor 1  Christiano Santana  Desenvolvedor 2   Ricardo Souza  Testador  Leonardo Finato  Tabela 2 ­ Sprint 1   
  22. 22. Sprint 2  Período: ​29/12/2014 à 11/01/2015  Funcionalidades  Manter Visitante  Manter Usuário  Manter Condômino  Scrum Master  Christiano Santana  Desenvolvedor 1  Ricardo Souza  Desenvolvedor 2   Leonardo Finato  Testador  Manoela Oliveira  Tabela 3 ­ Sprint 2      Sprint 3  Período: ​12/01/2015 à 25/01/2015  Funcionalidades  Manter Apartamento  Manter Visita  Registrar o ponto do funcionário a  partir da digital  Scrum Master  Ricardo Souza  Desenvolvedor 1  Leonardo Finato  Desenvolvedor 2   Manoela Oliveira  Testador  Christiano Santana  Tabela 4 ­ Sprint 3    Sprint 4  Período: ​26/01/2015 à 08/02/2015  Funcionalidades  Gerar relatório  Gerar gráfico  Scrum Master  Leonardo Finato 
  23. 23. Desenvolvedor 1  Manoela Oliveira  Desenvolvedor 2   Christiano Santana  Testador  Ricardo Souza  Tabela 5 ­ Sprint 4    4.2 Diagrama de Gantt   O Diagrama de Gantt permite visualizar de forma gráfica o avanço e                        planejamento das diferentes etapas de um projeto. ​As Figuras 3, 4 e 5                          descrevem tal diagrama. Ressalva­se que as figuras 4 e 5 são imagens                        ampliadas da Figura 3, objetivando maior entendimento.         
  24. 24.   Figura 3 ­ Diagrama de Gantt 
  25. 25. Na ​figura 3 ​pode­se observar o diagrama completo. Nota­se o período em que                          as atividades são realizadas, permitindo uma visualização simplificada de como                    o projeto foi desenvolvido.      Figura 4 ­ Tarefas e seus os respectivos intervalos de tempo    Na ​figura 4 ​pode­se notar o planejamento temporal onde cada atividade está                        relacionada a um período de realização. 
  26. 26.   Figura 5 ­ Duração das tarefas    Na ​figura 5 ​nota­se o período de codificação subdividido nas quatro ​sprints de                          duração igual, a realização de testes durante todo o processo como pede a                          metodologia XP e o período para Planejamento e Requisitos, análise e desenho.                        Ver figura 3.     ​5.0 ORGANIZAÇÃO DO PESSOAL  Mesmo existindo o gestor da equipe, toda decisão da equipe é tomada em grupo                            e compartilhada com todos os indivíduos.    5.1 Estrutura da equipe  O projeto foi desenvolvido por meio de um processo iterativo e incremental.                        Dessa forma a cada ​Sprint ​uma pessoa diferente assumiu o papel de Scrum                          master ​e a responsabilidade pela codificação e testes. Porém para questão de                        organização e estruturação temos os seguintes papéis definidos:   
  27. 27. Gestor de projetos​: Manoela dos Reis Oliveira. O Gestor de projetos exerce a                          função de planejar e controlar a execução dos projetos com o intuito de conduzir                            melhor a equipe.  Desenvolvedores​: Christiano Santana e Ricardo Souza. O Desenvolvedor                exerce a função de codificar ou prestar manutenção em rotinas de um sistema                          especifico.  Testador​: Leonardo Finato. O Testador exerce a função de verificação do                      funcionamento do ​software​, localizando e registrando as falhas e como elas                      acontecem repassando­as para a equipe de desenvolvimento.    5.2 Mecanismos de comunicação  Mecanismos de comunicação utilizados por nossa equipe foram:   ● E­mail​, devido a rápida comunicação, capacidade de armazenamento e                  acesso ao histórico e também a presença de todos os componentes da                        equipe;   ● Google Hangouts também foi uma ferramenta muito útil pela agilidade e                      registro das conversas;   ● Whatsapp e Viber ​rápida comunicação e acesso fácil.  ● Google drive mostrou­se uma ferramenta colaborativa muito poderosa                aproximando os membros da equipe na elaboração de documentos e                    papéis de trabalho.      5.3 Uso do Edu­blog como ferramenta de apoio  O uso do Edu­Blog proporciona um aprendizado descentralizado e uniforme,                    todos os assuntos disponibilizados são expostos de forma clara e flexível. Dessa                        forma, entende­se que o aluno é incentivado a buscar novidades tecnológicas,                     
  28. 28. proporcionando maior conhecimento no que tange Tecnologia da Informação.                  Contudo, esse processo de aprendizado objetiva “romper” os paradigmas do                    ensino demasiado em sala de aula e abrange o conhecimento extra­classe.    6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A                QUALIDADE DO PRODUTO DE SW  Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas                            preocupações foram tomadas:  ● Testes​: realizados durante todo o ciclo de vida do ​software​. Desde o                        levantamento dos requisitos até possíveis manutenções no produto                depois dele ter sido entregue, foram efetuados testes de caixa branca e                        caixa preta. Também toda a documentação passou por testes.  ● Reuniões diárias​: segundo a metodologia SCRUM são necessárias                pequenas reuniões diárias durante todo o processo para atualização do                    que está sendo feito, como está sendo feito e quais as dificuldades                        encontradas.  ● Controle de versão​: para a confecção dos documentos foram utilizadas                    ferramentas de controle de versão atribuindo marcos nos quais                  representavam algum tipo de alteração, seja de melhoria ou correção.  ● Documentação​: a documentação fornece um parâmetro para avaliar o                  que foi feito na prática em comparação com o que foi descrito. É                          composta por toda a descrição de como o desenvolvimento foi feito, os                        diagramas que foram utilizados, planejamento temporal, recursos de                hardware, humanos e​ software​, etc.  ● Programação pareada​: é uma das técnicas da metodologia XP que foi                      utilizada no nosso desenvolvimento. Consiste em dois programadores                sentados lado a lado, sendo que somente um codifica, enquanto o outro                        fica responsável em analisar o andamento da implementação. Assim o                   
  29. 29. código é desenvolvido e analisado simultaneamente, melhorando a                produtividade. 

×