Como Iniciar uma Melhoria Viável e Necessária em uma Micro ou Pequena Empresa de Software

(1)

Como Iniciar uma Melhoria

Viável e Necessária

em uma Micro ou Pequena

Empresa de Software

Clênio F. Salviano

clenio.salviano@cenpra.gov.br clenio.salviano@terra.com.br Campinas - SP Lavras, MG – 12 de Novembro de 2005

PRO QUALITI 2005

Este contexto é caracterizado por micro e pequenas organizações intensivas em software, com processos de baixa capacidade, que queiram iniciar um ciclo de melhoria:

o mais rápido possível, investindo poucos recursos e com resultados de curto prazo

(melhoria viável e necessária).

Em geral PRO2PI-WORK pode ser realizado em 5 dias de trabalho, orienta melhorias que podem ser realizadas pelos

próprios membros da organização, com resultados em cerca de 4 a 6 meses.

A estratégia é identificar melhorias importantes para a organização, que possam ser realizadas por seus próprios e

(2)

Proposta:

Utilizar o método PRO2PI-WORK !

Em geral PRO2PI-WORK pode ser realizado em 5 dias de trabalho, orienta melhorias que podem

ser realizadas pelos próprios membros da organização, com resultados em até 4 meses.

A estratégia é identificar melhorias

importantes para a organização, que possam ser realizadas por seus próprios membros e

tenham resultados a curto prazo Esta melhoria é representada

por um Perfil de Capacidade de Processo

Exemplo: Empresa Ampla

• micro empresa (8 pessoas) fundada em 1995

• localizada em Campinas, SP

• desenvolveu 90 projetos, para clientes diferentes,

utilizando em média 1 a 2 pessoas, 2 a 3 meses

• projeto de melhoria 2002, cooperação

CenPRA-UFLATEC, focando 5 processos da 15504:

CUS.2: Fornecimento Processo da Fábrica de Software:

Prospecção -> Contrato -> Desenvolvimento -> Entrega -> Encerramento CUS.3: MAN.2: ENG.1.6:

Elicitação Gerência Teste

de Reqs. de Projeto de Sw.

(3)

© CFS, 2005 5 5: Otimizando Inovação de Proc. Otimização de Proc. 4: Previsível Medição de Proc. Controle de Proc. 3: Estabelecido Definição de Proc. Implementação Proc. 2: Gerenciado. Ger. da Execução Ger. de Produtos 1: Executado Execução de Proc. 0: Incompleto Níveis de Capacidade e Exemplos de Processos da 15504-5 Construção de Software critérios unidades código verificação Gerência de Projeto escopo estimativas planos progresso Elicitação de Requisitos comunicação requisitos necessidade mudança Teste de Software critérios integração teste regressão Suporte ao Cliente serviços satisfação solicitações necessidades no nível 3 no nível 3 no nível 2 no nível 4 no nível 2

Exemplo de um Perfil de Capacidade de Processo

Mineiro, de Pedra Azul (Vale do Jequitinhonha) Bacharel/Mestre Ciência da Computação

(UFMG, 82/87) e Doutorando (UNICAMP) Especialista em Melhoria de Processo,

Chefe da Divisão de Melhoria de Processo de Software do CenPRA

Professor Pós-Graduação UFLA e SENAC-SP 25 anos de experiência em

Desenvolvimento de Software, Pesquisa Tecnológica,

Treinamento e Consultoria. Áreas de Experiência:

Software Orientado a Objetos, Software Patterns,

Melhoria de Processo (15504,CMM,CMMI,MPS.BR,outros) Co-editor ISO/IEC 15504-5, Equipe Técnica MPS.BR

Clênio Figueiredo Salviano

Pedra Azul .

(4)

Agenda do Curso

(4 horas-aula)

1: Motivação

2: Visão Geral do Método

3: Contexto da Empresa

4: Fatores de Negócio

5: Relevância dos Processos

6: Escolha do Perfil

7: Conclusão

Histórico

PRO2PI-WORK:

• 1999: AMP1 e MEP1 • 1999-2003: uso e evolução • 2003: PRO2PI v0.1 e uso • 2004-05: v1.0 e uso

OUTROS:

• 2000: RAPID • 2003: Goal-problem • 2003-2004: MARES • 2004: Constagedeous • 2004: SEI Toolkit

(5)

Abordagem PRO2PI

An Approach oriented by

Process Capability Profile

for Process Improvement

Uma Abordagem orientada a

Perfis de Capacidade de Processo

para Melhoria de Processo

