UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAO BACHARELADO EM CINCIA DA COMPUTAO

Plano de Projeto
Ttulo do Projeto: SIGPES Sistema de Gerenciamento de Pessoas
Disciplina: Gerncia de Projetos Prof PhD Rogrio P. C. do Nascimento

Equipe GT4: Adriana Lopes Diogo Soares Carlos Grimm Jeanne Trovo

Manaus Amazonas Novembro, 2011

NDICE
1. INTRODUO .................................................................................................................... 3 1.1 mbito do Projeto................................................................................................... 3 1.2 Funes principais do produto de software ............................................................... 3 1.3 Requisitos comportamentais ou de performance ...................................................... 4 1.4 Gesto e Restries Tcnicas ...................................................................................... 4 2. ESTIMATIVAS DO PROJETO ............................................................................................... 4 2.1 Dados histricos utilizados para as estimativas ......................................................... 4 2.2 Tcnicas de estimativas e resultados.......................................................................... 5 2.2.1 Tcnica de estimativa .......................................................................................... 5 2.3 Resultados ................................................................................................................... 5 2.4 Recursos do projeto .................................................................................................... 6 2.4.1 Recursos Humanos............................................................................................... 6 2.4.2 Recursos de Software .......................................................................................... 7 2.4.3 Recursos de Hardware ......................................................................................... 7 3. ANLISE E GESTO DE RISCOS .......................................................................................... 7 3.1 Riscos do projeto......................................................................................................... 8 3.2 Avaliao global dos riscos ......................................................................................... 8 3.3 Tabela de riscos........................................................................................................... 9 3.4 Reduo e Gesto do Risco ....................................................................................... 10 4. PLANEJAMENTO TEMPORAL ........................................................................................... 13 4.1 Conjunto de Tarefas do Projeto ................................................................................ 13 4.2 Diagrama de Gantt .................................................................................................... 16 5. ORGANIZAO DO PESSOAL ........................................................................................... 19 5.1 Estrutura da equipe .................................................................................................. 19 5.2 Mecanismos de comunicao ................................................................................... 19 5.2.1 Daily Scrum ........................................................................................................ 19 5.2.2 E-mail ................................................................................................................. 19 5.3 Uso do Edu-blog como ferramenta de apoio ........................................................... 20 6. PRECAUES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE ..................................................................................................................... 20 7. REFERNCIAS ................................................................................................................... 21 2

1. INTRODUO
1.1 mbito do Projeto
O produto destina-se Prefeitura Municipal do Estado do Amazonas e proporciona um modelo de gesto de pessoas alinhado com estratgias, princpios e processos de trabalho. Dever ser usada pelo setor de Administrao Pessoal, Administrao Financeira e responsveis pelas secretarias e coordenaes de projeto (Secretrios e Coordenadores). O produto possibilita verificar a evoluo e histrico na carreira, as aes de capacitao, reconhecimento s competncias relevantes para a organizao, emisso de contra-cheque e o registro de benefcios a cada funcionrio. O produto permite visualizar a lotao atual dos funcionrios, registra o aprendizado contnuo e o comprometimento dos empregados com relao ao seu desenvolvimento profissional. Co-responsabiliza os gestores da Prefeitura pela conduo do processo de gesto de pessoas e os investimentos em gesto de pessoas.

1.2 Funes principais do produto de software

As funcionalidades que o software implementa so descritas em baixo: Funcionrios Este ncleo estabelece as transaes CRUD (do ingls, Create, Research, Update, Delete) de funcionrios com os dados pessoais, e dependentes. Organizao dos Espaos Ocupacionais Este ncleo estabelece o quadro de funcionrios, apresenta a trajetria de carreira que os funcionrios da Prefeitura podem percorrer atravs do desenvolvimento profissional baseado em competncias. Acompanhamento e Avaliao de Resultados Estabelece o monitoramento dos resultados e desempenho de seus empregados. A avaliao realizada pelo supervisor de cada funcionrio. Reconhecimento Estabelece as polticas e procedimentos de remunerao para a compensao dos empregados pela aquisio de competncias e alcance dos resultados organizacionais. Capacitao 3

