capitulo 5 - gerenciamento de projeto

8/6/2019 Capitulo 5 - Gerenciamento de Projeto

1/70

PROJECT MANAGEMENT

Ian Sommerville, 8 edio Captulo 5Aula de Luiz Eduardo Guarino de Vasconcelos


2/70

Objetivos Introduzir gerenciamento de projeto de software e descrever

suas caractersticas distintivas Discutir o planejamento de projeto e o processo de

planejamento

Mostrar como re resenta es rficas de crono rama so

usados pelo gerenciamento do projeto Discutir a noo de riscos e o processo de gerenciamento de

risco


3/70

Tpicos abordados Atividades de gerenciamento

Planejamento do projeto

Cronograma do projeto

erenc amen o e r scos


4/70

Gerenciamento do projeto de software Preocupa-se com atividades envolvidas em garantir

que o software ser entregue no tempo e no prazodeterminados, e de acordo com os requisitos dasorganizaes desenvolvendo e adquirindo o

O gerenciamento do projeto necessrio, pois odesenvolvimento de software sempre assunto derestries de oramento e cronograma que so

estabelecidos pela organizao desenvolvendo osoftware


5/70

Distines do gerenciamento de Software

O produto intangvel

O produto unicamente flexvel A engenharia de software no reconhecida como

como a mecnica, a engenharia eltrica, etc. O processo de desenvolvimento de um software no

padronizado

Muitos projetos de software so projetos one-off


6/70

Atividades de gerenciamento Escrita da proposta

Planejamento e cronograma do projeto Custos do projeto

on oramen o o pro e o e rev s es Seleo e avaliao de pessoal

Relatrio escrito e apresentaes


7/70

Gerenciamento de semelhanas Essas atividades no so peculiares ao

gerenciamento de software

Muitas tcnicas de gerenciamento de projeto de

engen ar a s o gua mente ap c ve s para ogerenciamento de projeto de software

Sistemas de engenharia tecnicamente complexostendem a sofrer dos mesmos problemas que umsistema de software.


8/70

Seleo de pessoal para o projeto Pode no ser possvel apontar a pessoa ideal para trabalhar

em um projeto O oramento do projeto pode no permitir o uso de uma equipe com grandes

pagamentos

Equipe com a experincia apropriada pode no estar disponvel

Uma organizao pode querer desenvolver as habilidades dos empregados emum projeto de software

Os gerentes tm que trabalhar dentro dessas limitaesespecialmente quando (como corriqueiramente o caso) h

uma falta de pessoas habilitadas em tecnologia dainformao (TI) internacionalmente


9/70

Planejamento do projeto Provavelmente a atividade de gerenciamento do

projeto de maior consumo de tempo Atividade contnua do conceito inicial at a entrega

do sistema. Os planos devem ser regularmente

rev sa os me a que novas n orma es este amdisponveis

Vrios tipos diferentes de plano podem serdesenvolvidos para suportar o projeto principal deplanejamento que se preocupa com cronograma eoramento


10/70

Tipos de planos de projetoPlano Descrio

Plano de Qualidade

Descreve os procedimentos de qualidade e padres

que sero utilizados no projeto.

Plano de validaoDescreve a abordagem, os recursos e o cronograma

utilizados para a validao do sistema.

Plano de confi ura o do Descreve os rocedimentos de confi ura o do

gerenciamento

gerenciamento e estruturas a serem utilizados.

Plano de manutenoPrev os requisitos de manuteno do sistema, os

custos da manuteno e o esforo necessrio.

Plano de desenvolvimento dopessoal

Descreve como as habilidades e experincias dosmembros do time do projeto sero desenvolvidos


11/70

Planejamento do processo do projetoEstabelecer as restries do projeto

Fazer uma avaliao inicial dos parmetros do projeto

Definir os marcos e as entregas

enquanto o projeto no for completado ou cancelado faa:

Desenhe o cronograma do projeto

Inicie as atividades de acordo com o cronograma

