UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA

GRADUAO EM CINCIA DA COMPUTAO

2006.2

ABORDAGEM COMPARATIVA ENTRE

MODELOS DE MELHORIA PARA
PROCESSO DE SOFTWARE

Autor

Leonardo Monteiro Reinaldo (lmr@cin.ufpe.br)

Orientador

Prof. Ph.D. Alexandre Marcos Lins de Vasconcelos

Co-Orientador

Prof. M. Sc. Sandro Ronaldo Bezerra Oliveira

Recife, Maro 2007.

Universidade Federal de Pernambuco

Centro de Informtica

LEONARDO MONTEIRO REINALDO

ABORDAGEM COMPARATIVA ENTRE MODELOS DE MELHORIA PARA

PROCESSO DE SOFTWARE

Monografia

apresentada

ao

Centro de Informtica da Universidade

Federal

de

Pernambuco,

Grau

Bacharel

como

requisito parcial para obteno do

de

em

Cincia

da

Computao sob orientao do Prof.

Ph.D. Alexandre Vasconcelos e co-

orientao do aluno de doutorado M.

Sc. Sandro Ronaldo Bezerra Oliveira.

Recife, Maro 2007.

2

ASSINATURAS

Este Trabalho de Graduao resultado dos esforos do aluno

Leonardo Monteiro Reinaldo, sob a orientao do professor Alexandre
Marcos Lins de Vasconcelos, na participao do projeto Abordagem
Comparativa entre Modelos de Melhoria para Processo de Software,
conduzido

pelo

Centro

de

Informtica

da

Universidade

Federal

de

Pernambuco. Todos abaixo esto de acordo com o contedo deste

documento e os resultados deste Trabalho de Graduao.

Leonardo Monteiro Reinaldo

Alexandre Marcos Lins de Vasconcelos

 minha famlia.

Agradecimentos
Em primeiro lugar, aos meus pais, Francisco Reinaldo e Sineyde Monteiro,
pelo apoio e incentivo que sempre me deram, pois graas a sua dedicao
e esforo que hoje eu posso estar concluindo o curso de graduao em
cincia da computao.

A minha namorada, Rita de Cssia, pelo amor e carinho que tem me

dedicado, e pela pacincia e apoio que teve comigo durante o perodo de
desenvolvimento desse trabalho.

Ao meu orientador, Professor Alexandre Vasconcelos, pela oportunidade e

orientao concedidas nesta monografia;

Ao aluno de doutorado e Professor, Sandro Oliveira, pela sua amizade, apoio

e co-orientao no decorrer deste trabalho, fornecendo material para
pesquisa e estando sempre apto a ajudar.

Aos meus irmos Alexandre Monteiro, Maxwell Monteiro e Cibele Monteiro e

aos meus amigos, pela torcida e auxlio durante a elaborao deste trabalho.

Ao Centro de Informtica, pelo acolhimento e excelente formao acadmica

a mim concedidos.

Um passo a frente e voc no est mais no mesmo lugar.

(Chico Science)

Abordagem Comparativa entre Modelos de

Melhoria para Processo de Software

Resumo
O objetivo desse trabalho realizar uma anlise comparativa entre duas
abordagens do programa de melhoria de processo de software, focando,
principalmente, nos procedimentos propostos por cada uma delas. Uma das
abordagens de estudo trata da metodologia do ProImprove [Oliveira 06b], um
fluxo de trabalho adaptado para atender melhoria de processo de software
que possui como base o modelo IDEAL e outros elementos de medio que
transcendem os propsitos desse modelo. A outra abordagem o PRO2PI,
definida em [Salviano 06], que prope uma melhoria de processo de software
dirigida por perfis de capacidade de processo. O foco analisar as duas
iniciativas a fim de identificar semelhanas, diferenas e melhorias entre as
duas diferentes abordagens.

Palavras-Chave: Anlise Comparativa, Processo de Software, Abordagem para

Melhoria de Processos de Software, Qualidade de Software.

ndice
1

INTRODUO ..................................................................................................... 12
1.1

Contexto....................................................................................... 12

1.2

Motivao ..................................................................................... 13

1.3

Objetivos ...................................................................................... 13

1.4

Metodologia .................................................................................. 14

1.5

Estrutura ....................................................................................... 14

PROCESSO DE SOFTWARE: UMA VISO GERAL ............................................................ 16

2.1 Tecnologia de Processo de Software .................................................. 16
2.2 Ambientes de Desenvolvimento de Software Centrados em Processo . 17
2.3 Implementao de Processo de Software............................................ 19
2.4 Definio de Processo de Software..................................................... 20
2.5 Consideraes Finais ......................................................................... 21

ABORDAGENS DE MELHORIA CONTNUA DE PROCESSOS DE SOFTWARE ............................. 22

3.1 Melhoria Contnua de Processos ........................................................ 22
3.2 Abordagem Para a Medio e Melhoria de Processo de Software ........ 25
3.2.1 Definio de Mtricas ................................................................ 27
3.2.2 Coleta de Mtricas..................................................................... 30
3.2.3 Anlise das Mtricas Coletadas.................................................. 31
3.3 Modelo IDEAL Para a Melhoria Contnua de Processos........................ 31
3.5

3.4.1

ProImprove .............................................................................. 35

3.4.2

PRO2PI..................................................................................... 42

3.5
4

Iniciativas Metodolgicas para Melhoria de Processos de Software. 35

Consideraes Finais..................................................................... 44

ANLISE COMPARATIVA ENTRE AS ABORDAGENS ........................................................ 45

4.1 Comparativo...................................................................................... 45
4.2 Resultados......................................................................................... 48
8

4.3 Consideraes Finais ......................................................................... 49

5

CONCLUSO ...................................................................................................... 50
5.1

Sumrio do Trabalho ..................................................................... 50

5.2

Trabalhos Futuros ......................................................................... 51

REFERNCIAS ............................................................................................................ 52
GLOSSRIO .............................................................................................................. 57
APNDICE A ............................................................................................................. 59
APNDICE B.............................................................................................................. 68
APNDICE C ............................................................................................................. 70

LISTA DE TABELAS
Tabela B-1: Prticas base para o estabelecimento de Perfil de Capacidade de Processo...................... 69
Tabela C-1: Tabela comparativa entre as atividades do PRO2PI e do ProImprove ............................... 71

10

LISTA DE FIGURAS
Figura 2-1: Passos para implementar processo em uma empresa [Oliveira 05]................................... 20
Figura 3-1: Modelo IDEAL [Mcfeeley 96]............................................................................................ 34
Figura 3-2: Fluxo de Atividades do ProImprove [Oliveira 06a]............................................................ 38
Figura 4-1: Ciclo de vida do modelo IDEAL [Salviano 06] ................................................................... 45
Figura 4-2: Ciclo de vida da abordagem PRO2PI [Salviano 06] ........................................................... 46
Figura 4-3: Modelo de ciclo de vida para o ProImprove ..................................................................... 48
Figura A-1: Diagrama da definio de PRO2PI [Salviano 06]............................................................... 59
Figura A-2: Diagrama da utilizao (e definio) de PRO2PI [Salviano 06] .......................................... 60
Figura A-3: Diagrama da avaliao de processo (e definio e utilizao de PRO2PI) [Salviano 06]...... 62
Figura A-4: Diagrama da definio de modelos mais especficos [Salviano 06]................................... 62
Figura A-5: Diagrama da abordagem PRO2PI para modelos e melhoria de processo [Salviano 06] ...... 65
Figura A-6: Diagrama, anlogo ao de PRO2PI, do desenvolvimento de software [Salviano 06] ............ 65

11

1 INTRODUO
Neste captulo sero abordados o contexto de atuao do trabalho, a
motivao para o seu desenvolvimento, os objetivos que caracterizam o
trabalho realizado, a metodologia usada como linha de execuo do mesmo
e tambm sua estrutura.

1.1 CONTEXTO
Atualmente, as organizaes necessitam de uma melhoria contnua do
seu processo, e essa melhoria tem se mostrado na prtica ser uma
abordagem vivel, eficaz e eficiente para a necessria melhoria das
organizaes

intensivas

em

software

[Salviano

06],

visto

que

aperfeioamento de suas atividades para dispor de servios e produtos com

qualidade torna-se cada vez mais indispensvel e propcio para os seus
clientes.
Portanto, o objetivo desse trabalho realizar uma anlise comparativa
entre duas abordagens do programa de melhoria de processo de software,
focando, principalmente, nos procedimentos propostos por cada uma delas.
Uma das abordagens de estudo trata da metodologia do ProImprove [Oliveira
06b], um fluxo de trabalho adaptado para atender melhoria de processo de
software que possui como base o modelo IDEAL e outros elementos de
medio que transcendem os propsitos desse modelo. A outra abordagem
o PRO2PI, definida em [Salviano 06], que prope uma melhoria de processo
de software dirigida por perfis de capacidade de processo. O foco analisar

12

as duas iniciativas a fim de identificar semelhanas, diferenas e melhorias

entre as duas diferentes abordagens.
O

ProImprove

parte

integrante

do

ImPProS

(Ambiente

de

Implementao Progressiva de Processos de Software) [Oliveira 05], um

ambiente proposto em um plano de trabalho do programa de doutorado
submetido e aprovado pelo Centro de Informtica da Universidade Federal de
Pernambuco.

1.2 MOTIVAO
Ver como as abordagens realizam os conceitos tericos de melhoria
contnua para promover o aperfeioamento das prticas organizacionais a
partir de procedimentos direcionados anlise do contexto organizacional.
Para que isso seja possvel, faz-se necessrio uma anlise de como o

ProImprove funciona, desde a fase inicial do seu ciclo de melhoria at a

coleta de lies aprendidas acerca da melhoria realizada. O mesmo esforo
faz-se necessrio para analisar as fases de melhoria que realiza a abordagem
PRO2PI. Isso necessrio uma vez que as organizaes, com foco em
desenvolvimento de software, requerem estruturas que orientem o seu
trabalho de aperfeioamento.