Estabelece polticas e procedimentos para as aes de educao continuada, com a finalidade de desenvolver internamente as competncias requeridas pela Prefeitura conforme o Planejamento Estratgico de Pessoal. Neste ncleo os investimentos em cada funcionrio so registrados. Monitoramento da Cultura Organizacional Estabelece polticas e monitoramento da cultura organizacional da Prefeitura, perodo de trabalho, frias, as faltas no ms, afastamentos (por exemplo com atestado mdico, viagens a trabalho). Remunerao e Benefcios Estabelece a remunerao fixa/salrio base pagos mensalmente, permite a emisso de contra-cheque e estabelece os benefcios como: Assistncia Mdica, Previdncia Privada e Auxlio doena.

1.3 Requisitos comportamentais ou de performance

O sistema possui os seguintes requisitos comportamentais ou de performance: Deve ser um sistema seguro Para isso cada gestor (Secretrios ou Coordenadores) deve conter login e senha; Ter uma interface til e de fcil utilizao, para que qualquer pessoa mesmo sem estar ambientado com as novas tecnologias, possa utilizar; Possibilidade de transferncia da base de dados existente na organizao.

1.4 Gesto e Restries Tcnicas

As restries que podero afetar a maneira de conduzir o projeto so as seguintes: Falta de capacitao tcnica da equipe, sendo necessrio um treinamento especfico para alguns componentes da equipe com ferramentas que sero utilizadas; A quantidade dos recursos limitada.

2. ESTIMATIVAS DO PROJETO 2.1 Dados histricos utilizados para as estimativas

Este ser o primeiro projeto a ser realizado pela empresa, portanto ainda no possumos dados histricos armazenados que possam ser utilizados para as estimativas do mesmo.

2.2 Tcnicas de estimativas e resultados

2.2.1 Tcnica de estimativa
Para este projeto vamos utilizar a tcnica de estimativa usada em projetos de Software Orientado a Objeto da Lacertae Software, tcnica essa que a Lorenz & Kidd, que uma mtrica orientada a classes onde se destaca por ser simples e fcil de utilizar. Para usar a mtrica de Lorenz & Kidd temos que: 1. Definir o nmero de classes chave; 2. Encontrar o nmero de classes de suporte, que para isso temos que classificar o tipo de Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte; 3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimao do nmero de classes de suporte; 4. De seguida, calcula-se a quantidade total de Classes, somando o n de Classes-Chave com o n de Classes de Suporte; 5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo nmero mdio de unidades de trabalho (dias-pessoa) por classe Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Escolher um nmero entre 15-20 dias-pessoa e justificar a escolha; 6. Determinar a quantidade de esforo estimada; 7. Calculo do tempo previsto para a elaborao do projeto.

2.3 Resultados
1. N classes chave = 6 2. Escolhemos a Interface com base na aplicao grfica que ir ter o produto final. Multiplicador do GUI = 2,5. Logo, teremos 15 Classes de Suporte. 4. O nmero total de classes igual a: 5

N Classes Chave + N Classes de Suporte = 6 + 15 = 21 5. Em conjunto escolhemos 18 dias-pessoa. 6. O calculo da quantidade do esforo estimada : 21 X 18 = 378 dias de trabalho 7. Agora se pretendemos ter os dias/meses corridos (incluindo os fins de semana), temos que multiplicar os dias de trabalho com os 30 dias corridos e de seguida dividir pelos os 22 dias teis. 378 X 30 = 11340 / 22 = 515.45, que aproximadamente 516 dias corridos; Poderemos calcular agora os dias de trabalho por pessoa, e sendo assim temos 4 pessoas na equipe para este projeto divididos por 516 dias de trabalho ficaremos com 129 dias de trabalho para cada membro da equipe. Sabendo-se que os dias de trabalho totais so 516 dias, esses dias agora so distribudos de acordo com as seguintes percentagens de distribuio dos componentes essenciais no projeto, sugeridas pela Lacertae Software: 1) Planejamento: 2-3% 2) Anlise e Projeto: 40% 3) Gerao de Cdigo: 20% 4) Testes: 37-38% Os valores calculados so: 1) Planejamento: 516 * 3% = 15,48 dias de trabalho 2) Anlise e Projeto: 516 * 40% = 206,4 dias de trabalho 3) Gerao de cdigo: 516 * 20% = 103,2 dias de trabalho 4) Testes: 516 * 37% = 190,92 dias de trabalho

