UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAO
PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO



Disciplina: Engenharia de Software
Professor: Rogrio P C do Nascimento
rogerio@ufs.br





PLANO DO PROJETO
14COMMERCE








Ben Hur Neres de Barros 201411009740
Fernanda Gomes Silva 201411005349
Josimar de Souza Lima 201411003854








So Cristvo
2014


SUMRIO


1. INTRODUO ...................................................................................................... 4
1.1 mbito do projeto ................................................................................................... 4
1.2 Funes principais do produto de software ............................................................ 4
1.3 Requisitos comportamentais ou de performance .................................................... 6
1.4 Gesto e Restries Tcnicas .................................................................................. 6
2. ESTIMATIVAS DO PROJETO........................................................................... 7
2.1 Dados histricos para estimativas do projeto ......................................................... 8
2.2 Tcnicas de estimativas e resultados....................................................................... 8
2.3 Resultados ............................................................................................................... 9
2.4 Recursos do projeto .............................................................................................. 10
3. ANLISE E GESTO DE RISCOS .................................................................. 12
3.1 Riscos do projeto .................................................................................................. 12
3.2 Tabela de riscos .................................................................................................... 14
3.3 Reduo e gesto dos riscos .................................................................................. 15
4. PLANEJAMENTO TEMPORAL ...................................................................... 19
4.1 Conjunto de tarefas do projeto .............................................................................. 19
4.2 Diagrama de Gantt ................................................................................................ 19
5. ORGANIZAO DO PESSOAL ...................................................................... 26
5.1 Estrutura da equipe ............................................................................................... 26
5.2 Mecanismos de comunicao ............................................................................... 26
5.3 Uso do Edu-blog como ferramenta de apoio ........................................................ 26
6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW ..................................................................... 26
7. REFERNCIAS BIBLIOGRFICAS .............................................................. 28




SUMRIO DE TABELAS

Tabela 1: Atores e funcionalidades do sistema 14Commerce .......................................... 5
Tabela 2: Classificao dos tipos de interface .................................................................. 8
Tabela 3: Recursos humanos do projeto ......................................................................... 10
Tabela 4: Recursos de software ...................................................................................... 11
Tabela 5: Riscos gerais comuns a maioria dos projetos de softwares ............................ 12
Tabela 6: Todos os riscos do projeto 14Commerce ....................................................... 15
Tabela 7: Plano de reduo de riscos do projeto ............................................................ 18
Tabela 8: Diviso das tarefas do projeto ........................................................................ 19


SUMRIO DE FIGURAS

Figura 1: Ciclo do Scrum ................................................................................................. 7
Figura 2: Diagramas de classes ........................................................................................ 9
Figura 3: Cronograma do projeto (Parte 1) .................................................................... 20
Figura 4: Cronograma do projeto (Parte 2) .................................................................... 21
Figura 5: Cronograma do projeto (Parte 3) .................................................................... 22
Figura 6: Cronograma do projeto (Parte 4) .................................................................... 23
Figura 7: Cronograma do projeto (Parte 5) .................................................................... 24
4

1. INTRODUO

Esse plano faz uma breve explanao do produto de software a ser desenvolvido.
Aborda as estimativas, a anlise e gesto de riscos, o planejamento temporal, a
organizao do pessoal e as precaues tomadas para assegurar e controlar a qualidade
do projeto.


1.1 mbito do projeto

Este projeto visa desenvolver um produto de software para a empresa CIO
Market que uma loja de aplicativos corporativos, semelhante s lojas tradicionais
Apple Store, Google Play e Windows Store. O modelo dessa loja baseado no SaaS
(software as services) e seu objetivo permitir que empresas possam disponibilizar
aplicativos para outras empresas (B2B).
Quando se adquire um software pela CIO Market, um servidor virtual com os
requisitos adequados criado, instalado e configurado automaticamente. Desta maneira,
tanto os produtores de aplicativos quanto os clientes destes produtos podem se
concentrar no que eles fazem de melhor, suas atividades fins.
O produto que ser desenvolvido o 14Commerce. Trata-se de uma loja virtual
completa, totalmente customizvel e ficar disponvel em minutos para seus clientes. O
ambiente onde ela estar inserida, ir permitir que todos os clientes tenham acesso total
ao servidor virtual, podendo atualizar suas lojas e adapt-las conforme suas
necessidades.
A 14Commerce poder ser adaptada a qualquer tipo de negcio e ter como
objetivo principal transformar visitantes em compradores. Utilizar um layout agradvel
e personalizvel. Ir disponibilizar mltiplas formas de pagamentos, seus produtos
estaro organizados de maneira a potencializar sua visibilidade e sero aplicadas as
melhores tcnicas de otimizao para que a loja criada possa ser encontrada facilmente
pelos principais sites de buscas. Na pgina inicial de cada loja, o cliente poder conferir
os produtos que estiverem em promoo, os mais vendidos, os ltimos produtos
adicionados e os ltimos comentrios realizados pelos clientes.


1.2 Funes principais do produto de software

Os principais atores e funes do sistema 14commerce so apresentados na
Tabela 1.