Espere (um pouco

Revise o progresso do projeto

Revise estimativas dos parmetros do projeto

Atualize o cronograma do projeto

Renegocie as restries do projeto e as entregas

se (problemas surgirem) entoInicie a reviso tcnica e possvel reviso

fim do se

fim do enquanto


12/70

O plano de projeto O plano de projeto deve:

Recursos disponveis para o projeto A estrutura analtica do projeto

O crono rama de trabalho


13/70

Estrutura do plano de projeto Introduo: objetivos e restries que afetam o

gerenciamento de projeto (oramento, prazo, etc)

Organizao do projeto: organizao da equipe e seuspapis

Requisitos de recursos para hardware e software: o que necessrio, podendo ter estimativas

Work Breakdown Estrutura analtica: identifica marcos e

produtos a serem entregues Cronograma do projeto: dependncias, prazos e alocao

de pessoal

Monitorando e reportando mecanismos: relatrios


14/70

CRONOGRAMA


15/70

Organizao de atividades As atividades em um projeto devem ser

organizadas para produzir sadas tangveis para ogerenciamento para julgar o processo

Milestones marcos so os ontos finais de uma

atividade do processo Deliverables (Entregas) so resultados do projeto

entregues ao clientes

O processo cascata permite a definio direta demilestones de progresso


16/70

Milestones no processo Engenharia de

Requisitos


17/70

Cronograma do projeto Dividir o projeto em tarefas e estimar tempo, custo e recursos

necessrios para completar cada tarefa

Organizar as tarefas concomitantemente para um usootimizado da fora de trabalho

Minimizar as de endncias de tarefas ra evitar atrasos

causados por uma tarefa esperando pela finalizao deoutra

Depende da intuio e experincia do gerente do projeto

Sugesto: estime atividades de uma semana para facilidade

de acompanhamento. Caso a atividade seja grande, mais de10 semanas, divida-a em sub-atividades.


18/70

O processo de cronograma do projeto


19/70

Problemas no Cronograma Estimar a dificuldade de problemas e, a partir de

ento, o custo de desenvolver uma soluo difcil Produtividade no proporcional ao nmero de

pessoas trabalhando em uma tarefa

Adicionar pessoas tardiamente a um projeto faz comque ele se atrase mais devido aos atrasos nacomunicao

O inesperado sempre acontece. Sempre permitacontingncia no planejamento


20/70

Atraso na entrega: Causas Data de entrega irrealstica

Mudanas de requisitos Subestimativa de esforo e/ou recursos

considerados

Dificuldades tcnicas

Dificuldades Humanas Falta de comunicao entre a equipe de projeto

Falha na gerencia para perceber o atraso e falta de

ao


21/70

Atraso na entrega: Causas Imprevistos podem acontecer

Funcionrio doente Funcionrio pede demisso

Hardware pode apresentar defeito

Hardware e software de suporte podem demorar aserem entregues

Software novo e tecnicamente avanado pode

demorar mais tempo que o previsto para serdesenvolvido

Dependncia de fatores externos


22/70

Dvida O que devemos fazer quando a gerncia exige que

cumpramos um data de entrega impraticvel? Recomendaes nessa situao

Use dados histricos de projetos anteriores

Esforo e a durao

Use um modelo incremental e entregue apenas afuncionalidade crtica no prazo e adie a funcionalidaderestante

Reuna com o cliente e explique por que a data impraticvel

Frise que so baseadas em problemas anteriores


23/70

Cronogramao de Projetos Objetivo do gerente de projeto

Definir todas as tarefas do projeto Construir uma rede que mostre sua interdependncia

Identificar as tarefas ue so crticas nessa rede

Acompanhar seu progresso para certificar que atrasossejam reconhecidos

Monitorar o progresso


24/70

Cronogramao de Projetos uma atividade que distribui o esforo estimado

pela durao planejada do projeto, partilhando esseesforo por tarefas especficas de ES.

Cronograma

Macroscpico Detalhado

Uma data final foi estabelecida

Distribuir o esforo dentro do espao de tempo prescrito


25/70

Princpios Bsicos Compartimentalizao

Atividades e tarefas gerenciais Tanto o produto como processo so decomposto

Interdependncia

Tarefas seqncias Tarefas paralela

Atribuio de tempo

Cada tarefa deve ser atribuda uma unidade de trabalho(ex.: pessoas-dia esforo)

Cada tarefa deve ter uma data de incio e fim


26/70

Princpios Bsicos Validao de esforo

Garantir que no mais do que o nmero alocado depessoas seja cronogramado em um determinado momento

Responsabilidade definidas

Cada tarefa deve ser atribuda a um membro da equipe

Resultados definidos

Cada tarefa deve ter um resultado definido

Produto de trabalho

Marcos de referncia definidos

Atividades ou artefatos prontos


27/70

Relacionamento entre Pessoal e

Esforo Projeto pequeno

Uma pessoa pode fazer tudo Projeto grande isso no possvel!

Mito do gerente

Atraso no projetoColoco mais pessoas na equipe

Precisam aprender sobre o sistema

Quem ir trein-los so os que estavam fazendo otrabalho

Enquanto ensinam no pode fazer o trabalho e o projetoatrasa ainda mais


28/70

Distribuio de Esforo Regra 40-20-40

40% anlise e projeto finais20% codificao

Deve ser usada apenas como diretriz

Varia de acordo com as caractersticas de cadaprojeto


29/70

Cronograma do Projeto Recursos (alm dos prazos de execuo):

Esforo humano requerido Espao em disco de armazenamento

Tempo de uso de processamento especializado

a as para reuni es

Computadores e programas utilizados

Oramento de dirias para viagens

Pessoas disponveis para discusses

Sugesto: iniciar com uma estimativa de sem problemas eacrescentar:

30% para soluo de possveis problemas

20% para aspectos no previstos


30/70

Tipos de Projeto de Software Desenvolvimento conceitual

Desenvolvimento de novas aplicaes Aperfeioamento de aplicaes

Projetos de reengenharia


31/70

Fatores que influenciam o conjunto

de tarefas escolhido Tamanho do projeto e Urgncia

Nmero de usurios em potencial Criticidade da misso

Longevidade da aplicao

Estabilidade dos requisitos Facilidade de comunicao cliente/desenvolvedor

Maturidade da tecnologia aplicvel

Restries de desempenho Caractersticas embutidas e no-embutidas

Equipe de projeto

Fatores de reengenharia


32/70

Cronogramao Mtodos de cronogramao de software

Tcnica de avaliao e reviso de programao ( PERT) Mtodo do caminho crtico (CPM)

Usam

am n o cr t co

Tempo mais provveis

Limites de tempo (janelas)

Atividades

Estimativa de esforo Uma decomposio da funo do produto

Seleo de modelo de processo e conjunto de tarefas adequado

Decomposio de tarefas


33/70

Grfico de Tempo


34/70

Diagrama de barra e rede de atividades

Notaes grficas usadas pra ilustrar o

agendamento do projeto Mostrar a separao do projeto em tarefas. As

tarefas no devem ser muito pequenas. Devemevar uma ou uas semanas.

As redes de atividades mostram as dependnciasde tarefas e o caminho crtico

Diagramas de barra mostram o cronogramaconfrontado com o tempo do calendrio


35/70

Durao das tarefas e dependncias


36/70

Rede de atividades


37/70

Linha de tempo da atividade


38/70

Distribuio de pessoal


39/70

Acompanhamento do cronograma Roteiro para o gerente

Tarefas e marcos de referncia Conduzir reunies peridicas

Relatos de problemas e progresso

Avaliar o resultado de todas as revises Determinar se os marcos foram entregues na data prevista

Comparar a data real com a data de incio planejada

Anlise do valor agregado Tarefas planejadas/ Tarefas cumpridas

Quociente ideal igual a 1


40/70

Pesquisa Trabalho em grupo - 8 grupos

Estudar a ferramenta selecionada

Caractersticas, Funcionalidades, Pontos fortes e pontos fracos O que ? Para que serve (Qual o propstito)? Onde utilizado (Contexto de uso)? Use o

5W2H.

Elaborar um tutorial de instalao e um tutorial de uso

DotProject

GanttProject

TeamWork

Hipergate

MS PROJECT

Entregar no e-mail

Assunto: FES_CAP5

Arquivo: Nome_FES_CAP5


41/70

GERENCIAMENTO DERISCOS


42/70

Fontes de Riscos

Ferramentas inadequadas

Melhores profissionais deixam projeto Requisitos errados

Equipamento esperado no chega Documentos ambguos

Cronograma estimado inatingvel

Custo estimado est incorreto


43/70

Principais reas de Riscos

Pessoal

Cronograma e Custo Funcionalidade do Sistema

Anlise de requisitos inadequada Estabilidade dos Requisitos

Cliente tenta alterar requisitos o tempo todo

Qualidade de Componentes Externos

DIFICULDADE EM ANTECIPAR TUDO!!!


44/70

Riscos e medos

Segundo Beck, alguns riscos so:

Adiamento da data prevista Projeto cancelado: aps vrios adiamentos sem ao menos entrar

em produo

:

Negcio mal entendido: Ocorre quando o software no resolve oproblema do negcio

Mudana no negcio: O software entregue, mas os problemasforam substitudos.

Falsa caracterstica: O software possui muitas caractersticasinteressantes de proramao, mas no so rentveis para o cliente

Insatisfao da equipe: normalmente quando os bons

programadores se desinteressam pelo projeto.


45/70

Riscos e medos

Segundo Beck, alguns medos do cliente so:

No receber o que foi solicitado Solicitar uma coisa errada

Pagar muito por to pouco

No ver um plano, de desenvolvimento de projeto, confivel

Ficar preso s decises iniciais do projeto e no poder reagirs mudanas nos negcios

No saber o andamento do desenvolvimento do software

No saber da verdade (sobre as dificuldades dedesenvolvimento do projeto)


46/70

Riscos e medos

Segundo Beck, alguns medos do desenvolvedor so:

Ser mandado a fazer mais do que ele sabe Ficar desatualizado tecnicamente

Ser cobrado por responsabilidades sem ter recebido aautoridade necessria

Receber solicitaes superficiais sobre o que precisa ser feito

Ter de solucionar problemas difceis sem receber ajuda

Ter pouco tempo para conseguir os objetivos do

desenvolvimento No receber


47/70

Gerenciamento de riscos

Gerenciamento de riscos preocupa-se em identificar riscos edesenhar planos para minimizar seus efeitos em um projeto.

Um risco a probabilidade de que alguma circunstnciaadversa ocorra.

scos o pro e o a e am o cronograma ou recursos

Riscos do produto afetam a qualidade ou desempenho dosoftware sendo desenvolvido

Riscos do negcio afetam a organizao que desenvolve ou

compra o software Risco envolve mudanas, escolha e incertezas

Assim, o risco, a morte e impostos so as poucas certezas da

vida

Que riscos podem causar o fracasso


48/70

Que riscos podem causar o fracasso

de um projeto de software? Modificaes

Nos requisitos do cliente, nas tecnologias, nas leis, etc Que mtodo e ferramentas usar?

Quanta nfase na qualidade suficiente?

Eliminar riscos um risco, devemos minimiz-los

Estratgias de Riscos


49/70

Estratgias de Riscos

Proativas X Reativas Equipes de softwares

Estratgias reativas a riscosNo se faz nada...at que algo d errado.

Equipe corre para a ao

Modo de combate ao fogo Estratgias mais inteligente

Proativa


50/70

Estratgia Proativa

Comea muito antes do trabalho tcnico iniciar

Riscos potencias so identificados, suasprobabilidades e impactos so avaliados

Estabelece-se um plano para administrar riscos Plano de contingncia Resposta de modo controlado e efetivo


51/70

Riscos de Software


52/70

Tipos de Riscos de Software

Projeto

Produto ou Tcnicos Negcio


53/70

Risco de Projeto

Se eles tornam-se reais provavelmente o

cronograma se atrase e o custo aumente Complexidade, o tamanho e o grau de incerteza

, ,

cronograma, recursos e de requisitos


54/70

Riscos de Produto ou Tcnicos

Ameaam a qualidade e a pontualidade do

software a ser produzido Caso ele se torne realidade pode tornar a

im lementa o difcil ou im ossvel

Identificam problemas potenciais do projeto, deimplementao, de interface, de verificao e demanuteno

Ambiguidade nas especificaes, incerteza tcnica,obsolescncia tcnica, e tecnologia de ponta sofatores de riscos

R d N


55/70

Riscos de Negcios

Ameaa a viabilidade do software a ser construdo

Os principais 5 riscos de negcio: Construir um sistema ou produto excelente que ningum

quer (risco de mercado)

Construir um produto que no se enquadra mais na

estratgia geral da empresa (risco estratgico) Construir um produto que a equipe de vendas no sabe

como vender

Perda do apoio da gerencia superior por modificao daequipe (risco gerencial)

Perda do comprometimento oramentrio ou de pessoal(riscos de oramentos)

O d d


56/70

O processo de gerenciamento de risco

Identificao do risco

Identificar os riscos do projeto, do produto e donegcio

Anlise do risco

Avaliar a probabilidade e conseqncias desses riscos Planejamento do risco

Preparar planos para evitar ou minimizar os efeitos do

risco Monitoramento do risco

Monitorar os riscos durante todo o projeto

O d i d i


57/70

O processo de gerenciamento de risco


58/70

Identificao de risco Riscos tecnolgicos

Riscos de pessoal Riscos organizacionais

scos e erramen as

Riscos de requisitos

Riscos de estimativa

Ri ti d i


59/70

Riscos e tipos de risco

Id tifi d i Ch kli t


60/70

Identificao de riscos - Checklist

Tamanho do produto

Impacto no negcio Caractersticas do cliente

e n o o processo

Ambiente de desenvolvimento

Tecnologia para a construo

Tamanho e experincia da equipe

Exemplo de Checklist


61/70

Exemplo de Checklist

Os riscos esto plenamente entendidos pela equipe

de ES e por seus clientes? Os clientes envolveram totalmente na definio dos

re uisitos?

Os usurios finais tem expectativas realsticas? O escopo do projeto estvel?

A equipe suficiente para atender o projeto?

Anlise de riscos


62/70

Anlise de riscos

Avaliao de probabilidade e seriedade de cada

risco Probabilidade pode ser muito baixa, baixa,

moderada alta ou muito alta

Os efeitos do risco podem ser catastrfico, srio,tolervel ou insignificante

Anlise de risco (Exemplo 1)


63/70

Anlise de risco (Exemplo 1)

OBS.:Pode usar Chances ou Probabilidade de acontecer em %Pode usar Efeitos ou Probabilidade do impacto em % (levar em conta, natureza, escopo e poca)

Anlise de Risco (Exemplo 2)


64/70

Anlise de Risco (Exemplo 2)

Planejamento do risco


65/70

Planejamento do risco

Considerar cada risco e desenvolver uma

estratgia para gerenciar tal risco Estratgias para evitar o risco

Estratgias de minimizaoO impacto do risco no projeto ou produto ser

reduzido

Planos de contingncia Se o risco surgir, planos de contingncia so planos

para lidar com tal risco

Estratgias de Gerenciamento de


66/70

riscos

Monitoramento do risco


67/70

Monitoramento do risco

Cada averiguao identificou riscos regularmente

para decidir se est ou no se tornando menos oumais provvel

Tambm averi ua se os efeitos do risco mudaram

Cada risco-chave deve ser discutido nos encontrosde progresso de gerenciamento

Planilha final para Anlise de Risco


68/70

Planilha final para Anlise de Risco

Identificao do risco (nmero)

Risco

Descrio

Tipo de Risco (Projeto, Produto, Negcios)

Fator de risco (Pessoal, Organizacional, Tecnologia,Ferramentas, Requisitos, Estimativa)

Probabilidade de acontecer (Chances)

Impacto (Efeitos)

Consequncias e Estratgias de eliminao ou minimizao(RMMM Risk Mitigation, Monitoring, Management)

Valor (R$ ou U$S)

Pontos-chave


69/70

Pontos chave

Um bom gerenciamento do projeto essencial para o sucessodo projeto

A natureza intangvel do software causa problemas para ogerenciamento

eren es m versos pap s, mas suas a v a es ma s

significativas so o planejamento, estimativa e cronograma Planejamento e estimativa so processos interativos que

continuam durante todo o curso de um projeto

Pontos-chave


70/70

Pontos chave

Um milestone um estado previsvel onde algum

relatrio formal de progresso apresentado aogerenciamento.

Riscos odem ser de ro eto do roduto ou do

negcio Gerenciamento de riscos preocupa-se em

identificar riscos que possam afetar o projeto e

planejamento para certificar que tais riscos no setransformem em ameaas maiores

capitulo 5 - gerenciamento de projeto

Documents