Este documento apresenta o plano de projeto de software para o desenvolvimento de um sistema chamado PIC Eletrônico na Universidade Federal do Amazonas. O sistema tem como objetivo dar suporte ao Plano Institucional de Capacitação da universidade e abrangerá três das quatro etapas do processo de PIC. O documento descreve o escopo do projeto, os requisitos, as restrições técnicas, a estimativa de tempo de desenvolvimento utilizando a métrica de Lorenz & Kidd, e os recursos humanos, de software e hardware necessários.

1. PLANO DO PROJETO DE SOFTWARE OO
para produtos da Lacertae SW
1.0 INTRODUÇÃO
1.1 Âmbito do Projeto
Este projeto de software aborda um sistema que está sendo
desenvolvido pelos graduandos Alison Garantizado, Janiel Medeiros,
Kirmayr Costa e Urique Hoffmann do curso de Sistemas de Informação do
sexto período da Universidade Federal do Amazonas. É um resultado de
uma parceria entre o Instituto de Computação e a Pró­Reitoria de Pesquisa
e Pós­Graduação (Propesp). Está inserido em uma abordagem
multidisciplinar envolvendo quatro disciplinas cursadas nesse período pelos
alunos envolvidos. Tem o objetivo de capacitar os alunos e ao mesmo
tempo suprir necessidades da Universidade Federal do Amazonas.
O sistema que está sendo desenvolvido se intitula PIC Eletrônico.
Este tem o objetivo de dar suporte ao Plano Instituicional de Capacitação
(PIC) da Universidade Federal do Amazonas.
O PIC é gerido pela Propesp e acontece durante triênios. Este tem
como objetivo viabilizar o acesso à educação para servidores da
Universidade Federal do Amazonas (UFAM) para um desenvolvimento
melhor de suas atividades dentro da instituição. Esse programa acontece
em quatro etapas. Na primeira, há o Pedido de Capacitação Docente
Técnico (PCDT) de cada unidade para a Propesp. A segunda, é a etapa de
avaliação desses pedidos, cada um deles é avaliado individualmente e
1

2. então é decidido se este será aprovado ou não. A terceira, acontece no
momento em que chega a data pela qual o servidor aprovado na etapa
anterior se afastará para a capacitação. Esta etapa consiste no
preenchimento e na avaliação de alguns dados relevantes a sua ausência
durante o período de capacitação. A última etapa do programa é a parte de
execução da capacitação.
O sistema de PIC Eletrônico abrangerá três das quatro etapas
citadas anteriormente, não abrangendo a última etapa.
1.2 Funções principais do produto de software
O PIC Eletrônico está inserido em um cenário que possui a
participação de três perfis de usuários, administrador, unidade e propesp.
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 de Unidade diz respeito ao ator do sistema que representa
as unidades que utilizarão o software. O perfil Propesp diz respeito ao ator
do sistema que fará a avaliação de dados e pedidos enviados por usuários
do perfil unidade.
Seu escopo está dividido da seguinte forma:
● Para o Perfil de Administrador:
○ Gerência de Usuários;
○ Gerência de Unidades;
○ Gerência de Servidores;
○ Gerência de PIC;
● Para o Perfil Unidade:
○ Solicitar PCDT;
○ Geração de Relatórios;
○ Consulta a Histórico de PIC;
2

3. ○ Consulta a Situação da Unidade;
● Para o Perfil Propesp:
○ Avaliar Documentação de PCDT ;
○ Avaliar Pedidos ;
○ Consultar Diagnóstico de Unidade;
○ Geração de Relatórios;
1.3 Requisitos comportamentais ou de performance
O sistema terá que apresentar uma interface amigável visando sua
máxima utilização por diferentes perfis de usuário, os quais nem sempre
dispõem de conhecimento sobre informática e/ou tecnologias web.
Em relação aos requisitos comportamentais o sistema não
apresenta nenhuma funcionalidade crítica. Para a impressão dos relatórios
o sistema necessita esta sincronizado com uma impressora. Algumas
funcionalidades do sistema estarão disponíveis apenas quando a data
(para a disponibilidade da funcionalidade) previamente estabelecida pelo
administrador esteja vigente, fora desta data o sistema alertara aos seus
usuários que a funcionalidade esta indisponível.
1.4 Gestão e Restrições Técnicas
Abaixo seguem algumas questões técnicas e restrições que o PIC
Eletrônico está inserido. São elas:
○ O PIC Eletrônico deverá importar dados contidos na base de dados
do Sistema de Informações para o Ensino (SIE) da UFAM;
○ O PIC Eletrônico deverá rodar na plataforma Web;
○ O PIC Eletrônico deverá ser construído utilizando a tecnologia PHP e
3