Note: The name PRO2PI uses the number 2 to mean the double PRO

(Process Profile) and also as “to” Process Improvement Nota: O nome PRO2PI é baseado no nome em inglês da abordagem

[Salviano, 2004]

Contexto, objetivos e estratégia de negócio da organização

Experiência e resultados de outras organizações

Melhoria da Organização Decisão e comprometimento para a melhoria institucionaliza a melhoria Prepara institucionalização da melhoria Inicia ciclo de melhoria Avalia práticas correntes Planeja ações de melhoria Realiza ações de melhoria Define e utiliza PRO2PI PRO2PI Boas práticas de modelos de capacidade de processo (SW-CMM, ISO/IEC 15504-5, iCMM, CMMI-SE/SW, OPM3, MR-MPS, ...); outros modelos (ISO 9001, PMBoK, EFQM, PNQ, RUP, ...); e/ou qualquer outra fonte

PRO2PI-CYCLE: Orientações para PRO2PI Conclusão do trabalho Preparação do trabalho Escolha de PRO2PI PRO2PI-WORK:

(6)

Organization's business goals and context

Experiences and results from other organizations improved organization Decision and commitment for improvement improvement institutionalization Prepare improvement institutionalization Start improvement cycle Asses current practices Plan improvement actions Perform improvement actions Define and use PRO2PI PRO2PI Best practices from PCMs (9001, SW-CMM, 12207, 15504-5, CMMI-SE/SW PMBoK, OPM3, ... and other sources PRO2PI-CYCLE: Actions for PRO2PI Work conclusion Work

preparation _DefinitionPRO2PI PRO2PI-WORK:

Objetivos de PRO2PI-WORK:

Capacitar pessoas da organização em fundamentos e técnicas da engenharia de processo em modelos relevantes de capacidade de processo

Consolidar informações relevantes sobre a unidade organizacional

Consolidar objetivos de negócio para a melhoria Consolidar representação dos processos atuais Definir um perfil de capacidade de processo para a

melhoria da unidade organizacional (PRO2PI)

Entender processos atuais em relação ao perfil definido Definir orientações para atingir o perfil

(7)

PRO2PI-WORK como processo (em ETVX)

Entradas: A01-AcordoTrab A02-PlanoTrab A03-AcordoConf Saídas: A04-RelatPRO2PI A05-RelatAvalTrab

Propósito: Estabelecer um perfil de capacidade de processo para um ciclo de

melhoria de processo (PRO2PI)

Atores: Especialista, Patrocinador, Contato, Multiplicadores, Dirigentes,

Gerentes, Técnicos e Outros

Tarefas/Fases: início, escolha, orientações, conclusão Verificação: propriedades de PRO2PI Critério para Início: AcordoTrab assinado Critério para Término: RelatPRO2PI aprovado © CFS, 2005 14 Fases e atividades do método PRO2PI-WORK para consultoria F.1: Preparação do trabalho (8-16 hs.)

A.1.1: Obter informações da Unidade Organizacional A.1.2: Analisar informações da Unidade Organizacional A.1.3: Preparar próximas atividades

F.2: Escolha de PRO2PI (16-20 hs.)

A.2.1: Apresentar abordagem e trabalho A.2.2: Identificar fatores de negócio A.2.3: Obter fatores organizacionais A.2.4: Identificar relevância dos processos A.2.5: Mapear subsídios nos processos A.2.6: Escolher perfil de processo A.2.7: Apresentar e revisar perfil

F.3: Orientações para PRO2PI (16-20 hs.)

A.3.1: Preparar próximas atividades A.3.2: Apresentar técnicas da abordagem A.3.3: Identificar práticas correntes

A.3.4: Consolidar identificação e revisar perfil A.3.5: Definir orientações para melhoria A.3.6: Consolidar orientações e revisar perfil A.3.7: Apresentar perfil e orientações

F.4: Conclusão do trabalho (8-12 hs.)

A.4.1: Consolidar relatório final A.4.2: Entregar relatório final A.4.3: Avaliar o trabalho realizado

NOTAS: Nota 1: Total de 20 atividades Nota 2: Em vermelho, cinco

atividades mais importantes

Nota 3: (<Ni>-<Ns> hs.) :

intervalo do número típico de horas para execução da fase em uma MPE Nota 4: F.1 e F.4: off-site (16-28hs), e F.2 e F.3: on-site (32-40 hs, 3-4 dias)

Nota 5: Total intervalo

(48-68 hs)

(8)

Fases

e

construção

do resultado

do

método

PRO2PI-WORK

F.1: Preparação do trabalho (8-16 hs.)

Análise da unidade organizacional, seleção de 16 a 24 áreas de processo

F.2: Escolha de PRO2PI (16-20 hs.)

objetivos de negócio para melhoria, processo atual, e

PRO2PI com 4 a 8 áreas de processo

F.3: Orientações para PRO2PI (16-20 hs.)

PRO2PI com 2 a 6 áreas de processo, situação atual dos processos e

orientações para melhoria com PRO2PI

F.4: Conclusão do trabalho (8-12 hs.)

relatório final com PRO2PI

Capa, controle, titulo, apresentação, resumo executivo (R1DescUO) Descrição geral da Unidade Organizacional

(R2IntroPOHE) Introdução a POHE, PRO2PI-WORK e processos usados (R3ResTrab) Resumo do trabalho realizado, incluindo subsídios levantados (R4ProcAtual) Descrição em alto nível do processo atual

(R5DescNeg) Descrição da estratégia e objetivos de negócio da UO (R6PCPAtual) Descrição da situação atual (PCP atual, avaliado) (R7DescPRO2PI)Descrição de PRO2PI

(R8OrientMelh) Orientações para a melhoria buscando PRO2PI (R9GerMelh) Considerações gerais para gerência desta melhoria

(9)

Atividade 1

• Descrever um contexto, por exemplo uma

organização, para o qual o trabalho será

desenvolvido.

• Por exemplo:

A Empresa E1, fundada em 1988 com sede na cidade de XX , é uma empresa nacional que atualmente desenvolve, evolui e comercializa quatro produtos: P1, para administração de recursos humanos; P2, para gestão empresarial; P3, para administração de agências de viagens; e P4, para controle de acesso. E1 conta com cerca de 200 funcionários, sendo que aproximadamente 50% deles estão na área de desenvolvimento de software.

Técnica SWOT (1)

• SWOT (Strenghts, Weakness, Opportunities, Threats) é um resultado de uma pesquisa conduzida pelo

Stanford Research Institute entre 1960 e 1970 [Humphrey 2004].

• Esta pesquisa buscava entender porque planejamentos corporativos geralmente falhavam.

• A análise SWOT orienta a identificação de fatores que devem influenciar o desempenho e resultados de uma organização.

• SWOT identifica fatores os pontos fortes (“strenghts”) e fraquezas (“weakness”) internos de uma organização e as oportunidades (“opportunities”) e ameaças

(10)

Técnica SWOT (2)

Pontos fortes são condições do ambiente interno de uma

organização, que apresentam situação atual favorável, em relação ao seu desempenho geral.

Fraquezas são condições do ambiente interno de uma organização,

que apresentam situação atual desfavorável, em relação ao seu desempenho geral.

Ambas as condições de pontos fortes e fraquezas podem se relacionar a capacidades, estrutura de apoio à pesquisa, recursos financeiros, desempenho organizacional e alianças estratégicas.

Oportunidades são variáveis do ambiente externo, de alta

importância futura e positiva sobre as atividades e o desempenho da organização, enquanto que ameaças são variáveis do ambiente externo, de alta importância futura e negativa sobre as atividades e o desempenho da organização [Castro et al. 2005, p. 127-129]. A partir destas quatro variáveis, pode ser derivada estratégias pró-ativas, para aproveitar oportunidades, ou repró-ativas, para minimizar ameaças, sempre considerando os pontos fortes e fraquezas da organização.

Atividade 2

• Identificar pontos fortes, fraquezas,

oportunidades e ameaças segundo o SWOT

• Por exemplo:

Pontos fortes: Competência técnica; Base de clientes; Fraquezas: Competência gerencial; Pouca reserva financeira;

Oportunidades: Desenvolver novo produto para domínio X; ampliar mercado de regional para nacional e

internacional

Ameaças: Novo concorrente no mercado; Perda de cliente por qualidade inadequada

(11)

( . . . )

3.4 Relate de um a três principais pontos fortes da unidade organizacional.

(Nota: Pontos fortes são condições do ambiente interno de uma organização, que apresentam situação atual favorável, em relação ao seu desempenho geral) a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars.

3.5 Relate de um a três principais fraquezas da organização.

(Nota: fraquezas são condições do ambiente interno de uma organização, que apresentam situação atual desfavorável, em relação ao seu desempenho geral) a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars.

3.6 Relate de uma a três das principais experiências na organização que foram bem sucedidas

(por exemplo, o que já foi feito na organização, deu certo e você faria de novo). a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars.

3.7 Relate de uma a três das principais experiências na organização que não foram bem sucedidas

(por exemplo, o que já foi feito na organização, não deu certo e você não faria de novo ou faria de outra maneira).

a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars.

( . . . )

Trecho do questionário sobre fatores de negócio

da unidade organizacional: (1 de 2)

( . . . )

3.8 Relate de uma a três das principais ameaças à organização

(Nota: ameaças são variáveis do ambiente externo, de alta importância futura e

negativa sobre as atividades e o desempenho da organização)

3.9 Relate de uma a três das principais oportunidades de negócio para a organização. (Nota: oportunidades são variáveis do ambiente externo, de alta

importância futura e positiva sobre as atividades e o desempenho da organização) a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars.

3.10 Relate de uma a três das ações para a melhoria da organização que você gostaria que fossem realizadas. (podem ser ações novas, modificações de ações já

existentes ou mesmo eliminação de alguma ação).

3.11 Relate de uma a cinco das principais características de diferenciam esta organização das outras. (por exemplo, aquilo que somente ela faz, aquilo que ela

faz melhor do que as outras, aquilo que é o diferencial da organização,...) a) [ ] max 320 cars.; b) [ ] max 320 cars.; c) [ ] max 320 cars. d) [ ] max 320 cars.; e) [ ] max 320 cars..