1.3 OBJETIVOS
O objetivo deste trabalho analisar cada uma das fases que promovem
o aperfeioamento das prticas organizacionais sugeridas nas abordagens
antes citadas, bem como suas atividades e princpios, fazer um paralelo

13

entre elas e, a partir disso, saber o que cada abordagem tem a oferecer no
contexto de melhoria contnua de processo de software.
Para alcanar o objetivo principal, o trabalho foi subdividido nos
seguintes objetivos:

Estudo sobre processo software em uma viso geral;

Estudo do modelo de ciclo de vida do ProImprove;

Estudo do modelo de ciclo de vida do PRO2PI;

Comparao entre os modelos.

1.4 METODOLOGIA
Como metodologia de pesquisa a ser usada para reunir informaes
ser a pesquisa Bibliogrfica, a fim de conhecer o funcionamento e os
conceitos

inseridos

na

metodologia

do

ProImprove,

principalmente,

buscando entender seu fluxo de atividades e tambm as etapas melhoria

definidas pela abordagem PRO2PI, alm da anlise e comparao dos
mesmos.

1.5 ESTRUTURA
Alm deste capitulo introdutrio, o trabalho est organizado da
seguinte forma:

O captulo 2 apresenta Viso Geral no que se refere ao Processo

de Software.

O captulo 3 discute sobre Abordagens de Melhoria Contnua de

Processos de Software.

14

O captulo 4 apresenta uma Anlise Comparativa entre as

Abordagens.

Finalmente, o captulo 5 apresenta as concluses desse trabalho,

bem como propostas de trabalhos futuros.

15

2 PROCESSO DE SOFTWARE: UMA VISO GERAL

Inicialmente, esse captulo introduzir os conceitos sobre tecnologia
de processo de software, os ambientes de desenvolvimento de software e
implementao de software centrados em processo, alm da definio de
processo de software.

2.1 TECNOLOGIA DE PROCESSO DE SOFTWARE

Um processo de software formado por um conjunto de passos de
processo parcialmente ordenados, relacionados com conjuntos de artefatos,
pessoas, recursos, estruturas organizacionais e restries e tem como
objetivo produzir e manter os produtos de software finais requeridos [Reis
98].
Os passos que executam um processo podem ser classificados como
atividades ou tarefas. As do incio so as mais bem gerenciadas, no entanto,
as do final so as elementares, que acertadas levam execuo de uma
atividade.
O objetivo das atividades gerar ou modificar um certo conjunto de
artefatos. As atividades podem tambm possuir relacionamentos entre si,
estando associadas com papis, ferramentas e artefatos. Elas tanto podem
ser executadas por pessoas, com o suporte de ferramentas, quanto por
aplicaes de maneira totalmente automatizada, sem a interveno humana.
Cada artefato um produto que pode ser criado ou alterado durante
um processo. Ele resulta de uma atividade e pode ser usado posteriormente

16

como base para a mesma ou para outra atividade com o intuito de gerar
novos produtos.
O modelo de processo de software a descrio abstrata do processo
de software. As informaes de quem, quando, onde e por que os passos
so realizados, devem tambm ser integrado ao modelo de processo de
software [Reis 03].
Um modelo de processo pronto para a execuo um modelo de
processo instanciado ou processo executvel. Portanto, segundo [Pressman
02], um projeto a instncia de um processo, com objetivos e restries
especficos.

2.2 AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE CENTRADOS

EM

PROCESSO
A definio de Ambiente de Desenvolvimento de Software (ADS)

decorreu do fato em que o reconhecimento da comunicao e da

coordenao entre todas as ferramentas CASE (Computer-Aided Software

Engineering Engenharia de Software Auxiliada por Computador), utilizadas

no processo de desenvolvimento e manuteno de software so essenciais
para a aquisio de produtos de qualidade. Saber como as ferramentas so
definidas, desenvolvidas, adaptadas e integradas tem sido o ponto-chave
desta rea de conhecimento.
Segundo [Reis 00a], um ADS tem por principal objetivo promover um
ambiente onde produtos de software que so de grande porte possam ser
desenvolvidos atravs da integrao de um conjunto de ferramentas que

17

suportam mtodos de desenvolvimento, apoiados por uma estrutura que

permite a comunicao e cooperao entre as ferramentas.
E assim, a evoluo dos ADS prosseguiu com a utilizao de vrias
tecnologias, tais como: processo de software, sistemas distribudos,
inteligncia artificial, banco de dados no convencionais, suporte ao trabalho
coorporativo, padres de integrao, tcnicas de gerncia de projeto, entre
outras.
Os ADS tiveram uma evoluo significativa com a tecnologia de
processo de software. Os ADS mais recentes incorporaram a automao do
processo de software o que os tornaram ADS centrados em processos (ou
orientados a processo). Conhecido na literatura como PSEE ProcessCentered Software Engineering Environment. Tais ambientes formam uma
nova gerao de ADS, os quais suportam alm da funo de desenvolvimento
de software, tambm as funes associadas de gerncia e garantias da
qualidade durante o ciclo de vida do software. Um ADS centrado em processo
baseia-se em uma definio explcita do processo de desenvolvimento de
software. Por isso o processo de software utilizado na organizao deve estar
formalizado e ser obedecido.
As aes dos ADS centrados em processos ocorrem de forma mais
abrangente no desenvolvimento de software. Segundo [Reis 00a], as funes
gerais que podem ser suportadas por um ADS centrado em processo so:
Engenharia de Processos: definio e manuteno de modelos de
processo de software. O ADS deve prover facilidades de definio, anlise e
simulao de processos;

18

Engenharia de Software: desenvolvimento e manuteno de um

produto de software atravs do seguimento de um processo de software;
Gerncia de Projetos: coordenao e monitoramento das atividades da
engenharia de software a fim de garantir que o processo est sendo seguido.

2.3 IMPLEMENTAO DE PROCESSO DE SOFTWARE

No uma tarefa trivial mudar o processo de desenvolvimento de
software de uma empresa e, quase sempre, leva-se muito tempo para se
observar os resultados. [Balduino 02] diz que adotar uma nova ferramenta de
desenvolvimento diferente, pois basta instal-la, entender o manual do
usurio e seguir as instrues de um tutorial. Ou quem sabe ainda fazer um
curso sobre ela, levando horas ou talvez dias para realizar isso. Porm,
modificar o processo de desenvolvimento de software de uma organizao
afeta a maneira como os indivduos trabalham, vem, e do valor ao
resultado de seu trabalho. No entanto, ter uma mudana no processo de uma
organizao provoca um impacto muito maior sobre os indivduos que a
compe do que apenas uma mudana na tecnologia.
No entanto, ter uma mudana desse tipo no se faz da noite para o
dia. Deve-se ter o maior cuidado para sempre se fazer um planejamento e
um

gerenciamento

com

relao

mudanas.

Pode-se

obter

uma

implementao mais adequada fazendo-se valer de uma abordagem de

adoo gradual do processo de desenvolvimento e ferramentas de apoio, no
qual cada passo seja planejado, executado e avaliado com critrio.

19

Os quatro passos distintos mostrados a seguir descrevem, sob o

aspecto da engenharia de software, como se d a implementao de um novo
processo em uma empresa de desenvolvimento de software.

Figura 2-1: Passos para implementar processo em uma empresa [Oliveira 05]

2.4 DEFINIO DE PROCESSO DE SOFTWARE

Um processo de software segundo [Humphrey 89] o conjunto de
tarefas de engenharia de software necessrias para transformar os requisitos
dos usurios em software. Na definio de um processo de software devem
ser consideradas as seguintes informaes: atividades a serem realizadas,
recursos

utilizados,

artefatos

consumidos

gerados,

procedimentos

adotados, paradigma e tecnologia adotados, e o modelo de ciclo de vida

utilizado [Falbo 98].
Entender melhor as atividades executadas por todos os membros da
mesma equipe permitido pelo trabalho organizado de profissionais de

20

engenharia de software que possuem em sua organizao um processo de

software definido [Humphrey 89].
Definir processos que sejam genericamente aplicados ao vasto leque
de

aplicaes

esbarra

na

diversidade

de

polticas

procedimentos

organizacionais, na complexidade de projeto, nos mtodos e estratgias de

aquisio, no tamanho, nos mtodos de desenvolvimento do sistema, entre
outros. Fazendo com que eles sejam bem diferentes uns dos outros.
Assim, na definio de um processo preciso levar em considerao
desde caractersticas da equipe trabalho, da prpria organizao at as
tecnologias utilizadas, o tipo de software envolvido, o domnio da aplicao e
o grau de maturidade da equipe em engenharia de software ([Humphrey 89],
[Rocha 01]).

2.5 CONSIDERAES FINAIS

Aps a apresentao de uma viso geral dos conceitos e definies
relativos ao Processo de Software, o captulo seguinte mostrar os conceitos
de melhoria contnua e medio de processo de software, uma explanao
do modelo IDEAL que adota as caractersticas da melhoria contnua dos
processos organizacionais e, por fim, as iniciativas metodolgicas para
melhoria de

processos de

software que

serviram de base

para o

desenvolvimento deste trabalho.

21

3 ABORDAGENS DE MELHORIA CONTNUA DE PROCESSOS DE

SOFTWARE

Esse captulo comea descrevendo os conceitos de melhoria contnua e

medio de processo de software, bem como os conceitos e o ciclo de
melhoria do modelo IDEAL [Mcfeeley 96] que serviram de base para a
compreenso das fases da metodologia ProImprove, um dos principais
objetos de estudo deste trabalho. E, por fim, apresenta-se as iniciativas
metodolgicas para melhoria de processos de software que expem as
principais informaes para o desenvolvimento desse trabalho.

3.1 MELHORIA CONTNUA DE PROCESSOS