4. o Framework de desenvolvimento de software para web para a
linguagem PHP chamado CodeIgneiter;
○ O PIC Eletrônico deverá conter uma abordagem sólida em testes;
○ A equipe não possui experiência prática com as ferramentas e
métodos utilizados para o desenvolvimento;
○ O PIC Eletrônico será desenvolvido em um contexto de
Desenvolvimento Distribuído de Software (DDS);
○ Haverá Rotatividade de papéis durante todo o processo de
desenvolvimento.
○ O PIC Eletrônico deverá ser desenvolvido utilizando uma
metodologia de desenvolvimento ágil.
4

5. 2.0 ESTIMATIVAS DO PROJETO
Nesta seção será apresentado o cálculo para estimativa da duração total
do projeto em dias. Para encontrar esse tempo é necessário aplicar uma técnica
de estimativa e neste caso iremos utilizar a métrica adotada pela Lacertae
Software: Lorenz & Kidd;
2.1 Dados históricos utilizados para as estimativas
Não possuímos dados históricos para serem utilizados nas
estimativas.
2.2 Técnicas de estimativa e resultados
A métrica utilizada para encontrar o prazo total de duração do projeto
em dias foi a Lorentz & Kidd. É uma métrica orientada a classes adotada
pela Lacertae Software para realizar a estimativa do prazo total deste
projeto.
2.2.1 Técnica de estimativa.
Foi utilizada a técnica de estimativa que segue as regras da
métrica de Lorenz & Kidd adaptada pela Lacertae Software.
Seguiu­se os seguintes passos:
1. Definir o número de classes chave;
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;
3. Multiplicar a quantidade de classes­chave pelo multiplicador para
obter uma estimativa do número de classes de suporte;
4. Logo após, calcula­se a quantidade total de classes, somando o
nº de classes­chaves com o nº de classes de suporte;
5. Multiplicar a quantidade total de classes (classes­chave + classes
5

6. de suporte) pelo número médio de unidades de trabalho
(dias­pessoa) por classe. Lorenz & Kidd sugere entre 15 e 20 dias
pessoa por classe. Escolher um número entre 15 e 20 dias pessoa
por classe e justificar a escolha.
6. Determinar a quantidade de esforço estimada;
7. Calcular o tempo previsto para a elaboração do projeto.
A tabela abaixo mostra os fatores de multiplicação indicados
pela métrica para encontrar a quantidade de classes de suporte. O
projeto possui uma interface do tipo GUI complexo com um fator
multiplicador de 3,0.
Interface Multiplicador
Não gráfica 2
baseada em texto 2,25
GUI 2,5
GUI complexo 3,0
2.3 Resultados
De acordo com a métrica descrita acima obteve­se os
seguintes resultados:
1. Quantidade de classes chaves = 6;
2. É um sistema web que utiliza a interface gráfica GUI com um fator
multiplicador igual a 3,0;
3. Classes chaves x multiplicador (6 x 3) = 18 classes de suporte; 4.
Classes chaves + classes de suporte (6 + 18) = 24 classes
projetadas para o sistema;
6