5

ATOR FUNCIONALIDADES
Cliente
Pesquisar produto
Detalhar produto
Manter o produto no carrinho de compras
Manter produto na lista de itens desejados
Manter produto na lista de presentes
Manter comentrios
Manter pedido
Registrar-se
Autenticar-se
Manter endereo
Manter dados pessoais
Manter a forma de pagamento
Administrador
Manter produto
Manter fabricantes
Manter fornecedores
Manter categoria
Manter promoes
Manter cupom de descontos
Manter formas de pagamento
Manter taxas
Manter transportadora
Gerenciar comentrios
Consultar ltimos pedidos
Detalhar pedidos
Consultar painel gerencial
Detalhar item do painel gerencial
Alterar configuraes do Sistema
Tabela 1: Atores e funcionalidades do sistema 14Commerce

Vale destacar que as funcionalidades chaves nesse projeto so aquelas que esto
relacionadas com o produto, o pedido dos clientes em compra e as de configurao no
perfil de administrador.



6

1.3 Requisitos comportamentais ou de performance

O sistema 14Commerce deve ser capaz de funcionar nas verses mais recentes
dos principais browsers da atualidade e possuir um design responsivo, que ir se adaptar
automaticamente s telas de celulares, tablets, PC e Smart TV. Quanto sua
disponibilidade, o sistema deve estar on-line conectado aos bancos de dados
corporativos vinte e quatro horas por dia, sete dias por semana e com tempo de resposta
mnimo para cada ao solicitada pelo usurio.


1.4 Gesto e Restries Tcnicas

Com o intuito de produzir um software de alta qualidade e acelerar os prazos de
desenvolvimento do projeto proposto, o sistema 14commerce ser implementado
atravs de mtodos, prticas e tcnicas do Scrum, que uma metodologia de
desenvolvimento gil e defende a utilizao somente de documentao suficiente e
necessria para ajudar no desenvolvimento do projeto, porque possui um escopo
dinmico e suscetvel a mudanas de requisitos.
Segundo Fonseca (2009), Scrum so times trabalhando como uma unidade
altamente integrada com cada membro desempenhando um papel bem definido e o time
inteiro focando num nico objetivo, a entrega do produto. A referida metodologia
bastante objetiva, com propsitos claros, equipe coesa, flexvel e comprometida.
Utilizando o Scrum no possvel prever todas as atividades que sero realizadas no
decorrer do desenvolvimento do software. A ferramenta bem encaixada em trabalhos
complexos, por oferecer um framework e um conjunto de prticas que garantem a
visibilidade, isso possibilita que a equipe engajada no projeto possa ter uma viso clara
dos fatos que ocorrerem e quando necessrio, realizar customizaes visando alcanar
os objetivos previstos.
Os product owner, scrum master, scrum team e stakeholders so papis
definidos na metodologia Scrum para uma equipe multidisciplinar. Cada um possui
diversas responsabilidades, a fim de garantir a produo da lista de requisitos, o
funcionamento do ambiente Scrum, a entrega do produto, o auto-gerenciamento de suas
prprias atividades, dentre outras tarefas. A Figura 1 demonstra o funcionamento do
Scrum, ilustrando o ciclo de seu desenvolvimento de forma simplificada.
7


Figura 1: Ciclo do Scrum

O ciclo do Scrum inicia-se com o Product Backlog, que uma lista de itens
priorizados contendo todas as tarefas que precisam ser realizadas e tudo que agrega
valor ao negcio para finalizao do projeto, sejam requisitos funcionais ou no.
Segundo Schwaber (2004), o ciclo do Scrum tem um progresso baseado em iteraes,
com durao mdia de 02 a 04 semanas, chamadas Sprints. Antes de cada Sprint
realizada uma reunio de planejamento que promove o encontro entre o time do Scrum
e o cliente, a fim de priorizar o trabalho que precisa ser realizado, selecionar e estimar
as tarefas que o time ir realizar durante a Sprint. O produto dessa reunio o Sprint
Backlog que so os itens do Backlog j priorizados para a Sprint. Durante a execuo de
cada Sprint, o time realiza o controle do andamento do desenvolvimento atravs de
reunies dirias rpidas, com durao mxima de 15 minutos. Ao final de cada Sprint,
realizada uma reunio de reviso onde o time apresenta o produto gerado, a fim de
garantir que tudo foi realmente implementado e que o objetivo da Sprint foi atingido.
Assim que o processo finalizado, realizada uma reunio de retrospectiva para
melhorar o processo, time e/ou produto para a prxima Sprint.
Para implementar o 14commerce o time ir utilizar a linguagem de script open
source denominada PHP (Hypertext Preprocessor) por ser muito utilizada. A PHP foi
especialmente criada para o desenvolvimento de aplicaes Web. Por outro lado, o
sistema de gerenciamento de banco de dados ser MySQL.


2. ESTIMATIVAS DO PROJETO