Cada vez mais as tecnologias geram novos recursos para tornar nosso
dia-a-dia mais fcil e gil. Muitos deles, logo aps sua criao, passam a se
tornar indispensveis, principalmente no tocante ao desenvolvimento de
produtos de software e sistemas que, a cada dia, impressionam pela
complexidade com que vm sendo criados.
Todavia, sabe-se que

a complexidade gera um aumento das

dificuldades no decorrer do desenvolvimento.

[Humphrey 89] diz que

medida que aumenta a complexidade dos sistemas menor a produtividade

das equipes, e isso ocorre por causa da baixa qualidade dos sub-produtos
que formam o produto final. Alm de todos os problemas que surgem
quando o produto liberado para uso, na grande maioria dos projetos
constata-se problemas de cronograma e oramento. Assim, sobreviver num
mercado to competitivo vem sendo um desafio para as organizaes
22

desenvolvedoras de software. Observa-se que a qualidade dos produtos

torna-se cada vez mais inerente sobrevivncia das empresas.
Nos ltimos anos, observamos que garantir maior qualidade nos
produtos e

aperfeioar

o desenvolvimento de

softwares

provocaram

mudanas no enfoque em relao ao processo de software [Rocha 01]. Surge,

ento, uma nova abordagem onde a prioridade est em garantir a qualidade
do processo de produo, mostrando-se como fator decisivo para se obter
qualidade do produto final.
A partir dessa mudana de enfoque, intensificou-se as pesquisas sobre
o processo de desenvolvimento e vrias normas e modelos de qualidade
foram definidos para auxiliar na definio e melhoria de processos de
software. Dentre os quais vale destacar a Norma ISO/IEC 12207 [ISO 97], o
CMM (Capability Maturity Model) [Paulk 95], o SPICE (Software Process
Improvement and Capability dEtermination) hoje a norma ISO/IEC 15504 [ISO
98], o CMMI (Capability Maturity Model Integrarion) [CMMI 02], e o MPS.Br
(Melhoria do Processo de Softwre Brasileiro) [Softex 05].
Chegou-se a concluso que para se chegar a patamares cada vez mais
altos

de

qualidade,

era

preciso

melhorar

cada

etapa

do

ciclo

de

desenvolvimento. Contudo, tornar isso realidade era necessrio buscar e

analisar dados quantitativos que expressassem de forma clara quo melhor o
processo est sendo realizado. Assim, mensurar os produtos de software
tornou-se pr-requisito indispensvel na melhoria de processo [Basili 85].
Os seguintes objetivos listados abaixo foram alcanados a partir de
muitas propostas e aplicaes prticas [Park 96]:

23

Melhorar o entendimento sobre o processo, produto, recursos e

ambiente de desenvolvimento e, assim, estabelecer bases para a

comparao entre as medies;

Avaliar o andamento do projeto comparando com dados planejados;

Fazer previses sobre o futuro andamento do projeto com base em

comportamentos passados;
Promover melhorias identificando falhas, ineficincias e outras

oportunidades

para

melhorar

qualidade

do

produto

desenvolvimento do processo.
Contudo, no fcil definir, coletar e analisar um conjunto de
mtricas. A realizao destas atividades requer cuidados especiais, pois
podem

gerar

um

aumento

dos

problemas

enfrentados

durante

desenvolvimento de software. De acordo com [Basili 94], deve-se:

Concentrar-se em objetivos especficos;

Ser realizadas sobre todos os produtos, processos e recursos do

ciclo de vida;

Ter seus resultados interpretados com base em caractersticas do

contexto organizacional e do ambiente.

Finalmente, encontrar um conjunto de modificaes que melhore os

resultados obtidos seja do processo, seja da organizao bastante
desafiador. Na seo a seguir, ser descrita uma abordagem para medio e
melhoria de processos de software que inclui definio, coleta e anlise de
mtricas aplicadas aos processos de software [Oliveira 06a].

24

3.2 ABORDAGEM PARA A MEDIO E MELHORIA DE PROCESSO DE

SOFTWARE
Desenvolver aplicativos e sistemas de software no uma tarefa trivial,
requer empenho de equipes de trabalho que em conjunto pem em prtica
toda sua criatividade e capacidade de desenhar e implementar solues cada
vez mais complexas. Para tanto, seguir uma linha de execuo para que um
objetivo comum seja alcanado est sendo a alternativa que as organizaes
esto aplicando para identificar suas diferentes dimenses e encontrar
problemas que precisam ser analisados a fim de estabelecer prticas efetivas.
Sendo assim, supe-se que a qualidade adquirida do produto de software
quando se realiza um processo no seu desenvolvimento est diretamente
ligada qualidade do processo utilizado para o sua construo e
manuteno [Gomes 01]. Seguindo o raciocnio de cultivar a utilizao de
processo quando acontece algum problema, preciso que no apenas o
defeito encontrado seja corrigido, mas tambm o processo que permitiu que
tal erro acontecesse. Logo, trabalhos futuros no sofrero os mesmos tipos
de correo.
propsito, no se conhece um processo que seja genrico, ou seja,
aplicvel a qualquer tipo de projeto, pois cada um tem sua particularidade.
Sabe-se

que

h diferenas

na estratgia de

aquisio,

tamanho e

complexidade do projeto, bem como nas polticas e procedimentos

organizacionais que influenciam o produto de software, desde a aquisio
at a manuteno.
Alm de todas as caractersticas citadas acima, existem outras que
determinam na definio de um processo, dentre os quais podemos destacar
25

as tecnologias de desenvolvimento, a experincia e o conhecimento das

equipes de trabalho, o porte da empresa, bem como sua cultura e os
objetivos do projeto especfico [Machado 00].
No entanto, para melhor entender como sistemas complexos de
software so produzidos surgiu a necessidade de uma pesquisa mais a fundo
sobre a definio e a modelagem de processo de software. Com isso,
permite-se gerenciar a execuo, melhorar a compreenso, estudar o
aperfeioamento e automatizar parte da sua execuo [Arajo 98].
De incio, vrias ferramentas se propuseram a resolver o problema de
automatizao de parte do processo. Da, reparou-se que a preocupao
maior para o sucesso de um projeto est no pessoal e nos processos que o
compe. A tecnologia no se demonstra como um fator to de risco, talvez
seja o menos problemtico [Gomes 01]. No entanto, o desenvolvedor deve,
sim, se valer das ferramentas, mas elas por si s no so uma garantia de
xito.
As pesquisas mostram que a melhoria da qualidade dos softwares e,
por conseguinte, dos processos de software crescente quando se tm
empresas e projetos cada vez maiores. O que vem se observando tambm
que a definio dos processos deve ser de forma bem dinmica para poder
acompanhar as expectativas de um mercado exigente e competitivo. Para
tanto, necessita-se melhorar cada etapa do processo de desenvolvimento,
mas para que isso ocorra preciso obter dados quantitativos que possam
expressar o andamento atual do projeto. Vrias mtricas foram propostas
com o objetivo de suprir essa necessidade [Oliveira 06a].

26

[Rocha 01] baseia-se nas seguintes etapas para a abordagem de

medio e melhoria de processos de software:

Seleo / definio de mtricas adequadas, para realizar as

medies, com base em objetivos previamente identificados;

Realizao de medies como parte integrante do processo de

desenvolvimento de software;

Anlise dos resultados do uso do processo em projetos, apoiada

por um sistema com base em conhecimento;

Realizao

de

estudos

empricos

envolvendo

medio

de

processos de software.
Procurou-se, ainda, separar as atividades de medio, anlise e
melhoria de processo das atividades de desenvolvimento de software.
Percebeu-se que uma empresa de desenvolvimento de produtos de software
tem que manter o foco no seu objetivo, respeitando os prazos e os custos
para tal. A anlise do processo deve ser realizada por uma equipe de fora da
organizao desenvolvedora. Esta fornecer os dados necessrios para se
obter o feedback dos seus projetos com relao aos processos, incluindo as
diretrizes de melhoras dos mesmos [Basili 94].

3.2.1 DEFINIO DE MTRICAS

A tarefa de escolher as mtricas que vo compor o conjunto de
referncias para a medio do processo de software bastante complicada.
Olhar a literatura e decidir qual mtrica melhor para determinada situao
no trivial. A seguir sero mostradas as mtricas escolhidas para a

27

metodologia do ProImprove, onde, segundo [Rocha 01] no um conjunto

perfeito de mtricas, mas suficiente.
Seguem trs objetivos os quais as mtricas foram selecionadas. So
eles: caracterizar o projeto e seu contexto; medir, avaliar e sugerir melhorias
em um processo de software especfico; e realizar estudos empricos
envolvendo medio de processos de software. Veja como ficou a
organizao do conjunto selecionado [Oliveira 06a]:

Tempo: tempo total do projeto; tempo nas fases de anlise, projeto,

codificao, teste de unidades feitos por analistas, testes do sistema e
testes de homologao; tempo em reunies de reviso; e tempo em
retrabalho;

Preciso de estimativa de cronograma: estimativa de cronograma de

todo o projeto, estimativas de cronograma para as fases de anlise,
projeto, codificao, teste de unidades feitos por analistas, teste do
sistema e teste para homologao;

Esforo: esforo total do projeto; esforo nas fases de anlise, projeto,

codificao, teste de unidades feitos por analistas, testes do sistema e
testes de homologao, esforo em reunies de reviso; esforo em
revises; e esforo em retrabalho;

Preciso da estimativa de esforo: estimativa de esforo para todo o

projeto; estimativa de esforo para as fases de anlise, projeto,
codificao, teste de unidades feitos por analistas, teste do sistema,
teste de homologao e revises;

Tamanho do sistema: nmero de linhas de cdigo; pontos por funo;

pontos por casos de uso;
28

Nmero de erros: nmero de erros na especificao de requisitos e no

projeto do sistema encontrados em reunies de reviso, erros no
cdigo encontrados nos testes de unidade feitos por analistas;

Nmero de modificaes: nmero de modificaes na especificao de

requisitos, projeto ou cdigo aps a sua aprovao;

Densidade de defeitos: nmero de erros somado ao nmero de