7. 5. A quantidade de dias­pessoas adotada da sugestão de Lorenz &
Kidd foi de 19 dias, numa escala entre 15 e 20 dias. Levou­se em
conta a falta de experiência no método de desenvolvimento e do
framework por toda a equipe e a falta de conhecimento e prática em
programação web por parte da equipe.
6. Calculou­se a quantidade de esforço estimada: (24 x 19) =
456 dias de trabalho;
7. A equipe de desenvolvimento deste projeto possui quatro
membros. Calculou­se a distribuição dos dias de trabalho por
pessoa : 456 ÷ 4 = 114 dias sendo que foram trabalhados
efetivamente 78 dias, indicando que o projeto foi realizado dentro do
prazo. Supondo o valor de 15 dias para a quantidade de
dias­pessoas, o valor de dias trabalhados será de 360 dias, que
dividido pelos quatro membros: 360 ÷ 4 = 90 dias por pessoa.
Desta forma, com a redução dos dias por pessoa adotada da
sugestão da métrica Lorenz & Kidd, a estimativa do tempo do
projeto ficou mais próxima da real.
2.4 Recursos do projeto
Os recursos do sistema foram separados em três partes: recursos
humanos, recursos de software e recursos de hardware:
2.4.1 Recursos Humanos
A equipe utilizará o método SCRUM. Uma metodologia que
normalmente é utilizada em processos considerados imprevisíveis ( é
impossível predizer tudo o que irá ocorrer ). Desenvolvido inicialmente para
o gerenciamento de projetos de software, SCRUM também é utilizado na
manutenção de software e para o gerenciamento de forma global,
7

8. abrangendo projetos/programas. É dividido em iterações de (geralmente)
30 dias chamados sprints, onde se trabalha para alcançar objetivos bem
definidos. Estes objetivos são representados por uma lista de
funcionalidades que é atualizada e repriorizada a cada nova sprint. Os
papéis principais em equipes SCRUM são:
● Product Owner: responsável pela visão de negócios do projeto.
● Scrum Master: é uma mistura de gerente, facilitador e mediador da
equipe de desenvolvimento
● Desenvolvedor: responsável por implementar o sistema.
● Testador: responsável por realizar os testes no sistema.
A dinâmica seguida pelo SCRUM é a seguinte:
● Realiza­se uma reunião para definir quais funcionalidades serão
desenvolvidas na sprint
● Durante a sprint são realizadas reuniões diárias, com o objetivo de
avaliar o que foi feito no dia anterior, identificar quais impedimentos
surgiram e priorizar o trabalho a ser desenvolvido no dia seguinte.
● No fim da sprint é apresentado aos Stakholders, o conjunto de
funcionalidades que foram desenvolvidas, para que estas possam ser
aprovadas, e por fim é feita uma reunião para planejar a próxima sprint,
fechando assim o circulo
A equipe é formada por 4 integrantes , os componentes da equipe
assumem diferentes papéis a cada sprint. Esses papéis são de 1(um)
scrum master, 2 (dois) programadores , 1(um) testador e 2 (dois) product
owner. Cada ciclo da sprint é de 3 (três) semanas e após isso os
integrantes sofrem rotatividade da equipe na seção 5.1 será detalhado
como acontecerá, veja abaixo os papéis que cada integrante pode assumir:
Alison Lemos
○ Scrum Master;
8

9. ○ Desenvolvedor;
○ Testador.
Janiel Medeiros
○ Scrum Master;
○ Desenvolvedor;
○ Testador.
Kirmayr Tomaz
○ Scrum Master;
○ Desenvolvedor;
○ Testador.
Urique Hoffmann
○ Scrum Master;
○ Desenvolvedor;
○ Testador.
2.4.2 Recursos de Software:
NetBeans 7.2 ­ Apoio ao desenvolvimento da linguagem PHP, Javascript ,
Ajax , Json e Jquery.
PHP ­ Linguagem procedural executada no servidor, essencial para o
desenvolvimento WEB
Framework CodeIgniter ­ Utiliza o padrão MVC, fácil apredizado para
equipes inexperientes, além de possuir uma vasta documentação na web.
Json ­ Objeto criado dinamicamente para comunicação do servidor com o
cliente de forma assíncrona.
Jquery ­ Utilizado para melhorar a interação com o HTML.
Javascript ­ Utilizado para validações de campos, funções de envio de
9

