Plano do projeto de software SIGEM - Sistema de gestão de materiais

2,400 views
2,268 views

Published on

Trabalho final para a disciplina Gerência de Projetos.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,400
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
109
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Plano do projeto de software SIGEM - Sistema de gestão de materiais

  1. 1. UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAÇÃO PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW Cristina Araújo Marcos Felipe MANAUS 2013
  2. 2. UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAÇÃO Cristina Araújo Marcos Felipe Trabalho apresentado para graduação em Sistemas de Informação, com o tema “PLANO DO PROJETO DE SOFTWARE OO PARA PRODUTOS DA LACERTAE SW” para obtenção de nota parcial na disciplina IEC921 - GERÊNCIA DE PROJETOS, ministrada pelo Prof. Rogério Patrício Chagas do Nascimento. MANAUS 2013
  3. 3. Índice1. INTRODUÇÃO .................................................................................................... 3 1.1 ÂMBITO DO PROJETO ........................................................................................ 3 1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE ............................................... 3 1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ....................................... 5 1.4 GESTÃO E RESTRIÇÕES TÉCNICAS ..................................................................... 62. ESTIMATIVAS DO PROJETO ............................................................................ 7 2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS......................................... 7 2.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS ............................................................ 7 2.2.1 TÉCNICA DE ESTIMATIVAS ............................................................................... 72.3 RESULTADOS .................................................................................................. 9 2.4 RECURSOS DO PROJETO .................................................................................... 9 2.4.1 RECURSOS HUMANOS .................................................................................... 9 2.4.2 RECURSOS DE SOFTWARE ............................................................................ 10 2.4.3 RECURSOS DE HARDWARE ........................................................................... 113. ANÁLISE E GESTÃO DE RISCOS .................................................................. 12 3.1 RISCOS DO PROJETO ....................................................................................... 12 3.2 AVALIAÇÃO GLOBAL DOS RISCOS ...................................................................... 13 3.3 TABELA DE RISCOS .......................................................................................... 14 3.4 REDUÇÃO E GESTÃO DO RISCO ........................................................................ 154. PLANEJAMENTO TEMPORAL ........................................................................ 19 4.1 CONJUNTO DE TAREFAS DO PROJETO............................................................... 19 4.2 DIAGRAMA DE GANTT ...................................................................................... 205. ORGANIZAÇÃO DO PESSOAL ....................................................................... 21 5.1 ESTRUTURA DA EQUIPE.................................................................................... 21 5.2 MECANISMOS DE COMUNICAÇÃO....................................................................... 22 5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO ............................................. 236. PRECAUÇÕES PARA ASSEGURAR E CONTROLAR A QUALIDADE DOPRODUTO ............................................................................................................ 24 6.1 SEGUIMENTO E CONTROLE DO PROJETO DE SOFTWARE..................................... 24 6.2 REVISÕES TÉCNICAS FORMAIS ......................................................................... 24 6.3 PRODUÇÃO DE DOCUMENTAÇÃO ...................................................................... 247.1 ANEXOS ......................................................................................................... 25REFERÊNCIAS ..................................................................................................... 31
  4. 4. 1. Introdução 1.1 Âmbito do Projeto O Sigem (Sistema de Gestão de Materiais) tem por objetivo o controle de equipamentos que são emprestados e movimentados entre departamentos. Esses variam desde computadores e impressoras até placas e equipamentos de menor porte. Seu objetivo é facilitar os processos de empréstimo e devolução de equipamentos, por meio de registros como data de entrega e devolução, geração de relatórios e a documentação necessária, facilitando assim, o trabalho da secretaria e demais departamentos responsáveis. Como podem ser observados nas Figuras 1.1, 1.2 e 1.3, em anexos, o diagrama lógico, a modelagem estendida e o diagrama de classes, respectivamente. Estes demonstram a estrutura do sistema e relacionam o âmbito descrito anteriormente à um nível mais baixo de abstração. 1.2 Funções principais do produto de software As principais funcionalidades do Sistema de Gestão de materiais são:1. Cadastrar Categorias de Equipamento2. Editar Categorias de Equipamento3. Excluir Categorias de Equipamento4. Pesquisar Categorias de Equipamento5. Cadastrar Projetos6. Editar Projetos7. Excluir Projetos8. Pesquisar Projetos9. Cadastrar Alunos 3
  5. 5. 10. Editar Alunos11. Excluir Alunos12. Pesquisar Alunos13. Cadastrar Equipamento14. Editar Equipamento15. Excluir Equipamento16. Pesquisar Equipamento17. Efetuar Empréstimo18. Agendar Empréstimo19. Efetuar Devolução20. Gerar Relatórios O sistema deve permitir as seguintes funcionalidades para seus usuários: Secretaria Cadastrar equipamento Cadastrar curso Registrar empréstimo Cadastrar Aluno Coordenador Cadastrar projeto Cadastrar curso Gerar Relatório Aprovar empréstimo Professor Efetuar empréstimo Consultar equipamento Agendar empréstimo 4
  6. 6. 1.3 Requisitos comportamentais ou de performanceDisponibilidade:o O sistema estará em funcionamento 24hs por dia, 7 dias por semana, com paradas pré-programadas para manutenção. .Segurança:o O sistema não deve permitir acesso por usuários não autorizados.o Senhas devidamente criptografadas e especificadas por usuários.Portabilidade:o O sistema deve ser executado em plataformas Linux(Ou qualquer distribuição Unix) e Windows, XP ou superior.o O sistema deve ser compatível com os browsers Mozilla Firefox , Google Chrome, Opera e Safari. Conforme figura 1.4 em anexos, exibe a tela do sistema.Eficiência:o Em condições normais, o sistema deve responder a qualquer requisição no máximo em 3 segundos, com exceção de processamento de relatórios, aonde o limite máximo é 6 segundos.o Em condições de estresse (muitas requisições), o sistema deve responder a qualquer requisição no máximo em 6 segundos, com exceção de processamento de relatórios, aonde o limite máximo é 9 segundos.Integridade:o O sistema deverá exibir os dados de empréstimos somente para seus respectivos solicitantes, e a própria secretaria.o O usuário com perfil de professor somente poderá solicitar equipamentos caso o mesmo não esteja previamente alocado/reservado em outro projeto. 5
  7. 7. o Somente a secretaria poderá registrar os empréstimos e gerar a documentação necessária para os mesmos. Usabilidade: o Interface simples: o sistema exibe uma barra de menu contendo todas as funcionalidades disponíveis ao usuário. o A navegabilidade é intuitiva e a disposição dos campos facilita a compreensão e utilização mesmo para que não possui experiência com o sistema. 1.4 Gestão e Restrições Técnicas As restrições encontradas na descrição do sistema que poderão limitar o escopo podem ser:1. O produto deve ser implementado como uma aplicação web e portável a várias plataformas;2. O produto deve ser implementado na linguagem de programação PHP, HTML, jQuery, utilizando o framework CAKE;3. O produto deve utilizar Banco de Dados MySQL;4. Datas de entrega inflexíveis, pois o processo de desenvolvimento ágil (SCRUM), exige uma apresentação em datas previamente estipuladas;5. Stakeholders nem sempre presentes para recolhimento de requisitos e validação.6. Falta de experiência prática com as ferramentas e métodos utilizados para o desenvolvimento, assim como cronograma curto para desenvolvimento. 6
  8. 8. 2. Estimativas do Projeto As estimativas de projeto aqui apresentadas demonstram a quantidade de temponecessário para a execução do projeto. Paralelamente às estimativas baseadas namétrica da Lacertae Software, Lorenz &Kidd (orientada a classes), estão listadas deforma a comparar os dados das estimativas com os calculados (dados reais do projeto). É possível verificar que houve várias diferenças em relação ao que foi estimadoinicialmente, e o que ocorreu de fato. Pode-se dar ênfase à tarefa de codificação, quefoi estipulado em um nível inferior se relacionado com os dados reais. . 2.1 Dados históricos utilizados para as estimativas Levando em consideração projetos semelhantes, pode-se considerar o primeiroprojeto com maior detalhamento relacionado à estimativas de tempo e uso daferramenta, assim como análise de riscos. 2.2 Técnicas de estimação e resultados Para encontrar o tempo, aplicou-se uma técnica de estimativa, a qual foi indicadana disciplina de gerência de projetos. Neste caso iremos utilizar a métrica adotada pelaLacertae Software, Lorenz &Kidd (orientada a classes). 2.2.1 Técnica de estimativas Com a aplicação da métrica de Lorenz &Kidd definida pela Lacertae Software, osseguintes resultados foram obtidos: 7
  9. 9. O número de classes chaves do projeto são 3. Como o projeto é um sistema para ambiente WEB, utilizará interface GUI complexa, dessa forma o fator multiplicador será 3. O número de classes de suporte pode ser encontrado a partir do número de classes chave x multiplicador, dessa forma, 3 x 3 = 9 classes de suporte. O total de classes do projeto será número de classes chave + número de classes de suporte, onde 3 + 9 = 12 classes. Parte da equipe não possui muita experiência com projetos relacionados, então chegou-se à um número de aproximados 16 dias-pessoa. O cálculo do esforço estimado: 12 classes x 16 dias-pessoa, onde obtém-se 192 dias de trabalho. Considerando 4 pessoas envolvidas no projeto e 22 dias úteis de trabalho por mês => 192/4 = 48 dias, aproximadamente 1,6 meses Considerando que os dias de trabalho totais são 192 dias, esses dias agora sãodistribuídos de acordo com as seguintes porcentagens de distribuição dos componentesessenciais no projeto, sugeridas pela Lacertae Software: Estimativa RealizadoPlanejamento 20% 5%Análise e Projeto 20% 15%Geração de Código 20% 52%Testes 40% 28%Na tabela acima, a estimativa é realizada com base nos cálculos sugeridos pelametodologia da Lacertae Software, e ao lado, o Realizado é calculado com base nastarefas efetuadas ao longo das Sprints. Os dados do Realizado foram retirados doRedmine, referenciado em anexos, na figura 1.5. 8
  10. 10. 2.3 Resultados1) Planejamento: 192 * 20% = 38,4 dias de trabalho2) Análise e Projeto: 192 * 20% = 38,4 dias de trabalho3) Testes: 192 * 40% = 76,8 dias de trabalho4) Geração de código: 192 * 20% = 38,4 dias de trabalho 2.4 Recursos do projeto A aplicabilidade dos recursos do projeto são evidenciados no restante dodocumento, nas sessões aonde são exibidas as ferramentas e recursos relacionadosentre eles, recursos humanos e tecnológicos. 2.4.1 Recursos Humanos De acordo com a metodologia ágil, onde as funções mudam conforme as sprints,o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento contará comquatro pessoas que exercerão os diversos papéis necessários à execução, conformedescrito a seguir:Sprint 1 Período: 07/01 à 23/01Scrum Master Katlen MaduroDeveloper1 Marcos FelipeDeveloper2 Renan ReisTester Diovane 9
  11. 11. Sprint 2 Período: 28/01 à 20/02Scrum Master Renan ReisDeveloper1 Katlen MaduroDeveloper2 Diovane MonteiroTester Marcos FelipeSprint 3 Período: 25/02 à 13/03Scrum Master Marcos FelipeDeveloper1 Diovane MonteiroDeveloper2 Katlen MaduroTester Renan ReisSprint 4 Período: 18/03 à 03/04Scrum Master Diovane MonteiroDeveloper1 Renan ReisDeveloper2 Marcos FelipeTester Katlen Maduro 2.4.2 Recursos de Software O projeto irá usufruir dos seguintes softwares para composição do produto desoftware, além do projeto de gerência de produção: 10
  12. 12. Wamp – Composto do módulo Apache e MySQL, responsável pelo serviço detransação de dados para a Web e gerenciamento da base de dados do software.Eclipse SR2 – IDE a ser utilizada na implementação do produto de software final.PHP –linguagem de programação a ser utilizada para o desenvolvimento do softwarefinal.CAKE PHP – Framework escrito em PHP que tem como principais objetivos ofereceruma estrutura que possibilite aos programadores de PHP de todos os níveisdesenvolverem aplicações robustas rapidamente, sem perder flexibilidade, utilizadoconjuntamente com MVC.Microsoft Word– Editor de texto usados na documentação, relatórios e documentosafins.Microsoft Excel – Planilha eletrônica usada para criar o product backlog e mantercontrole sobre determinadas modificações.MSProject – Software gerenciador de projetos que servirá de base para gestãoatualizada e confiável do projeto do produto. 2.4.3 Recursos de Hardware Para documentação, implementação e gestão do projeto de software, nossosrecursos iniciais de hardware estão agrupados em quatro notebooks, além do recursodas nuvens, em servidores externos. 11
  13. 13. 3. Análise e Gestão de Riscos Esta análise consiste em uma série de passos que permitem compreender egerir os riscos que podem ocorrer no projeto. Desta forma, os riscos foram identificados,avaliados quanto à probabilidade de ocorrência e estimados segundo o seu impacto noprojeto de software para administrá-los corretamente. 3.1 Riscos do projeto Os riscos do projeto que foram identificados e necessitam ser monitoradosdurante o projeto são:Risco Projeto Técnico Negócio Comum EspecialEquipamento indisponível XRequisitos em constante XmudançasUso de metodologias X XespeciaisFalha na integração com X Xos demais sistemasEquipe com comunicação XreduzidaUtilização de softwares Xnos quais a equipe nãopossui nenhumaexperiência 12
  14. 14. 3.2 Avaliação global dos riscos1. O Gestor de Software dá suporte ao projeto? R: Confere. No caso do gestor, o mesmo participa do processo de forma ativa, por isso existe suporte ao projeto.1. Os Clientes estão entusiasmados com o projeto e o produto? R: Os usuários em geral, assim como o cliente, estão entusiasmados e possuem expectativas acerca do projeto, que auxiliará no processo de empréstimo e controle de equipamentos.2. Os Engenheiros de Software compreenderam bem os requisitos? R: Os requisitos foram bem definidos e o escopo pode ser considerado pequeno, porém com várias alterações na medida em que outros stakeholders estejam envolvidos.3. Os Clientes estiveram envolvidos na definição dos requisitos? R: Em maior parte do projeto. Porém a partir da Sprint 3, houve o envolvimento de mais stakeholders, o que acarretou em mais requisitos gerados.4. O âmbito do projeto é estável? R: O âmbito do projeto está fixo e condizente com a ideia inicial.5. Os engenheiros de software têm as competências requeridas? R: A maior parte dos engenheiros possui a competência necessária para desenvolver o projeto.6. Os requisitos do projeto são estáveis? R: Não há estabilidade relacionada aos requisitos do projeto, visto que ocorreram várias mudanças no decorrer do mesmo. 13
  15. 15. 7. A equipe de desenvolvimento tem experiência na tecnologia a implementar? R: Sim. A equipe possui experiência na tecnologia em questão.8. É adequado o número de pessoas da equipe de trabalho? R: Mesmo a equipe possuindo todos os integrantes, para o escopo determinado, seriam necessários mais integrantes para se manter a qualidade, escopo e prazo, na forma em que foram determinados. 3.3 Tabela de riscos Conforme os riscos identificados, abaixo serão apresentados a sua probabilidade de ocorrência e impacto esperado no projeto. Nº Risco Probabilidade Impacto 1 Exceder o prazo estipulado para 35% Catastrófico a entrega 2 Falta de validação por parte do 15% Catastrófico usuário final 3 Requisitos voláteis 58% Crítico 4 Requisitos não compreendidos 25% Crítico adequadamente 5 Afastamento de membro relativo 15% Crítico ao projeto 6 Dispersão da equipe durante o 95% Marginal projeto 7 Disponibilidade parcial do tempo 90% Marginal 8 Utilização de tecnologias 45% Marginal recentes 14
  16. 16. 3.4 Redução e Gestão do Risco Para garantir as estratégias de redução, supervisão e gestão dos riscos (RSGR)identificados, estão descrito abaixo os principais:1. Exceder o prazo estipulado para a entregaProbabilidade: 35% Impacto: CatastróficoDescrição: O prazo estimado para o projeto é suficiente, porém o escopo é volátil e,portanto, a estimativa pode estar equivocada.Estratégia de redução: A realização de acompanhamento e atualização dadocumentação.Plano de Contingência: Focar no desenvolvimento e possível entrega das funções emódulos essenciais para o funcionamento do sistema, além de negociar com ocliente quanto à uma possível extensão do prazo.Responsável: Marcos Felipe2. Falta de validação por parte do usuário finalProbabilidade: 15% Impacto: CatastróficoDescrição: Ocorreram de fato mudanças, devido aos principais stakeholders teremsido entrevistados no meio do projeto, visto que não era possível entrevistá-los antes,devido a problemas de comunicação.Estratégia de redução: Realizar reuniões periódicas com parte dos envolvidos paraesclarecer requisitos e regras de negócio conforme o projeto é desenvolvido . 15
  17. 17. Plano de Contingência: Replanejar parte das atividades para se adequar aos novosrequisitos do projetoResponsável: Diovane MonteiroStatus: Em andamento3. Requisitos voláteisProbabilidade: 58% Impacto: CríticoDescrição: Ocorreram de fato mudanças, devido aos principais stakeholders teremsido entrevistados no meio do projeto, visto que não era possível entrevistá-los antes,devido a problemas de comunicação.Estratégia de redução: A realização de reuniões com stakeholdersPlano de Contingência: Replanejar parte das atividades para se adequar aos novosrequisitos do projetoResponsável: Diovane MonteiroStatus: Em andamento4. Requisitos não compreendidos adequadamenteProbabilidade: 25% Impacto:CríticoDescrição:Nem todos os requisitos foram adequadamente capturados durante oprocesso de elicitação, assim como na adoção da metodologia Scrum.Estratégia de redução: Reuniões constantes com os integrantes e o ProductOwner,com a finalidade de sanar dúvidas relacionadas ao requisitos, mapeamento dosmesmo e criação do backlog.Plano de Contingência: Analisar os documentos gerados pelas reuniões e reaver osconceitos relacionados aos requisitos do sistema.Responsável: Diovane Monteiro 16
  18. 18. 5. Afastamento de membro relativo ao projetoProbabilidade: 15% Impacto: CríticoDescrição: Os integrantes do projeto são, em sua maioria, assíduos ecompromissados com o trabalho, porém por motivos de saúde e/ou locomoção, aausência em determinadas fases do projeto são plausíveis.Estratégia de redução: Distribuição das atividades do membro em questão para osdemais da equipe, assim como mudanças na prioridade do escopo.Plano de Contingência: No caso do afastamento ou abandono deste membro daequipe, todas suas tarefas deverão ser redistribuídas e replanejadas.Responsável: Renan Reis6. Dispersão da equipe durante o projetoProbabilidade: 95% Impacto:MarginalDescrição: A dispersão dos membros da equipe está relacionada ao tempodisponível para se dedicar ao projeto, assim como o tempo possível para reuniões“cara a cara” e afins.Estratégia de redução: Distribuição das funções dos membros da equipe, de formaque cada papel específico possa gerar ao final de cada tarefa o status relacionado,criando assim controle sobre o andamento das tarefas.Plano de Contingência: Criar meios para interação assíncrona entre os integrantesda equipe, amenizando assim o impacto da dispersão.Responsável: Renan Reis 17
  19. 19. 7. Disponibilidade parcial do tempoProbabilidade: 90% Impacto:MarginalDescrição:O tempo disponível para dedicação do projeto é parcialmenteaproveitado, visto que nenhum dos integrantes possui tempo integral para dedicaçãoao mesmo.Estratégia de redução: Iniciar o planejamento de atividades da forma identificadacomo ideal para a divisão de tempo e aproveitamento da disponibilidade de cadaintegrante.Plano de Contingência: Criar meios em que a equipe possa trabalhar de formadessincronizada e em tempo disponível.Responsável: Katlen MaduroStatus: Risco ocorreu de fato. O Planejamento das atividades foram realizadas paraalguns membros da equipe. Várias tarefas foram afetadas por atrasos econsequentemente repassadas para outras Sprints.8. Utilização de tecnologias recentesProbabilidade: 45% Impacto:MarginalDescrição: Parte dos membros não possuía experiência nas ferramentas etecnologias utilizadasEstratégia de redução: Induzir os membros com menos experiência ao aprendizadodas tecnologias com outros membros que já possuem mais experiência.Plano de Contingência: Criar um programa de treinamento para a tecnologiasolicitada.Responsável: Marcos FelipeStatus: Risco ocorreu de fato. Alguns integrantes da equipe necessitaram de umtreinamento prévio nas tecnologias empregadas. 18
  20. 20. 4. Planejamento Temporal No Planejamento Temporal são definidas as datas de execução das tarefasassim como, os responsáveis por cada uma delas através do Diagrama de Gantt, o qualfoi elaborado em cada Sprint por determinado Scrum Master, dentro do projeto. 4.1 Conjunto de Tarefas do Projeto Aqui são apresentados o Modelo de Processo escolhido e as suas atividades etarefas que foram escolhidas para serem apresentadas nesta seção.Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados), oesforço estimado para a realização do projeto é de 192 dias trabalhados, demonstradosna tabela abaixo, divididos por fases que vão desde o planejamento até os testes.Fase Projeto Cálculo Dias TrabalhadosPlanejamento 20% 192X20% 38,4Análise requisitos 20% 192X20% 38,4Geração de Código 20% 192X20% 38,4Testes 40% 192X40% 76,8 TOTAL 192 19
  21. 21. 4.2 Diagrama de Gantt O diagrama de Gantt é um gráfico usado para ilustrar o avanço das diferentesetapas de um projeto. Os intervalos de tempo representando o início e fim de cada faseaparecem como barras coloridas sobre o eixo horizontal do gráfico. [2] Na seção de anexos, se encontra o diagrama de Gantt exibido em quatro etapas,representados pelas SPRINTS decorrentes. O diagrama foi gerado a partir das tarefasregistradas no redmine, sendo estes referentes às quatro Sprints, de acordo com asFiguras 1.6 e 1.5 em anexos, aonde são exibidos o diagrama e as tarefas,respectivamente. 20
  22. 22. 5. Organização do Pessoal A organização pessoal se baseou em encontros com a equipe, além decomunicação via e-mail, gtalk, dentre outros meios possíveis, para que o projetopudesse ocorrer em paralelo à outras atividades exercidas pelos membros da equipe. 5.1 Estrutura da equipe A equipe possui uma estrutura composta com 4 integrantes. O modelo Ágilexigirá reunião diária, a revisão das metas a cada final da sprint, analisando as tarefase atrasos em retrospectiva para aprimoramento das metas. Os papéis descritos são:Scrum Master, Developer1, Developer2 e Tester, sendo o ProductOwner o Prof Dr.Arilo Dias. A disposição dos integrantes, relacionados a seus respectivos papéis, sãomodificados a cada Sprint.Scrum Master O Scrum Master caracteriza-se como o responsável pelo incentivo à equipe, coma tarefa de remover possíveis impedimentos que influenciem na parte operacional, alémde ser o responsável pelo registro de determinadas atividades da Sprint. Vale ressaltarque o Scrum Master não é o líder da equipe, somenete exerce a função de apoio.Desenvolvedores Desenvolvedores são os membros com todas as habilidades necessárias paratransformar os requisitos do ProductOwner em um pedaço potencialmente distribuíveldo produto ao final da Sprint.ProductOwner O ProductOwner é a única pessoa responsável pelo gerenciamento do Backlogdo Produto e por garantir o valor do trabalho realizado pelo Time Scrum, garantindo queseja visível para todos da equipe. 21
  23. 23. Tester ou Testador O Tester faz a integração com a equipe de análise e desenvolvimentoprocurando entender as regras de negócio, arquitetura e funcionamento das atividadesno sistema para validar o sistema. 5.2 Mecanismos de comunicaçãoRedmine Redmine é um software livre e de código aberto para gerenciamento de projetos.Foi desenvolvido na linguagem Ruby utilizando framework Ruby on Rails. Redmine éuma ferramenta multi-plataforma que suporta vários bancos de dados, extensões deplugins e sistema de controle de versão. [3] Nele os documentos foram centrados para consulta da equipe por todos osenvolvidos e para acompanhamento de mudanças na documentação relacionado aoprojeto.E-mail e Chats Um meio importante para comunicação entre a equipe se baseou em e-mails echats, aonde 90% da iteração entre os integrantes foi efetuada.Aplicativos (Whatsapp) Outros meios que foram utilizados para comunicação, são aplicativos parasmartphones, com a criação de grupos nos mesmos. 22
  24. 24. 5.3 Uso do Edu-blog como ferramenta de apoio [1] A utilização do Edu-blog como ferramenta de apoio foi de grande valia paracomplementação dos trabalhos aqui desenvolvidos, assim como o mesmo agrega valoraos conhecimentos que são exibidos na ferramenta. Pelo fato da ferramenta ser multiplataforma, seu fácil entendimento em questãode navegabilidade e seu conteúdo formam uma rede de conhecimento de grande valiapara seus visitantes e utilizadores, assim como um guia eficaz para o assunto em que éproposto. Durante o processo de desenvolvimento da documentação relacionada aoprojeto, a ferramenta Edu-blog influenciou de maneira positiva, como um guia durante odesenvolvimento, assim constituindo de forma eficaz o processo como um todo. 23
  25. 25. 6. Precauções para assegurar e controlar a qualidade do produto Para assegurar a qualidade de produto, existe o processo de teste do mesmo,sendo este executado durante e ao final de cada Sprint, garantindo assim que osistema está funcionando de forma devida. Para saber se o sistema atende o requisitodo usuário, revisões a cada Sprint, juntamente com os envolvidos, são uma forma degarantir a qualidade e assegurar que o escopo é válido. 6.1 Seguimento e Controle do Projeto de Software É realizado um acompanhamento constante das atividades desenvolvidas porparte de todos os envolvidos no projeto e principalmente validação com o cliente. 6.2 Revisões Técnicas Formais As revisões são realizadas na etapa de Análise e Projeto, visando à identificaçãode erros nas fases iniciais do projeto, onde o custo para a manutenção é menor. 6.3 Produção de Documentação Para o controle de qualidade do processo de desenvolvimento, foi elaboradadocumentação nas etapas de Análise, Projeto e Teste em todo o processo de execuçãodo projeto. 24
  26. 26. 7.1 ANEXOS Figura 1.1 - Diagrama lógico do sistema SIGEM 25
  27. 27. Figura 1.2 - Modelo EER (Estendido) do sistema SIGEM 26
  28. 28. Figura 1.3 – Diagrama de classes do sistema SIGEM 27
  29. 29. Figura 1.4 - Tela visualização de equipamentos do sistema SIGEM 28
  30. 30. Figura 1.5 - Tarefas extraídas do redmine 29
  31. 31. Figura 1.6 - Diagrama de Gantt extraído do redmine 30
  32. 32. Referências[1] - Edu Blog- Informações à respeito da documentação. Disponível em: http://gp-ufam-2012.blogspot.com.br. Acesso em: 17 de mar. 2013.[2] - Redmine - Diagrama de Gantt e tarefas das Sprints. Disponível em:http://redmine.icomp.ufam.edu.br/projects/b/issues/gantt. Acesso em: 20 de mar. 2013.[3] - Viva o Linux – Informações sobre o Redmine. Disponível em:http://www.vivaolinux.com.br/artigo/Gerencia-de-projetos-com-Redmine/. Acesso em:14 de mar. 2013. 31

×