Este documento apresenta o plano de projeto de software para o desenvolvimento de um Sistema de Gerenciamento de Atividades Extracurriculares (SGAE) para a Universidade Federal do Amazonas. O plano descreve o escopo do projeto, as estimativas de tempo e recursos, a análise e gestão de riscos, o planejamento temporal, a organização da equipe e as precauções para garantir a qualidade do produto.

1. Plano de Projeto de Software
Para Produtos da Lacertae SW
Universidade Federal do Amazonas / Instituto de Computação
Lacertae Software S/A

2. Dados Gerais do Projeto
Nome
Sistema de Gerenciamento de Atividades Extracurriculares
Disciplina
Gerência de Projetos
Professor
Rogério P C do Nascimento, PhD
Alunos
 Bruna Schramm
 Janderson Borges
 Leonardo Felipe
 Thiago Santos

3. SUMÁRIO
ACRÔNIMOS E SIGLAS ..................................................................................................... 3
1.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 ........................................................................................ 6
2.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 .................................................................................................... 10
3.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 ......................................................................................... 13
4.0 PLANEJAMENTO TEMPORAL ........................................................................... 17
4.1 Conjunto de Tarefas do Projeto .................................................................................. 17
4.2 Diagrama de Gantt ...................................................................................................... 18
5.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............................................................................................... 20
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW ..................................................................................................... 21

4. 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

5. 1.0 INTRODUÇÃO
1.1 Âmbito do Projeto
Por meio deste projeto será desenvolvido o Sistema de Gerenciamento de Atividades
Extracurriculares (SGAE) que objetiva automatizar os processos de aproveitamento de
atividades complementares, inscrição e operacionalização de monitoria para o Instituto de
Computaçã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 a
documentação requerida para efetivação de todos os elementos envolvido, que são
frequências e relatório final.
Para a secretaria e coordenadores, o SGAE possibilitará a análise das solicitações de
aproveitamento e inscrições em monitorias, além de fornecer relatórios sobre atividade
complementares e monitorias.
Sendo assim, será possível trabalhar com a manipulação da documentação, além de
lidar com todo o processo relacionado a atividades extracurriculares, desde a entrada de
informações particulares, a cada tipo de atividade.
Exemplo disso será a construção e preparo das opções de aproveitamento de
atividade, tudo na forma como convir ao usuário.
O objetivo em si é a formulação de regras de aproveitamento, gerenciamento dos
modelos de atividades. Bem como empregar essas atividades estanciadas durante o processo
de 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 e
manter o sistema bem como a alimentação de dados. O perfil Secretaria diz respeito ao ator
do sistema que irá analisar as solicitaçãoes de atividades complementares e terá acesso a
históricos de atividades complementares. O perfil Coordenador de Curso diz respeito ao ator
do sistema que analisará solicitações de atividades complementares e manterá as monitorias
oferecidas 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 por
analisar 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 de
atividades complementares e realizar inscrição nas monitorias ofertadas.
A listagem de funcionalidades abrangidas pelo sistema é apresentada na Tabela 1.
4

6. 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ária
Coordenador de Curso Análise das solicitações de atividades complementares
Coordenador de Curso e Histórico das atividades complementares realizadas por um
Secretaria aluno
Coordenador de Curso e Histórico das atividades complementares solicitadas por
Secretaria período
Coordenador de Curso Gerenciamento de Monitoria
Coordenador de Curso e Histórico das monitorias realizadas por um aluno
Secretaria
Coordenador Acadêmico Análise de cadastro de monitorias
Coordenador Acadêmico Análise das inscrições em monitorias
Coordenador Acadêmico Análise final das monitorias
Coordenador Acadêmico Histórico das monitorias realizadas por um aluno
Coordenador 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

7. 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 acessos
simultâ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 pontos
também base para os requisitos comportamentais.
REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE
Usabilidade 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

8. ● 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

9. 2.0 ESTIMATIVAS DO PROJETO
Nesta seção será demonstrado como efetuar o cálculo para encontrar o tempo total
de duração do projeto. Para encontrar esse tempo é necessário aplicar uma técnica de
estimativas e neste caso utilizaremos a métrica de Lorenz & Kidd, aconselhada pela Lacertae
Software.
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 dos
seguintes 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

10. 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 de
dias trabalhados real de 86 dias, observa-se que o projeto foi realizado dentro do prazo
estimado previamente.
Ajustando a quantidade de dias-pessoas para 15 (previamente definido como 17 no
passo 5), o esforço estimado será de 480 dias de trabalho, que divido entre os 4 membros da
equipe (480 dias de trabalho / 4 membros da equipe) resulta em 120 dias de trabalho por
pessoa. Dessa forma, a estimativa do esforço necessário fica mais próxima, porém ainda com
certa 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 Trabalho
Planejamento 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 realizadas
em uma quantidade de dias menor do que foi estimado. Isso de deve ao fato de que várias
atividades 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 do
projeto, é possível observar que as etapas de Planejamento e Análise e Projeto se
aproximaram bastante da estimativa. Por outro o esforço gasto nas etapas de Codificação e
9

11. Testes diferiu bastante da estimativa. As etapas de Codificação e Testes se equipararam pelo
fato 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éis
Sprints 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 Leonardo Felipe
Santos
4ª 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