10. dados e outros.
Sistema Operacional Ubuntu ­ Sistema operacional de código livre, que
será utilizado pela equpe.
Google Docs ­ Utilizado para a documentação das estórias,
procedimentos para desenvolvimento do sistema, regras de negócio e
qualquer outra documentação necessária.
Dropbox ­ Utilizado para armazenar todo o conteúdo necessário para o
sistema. Formulários do cliente, gravação da reunião com product owner,
protótipos , estórias e o que for necessário.
Pencil ­ Programa utilizado para a criação de protótipos do sistema
baseando­se nas estórias que forem criadas.
Artisteer ­ Programa para criação de templates WEB e sistemas CMS.
Gmail ­ Sistema de Email utilizado pelos integrantes do grupo.
Gtalk ­ Sistema de Comunicação via chat quando houver necessidade de
desenvolvimento distribuído de software.
RedMine ­ Utlizado para gerenciar o projeto, sistema web que facilita o
grupo a visualizar suas tarefas especificas que cada um deve realizar, além
de possuir uma opção para adicionar os bugs que vem sendo encontrado
no sistema. Contém também o gráfico de gantt e a percentagem de tarefas
realizadas, ajudando na representação visual do projeto e seus deadlines.
Subversion ­ Software SCV(Sistema de controle de versão).
Apache ­ servidor web livre, utilizado para executar as página para os
usuários via protocolo HTTP e HTTPS.
PostgreSQL ­ Serviço de banco de dados que será utilizado.
pgAdmin 1.14.2 ­ Serviço de gerenciamento do banco de dados
PostgreSQL.
10

11. Browser Chrome versão 22 ou Firefox versão 18 ­ Utilizados para
visualizar o que foi desenvolvido.
Drive de comunicação do Apache com o PostgreSQL ­ pgsql ­ Necessário
para a comunicação entre o Apache e PostgreSQL, sem isso o sistema
não poderá ser executado, gerando uma falha no sistema.
2.4.3 Recursos de Hardware:
Computador Servidor para SVN e Redmine.
Processador: Core I3.
Memória RAM: 4 Gigas de RAM.
HD : 320 Gigas no mínimo.
Computador para desenvolvimento :
Processador: Core I3.
Memória RAM: 4 Gigas de RAM.
HD : 320 Gigas no mínimo.
3.0 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão tratados os riscos identificados que precisam ser
monitorados durante o projeto.
3.1 Riscos do projeto
­ Custos associados a entrega;
­ Custos associados a um produto defeituoso;
11

12. ­ Falta da presença do cliente na definição dos requisitos;
­ O fato do cliente não oferecer suporte ao projeto;
­ A equipe não tem experiência na metodologia adotada;
­ Cliente e gestor ausentes;
­ Requisitos vagos;
­ Mudança de tecnologia;
­ Falta de integração com dados do SIE;
­ A tecnologia é nova para a equipe;
­ Os engenheiros de software não compreendem os requisitos;
­ Os engenheiros de software não tem a competência requerida;
­ Uso de Ferramentas de auxílio ao processo de desenvolvimento que não
estejam integradas gerando assim mais trabalho
­ Usuario com poucas habilidades;
­ Uso de novos métodos em Engenharia de Software;
­ Não ser estabelecido padrões de documentação e codificação;
­ Falta de dedicação exclusiva da equipe.
3.2 Tabela de riscos
Tabela com os riscos identificados e a sua probabilidade de ocorrência e
impacto esperado.
12

13. Risco Probabilidade Impacto
Mudança de Tecnologia 10% Catastrófico
A tecnologia é nova para 50% Crítico
equipe
Os engenheiros de software 50% Crítico
não compreendem os
requisitos
Requisitos Vagos 45% Crítico
Custos associados a 30% Crítico
entrega
Custos associados a um 30% Crítico
produto defeituoso
Cliente e Gestor ausentes 30% Crítico
Falta de Integração dos 30% Crítico
dados com o SIE
Os engenheiros de software 20% Crítico
não tem a competência
requerida
Falta da presença do 10% Crítico
cliente na definição dos
requisitos
Ponto de Corte
O cliente não oferecer 90% Marginal
suporte ao projeto
Falta de dedicação 90% Marginal
exclusiva da equipe
A equipe não tem 50% Marginal
experiência na metodologia
de desenvolvimento
adotada
13

