RUMO AO NÍVEL 3
Soeli T. Fiorini
SPIN/SP
Nov./1999
Agenda
Introdução
Rumo ao Nível 3
Noções da ACP (KPA)
ACP Nível 3 x Nível 2
Barreiras
Gastos
Retorno
CBA IPI
Dados do SEI
Metas do Desenvolvimento
Custo
Produtividade
Satisfação do Cliente
Cronograma
Lucro
Problema - Processo Imaturo
Processo improvisado pelos praticantes e
seus gerentes
Nada é rigorosamente seguido ou aplicado
Dependente das pessoas que realizam as
atividades
Problemas com custo e cronograma
Pouca visibilidade do progresso e qualidade
...
Processo Maduro
Consistente com a forma que o trabalho é
realizado
Definido, documentado e em melhoria
contínua
Visivelmente mantido por todos
Bem controlado - auditado e seguido
Medido
Tecnologia usada de forma disciplinada
Solução
MELHORIA DO PROCESSO
O que significa melhoria de
processo?
Reconhecer “a lei da criatividade”
Mudar o comportamento das pessoas
Prover mecanismos de feedback
medições
verificações
Esforço e reforço contínuo
dinâmico - nunca estático
...
Melhoria do Processo de
Software - SPI
Defina um modelo
IDEAL (iniciar, diagnosticar, estabelecer, agir,
implantar)
PDCA (planejar, fazer, verificar e agir)
Crie o seu modelo
Organize-se
Sumário do projeto
Priorize
avaliação
Conflitos, desafios e riscos de
projetos SPI
Conflito
cultura enraizada - processo e ideais
Desafio
implantar o processo com poucos recursos e
e no menor tempo possível
Risco
institucionalização
Rumo a Nível 3
N3
Foco no Processo da
Organização
Organization Process Focus
- OPF
OPF x N2
Gerência de Requisitos
Requisito do cliente x SPI
Projeto SPI possui requisitos (ACPs, práticas)
Projeto SPI x status dos requisitos
OPF x N2
Planejamento do Projeto de Software
Atividades de SPI - faça um projeto
Plano de Ação/Melhoria x Plano de Projeto
Plano de transferência de tecnologia
(cronograma ...)
OPF x N2
Supervisão e Acompanhamento de Projeto
de Software
Acompanhe o projeto SPI
tamanho, esforço, custo, cronograma, ...
acompanhar produtos produzidos
registrar dados de replanejamento - histórico
revisões
medições (ex. trabalho dos PATs)
SQA
OPF x N2
Gerência de Configuração de Software
Documentação do projeto SPI
Plano de ação, plano de gerência de configuração
e plano de garantia de qualidade, treinamentos,...
Planilhas de medições com status das áreaschaves do processo (KPAs)
ferramentas utilizadas no processo
OPF x N2
Garantia de Qualidade de Software
revisão/ auditoria de produtos do projeto SPI
Apoio na institucionalização dos processos -
feedback
OPF x N2
Gerência de Contrato de Software
Desenvolvimento de ferramentas para dar
suporte
“casar” com o tempo para institucinalização
OPF - Barreiras
Comprometimento da gerência superior
Respeito aos membros do SEPG
Recursos alocados
Motivação e comprometimento das
equipes
Gerentes e engenheiros cépticos mudança cultural
Organizações com freqüentes mudanças
OPF - Gastos
Recursos SEPG
coordenação, revisões, orientações,
medições, ...
Treinamento do SEPG
Treinamento para a organização
CMM e CBA IPI, processos, ferramentas, ...
Equipes (PATs)
Avaliação (assessment)
OPF - Retorno do Investimento
Redução do risco
Melhoria planejada
Melhoria de processo coordenada e focada
Entendimento da capacitação do processo
Avaliações
Aumento da capacitação do processo
Ações de melhoria
Definição do Processo da
Organização
Organization Process
Definition - OPD
Definição do Processo da
Organização - OPD
Desenvolver o Processo de Software
Padrão da Organização
Banco de
Dados de
Processos de
Software da
organização
Biblioteca
de Documentação Relacionada ao
Processo de
Software
Requisitos Externos
Requisitos de
Sistema
Descrições
dos
Ciclos de
Vida
Requisitos do
Sistema
Alocados ao
Software
Diretrizes
e Critérios
para Adaptar
o Processo de
Software
Padrão da
Organização
Selecionar o
Ciclo de Vida
Descrição do Processo de Software
Padrão da Organização
Arquitetura do Processo de Software
Descrição dos Elementos do
Processo de Software
Descrição do Processo de Software
Definido do Projeto
Ciclo de Vida de Software do Projeto
{Fase a} {Fase b} {Fase c} {Fase d}
Arquitetura de Alto Nível do Proc. Soft.
de Software
do Projeto
Desenvolver o
Processo de
Software
Definido do
Projeto
Descrição do Processo
de Software do Projeto
Plano de Desenvolvimento
de Software do Projeto
Tarefas de Projeto
Etapa a Etapa b Etapa c Etapa d
Atividades
Resultados do Projeto e artefatos de software
OPD x N2
Gerência de Requisitos
participantes são os clientes que tem
requisitos para melhoria de processos,
procedimentos e definições de processos
requisitos para criar padrão de documentação
requisitos para diretrizes e critérios de adaptação
requisitos para criar BB e biblioteca
padronização das descrições de processos de
gerência de requisitos
OPD x N2
Planejamento, Supervisão e
Acompanhamento do Projeto de Software
padronização das descrições de processos de
planejamento, supervisão e acompanhamento
descrições, templates, medições, padrões,
procedimentos
estimativas no banco de dados
OPD x N2
Gerência de Configuração de Software
padronização das descrições de processos de
gerência de configuração
descrições do processo de software padrão
sob SCM
ativos de processo gerenciados e controlados
OPD x N2
Garantia de Qualidade de Software
padronização das descrições de processos de
garantia de qualidade de software
participa da aprovação dos processos
revisa e/ou audita atividades e produtos de
OPD
OPD x N2
Gerência de Contrato de Software
padronização das descrições de processos de
gerência de contrato de software
definição de um “modelo de fábrica”
OPD - Barreiras
Nível de detalhes nas descrições de
processos e notações p/ representar o proc.
Boas práticas geralmente não estão definidas
e documentadas
Definição de processo não ser entendida
Esquema do banco de dados limitado
Mudanças durante a implantação/
institucionalização do processo
OPD - Gastos
Definir padrão para doc. de processos
Desenvolver e documentar o processo
Desenvolver e manter guidelines de
adaptação do processo
Definir e/ou comprar e manter o BD de
processo
Estabelecer e manter a biblioteca de
documentação relacionada ao processo
Treinamentos, medições, pilotos, ...
OPD - Retorno
Um processo e ativos -> Padronização
Base p/ gerar adaptações controladas
BD - possibilidade de medições e histórico
para estimativas -> controle/ previsibilidade
Biblioteca de documentação - auxilia no
aprendizado e institucionalização dos
processos
Programa de Treinamento
Training Program - TP
Programa de Treinamento - TP
Grupo de Treinamento
Necessidades de pessoas, projetos e organização
Padrões organizacionais
Procedimento
de Dispensa
Plano
Treinamento
Organização
Execução do
Treinamento
Plano
Treinamento
Projeto x
Plano
Treinamento
Projeto y
Plano
Treinamento
Projeto z
Registros de
Treinamentos
TP x N2
Gerência de Requisitos
Necessidade de treinamento contínuo
Treinamento em métodos, técnicas ...
TP x N2
Planejamento, Supervisão e
Acompanhamento do Projeto
Necessidade de treinamento contínuo
Ênfase em controles baseados em dados do
BD e limites
Pode-se incluir no plano de projeto as
necessidades de treinamento
TP x N2
Gerência de Configuração de Software
Necessidade de treinamento contínuo
TP x N2
Garantia da Qualidade de Software
Necessidade de treinamento contínuo
Ênfase em checklists padronizados
TP x N2
Gerência de Contrato de Software
Necessidade de treinamento contínuo
Treinamento de fornecedores
TP - Barreiras
Orçamento - dinheiro
Falta de suporte da gerência
Fornecer o treinamento muito tarde
Fornecer o treinamento muito cedo
Falta de instrutores
TP - Gastos
Treinamento para o grupo de treinamento
Padrões para preparação de cursos
Levantamento das necessidades de
treinamento
Prover o treinamento
Manter registros de treinamentos
Avaliações independentes - consultores
TP - Retorno
Capacitação das pessoas
Produtividade
Qualidade
Satisfação
Institucionalização mais rápida
Engenharia de Produtos de
Software
Software Product
Engineering - SPE
Engenharia de Produtos de
Software - SPE
Métodos
Ferramentas
Processo de Software Definido do Projeto - PSDP
Descrição
Requisitos
Codificação
Design
Documentação
Teste
Produtos sob SCM/ Gerenciados e Controlados
Revisão por Parceiros
Manter Consistência dos Artefatos
Coleta e
Análise
de Defeitos
SPE x N2
Gerência de Requisitos
Base para as atividades de SPE
Foco na definição de requisitos -métodos
SPE x N2
Planejamento, Supervisão e
Acompanhamento do Projeto de Software
definição de novas atividades a serem
incluídas e acompanhadas no plano do
projeto
SPE x N2
Gerência de Configuração de Software
definição de baselines de acordo com o ciclo
de vida do processo de desenvolvimento de
software estabelecido
integração da ferramenta de gerência de
configuração com as ferramentas de
desenvolvimento
SPE x N2
Garantia de Qualidade de Software
passa a ter mais recursos para realizar
revisões e auditorias -> procedimentos,
métodos, padrões de SPE ...
Passa a verificar traceability efetivamente
SPE x N2
Gerência de Contrato de Software
Cláusulas no contrato, se necessário, para
manter métodos, ferramentas e processos
compatíveis
Fábrica de software x atividades em
conjunto, integração do produto ...
SPE - Barreiras
Métodos e ferramentas pouco apropriados
ou incompatíveis
Métodos e ferramentas pouco eficientes
Processo pouco efetivo (ex. revisão por
pares)
Falta de conhecimento técnico
SPE - Gastos
Comprar ferramentas
Capacitar desenvolvedores nas técnicas e
ferramentas
Rastear e manter a consistência através
dos produtos
Definir e executar atividades de teste
Coletar e analisar dados de defeitos
SPE - Retorno
Consistência através dos produtos
Uso dos dados de defeitos para melhoria
do processo
Uso mais efetivo de ferramentas e
métodos
Mais controle e qualidade no
desenvolvimento
Gerência de Software
Integrada
Integrated Software
Management - ISM
Gerência de Software
Integrada - ISM
Processo de Software Padrão da Organização
Ciclos
Diretrizes
Padrões
de
e
e
Vida
Critérios
Formulários
Processo de Software Definido do Projeto
Plano de Desenvolvimento de Software
ISM x N2
Gerência de Requisitos
Base para o desenvolvimento do plano de
projeto
processo de gerência de requisitos ->
adaptação do processo - ex. solicitação de
mudanças (pequenas manutenções)
ISM x N2
Planejamento, Supervisão e
Acompanhamento do Projeto de Software
Estabelecer limites para gerenciar tamanho,
esforço, custo, dependências e caminhos
críticos do cronograma e recursos críticos de
computação
Riscos gerenciados - todos os eventos com
reais possibilidades de impedir que o projeto
alcance seus objetivos - plano de ger. riscos
ISM x N2
Planejamento, Supervisão e
Acompanhamento do Projeto de Software
Desenvolver e revisar o processo do projeto definido com base no padrão
Plano de projeto pode conter referências do
padrão - registro do processo definido do
projeto
ISM x N2
Gerência de Configuração de Software
Pode-se definir baselines mínimas acordando para a duração de projetos
ISM x N2
Gerência de Contrato de Software
Contratada define e entrega produtos de
acordo com os processos definidos (ex.
classes de projetos)
ISM x N2
Garantia de Qualidade de Software
Segue o processo de software definido para
para o projeto
acesso ao banco de dados p/ planejamento,
estimativa, acompanhamento
coleta e fornecimento de dados ao banco de
dados
gerência do projeto
...
ISM - Barreiras
Não existir um processo de software
padrão na organização
Planejamento, supervisão e
acompanhamento do projeto ainda com
problemas
Ativos serem difíceis de recuperar e usar
Definir diretrizes e guias de adaptação
claros e úteis
ISM - Barreiras
Identificação errônea de classes de
projetos/ manutenções e a adaptação
necessária
Resistência na documentação das
manutenções
Banco de dados pouco utilizado - uso para
planejar e estimar
ISM - Gastos
Levantamento de como adaptar
Elaboração de diretrizes e critérios de
adaptação - guias
Adaptação do banco de dados de
processos - limites
Adaptação ferramentas para reconher
tipos de projetos, templates, ...
ISM - Retorno
Processo definido de acordo com as
características dos projetos - diminui a
resistência ao uso de processos
Alertas anteriores ao acontecimento de
problemas no projeto
Possibilidade de medições mais efetivas
Coordenação entre Grupos
Intergroup Coordination IC
Coordenação entre Grupos - IC
IC x N2
Gerência de Requisitos
Base para os acordos entre grupos
envolvidos
IC x N2
Planejamento, Supervisão e
Acompanhamento de Projeto
Incluir no plano de projeto os compromissos,
responsáveis e dependências
Os compromissos e dependências são
acompanhados
IC x N2
Gerência de Configuração de Software
Disponibilizar a ferramenta de SCM para
todos os grupos envolvidos no projeto
Estabelecer as baselines em conjunto controle
IC x N2
Garantia de Qualidade de Software
incluir revisão/ auditoria de atividades e
produtos de IC
IC x N2
Gerência de Contrato de Software
exigências de níveis de maturidade da
contratada para trabalho em conjunto
IC - Barreiras
Estrutura organizacional rígida
Falta de respeito entre os grupos
 procedimento de escalonamento problemas
