Gt5 - Plano de Projeto

UNIVERSIDADE FEDERAL DO AMAZONAS

INSTITUTO DE COMPUTAÇÃO

PLANO DE PROJETO DE SOFTWARE

Desenvolvimento de Sistema E-Commerce

Equipe:

Afranio Lopes Lucas

Alexandre Braga Damasceno

Arlesson de Souza dos Anjos

Heber Santiago

Manoel da Silva Mota

Ramayana Júnior

Professor:

Rogerio P. C. do Nascimento

Manaus - AM

2011

Sumário

1.0 INTRODUÇÃO........................................................................................................................3

1.1 Âmbitos do Projeto............................................................................................................3

1.2 Funções principais do produto de software........................................................................4

1.3 Requisitos comportamentais ou de performance................................................................6

1.4 Gestão e Restrições Técnicas..............................................................................................6

2.0 ESTIMAÇÃO DO PROJETO.....................................................................................................7

2.1 Dados históricos utilizados para as estimações...................................................................7

2.2 Técnicas de estimação e resultados....................................................................................7

2.2.1 Técnica de estimativa.................................................................................................7

2.3 Resultados.........................................................................................................................8

2.4 Recursos do projeto...........................................................................................................9

2.4.1 Recursos de Software.................................................................................................9

2.4.2 Recursos de Hardware..............................................................................................10

3.0 ANÁLISE E GESTÃO DE RISCOS..........................................................................................10

3.1 Riscos do projeto..............................................................................................................11

3.2 Tabela de risco.................................................................................................................12

3.3 Redução e Gestão do Risco..............................................................................................13

4.0 PLANEJAMENTO TEMPORAL...............................................................................................17

4.1 Conjunto de Tarefas do Projeto........................................................................................17

4.2 Diagrama de Gantt...........................................................................................................17

5.0 ORGANIZAÇÃO DE PESSOAL...............................................................................................18

5.1 Estrutura da Equipe.........................................................................................................18

5.2 Mecanismo de Comunicação..........................................................................................18

5.3 Uso do EduBlog como ferramenta de apoio....................................................................19

Anexo I.......................................................................................................................................20

Anexo II......................................................................................................................................21

1.0 INTRODUÇÃO

Tendo em vista a ampliação do comércio eletrônico nos últimos anos a Empresa decidiu

criar um novo E-Commerce para entrar preparada nesse mercado tão promissor. Atualmente a

Empresa possui um site de vendas on-line que por ser terceirizado não tem a integração

desejada com os sistemas utilizados para controle de todo o processo de venda. Além da maior

integração a empresa pretende incluir novas funcionalidades para melhor atender seus

clientes.

1.1 Âmbitos do Projeto

A Empresa visa desenvolver um novo sistema para:

■ Prover o auto-atendimento virtual que permita fazer solicitações, sem ter a necessidade

de deslocamento do mundo virtual para o físico. “O cliente só vai a Loja física se

quiser”.

■ Elevar a competitividade da Empresa em relação aos seus concorrentes, oferecendo

serviços e valores diferenciados para os clientes.

■ Expandir a atuação do comercio eletrônico na região de Manaus e demais regiões do

País.

■ Aproximar o cliente da Empresa.

■ Estabelecer novos critérios de relacionamento com os clientes recorrentes, de acordo

com o volume e histórico de compras, regionalidade e hábitos de consumo.

■ Fazer uso das redes sociais e mobile, como recurso de relacionamento com o cliente,

na captação de vendas e novos clientes.

■ Ter uma plataforma tecnológica em ambiente distinto para manter o comércio

eletrônico, provido por recursos de segurança, administração e medição dos processos

virtuais.

3

■ Obter flexibilidade para implantação de estratégias de negócio com margem à

escalabilidade e sustentabilidade para o crescimento do negócio virtual.

■ Integrar todos os sistemas da operação física com a plataforma de comércio eletrônico.

1.2 Funções principais do produto de software

Após entrevistar todas as pessoas das áreas envolvidas no processo e estudar a

documentação dos sistemas existentes foi possível identificar que o novo sistema deve:

■ Permitir que o cliente mantenha seus dados pessoais.