14. Uso de novos métodos em 50% Marginal
Engenharia de Software
Não ser estabelecido 50% Marginal
padrões de documentação
e codificação
Uso de Ferramentas de 10% Marginal
auxílio ao processo de
desenvolvimento que não
estejam integradas gerando
assim mais trabalho
Usuário com poucas 90% Despresível
habilidades
Os riscos considerados catastróficos e críticos serão gerenciados com
mais atenção representando assim o ponto de corte para os riscos
identificados acima.
3.3 Redução e Gestão do Risco
Selecionados oito riscos de maior impacto e probabilidade, para serem
levantados as respectivas atividades de redução, supervisão e gestão de
riscos:
Risco: Mudança de Prob: 10% Impacto: Catrastrófico
Tecnologia
Descrição: Durante a construção do sistema pode haver a necessidade de
mudança de tecnologia de desenvolvimento devido as restrições de
manutenção e implantação do sistema.
14

15. Estratégia de redução: Validação com o cliente a respeito do ambiente em
que o sistema final irá rodar bem como saber quais os conhecimentos e
limitações de tecnologia da pessoas que farão a manutenção do sistema
após construído e implantado.
Plano de Contigência: Buscar pessoas capacitadas na nova tecnologia para
apoiar o desenvolvimento do sistema na nova tecnologia o mais rápido
possível.
Responsável: Toda a equipe.
Status: Não ocorrido.
Risco: A tecnologia é Prob: 50% Impacto: Crítico
nova para equipe;
Descrição: Durante o inicio do projeto ao realizar a organização da equipe do
projeto. O grupo na reunião, verifica que possui um carência com a nova
tecnologia utilizada para o desenvolvimento deste sistema.
Estratégia de redução: Compra de documentação necessária para o
aprendizado dos membros, e a busca de cursos para ajuda nos estudos.
Plano de Contigência: Caso algum ciclo de uma sprint já esteja realizado , o
Scrum master deve diminuir a quantidade de tarefas que devem ser
realizadas para esta pessoa que tem muita carência de conhecimento da
nova tecnologia, e procurar algum membro do grupo que tem um maior
experiência com a tecnologia para ajudar nesta necessidade.
Responsável: Toda a equipe.
Status: Ocorrido.
15

16. Risco: Os engenheiros Prob: 50% Impacto: Crítico
de softwares não
compreendem bem os
requisitos;
Descrição: Após a análise dos requisitos com o cliente, os engenheiros de
software que efetuaram esta, possuem dificuldades em compreender de
como deve ser desenvolvido e modelado o sistema.
Estratégia de redução: Procurar os engenheiros de software mais experientes
com a analise dos requisitos. Uma vez a análise feita, deve ser realizado
um levantamento dos requisitos e outra reunião com o cliente para que
possa mostrar quais requisitos são necessários e quais deveriam ser
incluídos na lista.
Plano de Contigência: Utilização de protótipos das tela para o cliente,
podendo ser realizado ao punho livre ou mockups.
Responsável: Toda a equipe.
Status: Não ocorrido.
Risco:Requisitos vagos Prob: 45% Impacto: crítico
Descrição: Requisitos dos sistema mal definidos pelo cliente e/ou pouco
compreendidos pelos engenheiros de software do projeto bem como falta
de definição de regras de negócio dificultando ainda mais o
desenvolvimento do sistema para atender as exigências estabelecidas
pelo cliente.
Estratégia de redução: Prototipação e reuniões constantes com os
stakeholders do projeto bem como fazer uma análise do processo em
que o sistema será inserido ou estudando documentações referentes ao
domínio do problema.
16