Diferenças de cultura/ linguagem
Diferenças de níveis de maturidade
Localização geográfica
Compatibilidade dos meios de
comunicação
IC - Gastos
Gerenciar compromissos e dependências
entre grupos
Revisões técnicas
Comunicação
Treinamentos - dinâmica em grupo,
orientações
IC - Retorno
Estabelecimento de responsabilidades “falar com a pessoa certa”
Visibilidade de dependências e
compromissos por todos os grupos
envolvidos
Tratamento de questões que impedem o
progresso - escalonamento
Conhecimento - aumenta com trabalho
em grupo
Revisões por Pares
Peer Review - PR
Revisões por Pares
PR x N2
Gerência de Requisitos
Requisitos podem ser submetidos a uma
reunião de revisão por pares
PR x N2
Planejamento, Supervisão e
Acompanhamento do Projeto de Software
Incluir no plano de projeto atividades de
revisão por pares
Plano de projeto pode ser submetido à
revisão por pares
Ações de melhoria para corrigir defeitos
devem ser acompanhadas até sua conclusão
PR x N2
Gerência de Configuração de Software
correções de defeitos resultam em mudanças
que precisam ser controladas
PR x N2
Garantia de Qualidade de Software
revê e/ou audita processo e atividades de
revisão por pares
cobra evidências da reunião
PR x N2
Gerência de Contrato de Software
Produtos entregues pela contratada podem
passar por uma revisão por pares
PR - Barreiras
Pressões de cronograma
Acreditar que as peer reviews são
demasiadamente caras
Revisões hostis
Medo de avaliações das pessoas
Seleção pouco apropriada de revisores
Pouca experiência técnica dos revisores
PR - Gastos
Treinamento
Planejamento
Fazer
Registrar dados - ferramenta
PR - Retorno
Descobrir defeitos cedo - menor custo
Dados disponíveis para guiar os testes
Dados para análise de processos
Aumenta qualidade - diminui o custo do
processo: retrabalho
Processo CBA IPI
CBA IPI - CMM Based
Appraisal Internal Process
Improvement
Processo CBA IPI
1. Identificar o
Escopo da
Avaliação
4. Brief do
Assessment
aos
Participantes
2. Desenvolver
um Plano para
a Avaliação
5. Administrar
os
Questionários
3. Preparar e
Treinar a
Equipe
6. Examinar as
Respostas dos
Questionários
7. Iniciar a
Revisão da
Documentação
8. Apresentar
Draft dos
Findings
Processo CBA IPI
2. Entrevistar
os Líderes de
Projeto (
individual 4)
1. Conduzir a
Reunião de
Abertura
8. Consolidar,
Medir e
Preparar
Findings Final
5. Consolidar
Informações
3. Entrevistar
Gerentes
Intermediários
(grupo)
5. Consolidar
Informações
4. Entrevistar
Representantes
de Áreas Func.
(grupo 6-12)
5. Consolidar
Informações
6. Preparar
Draft dos
Findings
7. Apresentar
Draft dos
Findings
Revisão de documentos, Entrevistas de Foloow-up
9. Apresentar
Findings Final
10. Conduzir
uma Sessão
Executiva
11. Elaborar
Relatório Final
para o SEI
Depois da conquista ...
Melhoria de processo é
melhoria contínua
Dados do SEI - Maio 97
Número de organizações iniciando SPI
continua a aumentar
Organizações da área comercial tem
aumentado
Aproximadamente metade das
organizações que tem reportado tem
menos que 100 funcionários
Transição de níveis: 2-3 tendem a ser
mais rápidos e com menos variância
Dados do SEI - Maio 97
Organizações Nível 1
 Garantia de Qualidade de Software e
Planejamento do Projeto de Software são as
áreas-chave freqüentemente menos
satisfeitas
Organizações Nível 2
Definição do Processo da Organização,
Gerência de Software Integrada e Programa
de Treinamento são as áreas-chave menos
satisfeitas.
Sucesso do projeto SPI
CMM tem que ser uma
conquista de todos