modificaes em relao ao tamanho do sistema;

Rotatividade do pessoal: percentual de pessoas que saram, entraram

ou mudaram de funo durante o desenvolvimento do projeto;

Produtividade: nmero de linhas de cdigo produzidas por unidade de

esforo; pontos por funo ou casos de uso por esforo;

Deteriorao do software: relao entre o esforo gasto para corrigir os

problemas encontrados aps a liberao do sistema para o usurio
comparado ao esforo gasto da liberao do software para o usurio.

Experincia da equipe: experincia na linguagem de programao, no

domnio da aplicao, nas ferramentas, no mtodo e no processo de
desenvolvimento, tipo de treinamento em engenharia de software e
tempo total de experincia profissional.
O objetivo de caracterizar o projeto, bem como seu contexto de

desenvolvimento se enquadra nas mtricas que procuram coletar e comparar

resultados de projetos similares. J o objetivo de medir, avaliar e sugerir
melhorias em um processo de software recai sobre as mtricas que tem por
meta avaliar e melhorar a preciso das estimativas, avaliar e melhorar a
qualidade dos produtos, e medir e reduzir o retrabalho. Por fim, para
[Oliveira 06a] o objetivo de formar uma base de dados para futuros estudos
29

empricos rege as mtricas que coletam informaes para o aumento do

entendimento sobre os processos do ciclo de vida de software.
Para garantir que as mtricas selecionadas tenham uma utilizao
correta. preciso definir sua estrutura operacional, para garantir que
pessoas diferentes as implementem de forma coerente e consistente e que
os dados sejam interpretados corretamente [Rocha 01].

3.2.2 COLETA DE MTRICAS

Vimos que a melhor maneira de se trabalhar com essas atividades de
medio de processo de software descentralizando as responsabilidades,
ou seja, deixando elas fora do comando da organizao desenvolvedora que
tem como atividade principal o desenvolvimento do produto de software.
Logo, para fins de anlise posterior, os dados devem ser resgatados de
documentos simples e geralmente produzidos pela organizao durante todo
o processo. Seja ele, um relatrio de histrico e/ou uma planilha de
atividades [Rocha 01].
Discriminando o que cada um dos documentos acima citados poderiam
oferecer, esto: o registro de todas as atividades do processo de
desenvolvimento com as datas de incio de trmino, as reunies de avaliao
realizadas e seus resultados (relatrio de histrico); os registro de todas as
atividades realizadas por cada membro da equipe de desenvolvimento e a
gerncia do projeto (planilha de atividades) [Oliveira 06a].

30

3.2.3 ANLISE DAS MTRICAS COLETADAS

Aqui, esto definidos dois objetivos que a anlise das mtricas
seguem, so eles: analisar os resultados buscando melhorias para o processo
de software e realizar estudos empricos de comparao das mtricas
colhidas em medies efetuadas nos diversos projetos [Rocha 01].
A anlise aqui descrita ser sustentada por um sistema que possui
uma base de conhecimento construdo (algum ambiente de desenvolvimento
de software descrito na literatura especializada) que foi gerada pelo
conhecimento de especialistas, dado os resultados coletados por meio de
medies.

As

informaes

oriundas

dessa

atividade

formam

um

conglomerado de recomendaes para a melhoria de processo. Especialistas

podem definir esse conglomerado de recomendaes e verificar a existncia
de resultados no aceitveis dentro do processo de software ou com relao
ao contexto em que realizado o desenvolvimento. Caso essa situao
ocorra,

dever

haver

alguma

inferncia

no

sistema

com

base

no

conhecimento sobre as caractersticas do processo [Oliveira 06a].

3.3 MODELO IDEAL PARA A MELHORIA CONTNUA DE PROCESSOS

Cada vez mais, organizaes reconhecem que preciso orientao
especial na execuo das suas atividades no instante em que mtodos,
processos e ferramentas de engenharia de software so escolhidos. Muitos
esforos de melhoria, incluindo melhoria do processo de software, contnuo
gerenciamento de riscos, ou a introduo de um novo ambiente de
desenvolvimento, so to complexos, e seus efeitos to de longo alcance,

31

que eles requerem uma abordagem especializada e sistemtica para

gerenciar o ciclo de vida de adoo da tecnologia. O Software Engineering
Institute (SEI) desenvolveu e refinou o Modelo IDEAL - Initiating, Diagnosing,
Establishing, Acting & Learning - para ajudar a satisfazer essa necessidade.
O modelo IDEAL, como concebido originalmente, era um modelo de
ciclo de vida para a melhoria do processo de software baseada no Capability
Maturity Model (CMM) [Paulk 93], e por esta razo o modelo usou termos da
melhoria do processo.
O Modelo IDEAL fornece uma abordagem usvel e fcil de entender
para o aprimoramento contnuo por mostrar os passos necessrios para se
estabelecer um programa de melhoria de processos bem sucedido. Seguir as
fases, atividades e princpios do Modelo IDEAL tem se provado benfico em
muitos esforos de melhoramentos. O modelo fornece uma abordagem de
engenharia disciplinada para o aprimoramento, foca no gerenciamento do
programa de aprimoramento, e estabelece a fundao para uma estratgia de
melhoramento de longo prazo. O modelo consiste em cinco fases e so
apresentadas na Figura 3-1, so elas:

Initiating: esta a fase onde a infra-estrutura inicial da melhoria

estabelecida, os papis e as responsabilidades para esta infraestrutura so inicialmente definidos, e os recursos inicias so
atribudos. Este fase foca no estmulo para a melhoria do processo
de software, na definio do contexto e do patrocinador e no
estabelecimento

da

infra-estrutura

inicial

para

suporte

da

melhoria [Oliveira 06a];

32

Diagnosing: o foco nesta fase desenvolver um entendimento

mais completo do trabalho de melhoria. Durante esta fase duas
estratgias para a melhoria do processo da organizao so
definidas: o estado atual e o estado futuro desejado. Estes
estados organizacionais so usados para desenvolver

uma

abordagem para a prtica de melhoria do negcio. Assim, o

objetivo caracterizar o estado atual e o estado futuro desejado
da organizao, e desenvolver recomendaes de como proceder
nas fases subseqentes [Oliveira 06a];

Establishing: o objetivo desta fase desenvolver um plano de

trabalho

detalhado.

As

prioridades

de

quais

prticas

organizacionais sero melhoradas so ajustadas para refletir as

recomendaes feitas durante a fase Diagnosing. Este passo tem a
finalidade de colocar prioridades para as alteraes, desenvolver
uma estratgia para realizao do trabalho, identificar recursos
disponveis, e desenvolver um plano de implementao detalhado
(onde as aes, marcos de referncia e as responsabilidades so
incorporados em um plano de ao) [Oliveira 06a];

Acting: as atividades desta fase servem para ajudar uma

organizao a implementar o trabalho realizado nas trs fases
anteriores (Initiating, Diagnosing e Establishing). Assim, o foco
criar

melhor

soluo

que

atenda

as

necessidades

organizacionais identificadas, testar a soluo criada atravs de

um

projeto

piloto,

modificar

soluo

para

refletir

33

conhecimento, experincias e lies obtidas no projeto piloto, e

implementar a soluo em toda a organizao [Oliveira 06a];

Learning: nesta fase a experincia obtida com execuo do

modelo

IDEAL

conseguiram

revista

atingir

os

para

determinar

objetivos

se

pretendidos,

os
e

esforos
como

organizao pode executar a mudana mais eficazmente e / ou

eficientemente no futuro. Para isso, as lies so coletadas,
analisadas e documentadas, as necessidades identificadas na fase
Initiating so reexaminadas para ver se foram atendidas, e
propostas

de

alteraes

para

melhoria

futura

devem

ser

fornecidas [Oliveira 06a].

Figura 3-1: Modelo IDEAL [Mcfeeley 96]

34

3.5 INICIATIVAS METODOLGICAS PARA MELHORIA DE PROCESSOS

DE SOFTWARE
A seguir, sero mostradas as abordagens que serviram de base para a
anlise comparativa proposta neste trabalho. Revelando os conceitos
inerentes a cada uma delas, bem como suas peculiaridades com relao s
suas atividades.

3.4.1 PROIMPROVE
O ProImprove faz parte de um ambiente cooperativo formado por nove
ferramentas principais. Sua funo possibilitar a execuo sistemtica das
atividades de melhoria contnua de processo de software. O ImPProS,
ambiente em que o ProImprove est inserido um projeto de iniciativa do
Centro de Informtica da UFPE Universidade Federal de Pernambuco com a
parceria da UNAMA Universidade da Amaznia, financiado pelo CNPq
Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico, que visa a
criao de um ambiente de apoio implementao de um processo de
software em uma organizao de forma progressiva. O termo progressiva
decorre do fato de que a implementao do processo aperfeioada com as
experincias aprendidas na sua definio, simulao, execuo e avaliao.
Em um trabalho de graduao [Correia 05], desenvolvido por Rafael
Correia, o modelo IDEAL acima citado foi adaptado para ser utilizado no
ambiente de implementao de processo de software. Como parte desse
trabalho foi desenvolvida toda a metodologia do ProImprove, alm de um
prottipo dessa adaptao. Num outro trabalho de graduao [Matos 05],
35

desenvolvido por Pedro Matos, o ProImprove foi estendido para oferecer

suporte a mtricas para validar se uma dada melhoria atingiu seus objetivos
e avaliar tambm o processo de melhoria em si.
3.4.1.1 Adaptao do Modelo IDEAL
O trabalho realizado por [Correia 05] consistiu de uma anlise de todas
as fases do modelo visando a contextualizao dessas para o ambiente de
implementao de processos de software. Sua adaptao foi alcanada e
baseada em dois objetivos principais: a utilizao dos conceitos de melhoria
contnua no contexto do ambiente e estudar como o modelo IDEAL se
comportaria na implantao de melhorias em processos de software dentro
desse contexto.
A adaptao proposta definiu trs vises distintas:
Gerenciamento: responsvel por planejar como as informaes seriam
manipuladas no ambiente pelos usurios.
Uso (Execuo): responsvel pela por manter informaes relativas
execuo das melhorias.
Avaliao: responsvel por todas as atividades onde necessrio
avaliar alguma informao a fim de inferir um resultado.
A adaptao definiu ainda dois perfis de pessoas responsveis pela
melhoria de um processo de software:
Projetista