17. Plano de Contigência: Buscar nas próximas iterações do projeto definir
melhor os requisitos e validar­los com os stakeholders do sistema. Fazer
reuniões imediatas com o cliente para poder sanar tal problema e
diminuir o impacto.
Responsável: Toda a equipe.
Status: Ocorrido.
Risco:Custos Prob: 30% Impacto: Crítico
associados a entrega.
Descrição: O risco está associado a não entrega do produto no período
combinado com o cliente, podendo gerar assim custos associado a isso
como prejuízos para a equipe.
Estratégia de redução: Reuniões diárias com a equipe para saber o
andamento do projeto, e se houver algum impedimento buscar resolver o
mais rápido possível. Buscar seguir o planejamento feito em cada
iteração do projeto.
Plano de Contigência: Aceitar o atraso e buscar negociar com o cliente um
meio de diminuir os impactos associados ao atraso na entrega para que
nenhuma das partes saia prejudicada, principalmente o cliente.
Responsável: Toda a equipe
Status: Não ocorrido.
Risco: Custos Prob: 30% Impacto: Crítico
associados a um produto
defeituoso;
17

18. Descrição: O risco diz respeito a entrega de um produto ou de um incremento
que não atenda completamente ao que foi negociado, ou não atenda as
necessidades do cliente.
Estratégia de redução: Buscar manter o cliente o mais próximo possível do
desenvolvimento, e haver constantes reuniões de apresentação e
validação do que está sendo feito , para que o cliente entenda e diga se
isso está ou não de acordo com suas necessidades.
Plano de Contigência: Se ocorrer em uma iteração do sistema que não seja a
ultima, o que deve ser feito é a correção da parte defeituosa no próximo
incremento. Acelerar o Processo de desenvolvimento da próxima iteração
para conseguir corrigir esse erro e não atrasar o andamento do projeto.
Se acontecer na ultima entrega do sistema, negociar com o cliente uma
nova iteração para a correção do erro em questão.
Responsável: Toda a equipe
Status: Não ocorrido.
Risco: Cliente e gestor Prob: 30% Impacto: crítico
ausentes.
Descrição: Durante os processo de desenvolvimento do software ambos
stakeholders não estiverem presentes para resolver as dúvidas e auxiliar
na gestão.
Estratégia de redução: Encontrar diversas formas de comunicação com
ambos para que sempre seja realizada essa interação, sem a perda de
contato
Plano de Contigência: Formalizar o contato com os stakeholders por meio de
documentação formal.
18

19. Responsável: Scrum Master
Status: Ocorrido.
Risco: Falta de Prob: 30% Impacto: Crítico.
integração com dados
do SIE;
Descrição: Na última etapa de desenvolvimento do sistema, não ser possível
realizar a integração dos sistemas
Estratégia de redução: Buscar desenvolver a estrutura do banco de dados do
sistema de forma similar à utilizada pelo SIE, realizar esta integração o
mais rápido possivél.
Plano de Contigência: Acessar a base dados existente por meio de
Web­Service.
Responsável: Toda a equipe.
Status: Não ocorrido.
4.0 PLANEJAMENTO TEMPORAL
Aqui são apresentadas as tarefas do projeto e suas dependências bem
como o planejamento temporal feito para cada uma dessas tarefas e como ficou o
planejamento do projeto.
4.1 Conjunto de Tarefas do Projeto
Como apresentado na seção 2.4.1 desse documento, o projeto será
19

20. desenvolvido utilizando a metodologia de desenvolvimento ágil conhecida
como SCRUM, tal metodologia trabalha com entregas parciais e
incrementais do sistema em iterações chamadas sprints. A equipe planeja
que o projeto seja desenvolvido em 5 sprints, sendo que a primeira sprint
chamada de sprint 0 é uma sprint de configuração, planejamento e
definições para a continuidade do projeto. A partir da sprint 1 até a sprint 4
o clico de atividades é o mesmo, portanto abaixo é listado apenas as
macro atividades das sprints 0 e 1. Cada macro atividade é composta por
subatividades que não serão descritas nessa seção no entanto é possível
identificá­las na próxima seção através do diagrama de Gantt.
As atividades são as seguintes:
○ Sprint 0:
■ Planejamento do Projeto em Geral: Essa atividade diz
respeito do planejamento inicial do projeto, aqui é feito a
reunião inicial com o cliente, a definição do escopo do
sistema, definição do Product Backlog bem como a
definição dos papéis dos membros da equipe em cada
iteração do projeto e a rotatividade desses papéis.
● Gestão de risco do projeto: A gestão de risco do
projeto é uma das subatividades do Planejamento do
projeto em geral, esta é uma subatividades divididas
em outras atividades menores. Aqui é feito a definição
dos riscos do projeto e um planejamento de mitigação
e contingência para os riscos identificados.
■ Configuração do ambiente de desenvolvimento: Essa macro
atividade é dividida em configurar e definir quais serão as
tecnologias utilizadas no projeto, a ambientação, treinamento
e configuração das ferramentas. Além da configuração do
ambiente está inserido aqui também atividades de
20

