como gerenciar na prática projetos de desenvolvimento de ... · como gerenciar na prática...
Post on 24-Jan-2019
223 Views
Preview:
TRANSCRIPT
Como Gerenciar na Prática Projetosde Desenvolvimento de Software
Gerson PechUniversidade do Estado do Rio de Janeiro
Gerson Pech - UERJ 2
15 de março de 1990
Gerson Pech - UERJ 3
Gerson Pech - UERJ 4
Apenas 5 dias para:
Alterar o sistema de 420 instituições financeiras;
Cruzado Novo – Cruzeiro;
Bloqueio dos saldos das contas correntes ecadernetas de poupança acima de CR$ 50,00;
Criação de novos tributos;
Criação de duas contas para cada cliente:Uma podendo movimentar, a outra não.
Gerson Pech - UERJ 5
Como foi a reabertura dos bancos?
Saldos não batiam;Diversas informações desencontradas;Alguns bancos nem puderam forneceros saldos;
Entretanto, as bases estavam lá
Caos Total
Gerson Pech - UERJ 6
Gerson Pech - UERJ 7
Uno mile online
• Aumento da demanda por carrospopulares;
• Fiat lança novo modelo para a comprade carros;
• Compra por telefone com prazosdeterminados de entrega;
• O programa é um sucesso:1o. VW 62% 22%2o. Fiat 8% 30%
Gerson Pech - UERJ 8
Uno mille off line
• Apenas 5% nas revendas ligadas por3270 a fábrica;
• O resto se comunicando por fax;• Entrada no sistema: Digitação;• Retorno para a empresa com prazo de
entrega.
Gerson Pech - UERJ 9
Antes de começar algumas lições
• Não bastam apenas processos padronizados;• Não basta que toda a documentação esteja
institucionalizada;• Não basta a tecnologia que será implantada;
O que importa é o uso que se faz de tudo isso!
Gerson Pech - UERJ 10
Quem solicita um software sabe oque quer?
Os usuários normalmente sabem exatamente o quenão precisam, depois de ver o software;À medida que o sw se desenvolve, tornando-setangível, os usuários vêem novas possibilidades etentam mudar o projeto de acordo com elas;Seu software fracassará se ele não for corretamenteutilizado ou não atender as especificações de seusclientes.
S = P – E
Gerson Pech - UERJ 11
Problemas de software
• Prazo estourados;• Custo acima do esperado;• Dificuldade/impossibilidade de
manutenção;• Desempenho inadequado;• Não faz o que deveria fazer ...
Gerson Pech - UERJ 12
O que é gerência de projeto desoftware?
Gerência de Projeto de Software é aaplicação de conhecimento, habilidades,ferramentas e técnicas no desenvolvimentode software com o objetivo de atender osrequerimentos do projeto.
Baseado no PMI – PMBook, 2000www.pmi.org
Gerson Pech - UERJ 13
Principal Dificuldade
Balancear demandas conflitanteBalancear demandas conflitante
Atingir ou exceder necessidadese expectativasAtingir ou exceder necessidadese expectativas
Gerson Pech - UERJ 14
A Restrição Tripla
Escopo
PrazoRecursos
Gerson Pech - UERJ 15
Stakeholders ?
Gerson Pech - UERJ 16
O que são Stakeholders?
Todos aqueles que influenciam oprojeto.
Gerson Pech - UERJ 17
Processo de Gerência de Stakeholders
organizando
planejandocontrolando
dirigindo
motivando
Identificar osStakeholders
LevantarInformações sobre os stk
Identificar amissão dos stk
Determinaros pts fortes efracos dos stk
Identificar aestratégiados stk
Equipede Gerência de swPrever o
comportamentodos stk
Implementara gerência
Gerson Pech - UERJ 18
conc
epçã
o
plan
ejam
ento
exec
ução
final
izaç
ão
Tempo
Nív
el d
e A
tivid
ade
Ciclo de vida
Gerson Pech - UERJ 19
Concepção
• Identificação das necessidades;• Definição do problema;• Determinação dos objetivos, metas e
escopo;• Análise do ambiente;• Análise das potencialidades e recursos
disponíveis;
Gerson Pech - UERJ 20
Concepção
• Estudo das viabilidades dos objetivos;• Estimativa dos recursos necessários;• Elaboração da proposta do projeto;• Apresentação da proposta;• Decisão (ou não) de execução.
Gerson Pech - UERJ 21
Planejamento
• Detalhamento das metas e objetivos;• Programação das atividades;• Determinação dos pontos de controle
(milestones);• Programação de recursos;• Análise de Riscos;• Elaboração do Plano de Projeto.
Gerson Pech - UERJ 22
Planejamento de Qualidade de SoftwareISO 9000-3 (Orientações)
Definição do ciclo de vida utilizado
Definição dos critérios para início e fim decada fase
Identificação dos tipos de análise crítica
Identificação dos procedimentos de gestão de configuração, validação, verificação e testes
Gerson Pech - UERJ 23
PlanejamentoISO 9000-3 (Orientações)
Planos para cada fase do desenvolvimento
Análise dos superiores hierárquicos e aprovação,antes de entrar para a execução
Procedimentos para acompanhamento e análisescríticas periódicas pela gerência/clientes
Gerson Pech - UERJ 24
Plano de Projeto
• Quanto detalhado deve ser o Plano deProjeto?
• Quando deve ser iniciada a elaboraçãodo Plano de Projeto?
• Quem deve participar desta elaboração?• Quem deve receber uma cópia do
Plano?• Quem é o responsável final pelo Plano?
Gerson Pech - UERJ 25
Plano de Projeto
• Sumário Executivo;• WBS;• Declaração de Escopo;• Cronograma;• Plano de Gerência de Custos;• Plano de Qualidade;• Plano de RH;• Plano de Comunicação;• Plano de Gerência de Riscos;• Plano de Responsabilidades;• Plano de Avaliação para o Fechamento do Projeto.
Gerson Pech - UERJ 26
WBS (Work Breakdown Structrure)Estrutura de Desmembramento do Projeto
• Identifica todas as tarefas do projeto;• Fornece uma ilustração detalhada do
escopo do projeto;• Monitora o progresso do projeto;• Facilita o entendimento das
responsabilidades de cada membro deequipe;
Gerson Pech - UERJ 27
WBS
Desmembrar o projeto em unidades detrabalho menores que tenhamsignificado e que sejam gerenciáveis.
Gerson Pech - UERJ 28
Desenv. doPlanej. de Turmas
Desenv. daInscrição em discip.
Identificar usuários
Entrevistar
Documentare apresentar
Realizar Análisede Requisitos
Desenvolvero modelo funcional
Desenvolvero modelo de dados
Elaborar projetofísico
Modelar
Implementarprogramas
Codificarconversão de dados
Codificar
Realizar os testesinternos
Realizar testesno usuário
Realizar piloto
Testar
Treinar usuários
Apresentação
Gerar versão
Implantar
Desenvolv. doControle Acadêmico
Desenvolv. doControle Curricular
Desenvolvimento do Sistema Acadêmico
Gerson Pech - UERJ 29
Id Nome da tarefa Início Término1 INSCRIÇÃO - REQUERIMENTOS DE INS Ter 2/13/01 Sex 5/4/012 Atualizar DADOS VESTIBULAR - Pa Ter 2/13/01 Ter 2/13/013 Emitir REQUERIMENTO DE INSCRI Ter 2/13/01 Seg 2/26/014 Registrar REMESSA DE REQUERIM Ter 2/13/01 Sex 3/23/015 Informar REQUERIMENTO DANIFIC Ter 2/13/01 Sex 5/4/016 Substituir REQUERIMENTO DE INSC Ter 2/13/01 Sex 3/23/017 INSCRIÇÃO DE CANDIDATOS Ter 3/13/01 Sex 3/23/018 CADASTRAMENTO BÁSICO Ter 3/13/01 Seg 4/2/0115 CADASTRAMENTO DO EDITAL Ter 3/13/01 Qui 5/3/0121 DIGITAÇÃO E DIGITALIZAÇÃO Seg 4/2/01 Ter 4/17/0125 INSCRIÇÃO - ATUALIZAÇÃO DE CADAS Ter 4/3/01 Qua 4/11/0132 IDENTIFICAÇÃO E CORREÇÃO DE NÚM Ter 4/3/01 Qua 4/11/0138 INSCRIÇÃO - ATLZ DO CADASTRO DEF Qua 4/11/01 Ter 4/17/0147 CADASTRAMENTO DE SALAS Seg 4/2/01 Ter 4/17/0155 ALOCAÇÃO DE CANDIDATOS Qua 4/18/01 Ter 4/24/0167 RETIF. E 2a VIA CARTÃO CONFIRMAÇÃ Sex 4/27/01 Sex 5/4/01
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
������������
T Q Q S S27 01
Gerson Pech - UERJ 30
Plano do Projeto
Desenvolverorçamento
Atribuir e Redistribuir
recursos
Gerência deRiscos
Criar sequênciapara as tarefas Criar WBS
Calcular ocronograma
Regras
Escopo Limitações
Planejamento
Estimar recursospara as tarefas
Gerson Pech - UERJ 31
Execução
• Execução das etapas previstas no planode projeto;
• Utilização dos recursos conformeprogramado;
• Solução dos conflitos;• Metas.
Gerson Pech - UERJ 32
Finalização
• Finalização formal;• Gestão de Conhecimento;• Re-alocação dos recursos;
Gerson Pech - UERJ 33
conc
epçã
o
plan
ejam
ento
exec
ução
final
izaç
ão
Tempo
Nív
el d
e A
tivid
ade
Ciclo de vida
Custo para Consertar um erroRiscos e
Incertezas
Gerson Pech - UERJ 34
Processos de Gerência
Uma série de ações que geram umresultado padronizado essencial para odesenvolvimento do software;
Gerson Pech - UERJ 35
Grupos de Processos - PMI
Processos de Iniciação; Processos de Planejamento; Processos de Execução; Processos de Controle; Processos de Encerramento
Gerson Pech - UERJ 36
Processos de Encerramento
Processos deControle
Processos deExecução
Processos de Planejamento
Processos deIniciação
Gerson Pech - UERJ 37
Controle – Reuniões de Análise CríticaISO 9000-3 (Orientações)
Verificação do andamento do projeto comrelação ao cronograma de desenvolvimento
Verificação das pendências do próprio cliente
Verificação da adequação dos produtosdesenvolvidos com relação ao especificado
Verificação do andamento do treinamento econversão de dados
Testes de aceitação
http:/www.abnt.org.br
Gerson Pech - UERJ 38
Controle – MediçãoISO 9126 (Definições)
Funcionalidade
Confiabilidade
Usabilidade Portabilidade
Manutenibilidade
Eficiência
Gerson Pech - UERJ 39
Controle – MediçãoISO 9126 (Definições)
Funcionalidade
• Propõe-se a fazer o que devia?
• Gera resultados conforme acordados?
• É capaz de interagir com os sistemas especificados?
• Evita acesso não autorizado,acidental a programas e dados?
• Está de acordo com normas e convenções previstas em lei edescrições similares?
Gerson Pech - UERJ 40
Controle – MediçãoISO 9126 (Definições)
Confiabilidade
• Com que frequência apresentafalhas?
• Ocorrendo falhas como elereage?
• É capaz de recuperar dadosdepois de uma falha?
Gerson Pech - UERJ 41
Controle – MediçãoISO 9126 (Definições)
Usabilidade
• É fácil entender os conceitosutilizados?
• É fácil aprender a usar?
• É fácil de operar e controlar aoperação?
Gerson Pech - UERJ 42
Controle – MediçãoISO 9126 (Definições)
Eficiência
• Qual o tempo de resposta ede processamento?
• Quanto recurso utiliza?
• Os recursos e os tempos sãocompatíveis com o nível dedesempenho requerido?
Gerson Pech - UERJ 43
Controle – MediçãoISO 9126 (Definições)
Manutenibilidade
• É fácil encontrar uma falhaquando ela ocorre?
• É fácil modificar e removerdefeitos?
• Há grandes riscos de bugsquando se faz uma alteração?
• É fácil testar quando se fazuma alterações?
Gerson Pech - UERJ 44
Controle – MediçãoISO 9126 (Definições)
Portabilidade
• É fácil adaptar a outros ambientessem aplicar outras ações ou meiosalém dos fornecidos para estafinalidade ?
• É fácil instalar em outros ambientes?
• É fácil substituir por outro software?
• Está de acordo com padrões ouconvenções de portabilidade?
Gerson Pech - UERJ 45
Tempo
Nív
el d
e A
tivid
ade
Iniciação
Planejamento
Controle
Execução
Final.
Gerson Pech - UERJ 46
Controle das alterações
Plano de Projeto
Relatório de desempenho
Requisições de mudança
Plano de Projeto atualizado
Ações corretivas
Lições aprendidas
Gerson Pech - UERJ 47
Alterações de RequisitosISO 9000-3 (Orientações)
É comum que requisitos não estejam completosdurante a assinatura do contrato dedesenvolvimento, mas as mudanças posterioresdevem ter o seu impacto devidamenteregistrados no contrato.
Gerson Pech - UERJ 48
Gerenciamento dos Riscos
O gerenciamento dos riscos é o meio pelo qual a incerteza é sistematicamente gerenciada para aumentar a probabilidade de cumprir os objetivos do projeto.
Gerson Pech - UERJ 49
Identificaçãodos Riscos
Desenvolvimentode Respostas Controle
Riscos novos Riscos novos
Gerenciamento de Riscos
Gerson Pech - UERJ 50
Identificaçãodos Riscos
Desenvolvimentode Respostas Controle
Riscos novos Riscos novos
Gerenciamento de Riscos
Gerson Pech - UERJ 51
Identificação dos Riscos
Perguntar aos participantes;
Sessões de criação de idéias;
Crie a maior lista possível de riscos potenciais;
Combine os riscos semelhantes
Tudo que pode dar errado dará erradoLei de Murphy
Gerson Pech - UERJ 52
Como Identificar os Riscos?
• Aprenda a partir de projetos dedesenvolvimento antigos
Perfil de RiscosSão específicos a uma determinada área;São específicos a uma determinadaorganização;Devem ser atualizados.
Gerson Pech - UERJ 53
Equipe do Projeto
• Quantas pessoas tem a equipe?• Que percentual da equipe está dedicada
integralmente ao projeto?• Que membros da equipe irão gastar menos que
20% de tempo trabalhando no projeto?• Qual o nível de experiência da equipe?• Os membros da equipe já trabalharam juntos
antes?• A equipe está geograficamente espalhada?• Quais os membros da equipe que poderão
abandonar o projeto?
Gerson Pech - UERJ 54
Cliente
• O cliente irá mudar seus processos atuais parautilizar o sistema?
• O sistema para ser utilizado precisará dereorganização do cliente?
• Os clientes são de departamentos diferentes?• Existe sistema atual para as funcionalidades que
serão desenvolvidas?• Existe resistência por parte do usuário?
Gerson Pech - UERJ 55
Tecnologia
• A tecnologia que será usada é novidade para aequipe de desenvolvimento?
• A tecnologia que será usada é novidade para aclientes e usuários?
• Existe alguma tecnologia de ponta no projeto?• A equipe possui maturidade para o
desenvolvimento de sistemas dessa complexidade?• Existem ferramentas disponíveis para o trabalho?
Perfil de Riscos – SEIContinuous Risk Management Guidebookhttp://www.sei.cmu.edu/
Gerson Pech - UERJ 56
Realize Registros Históricos
• Desempenho: Planejado X Real;• Problemas relativos a mudanças
inesperadas; e como elas foramtransportadas;
• Análise após o fim do projeto;• Satisfação do cliente.
Gerson Pech - UERJ 57
Identificaçãodos Riscos
Desenvolvimentode Respostas Controle
Riscos novos Riscos novos
Gerenciamento de Riscos
Gerson Pech - UERJ 58
Como Desenvolver uma Estratégia deResposta
1o passo: Defina a gravidade do risco;Qual o impacto do risco?
2o passo: Atribua uma probabilidade;Qual a probabilidade do problema ocorrer?
3o passo: Desenvolva uma estratégia para reduzir um possível dano.
Gerson Pech - UERJ 59
Risco maldefinido:O projeto de desenvolvimento exige o uso de uma
nova tecnologia.
Melhor:O departamento de RH exige que o acesso aosistema se dê através da Web. Os programadores dodepartamento de informática ainda nãodesenvolveram programas nessa tecnologia.
Gerson Pech - UERJ 60
Def
iniç
ãoRisco: Os usuários nunca utilizaram leitoras de código de barra,ferramentas que serão as componentes de entrada de dados para oprocessamento.Conseqüência: A utilização incorreta irá introduzir erros na base. Esteserros poderão causar retrabalho de até três dias para a equipe causandoatraso no prazo final de entrega dos relatórios finais.
Prob
abili
dade Probabilidade de retrabalho de 1d. – 20% - R$ 10.000,00
Probabilidade de retrabalho de 2d. – 10% - R$ 20.000,00 graveProbabilidade de retrabalho de 3d. – 5% - R$ 30.000,00 ...
Estra
tégi
a Enviar todos os operadores para um curso intensivo;R$ 2.000,00 – 2d
Contratar o fornecedor para suprir dois ou três operadores especializados;R$ 600,00 /d/op
Gerson Pech - UERJ 61
Def
iniç
ãoRisco: mudanças nas leis que regulamentam as aplicações financeirasintroduzirão novas exigências no projeto de desenvolvimento do sw.
Conseqüência: O software não mais irá atender aos requisitosestabelecidos pelo usuário.
Prob
abili
dade
Estra
tégi
a
30% no final de um semestre – Dados históricos;
Analisar com todos os detalhes todas as mudanças ocorridas nos últimos quatro anos;Deixar o sistema parametrizado/generalizado para as principais mudanças;Tempo: + 2,5 mesesCusto: + 280.000,00
Gerson Pech - UERJ 62
Como prevenir as conseqüências dos riscos?
• Aceitar • Evitar• Monitorar e preparar os planos de contingência• Transferir• Mitigar
Contratos fixos também têm riscos:• Você pode ser cobrado a mais;• Os terceirizados podem ter subestimado oscustos;
Gerson Pech - UERJ 63
Terceirizar um serviço especializado
Terceirização Falta de controle no projetoDificuldade de comunicação
Risco Terceirizado
Avaliação de Riscos
Para cada risco:
{ri , Pi , Ii }
ri iésimo risco
Pi prob. do ri ocorrer
Ii impacto de ri
Gerson Pech - UERJ 65
Impa
cto
ProbabilidadeP1
I1
ri
P2
I2
Curva de Segurança
Gerson Pech - UERJ 66
Impa
cto
Probabilidade
Perigo
Risco controlável
Gerson Pech - UERJ 67
MB B M A MA
MA
A
M
B
MB 1
109 8 7 6
54 3 2
1716
1514131211
2221
19 18
252423
20
Gerson Pech - UERJ 68
Identificaçãodos Riscos
Desenvolvimentode Respostas Controle
Riscos novos Riscos novos
Gerenciamento de Riscos
Gerson Pech - UERJ 69
Executar uma estratégia contra os riscos;
Monitorar os riscos;
Vigiar novos riscos;
Documentar os problemas.
Controle dos Riscos
Gerson Pech - UERJ 70
Os Erros Clássicos
“Nunca esquecem, e nunca aprendem”
Gerson Pech - UERJ 71
• 70% dos grandes projetos sofrem de instabilidade dos requisitos;• Pelo menos 50% dos projetos são executados com níveis de
produtividade abaixo da normal;• Pelo menos 25% dos sw de prateleira e 50% dos feitos por
encomenda apresentam mais defeitos do que o razoável;• Produtos feitos sob pressão de prazos podem quadruplicar o
número de defeitos;• Pelo menos 50% dos grandes projetos de sw estouram seu
orçamento e prazo;• 2/3 dos projetos de sw muito grandes são cancelados antes do
fim;• Tipicamente 50% do patrimônio de sw da empresa não são
utilizados;• Atritos entre a área de TI e a alta gerência ocorrem em mais de
30% das organizações;• Atritos com os clientes ocorrem em 50% dos contratos por
administração e 65% dos contratos por empreitada.
Base 4.000 projetos – Assessment and Control of Software Risks – Prentice-Hall Capers Jones
Gerson Pech - UERJ 72
Erros EstratégiaRequisitos: Características interessantes
Requisitos: Adição descontrolada denovos requisitos
Análise detalhada de novos requisitos
Análise de impacto
Prazos:Desperdício antes do início
Acabar com a inércia na tomada de decisões
Prazos:Prazos excessivamente otimistas
Controle das pressões de clientes e daalta gerência com a demonstração dedados históricos e do plano do projeto
Planejamento: Incompleto e insuficiente
Definir as estimativas corretas e terminar com o excesso de otimismo
Falta de controle gerencial paracumprir o planejado
Estabelecimento de marcos claros eacompanhamento das atividades de perto
Para o cumprimento de prazos impossíveis, abandono dos planos
As atividades planejamento dostestes, garantia de qualidade nãodevem ser cortadas
Gerson Pech - UERJ 73
Erros Estratégia
Codificação desenfreada
Falha de subcontratados
Aumentar a qualidade técnica dos produtos da análise. Modelo físico.
Procedimentos de controle das tarefas realizadas pelos subcontratados
Entrega prematura do produtoConseguir autorização para adiamento dos prazos. Atenção nunca usar a Estratégia Vietnã.
Falta de patrocínio eficaz
Falta de participação das partes interessadas no produto
Torna-las parte do projeto. Mostrar que se o projeto sair vitorioso, será por causa do deles.
Defeitos de formação do staffdo Projeto.
Métodos adequados de seleção.Desenvolvedores mais experientespodem treinar os novatos. Cuidado como aumento de profissionais.
O comprometimento dos sponsors deve ser trabalhado através de reuniões e apresentações
Atritos entre os desenvolve- dores e os clientes/usuários
Gestão das expectativas dos clientes/usuários
Gerson Pech - UERJ 74
Erros Estratégia
Salas apinhadas e barulhentas
Falta de motivação dos desenvolvedores
Organização do ambiente para o aumento da concentração
Programa de avaliação baseado em metas reais e desafios profissionais
Mudança de ferramenta no meio do projeto (sw/hw)
Falta de automação de algumas atividades
Ferramentas para automatizar a gestãode configurações.Ferramenta para a modelagem.A execução e controle dos testesprecisa ser automatizada.
Estimativa exagerada dos ganhos de produtividade
O importante não é a tecnologia , masComo ela será utilizada
Mudanças de tecnologia devem seravaliadas, planejadas e introduzidasfora da pressão dos prazos
Gerson Pech - UERJ 75
Problemas Comuns
Base: Princípios e Técnicas de Gerência de Projetos - FGV
Gerson Pech - UERJ 76
1o Problema Comum: Responsabilidade além da sua autoridade
Você é o gerente de desenvolvim ento e possui em sua equipe analistas que não estão sob a sua gerência direta e nem sob a gerência do Sponsor do projeto. Com o transform a-los em um tim e que responda, com entusiasm o e confiança, pelo projeto?
Gerson Pech - UERJ 77
1o Problema Comum: Responsabilidade além da sua autoridade
Sugestões:
Project Charter: Publicação pelo sponsor. Ênfase na autoridade do PM.
Razão do Projeto: Explicação para a equipe da importância do projeto.
Sponsor: Informação.
Gerson Pech - UERJ 78
1o Problema Comum: Responsabilidade além da sua autoridade
Sugestões:
Deliverables: Importância e responsabilidade dentro do projeto.
Diagrama de Rede: Conexão e integração entre asatividades de todos.
Plano de Comunicação: Participação máxima da elaboração.
Gerson Pech - UERJ 79
2o Problema Comum: O Salvador da Pátria
O projeto está um com pleto desastre. Cronogram a atrasado, orçam ento estourado, cliente insatisfeito,grande pressão interna. Por isso, o PM foi dem itidoe você assum e o seu lugar. O que fazer?
Gerson Pech - UERJ 80
2o Problema Comum: O Salvador da Pátria
Sugestões:
Análise Financeira: Decisão go/no go.
Objetivos e Escopo: Quais os objetivos do projeto?Priorize o que falta do escopo.Esclareça as penalidades.
Time: Ouça o que eles tem a dizer.Alternativas podem surgir
Gerson Pech - UERJ 81
2o Problema Comum: O Salvador da Pátria
Sugestões:
Novo Cronograma:
Refaça a análise do caminho crítico supondo todos osrecursos necessários.
Negocie mais tempo, mais recursos e menos escopo.
Esteja 100% seguro antes de entregar o seu 1o
Cronograma.
Faça reuniões freqüentes e pequenas focadas nosresultados e marcos. Celebre pequenas vitórias.
Gerson Pech - UERJ 82
3o Problema Comum: Estimativas Impossíveis
Você foi designado para um projeto com tarefas m uito difíceis de serem estim adas. Apesar de fazerparte dos processos já definidos, você não querdivulgar um cronogram a, porque sem pre acontecealgum a coisa que aum enta em 30% ou 40% suasestim ativas. O que fazer?
Gerson Pech - UERJ 83
3o Problema Comum: Estimativas Impossíveis
Sugestões:
Estimativas por fases: Não vá além do que está emseu horizonte.
Tarefas Pequenas: Isole as tarefas mais imprevisíveis.
Dados Históricos: Pesquise se existem riscos comunscom projetos passsados.
Gerson Pech - UERJ 84
4o Problema Comum: Time to Market
Você é obrigado a ter um tem po de desenvolvim entode software 25% m enor do planejado. Entretanto,a funcionalidade e recursos não podem ser alterados.O que fazer?
Gerson Pech - UERJ 85
4o Problema Comum: Time to Market
Sugestões:
Base: Comece construindo uma base sólida.
Fases Distintas: Não detalhe o cronograma até o final. Trabalhe por fases.
Plano do Projeto: Construa o plano por fases contendo planos de qualidade.
Gerson Pech - UERJ 86
Programa de Melhoria deProcessos
Gerson Pech - UERJ 87
Programa de Melhoria de Processos - Condições
• Forte apoio da alta administração;• Gerentes devem ter participação ativa;• Envolvimento de todos;• Processos atuais devem ser conhecidos;• Investimentos;• Estágios intermediários com pontos de
controle.
Engenharia de softwareWilson de P. Paula. LTC Ed.
Gerson Pech - UERJ 88
Prog. de Melhoria de Processos - Estabilização
• Formação de grupos de MP;• Formação de estruturas
organizacionais;• Desenvolvimento de recursos de apoio;• Treinamento, orientação,
aconselhamento e comunicação;• Medições do grau de progresso;
Gerson Pech - UERJ 89
Os Personagens
• Campeões;• Patrocinadores;• Agentes.
Gerson Pech - UERJ 90
Fase Atividades
Início
Diagnóstico
Estabelecimento
Ação
Lições
MotivaçãoPatrocínioInfra-estruturaAferições
RecomendaçõesPriorização
AbordagemPlanejamento
Criação da soluçãoTestes-pilotoRefinamentoAnálise e Validação
Proposição de ações futuras
Gerson Pech - UERJ 91
Processos – ISO 12207
AquisiçãoFornecimento
Operação
Manutenção
FUNDAMENTAIS
Desenvol-vimento
DocumentaçãoG. de Configuração
Verificação
APOIO
Validação
Garantia de Qualidade
Revisão ConjuntaAuditoria
Resolução de Problemas
GerênciaMelhoria Treinamento
Infra-estruturaOrganizacionais
Gerson Pech - UERJ 92
CMM – Modelo de Maturidade deCapacitação para Software
SEI – Carnegie Mellon UniversityPittsburgh, Penn EUACriado em 1984 pelo DoD
“Melhorando o processo é possível melhorarmoso software.”
http://www.sei.cmu.edu/cmm
Gerson Pech - UERJ 93
O que é Maturidade de Capacitação?
• Assegurar a gerenciabilidade doprojeto
• Assegurar a qualidade do produtogerado
• Assegurar a adaptação do processoàs características específicas daempresa
• Assegurar melhora contínua.
Gerson Pech - UERJ 94
CMM – Caminho de Melhoria Evolutiva
1o. Inicial – Poucos processos são definidos. Sucesso depende do esforço individual.
2o. Repetível – Processos básicos de gestão são definidos.
3o. Definido – Processo padronizado e integra-do em um processo padrão p/ a organização.
4o. Gerenciado – Processos e produtos sãoquantitativa// compreendidos e controlados.
5o. Otimizado – Melhoria contínuado processo.
Gerson Pech - UERJ 95
Nível 1 - Inicial
Faltam práticas de gestão
Planejamento ineficiente
Compromissos reativos
Abandono aos procedi-mentos planejados
Processos constantemente Alterados
Desempenho imprevisível
Gerson Pech - UERJ 96
INOUT
Visibilidade da Gerência no Nível 1
Gerson Pech - UERJ 97
Nível 2 - Repetível
Estabilidade: das políticas de gestão e dos procedimentos para implementá-las
Experiência Adquirida
Institucionalização dosprocessos
Controle de custos, cronogra- ma e funcionabilidade
Problemas com compromissos são identificados
Gerson Pech - UERJ 98
Visibilidade da Gerência no Nível 2
IN OUT
Gerson Pech - UERJ 99
Processo de swpadrão para a organização
Nível 3 - Definido
Práticas de ES efetivas - SEPG
Programa de Treinamento
Processo de sw definido doprojeto
Qualidadecontrolada
Gerson Pech - UERJ 100
Visibilidade da Gerência no Nível 3
IN OUT
Gerson Pech - UERJ 101
Nível 4 - Gerenciado
Capabilidade previsívelProdutos de alta qualidade
Metas quantitativas de qualidade para os produtos
Metas quantitativas de qualidade para os processos
Gestão do conhecimentoO processo opera dentrode limites mensuráveis
Gerson Pech - UERJ 102
Visibilidade da Gerência no Nível 4
IN OUT
Gerson Pech - UERJ 103
Nível 5 – Em Otimização
A organização está voltada para a melhoriacontínua do processo
Identificação das oportunidades
Análise de custo/benefício de novas tecnologias
Análise das falhas para determinar as causas
Lições são disseminadas
Gerson Pech - UERJ 104
IN OUT
Visibilidade da Gerência no Nível 5
Gerson Pech - UERJ 105
5
4
3
2
1
Gerson Pech - UERJ 106
Tempo/Custo
Prob
abili
dade
Gerson Pech - UERJ 107
SPICE – Software Process Improvement and Cabability dEtermination - ISO 15505
Seis Níveis de Capabilidade – Escala crescente Qualquer processo pode estar em qualquer nível
Nível Processo0 Incompleto
1 Executado
2 Gerenciado
3 Estabelecido
4 Previsível
5 Otimizado
Gerson Pech - UERJ 108
A Estrutura do CMM
Gerson Pech - UERJ 109
Nível de MaturidadeNível de Maturidade
Áreas Chaves de Processo
Áreas Chaves de Processo
CaracterísticasComuns
CaracterísticasComuns
Práticas ChavesPráticas Chaves
Capabilidadedo processo
Metas
Institucionalização
Infraestrutura ouatividade
Contém
Organizado por
Contém
indica
alcança
encaminha
descreve
Gerson Pech - UERJ 110
CMM – Caminho de Melhoria Evolutiva
1o. Inicial – Poucos processos são definidos. Sucesso depende do esforço individual.
2o. Repetível – Processos básicos de gestão são definidos.
3o. Definido – Processo padronizado e integra-do em um processo padrão p/ a organização.
4o. Gerenciado – Processos e produtos sãoquantitativa// compreendidos e controlados.
5o. Otimizado – Melhoria contínuado processo.
Gerson Pech - UERJ 111
Áreas-chave de Processo do Nível 2
Gestão de Requisitos
Planejamento de Projeto de Software
Acompanhamento e Supervisão de Projeto de Software
Gestão de Subcontratação de Software
Garantia de Qualidade de Software
Gestão de Configuração de Software
Gerson Pech - UERJ 112
Metas
Gestão de Requisitos
Meta 1 Os requisitos de sistema alocados ao sw são controlados para estabelecer um baseline parao desenvolvimento de sw e para uso gerencial.
Meta 2 Os planos, os produtos e as atividades de software são mantidos consistentes com os requisitos de sistema alocados ao software.
Gerson Pech - UERJ 113
Práticas Chave
Gestão de Requisitos
Compromisso 1 O projeto segue uma política estabelecida pela organização para o gerenciamento de requisitos de sistema alocados ao software.
Gerson Pech - UERJ 114
Práticas Chave
Gestão de Requisitos
Habilidade 1 Para cada projeto é definida a responsabilidade pelos RS e sua alocaçãoao hw, ao sw a aos outros componentesdo sistema.
Habilidade 2 Os requisitos alocados são documentados.
Habilidade 3 Recursos e orçamentos adequados são providos para a gerência dos requisitos alocados.
Gerson Pech - UERJ 115
Práticas Chave
Gestão de Requisitos
Habilidade 4 Os membros da equipe de desenvolvimento de sw e outros grupos de sw relacionados são treinados para realizar suas atividades de GR.
Gerson Pech - UERJ 116
Práticas Chave
Gestão de Requisitos
Atividade 1 A equipe de desenvolvimento revisa os requisitos alocados antes deles serem incorporados ao projeto de sw.
Atividade 2 A equipe de desenvolvimento deve utilizar osrequisitos alocados como base para os planos,para os produtos e para as atividades de sw.
Atividade 3 As modificações nos requisitos alocados sãorevisadas e incorporadas ao projeto.
Gerson Pech - UERJ 117
Práticas Chave
Gestão de Requisitos
Medições e As medições são realizadas e utilizadasAnálises 1 para determinar a situação das
atividades de gestão de requisitos
Gerson Pech - UERJ 118
Práticas Chave
Gestão de Requisitos
Verificação 1 As atividades de GR são revisadas periodicamente por um gerente superior.
Verificação 2 As atividades de GR alocados sãorevisadas pelo gerente de projeto, tantoperiodicamente,como motivadas por umevento.
Verificação 3 A equipe de garantia da qualidade de swdeve revisar e/ou proceder à auditoriadas atividades e dos produtos da GR alocados e reportar os resultados.
Gerson Pech - UERJ 119
Gestão de Requisitos:Procedimentos
CadastramentoCadastramento
AlteraçõesAlterações
RastreamentoRastreamento
Gerson Pech - UERJ 120
Número Nome do requisito Tipo Importância Complexidade Estabilidade1 Interface de usuário Tela de Abertura do Caixa Interface Essencial Baixa Média2 Interface de usuário Tela de Compras Interface Essencial Média Média3 Interface de usuário Tela de Estoque Interface Desejável Média Baixa4 Interface de usuário Tela de Fechamento do Caixa Interface Essencial Baixa Média5 Interface de usuário Tela de Fornecedores Interface Essencial Média Baixa6 Interface de usuário Tela de Mercadorias Interface Essencial Média Alta7 Interface de usuário Tela de Nota Fiscal Interface Desejável Baixa Alta8 Interface de usuário Tela de Pedidos de Compras Interface Opcional Baixa Baixa9 Interface de usuário Tela de Relatórios Interface Essencial Baixa Baixa
10 Interface de usuário Tela de Usuários Interface Essencial Baixa Média11 Interface de usuário Tela de Vendas Interface Essencial Alta Média12 Interface de usuário Relatório de Estoque Baixo Interface Desejável Média Baixa13 Interface de usuário Relatório de Fornecedores Interface Desejável Média Baixa14 Interface de usuário Relatório de Mercadorias Interface Desejável Média Alta15 Interface de usuário Nota Fiscal Interface Essencial Média Baixa16 Interface de usuário Pedido de Compra Interface Opcional Baixa Baixa17 Interface de usuário Relação de Pedidos de Compra Interface Opcional Média Média18 Interface de usuário Ticket de Venda Interface Essencial Média Média19 Interface de software Sistema Financeiro Interface Desejável Média Média20 Caso de uso Abertura do Caixa Caso de uso Essencial Baixa Média21 Caso de uso Emissão de Nota Fiscal Caso de uso Desejável Média Média22 Caso de uso Emissão de Relatórios Caso de uso Essencial Baixa Baixa23 Caso de uso Fechamento do Caixa Caso de uso Essencial Baixa Média24 Caso de uso Gestão de Fornecedores Caso de uso Essencial Média Baixa25 Caso de uso Gestão de Mercadorias Caso de uso Essencial Média Média26 Caso de uso Gestão de Pedidos de Compra Caso de uso Opcional Baixa Baixa27 Caso de uso Gestão de Usuários Caso de uso Essencial Baixa Média28 Caso de uso Gestão Manual de Estoque Caso de uso Desejável Média Baixa29 Caso de uso Operação de Venda Caso de uso Essencial Alta Média30 Requisito de desempenho Tempo de resposta Não funcional Desejável Baixa Alta31 Restrição ao desenho Padrão de Nota Fiscal Não funcional Essencial Média Alta32 Restrição ao desenho Expansibilidade Não funcional Opcional Alta Média33 Atributo da qualidade Segurança do Acesso Não funcional Desejável Média Média34 Atributo da qualidade Apreensibilidade Não funcional Desejável Média Alta
Gerson Pech - UERJ 121
No Regra de Mudança
Alterações nos requisitos só devem ocorrer em marcos pré-definidos e acordados.
As alterações devem ser revisadas pelos grupos envolvidos.
Os impactos nos compromissos devem ser avaliados.
Os impactos devem ser comunicados na busca de acordo.
As alterações devem ser aprovadas pelos usuários-chave, gerente do projeto e gerentes executivos.
Devem ser produzidas novas versões do Plano de GR incorporando as alterações.
1
2
3
4
5
6
Engenharia de softwareWilson de P. Paula. LTC Ed.
Gerson Pech - UERJ 122
Número Nome do requisito Tipo Import. Complex. Estab. Status 1 Interface de usuário Tela de Abertura do Caixa Interface Essencial Baixa Média Original 2 Interface de usuário Tela de Compras Interface Essencial Média Média Original 3 Interface de usuário Tela de Estoque Interface Desejável Média Baixa Alterado 19 Interface de software Sistema Financeiro Interface Desejável Média Média Original 20 Caso de uso Abertura do Caixa Caso de uso Essencial Baixa Média Original
21 Caso de uso Emissão de Nota Fiscal Caso de uso Desejável Média Média Original 22 Caso de uso Emissão de Relatórios Caso de uso Essencial Baixa Baixa Original 30 Requisito de desempenho Tempo de resposta Não funcional Desejável Baixa Alta Original 31 Restrição ao desenho Padrão de Nota Fiscal Não funcional Essencial Média Alta Alterado 32 Restrição ao desenho Expansibilidade Não funcional Opcional Alta Média Original 33 Atributo da qualidade Segurança do Acesso Não funcional Desejável Média Média Original 34 Atributo da qualidade Apreensibilidade Não funcional Desejável Média Alta Original 35 Atributo de qualidade portabilidade Não funcional Essencial Média Baixa Novo
Cadastro Atualizado de Requisitos
Gerson Pech - UERJ 123
Data Requisito alterado Tipo de mudança Motivo Impacto
26/5/2001 Caso de uso Operação de Venda
Alteração no fluxo Falha da Análise 3 dias de atraso; mais 15 horas de esforço
25/6/2001 Interface de usuário Emissão de Notas Fiscais
Alteração no leiaute Mudança de legislação Mais 2 horas de esforço
17/7/2001Interface de usuário Tela de
Estoque Alteração no leiaute Falha da Análise1 dia de atraso; mais 4
horas de esforço
18/7/2001 Diagrama de classes persistentes
Alteração em 2 operações da Classe Mercadoria
Conseqüência da alteração 3
2 dias de atraso; mais 6 horas de esforço
Tabela de Mudança de Requisitos
Gerson Pech - UERJ 124
Num Nome do item Tipo 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 341 Tela de Abertura do Caixa Cl. fronteira x2 Tela de Compras Cl. fronteira x x3 Tela de Estoque Cl. fronteira x x4 Tela de Fechamento do Caixa Cl. fronteira x5 Tela de Fornecedores Cl. fronteira x x6 Tela de Mercadorias Cl. fronteira x x7 Tela de Nota Fiscal Cl. fronteira x x8 Tela de Pedidos de Compras Cl. fronteira x x9 Tela de Relatórios Cl. fronteira x10 Tela de Usuários Cl. fronteira x x11 Tela de Vendas Cl. fronteira x x12 Sistema Financeiro Cl. fronteira x x x13 Caixa Cl. entidade x x14 Fornecedor Cl. entidade x x x x x x x15 Item de Compra Cl. entidade x x x x16 Item de Mercadoria Cl. entidade x x x x x x x17 Item de Venda Cl. entidade x x x x18 Mercadoria Cl. entidade x x x x x x x19 Usuário Cl. entidade x20 Nota Fiscal Cl. entidade x x21 Pedido de Compra Cl. controle x x x x x x x22 Venda Cl. controle x x x x x x x x23 Controlador de Mercadorias Cl. controle x x24 Controlador de Estoque Cl. controle x x25 Controlador de Compras Cl. controle26 Controlador de Fornecedores Cl. controle x x27 Emissor de Relatórios Cl. controle28 Tratador de Usuários Cl. controle x
Item de requisitos
Rastreamento
Gerson Pech - UERJ 125
Metas
Planejamento de Projeto
Meta 1 As estimativas de sw são documentadas para serem utilizadas no planejamento e no acompanhamento de projeto.
Meta 2 As atividades e os compromissos do projeto desw são planejados e documentados.
Meta 3 Os grupos e as pessoas afetadas estão de acordo com os seus compromissos relacionadosao projeto de sw.
Gerson Pech - UERJ 126
Planejamento de Projetos - Procedimentos
Estimativa de tamanho
Distribuição do esforço
Distribuição dos recursos
Esforço total do projeto
Elaboração do cronograma
Gerson Pech - UERJ 127
Estimativa do Esforço Total do Projeto (ET )
ET
Pontos por Função (FP)
Dados Históricos
Gerson Pech - UERJ 128
Estimativa do Esforço Total do Projeto (ET)
ET
Pontos por Função (FP)
Gerson Pech - UERJ 129
Estimativa do Esforço Total do Projeto (ET)ET
Pontos por Função (FP)
ET = a FP + b
ba
http://www.ifpug.org/
Gerson Pech - UERJ 130
100 %20,00%55,00%20,00%5,00% Total
23,75%13,40%9,90%0,40%0,05% Testes
29,40%4,00%24,75%0,60%0,05% Implem.
19,65%2,00%16,50%1,00%0,15% Desenho
14,90%0,40%2,75%11,00%0,75% Análise
12,30%0,20%1,10%7,00%4,00% Requisitos
TotalTransiçãoConstruçãoElaboraçãoConcepção
Gerson Pech - UERJ 131
Id Nome da tarefa Duração1 Sistema de Desembolso Descentralizado 92 dias2 Análise de Requisitos 26 dias3 Reuniões de Iniciação 2 dias4 Definição do Escopo 2 dias5 Levantamento Inicial 5 dias6 Levantamento Detalhado dos Requisitos 7 dias7 Levantamento Detalhado dos Casos de Uso 7 dias8 Apresentação do Levantamento 2 dias9 Conclusão do Levantamento 1 dia10 Definição dos Requisitos 3 dias11 Estudo de Viabilidade 1 dia12 Construção do Modelo Lógico 34 dias13 Detalhamento de Objetos e Classes 6 dias14 Organizações das Classes e Relacionamentos 6 dias15 Desenho Inicial 2 dias16 Esboço do Modelo do sw 2 dias17 Elaboração do Modelo de Banco de Dados 6 dias18 Detalhamento dos Diagramas 20 dias19 Construção do Modelo Físico 14 dias20 Modelagem Física - Fase Inicial 7 dias21 Modelagem Física - Fase Final 7 dias22 Implementação 27 dias
����
��������������
������������
������������
������������
������������
����������������
��������
����
��������������
��������������
�����������
����Q
Gerson Pech - UERJ 132
Gerson Pech - UERJ 133
mar/02 abri/02 mai/02 jun/02 jul/02 ago/02 set/02 out/02
Tempo
Esfo
rço
Acu
mul
ado
VE
VP
EESEERSR
EESR
IDE =
IDP =
EESRERSR
EESREESE
Gerson Pech - UERJ 134
Planejamento de Projetos - Procedimentos
Planejamento de Custos
Orçamento de Custos
Controle de Custos
Estimativa de Custos
Gerson Pech - UERJ 135
Gerson Pech - UERJ 136
Plano de Entregáveis Despesas Despesas Datas Planejado Desembolsos Percentual Agregado AgregadoContas Planejado Realizado Acumulado Acumulados Realizado Acumulado
1.2 CADASTRAME 1K R$ 20,00 1K R$ 22,00 02/Abr/01 1K R$ 20,00 1K R$ 22,00 100% 1K R$ 20,00 1K R$ 20,001.5 INSCRIÇÃO - 1K R$ 30,00 1K R$ 31,00 11/Abr/01 1K R$ 50,00 1K R$ 53,00 100% 1K R$ 30,00 1K R$ 50,001.6 IDENTIFICAÇ 1K R$ 35,00 1K R$ 37,00 13/Abr/01 1K R$ 85,00 1K R$ 90,00 100% 1K R$ 35,00 1K R$ 85,001.4 DIGITAÇÃO E 1K R$ 30,00 1K R$ 32,00 17/Abr/01 1K R$ 115,00 1K R$ 122,00 100% 1K R$ 30,00 1K R$ 115,001.7 INSCRIÇÃO - 1K R$ 35,00 1K R$ 35,00 17/Abr/01 1K R$ 150,00 1K R$ 157,00 100% 1K R$ 35,00 1K R$ 150,001.8 CADASTRAME 1K R$ 40,00 1K R$ 39,00 17/Abr/01 1K R$ 190,00 1K R$ 196,00 100% 1K R$ 40,00 1K R$ 190,001.9 ALOCAÇÃO D 1K R$ 40,00 1K R$ 43,00 24/Abr/01 1K R$ 230,00 1K R$ 239,00 100% 1K R$ 40,00 1K R$ 230,001.3 CADASTRAME 1K R$ 15,00 1K R$ 20,00 01/Mai/01 1K R$ 245,00 1K R$ 259,00 100% 1K R$ 15,00 1K R$ 245,001.1 INSCRIÇÃO - 1K R$ 30,00 1K R$ 40,00 03/Mai/01 1K R$ 275,00 1K R$ 299,00 100% 1K R$ 30,00 1K R$ 275,001.10 RETIF. E 2a V 1K R$ 55,00 1K R$ 56,00 04/Mai/01 1K R$ 330,00 1K R$ 355,00 100% 1K R$ 55,00 1K R$ 330,001.11 RETIFICAÇÃO 1K R$ 55,00 1K R$ 60,00 08/Mai/01 1K R$ 385,00 1K R$ 415,00 100% 1K R$ 55,00 1K R$ 385,001.13 ALOCAÇÃO - 1K R$ 25,00 1K R$ 26,00 18/Mai/01 1K R$ 410,00 1K R$ 441,00 100% 1K R$ 25,00 1K U$ 410,001.12 REALIZAÇÃO 1K R$ 30,00 1K R$ 30,00 26/Mai/01 1K R$ 440,00 1K R$ 471,00 20% 1K R$ 6,00 1K U$ 416,001.14 APLICAÇÃO D 1K R$ 10,00 27/Mai/01 1K R$ 450,001.15 LEITURA CAR 1K R$ 20,00 01/Jun/01 1K R$ 470,001.16 CORREÇÃO 1K R$ 15,00 01/Jun/01 1K R$ 485,001.17 RELATORIOS 1K R$ 20,00 13/Jun/01 1K R$ 505,001.18 RESULTADO 1K R$ 15,00 19/Jun/01 1K R$ 520,00
Gerson Pech - UERJ 137
mar/01 abri/01 mai/01 jun/01 jul/01 ago/01 set/01 out/01
Tempo
Cus
to A
cum
ulad
o
VC
VP
COSECRSR
COSR
IDC =
IDP =
COSRCRSR
COSRCOSE
Gerson Pech - UERJ 138
CMM – Caminho de Melhoria Evolutiva
1o. Inicial – Poucos processos são definidos. Sucesso depende do esforço individual.
2o. Repetível – Processos básicos de gestão são definidos.
3o. Definido – Processo padronizado e integra-do em um processo padrão p/ a organização.
4o. Gerenciado – Processos e produtos sãoquantitativa// compreendidos e controlados.
5o. Otimizado – Melhoria contínuado processo.
Gerson Pech - UERJ 139
Metas
Área Chave – Nível 4Gestão Quantitativa de Processo
Meta 1 As atividades de gerência quantitativa de processo são planejadas
Meta 2 O desempenho do processo de softwaredefinido para o projeto é controladoquantitativamente
Meta 3 A capabilidade do processo padrão de softwareda organização é conhecido em termosquantitativos
Gerson Pech - UERJ 140
PSMPractical Software Measurement -
Objective Information for Decision Makers
Addison-Wesley
Gerson Pech - UERJ 141
Conceitos-Chave
Medição é um processo – Não é uma lista pré-definida degráficos e relatórios
Tanto a coleta quanto a análise de dados devem serPlanejadas
O PSM é flexível – Adaptado para atender Necessidades deInformação específicas
O PSM suporta as Necessidades Integradas de Informaçãodo fornecedor e do cliente
O PSM aborda as relações e compromissos entre os objetivosdo projeto
Gerson Pech - UERJ 142
Produto deInformação
Necessidades deInformação
Medida Derivada
Indicador
Modelo deanálise
Medida Derivada
Função de Medição
Medida Básica Medidas Básicas
Método de Medição
Método de Medição
Atributo
Interpretação
Propriedades relevantesAtributo
Gerson Pech - UERJ 143
PSM - Categorias de Informação
Cronograma e Progresso
Recursos e Custo
Tamanho e Estabilidade do Produto
Qualidade do Produto
Performance do Processo
Eficácia da Tecnologia
Satisfação do Cliente
Gerson Pech - UERJ 144
PSM - Categorias de Informação
Cronograma e Progresso
Recursos e Custo
Tamanho e Estabilidade do Produto
Qualidade do Produto
Performance do Processo
Eficácia da Tecnologia
Satisfação do Cliente
Gerson Pech - UERJ 145
PSM - Conceito Mensurável
Cronograma e Progresso
Alcance dos Marcos
Performance do CP
Progresso das Unidades de Trabalho
Capacidade Incremental
Gerson Pech - UERJ 146
PSM - Conceito Mensurável
Cronograma e Progresso
Alcance dos Marcos
Performance do CP
Progresso das Unidades de Trabalho
Capacidade Incremental
Gerson Pech - UERJ 147
PSM - Medida
Cronograma e Progresso
Progresso das Unidades de TrabalhoRequisitos RastreadosRequisitos TestadosRelatórios de Problemas AbertosRelatórios de Problemas FechadosRevisões CompletadasRequisições de Mudanças AbertasRequisições de Mudanças FechadasUnidades CodificadasUnidades IntegradasCasos de Testes ExecutadosCasos de Testes PassadosItens de Ação AbertosItens de Ações Completados
Gerson Pech - UERJ 148
Performancedo Processo
Eficácia da TecnologiaTamanho e
Estabilidade do Produto
Recursos e Custos
Cronograma e Progresso
Qualidade do Produto
Satisfação do Cliente
Gerson Pech - UERJ 149
PSM - Atividade de MediçãoISO - 15939
Gerson Pech - UERJ 150
A Clínica de Saúde João Guimarães – CSJG - tem o seu serviço deinformática terceirizado há quatro anos. Entretanto, Os funcionários daclínica vivem se queixando do sistema, cujas informações são duvidosas ecuja tecnologia não corresponde as expectativas dos médicos. O softwarecontrola praticamente toda a clínica. Pacientes, prontuário, ambulatório,internação, exames, farmácia, cobrança, pessoal etc.
Há cinco meses o conselho que administra a Clínica contratou uma outraempresa – TSOFT - para a construção de um novo sistema que fosse apto arealizar todos os procedimentos necessários à gestão administrativa emédica da CSJG.
O contrato estipula um prazo de oito meses para a implantação. Define opadrão de qualidade do produto, treinamento dos usuários, custosnecessários a implantação e um escopo bastante claro onde as funções doproduto final são resumidas.
A TSOFT inicia o projeto, entretanto, tem dificuldades na contratação deAnalistas que tenham experiência na área médica.
Gerson Pech - UERJ 151
Semanas
Def
eito
s
60
50
40
30
20
5 10 15 20 25
Defeitos Acumulados
DR
DE
DC
Gerson Pech - UERJ 152
Defeitos na Fase de Análise de Requisitos
40%
30%
20%
10%
Freq
uênc
ia
RI DO VP DE
Gerson Pech - UERJ 153
Defeitos por Fases
40%
30%
20%
10%
Freq
uênc
ia
RI DO VP DERI DO VP DE
Requisitos Projeto
Gerson Pech - UERJ 154
Semanas
120
100
80
60
40
5 10 15 20 25
Evolução dos Requisitos
RA
RE
Gerson Pech - UERJ 155
Incrementos ou mudanças nos requisitos
40%
30%
20%
10%
Freq
uênc
ia
RH Conselho Compras Outros
Gerson Pech - UERJ 156
Semanas 15 20 25 30
Progresso da Implementação
% do swcodif. etestado
75
60
45
30
Estimado
Real
Gerson Pech - UERJ 157
Semanas 2 4 6 8
Manutenção - Backlog
No. de solicitações
25
20
15
10
5
Solicitações Recebidas
Solicitações Fechadas
Gerson Pech - UERJ 158
Gerson Pechpech@uerj.br
Tel: 21 9969165521 25877477
top related