2.4 Recursos do projeto

2.4.1 Recursos Humanos
O projeto contar com 4 pessoas que exercero os diversos papis necessrios execuo do projeto para o desenvolvimento do software conforme a Tabela 1.

Papel Gerente de Projeto Analista de Sistema Arquiteto Programador Analista de Teste Testador Adriana

Exercido por

Adriana, Jeanne Carlos, Diogo Carlos, Diogo Jeanne Diogo, Carlos

Tabela 1: Recursos Humanos

Obs:. O testador no deve testar o seu prprio programa, mas ele deve testar o de outro programador. Ex: Se o Carlos desenvolver uma tela de Login, quem deve testar o Diogo. Caso quem tenha desenvolvido a tela tenha sido o Diogo, o Carlos deve testar.

2.4.2 Recursos de Software

O projeto ir usufruir dos seguintes softwares para composio do produto de software, alm do projeto de gerncia de produo: Mysql Sistema que permitir a gerncia do banco de dados usado na composio do produto final. Delphi IDE e linguagem de programao a ser utilizada na implementao do produto de software final. OpenOffice e Microsoft Word Editores de texto usados na documentao, relatrios e documentos afins. MSProject Software gerenciador de projetos que servir de base para gesto atualizada e confivel do projeto do produto. Git Sistema de controle de verso a ser utilizado para permitir desenvolvimento distribudo do software

2.4.3 Recursos de Hardware

Para documentao, implementao e gesto do projeto de software, nossos recursos iniciais de hardware esto agrupados em quatro notebooks e um servidor.

3. ANLISE E GESTO DE RISCOS

Projetos esto sujeitos a determinados riscos que no podem ser ignorados, pelo contrrio, necessrio saber estim-los para que seja traado um plano em que se possa evitar ou minimizar os riscos.

3.1 Riscos do projeto

Tabela 2 apresenta os riscos gerais e do projeto pedidos no plano de Projeto da Lacertae SW. Risco Equipamento no disponvel Requisitos Incompletos Uso de metodologias especiais Problemas na busca da confiabilidade requerida Reteno de pessoas chave Subestimativa do esforo Desistncia do cliente potencial Os custos e o cronograma no esto bem definidos X X X X X X X Projeto Tcnico X X X X Negcio Comum Especial

X X

X X

Tabela 2: Riscos de Projeto.

3.2 Avaliao global dos riscos

1. O Gestor de Software d suporte ao projeto? No, o gestor um participante que possui muito conhecimento adquirido ao longo da vida acadmica, mas muita pouca experincia profissional. 8

2. Os Clientes esto entusiasmados com o projeto e o produto? O cliente est entusiasmado para adquirir o produto final e contribui para o desenvolvimento do projeto. 3. Os Engenheiros de Software compreenderam bem os requisitos? Sim, todos sabem o que o sistema deve conter atravs dos requisitos. 4. Os Clientes estiveram envolvidos na definio dos requisitos? Sim, houve a elicitao dos requisitos com o cliente por meio de entrevista e questionrio. 5. O mbito do projeto estvel? Sim, o mbito do nosso projeto no foi alterado. 6. Os engenheiros de Software tm as competncias requeridas? Os engenheiros de Software possuem capacidade e competncia necessria para a elaborao deste projeto. 7. Os requisitos do projeto so estveis? Sim, os requisitos so estveis. 8. A equipe de desenvolvimento tem experincia na tecnologia a implementar? Sim, a equipe possui conhecimentos adquiridos ao longo da vida acadmica e profissional. 9. adequado o nmero de pessoas da equipe de trabalho? No, um trabalho extenso para um nmero reduzido de pessoas o que levar a um esforo complementar de cada um.

3.3 Tabela de riscos

Tabela com os riscos identificados a sua probabilidade de ocorrncia e impacto esperado.