21. treinamento e estudo a respeito das tecnologias definidas
para o projeto.
● Definição das tecnologias e ferramentas utilizadas:
Essa macro atividade diz respeito em definir a
tecnologia de desenvolvimento de software, ferramenta
de gerenciamento de projeto, ferramenta de controle
de versão, definição do SGBD, ferramenta para testes,
hardwares utilizados.
○ Sprints 1,2,3 e 4
■ Planejamento e análise da sprint: cada uma das 4 sprints
precisa de um planejamento que norteará as atividades feitas
nessa sprint. Esse planejamento da sprint depende do
planejamento geral feito na sprint 0 e do sucesso das sprints
anteriores. As subatividades relacionadas são atividades
como reunião de planejamento da sprint, definição do sprint
backlog, reunião com o product owner para a validação da
sprint backlog entre outros.
● Análise e projeto da sprint: Um das subatividades do
planejamento da sprint é a análise e projeto da sprint.
Nessa etapa da sprint são feitas as descrições das
estórias dos usuários, criação dos diagramas UML e a
modelagem do banco de dados relacionado a sprint
em questão. Nessa etapa incluem­se também
atividades de reunião de apresentação dos modelos
criados para os desenvolvedores e se necessário
inspeções dos artefatos de software produzidos nessa
etapa bem como o versionamento de tudo o que foi
feito até o momento na sprint.
■ Codificação: A atividade de codificação não precisa de um
21

22. detalhamento maior por conta de se entender que nessa fase
é feita a construção do produto que será entregue na sprint,
esta possui algumas subatividades relacionadas tais como:
produção de protótipos para as estórias, codificação dessas
estórias, testes de unidade e o versionamento dos artefatos
produzidos durante essa fase da sprint.
■ Testes: Esta atividade engloba: as criações dos recursos
necessários para a execução dos testes como os casos de
teste para as estórias da sprint e os scripts de teste. Além
disso esta inserido nesta atividade a execução dos testes e
por fim a documentação dos bugs encontrados na execução
dos testes. Esta atividade ocorre nas quatro sprints.
● Retrabalho: Esta subatividade constitui­se das
correções dos bugs reportados nos testes, da
execução dos testes de regressão, que são os testes
realizados após as correções feitas e por fim do
versionamento dos artefatos produzidos na atividade
de testes.
■ Finalização e entrega do produto produzido na sprint: Esta
macro atividade refere­se as reuniões de finalização e de
retrospective da sprint além do versionamento, apresentação
e configuração do produto produzido.
22

23. 4.2 Diagrama de Gantt
O Diagrama de Gantt (em anexo ao projeto de software) detalha as
atividades planejadas para o projeto.
No diagrama são descritos o nome das atividades, a estimativa de
duração para cada uma delas, a data de início e fim, qual(is) atividade(s)
predece(em) cada atividade e o(s) responsável(is) por cada uma das
tarefas descritas no documento.
23