12. ● 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 equipe
3 Recursos de Hardware
Computador para desenvolvimento:
Processador: Core 2 Duo ou superior.
Memória RAM: 4 Gb de RAM.
HD: 120 Gb ou superior.
11

13. 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 de
desenvolvimento do mesmo. Não foram considerados custos referentes a impactos financeiros
dos 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ão
1 aceitar um framework de Sprint #1 Implantação Alta Catastrófico
desenvolvimento diferente do
Grails
Desconhecimento das
ferramentas de
2 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 das
3 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 resultar
4 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 de
5 Sprint #1 Técnico Alta Alto
casos de uso extensa e
trabalhosa, que consumirá
muito tempo do sprint
6 Alternância entre atividades de Sprint #1 Técnico Médio Médio
prototipação e
12

14. 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 os
riscos de maior impacto no projeto, planos de contingência. O acompanhamento foi feito com
base 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

15. 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.O
1 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 de
2 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 Scrum
3 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 Scrum
4 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
Scrum
5 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

16. 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 de
contigê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 de
6 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 ocorrendo
7 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 paralelamente
8 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 planilha
9 constantes falhas no mesmo, Eliminar de acompanhamento das atividades,
impactar no gerenciamento do facilitando o controle do ScrumMaster
projeto.
15

17. Falta de contato com membros Eliminar Criar Matriz de Comunicação com as
da equipe resultar em problemas informações de contato da equipe
10
de acompanhamento das
atividades
Outras disciplinas exigirem Aceitar
11 tempo adicional não previsto nos
planejamentos dos sprints.
16

18. 4.0 PLANEJAMENTO TEMPORAL
Nesta sessão serão apresentadas as tarefas realizadas no projeto e o planejamento
temporal das mesmas por meio do Diagrama de Gantt, onde será definido as datas de início e
fim e o responsável por cada tarefa.
4.1 Conjunto de Tarefas do Projeto
Todas as atividades deste projeto, bem como o planejamento das mesmas
transcorrerá 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 desenvolvido
a cada entrega. Para isso dividiremos o prazo de desenvolvimento em 4 marcos principais que
chamaremos 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 se
deve 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, eventuais
encontros com o cliente acontecerão no decorrer do desenvolvimentos sempre que ambas as
partes precisarem.
Desenvolvimento: após termos definido o escopo do projeto, o planejamento
do desenvolvimento acontecerá a cada interação.
Com a equipe reunida (desenvolvedores, testadores e scrum master), serão
analisados os objetivos tangíveis para que se possa ter uma entrega bem concluída. Esta
reunião deve mostrar a direção que o projeto tomará na sprint em questão. De forma
concreta, deve-se formar o product backlog de desenvolvimento para esta sprint.
Aqui também devem ser definidos os prazos, esforço estimado, tudo o que
possa auxiliar no acompanhamento real do desenvolvimento.
Product Owner: Reuniões com o PO deverão ser feitas eventualmente para
que se possa ter um acompanhamento e validação do produto.
Análise e Projeto
Refinamento de Requisitos: Neste ponto analisaremos os requisitos mais a
fundo 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 uma
lista mais resumida para o desenvolvimento, e minunciosa para as atividades
17

19. 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 de
protó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 e
planejado em prática. Assim como as outras, ocorrerá a cada sprint.
É imprescindível que o planejamento seja bem executado, pois o esforço
adicionado a codificação deve ser somente direcionado a resolução dos problemas
algorí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 atividades
necessárias para execução do projeto.
No diagrama são descritos os atributos nome , percentual de conclusão, a duração
estimadas em dias, a data de início e término, nome do responsável e o código da atividade
predecessora sobre cada atividade planejada.
18

20. 5.0 ORGANIZAÇÃO DO PESSOAL
Nesta seção será demonstrado como será a organização da equipe a cada Sprint
durante 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 equipe
de 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 envolve
conduzir 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ção
diária de reuniões, por onde pode ser feito o acompanhamento do andamento das tarefas
individuas 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ão
feitos os comunicados para toda a equipe.
Como mecanismo de monitoração do avanço do projeto, é utilizada a ferramenta
Redmine, pela qual é feito o gerenciamento das atividades do projeto, envolvendo as
atividades de desenvolvimento, testes e defeitos. Por meio dela é possível verificar o
andamento de todas as atividades do projeto. Também é utilizado para manter o registro das
reuniões diárias realizadas pela equipe.
19

21. 5.3 Uso do Edu-blog como ferramenta de apoio
O conhecimento sobre a Gerência de Projetos é de suma importância para o sucesso
ou o fracasso dos projetos de software.
O Edu-blog foi uma experiência nova para as nossas vidas acadêmicas. Podemos tirar
bastante proveito dos tópicos que foram apresentados durante o decorrer da disciplina. A
linguagem clara e objetiva são pontos que merecem destaque no blog.
Ficamos muito contentes de termos a oportunidade de experimentar esta didática e
mais contente ainda por termos um blog que nos auxilia no aprendizado da Gerência de
Projetos.
5.4 Matriz de Comunicação
20

22. 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 seguintes
atividades:
● 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