de Processo: responsvel por descrever

a melhoria,

identificar a motivao para que esta seja executada, definir o contexto

organizacional, alocar a infra-estrutura necessria, definir os procedimentos
necessrios e fornecer uma anlise e validao da soluo implantada.

36

Gerente de Processo: responsvel por definir um plano de aes, criar

a soluo, test-la, refin-la e por fim implant-la.
A prxima seo fornece uma rpida viso do fluxo das atividades
envolvidas na adaptao proposta.
3.4.1.2 Fluxo de Atividades do ProImprove
A adaptao pode ser visualizada como um fluxo de atividades
distribudas entre o projetista do processo, o gerente do processo e o
patrocinador que fornecer o apoio necessrio para que melhoria ocorra. A
Figura 3-2 ilustra esse fluxo de atividades.

37

Figura 3-2: Fluxo de Atividades do ProImprove [Oliveira 06a]

A atividade Cadastrar Razo corresponde fase de definio do

estmulo da mudana no modelo IDEAL. nessa fase onde o projetista
definir quais razes faro a empresa investir na melhoria de seus processos,
bem como quais as prticas que faro a melhoria acontecer. J na atividade

Definir Contexto, o projetista descrever os objetivos que a melhoria

pretende buscar, quais os benefcios que a melhoria trar para a organizao

38

e como ela afetar os trabalhos existentes que esto relacionados com a

melhoria.
Para que o projeto siga a diante, na atividade Construir Apoio algum
membro da alta administrao da organizao deve assumir o papel de
patrocinador, formalizando o seu interesse pela melhoria e garantindo o
apoio necessrio para que a mesma seja executada.
Aps receber o apoio necessrio, o projetista do processo dever
executar a atividade Alocar Infra-Estrutura, nesse momento precisa-se saber
se h alguma restrio antes que a melhoria seja executada. H que se
definir

com o que

cada pessoa alocada para

essa

empreitada se

comprometer e quais esforos sero necessrios para a realizao da

melhoria. Uma vez montada a infra-estrutura, o projetista ter de concluir a
atividade Caracterizar Estados. O foco dessa atividade definir os estados
atual e desejado para cada prtica do processo software que sofrer
modificao para servir de base para a validao da melhoria. Alm disso,
nesta atividade, foi adicionada a habilidade do projetista especificar um
conjunto de mtricas.
A partir da, definido claramente o estado em que a prtica est e o
estado

que

ela

pretende

alcanar,

projetista

caracterizar

toda

configurao das mtricas que avaliar as prticas decorrentes da melhoria,

primeiramente realizando a ao de Configurar Questes para Validao das

Prticas,

nela

projetista

informar

as

questes

cujas

respostas

influenciaro na validao da prtica e ajudar a identificar se o estado

desejado para a prtica foi alcanado. Seguindo essa configurao temos,

Configurar Anlise das Questes, onde o projetista cadastrar todos os

39

valores possveis para todas as questes inseridas na etapa anterior. Esses

valores podem ser qualidades, no caso de mtricas qualitativas, podem ser
nmeros ou intervalos numricos, no caso de mtricas quantitativas. Para
cada valor inserido, deve ser definida tambm uma interpretao para a
mtrica: Prtica Validada

ou Prtica

No Validada. Concluindo essa

especificao de mtricas, o projetista ir Configurar Validao da Prtica.

Nela, dever se escolher o percentual mnimo de questes cuja inferncia
deva ser Prtica Valida para que o ambiente possa efetivamente inferir que a
prtica foi validada.
Definida todas as mtricas para o projeto de melhoria, o passo
seguinte executar a atividade Definir Procedimentos, na qual especificar
as recomendaes que iro servir de apoio para as atividades posteriores.
A prxima etapa a ser executada pelo projetista Definir Prioridades.
Nessa etapa, subgrupos so formados para se ter uma maior flexibilidade
quanto execuo da melhoria. So definidas quais prticas sero focadas
inicialmente e na seqncia da melhoria. Aps definir prioridades, o
projetista dever Desenvolver Estratgias, ou seja, criar um plano estratgico
de execuo da melhoria.
Uma vez definido o plano estratgico, o gerente do processo poder
dar incio atividade Planejar Aes. O foco dessa atividade a definio de
um plano de aes para implantao da melhoria, contendo um cronograma
de tarefas, milestones e pontos de deciso. O plano de aes inclui ainda um
gerenciamento de recursos, atribuio de responsabilidades, definio de
mtricas,

mecanismos

de

tracking,

planejamento

de

estratgias

gerenciamento de riscos.
40

Aps a definio do plano de aes, o gerente poder iniciar a

atividade Criar Soluo. A soluo composta pelas ferramentas e processos
que sero utilizados; conhecimentos e habilidades necessrias; ajuda externa
que ser requerida e quaisquer outras informaes adicionais. Aps a criao
da soluo esta dever passar pelas atividades de Testar Soluo e Refinar

Soluo. Quando a soluo for finalmente validada, esta ser implantada na

atividade Implantar Soluo.
Uma vez implantada a soluo, atravs da atividade Analisar e Validar

Soluo o projetista do processo poder saber se para cada prtica escolhida

para a melhoria foi validada ou no. Essa atividade foi estendida para que o
projetista pudesse executar a ao de Analisar Questes de Validao da

Prtica, onde se deve fornecer um valor vlido para cada uma das questes
de validao da prtica, valores que serviro como resposta correta para o
parmetro de avaliao. E tambm, observar as informaes em Sugerir

Resultado de Validao da Prtica, onde os valores mostrados sero inferidos

a partir dos dados inseridos na fase Caracterizar Estados. Informa-se a
resposta e a interpretao para cada questo de validao da prtica, bem
como, a sugesto de validao da prtica e o seu percentual de inferncia.
Alm disso, h ainda a ao Analisar Caractersticas de Execuo da Sub-

melhoria, onde se ir avaliar a melhoria como um todo. Deve-se fornecer um

valor vlido para cada uma das suas caractersticas, para a partir da o

ProImprove Inferir Questes de Execuo da Sub-melhoria. O valor de

inferncia ser informado podendo o projetista aceitar ou no.
Finalizando o fluxo, o projetista executar a atividade Propor Aes

Futuras. Aps registrar as lies aprendidas durante a sua execuo elas

41

formaro uma base de conhecimento do mtodo de implantao de

melhorias, permitindo que boas prticas sejam reconhecidas e erros sejam
evitados no futuro. Se julgar necessrio, ele poder ainda propor as aes
futuras que iro trazer mais eficincia e confiabilidade execuo de
melhorias que vierem adiante.

3.4.2PRO2PI
A abordagem PRO2PI definida na Tese de Doutorado de Clnio
Figueiredo Salviano pela Faculdade de Engenharia Eltrica e de Computao
da Universidade Estadual de Campinas prope uma engenharia de processo
dirigida por perfis de capacidade de processo. A seguir, descreveremos como
so estruturadas suas fases e atividades. Uma viso geral da utilizao da
abordagem PRO2PI pode ser vista no Apndice A.
3.4.2.1 Fases e Atividades do PRO2PI
O objetivo principal das atividades de definio e utilizao de PRO2PI
definir e utilizar PRO2PI. O produto de entrada e de sada o perfil de
capacidade de processo. As atividades podem ser consideradas como uma
implementao

das

prticas

base

definidas

para

processo

de

estabelecimento de processo, que esto descritas no Apndice B.

A seguir, as fases e as atividades que compes a abordagem PRO2PI
sero expostas para que sejam melhor compreendidas.
De acordo com PRO2PI a primeira fase Iniciar Ciclo de Melhoria,
onde se faz o levantamento de informaes gerais sobre a empresa,
incluindo o contexto e objetivos estratgicos, metodologias existentes,

42

tecnologias e projetos existentes, a definio das Metas de Melhoria, a

definio do Perfil de Capacidade de Processo, a reviso e detalhamento do
Programa de Melhoria de Processo e a definio do Plano Preliminar da
Avaliao das Prticas Correntes.
Seguindo esse fluxo, temos a fase Avaliar Prticas Correntes, onde se
executa as atividades de reviso do Plano da Avaliao das Prticas
Correntes, o treinamento da equipe de Avaliao sobre o Processo da
Avaliao,

a adaptao das Prticas de Referncia para a Avaliao, o

levantamento e validao de dados para a avaliao dos Projetos e Processos

selecionados,

a derivao e elaborao dos Resultados da Avaliao, a

apresentao dos Resultados da Avaliao e a reviso do Perfil de Capacidade

de Processo.
A fase Planejar Aes de Melhoria, realizada com as atividades de
treinamento de pessoas selecionadas sobre o Processo de Planejamento da
Melhoria e elementos para sua implantao, definio da Estratgia para
Implantao da Melhoria, definio das Aes de Melhoria, elaborao do
Plano

de

Melhoria

de

Processo,

definio

das

responsabilidades

necessidades de compromissos, pela elaborao do Plano de Preparao da

Organizao, reviso do Plano de Melhoria de Processo por pessoas
selecionadas, estabelecimento das responsabilidades para execuo do Plano
de Melhoria de processo, incluindo as funes de gerente, grupo de processo
e grupos de implementao de processo, estabelecimento dos compromissos
para execuo do Plano, atividades para consolidao de planejamento,
reviso das atividades e resultados da subfase anterior, atualizao do Plano,

43

treinamento de pessoas selecionadas sobre elementos para implantao do