( . . . )

Trecho do questionário sobre fatores de negócio

(12)

Melhoria de Processo

baseada em problemas e metas

Livro:

“

Making Process Improvement

Work:

A concise action guide for

software managers and practitioners”

Neil S. Potter and Mary E. Sakry

2002, Addison-Wesley Professional

(ISBN 0201775778)

Exemplos de metas objetivas

(Potter, Sakry 2002)

• (a) aumentar a qualidade do produto para

no máximo 10 defeitos por liberação,

(b) ganhar de volta os clientes X, Y, e Z, e

(c) aumentar a participação no mercado em 10% .

• (a) Reduzir o retrabalho de 30 para até 10%

do esforço do projeto, e (b) utilizar este tempo

para criar um novo produto PY.

• (a) Melhorar a estimativa de esforço para

+/- 10 % de acurácia, (b) eliminando

cancelamento forçado de férias.

(13)

Exemplos de metas não objetivas

1) Neste caso, pergunte por que é desejado atingir esta meta, buscando os benefícios desejados. 2) Então os benefícios mais importantes,

devem se tornar as novas metas!

3) As metas originais podem ser removidas ou passarem a ser metas intermediárias.

* Documentar todos os processos

* Desenvolver uma representação

detalhada do ciclo de vida do software

* Estabelecer um programa de medições