24. 5.0 ORGANIZAÇÃO DO PESSOAL
Na seção 2.4.1 desse documento é apresentada a metodologia de
desenvolvimento em que o projeto de software está inserido, ali é possível
identificar que será adotado o SCRUM como metodologia. Foi possível
entender o papel de cada um dos componente da equipe no projeto, no
entanto não foi identificado em que momento cada um componente da
equipe assumiria qual papel durante o processo de desenvolvimento,
abaixo é descrito como acontecerá a rotatividade dos membros e seus
respectivos papéis em cada uma das sprints do SCRUM.
5.1 Estrutura da equipa
Sprint 1
○ Scrum Master : Alison Lemos
○ Programador 1: Janiel Medeiros
○ Programador 2 : Kirmayr Tomaz
○ Testador: Urique Hoffmann
Sprint 2:
○ Scrum Master : Kirmayr Tomaz
○ Programador 1: Urique Hoffmann
○ Programador 2 : Alison Lemos
○ Testador:Janiel Medeiros
Sprint 3:
○ Scrum Master :Urique Hoffmann
○ Programador 1: Janiel Medeiros
○ Programador 2 : Kirmayr Tomaz
○ Testador:Alison Lemos
Sprint 4:
○ Scrum Master : Janiel Medeiros
24

25. ○ Programador 1:Urique Hoffmann
○ Programador 2 : Alison Medeiros
○ Testador:Kirmayr Tomaz
5.2 Mecanismos de comunicação
A equipe utiliza como meios de comunicação diversas ferramentas.
Além da comunicação face a face que é feita diariamente em reuniões que
acontecem, a equipe utiliza redes sociais como o Facebook e o Google+ ,
chats na web como o Google Talk, telefones e algumas ferramentas além
dessas. As ferramentas adicionais utilizadas são: Google Drive, utilizado
para compartilhar arquivos, e o Redmine, uma ferramenta de
gerenciamento que a equipe utiliza para o acompanhamento do andamento
das atividades realizadas e onde é registrado o Daily Meeting, a reunião
diária que a equipe faz seguindo os padrões do processo SCRUM onde
são respondidas três questões básicas, são elas: O que eu fiz hoje? O que
vou fazer amanhã? Existe algum impedimento para realização das minhas
atividades?
5.3 Uso do Edu­blog como ferramenta de apoio
O uso do Edu­blog pode ter algumas interações: A facilidade de
aprendizado de determinados assuntos encontrados em outros blogs
adjacentes. Uma forma também de compartilhar os assuntos para o público
geral, sem a necessidade de algo complicado e de difícil acesso e
auxiliando também na comunicação entre o professor e o aluno.
Facilidade para encontrar o material da disciplina, documentos
antigos, turmas que já realizaram a disciplina e assim um ponto de
referência para qual caminho devemos seguir e que melhorias devemos
tomar com estes aprendizado.
25

26. 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E
CONTROLAR A QUALIDADE DO PRODUTO DE SW
É realizado um acompanhamento para assegurar e controlar as
atividades que estão sendo executadas no projeto, tais serão descritas
baixo:
Revisões Técnicas Formais
As revisões formais existentes são as revisões técnicas, inspeção,
walkthrough e revisões gerenciais. No contexto do SCRUM optamos por
algo que seja rápido, e ajude na qualidade do produto. De forma que será
utilizada a técnica de revisões gerenciais , realizada em cada sprint que
necessite da atualização da documentação dos requisitos do sistema, ou
seja, em cada sprint o sistema passará pôr uma revisão gerencial com foco
da garantia desta qualidade .
Gestão de Configuração do SW
A cada sprint o sistema passa por um controle de versão das
estórias do sistema, casos de teste e da codificação.
Produção de Documentação
Para o controle de qualidade do processo de desenvolvimento, foi
elaborada documentação nas etapas de Análise, Projeto e Teste.
Registro de Atividades
Com registro das atividades por meio de um software de gerência
de Projetos(Redmine) ,consegue assim, por meio desta, estabelecer as
26

27. atividades e o status de execução destas.
Análise de Riscos
Identificação, análise e controle dos riscos, elaborando­se planos de
redução e de contingência, conforme citádo no capítulo 3 deste documento.
Testes
Após toda a análise do que será realizado pelo sistema. Será
definido alguns critérios da realização do teste de software. Na forma que
terá a cada sprint um planejamento dos tipos de teste que devem ser
realizado em cada sprint, em que ponto os testes são necessários parar,
dependendo do que o cliente solicitou assim como os testes caixa preta
que serão executados no sistema. Casos de teste, procedimentos de teste,
testes de integração também serão realizados.
27