Plano e apresentao para incio da implantao das aes de melhoria.
A prxima, a fase Realizar Aes de Melhoria, que realiza as
atividades descritas no Plano, monitora as atividades conforme o Plano,
revisa o Plano e realiza aes corretivas, quando necessrio.
Para Preparar institucionalizao da melhoria tem-se que revisar o
resultado da Melhoria e elaborar o Plano de Institucionalizao.
Por fim, temos a fase Institucionalizar a melhoria, onde se promove a
realizao das atividades descritas no Plano de Institucionalizao, o
monitoramento das atividades conforme o Plano de Institucionalizao, a
Reviso do plano de Institucionalizao e a realizao das aes corretivas,
caso seja necessrio.

3.5 CONSIDERAES FINAIS

Neste captulo foram apresentados os conceitos de melhoria contnua e
medio de processo de software, uma descrio das fases do modelo IDEAL
e as atividades das duas iniciativas metodolgicas para melhoria de
processos de software que so as bases para a anlise comparativa que ser
mostrada no captulo seguinte.

44

4 ANLISE COMPARATIVA ENTRE AS ABORDAGENS

Este captulo tem por objetivo traar uma anlise comparativa com
diversos aspectos das abordagens mencionadas no captulo anterior, na
tentativa de ilustrar semelhanas e diferenas que possam justificar uma
abordagem mais ampla. Talvez esta anlise venha auxiliar em futuras
pesquisas, com o surgimento de novos elementos que estendam o trabalho
aqui realizado.

4.1 COMPARATIVO
Atravs do comparativo realizado entre os fluxos de atividades, ver
Apndice C, contemplados pelos dois ciclos de vida de melhoria de processo
de software, o primeiro mostrado na Figura 3-1, que sofreu adaptaes
quando aplicado ao ProImprove e o segundo descrito na seo 3.4.2.1,
descobriu-se quais atividades pertenciam a um determinado ciclo e no
pertenciam ao outro e vice-versa. As Figuras 4-1 e 4-2 abaixo sintetizam
esses dois ciclos.

Figura 4-1: Ciclo de vida do modelo IDEAL [Salviano 06]

45

Figura 4-2: Ciclo de vida da abordagem PRO2PI [Salviano 06]

Atividades do PRO2PI no contempladas pelo ProImprove:

Reviso e detalhamento do Programa de Melhoria de Processo:

o Esta atividade de reviso no contemplada pelo ProImprove
porque as revises so feitas continuamente e automaticamente
pelo sistema. O que no acontece com o PRO2PI, visto que a
dinmica de atividades realizada com relatrios escritos, ou
seja, manualmente.

Treinamento da equipe de avaliao sobre o processo da avaliao,

Treinamento

de

pessoas

selecionadas

sobre

processo

de

planejamento da melhoria e elementos para sua implantao e

Treinamento

de

pessoas

selecionadas

sobre

elementos

para

implantao do Plano:
o No h atividade de treinamento, pois o treinamento no ImPProS
realizado antes de entrar no ciclo de melhoria de processo.
Antes de qualquer coisa, h um treinamento para a execuo da
metodologia do ProImprove que permitir aos usurios realizar
as

atividades

de

melhoria

de

processo

que

nela

esto

contempladas.

46

Apresentao para incio da implantao das aes de melhoria:

o Esta atividade s existe no PRO2PI porque as atividades no so
automatizadas nem integradas em um ambiente (ImPProS) que
permita a uma visualizao de tudo que est sendo executado,
ou seja, um ciclo de vida voltado para automatizar as fases de
implementao do processo de software (definio, simulao,
execuo e avaliao).

Atividades do ProImprove no contempladas no PRO2PI:

Configurando Validao da Prtica:

o Como o ProImprove realiza todas suas atividades automatizadas,
bem como seu processo de mtricas para medio das
melhorias, h uma atividade onde o usurio dever escolher o
percentual mnimo de questes cuja inferncia deva ser Prtica
Valida para que o ambiente possa efetivamente inferir que a
prtica foi validada. Esta atividade prpria do ProImprove.

Definir prioridades:
o Atividade prpria do ProImprove onde so informadas quais as
prticas que sero focadas inicialmente na seqncia da
melhoria, ou seja, a melhoria tratada de forma particionada,
garantindo, assim, o seu objetivo de ser contnuo. No PRO2PI
no h essa flexibilidade quanto execuo da melhoria, ou
seja, um nico grupo de processos escolhidos melhorado.

47

4.2 RESULTADOS
Com base na anlise das duas abordagens observa-se a adequao do
modelo de ciclo de vida para o ProImprove como mostra na Figura 4-3, onde
as atividades de definio do Perfil de Capacidade de Processo, definio do
Plano Preliminar da Avaliao das Prticas Correntes, reviso do Plano da
Avaliao das Prticas Correntes e reviso do Perfil de Capacidade de
Processo que em comparao ao PRO2PI estariam no fluxo de atividades do

ProImprove, seriam executadas na base do ambiente ImPProS, ou seja, fora

do seu fluxo normal.

Figura 4-3: Modelo de ciclo de vida para o ProImprove

A partir da observao da tabela comparativa disponvel no Apndice

C, observou-se que os dois modelos so adequados para executar a tarefa
de melhoria contnua de processo de software. O ProImprove, usando como
filosofia e base o Modelo IDEAL, bem como seu modelo de mtricas e, o
PRO2PI, focando na Capacidade de Processo, onde apesar das diferenas
conceituais ambos possibilitam agregar valor ao trabalho que cada um se
prope.

48

4.3 CONSIDERAES FINAIS

Neste captulo, foram apresentados o comparativo e os resultados
obtidos a partir anlise feita entre os fluxos de melhoria dos modelos
apresentados. O prximo captulo mostrar a concluso desse trabalho.

49

5 CONCLUSO
Neste captulo sero apresentadas s consideraes finais desse
trabalho, descrevendo em linhas gerais o sumrio do trabalho, e os possveis
trabalhos de extenso propostos a este.

5.1 SUMRIO DO TRABALHO

Uma abordagem para melhoria de processo de software uma
orientao para um conjunto de aes para a melhoria de processo em uma
organizao intensiva em software. A vantagem disso que o processo de
melhoria de processo garante a melhoria contnua da eficincia e eficcia da
organizao por meio dos processos que esto sendo utilizados e mantidos
de forma alinhada s necessidades de negcio.
Neste trabalho foi apresentada a anlise de duas abordagens de
melhoria de processo de software, focando, principalmente, as atividades de
melhoria de cada uma delas. O ciclo de vida do ProImprove mostrou-se
bastante completo, sobretudo, porque oferece a automatizao de todo o
processo alm de oferecer, no seu fluxo, mecanismos onde se definem
mtricas para avaliar o esforo da melhoria. J nas fases da abordagem
PRO2PI, observa-se que, diferentemente do ProImprove, as revises, os
treinamentos e as apresentaes so feitas no decorrer do fluxo de
atividades e mostram-se desfavorecidos por no prover um processo
automatizado, nem uma configurao para validao das prticas. Apesar
disso, atravs dessa anlise, percebeu-se que funcionalmente as duas

50

propostas esto compatveis dentro do que eles focam em melhoria

contnua.
Espera-se ento, que o resultado deste trabalho seja utilizado como
base para outras pesquisas que compartilhem de objetivos semelhantes e
sirva de inspirao para o surgimento de novos elementos na anlise
comparativa.

5.2 TRABALHOS FUTUROS

Como proposio para a extenso deste trabalho, pode-se relacionar
atividades cujo interesse siga a linha de melhoria contnua do processo de
software, a saber: experimentao das duas propostas de melhorias
contnuas usando como base um cenrio nico para anlise dos resultados
obtidos e assim uma verificao comparativa mais direcionada a aplicao
das duas abordagens em um contexto real.

51

REFERNCIAS
[Ahern 01] Ahern D. M., Clouse A., e Turner R., CMMI Distilled: A Practical
Introduction to Integrated Process Improvement, SEI Series in Software
Engineering, Addison- Wesley, 2001.

[Arajo 98] Arajo, M. A. P., Automatizao do Processo de Desenvolvimento

de Software nos Ambientes Instanciados pela Estao TABA, Orientadora: Ana
Regina Rocha. Dissertao de Mestrado, COPPE/UFRJ, 1998.

[Basili 85] Basili, V. R., Quantitative Evaluation of Software Methodology,

Keynote Address, First Pan Pacific Computer Conference, Melbourne,
Australia, 1985.

[Basili 94] Basili, V. R., Kan, S.H. e Shapiro, L.N., Software Quality: An
Overview from the Total Quality Management Perspective, IBM Systems
Journal, 1994.

[Chrissis 03] Chrissis M. B., Konrad M. e Shrum S., CMMI: Guidelines for
Process Integration and Product Improvement, Addison-Wesley Pub Co,
2003.

[CMMI 02] CMMI Product Team, Capability Maturity Model Integration (CMMI)
for Software Engineering Version 1.1, Staged Representation, Carnegie
Mellon, USA, 2002.

52

[Correia 05] Correia, R.,

Avaliao (adaptao) do modelo IDEAL para um

ambiente de implementao de processo de software. Trabalho de concluso

da graduao em

Cincia da Computao,

Universidade

Federal

de

Pernambuco, 2005.

[Falbo 98] Falbo, R. A., Integrao de Conhecimento em um Ambiente de

Desenvolvimento de Software, Orientadora: Ana Regina Cavalcanti da Rocha.
Tese de Doutorado, COPPE/UFRJ, 1998.

[Florac 99] Florac e Carleton, Measuring the Software Process Statistical

Process Control for Software Process Improvement, 1999.

[Gomes 01] Gomes, Augusto G., Avaliao de Processos de Software baseada

em Medies, Orientadora: Ana Regina Rocha e Kthia Maral de Oliveira.
Dissertao de Mestrado, COPPE/UFRJ, 2001.

[Humphrey 89] Humphrey, Watts S., Managing the Software Process, The SEI
Series in Software Engineering. Addison-Wesley, 1989.

[ISO 97] NBR ISO/IEC 12207:1995, Tecnologia de Informao processos de

