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.