Risco

Categoria

Prob.

Impacto 9

1 2 3 4
Ponto de Corte

Expectativas no satisfeitas Data de entrega ajustada Pouco pessoal com comprometimento total (tempo) Mudana nos requisitos Distncia do cliente Mais utilizadores que os previstos Falta de sofisticao tcnica do cliente Dvidas sobre a implementao dos requisitos do sistema

Cliente Negcio Equipe Cliente Cliente Tamanho Cliente Equipe

60% 60% 60% 50% 60% 20% 80% 30%

Catastrfico Crtico Crtico Crtico Crtico Marginal Marginal Marginal

5 6 7 8

Tabela 3: Riscos identificados no Projeto.

3.4 Reduo e Gesto do Risco

1. Expectativas no satisfeitas
Risco: 1 Probabilidade: 60% Impacto: Catastrfico

Descrio: O cliente pode no gostar da estrutura do programa na entrega de cada iterao. Estratgia de reduo: Elaborao de wireframe e validao pelo cliente. Antecipar a entrega do documento de requisitos para elaborao de Teste do mesmo. Plano de contingncia: Entrega da iterao com os dias alocados para Risco do Projeto. Pessoa responsvel: Gerente de Projeto Status: Simulao agendada para entrega de cada ciclo.

2. Data de entrega ajustada

Risco: 2 Probabilidade: 60% Impacto: Crtico

10

Descrio: No haver tempo til e hbil para a realizao total do projeto. Estratgia de reduo: Maior divisibilidade nos trabalhos atribudos e em cada iterao do produto conforme sua complexidade . Plano de contingncia: Entrega da iterao com os dias alocados para Risco do Projeto. Pessoa responsvel: Gerente de Projeto, Analistas de Sistema Status: Simulao agendada para entrega de cada ciclo.

3. Pouco pessoal com comprometimento total (tempo)

Risco: 3 Probabilidade: 60% Impacto: Crtico

Descrio: A dificuldade na disposio integral de cada integrante da equipe no desenvolvimento do sistema. Estratgia de reduo: Trabalhar em horas vagas, utilizando algum final de semana. Plano de contingncia: Trabalhar, quando acordado, nos finais de semana, elaborar um horrio flexvel para cada funcionrio afim de que seja utilizado o mximo do mesmo. Pessoa responsvel: Gerente de Projeto Status: Simulao agendada para entrega de cada ciclo.

4. Mudana nos Requisitos

Risco: 4 Probabilidade: 50% Impacto: Crtico

Descrio: Adio, excluso ou alterao dos requisitos do sistema resultando na modificao de artefatos. Estratgia de reduo: Validar todos os requisitos com o cliente antes de comear a produzir artefatos subsequentes da elicitao de requisitos. Plano de contingncia: Conversar com o cliente para verificar o que pode ser feito de forma a seguir o cronograma e os custos do plano do projeto. Pessoa responsvel: Analistas de Sistema Status: Simulao agendada para entrega de cada ciclo.

5. Distncia do Cliente
Risco: 5 Probabilidade: 60% Impacto: Crtico

11

Descrio: A dificuldade na comunicao devido distncia do cliente durante o

desenvolvimento do sistema um risco que pode atrasar o processo quando a equipe precisar conversar com o cliente sobre alguma caracterstica do sistema.
Estratgia de reduo: Elaborar e acordar com o cliente um cronograma de reunies a serem realizadas durante o desenvolvimento e alocar um substituto responsvel para atender a equipe quando o cliente no estiver disponvel. Plano de contingncia: Quando no houver possibilidade de falar com o cliente, utilizar e-mails para ajudar na comunicao ou falar com o substituto do cliente. Pessoa responsvel: Equipe Status: Simulao agendada para entrega de cada ciclo.

6. Mais utilizadores que os previstos

Risco: 6 Probabilidade: 20% Impacto: Marginal

Descrio: Mais utilizadores que os previstos. Estratgia de reduo: Aumentando recursos e recursos compartilhados do sistema Plano de contingncia: Reintegrar um upgrade do sistema a ser entregue na nova interao Pessoa responsvel: Equipe Status: Simulao agendada para entrega de cada ciclo.

