Página 1

Gerência de ProjetosGerência de Projetos

•Planejamento e Gerência de Projeto

•Projeto•Planejamento

•Um Plano de Projeto

Wesley Peron SenoWesley Peron Seno

Página 2

O que é Projeto ?O que é Projeto ?

“É uma sequência bem definida de eventos com um início e um fim, que se destina a atingir um objetivo

claro, sendo conduzida por pessoas dentro de parâmetros estabelecidos como tempo, custo,

recursos e qualidade”.

A extensão do planejamento de um projeto depende da sua complexidade, quanto mais complexo mais você

tem de planejar.

Página 3

PlanejamentoPlanejamento

Tempo -

– É o mais valioso bem disponível a um engenheiro de software.

Se houver suficiente tempo disponível::

– um problema pode ser adequadamente analisado;

– uma solução compreensivamente projetada;

– um código-fonte cuidadosamente implementado;

– um programa minuciosamente testado.

“Mas parece que nunca há tempo o bastante!”

Página 4

TempoTempo

Um conceito importanteUm conceito importante

História sobre as Pedras Grandes e o VasoHistória sobre as Pedras Grandes e o Vaso

Página 5

PlanejamentoPlanejamento

• “Às vezes parece que em nossa ansiedade para começar, não despendemos tempo para “organizar nossas ações”

• O planejamento obriga gerentes e profissionais a despender esse tempo.

• Antes de começar:– Desenvolver uma estratégia para atacar o problema

– Estabelecer um mecanismo para avaliação do progresso

– Organizar o pessoal

Página 6

Um Plano de Projeto de SoftwareUm Plano de Projeto de Software

1) IntroduçãoObjetivos do projeto

2) Estimativas de projeto

3) Riscos de projeto

4) Cronograma

5) Recursos do projeto

6) Organização do pessoal

7) Mecanismos de controle

8) Apêndices

Página 7

1 - Objetivos do Projeto1 - Objetivos do Projeto

• Deve ser o mais específico possível• Facilitar um melhor planejamento exemplo:

Genérico Específico

Implantar o novo sistemade relatórios financeiros

Treinar o departamento financeiroe os chefes de departamento paratrabalhar com o novo sistema de

preparação de relatóriosfinanceiros, até o segundo

trimestre, na fase-piloto. Treinartoda a empresa até o final do ano.

Página 8

2 - Estimativas de Projeto2 - Estimativas de ProjetoEsforço, Prazo e CustoEsforço, Prazo e Custo

• Uma das tarefas mais cruciais para um gerente de projeto.

• Uma das máximas em Gerência de Projetos é que: “Negociar prazos e recursos para um projeto sempre deve acontecer quando do seu planejamento, jamais no meio ou no fim do projeto”.

Página 9

2 - Métodos de Estimativas de 2 - Métodos de Estimativas de Esforço, Prazo e Custo de Projetos de SistemasEsforço, Prazo e Custo de Projetos de Sistemas

• Para auxiliar o gerente de projeto, existem diversos métodos de estimativas:

• FPA - Function Point Analysis (IBM)• COCOMO e COCOMOII - Constructive Cost Model

(Barry Bohem)“Todos os modelos de estimativas necessitam ser calibrados para

o ambiente específico da organização. É necessário coletar dados históricos dos projetos a fim de que os modelos sejam

calibrados às condições locais”. Kemerer

Página 10

3 - Análise dos Riscos3 - Análise dos Riscos

• O risco preocupa-se com acontecimentos futuros.• Risco envolve mudanças, tais como:

– de mentalidade;

– de opinião;

– de ações ou

– de lugares.

“Paradoxalmente, o risco, como a morte e os impostos, é uma das poucas certezas da vida”.

Página 11

3 - Análise dos Riscos3 - Análise dos Riscos

• A análise dos risco é, de fato, composta por 4 atividades:

– Identificação,

– Projeção,

– Avaliação e

– Administração dos riscos.

“Embora seja fútil tentar eliminar o risco, e questionável tentar eliminá-lo, é fundamental que os riscos assumidos sejam os

riscos certos”.

Página 12

3 - Identificação dos Riscos3 - Identificação dos Riscos

• Riscos de Projeto identificam:– problemas orçamentários, cronograma e pessoal

• Riscos Técnicos identificam– problemas de projeto, implementação, interface, verificação e manutenção

• Riscos de Negócios– são insidiosos e podem destruir o projeto

– 1) construir um produto excelente que não é usado

– 2) construir um produto que não se encaixa mais à estratégia da empresa

– 3) construir um produto que a equipe de venda não sabe como vender

– 2) perder o apoio da alta adm. Devido à mudança de enfoque ou de pessoas

– 3) perder compromisso orçamentário

Página 13

3 - Projeção dos Riscos3 - Projeção dos Riscos

• Também chamada de estimativas dos riscos, tenta classificar cada risco de duas maneiras, caso ele ocorra:– a probabilidade de que o risco seja real e

– as consequências dos problemas associados ao risco.

• O que fazer?– estabelecer uma escala que reflita a probabilidade de

ocorrência dos riscos

– delineamento das conseqüências dos riscos

– estimativas do impacto dos riscos

Página 14

3 - Avaliação dos Riscos3 - Avaliação dos Riscos

• Etapas durante a avaliação:– Definir os níveis de risco referentes para o projeto

– Prever o conjunto de pontos referentes que define uma região de encerramento do projeto.

