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

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.

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

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

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

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

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

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

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 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: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 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

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

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

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

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, 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