ciclo de vida de software. Associao Brasileira de Normas Tcnicas, 1997.

[ISO 98] ISO/IEC TR 15504, Information Technology software process

assessment. International Organization for Standardization, 1998.
53

[ISO 04] ISO/IEC 15504 - Information Technology - process assessment

Part 1: Concepts and Vocabulary, 2004.

[Machado 00] Machado, L. F. C., Santos, G., Oliveira, K. M. e Rocha, A. R.,

Def-Pro: Uma ferramenta para apoiar a definio do processos padro. XI
CITS Conferncia Internacional de Tecnologia de Software. Curtiba, PR,
2000.

[Mcfeeley 96] Mcfeeley, B., IDEALSM: A Users Guide for Software Process
Improvement. Software Engineering Institute Handbook. Carnegie Mellon
University. CMU/SEI-96-HB-001. 1996.

[Oliveira 05] Oliveira S. R. B. e Vasconcelos A. M. L., Proposta de um ambiente

de implementao de processo de software, Proposta de doutorado
submetida ao Centro de Informtica da Universidade Federal de Pernambuco,
Recife, PE, 2005.

[Oliveira 06a] Oliveira, S. R. B., Processo de software: princpios, ambientes e

mecanismos de execuo, Exame de qualificao do programa de doutorado
do CIn/UFPE, orientado pelo prof. Alexandre Vasconcelos, Recife, PE, 2006.

[Oliveira 06b] Oliveira, S. R. B., Vasconcelos, A. M. L. A Continuous

Improvement Model in ImPProS, Proceedings on COMPSAC Fast Abstract

54

Session - 30th Annual International Computer Software and Applications

Conference, Chicago, USA, 2006.

[Park 96] Park, R. E. & Goethert, W. B. & Florac, W. A., Goal-driven software
measurement A guidebook, Pittsburgh, PA, CMU/SEI-96-HB-002, Software
Engineering Institute, Carnegie Mellon University, 1996.

[Paulk 93] Paulk, M. C., Chrissis, M. B., Curtis, B. e Weber, C. V., Capability
Maturity Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR024. Software Engineering Institute - Carnegie Mellon University, 1993.

[Paulk 95] Paulk, M. C., Chrissis, M. B., Curtis, B. e Weber, C. V., The
Capability Maturity Model: Guidelines for Improving Software Process,
Addison Wesley, USA, 1995.

[Pressman 02] Pressman, R., Engenharia de Software, So Paulo: Makron

Books, 2002.

[Reis 98] Reis, C. A. L., Um Gerenciador de Processos de Software para o

Ambiente PROSOFT, Orientador Daltro Nunes. Dissertao de Mestrado.
PPGCUFRGS, 1998.

[Reis 03] Reis, C. A. L., Uma Abordagem Flexvel para Execuo de Processos
de Software Evolutivos, Orientador Daltro Nunes. Tese de Doutorado. PPGC
UFRGS, 2003.
55

[Rocha 01] Rocha, A. R. C. da, Maldonado, J. C. e Weber, K. C., Qualidade de

Software: Teoria e Prtica, Prentice Hall, So Paulo, 2001.

[Salviano 06] Salviano, C. F., Uma Proposta Orientada a Perfis de Capacidade

de Processo para Evoluo da Melhoria de Processo de Software, Exame de
qualificao do programa de doutorado da Faculdade de Engenharia Eltrica
e de Computao da Universidade Estadual de Campinas, orientado pelo
prof. Dr. Mario Jino, Campinas, SP, 2006.

[Softex 05] Softex - Sociedade para Promoo da Excelncia do Software

Brasileiro, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral,
verso 1.0, 2005.

[Sommerville 00] Sommerville, Ian, Software Engineering, 6th edition,

Addison-Wesley, 2000.

56

GLOSSRIO
Ciclo

de

vida.

Conjunto

das

atividades

que

ocorrem

durante

desenvolvimento de um software.

CMM (Capability Maturity Model). Um modelo de maturidade dos processos

organizacionais. uma iniciativa do SEI ( Software Engineering Institute); um
modelo para avaliar e certificar a maturidade dos processos de uma
organizao que desenvolve software. Em general, se aplica principalmente
em grandes empresas de software.

CMMI (Capability Maturity Model Integration). uma evoluo do CMM e

procura estabelecer um nico modelo para o processo de melhoria
corporativo, integrando diferentes modelos e disciplinas.

ISO

(International

Standard

Organization).

Organizao

de

Padres

Internacionais. Normaliza diversas caractersticas de processos e produtos no

domnio do software ou de outros domnios. Por exemplo, normas sobre as
caractersticas

de

qualidade

do

produto

de

software

se

encontram

especificadas no padro 9126; para o processo de avaliao de qualidade de

produtos, no padro 14598; para a avaliao dos processos de ciclo de vida
do software, no padro 12207; etc.

57

Requisito. Uma necessidade ou desejo do usurio, explcito ou implcito, que

se traduz em atributos, caractersticas ou funes necessrias de um
software.

SEI (Software Engineering Institute). Centro de pesquisa e desenvolvimento

federal patrocinado pelo Departamento de Defesa dos Estados Unidos e
operado pela Carnegie Mellon University.

58

APNDICE A
Uma viso geral da utilizao da abordagem PRO2PI apresentada a
seguir por meio de quatro funes. O diagrama com a funo de definio,
ou atualizao, de PRO2PI apresentado na Figura A-1.

Figura A-1: Diagrama da definio de PRO2PI [Salviano 06]

De incio, uma organizao seleciona elementos de um ou mais

modelos de referncias para definir um perfil de capacidade de processo que
represente os elementos selecionados desses modelos e de qualquer outra
fonte. Buscando evoluir os processos para atender a esse perfil um ciclo de
melhoria de processo realizado. Esse perfil ajustado com o contexto e
objetivos estratgicos da organizao e da unidade organizacional. Segundo
[Salviano 06] o perfil pode conter boas prticas de referncia selecionadas

59

dos modelos mais genricos existentes e de outras fontes, de forma a

representar orientaes relevantes organizao.
A qualquer momento em funo de novas percepes, alteraes do
contexto ou dos objetivos estratgicos e dos resultados da utilizao da
verso corrente o perfil pode ser alterado. Esse uso representado pela
funo defineP (define, ou atualiza, perfil de capacidade de processo) da
Figura A-1.
O diagrama com a funo de utilizao de PRO2PI apresentado na
Figura A-2 como um acrscimo em relao Figura A-1.

Figura A-2: Diagrama da utilizao (e definio) de PRO2PI [Salviano 06]

[Salviano 06] define a funo usaP (usa perfil de capacidade de

processo) da Figura A-2 como responsvel pelo uso desse perfil para
orientar as aes de melhoria. Neste caso as aes de melhoria devem ser
suficientes para que o processo resultante atenda a todos os requisitos
60

representados no perfil de capacidade de processo e apenas a estes

requisitos.
O diagrama com a funo de avaliao de capacidade de processo em
relao a um PRO2PI apresentado na Figura A-3 como um acrscimo em
relao Figura A-2.
O processo da unidade organizacional pode ser examinado com uma
avaliao de capacidade de processo em relao ao perfil de capacidade de
processo. Esse

exame

representado pela

funo avaliaPr (avalia

capacidade de processo em relao a um PRO2PI). Observe a Figura A-3. Os

resultados de capacidade de processo gerados por essa avaliao podem ser
utilizados como referncias adicionais para a definio, ou alterao, do
perfil de capacidade de processo [Salviano 06].
O diagrama com a funo de definio de modelos de capacidade de
processo mais especficos com a abordagem PRO2PI apresentado na Figura
A-5.
Um modelo mais especfico pode ser definido a partir do contexto de
negcio de um segmento qualquer, como, por exemplo, o segmento
bancrio, ou de um domnio, como, por exemplo, engenharia de requisitos.
Esse modelo pode ser composto por reas de processo ou perfis de
capacidade de processo mais especficos para um segmento ou domnio.

61

Figura A-3: Diagrama da avaliao de processo (e definio e utilizao de PRO2PI) [Salviano

06]

Figura A-4: Diagrama da definio de modelos mais especficos [Salviano 06]

62

Esse modelo mais especfico, diz [Salviano 06], pode conter boas
prticas selecionadas dos modelos de capacidade de processo, modelos de
outros tipos ou de qualquer outra fonte de forma a representar orientaes
relevantes no segmento ou domnio. A funo defineM (define, ou atualiza,
modelo mais especifico de capacidade de processo) da Figura A-5 que
representa esse uso.
Um modelo mais especfico pode ser que qualquer uma das trs
geraes de arquiteturas de modelo de capacidade de processo. Para
[Salviano 06] caso seja um modelo estagiado fixo, ele ser composto por
uma hierarquia de perfis de capacidade de processo, como, por exemplo, a
hierarquia do modelo PMMM (Project Management Maturity Model, Modelo de
Maturidade da Gerncia de Projeto) para o domnio de gerncia de projeto e
do modelo KMMM (Knowledge Management Maturity Model, Modelo de
Maturidade de Gerncia de Conhecimento) para o domnio de gerncia de
conhecimento. Caso seja um modelo contnuo fechado, ele ser composto
por um conjunto de reas de processo, como, por exemplo, as reas de
processo do modelo Automotive SPICE para o segmento de fornecedores de
software para automveis e as do modelo OOSPICE para o domnio de
desenvolvimento de software orientado a componentes.
Esses modelos podem ter sugestes de hierarquia de perfis de
capacidade de processo. Caso seja um modelo contnuo aberto, ele ser
composto de especializaes dos nveis de capacidade de processo.
A Figura A-5 de [Salviano 06] representa um diagrama esquemtico
completo da utilizao da abordagem PRO2PI para desenvolvimento de
modelos mais especficos e para realizao de aes de melhoria dirigida por
63

perfil de capacidade de processo. Essa utilizao realizada por meio das