• Charrette e Rowe - Matemática utilizada para apoiar a avaliação.

Página 15

3 - Gerenciamento dos Riscos3 - Gerenciamento dos Riscos

Gerenciamentodos riscos

Risco 1

Risco 2

Risco n

Dados da Análise

Passos deAdministração

dos Riscos

Dados da Análise

Dados da Análise

Passos deAdministração

dos Riscos

Passos deAdministração

dos Riscos

Plano deadministração emonitoração dos

riscos

ooo

Página 16

4 - Cronograma4 - Cronograma

A determinação de um cronograma para projeto pode ser vista a partir de duas perspectivas:

• 1ª - Uma data final para entrega já foi definida. Devemos distribuir o esforço dentro do tempo previsto.

• 2ª - O esforço é distribuído para se tirar o maior proveito dos recursos e uma data final é definida após cuidadosa análise pela equipe de desenvolvimento.

Infelizmente a 1ª é encontrada mais freqüentemente!

Página 17

4 - Cronograma4 - Cronograma

• As técnicas de determinação de cronogramas podem ser implementadas com ferramentas automatizadas.

• Métodos comumente utilizados:

– PERT - Program Evaluation and Review Technique (método de avaliação e revisão de programa)

– CPM - Critical Path Method (método do caminho crítico)

• Exemplo de Ferramenta: MS-Project

Página 18

4 - Recursos e Pontos de Controle4 - Recursos e Pontos de Controle

Página 19

5 - Recursos do Projeto5 - Recursos do Projeto

• Pessoas– Identificar pessoas ou grupos (usar tipos genéricos como

analista, programador, eng. de software ...)

• Equipamentos– Verificar se existe equipamentos disponíveis ou se há

necessidade de aquisição e deve constar do planejamento.

• Instalações– Considerar os requisitos de espaço para a quantidade de

pessoas ou materiais envolvidos.

Página 20

5 - Pessoas5 - Pessoas

• O mais importante recurso em projetos de sistemas (às vezes o único além do tempo)

• É fundamental que engenheiros de software entendam de fatores humanos, porque pessoas julgarão a utilidade do software que eles constróem.

• Pontos Chaves:

• trabalho em grupos pequenos (no máximo sete),

• liderança técnica por competência e

• local de trabalho adequado.

Página 21

5 - Fatores Humanos5 - Fatores Humanos

• Grupos democráticos tendem a ter mais sucesso que grupos autocráticos.

• Interação do grupo deve ser estruturada de modo que o número de elos de comunicação seja minimizado.

• Ergonomia: o local de trabalho tem efeitos importantes mas não quantificáveis na produtividade de software.

Página 22

5 - O que fazem os programadores?5 - O que fazem os programadores?

Escrevem programas

13%

Comunicação de trabalho

32%

Pessoal13%

Miscelânea (deslocamento

s fora do local...)

15%

Correios, doc administrativos

5%

Treinamento6%

Lêem programas

16%

Página 23

6 - Estrutura Organizacional6 - Estrutura Organizacional

• Motivação Básica da Organização/Coordenação– Necessidade de cooperação quando as metas não podem ser

realizadas por uma única pessoa num tempo razoável.• Qual o melhor papel para cada indivíduo?

• Como as responsabilidades devem ser dividas?

• Modelos como o COCOMO permitem estimar o número necessário de pessoas num projeto em função da complexidade do sistema.– Como dividir em equipes?

Página 24

6 - Estruturas de Equipe6 - Estruturas de Equipe

• Convencional

• Democrática

• Centralizada

• Hierárquica

Página 25

6 - Estrutura Convencional6 - Estrutura Convencional

• Reúnem-se analistas e programadores, designa-se um gerente e começa-se a trabalhar.

• Cada um é responsável pelo design e implementação de sua parte.

Página 26

6 - Estrutura Democrática6 - Estrutura Democrática

• Controle descentralizado, decisões por consenso

• O trabalho é considerado trabalho em grupo

• Para projetos longos, por causa do volume de comunicação intragrupos

• Não é adequada para equipes grandes– sobrecarga de comunicação

– risco de perfeccionismo

EstruturaGerencial

Padrões deComunicação

Página 27

6 - Estrutura Centralizada6 - Estrutura CentralizadaChief Programmer TeamChief Programmer Team

• Único responsável técnico por todas as fases do projeto

• Apropriada para projetos de curto prazo e problemas bem entendidos por um único indivíduo

• Problemas: políticos, dependência de líderes técnicosProgramador chefe

Documentador

Programadores Especialistas

Página 28

6 - Equipe Hierárquica6 - Equipe Hierárquica

• Líder dirige grupo de programadores experientes

• Cada programador experiente, por sua vez dirige um grupo de outros menos experientes

• Cada chefe de subgrupo atua como transmissor de informações para o seu subgrupo e como ligação entre os chefes de outros grupos.

Gerente

Pessoal Senior

Pessoal Junior

Página 29

7 - Mecanismos de Controle7 - Mecanismos de Controle

• ditado: “Os projetos de software atrasam-se em seu cronograma um dia de cada vez”.

• Um dos papéis da gerência é rastrear e controlar o projeto. Para isso deve-se definir mecanismos como:– Reuniões periódicas

– Avaliação dos resultados

– Determinação de marcos do projeto

– Comparação das datas reais e planejadas

– Reuniões informais para obter opiniões sobre problemas futuros