Na estimativa so realizados clculos para mensurar o tempo das fases do
projeto, bem como seu planejamento, requisitos, anlise, projeto, implementao e
testes, e por consequncia, seu tempo total.
de fundamental importncia a utilizao de ferramentas e tcnicas que
permitam ao gestor do projeto uma viso ampliada da durao total das fases previstas
no plano, a fim de que seja possvel avaliar e melhorar sempre que necessrio.
8

As estimativas de custo, esforo e tempo do projeto sero realizadas utilizando-
se a tcnica de estimao de projetos de softwares orientados a objetos da Lacertae
Software e as mtricas correspondentes.


2.1 Dados histricos para estimativas do projeto

Tendo em vista que esta a primeira vez que utilizaremos o modelo da Lacertae
Software para desenvolvimento de nossos produtos software, no possumos dados
histricos para auxiliar nas estimativas deste projeto.

2.2 Tcnicas de estimativas e resultados

Para calcular o tempo de cada fase do projeto de implementao da
14Commerce ser utilizada a mtrica orientada a classes de Lorenz & Kidd adotada pela
Lacertae SW, destacada por ser simples e fcil de utilizar.
Os passos que devem ser seguidos na utilizao da mtrica de Lorenz & Kidd
so:
1) Definir a quantidade de classes chave que esto contidas no domnio do
problema;
2) Classificar o tipo de interface do produto, baseado na Tabela 2 e desenvolver um
multiplicador para a as classes de suporte:
3) Obter o nmero de classe de suporte, que o produto do multiplicador da
interface definido na Tabela 2 pela quantidade de classes chaves;
4) Calcular a quantidade total das classes que obtida atravs da soma do nmero
de classes chaves com o nmero de classes de suporte;
5) Multiplicar a quantidade total de classe obtida no item anterior pelo nmero
mdio de unidades de trabalho (dias-pessoa) por classe e justificar a escolha
(Lorenz e Kidd sugere um valor entre 15 e 20 dias-pessoa por classe);
6) Determinar a quantidade de esforo estimada;
7) Baseado nas informaes coletadas, calcular o tempo previsto para elaborao
do projeto.

Interface Multiplicador
No grfica 2
baseada em texto 2,25
GUI 2,5
GUI complexa 30
Tabela 2: Classificao dos tipos de interface
Na Tabela 2 so mostrados os tipos de interfaces com o usurio. Para o projeto
14Commerce foi escolhido a interface GUI onde o fator multiplicador 2,5. Uma
9

explicao mais detalhada sobre o porqu da escolha desta interface ser apresentada na
subseo 2.3 deste projeto.
Na Figura 2 mostrado o diagrama de classes que serviu como base para utilizao
desta tcnica.

Figura 2: Diagramas de classes

O diagrama de classes apresentado na Figura 2, mostra as classes chaves do
projeto 14Commerce. Nele possvel identificar as classes administrador, cliente,
usurio, produto, carrinho de compras e configuraes. Nas classes carrinhos de
compras e configuraes encontram-se as principais funcionalidades do projeto que
sero implementadas.

2.3 Resultados

Aps a anlise do diagrama de classes e aplicao da tcnica de estimativas de
Lorentz & Kidd os seguintes resultados foram obtidos:
1) Nmero de classes chaves: 05 classes. Apesar do diagrama de classes na Figura
2 apresentar 6 classes, a classe Usurio apenas um superclasse criada para que
as subclasses Administrador e Cliente pudessem existir;
2) Tipo de interface com usurio: GUI simples, assim o fator multiplicador
utilizado ser 2,5, conforme destacada na Tabela 2. Esse tipo de interface com o
usurio foi escolhido devido ao software que ir apresentar uma interface web
simples, onde apesar da necessidade de uma interface grfica, recursos
avanados no sero utilizados;
3) Nmero de classes de suporte: nmero de classes chaves X fator multiplicador
(5 X 2,5) = 12,5;
4) Nmero total de classes do projeto: nmero de classes chaves + nmero de
classes de suporte (5 + 12,5) = 17,5;
10

5) Unidade mdia de trabalho por classe utilizada: 20 dias-pessoa. Valor
escolhido em conjunto pelos integrantes da equipe, pelo fato de ser a primeira
vez que esto trabalhando juntos, alm do fato de nunca terem trabalhado
utilizando a metodologia Scrum e o framework de desenvolvimento PHP
codeigniter;
6) Clculo da quantidade de esforo estimada: nmero total de classes do
projeto x quantidade de dias-pessoa por classe (17,5 X 20) = 350 dias de
trabalho. Porm precisamos identificar quantidade de dias corridos de trabalho,
para isso, multiplicaremos a quantidade de dias de trabalho por 30 (quantidade
mdia de dias de um ms) e dividimos por 22 (quantidade mdia de dias teis
por ms) assim teremos o seguinte resultado: (350 X 30 / 22) = 477,2, ou seja
aproximadamente 478 dias corridos;
7) Tempo previsto para elaborao do projeto: considerando que a equipe do
projeto possui 03 membros, ento dividiremos a quantidade de dias corridos
encontrados pela quantidade de membros do projeto (477,2 / 3) = 159,1 dias por
membro da equipe. Dividindo o valor encontrado por dia 30 (quantidade mdia
de dias em um ms), conclumos que o tempo previsto para a elaborao deste
projeto de aproximadamente 5,3 meses.