■ Permitir que o cliente recupere sua senha.

■ Permitir que o cliente cadastre uma palavra-chave para auxiliá-lo caso ele esqueça sua

senha.

■ Permitir que o cliente modifique a sua senha.

■ Acumular pontos para o cliente a cada compra realizada.

■ Permitir ao cliente visualizar suas últimas compras.

■ Recomendar ao cliente produtos baseado no seu padrão de compras.

■ Permitir ao cliente comparar produtos.

■ Integrar promoções com as redes sociais.

■ Exibir o catálogo de produtos organizados em categorias e subcategorias.

■ Permitir ao cliente selecionar produtos e adicioná-los ao carrinho de compras, através

de Drag-and-Drop.

■ Permitir que o cliente escolha mais de um endereço de entrega.

■ Enviar a confirmação do pedido via email.

■ Aceitar as seguintes formas de pagamento: Cartão de Crédito, Débito e Boleto

Bancário.

■ Permitir ao cliente cadastrar sua lista de desejos.

■ Permitir aos administradores do site gerenciar os pedidos.

4

■ Gerar relatórios de pedidos.

■ Permitir aos clientes visualizar seus contratos com suas respectivas parcelas dando ao

cliente a opção para realizar o pagamento.

■ Permitir que o cliente utilize seus pontos de bônus para obter desconto nas compras.

■ Disponibilizar um chat para atendimento aos clientes.

■ Permitir a venda de recarga de celular.

■ Disponibilizar a lista das assistências técnicas.

■ Permitir ao cliente imprimir a 2ª via de notas fiscais.

■ Permitir ao cliente devolver produtos.

■ Disponibilizar a opção Fale Conosco.

■ Permitir aos clientes enviar sugestões de produtos.

■ Disponibilizar um formulário para pesquisa de satisfação.

■ Disponibilizar página para simulação de pagamento com cartão de Crédito.

■ Disponibilizar um formulário para cadastro de currículos.

■ Permitir cadastrar os dados das lojas físicas do grupo.

■ Permitir que o cliente ao realizar uma compra pelo site opte por retirar o produto em

qualquer loja que possua estoque.

■ Permitir que o vendedor realize venda assistida.

■ Permitir a identificação do cliente através do e-mail, código, CPF e CNPJ.

■ Bonificar o cliente em que ele se identificar com o CPF.

■ Enviar e-mail com promoções e orçamentos para os clientes que optarem em receber

essas informações.

■ Enviar SMS com promoções e notificações para os clientes.

■ Permitir o cadastro de promoções.

■ Deverá ter uma opção para exibição dos produtos mais vendidos.

■ Enviar notificações ao cliente agradecendo-o por ter se inscrito no site, por ter ido a uma

loja e também por ter realizado uma compra.

■ Permitir vendas de produtos para todo Brasil.

5

■ Permitir que o cliente efetue um pedido informado apenas o CPF e o endereço de

entrega.

■ Permitir informar para que região os produtos devam ser vendidos.

■ Permitir computar pontos para o vendedor responsável pela venda.

1.3 Requisitos comportamentais ou de performance

Após o levantamento das necessidades foi observado em relação aos requisitos

comportamentais ou performance que o sistema deve:

■ Possuir uma interface Web.

■ Estar disponível 24 horas por dia e 7 dias por semana, para uso do cliente. Cabendo

aos administradores a responsabilidade pela manutenção do sistema e a preocupação

com as falhas ou erros da rede elétrica e com os provedores de acesso onde o sistema

está hospedado.

■ Ser compatível com diversos sistemas operacionais, principalmente com as diversas

distribuições Linux.

■ Funcionar nos navegadores: Internet Explorer e Firefox.

1.4 Gestão e Restrições Técnicas

Seguem neste item as restrições para o desenvolvimento do sistema delimitando o

escopo em que o sistema deverá ser produzido.

■ O sistema deverá migrar os dados dos clientes do E-Commerce antigo para o novo.

■ O sistema deverá ser construído utilizando JSP e com integrações desenvolvidas

usando SAP PI.

■ Falta de experiência prática com as ferramentas e métodos utilizados para o