Ações:

Exemplo Metas

Processo => Negócio

• Meta original: 15504 ENG e Ger.Proj. nível 2

• Por que ENG e Ger.Proj. nível 2 ? Respostas:

Encontrar defeitos cedo na codificação para reduzir

custos de teste (e retrabalho);

Reduzir os U$ 2 milhões gastos em retrabalho por ano

Ganhar mais contratos reduzindo o custo de retrabalho Melhorar previsibilidade de prazo e custo

Reduzir atrasos devido a riscos

não gerenciados de sistemas complexos

Melhorar engenharia de sistemas e simplificar integração de produto

(14)

Exemplo Metas

Processo => Negócio

• Meta original: 15504 ENG e Ger.Proj. Nível 2

• Nova meta principal:

Reduzir os U$ 2 milhões gastos

atualmente em retrabalho por ano

• Outras metas e nível 2

viram metas e práticas

intermediárias

para a meta principal

Atividade 3

• Consolide uma ou mais metas objetivas

para a melhoria

• Exemplo:

• Reduzir em seis meses o re-trabalho de 30

para 10% por meio de uma melhor gerência

das solicitações de mudanças e evolução do

produto.

(15)

Atividade 4

[PRO2PI-WORK A.2.4]

Identificar relevância dos processos

Tarefas: Para cada processo (estimativa: 20 minutos por processo):

– Apresentar o processo por: a) definição do processo,

conforme o modelo; b) sintomas quando não é bem executado, e c) razões porque é importante.

– Discutir e identificar a correspondência dele na organização (Nota: neste momento é possível a subdivisão do processo, nestes casos os passos seguintes são executados para cada subdivisão).

– Identificar como ele é executado hoje (ou seja, em qual nível de capacidade e justificativas)

– Definir a importância: Qual a importância deste processo para os objetivos de negócio da organização. (resposta: baixo, medio ou alto, e porque)