Ao utilizar esta tcnica de estimativa, foram considerados como dias teis, a
quantidade mdia de dias em um ms (22 dias). Assim os valores aqui apresentados
podero sofrer alguma diferena ao serem comparados com a quantidade de dias reais
de trabalho que ser apresentado na seo 4 deste projeto, mais especificamente no
diagrama de Gantt. Isso devido ao fato de se utilizar um calendrio contendo meses com
diferentes quantidades de dias teis.

2.4 Recursos do projeto

Sero utilizados diversos recursos neste projeto, sendo eles humanos, de
software; de hardware e bibliogrficos.


Recursos Humanos

A equipe de desenvolvimento do projeto formada por trs membros que esto
elencados na Tabela 3.

NOME PAPEL
Ben Hur Neres de Barros Scrum team e Product Owner
Fernanda Gomes Silva Scrum team e Scrum Master
Josimar de Souza Lima Scrum team
Tabela 3: Recursos humanos do projeto

Na Tabela 3 so mostrados os recursos humanos envolvidos no projeto e o papel
que cada um desempenhar. Por se tratar de uma equipe com nmero de integrantes
11

inferior ao recomendado pela metodologia Scrum, alguns membros da equipe tero que
assumir mais de um papel.

Recursos de Software

As ferramentas que sero utilizadas no desenvolvimento deste projeto esto
apresentadas na Tabela 4.

FERRAMENTA DESCRIO
Eclipse for PHP Developers IDE Eclipse para desenvolvedores PHP
Visual Paradigma Ferramenta case para modelagem UML
LAMP (Linux-Apache-Mysql-
PHP)
Combinao de softwares para desenvolvimento web
Framework Codeigniter
Framework de cdigo livre para desenvolvimento de
aplicaes PHP
Microsoft Project 2013
Ferramenta de gerenciamento das atividades do
projeto
Google Drive
Ferramenta utilizada para compartilhamento de
arquivos do projeto
GIT Sistema de controle de verso distribudo
Microsoft Office 2013
Utilizado em conjunto com Google Drive para manter
a documentao do projeto
Blogger Recurso de criao de blogs do google
Tabela 4: Recursos de software

A Tabela 4 mostra os recursos de software utilizados neste projeto. Alm das
ferramentas bsicas para o desenvolvimento web tambm sero utilizados um software
de gerenciamento de projetos, de controle de verso e edio de documentos.

Recursos de Hardware

Para o desenvolvimento deste projeto ser necessria aquisio de trs notebooks
para os membros da equipe, no havendo necessidade de utilizar nenhum hardware
especfico.





12

3. ANLISE E GESTO DE RISCOS

Para ALENCAR e SCHMITZ (2006), o risco a probabilidade de que um fator
acontea e venha prejudicar, total ou parcialmente, as chances de sucesso de um projeto,
ou seja, as chances do projeto no realizar o que foi proposto dentro do prazo e fluxo
estabelecidos.
Por isso, a gerncia de riscos considerada parte fundamental na gesto de
projetos, j que aumenta consideravelmente a possibilidade do mesmo ser concludo
com sucesso.
Os projetos sofrem mudanas constantemente e seus gestores precisam
identificar os riscos, avaliar a probabilidade de sua ocorrncia e medir seu impacto.
Existem diversos fatores que podem influenciar diretamente no fracasso do
projeto, sejam mudanas no paradigma, nas leis, evoluo da tecnologia, alteraes nos
requisitos do sistema, aquisio de ferramentas e tecnologias, sada de membros da
equipe, dentre diversos outros.
No desenvolvimento de software, por exemplo, por ser uma atividade complexa
faz com que grande parte dos projetos desse tipo exceda os prazos de entrega e custos
previstos, alm de no conseguir atender todas as expectativas de seus clientes
referentes a funcionalidades e qualidade.
Diante disso, faz-se necessria a utilizao de tcnicas de gerncia de riscos e
uma preparao da equipe para garantir a identificao e administrao das incertezas
do projeto.

3.1 Riscos do projeto

Existe um conjunto de riscos que esto presentes na maioria dos projetos de
desenvolvimento de softwares, sendo considerados riscos gerais. Na Tabela 5, so
apresentados alguns riscos gerais.

Risco Projeto Tcnico Negcio Comum Especial
Equipamento no disponvel

x

Requisitos incompletos x

x

Uso de metodologia especial

x

x
Reteno de pessoas chaves x

x

Sub estimativas de esforos x

x

Concorrncia do mercado

x

Tabela 5: Riscos gerais comuns a maioria dos projetos de softwares

13

A Tabela 5 mostra os principais riscos gerais, comum a maioria dos projetos.
Percebe-se que alguns riscos se enquadram em mais de uma categoria, o que demanda
ainda mais ateno para o seu gerenciamento.
Os riscos especficos deste projeto de software foram detectados a partir da
tcnica de questionamento sugerida por Pressman (2011), a fim de que possamos
realizar uma avaliao global das incertezas que possam acontecer durante a
implementao do sistema 14Commerce. A seguir sero apresentados estes
questionamentos e a respostas que levaram ao levantamento dos principais riscos do
projeto.

