Post on 05-Dec-2014
description
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ósGraduaçã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
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
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
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
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.
Seguiuse 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 classeschave pelo multiplicador para
obter uma estimativa do número de classes de suporte;
4. Logo após, calculase a quantidade total de classes, somando o
nº de classeschaves com o nº de classes de suporte;
5. Multiplicar a quantidade total de classes (classeschave + classes
5
de suporte) pelo número médio de unidades de trabalho
(diaspessoa) 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 obtevese 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
5. A quantidade de diaspessoas adotada da sugestão de Lorenz &
Kidd foi de 19 dias, numa escala entre 15 e 20 dias. Levouse 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. Calculouse a quantidade de esforço estimada: (24 x 19) =
456 dias de trabalho;
7. A equipe de desenvolvimento deste projeto possui quatro
membros. Calculouse 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
diaspessoas, 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
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:
Realizase 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
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
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
baseandose 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
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
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
Risco Probabilidade Impacto
Mudança de Tecnologia 10% Catastrófico
A tecnologia é nova para equipe
50% Crítico
Os engenheiros de software não compreendem os requisitos
50% Crítico
Requisitos Vagos 45% Crítico
Custos associados a entrega
30% Crítico
Custos associados a um produto defeituoso
30% Crítico
Cliente e Gestor ausentes 30% Crítico
Falta de Integração dos dados com o SIE
30% Crítico
Os engenheiros de software não tem a competência requerida
20% Crítico
Falta da presença do cliente na definição dos requisitos
10% Crítico
Ponto de Corte
O cliente não oferecer suporte ao projeto
90% Marginal
Falta de dedicação exclusiva da equipe
90% Marginal
A equipe não tem experiência na metodologia de desenvolvimento adotada
50% Marginal
13
Uso de novos métodos em
Engenharia de Software
50% Marginal
Não ser estabelecido padrões de documentação e codificação
50% Marginal
Uso de Ferramentas de auxílio ao processo de desenvolvimento que não estejam integradas gerando assim mais trabalho
10% Marginal
Usuário com poucas habilidades
90% Despresível
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 Tecnologia
Prob: 10% Impacto: Catrastrófico
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
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 é nova para equipe;
Prob: 50% Impacto: Crítico
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
Risco: Os engenheiros de softwares não compreendem bem os requisitos;
Prob: 50% Impacto: Crítico
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
Plano de Contigência: Buscar nas próximas iterações do projeto definir melhor os requisitos e validarlos 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:Custosassociados a entrega.
Prob: 30% Impacto: Crítico
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 associados a um produto defeituoso;
Prob: 30% Impacto: Crítico
17
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 ausentes.
Prob: 30% Impacto: crítico
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
Responsável: Scrum Master
Status: Ocorrido.
Risco: Falta de integração com dados do SIE;
Prob: 30% Impacto: Crítico.
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 WebService.
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
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
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 incluemse 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
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 constituise 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 referese as reuniões de finalização e de
retrospective da sprint além do versionamento, apresentação
e configuração do produto produzido.
22
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
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
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 Edublog como ferramenta de apoio
O uso do Edublog 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
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
atividades e o status de execução destas.
Análise de Riscos
Identificação, análise e controle dos riscos, elaborandose 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