– Definir o risco: Qual o risco deste processo, em relação aos seus objetivos, se ele continuar a ser executado como é hoje.(resposta baixo, médio ou alto, e porque)

( . . . )

1. Identificações

1.1 Identificação da Unidade Organizacional: [ ] max 72 cars.

1.2 Identificação da Área de Processo: [ ] max 32 cars.

1.3 Identificação do Modelo de Capacidade de Processo: [ ] max 32 cars.

2. Área de Processo e a Unidade Organizacional

2.1 Comentários gerais sobre qualquer assunto relacionado: (tamanho

sugerido: 10 linhas) [ ] max 800 caracteres

2.2 Correspondência desta área de processo na Unidade Organizacional:

(tamanho sugerido: 10 linhas) [ ] max 800 caracteres

2.3 Comentários sobre como esta área de processo é realizada na Unidade

Organizacional: (tamanho sugerido: 10 linhas) [ ] max 800 caracteres

2.4 Estimativa do Nível de Capacidade do processo atual na Unidade Organizacional: [ ]

2.5 Importância da área de processo para o desempenho global

da Unidade Organizacional: [ ] Justifique: (tamanho sugerido: 10 linhas)

[ ] max 800 caracteres

2.6 Risco de manter o desempenho atual da área de processo para o desempenho global da Unidade Organizacional: [ ] Justifique: (tamanho

sugerido: 10 linhas) [ ] max 800 caracteres

( . . . )

Trecho do questionário sobre relevância de

(16)

Como é executado (atualmente) Importância para a U.O. Risco para a U.O. Processo

Identificado e (Modelo)

Nível

Cap. Descrição Nível Descrição Nível Descrição Não existe processo

formal e/ou padronizado; cada analista de sistemas é responsável por vários

projetos, de diversas áreas. Visando melhorar a produtividade do departamento, deve-se melhorar o cumprimento de prazos e alocação de recursos.

O atraso contínuo nas entregas pode comprometer a imagem do Departamento a longo prazo. GerR - Gerência de Projetos (15504-5) 1 Média Médio Alta O correto entendimento dos requisitos proporciona uma melhor

elaboração dos projetos, bem como a definição de prazos de

entrega

Sem a devida documentação os requisito podem ser mal compreendidos e constantemente sofrem alterações dentro do projeto. Alto

Não há refinamento dos requisitos para o desenvolvimento do produto Não existe documentação adequada e nem um padrão de teste a ser

seguido. REQM - Gerência de Requisitos (CMMI-SE/SW) 1 RD - Desenvolvim ento de Requisitos (CMMI-SE/SW) 1 STE - Solução Técnica (MR-MPS) 2 Existe uma comunicação informal com o usuário, porém

não existe documentação deste entendimento Uma boa documentação e padrões de testes são indispensável para

evitar a perda de conhecimentos e garantir a qualidade. Médio Apesar dos constantes atrasos na entrega, conseguimos manter um bom nível de qualidade

nos produtos entregues. Alta Com o correto refinamento evita-se o retrabalho no desenvolvimento Existe constantes mudanças durante o desenvolvimento do produto acarretando atrasos Alto LP - Liberação do Produto (15504-5)

Muitas vezes o produto é liberado e não é feita a confirmação formal da

operação Média

Alta

Garantir que o produto entregue satisfaça as necessidades do usuário Baixo Muistas vezes é necessário o retrabalho. 2 Risco: Potencial impacto negativo do processo atual RD REQM STE GerP LP alto médio baixo Importância do processo para a unidade organizacional

baixo médio alto

Exemplo de cinco áreas de processo para uma determinada unidade organizacional Quadro de Relevância:

adaptado de [de Petri et al. 2005]

Processos Fundamentais

Grupo de Processos de Aquisição (ACQ)

ACQ.1 Preparação da Aquisição ACQ.2 Seleção de Fornecedor ACQ.3 Acordo Contratual ACQ.4 Monitoramento de Fornecedor ACQ.5 Aceitação pelo Cliente

Grupo de Processos de Fornecimento (SPL)

SPL.1 Prospecção de Fornecimento SPL.2 Liberação de Produto SPL.3 Apoio para Aceitação do Produto

Grupo de Processos de Engenharia (ENG)

ENG.1 Elicitação de Requisitos ENG.2 Análise de Requisitos de Sistema ENG.3 Projeto da Arquitetura de Sistema ENG.4 Análise de Requisitos de Software ENG.5 Projeto de Software ENG.6 Construção de Software ENG.7 Integração de Software ENG.8 Teste de Software ENG.9 Integração de Sistema ENG.10 Teste de Sistema ENG.11 Instalação de Software ENG.12 Manutenção de Software e Sistema