1) Os gestores do Software e Cliente do suporte ao projeto?
Sim, dentro do Scrum, processo utilizado para desenvolvimento do produto, o
papel do cliente representado pelo product Owner. No entanto no existe o
papel do gerente do projeto porque as equipes scrums so auto gerenciveis. O
que existe o papel do scrum master que responsvel por fazer com que o
scrum seja entendido e aplicado.

2) Os clientes esto entusiasmados com o projeto e o produto?
Sim, o product Owner que representa o cliente est bastante entusiasmado com o
produto que est sendo desenvolvido, no entanto existe um risco envolvido por
se tratar de uma loja virtual que ser vendida para diversos outros clientes.

3) Os Engenheiros de Software e os clientes entendem bem os requisitos?
Sim, por se tratar de uma loja virtual os requisitos principais so conhecidos, os
demais esto sendo cuidadosamente levantados e analisados.

4) Os clientes estiveram envolvidos na definio de requisitos?
Sim, pois ao se utilizar o Scrum o cliente parte integrante da equipe do projeto

5) As expectativas dos utilizadores so realistas?
Os utilizadores do produto ainda no so conhecidos, ser criado um plano de
reduo de riscos especificamente para conhecer os possveis utilizadores do
produto.

6) O mbito do Projeto estvel?
No, o mbito do projeto suscetvel a mudanas, visto que o produto final ser
uma loja virtual totalmente customizvel.

7) Os Engenheiros tm competncia requerida?
No, apesar da equipe j ter trabalhado em diversos outros projetos, nunca
trabalharam com as metodologias que sero utilizadas nesse projeto. Por essa
razo tero que passar por treinamento especfico.

8) A equipe de desenvolvimento tem experincia na tecnologia a ser
implementada?
No, a equipe do projeto possui pouca experincia com o framework PHP que
ser utilizado. No entanto, a equipe tem experincia com tecnologias
semelhantes, o que diminuir a curva de aprendizagem.
14



3.2 Tabela de riscos

Os riscos do projeto foram identificados a partir da avaliao global e anlise
dos requisitos do negcio. Na Tabela 6, podemos encontrar os riscos que foram
detectados, devidamente categorizados, com a indicao da probabilidade de ocorrncia
e seu impacto esperado no projeto.

Sequncia Risco Categoria Probabilidade Impacto
001
Equipe do projeto no se
adaptar ao modelo de equipe
auto-gerencivel do Scrum.
projeto 70 catastrfico
002
Sistema no oferecer a
segurana necessria para os
clientes
tcnico 70 catastrfico
003
No conhecer as expectativas
dos possveis clientes
negcio 80 crtico
004
Sistema depende de sistemas
externos (ex. Paypal, Mercado
Pago, Correios)
projeto 80 crtico
005
Equipe do projeto no possui
quantidade de membros
recomendados pelo Scrum
podendo prejudicar a aplicao
do processo
pessoal 80 crtico
006
Quantidade elevada de usurios
de um mesmo cliente prejudica
a performance do sistema
tcnico 70 crtico
007
Falta de conhecimento nas
tecnologias utilizadas
tcnico 60 crtico
008
Encontrar componentes
reutilizveis de outros projetos
ou na internet que podem ser
adaptados ao projeto (risco
positivo)
projeto 40 crtico
009
O cliente no perceber que o
sistema possui diferenciais
competitivos em relao a lojas
virtuais disponveis no mercado
negcio 40 crtico
15

010
O processo escolhido no
permite que se tenha uma
equipe exclusiva para testes
podendo fazer com que o
produto seja entregue com
nmero grande de defeitos.
projeto 40 crtico
011
Prazo curto para entrega do
projeto
projeto 40 crtico
012
Sistema possui tempo de
resposta insatisfatrio
tcnico 30 crtico
013
Mudana de alguma das
tecnologias utilizadas
tcnico 30 crtico
014
Desenvolver o projeto antes
prazo atendendo a todos os
requisitos com qualidade (Risco
positivo)
projeto 10 crtico
015
O potencial cliente no perceber
que o sistema possui
diferenciais competitivos em
relao a lojas virtuais
disponveis no mercado
negcio 40 marginal
016
Dificuldade em deslocar os
membros da equipe para
treinamentos especficos nas
tecnologias utilizadas
projeto 40 marginal
017
O sistema no possui uma
interface com usurio intuitiva
tcnico 20 marginal
Tabela 6: Todos os riscos do projeto 14Commerce

Na Tabela 6 so os mostrados os riscos detectados, devidamente categorizados,
com a indicao da probabilidade de ocorrncia e seu impacto esperado no projeto. As
estratgias de reduo dos mesmos podem ser observadas na seo 3.3.


3.3 Reduo e gesto dos riscos

Foi determinado um ponto de corte, priorizando o tratamento dos riscos com
maior probabilidade de impacto. Foram extrados da Tabela 6 nove riscos para
descrevermos as aes estratgicas de reduo e o plano de contingncia, a fim de
16