7. Falta de sofisticao tcnica do cliente do cliente.

Risco: 7 Probabilidade: 80% Impacto: Marginal

Descrio: Falta de sofisticao tcnica do cliente. Estratgia de reduo: Compensar a falta de sofisticao tcnica com uma anlise mais bem elaborada Plano de contingncia: Imaginar o sistema do ponto de vista do cliente e perceber falhas tcnicas imperceptveis para o cliente. Pessoa responsvel: Equipe Status: Simulao agendada para entrega de cada ciclo.

8. Expectativas no satisfeitas 12

Risco: 8

Probabilidade: 30%

Impacto: Marginal

Descrio: Requisitos do sistema podem ser ambguos ou confusos Estratgia de reduo: Validao coerente de um cliente especializado, se houver e reviso da documentao de anlise. Plano de contingncia: Entrega da iterao com os dias alocados para Risco do Projeto. Pessoa responsvel: Equipe Status: Simulao agendada para entrega de cada ciclo.

4. PLANEJAMENTO TEMPORAL
No planejamento de tempo, so definidas as datas de execuo das tarefas e os responsveis por tais, neste processo elaborado o Diagrama de Gantt.

4.1 Conjunto de Tarefas do Projeto

Com base no projeto, estrutura organizacional e a equipe de trabalho, escolhemos uma metodologia gil para gesto de projetos, o Scrum; No seguimos a risca a metodologia do Scrum, aderindo, em nosso projeto prticas da Engenharia de Software. Com as funcionalidades levantadas na seo 1, montamos o Product Backlog com as prioridades definidas de acordo com o valor de importncia para o cliente.
Prioridade Item Descrio Tempo Estimado Responsvel

Muito alta 1 2 Alta 3 Mdia 4 5 Capacitao Desempenho

Tabela 4: Product Backlog

Funcionrio e Perfil Organizao Remunerao e Benefcios

123 123 82 41 41

Equipe Equipe Equipe Equipe Equipe

Na Tabela 4, os itens do Product Backlog esto organizados por prioridade (muito alta, alta, mdia), perodo estimado para entrega e responsvel pela execuo da tarefa; Em seguida, criamos nosso Sprint formado pelo conjunto de itens extrados do Product Backlog; 13

O Sprint formado dividido em tarefas que por sua vez ficam sobre responsabilidade da equipe; As tarefas para este projeto so Planejamento, atividades de Engenharia de Software e as etapas de desenvolvimento de software, tais como, Anlise e Projeto, Codificao e Teste; O tempo de durao para cada Sprint foi estimado de acordo com os clculos da Tabela 5, o resultado de cada Sprint gera um novo incremento para o produto.

Funcionalidade

Release

Distribuio por release

Distribuio por release (d)

Atividade

Distribuio por atividade

Planejamento
Funcionrio e Perfil

3.69 49.2 24.6 45.51 3.69 49.2 24.6 45.51 2.46 32.8 16.4 30.34 1.23 16.4 8.2 15.17 1.23 16.4 14

30%

123

Anlise e Projeto Codificao Teste Planejamento

Organizao

30%

123

Anlise e Projeto Codificao Teste Planejamento

Remunerao e Beneficios

20%

82

Anlise e Projeto Codificao Teste Planejamento

Capacitao

10%

41

Anlise e Projeto Codificao Teste Planejamento

10%

41

Anlise e Projeto

Desempenho

Codificao Teste
Tabela 5: Distribuio de atividades e esforos.

8.2 15.17

15

4.2 Diagrama de Gantt

O diagrama de Gantt composto pela diviso em tarefas e sub-tarefas das fases do projeto, onde estas tarefas possuem uma data de incio e concluso, bem como esto associadas a um ou mais membros da equipe de desenvolvimento do projeto.

16

17

18

5. ORGANIZAO DO PESSOAL
Apesar da equipe do projeto ter um gestor responsvel pela organizao dos trabalhos, as decises so tomadas em conjunto e em consenso de todos os envolvidos, onde h uma melhor comunicao para a soluo de problemas que possuem alta complexidade.

