Plano de Projeto de Software
Upcoming SlideShare
Loading in...5
×
 

Plano de Projeto de Software

on

  • 484 views

 

Statistics

Views

Total Views
484
Views on SlideShare
395
Embed Views
89

Actions

Likes
0
Downloads
11
Comments
0

2 Embeds 89

http://thestruct.blogspot.com.br 87
http://thestruct.blogspot.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Plano de Projeto de Software Plano de Projeto de Software Document Transcript

  • Plano de Projeto de Software Para Produtos da Lacertae SW Universidade Federal do Amazonas / Instituto de Computação Lacertae Software S/A
  • Dados Gerais do ProjetoNomeSistema de Gerenciamento de Atividades ExtracurricularesDisciplinaGerência de ProjetosProfessorRogério P C do Nascimento, PhDAlunos  Bruna Schramm  Janderson Borges  Leonardo Felipe  Thiago Santos
  • SUMÁRIOACRÔNIMOS E SIGLAS ..................................................................................................... 31.0 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 ........................................................ 6 1.4 Gestão e Restrições Técnicas ........................................................................................ 62.0 ESTIMATIVAS DO PROJETO ............................................................................... 8 2.1 Dados históricos utilizados para as estimativas do projeto .......................................... 8 2.2 Técnicas de estimação e resultados .............................................................................. 8 2.3 - Resultados Obtidos ..................................................................................................... 8 2.4 Recursos do Projeto .................................................................................................... 103.0 ANÁLISE E GESTÃO DE RISCOS ......................................................................... 12 3.1 Riscos do projecto ....................................................................................................... 12 3.2 Tabela de riscos ........................................................................................................... 12 3.3 Redução e Gestão do Risco ......................................................................................... 134.0 PLANEJAMENTO TEMPORAL ........................................................................... 17 4.1 Conjunto de Tarefas do Projeto .................................................................................. 17 4.2 Diagrama de Gantt ...................................................................................................... 185.0 ORGANIZAÇÃO DO PESSOAL ........................................................................... 19 5.1 Estrutura da equipe ..................................................................................................... 19 5.2 Mecanismos de comunicação ..................................................................................... 19 5.3 Uso do Edu-blog como ferramenta de apoio .............................................................. 20 5.4 Matriz de Comunicação............................................................................................... 206.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DOPRODUTO DE SW ..................................................................................................... 21
  • Acrônimos e siglas SCRUM - Processo de desenvolvimento evolutivo e iterativo para construção de produtos de software SCRUM Master - Líder de projeto P.O. ou Product Owner - Representante do cliente Sprint - Iteração de projeto Edu-blog - Blog proposto pelo professor e utilizado na disciplina para discursões sobre o conteúdo da mesma PBI - Product Backlog Item (Item do backlog do produto/ Funcionalidade) 3
  • 1.0 INTRODUÇÃO 1.1 Âmbito do Projeto Por meio deste projeto será desenvolvido o Sistema de Gerenciamento de AtividadesExtracurriculares (SGAE) que objetiva automatizar os processos de aproveitamento deatividades complementares, inscrição e operacionalização de monitoria para o Instituto deComputação da Universidade Federal do Amazonas. O SGAE permitirá ao aluno solicitar aproveitamento em atividades complementares,visualizar a avaliação sobre estas solicitações, inscrever-se em monitorias e enviar adocumentação requerida para efetivação de todos os elementos envolvido, que sãofrequências e relatório final. Para a secretaria e coordenadores, o SGAE possibilitará a análise das solicitações deaproveitamento e inscrições em monitorias, além de fornecer relatórios sobre atividadecomplementares e monitorias. Sendo assim, será possível trabalhar com a manipulação da documentação, além delidar com todo o processo relacionado a atividades extracurriculares, desde a entrada deinformações particulares, a cada tipo de atividade. Exemplo disso será a construção e preparo das opções de aproveitamento deatividade, tudo na forma como convir ao usuário. O objetivo em si é a formulação de regras de aproveitamento, gerenciamento dosmodelos de atividades. Bem como empregar essas atividades estanciadas durante o processode solicitações. 1.2 Funções principais do produto de software O SGAE envolverá a participação de cinco perfis de usuários, são eles Administrador,Coordenador de Curso, Coordenador Acadêmico, Aluno e Secretaria. O perfil de Administrador diz respeito ao ator do sistema responsável por configurar emanter o sistema bem como a alimentação de dados. O perfil Secretaria diz respeito ao atordo sistema que irá analisar as solicitaçãoes de atividades complementares e terá acesso ahistóricos de atividades complementares. O perfil Coordenador de Curso diz respeito ao atordo sistema que analisará solicitações de atividades complementares e manterá as monitoriasoferecidas por período, além de históricos de monitorias e atividades complementares. O perfil Coordenador Acadêmico diz respeito ao ator do sistema responsável poranalisar os cadastros, inscrições e fechamento de monitorias, além de históricos de monitoria.O perfil Aluno diz respeito ao ator do sistema responsável por solicitar aproveitamento deatividades complementares e realizar inscrição nas monitorias ofertadas. A listagem de funcionalidades abrangidas pelo sistema é apresentada na Tabela 1. 4
  • PERFIL DO USUÁRIO FUNCIONALIDADES Administrador Gerenciamento de Curso Administrador Gerenciamento de Grupo Administrador Gerenciamento de Atividade Complementar Administrador Gerenciamento de Disciplina Administrador Gerenciamento de Coordenador de Curso Administrador Gerenciamento de Coordenador Acadêmico Administrador Gerenciamento de Aluno Administrador Gerenciamento de Professor Administrador Gerenciamento de SecretáriaCoordenador de Curso Análise das solicitações de atividades complementaresCoordenador de Curso e Histórico das atividades complementares realizadas por um Secretaria alunoCoordenador de Curso e Histórico das atividades complementares solicitadas por Secretaria períodoCoordenador de Curso Gerenciamento de MonitoriaCoordenador de Curso e Histórico das monitorias realizadas por um aluno SecretariaCoordenador Acadêmico Análise de cadastro de monitoriasCoordenador Acadêmico Análise das inscrições em monitoriasCoordenador Acadêmico Análise final das monitoriasCoordenador Acadêmico Histórico das monitorias realizadas por um alunoCoordenador Acadêmico Histórico de monitorias Aluno Solicitar atividade complementar Aluno Histórico das atividades complementares realizadas Aluno Gerenciamento das inscrições em monitoria 5
  • Aluno Envio das documentações da monitoria Aluno Histórico das monitorias realizadas Secretaria Análise das solicitações de atividades complementares Secretaria Histórico de monitorias Tabela 1 - Lista de Funcionalidades do Sistema 1.3 Requisitos comportamentais ou de performance Os requisitos foram pensados visando a disponibilidade, tanto nos múltiplos acessossimultâneos, quanto a liberdade de horário para acesso. Além disso, em se tratando de um sistema que tratará de diversas tarefas, éfundamental que se objetive a praticidade e facilidade de uso, sendo estes dois pontostambém base para os requisitos comportamentais. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCEUsabilidade O usuário não deverá precisar de mais de 3 clicks para acessar a funcionalidade ou informação que procura.Desempenho O sistema não deverá demorar mais de 3 segundos para processar informações, independente da operação.Disponibilidade O sistema deverá estar disponível 24 horas por dia, 7 dias por semana. Nos horários de 06:00 as 22:00 deve estar funcionando pelo menos 99,95% do tempo.Tipo de interface O sistema será para web acessado via browser HTTP/HTML.Volume de utilização O sistema deverá suportar uma carga máxima de 10000 usuários simultâneos com degradação de desempenho de, no máximo, 20% em qualquer operação. Tabela 2 - REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE 1.4 Gestão e Restrições Técnicas Os aspectos e restrições técnicas que afetarão o projeto são:Aspectos ● A equipe não possui experiência com desenvolvimento para a plataforma web. ● A equipe não possui experiência com o framework que será utilizado. 6
  • ● A equipe não possui experiência com a ferramenta para controle do projeto e metodologia utilizados.Restrições Técnicas: ● A cada sprint apenas dois membros da equipe poderão desenvolver. ● Cada sprint possui um prazo definido de três semanas. ● O sistema deverá se implementado para a plataforma web. ● O projeto será desenvolvido por meio da metodologia de desenvolvimento ágil Scrum. ● O sistema será desenvolvido utilizando a linguagem de programação Java, através do framework de desenvolvimento Vraptor. ● Para o gerenciamento de projeto será utilizada a ferramenta Redmine. 7
  • 2.0 ESTIMATIVAS DO PROJETO Nesta seção será demonstrado como efetuar o cálculo para encontrar o tempo totalde duração do projeto. Para encontrar esse tempo é necessário aplicar uma técnica deestimativas e neste caso utilizaremos a métrica de Lorenz & Kidd, aconselhada pela LacertaeSoftware. 2.1 Dados históricos utilizados para as estimativas do projeto Não possuímos dados históricos para relatar. 2.2 Técnicas de estimação e resultados Para estimar a duração total deste projeto foi utilizada a métrica de projeto Lorenz&Kidd. É uma métrica orientada a classes, utilizada pela Lacertae Software. Consiste dosseguintes passos: 1. Definir o número de classes chave do projeto. 2. Encontrar o número de classes de suporte, classificar o tipo de interface do produto e desenvolver um multiplicador para as classes de suporte (definidos na Tabela 3). 3. Multiplicar a quantidade de classes-chave pelo multiplicador para obter o número de classes de suporte. 4. Calcular a quantidade total de classes, que será: total de classes-chave + total de classes de suporte. 5. Multiplicar a quantidade total de classes pelo número médio de unidades de trabalho (dias-pessoa). 6. Determinar a quantidade de esforço estimada. 7. Cálculo do tempo previsto para a realização do projeto Interface Valor Multiplicador Interface Valor multiplicador não gráfica 2 Baseada em texto 2,25 GUI 2,5 GUI Complexa 3 Tabela 3 - Fatores de Multiplicação 2.3 - Resultados Obtidos Por meio da aplicação da métrica, os seguintes resultados foram obtidos: 1 Número de classes-chave = 8 2 O sistema utilizará interface GUI complexa, então fator multiplicador é 3.0. 8
  • 3 Classes de suporte = classes-chave x fator multiplicador = 8 x 3 = 24. 4 Total de classes do projeto = classes-chave + classes de suporte = 8 + 24 = 32. 5 O número médio de unidades de trabalho (dias-pessoa) por classe, levando em consideração a sugestão da métrica Lorenz & Kidd foi de 17 dias-pessoa. Foi levado em consideração que a equipe já possuía certa experiência com linguagem de programação utilizada e a falta de conhecimento com programação web. 6 O esforço estimado = 32 x 17 = 544 dias de trabalho. 7 Considerando 4 membros na equipe, então por pessoa serão (total de dias / nº de membros) 544 / 4 = 136 dias por pessoa. Fazendo a comparação com o esforço real gasto no projeto, a partir da quantidade dedias trabalhados real de 86 dias, observa-se que o projeto foi realizado dentro do prazoestimado previamente. Ajustando a quantidade de dias-pessoas para 15 (previamente definido como 17 nopasso 5), o esforço estimado será de 480 dias de trabalho, que divido entre os 4 membros daequipe (480 dias de trabalho / 4 membros da equipe) resulta em 120 dias de trabalho porpessoa. Dessa forma, a estimativa do esforço necessário fica mais próxima, porém ainda comcerta margem de distancia, do tempo real gasto. O esforço total do projeto (544 dias de trabalho) será distribuído da seguinte maneira: Estimado Real Esforço do Dias de Esforço do Dias de Fase Cálculo Projeto Trabalho Projeto TrabalhoPlanejamento 3% 544 x 3% 16,32 2,26% 4 Análise e 20% 544 x 20% 108,8 22,66% 40 Projeto Codificação 60% 544 x 60% 326,4 35,69% 63 Testes 17% 544 x 17% 92,48 39,69% 69,5 Tabela 4 - Divisão do esforço estimado e real do projeto A partir da tabela 4, observa-se que as estimativas todas as etapas foram realizadasem uma quantidade de dias menor do que foi estimado. Isso de deve ao fato de que váriasatividades de cada etapa terem sido realizadas paralelamente pelos membros da equipe,principalmente as atividades envolvidas nas etapas de Análise e Projeto e de Codificação. Então analisando com base na porcentagem do esforço gasto em cada etapa doprojeto, é possível observar que as etapas de Planejamento e Análise e Projeto seaproximaram bastante da estimativa. Por outro o esforço gasto nas etapas de Codificação e 9
  • Testes diferiu bastante da estimativa. As etapas de Codificação e Testes se equipararam pelofato da etapa de Testes ter envolvido os custos do retrabalho. 2.4 Recursos do Projeto 1 Recursos Humanos O projeto contará com quatro integrantes, que exercerão diversos papéis necessários à execução do projeto. Os responsáveis pelos papéis a cada Sprint são apresentados na tabela a seguir: PapéisSprints Scrum Master Desenvolvedor 1 Testador Desenvolvedor 21ª Sprint Thiago Santos Leonardo Felipe Bruna Janderson Borges Schramm2ª Sprint Leonardo Felipe Bruna Schramm Janderson Thiago Santos Borges3ª Sprint Bruna Schramm Janderson Borges Thiago Leonardo Felipe Santos4ª Sprint Janderson Thiago Santos Leonardo Bruna Schramm Borges Felipe 2 Recursos de Software Serão necessários para o projeto os seguintes softwares: ● PostgreSQL – Sistema para gerenciamento do banco de dados usado na composição do produto final; ● Apache Tomcat - Servidor de aplicações JavaEE. ● Java – Linguagem de programação a ser utilizada para o desenvolvimento do produto de software final. ● Vraptor 3 – Framework MVC web para desenvolvimento Java, utilizado para o desenvolvimento do produto de software final. ● Hibernate – Framework para o mapeamento objeto-relacional, utilizado para o desenvolvimento do produto de software final. ● Java Persistence API 2 - API padrão do Java para persistência que deve ser implementada pelo Hibernate, utilizada para o desenvolvimento do produto de software final. ● Pencil Projects – Ferramenta para prototipagem das interfaces gráficas do sistema baseada nas User Stories (estórias). ● NetBeans IDE – Ambiente de desenvolvimento integrado (IDE) para desenvolvimento de software na linguagem Java, utilizada para o desenvolvimento do produto de software final. 10
  • ● Microsoft Office – Editor de texto, planilhas e apresentações usado na documentação, reports e afins.● Redmine – Ferramenta para gerenciamento do projeto que servirá de base para gestão atualizada e confiável do projeto do produto.● Subversion – Software para versionamento dos artefatos do projeto.● Gmail – Sistema de e-mail utilizado para comunicação da equipe3 Recursos de HardwareComputador para desenvolvimento:Processador: Core 2 Duo ou superior.Memória RAM: 4 Gb de RAM.HD: 120 Gb ou superior. 11
  • 3.0 ANÁLISE E GESTÃO DE RISCOS 3.1 Riscos do projecto Os riscos descritos têm impacto de cronograma, geralmente verificados na fase dedesenvolvimento do mesmo. Não foram considerados custos referentes a impactos financeirosdos riscos. 3.2 Tabela de riscos# Descrição do Risco Fase ID Categoria Probabilidade Impacto Não utilização do sistema pela equipe do CPD, por esta não1 aceitar um framework de Sprint #1 Implantação Alta Catastrófico desenvolvimento diferente do Grails Desconhecimento das ferramentas de2 desenvolvimento Impactar Sprint #1 Técnico Ocorreu Muito Alto negativamente no tempo de desenvolvimento do projeto. Falta de experiência em análise prejudicar o entendimento das3 regras de negócio e gerar Sprint #1 Técnico Alta Alto defeitos na documentação do projeto. Distância geográfica dos integrantes da equipe resultar4 Sprint #1 Projeto Ocorreu Alto em impossibilidade de realização de reuniões diárias Excesso de Complexidade de algumas funções do sistema resultar em documentação de5 Sprint #1 Técnico Alta Alto casos de uso extensa e trabalhosa, que consumirá muito tempo do sprint6 Alternância entre atividades de Sprint #1 Técnico Médio Médio prototipação e 12
  • desenvolvimento resultar em baixo foco e motivação dos desenvolvedores para fazer documentação de qualidade. Atuais falhas no sistema de controle de versionamento da ufam, continuarem ocorrendo 7 Sprint #2 Técnico Ocorreu Médio durante os sprints, impossibilitando o acesso ao repositório. Falta de acesso ao sistema de gestão RedMine, da ufam, por 8 constantes falhas no mesmo, Sprint #3 Técnico Ocorreu Médio impactar no gerenciamento do projeto. Impacto de tempo nos sprints ocasionado pela fase de testes, 9 geralmente com equipe ociosa Sprint #2 Técnico Alta Médio e alta carga de trabalho concentrada no testador. Falta de contato com membros Sprint #4 Projeto Ocorreu Médio da equipe resultar em 10 problemas de acompanhamento das atividades Outras disciplinas exigirem Sprint #4 Projeto Ocorreu Médio 11 tempo adicional não previsto no planejamento dos sprints. 3.3 Redução e Gestão do Risco A redução de riscos consistiu na implantação de estratégias de redução e, para osriscos de maior impacto no projeto, planos de contingência. O acompanhamento foi feito combase nos dados de projeto ao final de cada sprint, durante a reunião de lições aprendidas.Para os itens mais críticos, com classificação de impacto “Catastrófico”, “Muito alto” ou “Alto”,foram formuladas as seguintes estratégias de redução e planos de contingência: # Descrição Ação Estratégia de Plano de Contingência Resp. 13
  • Redução O Product Owner Não utilização do sistema O Product Owner tentará convencer a pela equipe do CPD, por ficará responsável equipe do CPD da esta não aceitar um Transfer P.O1 por resolver este utilização do sistema, e framework de ir (Arilo) problema junto à arcará com o impacto desenvolvimento diferente equipe do CPD. resultante da ocorrência do Grails do risco. A equipe se O membro mais comprometeu a Desconhecimento das experiente da equipe, estudar a ferramentas de Thiago, ficou arquitetura e desenvolvimento Impactar encarregado de2 Mitigar padronizações do Thiago negativamente no tempo executar treinamentos e sistema e as de desenvolvimento do adotar desenvolvimento linguagens e projeto. XP com os membros em técnicas dificuldade. envolvidas. A documentação do sprint será detalhada pela equipe de Falta de experiência em desenvolvimento Dividir o sprint em 3 análise prejudicar o com o apoio do entregas menores, com entendimento das regras restante da aprovação do cliente em Scrum3 Mitigar de negócio e gerar equipe, com relação aos requisitos Master defeitos na documentação discussão ampla em cada uma dessas do projeto. de todos os entregas envolvidos. Recorrendo ao P.O nas dúvidas persistentes. Distância geográfica dos integrantes da equipe Serão realizadas Marcar Reuniões de resultar em reuniões por Emergência no horário Scrum4 Mitigar impossibilidade de teleconferência da disciplina, conforme Master realização de reuniões utilizando Gtalk acertado com o P.O diárias Excesso de Complexidade Foi feito um Scrum5 de certa funções do Eliminar acordo com o P.O sistema resultar em para que a Master documentação de casos de documentação 14
  • uso extensa e trabalhosa, não fosse feita que consumirá muito usando tempo do sprint detalhamento de casos de uso, mas prototipação de telas apoiada, somente quando necessário, por diagramas de atividade e estados.Para os riscos com classificação de impacto “Baixa” ou “Média” não foram feitos planos decontigência. Para estes, contudo, foram planejadas as seguintes estratégias de redução:# Descrição do Risco Estratégia Descrição da Estratégia de Redução Alternância entre atividades de A prototipação das telas da iteração será feita prototipação e desenvolvimento em sua reunião inicial de planejamento, pela resultar em baixo foco e equipe, ficando apenas atividades de6 Mitigar motivação dos desenvolvedores desenvolvimento para o sprint. Isso também para fazer documentação de permitirá que o planejamento dos testes qualidade. inicie imediatamente após esta reunião. Atuais falhas no sistema de controle de versionamento da Utilização de um servidor svn alternativo. ufam, continuarem ocorrendo7 Eliminar Será utilizado o serviço xp-dev, gratuito e com durante os sprints, acesso privado. impossibilitando o acesso ao repositório. Impacto de tempo nos sprints O planejamento e casos de testes para as ocasionado pela fase de testes, histórias do sprint, ocorrerão paralelamente8 geralmente com equipe ociosa e Eliminar ao desenvolvimento, pela documentação. Na alta carga de trabalho fase de testes, será realizada a identificação e concentrada no testador. correção de defeitos. Falta de acesso ao sistema de gestão RedMine, da ufam, por Utilização, no próximo sprint, de uma planilha9 constantes falhas no mesmo, Eliminar de acompanhamento das atividades, impactar no gerenciamento do facilitando o controle do ScrumMaster projeto. 15
  • Falta de contato com membros Eliminar Criar Matriz de Comunicação com as da equipe resultar em problemas informações de contato da equipe10 de acompanhamento das atividades Outras disciplinas exigirem Aceitar11 tempo adicional não previsto nos planejamentos dos sprints. 16
  • 4.0 PLANEJAMENTO TEMPORAL Nesta sessão serão apresentadas as tarefas realizadas no projeto e o planejamentotemporal das mesmas por meio do Diagrama de Gantt, onde será definido as datas de início efim e o responsável por cada tarefa. 4.1 Conjunto de Tarefas do Projeto Todas as atividades deste projeto, bem como o planejamento das mesmastranscorrerá com base na metodologia de desenvolvimento ágil SCRUM. Partindo destes princípios, a equipe trabalhará em cima do seguinte processo:Entregas parciais e incrementais, visando sempre ter partes conluídas do sistema desenvolvidoa cada entrega. Para isso dividiremos o prazo de desenvolvimento em 4 marcos principais quechamaremos sprint, onde repetiremos cada uma das fases - Planejamento, Análise,Codificação e Testes. Planejamento: Âmbito: Uma primeira reunião será feita com o cliente para definir o que sedeve construir e então ter domínio do problema. A equipe buscará o cliente para que possa ser definido o escopo do sistema,bem como a lista inicia do Product Backlog. Concluída esta primeira reunião, eventuaisencontros com o cliente acontecerão no decorrer do desenvolvimentos sempre que ambas aspartes precisarem. Desenvolvimento: após termos definido o escopo do projeto, o planejamentodo desenvolvimento acontecerá a cada interação. Com a equipe reunida (desenvolvedores, testadores e scrum master), serãoanalisados os objetivos tangíveis para que se possa ter uma entrega bem concluída. Estareunião deve mostrar a direção que o projeto tomará na sprint em questão. De formaconcreta, deve-se formar o product backlog de desenvolvimento para esta sprint. Aqui também devem ser definidos os prazos, esforço estimado, tudo o quepossa auxiliar no acompanhamento real do desenvolvimento. Product Owner: Reuniões com o PO deverão ser feitas eventualmente paraque se possa ter um acompanhamento e validação do produto. Análise e Projeto Refinamento de Requisitos: Neste ponto analisaremos os requisitos mais afundo buscando filtrar a informação e modularizar a cada sprint o que será desenvolvido. Uma vez que o Product Backlog geral já esta definido, penas definiremos umalista mais resumida para o desenvolvimento, e minunciosa para as atividades 17
  • Prototipação: Em seguida, tendo definido o atual foco do desenvolvimento,poremos no papel de forma visual o que será a base para a codificação - a criação deprotótipos. A prototipagem será a base e norte do desenvolvimento, deverá levar em consideração as regras de negócio definidas, pontos de usabilidade, e qualquer informação útil aos desenvolvedores. Estes terão a liberdade de modificar o desenho dos protótipo, porém sempre deverão reportar as mudanças e assinalá-las no versionador. Codificação: Construção: Esta fase será o momento de por tudo o que foi analisado eplanejado em prática. Assim como as outras, ocorrerá a cada sprint. É imprescindível que o planejamento seja bem executado, pois o esforçoadicionado a codificação deve ser somente direcionado a resolução dos problemasalgorítimicos. Partindo de que parte da arquitetura será feita no planejamento, a codificação deverá seguir a documentação feita naquela fase. Faremos uso de prototipação inicial e então inciar a construção do software. Testes: Paralelismo: Além dos ciclos de testes que refletem as sprints, essa atividade deverá seguir como atividade guarda-chuva por todo o desenvolvimento. Os testes acompanharão cada mini realise para que se tenha garantia da qualidade. Além do planejamento inicial de cada sprint, os testes em si serão planejados a cada nova bateria de testes, sendo este o processo: planejamento dos testes, execução, report, verificação de correção. Apartir daí, se necessário, reinicia o processo para os módulos testados ou se inicia uma nova bateria de testes para novos módulos. 4.2 Diagrama de Gantt O Diagrama de gantt (em anexo ao plano de projeto) demonstra as atividadesnecessárias para execução do projeto. No diagrama são descritos os atributos nome , percentual de conclusão, a duraçãoestimadas em dias, a data de início e término, nome do responsável e o código da atividadepredecessora sobre cada atividade planejada. 18
  • 5.0 ORGANIZAÇÃO DO PESSOAL Nesta seção será demonstrado como será a organização da equipe a cada Sprintdurante o projeto e os mecanismos para comunicação dos seus integrantes. 5.1 Estrutura da equipe Teremos os seguintes papéis: Scrum Master é responsável pela remoção de impedimentos à capacidade da equipede entregar o objetivo da sprint. A equipe de desenvolvimento é responsável pela entrega do produto. A equipe serácomposta de 2 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar,projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) O Testador é responsável pelas atividades centrais do esforço de teste, que envolveconduzir os testes necessários e registrar os resultados desses testes. As sprints terão as seguintes formações: Sprint X Papéis Scrum Master Desenvolvedor 1 Testador Desenvolvedor 2 1ª Sprint Thiago Santos Leonardo Felipe Bruna Janderson Borges Schramm 2ª Sprint Leonardo Felipe Bruna Schramm Janderson Thiago Santos Borges 3ª Sprint Bruna Schramm Janderson Borges Thiago Santos Leonardo Felipe 4ª Sprint Janderson Thiago Santos Leonardo Bruna Schramm Borges Felipe 5.2 Mecanismos de comunicação Como mecanismos de comunicação a equipe utiliza o Google Talk para a realizaçãodiária de reuniões, por onde pode ser feito o acompanhamento do andamento das tarefasindividuas projeto e ocorre a comunicação constante entre os membros da equipe. E por e-mails, por onde informações importantes a respeito do projeto são repassadas e por onde sãofeitos os comunicados para toda a equipe. Como mecanismo de monitoração do avanço do projeto, é utilizada a ferramentaRedmine, pela qual é feito o gerenciamento das atividades do projeto, envolvendo asatividades de desenvolvimento, testes e defeitos. Por meio dela é possível verificar oandamento de todas as atividades do projeto. Também é utilizado para manter o registro dasreuniões diárias realizadas pela equipe. 19
  • 5.3 Uso do Edu-blog como ferramenta de apoio O conhecimento sobre a Gerência de Projetos é de suma importância para o sucessoou o fracasso dos projetos de software. O Edu-blog foi uma experiência nova para as nossas vidas acadêmicas. Podemos tirarbastante proveito dos tópicos que foram apresentados durante o decorrer da disciplina. Alinguagem clara e objetiva são pontos que merecem destaque no blog. Ficamos muito contentes de termos a oportunidade de experimentar esta didática emais contente ainda por termos um blog que nos auxilia no aprendizado da Gerência deProjetos. 5.4 Matriz de Comunicação 20
  • 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW Para assegurar e controlar a qualidade do produto, foram realizadas as seguintesatividades: ● Testes: a atividade de testes foi realizada paralelamente à atividade de desenvolvimento, com o objetivo de analisar constantemente os produtos parciais desenvolvidos e identificar rapidamente defeitos no código, para que a correção fosse realizada antes que o defeito se propagasse e que os mesmos erros não fossem repetidos no desenvolvimento dos novos itens. ● Reuniões diárias: por meio das reuniões diárias realizadas pela equipe, foi possível esclarecer dúvidas a respeito do projeto, dessa forma pequenos desvios de má interpretação eram rapidamente corrigidos, e comunicar rapidamente problemas detectados nele, como por exemplo, omissão de itens importantes, dessa forma ações para solucionar o problema eram discutidas rapidamente por toda a equipe. ● Elaboração de documentação: para o controle do projeto foi elaborada a documentação nas fases de análise, projeto e testes. 21