reduzir ou gerir os riscos encontrados. Sendo assim, na Tabela 7 esto descritas essas
aes estratgicas de reduo e os planos de contingncias de cada um deles.

Equipe do projeto no se adaptar ao modelo de equipe auto gerencivel do
Scrum
RISCO: 001 PROB: 70% IMPACTO: Catastrfico
Descrio: Por no estar acostumada a utilizar o Scrum como processo de
desenvolvimento, a equipe do projeto poder no se adaptar ao modelo auto
gerencivel do Scrum, ocasionando perda de desempenho e at o fracasso do projeto.
Estratgia de Reduo: Realizao de treinamento especfico com os membros da
equipe focando na importncia da equipe Scrum para projetos geis.
Plano de contingncia: Contratar um profissional experiente em aplicao de
processos Scrum para que o mesmo possa conduzir a equipe durante o perodo de
adaptao ao novo processo.
Pessoa responsvel: Ben Hur Neres de Barros
Status: Em andamento

O sistema no oferece a segurana necessria para os clientes
RISCO: 002 PROB: 70% IMPACTO: Catastrfico
Descrio: Por se tratar de um sistema que envolve transaes financeiras o sistema
deve oferecer segurana necessria para o cliente.
Estratgia de Reduo: Todas as requisies do sistema devem ser implementadas
utilizando o protocolo HTTPS. A etapa de teste tambm destinar parte do esforo
empenhado nas questes de segurana,
Plano de contingncia: Capacitar a equipe com treinamentos focado em recuperar
sistemas invadidos e verificar a possibilidade de contratao de servios de uma
empresa especializada para garantir que as falhas encontradas sejam corrigidas
Pessoa responsvel: Fernanda Gomes Silva
Status: Em anlise

No conhecer as expectativas dos futuros clientes
RISCO: 003 PROB: 80% IMPACTO: Crtico
Descrio: Por se tratar de um sistema que ser disponibilizado para venda apenas
aps ser concludo, existe o risco de que o sistema no atenda as expectativas dos
futuros clientes uma vez que sua principal caracterstica atender a diversos tipos de
negcios.
Estratgia de Reduo: Fazer o levantamento de requisitos levando em
considerao cada provvel tipo de negcio que o sistema pretende atender. Construir
o sistema com foco na escalabilidade.
Plano de contingncia: Priorizar a implementao das funcionalidades crticas dos
clientes ativos do sistema. medida que novos clientes adquiram o produto elabora
um plano de implementao baseado em suas necessidades.
Pessoa responsvel: Josimar de Souza Lima
Status: Em andamento

O sistema depende de sistemas externos (Paypal, Cartes de Crdito, Correios
entre outros)
17

RISCO: 004 PROB: 80% IMPACTO: Crtico
Descrio: Sistemas ecommerces normalmente utilizam sistemas externo para
realizao de algumas funcionalidades tais como formas de pagamento e rastreio dos
produtos adquiridos atravs do site dos correios. Caso alguma destas funcionalidades
esteja indisponvel, o cliente ficar insatisfeito.
Estratgia de Reduo: Utilizar mais de um sistema externo com a mesma
finalidade. Por exemplo, Em relao da forma de pagamento utilizar ao mesmo tempo
o Paypal e o Mercado Pago. Em relao ao pagamento com cartes de crdito
disponibilizar a possibilidade de pagar atravs de deposito bancrio. Em relao ao
sistema dos correios, salvar as informaes a cada requisio em um banco de dados
prprio para que, em caso de indisponibilidade de conexo com o site dos correios, o
cliente consiga acompanhar o andamento dos seus pedidos at a conexo ser
reestabelecida.
Plano de contingncia: Implementar funcionalidades que possam sugerir alternativas
ao cliente caso algum sistema externo esteja indisponvel. Em relao ao sistema dos
correios redirecionar as requisies para o banco de dados prprio do 14commerce.
Pessoa responsvel: Josimar de Souza Lima
Status: Em andamento

Equipe do Projeto no possui quantidade de membros recomendada pelo Scrum
podendo prejudicar a aplicao do processo.
RISCO: 005 PROB: 80% IMPACTO: Crtico
Descrio: De acordo com o Scrum Guide recomendado que projetos Scrum
tenham equipes com no mnimo 5 ou no mximo 9 integrantes. Inicialmente foram
alocados apenas 3 membros para realizao do projeto.
Estratgia de Reduo: Fazer com que alguns membros assumam mais de um papel
entre os trs definidos pelo Scrum.
Plano de contingncia: Analizar e viabilizar a possibilidade contratao temporria
de profissionais para compor a equipe.
Pessoa responsvel: Ben Hur Neres Barros
Status: Em anlise