5.1 Estrutura da equipe

O projeto contar com 4 pessoas, que exercero diversos papis necessrios execuo do projeto conforme a Tabela 1. Na Tabela 6, so especificados os papis e a descrio dos mesmos no projeto.

Papel Gerente de Projeto Analista de Sistema Arquiteto Programador Analista de Teste Testador

Descrio Responsvel por gerenciar as atividades da equipe do projeto. Responsvel pelos requisitos do sistema e elaborao dos diagramas da anlise. Responsvel pelo projeto arquitetural do sistema, incluindo os diagramas de projeto. Responsvel pela codificao do sistema. Responsvel pelo planejamento de testes de sistema. Responsvel pela execuo dos testes do sistema.
Tabela 6: Papel e descrio

5.2 Mecanismos de comunicao

5.2.1 Daily Scrum
Reunies de no mximo 15 minutos, realizadas em p, feitas diariamente com a equipe. Cada membro discorreu sobre os seguintes questionamentos: o que foi feito no dia anterior; o que ser feito no dia atual aps a reunio e o que vem a impedi-lo de realizar sua atividade para compartilhar informaes sobre o andamento das atividades.

5.2.2 E-mail
19

Foi utilizada a comunicao por e-mail para diviso de tarefas, tirar dvidas com o cliente e dvidas entre a equipe. Tambm foi utilizado para obter controle do andamento na fase do desenvolvimento, ou seja, como estavam as tarefas que cada um estava desenvolvendo.

5.3 Uso do Edu-blog como ferramenta de apoio

O uso do Edu-blog foi interessante, pois nos permitiu uma maior organizao dos assuntos pesquisados e encontrados por cada integrante da equipe, ou seja, obtivemos um histrico das nossas pesquisas, alm de nos auxiliar a questes relacionadas s ferramentas utilizadas pelos outros grupos. A utilizao do mesmo tambm permitiu a informalizao e expanso do conhecimento ao documentarmos de forma criteriosa nossas pesquisas e tambm de demonstrarmos nossos relatos de vivncia com a gesto.

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

Para assegurar e controlar a qualidade do produto de Software, necessrio ter diversos cuidados, segue-se assim uma descrio de todas as medidas tomadas para assegurar a qualidade dos produtos de software desenvolvidos pela Lacertae SW e mais propriamente pela equipe GT4: Seguimento e Controle do Projeto de Software realizado um acompanhamento constante das atividades desenvolvidas por parte de todos os envolvidos no projeto. Revises Tcnicas Formais As revises so realizadas na etapa de Anlise e Projeto, visando identificao de erros nas fases iniciais do projeto, onde o custo para a manuteno menor. Gesto de Configurao do SW Existe um controle a cada verso do software e dos documentos gerados, visando integridade de ambos ao longo do seu ciclo de vida. Produo de Documentao Para o controle de qualidade do processo de desenvolvimento, foi elaborada documentao nas etapas de Anlise, Projeto e Teste. 20

 Medies So realizadas medies para verificar caractersticas do software para ter noo se os requisitos esto consistentes e completos, se o projeto tem boa qualidade. Registro de Atividades Com o registro de atividades foi possvel tambm analisar quais so as atividades que demandam mais tempo dos colaboradores, podendo planejar ampliao ou realocao de colaboradores estrategicamente. Logo temos como benefcios a Medio da produtividade do trabalho dos colaboradores, consequentemente da produtividade da organizao; Anlise de Riscos Identificao, anlise e controle dos riscos, elaborando-se planos de reduo e de contingncia. Testes Para o produto de software, utilizamos Teste de Sistema para validao de funcionalidades e busca por falhas no ambiente de produo.

7. REFERNCIAS
Almeida, C.; Vieira, J. Plano de Projeto de Software. Aracaju, 2010. Palmeira, J. C.; Cardoso, J. H. M. Plano de Projeto. Acaraju, 2010. Ferreira, D.; Costa, F.; Alonso, F.; Alves, P.; Nunes, T. SCRUM, Um Modelo gil para Gesto de Projectos de Software. 2005.

21