como gerenciar na prática projetos de desenvolvimento de ... · como gerenciar na prática...

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


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.


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


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%


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.


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!


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


Problemas de software

• Prazo estourados;• Custo acima do esperado;• Dificuldade/impossibilidade de

manutenção;• Desempenho inadequado;• Não faz o que deveria fazer ...


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


Principal Dificuldade

Balancear demandas conflitanteBalancear demandas conflitante

Atingir ou exceder necessidadese expectativasAtingir ou exceder necessidadese expectativas


A Restrição Tripla

Escopo

PrazoRecursos


Stakeholders ?


O que são Stakeholders?

Todos aqueles que influenciam oprojeto.


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


conc

epçã

o

plan

ejam

ento

exec

ução

final

izaç

ão

Tempo

Nív

el d

e A

tivid

ade

Ciclo de vida


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;


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.


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.


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


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


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?


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.


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;


WBS

Desmembrar o projeto em unidades detrabalho menores que tenhamsignificado e que sejam gerenciáveis.


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


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


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


Execução

• Execução das etapas previstas no planode projeto;

• Utilização dos recursos conformeprogramado;

• Solução dos conflitos;• Metas.


Finalização

• Finalização formal;• Gestão de Conhecimento;• Re-alocação dos recursos;


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


Processos de Gerência

Uma série de ações que geram umresultado padronizado essencial para odesenvolvimento do software;


Grupos de Processos - PMI

Processos de Iniciação; Processos de Planejamento; Processos de Execução; Processos de Controle; Processos de Encerramento


Processos de Encerramento

Processos deControle

Processos deExecução

Processos de Planejamento

Processos deIniciação


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


Controle – MediçãoISO 9126 (Definições)

Funcionalidade

Confiabilidade

Usabilidade Portabilidade

Manutenibilidade

Eficiência



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?



Confiabilidade

• Com que frequência apresentafalhas?

• Ocorrendo falhas como elereage?

• É capaz de recuperar dadosdepois de uma falha?



Usabilidade

• É fácil entender os conceitosutilizados?

• É fácil aprender a usar?

• É fácil de operar e controlar aoperação?



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?



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?



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?


Tempo

Nív

el d

e A

tivid

ade

Iniciação

Planejamento

Controle

Execução

Final.


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


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.


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.


Identificaçãodos Riscos

Desenvolvimentode Respostas Controle

Riscos novos Riscos novos

Gerenciamento de Riscos


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


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.


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?


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?


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/


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.


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.


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.


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


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


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;


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


Impa

cto

ProbabilidadeP1

I1

ri

P2

I2

Curva de Segurança


Impa

cto

Probabilidade

Perigo

Risco controlável


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


Executar uma estratégia contra os riscos;

Monitorar os riscos;

Vigiar novos riscos;

Documentar os problemas.

Controle dos Riscos


Os Erros Clássicos

“Nunca esquecem, e nunca aprendem”


• 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


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


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 desenvolvedores e os clientes/usuários

Gestão das expectativas dos clientes/usuários


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


Problemas Comuns

Base: Princípios e Técnicas de Gerência de Projetos - FGV


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?



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.



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.


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?



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



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.


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?


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.


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?


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.


Programa de Melhoria deProcessos


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.


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;


Os Personagens

• Campeões;• Patrocinadores;• Agentes.


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


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


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


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.


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.


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


INOUT

Visibilidade da Gerência no Nível 1


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, cronograma e funcionabilidade

Problemas com compromissos são identificados



IN OUT


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



IN OUT


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



IN OUT


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


IN OUT



5

4

3

2

1


Tempo/Custo

Prob

abili

dade


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


A Estrutura do CMM


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


Á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


Metas


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.


Práticas Chave


Compromisso 1 O projeto segue uma política estabelecida pela organização para o gerenciamento de requisitos de sistema alocados ao software.


Práticas Chave


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.


Práticas Chave


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.


Práticas Chave


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.


Práticas Chave


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


Práticas Chave


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.


Gestão de Requisitos:Procedimentos

CadastramentoCadastramento

AlteraçõesAlterações

RastreamentoRastreamento


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


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.


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


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


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


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.


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


Estimativa do Esforço Total do Projeto (ET )

ET

Pontos por Função (FP)

Dados Históricos


Estimativa do Esforço Total do Projeto (ET)

ET



Estimativa do Esforço Total do Projeto (ET)ET


ET = a FP + b

ba

http://www.ifpug.org/


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


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


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


Planejamento de Projetos - Procedimentos

Planejamento de Custos

Orçamento de Custos

Controle de Custos

Estimativa de Custos


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


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


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


PSMPractical Software Measurement -

Objective Information for Decision Makers

Addison-Wesley


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


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


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


PSM - Categorias de Informação


Recursos e Custo

Tamanho e Estabilidade do Produto


Performance do Processo

Eficácia da Tecnologia



PSM - Conceito Mensurável


Alcance dos Marcos

Performance do CP

Progresso das Unidades de Trabalho

Capacidade Incremental


PSM - Medida


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


Performancedo Processo

Eficácia da TecnologiaTamanho e

Estabilidade do Produto

Recursos e Custos





PSM - Atividade de MediçãoISO - 15939


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.


Semanas

Def

eito

s

60

50

40

30

20

5 10 15 20 25

Defeitos Acumulados

DR

DE

DC


Defeitos na Fase de Análise de Requisitos

40%

30%

20%

10%

Freq

uênc

ia

RI DO VP DE


Defeitos por Fases

40%

30%

20%

10%

Freq

uênc

ia

RI DO VP DERI DO VP DE

Requisitos Projeto


Semanas

120

100

80

60

40

5 10 15 20 25

Evolução dos Requisitos

RA

RE


Incrementos ou mudanças nos requisitos

40%

30%

20%

10%

Freq

uênc

ia

RH Conselho Compras Outros


Semanas 15 20 25 30

Progresso da Implementação

% do swcodif. etestado

75

60

45

30

Estimado

Real


Semanas 2 4 6 8

Manutenção - Backlog

No. de solicitações

25

20

15

10

5

Solicitações Recebidas

Solicitações Fechadas


Gerson [email protected]

Tel: 21 9969165521 25877477

como gerenciar na prática projetos de desenvolvimento de ... · como gerenciar na prática...

Documents