Quantidade elevada de usurios de um mesmo cliente pode prejudicar a
performance do sistema
RISCO: 006 PROB: 70% IMPACTO: Crtico
Descrio: Quanto maior for a quantidade de usurios de um mesmo cliente, melhor
ter que ser a infraestrutura para que o sistema funcione perfeitamente. Um grande
nmero de usurios de um mesmo cliente conectados ao mesmo tempo poder afetar
a performance do sistema.
Estratgia de Reduo: Criar planos diferenciados limitando a quantidade de
usurios de um mesmo cliente utilizando o sistema simultaneamente. Fazendo com
que o cliente seja cobrado um valor adicional medida que seus clientes ultrapassem
os valores pr-definidos dos planos contratados inicialmente.
Plano de contingncia: Implementar relatrios de acessos com indicadores
sugerindo ao administrador do sistema qual plano ideal baseado na quantidade de
usurios simultneos.
Pessoa responsvel: Fernanda Gomes Silva
Status: Concludo

18

Falta de Conhecimento nas Tecnologias Utilizadas
RISCO: 007 PROB: 60% IMPACTO: Crtico
Descrio: A equipe projeto ir utilizar um framework de desenvolvimento PHP que
ainda no domina completamente. Assim existe o risco que no conseguir usufruir
totalmente dos benefcios que o framework traz.
Estratgia de Reduo: Aquisio de cursos online sobre os frameworks que sero
utilizados no projeto e disponibilizar um perodo antes do incio do projeto para que
os membros da equipe possam fazer estes cursos
Plano de contingncia: Viabilizar a contratao de empresa especializada em
treinamento para capacitar os membros da equipe do projeto.
Pessoa responsvel: Fernanda Gomes Silva
Status: Concludo

Componentes reutilizveis podem ser adaptados ao projeto (Risco positivo)
RISCO: 008 PROB: 40% IMPACTO: Crtico
Descrio: Existem diversos componentes prontos que podem ser reaproveitados em
grande parte dos projetos que esto sendo desenvolvidos. Estes componentes tanto
podem ter sido criados para um projeto semelhante pela prpria empresa que est
desenvolvendo o software como podem ser adquiridos atravs de sites na internet.
Estratgia de Reduo: O objetivo deste tpico no reduzir e sim aumentar a
possibilidade que este risco acontea. Para isso sero organizadas reunies
estratgicas apenas para tratar deste assunto. Alm disso, designar um dos membros
da equipe a responsabilidade de sempre estar buscando solues prontas para as
necessidades que forem levantadas pelo representante do cliente no reunies de
planejamento.
Plano de contingncia: Por se tratar de um risco positivo, o plano de contingncia
tambm tem objetivo contrrio ao que se est acostumado. Caso o risco acontea,
ser necessria a realocao das tarefas restantes e elaborao de uma nova reunio
de planejamento.
Pessoa responsvel: Josimar de Souza Lima
Status: Em anlise

O potencial cliente no perceber que o sistema possui diferenciais competitivos
em relao a lojas virtuais disponveis no mercado
RISCO: 009 PROB: 40% IMPACTO: Crtico
Descrio: Existe o risco de que o potencial cliente no perceba os diferenciais
competitivos que ter ao adquirir a loja virtual 14commerce quando comparada com
outras lojas virtuais disponveis no mercado
Estratgia de Reduo: Criar uma estratgia de divulgao do projeto focando
especificamente nas vantagens que se tem ao adquirir o sistema 14commerce
disponibilizando verses de demonstrao da ferramenta e disponibilizando casos de
sucessos.
Plano de contingncia: Organizar eventos de demonstrao com sorteios de licenas
e promoes com objetivo de demostrar aos potenciais clientes todas as vantagens
que ter em adquirir o sistema 14Commerce
Pessoa responsvel: Josimar de Souza Lima
Status: Em andamento
Tabela 7: Plano de reduo de riscos do projeto
19


Na Tabela 7 so mostrados os planos de reduo de riscos do projeto. Esto
sendo contemplados os riscos relativos segurana, implementao do sistema, ao
processo de desenvolvimento, e at mesmo, riscos positivos que podem beneficiar o
projeto caso aconteam.

4. PLANEJAMENTO TEMPORAL

Foram definidas as datas de execuo de todas as atividades previstas no projeto
14Commerce e os membros da equipe sero responsveis por cada uma delas,
utilizando o Diagrama de Gantt construdo na ferramenta para gesto de projetos MS
Project da Microsoft.


4.1 Conjunto de tarefas do projeto

Aps a obteno do esforo com a aplicao da tcnica de estimativas da
Lorentz & Kidd, o tempo do projeto foi dividido entre planejamento, anlise, gerao de
cdigo e testes conforme apresentado na Tabela 8.

Tarefas Percentagem do tempo Dias de atividades
Planejamento 2% 03
Anlise 40% 64
Gerao de cdigo 20% 32
Testes 38% 60
Tabela 8: Diviso das tarefas do projeto


4.2 Diagrama de Gantt

Atravs do diagrama de Gantt possvel ilustrar e acompanhar o avano das
diversas atividades previstas em um projeto, pois a ferramenta MS Project, utilizada
nesse projeto, permite o cadastro dos intervalos de tempo que representam o incio e fim
de cada fase e apresenta essas informaes atravs de grficos. As tarefas previstas no
projeto so associadas aos elementos da equipe do projeto e esto divididas por Sprint
de acordo com a metodologia adotada, como podem ser observadas nas Figuras 3, 4, 5,
6 e 7.