Grupo de Processos de Operação (OPE)

OPE.1 Operação OPE.2 Suporte ao Cliente

Grupo de Processos de Apoio (Support) (SUP)

SUP.1 Garantia da Qualidade

SUP.2 Verificação SUP.5 Auditoria SUP.8 Gerência de Configuração SUP.3 Validação SUP.6 Avaliação de Produto SUP.9 Gerência de Resolução de Problemas

Níveis de Capacidade 5: Em Otimização 5.1 Inovação 5.2 Melhoria Contínua 4: Previsível 4.1 Medição 4.2 Controle 3: Definido 3.1 Definição 3.2 Implantação 2: Gerenciado 2.1 Gerência de Execução 2.2 Gerência de Produtos 1: Executado 1.1 Execução 0: Incompleto Processos

ISO/IEC 15504-52005: (6) Níveis de Capacidade (15504-2) e (48) Processos (12207 Amd2)

Grupo de Processos de Melhoria de Processo (PIM)

PIM.1 Estabelecimento de Processo PIM.2 Avaliação de Processo PIM.3 Melhoria de Processo

Grupo de Processos de Recursos e Infra-estrutura (RIN)

RIN.1 Gerência de Recursos Humanos RIN.2 Treinamento

RIN.3 Gerência de Conhecimento RIN.4 Infra-estrutura

Grupo de Processos de Reuso (REU)

REU.1 Gerência de Ativos REU.2 Gerência de Programa de Reuso REU.3 Engenharia de Domínio

Grupo de Processos de Gerência (MAN)

MAN.1 Alinhamento Organizacional MAN.2 Gerência Organizacional MAN.3 Gerência de Projeto MAN.4 Gerência da Qualidade MAN.5 Gerência de Riscos MAN.6 Medição

Processos Organizacionais

(17)

Área CMMI-SE/SW 15504-5 MPS.BR Engenharia de Requisitos RD/REQM ER/ARS RE/GRE Construção de Software TS/PI PS/CS/IntS STE/ITP Manutenção de Software x MSS/GSM x Verificação e Validação VER/VAL TstS/Ve/Va VER/VAL Gerência de Projeto PP/PMC GerP GPR Garantia da Qualidade PPQA GarQ GQA Medição MA Med MED Gerência de Configuração CM GC GCO Aquisição SAM PAq/SF/ACo/MF/ACl AQU Fornecimento x PF/LP/AAP LIP Suporte ao Cliente x SupC x Engenharia de Domínio x EngD x Engenharia de Processo OPF/OPD EP/AP/MP DFP/AMP

Área de Processo CRMP

Processo de

Gerência de Solicitações de Mudanças

Change Request Management Process(CRMP)

Processo SUP.10 da ISO/IEC15504-5

Propósito:

“Garantir que as solicitações de mudanças são gerenciadas, acompanhadas e controladas

“ensure that change requests are managed, tracked and controlled”

(18)

Como resultado de uma implementação com sucesso do processo de gerência de solicitação de mudança: uma estratégia para gerência de mudança é desenvolvida; solicitações de mudanças são armazenadas e identificadas; dependências e relacionamentos

para outras solicitações de mudanças são identificadas; critérios para confirmação da implementação

das mudanças solicitadas são definidos;

solicitações de mudanças são priorizadas e os recursos requeridos são estimados;

mudanças são aprovadas com base na

prioridade das mudanças e disponibilidade de recursos; mudanças aprovadas são

implementadas e acompanhadas até a conclusão; e

o estado de todas as solicitações de mudanças é conhecido.

CFG.4.BP1: Develop a change management strategy. A change

management strategy is established and implemented to ensure changes can be described, recorded, analyzed, and actioned. [Outcome: 1]

CFG.4.BP2: Record the request for change. Each change request

is uniquely identified, and recorded. [Outcome: 2]

CFG.4.BP3: Record the status of change requests. Change

requests and changes are allocated a status indication to facilitate tracking. [Outcome: 8]

NOTE 1: Provide traceability to the reason for the change. Change requests submitted as a resolution to a problem or error report should retain a link to the originating problem or error report. [Outcome: 3]

CFG.4.BP4: Establish the dependencies and relationships to other change requests. Identify the relationship of a change