quatro funes: defineM, defineP, usaP e avaliaPr. No existe uma ordem
pr-definida de utilizao destas funes. Elas podem ser utilizadas vrias
vezes cada uma independente da execuo das outras funes.
Na abordagem PRO2PI existe uma busca contnua em direo ao
alinhamento do perfil de capacidade de processo como uma representao,
segundo o aspecto de capacidade de processo, do processo da unidade
organizacional.
Conforme representado na Figura A-5 uma melhoria de processo com
a abordagem PRO2PI realizada com a definio e utilizao de um PRO2PI
que pode conter boas prticas selecionadas dos modelos de capacidade de
processo, modelos de outros tipos, modelos mais especficos de um
segmento ou domnio ou de qualquer outra fonte.
Essa utilizao da abordagem PRO2PI pode ser considerada como
anloga utilizao da engenharia de requisitos no desenvolvimento de
software, que podemos denominar de desenvolvimento de software dirigido
por requisitos. A Figura A-6 apresenta um diagrama da utilizao da
engenharia de requisitos para desenvolvimento de software de forma anloga
ao diagrama de utilizao de PRO2PI descrito na Figura A-5.

64

Figura A-5: Diagrama da abordagem PRO2PI para modelos e melhoria de processo [Salviano
06]

Figura A-6: Diagrama, anlogo ao de PRO2PI, do desenvolvimento de software [Salviano 06]

65

Uma forma hipottica de desenvolvimento de software seria fazer esse

desenvolvimento baseado em conjuntos de necessidades, restries e
requisitos de diferentes stakeholders, sem sistematizar esses conjuntos em
um nico conjunto de requisitos. Essa forma hipottica porque no
utilizada,

ou

no

deveria

ser

utilizada,

em

praticamente

nenhum

desenvolvimento de software.
O diagrama da Figura A-6 representa uma forma de desenvolvimento
de software que mais utilizada atualmente, para a qual os conjuntos de
necessidades, restries e requisitos dos diferentes stakeholders so
analisados e representados como um sistema em um nico conjunto de
requisitos para o software [Salviano 06]. Desta forma o software tem tudo
que os requisitos requisitam e somente o que os requisitos requisitam. Nesta
forma de desenvolvimento, a funo defineR (define requisitos) seria
utilizada para definir, ou atualizar, o conjunto de requisitos, a funo usaRS
(usa requisitos de software) seria utilizada para orientar as aes de
implementao do software de forma que isto seja dirigida pelos requisitos e
a funo testaSw (testa software) seria utilizada para buscar problemas no
software e com isto sugerir o quanto o software desenvolvido atende aos
requisitos [Salviano 06].
O desenvolvimento de requisitos para uma linha de produto de
software, de tal forma que esses requisitos sejam um sistema representado
pela funo defineRLPS (define requisitos de linha de produto de
software), sendo que os requisitos foram baseados em diferentes conjuntos
de requisitos, de diferentes stakeholders. Para [Salviano 06] esta forma de

66

desenvolvimento de requisitos anloga forma de desenvolvimento de

modelos mais especficos representada na Figura A-5.
Segundo [Slaviano 06] o diagrama da Figura A-6 representa a
integrao da forma de desenvolvimento de requisitos para um framework de
produtos de software e da forma de desenvolvimento de software dirigida a
requisitos de software, de tal forma que esses requisitos sejam um sistema,
sendo que os requisitos foram baseados em diferentes conjuntos de
requisitos, de diferentes stakeholders, e em requisitos de um framework de
software. Esta forma de desenvolvimento de requisitos anloga forma de
desenvolvimento de modelos e realizao de melhoria de processo
representada na Figura A-5.

67

APNDICE B
A Tabela B-1 abaixo descreve as prticas base para o estabelecimento de Perfil de Capacidade de Processo que
tem como propsito definir, utilizar, manter e melhorar um perfil de capacidade de processo como abstrao do
processo atual ou idealizado para uma unidade organizacional.

68

Prticas Base

Definio

1 Analisar objetivos (estratgicos) de

Identificar e analisar os objetivos, estratgia, contexto e/ou qualquer outro aspecto relevante de

negcio

negcio da unidade organizacional e da organizao, para subsidiar e orientar a definio dos

objetivos de melhoria.

2 Identificar objetivos da melhoria

Identificar os objetivos da melhoria, incluindo objetivos mais especficos para o prximo ciclo de
melhoria e objetivos mais gerais para o programa de melhoria, sempre alinhado aos objetivos,
estratgia, contexto e/ou qualquer outro aspecto relevante de negcio identificados.

3 Estabelecer critrios de qualidade

Estabelecer critrios de qualidade para avaliar e melhorar um perfil de capacidade de processo.

para perfil
4 Identificar modelos de capacidade

Identificar modelos de capacidade de processo que sejam relevantes para a organizao, e selecionar

e reas de processo

reas de processo desses modelos e, caso necessrio, definir novas reas de processo, que sejam
relevantes para o processo atual e sua melhoria.

5 Definir ou selecionar um perfil

Definir, selecionar e/ou adaptar um perfil de capacidade de processo com reas de processo
selecionadas e/ou definidas, de forma que esse perfil esteja alinhado aos objetivos de melhoria.

6 Utilizar perfil para entendimento

Utilizar o perfil de capacidade de processo definido para orientar o entendimento dos processos

dos processos

correntes da unidade organizacional.

7 Utilizar perfil para a melhoria

Utilizar o perfil de capacidade de processo definido e os resultados do entendimento dos processos

correntes, para orientar as aes de melhoria dos processos da unidade organizacional.

8 Analisar perfil definido

Analisar o perfil de capacidade de processo definido segundo os critrios de qualidade estabelecidos,

quando necessrio, como, por exemplo, em marcos definidos do ciclo de melhoria, em eventos ou
periodicamente.

9 Ajustar o perfil definido

Ajustar o perfil de capacidade de processo definido segundo resultados de anlise do perfil.

10 Monitorar o perfil definido

Monitorar o perfil de capacidade de processo definido em relao aos objetivos estratgicos para
identificar possveis desvios no alinhamento entre o perfil e os objetivos estratgicos.

11 Atualizar perfil definido

Atualizar o perfil de capacidade de processo definido sempre que o monitoramento identificar desvios
significativos no alinhamento entre o perfil e os objetivos estratgicos, de forma que este alinhamento
seja mantido.

12 Buscar correspondncia entre

Buscar, por meio de ajustes no perfil e/ou aes de melhoria, a correspondncia entre o perfil de

perfil e processo

capacidade de processo definido e o processo da unidade organizacional.

Tabela B-1: Prticas base para o estabelecimento de Perfil de Capacidade de Processo
69

APNDICE C
Fases do PRO2PI
Inicia

ciclo

de

melhoria

Atividades do PRO2PI

Atividades do ProImprove

Levantamento de informaes gerais sobre a empresa, incluindo o contexto e

Cadastrar Razo

objetivos estratgicos, metodologias existentes, tecnologias e projetos existentes

Definir Contexto
Construir Apoio
Alocar infra-estrutura

Definio das Metas de Melhoria

Caracterizar estados

Definio do Perfil de Capacidade de Processo

Base do ImPProS (Definio)

Reviso e detalhamento do Programa de Melhoria de Processo

Definio do Plano Preliminar da Avaliao das Prticas Correntes
Avalia

prticas

correntes

Reviso do Plano da Avaliao das Prticas Correntes

No se Aplica ao ProImprove
Base do ImPProS (Avaliao)
Base do ImPProS (Avaliao)

Treinamento da equipe de avaliao sobre o processo da avaliao

No se Aplica ao ProImprove

Adaptao das prticas de referncia para a avaliao

Configurando Questes para

Validao das Prticas

Levantamento e validao de dados para a avaliao dos projetos e processos

Configurando anlise das

selecionados

Questes

Derivao e elaborao dos resultados da avaliao

Analisando e Validando a
Execuo da Sub-melhoria
Analisando Questes de
Validao da Prtica

Apresentao dos resultados da avaliao

Inferindo Questes de Execuo

da Sub-melhoria
Sugerindo Resultado de
Validao da Prtica

Reviso do perfil de capacidade de processo

Planeja aes de

Treinamento de pessoas selecionadas sobre o processo de planejamento da melhoria

melhoria

e elementos para sua implantao

Definio da estratgia para implantao da melhoria

Base do ImPProS (Definio)

No se Aplica ao ProImprove
Definir Procedimentos
Desenvolver estratgias

70

Definio das aes de melhoria

Planejar aes

Elaborao do Plano de Melhoria de Processo

Definio das responsabilidades e necessidades de compromissos
Elaborao do Plano de Preparao da Organizao

Criar soluo

Reviso do Plano de Melhoria de Processo por pessoas selecionadas

Planejar aes

Estabelecimento das responsabilidades para execuo do Plano de Melhoria de

Alocar Infra-estrutura

processo, incluindo as funes de gerente, grupo de processo e grupos de

implementao de processo
Estabelecimento dos compromissos para execuo do Plano
Atividades para consolidao de planejamento

Planejar aes

Reviso das atividades e resultados da sub-fase anterior

Atualizao do Plano
Treinamento de pessoas selecionadas sobre elementos para implantao do Plano

No se Aplica ao

Apresentao para incio da implantao das aes de melhoria

No se Aplica ao

Realiza aes de

Realizar atividades descritas no Plano

Testar soluo

melhoria

Monitorar as atividades conforme o Plano

Refinar soluo

ProImprove
ProImprove

Revisar o plano e realizar aes corretivas

Prepara

Reviso do resultado da melhoria

institucionalizao

Elaborao do Plano de institucionalizao

da melhoria
Institucionaliza
melhoria

Implantar soluo

Realizar atividades descritas no Plano de Institucionalizao

Monitorar as atividades conforme o Plano de Institucionalizao

Analisar e validar

Revisar o plano de Institucionalizao e realizar aes corretivas

Propor Aes Futuras

Tabela C-1: Tabela comparativa entre as atividades do PRO2PI e do ProImprove

71