20


Figura 3: Cronograma do projeto (Parte 1)
21


Figura 4: Cronograma do projeto (Parte 2)
22


Figura 5: Cronograma do projeto (Parte 3)
23


Figura 6: Cronograma do projeto (Parte 4)
24


Figura 7: Cronograma do projeto (Parte 5)

possvel verificar no cronograma do projeto demonstrado nas Figuras 3, 4, 5, 6 e 7, a diviso das tarefas, em dias, de planejamento,
anlise, gerao de cdigo e testes. A tarefa reunio de planejamento ocorre nas seis Sprints definidas para o projeto, com durao de 0,5 dias,
totalizando os trs dias previstos na Tabela 7 para a tarefa planejamento. J a tarefa anlise e prototipao do referido cronograma, ocorre em cada
uma das vinte funcionalidades definidas, com durao de 3,2 dias, totalizando os 24 dias de anlise previstos na Tabela 7. A codificao est
prevista nas vinte funcionalidades com durao de 1,6 dias, confirmando os 32 dias de atividades da Tabela 7. E por fim, as tarefas de
planejamento de testes em cada funcionalidade, execuo dos testes e correo que ocorre a cada Sprint totalizam os 60 dias apresentados na tarefa
de testes da Tabela 7.
26

5. ORGANIZAO DO PESSOAL

Nesta seo ser apresentada a forma como a equipe est organizada. Sero
apresentados os membros da equipe Scrum, os mecanismos de comunicao utilizados e
o uso das tecnologias de apoio ao desenvolvimento do projeto.

5.1 Estrutura da equipe

Por se tratar de um projeto que utilizar a metodologia gil Scrum, existem
apenas trs papeis definidos: o Scrum master, o Product Owner e a Scrum Team uma
tabela detalhando o papel de cada membro da equipe pode ser visto na subseo 2.4 que
explica detalhadamente os recursos do projeto.

5.2 Mecanismos de comunicao

A equipe do projeto utilizar como principal estratgia de comunicao as
reunies dirias que uma das caractersticas encontradas na metodologia Scrum, onde
cada membro da equipe informa o que fez no dia anterior o que far no dia atual e quais
as dificuldades encontradas para realizar suas atividades. Alm disso, sero utilizados
softwares de comunicao e colaborao tais como gtalk, googledrive, skype e
whatsapp.

5.3 Uso do Edu-blog como ferramenta de apoio

O Edu-blog se mostrou uma ferramenta essencial durante a realizao projeto,
pois atravs dos modelos disponibilizados foi possvel utilizar as melhores prticas
propostas pela disciplina. Alm disso, foi criado um Edu-blog para a comunicao entre
os membros do projeto e o professor da disciplina, para colaborao entre os membros
da equipe optou-se por utilizar o googledrive.


6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW

Para assegurar e controlar a qualidade do produto desenvolvido por este plano de
projeto, os itens que seguem foram utilizados em todo o projeto:

Utilizao dos princpios do manifesto gil;
Utilizao do Scrum como medologia gil de desenvolvimento;
27

Utilizao do modelo de planejamento de projeto da Lacertae Software;
Utilizao de mtricas para estimativa da durao do projeto;
Utilizao de tcnica de anlise de riscos e estratgias de reduo dos riscos
identificados;
Aplicao de testes.
28

7. REFERNCIAS BIBLIOGRFICAS

ALENCAR, A. J., SCHMITZ, E. A., Anlise de Risco em Gerncia de Projetos. Rio
de Janeiro, Editora Brasport, 2006.

CodeIgniter User Guide. Disponvel em: <http://ellislab.com/codeigniter/user-guide>
Acesso em: 15 de Abril. 2014

Guia do Scrum. Disponvel em: <https://www.scrum.org/Portals/0/Documents/
Scrum%20Guides/Scrum%20Guide%20-%20Portuguese%20BR.pdf> Acesso em: 10
de Abril. 2014

Visual paradigma paradigma for UML user Guide. Disponvel em:
<http://www.visual-paradigm.com/support/documents/vpumluserguide.jsp> Acesso em:
01 de Abril 2014

Guia rpido Project 2013. Disponvel em: <http://office.microsoft.com/pt-
br/support/guia-de-inicio-rapido-do-project-2013-HA103673696.aspx>Acesso em: 12
de Abril 2014
LORENZ. M, KIDD J.,Object-Oriented Software Metrics, Prentice Hall, 1994

MACHADO, M., MEDINA, S. SCRUM - Mtodo gil: uma mudana cultural na
Gesto de Projetos de Desenvolvimento de Software.

PRESSMAN, Roger S. Software engineering: a practitioners approach.
5th ed. Boston: McGraw-Hill, c2011. 860 p

PEREIRA, P.; TORREAO P.; MARCAL, A.S. Entendendo Scrum para Gerenciar
Projetos de Forma gil, revista Mundo PM. So Paulo. v.14 abr./maio 2007.

SCHWABER K., Agile Project Management With Scrum, Microsoft, 2004.