request to other change requests to establish dependencies (e.g. towards another change to the same software element or for a set of

(19)

CFG.4.BP5: Assess the impact of the change. Assess the impact,

resources, risks, and potential benefits of the change request and establish criteria for confirming implementation. [Outcome: 4,5] NOTE 2: A Change Request Board (CRB) is a common mechanism used to assess change requests. When conducting impact and resource assessment, the effect on the infrastructure and users must be considered together with the resources required for

implementing the change, including likely costs, the number and availability of people and the elapsed time to implement.

CFG.4.BP6: Identify the verification and validation activities to be performed for implemented changes. Before implementing a

change the scope of verification and validation activities to be undertaken are identified. [Outcome: 7]

CFG.4.BP7: Approve changes. All changes are approved before

implementation. [Outcome: 6]

CFG.4.BP8: Schedule the change. Approved changes are

scheduled for implementation. [Outcome: 7, 5]

NOTE 3: Scheduled changes may be incorporated into target releases. A packaged release may incorporate corrective and adaptive changes. Part of change scheduling will involve ensuring estimated resources and costs are within overall budget.

CFG.4.BP9: Review the implemented change. All changes are

reviewed after implementation and before closure to ensure that they had the desired effect and met their objectives. [Outcome: 7,8]

(20)

Área de Processo DE

[ISO/IEC 15504

(*)

_]

Engenharia de Domínio (Domain Enginnering DE)

Propósito:

“Desenvolver e manter modelos e arquiteturas do domínio e ativos para o domínio”

Objetivos:

OE 1: Desenvolver e manter elementos do domínio

(*): descrito como uma área de processo no formato do CMMI

AP Engenharia de Domínio

(Domain Enginnering DE)

OE 1 Desenvolver e manter elementos do domínio. Desenvolver e manter modelos e arquiteturas do domínio e ativos para o domínio.

PE 1.1 Selecionar representação do domínio. Selecionar as formas de representação para os modelos do domínio e arquitetura do domínio.

PE 1.2 Estabelecer fronteiras do domínio. Estabelecer fronteiras do domínio e seus relacionamentos com outros domínios

PE 1.3 Desenvolver modelo do domínio. Desenvolver um modelo do domínio que capture os pontos essenciais e diferentes características, capacidades, conceitos e funções do domínio.

PE 1.4 Desenvolver arquitetura do domínio. Desenvolver uma arquitetura do domínio descrevendo a família de sistemas abrangida pelo domínio.

PE 1.5 Definir ativos do domínio.Definir os ativos pertencentes ao domínio.

PE 1.6 Adquirir ou desenvolver, e manter ativos.Adquirir ou desenvolver, e manter durante seu ciclo de vida, os ativos pertencentes ao domínio.

(21)

representação do domínio

Desenvolver e manter elementos do domínio

Desenvolver modelo do domínio Ativos Estabelecer delimitações do domínio

Objetivo DE.1:

Desenvolver e manter

elementos domínio

Modelo do

Domínio _{do Domínio}Arquitetura

Desenvolver arquitetura do domínio Definir ativos do domínio Adquirir ou desenvolver, e manter ativos Manter modelo e arquitetura do domínio © CFS, 2005 42

Quando DE não é bem feita …

• Sintomas:

– Pouco reuso entre projetos

– Projetos novos são sempre surpresas e em novas áreas

– Tempo muito longo para desenvolver ou customizar soluções e o design do produto

• Por que se preocupar com isto? Porque…

– Tendência de especialização das organizações de software, e sem uma engenharia de domínio

(22)

Área de Processo RD

Desenvolvimento de Requisitos

Requirements Development

RD

Propósito:

“Produzir e analisar requisitos do cliente,

produto e componentes do produto”

Objetivos:

OE 1: Desenvolver requisitos do cliente

OE 2: Desenvolver requisitos do produto

OE 3: Analisar e validar os requisitos

Desenvolver os requisitos

dos clientes

Requisitos do Cliente

Desenvolver requisitos do cliente

Coletar necessidades dos Stakeholders Elicitar necessidades Necessidades dos Stakeholders

Objetivo RD.1:

(23)

Desenvolver requisitos do produto

Alocar requisitos aos componentes do produto Identificar requisitos de interface Requisitos do Cliente

Objetivo RD.2:

Desenvolver requisitos do produto

© CFS, 2005 46 Estabelecer conceitos operacionais e cenários Estabelecer a definição da funcionalidade requerida Analisar requisitos para atingir balanço Analisar requisitos Requisitos de Produto, Componente de Produto e Interface Validar os Requisitos

Analisar e validar os requisitos

Validar requisitos Validar requisitos com metodos

Objetivo RD.3:

(24)

Quando RD não é bem feita …

• Sintomas:

– Falta de requisitos, requisitos documentados pobremente que resultam em confusão entre a equipe e o cliente

– Produtos de trabalho do projeto, que interpretam de forma inconsistente os requisitos

– Tempo desordenadamente longo para obter o acordo sobre o design do produto

• Por que se preocupar com isto? Porque…

– Produtos não usáveis e clientes insatisfeitos levam para perda de negocios futuros

– Tempo e recursos desperdiçados para construir um produto de acordo com requisitos que o cliente não deseja, pode comprometer o seu lucro

– Equipe se desgasta em refazer trabalho em que os requisitos foram re-interpretados “mais uma vez”

– O potencial para gastos excessivos com a finalidade de atingir expectativas do cliente aumenta, quando os requisitos não foram bem identificados

Atividade 5

Posicionar o resultado

da relevância de cada área de processo em um quadro de

importância e risco e

(25)

Risco se mantida a execução atual da área de processo

Im p o rt ân ci a d a ár ea d e p ro ce ss o b ai x a m éd ia a lt a Formulário PRO2PI-WORK-A21-v1p1e-QuadroRelevProcUO

Quadro resumido da relevância das áreas de processo analisadas para a unidade organizacional, em termos de importância e risco

Unidade organizacional: Data:

Modelos utilizados:

baixo médio alto Risco se mantida a execução atual da área de processo

Im p o rt ân ci a d a ár ea d e p ro ce ss o b ai x a m éd ia a lt a Formulário PRO2PI-WORK-A21-v1p2e-QuadroRelevAreaProcUO

RD VAL REQM PP TS OPD PMC PI OPF OT VER PPQA CM MA SAM IPM DAR RSKM

Dep. de Projetos de Software da HAL 21/10/2005 Modelos utilizados: CMMI-SE/SW v1.1

(26)

Risco se mantida a execução atual da área de processo

Im p o rt ân ci a d a ár ea d e p ro ce ss o b ai x a m éd ia a lt a Formulário PRO2PI-WORK-A21-v1p2e-QuadroRelevAreaProcUO

MAN.3 SUP.1 OPE.2 ENG.5 PIN.1 SUP.10 ENG.12 ENG.8 ENG.4 ENG.7 MAN.1 MAN.2 RIN.5 ENG.5 PIN.3 MAN.5 SUP.8 REU.2 ENG.1 SUP.9 ACQ.4 ACQ.1 RIN.4 OPE.1

Dep. de Produtos HAL 21/10/2005

Modelos utilizados: ISO/IEC FDIS 15504-5

Atividade 6

Com base nos subsídios: contexto da organização

pontos fortes, fraquezas, oportunidades e ameaças metas da melhoria

relevância das áreas de processo, e outros

estabelecer um PRO2PI com

o Perfil para a melhoria, Práticas atuais em relação ao Perfil e orientações para a melhoria

(27)

aos objetivos de negócio da organização Relevante explora oportunidades existentes Oportuno forma um sistema Sistêmico às características da organização Específico

aos modelos relevantes

Rastreável

do processo

Abstração

pode ser alterado

Dinâmico

aplica-se ao todo do PRO2PI aplica-se a uma parte do PRO2PI

Comparação com outros métodos

PRO2PI-WORK:

• 1999: AMP1 e MEP1 • 1999-2003: uso e evolução • 2003: PRO2PI v0.1 e uso • 2004-05: v1.0 e uso

OUTROS:

• 2000: RAPID • 2003: Goal-problem • 2003-2004: MARES • 2004: Constagedeous • 2004: SEI Toolkit

(28)

Contatos

Centro de Pesquisas Renato Archer

Centro de Pesquisas Renato Archer -- CenPRA / MCTCenPRA / MCT (antigo CTI e ITI: Inst. Nac. de Tecnologia da Informação) (antigo CTI e ITI: Inst. Nac. de Tecnologia da Informação)

Divisão de Melhoria de Processos de Software - DMPS

Clenio F. Salviano Clenio F. Salviano e

e--mail: Clenio.Salviano@cenpra.gov.brmail: Clenio.Salviano@cenpra.gov.br Clenio.Salviano@terra.com.br Clenio.Salviano@terra.com.br telefone: (19) 3746

telefone: (19) 3746--6109 6109

Rodovia Dom Pedro I, km 143,6 Rodovia Dom Pedro I, km 143,6 Campinas SP

Campinas SP –– CEP 13082CEP 13082--120120