desenvolvimento.

6

2.0 ESTIMAÇÃO DO PROJETO

A estimação do projeto leva em consideração uma série de fatores tais como: número

de pessoas envolvidas, complexidade do projeto, material disponível para execução das

atividades, conhecimento técnico dos envolvidos, além de outros fatores. As estimativas

mostram ao gerente do projeto o que deverá ser feito em cada etapa de desenvolvimento e

quanto tempo cada uma delas irá consumir.

2.1 Dados históricos utilizados para as estimações

Por se tratar do primeiro projeto em que utilizaremos métricas para estimar o esforço

necessário para a produção do software, não temos dados históricos para apresentar.

2.2 Técnicas de estimação e resultados

Para estimar o prazo total do projeto, foi utilizada a métrica de Lorenz & Kidd,

apresentada pela Lacertae Software. A seguir demonstramos o cálculo realizado e os fatores

envolvidos.

2.2.1 Técnica de estimativa

Etapas de aplicação da técnica Lorenz & Kidd:

1. Definir o número de classes chave;

2. Encontrar o número de classes de suporte. Para isso temos que classificar o tipo de

Interface do Produto e selecionar um valor 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. Calcular a quantidade total de Classes, somando o número de Classes-Chave com o

número de Classes de Suporte;

7

5. Multiplicar a quantidade total de Classes (classes-chave + classes 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-20 dias-

pessoa e justificar a escolha.

6. Determinar a quantidade de esforço estimada;

7. Cálculo do tempo previsto para a elaboração do projeto.

A tabela abaixo mostra os fatores de multiplicação para encontrar a quantidade de

classes de suporte:

Interface MultiplicadorNão gráfica 2

Baseada em texto 2,25GUI 2,5

GUI complexa 3

Tabela 01: Fatores de multiplicação

2.3 Resultados

Para utilizar a métrica descrita no item 2.2.1 do diagrama de classes(Figura 01) em

anexo. Segue a aplicação do método:

1. Quantidade de classes chaves = 15;

2. Este sistema rodará na WEB. Então, a interface gráfica GUI = 2,5;

3. Classes chaves x multiplicador (15 x 2,5) = 38 classes de suporte;

4. Classes chaves + classes de suporte (15 + 38) = 53 classes projetada para o sistema;

5. Por falta de experiência da equipe em trabalhos do gênero, consideramos o

máximo de dias indicado pela métrica (20 dias-pessoa);

6. Calculando a quantidade de esforço estimado, temos: (53 x 20) = 1060 dias de trabalho;

7. Considerando 6 pessoas envolvidas no projeto, temos: 1060 dias ÷ 6 pessoas ≈ 176

(dias / pessoa), o que dividido por 22 (dias úteis / mês) resulta em um tempo total

aproximadamente 8 meses.

8

2.4 Recursos do projeto

Para que um projeto seja bem elaborado precisamos conhecer os recursos que serão

utilizados na produção do mesmo. Os recursos se dividem em: Recursos de Software e

Hardware.

2.4.1 Recursos de Software

Para o desenvolvimento deste projeto serão utilizadas as seguintes ferramentas de

Software:

■ SAP ERP – Sistema integrado de gestão empresarial (ERP).

■ SAP PI - Tecnologia de integração entre plataformas que visa prover um ponto único de

integração para todos os sistemas, SAP e não SAP.

■ Oracle - sistema de gerência de banco de dados relacional muito usado em empresas e

por grandes sistemas corporativos.

■ ABAP - É uma linguagem de programação de alto nível desenvolvida pela empresa de

software SAP.

■ MsProject - utilizado para facilitar a administração do projeto.

■ Microsoft Word - para fazer documentações simples.

■ JavaServer Pages (JSP) - Tecnologia utilizada no desenvolvimento de aplicações para

Web, browser de Internet.

■ Mozila Firefox, browser de Internet.

■ Eclipse - software que dá apoio ao desenvolvimento em Linguagem de programação

JAVA.

9

2.4.2 Recursos de Hardware

Para o desenvolvimento deste projeto serão utilizadas as seguintes ferramentas de

Hardware:

■ Computadores Pessoais PC.

■ Projetor para apresentações.

■ Impressora para testes de impressão.

■ Servidor de Desenvolvimento.

3.0 ANÁLISE E GESTÃO DE RISCOS

Na fase de Análise e Gestão de Riscos foi feito um brainstorming dos riscos potenciais

para o projeto de acordo com as necessidades e restrições de um sistema E-Commerce a

partir das especificações da Lacertae Software.

■ Cada membro do grupo identificou uma lista de riscos individualmente

■ Logo após, para cada risco da lista foi atribuído uma probabilidade e um impacto de

acordo com uma classificação predefinida pela equipe.

■ Em grupo juntamos todas as listas e fizemos uma análise circular em relação às

probabilidades e impacto.

■ A lista de riscos foi organizada em ordem decrescente em relação ao impacto e

probabilidade.

■ Por fim, foi feito o Plano de Redução, Supervisão e Gestão do Risco (RSGR), definindo

para cada risco uma Estratégia de Redução, um Plano de Contingência e o(s)

Responsável(eis) pela execução.

10

3.1 Riscos do projeto

A partir da Análise Circular feita pela equipe foi elaborada a tabela contendo todos os

riscos e sua classificação por área: 1.Projeto, 2.Técnico, 3.Negócio, 4.Comum, 5.Especial.

Abaixo segue a tabela dos riscos gerais.

N Risco 1 2 3 4 5

1 Falta de recursos financeiro x x

2 Volume de dados não suportado pelo banco x x

3 Treinamento da equipe indisponível x x

4 Problemas de segurança do sistema x x

5 Falta de pessoal com habilidades requeridas x x

6 Mudança de Requisitos durante o desenvolvimento x x

7 Excesso de requisições de páginas ao servidor x x

8 Falta de tecnologia para desenvolvimento x x

9 Atividades mal-distribuídas x x

10 Ferramentas de desenvolvimento com recursos limitados x x

11 Mudança no quadro de pessoal em estágios cruciais x x

12 Mudanças nas políticas governamentais x x

Tabela 02: Lista de riscos - área

A equipe elaborou a tabela 03, com o intuito de facilitar a classificação dos riscos

atribuindo uma probabilidade para o mesmo.

CLASSIFICAÇÂO PROBABILIDADE

muito baixa < 10%

baixa 10% e 25%

média 25% e 50%

alta 50% e 75%

muito alta > 75%

Tabela 03: Classificação dos Riscos

11

3.2 Tabela de risco

Por motivos de organização do plano de projeto foi feita uma organização da Lista de

riscos de acordo com a probabilidade e impacto de cada risco. Veja na tabela 04.

Risco Prob. Impacto RSGR

Falta de recursos financeiro 30% Catastrófico 001

Volume de dados não suportado pelo banco 25% Catastrófico 002

Treinamento da equipe indisponível 10% Catastrófico 003

Problemas de segurança do sistema 10% Catastrófico 004

Mudança de Requisitos durante o desenvolvimento 40% Crítico 005

Mudança no quadro de pessoal em estágios cruciais 40% Crítico 006

Excesso de requisições de páginas ao servidor 30% Crítico 007

Falta de tecnologia para desenvolvimento 30% Crítico 008

Falta de pessoal com habilidades requeridas 25% Crítico 009

Atividades mal-distribuídas 25% Crítico 010

Ferramentas de desenvolvimento com recursos limitados 20% Crítico 011

Mudanças nas políticas governamentais 50% Marginal 012

Tabela 04: Lista de Riscos – Probabilidade e Impacto.

12

3.3 Redução e Gestão do Risco

Para o Plano de Redução, Supervisão e Gestão do Risco (RSGR), são descritos a

seguir, uma estratégia de redução com o seu respectivo plano de contingência e a(s) pessoa(s)

responsável(eis).

Risco: 001 Prob: 30% Impacto: Catastrófico

Descrição: Falta de recursos financeiro

Estrategia de redução: Manter uma reserva financeira; Economia em gastos operacionais.

Plano de contingência: Redução na folha de pagamento; buscar novos investidores;

migrar para ferramentas de Software Livre.

Pessoa responsável: Heber Santiago

Status: Simulação finalizada


Descrição: Volume de dados não suportado pelo banco

Estrategia de redução: Gravar no banco de dados apenas informações relevantes.

Plano de contingência: Expansão ou migração para uma base que comporte grandes

volumes de dados; Remover informações mais antigas que não seriam mais utilizadas.

Pessoa responsável: Afrânio Lucas / Ramayana Júnior

Status: finalizada


Descrição: Treinamento da equipe indisponível

Estrategia de redução: Manter contato com as empresas de treinamento.

Plano de contingência: Buscar outras empresas capacitadas.


Status: em execução

13


Descrição: Problemas de segurança do sistema

Estrategia de redução: Efetuar testes de segurança, se possível com a ajuda de pessoas

especializadas em burlar segurança(harkers).

Plano de contingência: Efetuar mudanças no sistema para correção de falhas, em casos

graves retirar o site do ar.

Pessoa responsável: Alexandre Braga

Status: finalizada

Risco: 005 Prob: 40% Impacto: Crítico

Descrição: Mudança de Requisitos durante o desenvolvimento

Estrategia de redução: Aplicar mais de uma técnica para elicitação de requisitos; Para

cada requisito que for feito a elicitação aplicar verificação e validação para que não haja

inconsistências; especificar em contrato que mudanças nos requisitos acarretarão em

mudança no prazo de entrega e custo do projeto.

Plano de contingência: Redefinir cronograma do projeto incluindo as alterações

solicitadas.

Pessoa responsável: Arlesson Anjos / Manoel Mota

Status: finalizada


Descrição: Mudança no quadro de pessoal em estágios cruciais

Estrategia de redução: Remunerar de forma justa os colaboradores; Reconhecer

desempenho por atividades concluídas no prazo estimado por meio de bonificação;

Promover um bom clima organizacional; conceder benefícios como: auxílio alimentação,

auxílio transporte, plano de saúde, participação nos resultados.

Plano de contingência: contratar substituto a altura ; Rever cronograma; redistribuir

atividades.



14


Descrição: Excesso de requisições de páginas ao servidor

Estrategia de redução: Escolher servidor adequado com base na projeção de utilização

do site.

Plano de contingência: Upgrade ou migração para um servidor que comporte a

quantidade de acessos simultâneos; limitar o número de acessos ao site, por meio de

uma fila virtual de atendimento.

Pessoa responsável: Afrânio Lucas / Ramayana Júnior

Status: finalizada


Descrição: Falta de tecnologia para desenvolvimento

Estrategia de redução: Aplicar investimento em tecnologias alternativas.

Plano de contingência: Adquirir produto tecnológico similar que supra as necessidades do

projeto.


Status: finalizada

Risco: 009 Prob: 25% Impacto: Crítica

Descrição: Falta de pessoal com habilidades requeridas

Estrategia de redução: Buscar recrutar profissionais qualificados; aplicar treinamento

interno; Motivar a equipe à participar de workshops.

Plano de contingência: Contratar profissional com a habilidade requerida pelo projeto;

treinar equipe do projeto.


Status: finalizada

15


Descrição: Atividades mal-distribuídas

Estrategia de redução: Distribuir as atividades de forma correta, avaliando a experiência e

carga de trabalho atual dos colaboradores.

Plano de contingência: Rever cronograma e redistribuir as atividades.




Descrição: Ferramentas de desenvolvimento com recursos limitados.

Estrategia de redução: Escolher ferramentas confiáveis de desenvolvimento que melhor

atendam às necessidades do projeto; Desenvolver módulos da aplicação que sejam

independentes de bibliotecas ou plugins específicos.

Plano de contingência: Buscar soluções alternativas; Entrar em contato com o fornecedor

solicitando / sugerindo a inclusão do recurso.

Pessoa responsável: Alexandre Braga / Afrânio Lucas / Ramayana Júnior

Status: finalizada


Descrição: Mudanças nas políticas governamentais

Estrategia de redução: Estar atento às mudanças nas políticas governamentais para

caso seja necessário tratar alguma modificação no projeto, existir tempo hábil para

realizá-las.

Plano de contingência: Garantir que eventuais mudanças nas políticas governamentais

serão implantadas no âmbito do projeto; Rever cronograma incluindo a modificação na

lista de atividades.



16

4.0 PLANEJAMENTO TEMPORAL

No Planejamento Temporal são definidas as datas de execução das tarefas assim

como, os responsáveis por cada uma delas através do Diagrama de Gantt elaborado pelo

Gerente do Projeto.

4.1 Conjunto de Tarefas do Projeto

Como calculado no item 2.3, o esforço estimado para a realização do projeto é de 1060

dias trabalhados. Segue na tabela

Fase %Projeto Cálculo Dias trabalhados

Planejamento 3% 1060 x 3% 32

Análise de requisitos e modelagem 40% 1060 x 40% 424

Geração de código 20% 1060 x 20% 212

Testes 37% 1060 x 37% 392

Resultado 1060

Tabela 05: Plano temporal das fases do projeto

4.2 Diagrama de Gantt

Para obter maior detalhamento das etapas de desenvolvimento do sistema, tempo que

cada uma delas irá durar e quais atividades já foram concluídas, utilizou-se o Diagrama de

Gantt que pode ser visto em anexo (Figura 02).

17

5.0 ORGANIZAÇÃO DE PESSOAL

A equipe é formada por seis componentes, todos devidamente relacionados a

atividades que devem ser executadas para a implementação de um bom projeto. Essa divisão

foi realizada com base na preferência e nos conhecimentos de cada membro da equipe.

5.1 Estrutura da Equipe

■ Analista: Planejar, monitorar e administrar projetos de clientes externos, usando

processos e ferramentas formais para gerir recursos, orçamentos, riscos e mudanças.

Responsável: Arlesson dos Anjos / Manoel Mota

■ Arquiteto de software: Liderar e coordenar as atividades e os artefatos técnicos no

decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada visão

de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces

entre esses principais agrupamentos. Responsáveis: Afranio Lucas / Ramayana Júnior

■ Gerente de projeto: Alocar recursos, ajustar as prioridades, coordenar interações com

clientes e usuários e geralmente mantém a equipe do projeto concentrada na meta

certa. O gerente de projeto também estabelece um conjunto de práticas que garantem a

integridade e a qualidade dos artefatos do projeto. Responsável: Heber Santiago

■ Programador: Organizam os papéis envolvidos principalmente no design e

desenvolvimento de software. Responsável: Alexandre Damasceno

■ Testador: Organizam os papéis que lidam com habilidades específicas exclusivas para

teste. Responsáveis: Manoel Mota / Ramayana Júnior

5.2 - Mecanismo de Comunicação

A comunicação entre a equipe foi mantida através de reuniões presenciais com menor

frequência e virtuais com maior frequência que ocorreram acompanhando as mudanças e

evoluções do projeto. Virtualmente por meio de Web-Chats e E-mails em grupo (gerencia-de-

[email protected]).

18

Também através dos nossos twitters:

■ Afrânio Lucas: @AfraLucas

■ Alexandre Damasceno: @AlexandreBragaD

■ Arlesson Anjos: @arlesson_anjos

■ Heber Santiago: @heberayres

■ Manoel Mota: @motamanoel

■ Ramayana Júnior: @ramayanajr

5.3 Uso do Edu-Blog como ferramenta de apoio

A utilização do Edu-Blog é importante para a orientação das equipes e para

acompanhamento das aulas em geral. Serve como ferramenta de apoio para que as atividades

sejam cumpridas dentro do prazo e com a métrica esperada pelo professor. Através do blog

podemos revisar o conteúdo dado em sala de aula e nos manter informados sobre eventuais

mudanças em datas de atividades e cronograma. Além de auxiliar na comunicação entre os

alunos e o professor, o edu-blog torna-se uma fonte de pesquisa para temas abordados em

aula através dos blogs relacionados.

19

Anexo I

Figura 01: Diagrama de Classe

20

Anexo II

Figura 02: Diagrama de Gantt

21

Documents

Gt5 - Plano de Projeto