Plano de Projeto de Software NutriBR

486 visualizações

Publicada em

Plano de Projeto de Software NutriBR para a matéria Engenharia de Software

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

Nenhuma nota no slide

Plano de Projeto de Software NutriBR

  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 5 Affonso de Oliveira Souza Neto Ana Rute Passos Matheus Nascimento Oliveira Thiers Menezes Valdicélio Mendes São Cristóvão – Sergipe 2014
  2. 2. Affonso de Oliveira Souza Neto Ana Rute Passos Matheus Nascimento Oliveira Thiers Menezes Valdicélio Mendes 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 2014
  3. 3. Sumário 1. Introdução ....................................................................................................................4 1.1 Âmbito do Projeto ..................................................................................................4 1.2 Funções principais do produto de software.......................................................4 1.3 Requisitos comportamentais ou de performance.............................................5 1.4 Gestão e Restrições Técnicas.............................................................................5 2. Estimativas do Projeto ................................................................................................6 2.1 Dados históricos utilizados para as estimativas ...............................................6 2.2 Técnicas de estimação e resultados ..................................................................6 2.2.1 Técnica de estimação........................................................................................6 2.3 Resultados..............................................................................................................7 2.4 Recursos do Projeto..............................................................................................8 2.4.1 Recursos Humanos .......................................................................................8 2.4.2 Recursos de Hardware..................................................................................8 2.4.3 Recurso de Software .....................................................................................9 3. Análise e Gestão de Riscos .....................................................................................10 3.1 Riscos do projeto .................................................................................................10 3.2 Tabela de riscos...................................................................................................12 3.3 Redução e Gestão do Risco ..............................................................................13 4. Planejamento Temporal............................................................................................22 4.1 Conjunto de Tarefas do Projeto ........................................................................22 4.2 Diagrama de Gantt ..............................................................................................24 5. Organização do Pessoal...........................................................................................25 5.1 Estrutura da equipe .............................................................................................25 5.2 Mecanismos de comunicação ...........................................................................26 5.3 Uso do Edu-blog como ferramenta de apoio ..................................................26 6. Precauções tomadas para assegurar e controlar a qualidade do produto de SW....................................................................................................................................27 7. Anexos.........................................................................................................................28
  4. 4. 1. Introdução 1.1 Âmbito do Projeto O software NutriBR foi desenvolvido em 2013 com o objetivo de auxiliar o HU (Hospital Universitário) na coleta de dados sobre alimentação de pacientes. O Software gerencia uma base de dados para acompanhar a dieta de pacientes com problemas cardíacos distribuídos em dois grupo (grupo prevenção e grupo controle). As entradas são dados antropométricos e dieta, as saídas são dados armazenados no banco de dados organizados para consulta em um Sistema Web e geração de relatórios. 1.2 Funções principais do produto de software O sistema é composto por funcionalidades que permitem o controle dos dados inseridos pelos usuários. As principais funcionalidades e os respectivos usuários estão detalhados na Tabela 1 abaixo. Funcionalidade Usuário Cadastrar pacientes Nutricionista Cadastrar usuários Nutricionista Cadastrar dados antropométricos Nutricionista Cadastrar a dieta dos pacientes Nutricionista Tabela 1 – Funcionalidades e Usuários do NutriBR. Um diagrama de casos de uso está disponível na Figura 7.1, localizado na seção 7(Anexos) deste documento. A figura apresenta de forma detalhada de como será o uso do software.
  5. 5. 1.3 Requisitos comportamentais ou de performance Para que o NutriBR possa atender de forma eficiente aos seus usuários, o sistema deve: 1. Ser fácil de usar, possuindo uma linguagem de acordo com o ambiente do negócio. 2. Ser capaz de estar funcionando a todo momento (próximo às 24 horas do dia). 3. Os dados manipulados pelos usuário de um grupo (controle) não podem ser visto pelos usuários do outro grupo (prevenção) e vice-versa. 4. As informações armazenadas pelo NutriBR deverão ser íntegras para geração de dados concretos da pesquisa. . 1.4 Gestão e Restrições Técnicas As restrições técnicas que definem o escopo do NutriBR são: 1. O sistema de gerenciamento de banco de dados deverá ser o PostgreSQL. 2. A linguagem de programação deverá ser Ruby. 3. Todas as máquinas do Hospital Universitário que serão usadas para acesso do sistema devem possuir um Navegador Web. 4. O Framework de Desenvolvimento utilizado para o desenvolvimento da ferramenta deverá ser o Ruby On Rails. 5. O funcionamento do NutriBR depende de uma infraestrutura de rede intranet entre os diversos computadores que o utilizarão.
  6. 6. 2. Estimativas do Projeto Serão descritas nesta seção as etapas utilizadas para calcular o tempo total de execução deste projeto. A métrica utilizada foi a de Lorenz & Kidd, que estima o esforço em termos de dias por pessoa. 2.1 Dados históricos utilizados para as estimativas Como se trata do primeiro projeto da equipe, não há dados históricos para auxiliar na estimação. 2.2 Técnicas de estimação e resultados Será utilizada a métrica de Lorenz&Kidd para estimar o tempo de consecução do projeto. 2.2.1 Técnica de estimação A métrica de Lorenz&Kidd, orientada a classe, consiste em: 1. Identificar a quantidade de classes chave do projeto; 2. Encontrar a quantidade de classes suporte através da multiplicação da quantidade de classes chave pelo fator correspondente ao tipo da interface do projeto, conforme a Tabela 2 abaixo: Tabela 2 - Interface x Multiplicador. 3. Calcular o total de classe por meio da soma entre a quantidade de classes chave e quantidade de classes de suporte.
  7. 7. 4. Multiplicar o total de classes pelo número médio de unidades de trabalho (dias-pessoa) por classe, que seriam de 15 e 20 dias, segundo a métrica. 5. Assim, calcula-se o tempo previsto para desenvolvimento do projeto. 2.3 Resultados A seguir, os dados e cálculos do projeto: 1. Classes chaves: 6 classes. Um diagrama de classes está disponível na Figura 7.2, localizado na seção 7(Anexos) deste documento. A figura apresenta de forma detalhada as classes definidas no projeto. Classes principais: Usuário, ProfissionalSaude, VisitaClinica, Paciente, Recordatório e EventosClinicos. 2. Tipos de classes de suporte: GUI simples; 3. Fator multiplicador: 2,5; 4. Classes de suporte: 6 x 2,5 = 15 (Classes x Fator); 5. Total de classes: 6 + 15 = 21 (chave + suporte); 6. Como não há registros históricos anteriores, usa-se como base a sugestão da técnica de Lorenz & Kidd (15 a 20 dias/pessoa). Assim, determinou-se 17 dias/pessoa como número médio de unidades de trabalho; 7. Tempo previsto: 21 x 17 = 357 (total de classes x unidade de trabalho) dias por pessoa para construção das classes; 8. Como a equipe é formada por 05 componentes, resulta no total de 71 dias; 9. Levando-se em consideração os cerca de 22 dias úteis por mês, chega-se ao tempo previsto de quase 3 meses para finalização do Projeto.
  8. 8. Considerando os percentuais de distribuição de componentes essenciais no projeto, sugeridas pelas diretrizes da Lacertae Software, os 71 dias estimados para o desenvolvimento do projeto são distribuídos nas respectivas fases do projeto, apresentadas na Tabela 3. Fase Estimativa Dias de Trabalho Planejamento 4% 71 x 4% = 3 dias Análise e Projeto 20% 71 x 20% = 14 dias Geração de Código 40% 71 x 40% = 28 dias Testes 36% 71 x 36% = 26 dias Tabela 3 – Estimativa dos dias de trabalho por fase do projeto. 2.4 Recursos do Projeto Nesta seção são apresentados os Recursos Humanos, Recursos de Software e Recursos de Hardware. 2.4.1 Recursos Humanos ● 01 Gerente de Projetos; ● 01 Gerente de Negócios; ● 01 Analista de Testes; ● 02 Engenheiros de Software. 2.4.2 Recursos de Hardware 03 Estações de Trabalho com as seguintes configurações: ● Processador Core I5 de 3,0GHZ ou similar ● 8 GB de Memória Ram ● 250GB de Armazenamento
  9. 9. ● 2 Monitores de 19 Polegadas 02 Notebooks com as seguintes configurações: ● Processador Core I3 de 2,4GHZ ou similar ● 4 GB de Memória Ram ● 250GB de Armazenamento ● Tela de 14 Polegadas 2.4.3 Recurso de Software Para a construção do software serão utilizados alguns outros softwares que auxiliarão no processo de desenvolvimento. Dentro de um conjunto de softwares estão contidos editor de texto, servidor HTTP, máquina virtual, IDE de Desenvolvimento, entre outros. Apache 2.4 - Servidor HTTP produzido pela Apache e distribuído como software livre. Ruby - Linguagem de programação utilizada no desenvolvimento do projeto. RubyMine 6 - IDE de codificação do software. NetBeans - IDE de codificação do software. Google Chrome - Navegador Web. Mozilla Firefox - Navegador Web. StarUML - Ambiente de modelagem dos diagramas UML. Microsoft Office Word – Editor de texto para a documentação do software. Open Project - Ambiente de gerenciamento e criação de cronogramas a serem executados durante o processo de desenvolvimento do software. Google Drive - Software de armazenamento em nuvem. GIT - Sistema livre de controle de versão. GitHub - Armazenamento em nuvem do controle de versão implementado pelo GIT.
  10. 10. 3. Análise e Gestão de Riscos Nesta seção, serão analisados os riscos de acordo com as classificações e com base na probabilidade de ocorrência dos mesmos. Isso permitirá definir como será o impacto no projeto e formas de minimizar essas ocorrências. 3.1 Riscos do projeto Os riscos de um projeto podem ser distinguidos em riscos gerais (comuns a todo projeto) e riscos únicos do projeto. Os riscos gerais são listados na Tabela 4 abaixo: Risco Projeto Técnico Negócio Comum Especial Equipamento não disponível X Requisitos incompletos X X Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida X X Retenção de pessoas chaves X X Subestimativas do esforço X X Tabela 4 – Riscos gerais de um projeto de software.
  11. 11. Avaliação global dos riscos: 1. O Gestor de Software dá suporte ao projeto? Sim. O gestor de software tem um papel importante e muito participativo, o que contribui para o bom andamento do projeto. 2. Os Clientes estão entusiasmados com o projeto e o produto? O cliente está muito interessado no produto pois o software permitirá gerar um banco de dados rico em informações de dieta de pacientes. 3. Os Engenheiros de Software compreenderam bem os requisitos? Sim, os engenheiros compreendem bem os requisitos do projeto. 4. Os Clientes estiveram envolvidos na definição dos requisitos? Não. Foram muito solícitos na coleta de requisitos mas por serem muito atarefados, os encontros com a equipe são raros. 5. O âmbito do projeto é estável? Sim. 6. Os engenheiros de Software têm as competências requeridas? Apesar de pouco experientes, os Engenheiros de Software foram bem orientados na vida acadêmica e possuem base sólida para a função.
  12. 12. 7. Os requisitos do projeto são estáveis? Os requisitos foram bem definidos no início do trabalho e não foram necessárias alterações posteriores. 8. A Equipe de Desenvolvimento tem experiência na tecnologia a implementar? Não, poucos membros da equipe têm boa experiência com a tecnologia utilizada. 9. É adequado o número de pessoas da equipe de trabalho? Sim. Mesmo com a falta de experiência com a tecnologia, a equipe está fazendo grande progresso ao familiarizar-se com as ferramentas. 3.2 Tabela de riscos A Tabela 5 demostra os riscos identificados no projeto com seus valores de probabilidade associados. Um ponto de corte foi definido para agrupar e destacar riscos que possuem probabilidade de 50% ou superior. Nº Risco Categoria Probabilidade Impacto 1 O cliente não possui ideias claras sobre os requisitos Cliente 80% 5 (catastrófico) 2 Disponibilidade de hardware no servidor do HU Tecnologia 80% 5 (catastrófico) 3 Curto período para a construção do projeto Equipe 80% 4 (crítico) 4 Defeito do produto Negócio 70% 4 (crítico) 5 Funcionalidades implementadas do Tecnologia 70% 4 (crítico)
  13. 13. zero, sem reutilização 6 Tecnologia nova Tecnologia 70% 3 (moderado) 7 Restrição governamental Negócio 60% 3 (moderado) 8 Atraso na entrega Negócio 60% 3 (moderado) 9 Integrantes não possuem as habilidades necessárias Equipe 50% 2 (marginal) Linha de corte 10 Restrição de interoperabilidade Negócio 40% 2 (marginal) 11 Sem experiência anterior com o cliente Cliente 40% 2 (marginal) 12 Revisão técnica formal Maturidade do processo 40% 2 (marginal) 13 Cliente com pouca participação nas revisões Cliente 40% 2 (marginal) 14 Equipe não foi devidamente treinada Equipe 30% 2 (marginal) 15 Pessoas trabalhando apenas 1 turno Equipe 25% 1 (insignificante) Tabela 5 – Tabela de riscos específicos.
  14. 14. 3.3 Redução e Gestão do Risco Ações para prever, reduzir ou gerir os riscos identificados: 1. O cliente não possui ideias claras sobre os requisitos Probabilidade: 80% Impacto: Catastrófico Descrição: O cliente não consegue exprimir exatamente quais são suas reais necessidades. Estratégia de redução: Utilizar as técnicas de levantamento de requisitos (entrevistas, questionários, etc) Plano de contingência: Alocar a equipe para acompanhar a rotina do cliente com o objetivo de ajudá-lo na identificação dos requisitos. Responsável: Valdicélio Mendes Status: Iniciado 2.Disponibilidade de Hardware no Servidor do HU Probabilidade: 80% Impacto: Catastrófico Descrição: Obsolescência do servidor de aplicação poderá prejudicar o desempenho do sistema. Estratégia de redução: Solicitar a revitalização do servidor. Plano de contingência: Solicitar ao cliente a troca do servidor. Responsável: Valdicélio Mendes Status: Iniciado
  15. 15. 3.Curto período para a construção do projeto Probabilidade: 80% Impacto: Crítico Descrição: A qualidade do projeto poderá ser comprometida por falta de tempo. Estratégia de redução: Unir todos os recursos disponíveis para acelerar o processo de construção do projeto. Plano de contingência: Solicitar ao cliente extensão do prazo de entrega. Responsável: Valdicélio Mendes Status: Iniciado 4. Defeito do produto Probabilidade: 70% Impacto: Crítico Descrição: Produto com mal funcionamento. Estratégia de redução: Criar um script de log automático de notificação de defeito. Plano de contingência: Utilizar um SaSS de gerenciamento de falhas (bug tracker). Responsável: Rute Status: Iniciado
  16. 16. 5. Funcionalidades implementadas do zero, sem reutilização Probabilidade: 70% Impacto: Crítico Descrição: Não há código de projetos anteriores para serem utilizados. Estratégia de redução: procurar projetos open source que possamos reutilizar alguma funcionalidade. Plano de contingência: Criar as novas funcionalidades. Responsável: Rute Status: Iniciado 6. Tecnologia nova Probabilidade: 70% Impacto: Moderado Descrição: Tecnologia desconhecida pela equipe. Estratégia de redução: Sugerir que os integrantes da equipe participem de cursos e discussões em grupo. Plano de contingência: Adotar uma tecnologia conhecida pela equipe. Responsável: Rute Status: Iniciado
  17. 17. 7. Restrição Governamental Probabilidade: 60% Impacto: Moderado Descrição: O uso do software infligiu regras de uso em hospitais. Estratégia de redução: Instruir a equipe sobre regras da área da saúde. Plano de contingência: Corrigir imediatamente o motivo de impedimento do sistema. Responsável: Affonso Status: Iniciado 8. Atraso na entrega Probabilidade: 60% Impacto: Moderado Descrição: O produto não será entregue no prazo definido. Estratégia de redução: Acompanhamento do desenvolvimento do projeto. Plano de contingência: Parcerias com empresas de desenvolvimento terceirizadas. Responsável: Affonso Status: Iniciado
  18. 18. 9. Integrantes não possuem as habilidades necessárias Probabilidade: 50% Impacto: Marginal Descrição: Equipe sem treinamento necessário Estratégia de redução: Sugerir que os integrantes da equipe participem de cursos e discussões em grupo. Plano de contingência: Formar parcerias com centros de cursos especializados. Responsável: Affonso Status: Iniciado 10. Restrição de Interoperabilidade Probabilidade: 40% Impacto: Marginal Descrição: O sistema deverá possuir um canal de interação com outros sistemas Estratégia de redução: Adicionar ao plano de projeto a documentação de desenvolvimento de uma API para estabelecimento de comunicação de entrada e saída de dados através do sistema. Plano de contingência: Desenvolver uma API e a documentação da mesma para comunicação com sistemas externos Responsável: Matheus Oliveira Status: Iniciado
  19. 19. 11. Sem experiência anterior com o cliente Probabilidade: 40% Impacto: Marginal Descrição: A equipe não possui experiência de trabalhos anteriores com o cliente. Estratégia de redução: Incluir no Plano de Projeto reuniões semanais com o cliente. Plano de contingência: Solicitar ao cliente para que faça uma apresentação de todo o negócio e o contexto onde está inserido para a equipe. Responsável: Matheus Oliveira Status: Iniciado 12. Revisão técnica formal Probabilidade: 40% Impacto: Marginal Descrição: É necessário realizar revisão técnica formal por parte do cliente. Estratégia de redução: Solicitar ao cliente a participação das reuniões de modelagem do processo para homologação dos mesmos. Plano de contingência: Incluir no Plano de Projeto reuniões de modelagem de processos com o cliente Responsável: Matheus Oliveira Status: Iniciado
  20. 20. 13. Cliente com pouca participação nas revisões Probabilidade: 40% Impacto: Marginal Descrição: A falta de interesse do cliente no andamento do projeto pode fazer com que a equipe cometa erros, causando desistência do cliente. Estratégia de redução: Motivar a participação constante do cliente no projeto. Plano de contingência: Mostrar para o cliente que a participação dele é importante e mostrar como o software pode ser, de fato, interessante para o negócio dele. Responsável: Thiers Status: Iniciado 14. Equipe não foi devidamente treinada Probabilidade: 30% Impacto: Marginal Descrição: Equipe sem capacidade para desenvolver o projeto na linguagem sugerida. Estratégia de redução: Preparar a equipe disponibilizando cursos de capacitação. Plano de contingência: Usar linguagem que a equipe domina e está acostumada a trabalhar. Responsável: Thiers Status: Iniciado
  21. 21. 15. Pessoas trabalhando apenas um turno Probabilidade: 30% Impacto: Insignificante Descrição: Desenvolvedores que não trabalham integralmente ao projeto podem causar atrasos. Estratégia de redução: Motivar a equipe trabalhando inteiramente no projeto. Plano de contingência: Considerar a adoção de incentivos financeiros referente à produtividade. Responsável: Thiers Status: Iniciado
  22. 22. 4. PlanejamentoTemporal 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 faremos o uso do gráfico de Gantt. 4.1 Conjunto de Tarefas do Projeto A metodologia de desenvolvimento de software escolhida foi o RUP, que se divide-se em quatro fases: Concepção/Iniciação, Elaboração, Codificação/Construção e Transição/Testes. Os detalhes do cronograma de tarefas são expostos na Tabela 6 abaixo. Id Tarefa Duração Início Término 1 Concepção/Iniciação 3 dias 02/02/2015 04/02/2015 2 Realizar levantamento de requisitos 2 dias 02/02/2015 03/02/2015 3 Elaborar especificação dos requisitos 2 dias 03/02/2015 04/02/2015 4 Elaboração 20 dias 05/02/2015 24/02/2015 5 Elaborar Modelo de Caso de Uso 2 dias 05/02/2015 06/02/2015 6 Elaborar Diagrama de Classes 2 dias 09/02/2015 10/02/2015 7 Elaborar Diagrama de Estado 2 dias 11/02/2015 12/02/2015 8 Elaborar Diagrama de Componentes 4 dias 13/02/2015 16/02/2015 9 Elaborar Diagrama de Sequência 2 dias 17/02/2015 18/02/2015 10 Elaborar Diagrama de Implantação 1 dias 19/02/2015 19/02/2015 11 Projetar Interfaces 4 dias 20/02/2015 23/02/2015
  23. 23. 12 Avaliar projeto de intefaces 1 dias 24/02/2015 24/02/2015 13 Codificação/Construção 38 dias 25/02/2015 03/04/2015 14 Cadastrar Paciente 3 dias 25/02/2015 27/02/2015 15 Consultar Paciente 3 dias 02/03/2015 04/03/2015 16 Alterar Paciente 5 dias 05/03/2015 09/03/2015 17 Excluir Paciente 2 dias 10/03/2015 11/03/2015 18 Cadastrar Especialista 5 dias 12/03/2015 16/03/2015 19 Consultar Especialista 3 dias 17/03/2015 19/03/2015 20 Alterar Especialista 5 dias 20/03/2015 24/03/2015 21 Excluir Especialista 2 dias 25/03/2015 26/03/2015 22 Manutenir Dieta 5 dias 27/03/2015 31/03/2015 23 Emitir Relatório 3 dias 01/04/2015 03/04/2015 24 Transição/Testes 23 dias 07/04/2015 29/04/2015 25 Especificar de Testes 3 dias 07/04/2015 09/04/2015 26 Executar Testes 8 dias 10/04/2015 17/04/2015 27 Analisar resultados 2 dias 20/04/2015 21/04/2015 28 Realizar testes de aceitação 6 dias 22/04/2015 27/04/2015 29 Entregar software 2 dias 28/04/2015 29/04/2015 Tabela 6 – Cronograma do diagrama de Gantt.
  24. 24. 4.2 Diagrama de Gantt A figura 1 representa o Diagrama de Gantt de acordo com o cronograma de tarefas apresentado na Tabela 6. Figura 1 – Diagrama de Gantt.
  25. 25. 5. Organização do Pessoal Nesta seção será apresentada a forma de distribuição dos recursos humanos no projeto e qual a função de cada papel. 5.1 Estrutura da equipe Gerente de Projetos: Responsável pela alocação de recursos, ajuste de prioridades, coordenação das interações entre clientes e usuários. Gerente de Negócios: Busca maximizar as oportunidades para a empresa e para o projeto, entendendo sobre os desejos e necessidades dos seus clientes. Analista de Testes: Será o responsável por identificar e definir os testes, monitorar a abrangência dos testes e avaliar a qualidade obtida após os testes. Engenheiro de Software: Terá a responsabilidade de liderar e coordenar a equipe na identificação de requisitos e na modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade. A Tabela 7 mostra, de forma geral, como ficou a distribuição de funções entre os integrantes da equipe. Papel Integrante Gerente de Projetos Matheus Oliveira Gerente de Negócios Affonso Souza Engenheiro de Software Valdicélio Mendes
  26. 26. Engenheiro de Software Thiers Menezes Analista de Testes Ana Rute Passos Tabela 7 – Distribuição de papéis. 5.2 Mecanismos de comunicação A comunicação entre a própria equipe e os clientes será feita pelos seguintes meio: ● E-mail: ferramenta mais utilizada, principalmente pelo alcance entre os participantes e com o cliente. ● Google Hangout: poderoso software de comunicação que permite de conversas de texto a conferências. ● Reuniões presenciais: recurso que permite, de forma rápida, identificar a situação do projeto e solucionar problemas locais. 5.3 Uso do Edu-blog como ferramenta de apoio A utilização do Edu-blog incentiva a pesquisa dos temas propostos pela disciplina. Permite que cada equipe se aprofunde no assunto designado pelo Professor, compartilhando o conhecimento com os demais colegas ao longo e ao final do semestre e com qualquer usuário da Internet. Essa ferramenta deveria ser utilizada em outras disciplinas, pois, forçaria que os alunos estudassem os assuntos e depois haveria a compilação dos principais tópicos para apresentação ao final da disciplina.
  27. 27. 6. Precauções tomadas paraassegurar e controlara qualidade do produto de SW Com a finalidade de garantir a qualidade de todas as fases do projeto, algumas preocupações foram tomadas: Documentação: durante todo o ciclo de vida do software, foram produzidos documentos. A produção de documentação fornece um parâmetro para avaliar o que foi feito na prática em comparação com o que foi descrito. Essa documentação é importante na elaboração dos testes, a fim de que o sistema esteja totalmente de acordo com as especificações. Também serve para guiar o andamento do projeto. A documentação deverá ser atualizada quando houver mudanças. Testes: A fim de garantir a qualidade final ao produto e minimizar as eventuais falhas que viessem a ocorrer, os testes de software foram elaborados e colocados em prática durante todo o ciclo de desenvolvimento do projeto. Desde o levantamento de requisitos até possíveis manutenções no produto depois de ele ter sido entregue. A contínua aplicação de testes permite que os defeitos sejam descobertos o mais cedo possível, causando assim um menor impacto nos custos de modificações do software. Controle de versão: ferramenta que permite o rastreamento de alterações, identificando os seus autores. Ajuda 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. Acompanhamento do projeto: as atividades desenvolvidas durante todo o ciclo de desenvolvimento são acompanhadas constantemente e todos os requisitos são validados com os clientes.
  28. 28. 7. Anexos Figura 7.1 - Diagrama de casos de uso
  29. 29. Figura 7.2 - Diagrama de classes do projeto

×