Você está na página 1de 88

1

UNIVERSIDADE FEDERAL DE SANTA CATARINA










Implantao do MPS.BR Nvel G







Autor: Thais Oliveira Bergmann
Florianpolis
2008/1

2
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLGICO
DEPARTAMENTO DE INFORMTICA E ESTATSTICA
CURSO DE SISTEMAS DE INFORMAO






Implantao do MPS.BR Nvel G
Thais Oliveira Bergmann


Trabalho de concluso de curso apresentado
como parte dos requisitos para obteno do
grau de Bacharel em Sistemas de Informao





Florianpolis - SC
2008/1

3
Thais Oliveira Bergmann
Implantao do MPS.BR Nvel G
Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do
grau de Bacharel em Sistemas de Informao.

Orientador:

_______________________________________
Prof, Roberto C. S. Pacheco

Banca examinadora:

_______________________________________
Professor J os Salm J r.

_______________________________________
Professor Nikolai Dimitri

4

















Dedicatria
Dedico este trabalho aos
meus pais, in memoriam.

5
Agradecimentos

Agradeo ao Marcos pela compreenso e pacincia, minha famlia e a todos que
estiveram de alguma forma presentes e me apoiaram nesta caminhada. Agradeo
tambm Ilog Tecnologia, empresa onde este trabalho foi desenvolvido e ao professor
J oo Bosco da Motta Alves, pelas conversas orientadoras no comeo do curso.
LISTA DE FIGURAS
Figura 1 - Estrutura da Norma ISO/IEC 12207 .........................................................19
Figura 2 - Modelo de Ciclo de Vida em Cascata........................................................20
Figura 3 - Modelo de Ciclo de Vida Incremental ......................................................21
Figura 4 - Modelo de Ciclo de Vida Iterativo.............................................................22
Figura 5 - Modelo de Ciclo de Vida em Espiral ........................................................23
Figura 6 - Modelo de Ciclo de Vida Espiral...............................................................24
Figura 7 - Modelo V ...................................................................................................25
Figure 8 Nveis de Classificao dos Processos ISO/IEC 15504............................28
Figura 9 - Estrutura da norma ISO/IEC 15504...........................................................29
Figura 10 - Estrutura da Documentao do MPS.BR ................................................34
Figura 11 - Organograma Ilog Fonte Ilog ...............................................................43
Figura 12 - Processo de Fornecimento.......................................................................48
Figura 13 - Template Checklist Aceitao de Requisitos...........................................53
Figura 14 - Template para Estimativas de Esforo.....................................................54
Figura 15 - Processo de Planejamento de Projeto......................................................56
Figura 16 - Template para Plano de Gerncia de Dados............................................57
Figura 17 - Template para Plano de Comunicao Organizacional ...........................58
Figura 18 - Template para Descrio de Papis.........................................................65
Figura 19 - Template para Mapa de Habilidades e Competncias.............................65
Figura 20 - Template para Ata de Reunio de Comprometimento.............................67
Figura 21 - Processo de Gerncia de Mudana de Requisitos....................................69
Figura 22 - Template para Requisio de Mudana de Requisitos............................72
Figura 23 - Processo de Monitorao de Projetos.....................................................75
Figura 24 - Estrutura de Dados de Desenvolvimento de Processo.............................81
Figura 25 - Relatrio de Alocao de Recursos ........................................................82


7
Lista de Tabelas

Tabela 1 Vantagens de desvantagens dos modelos de ciclo de vida....................................26
Tabela 2 - Comparao entre nveis de maturidade e nveis capacidade...............................30
Tabela 3 - Comparao entre nveis de maturidade CMMI e MPS.BR................................ 33
Tabela 4 - Estrutura de processos e nveis do MPS.BR.........................................................37

8
Lista de Redues

MPS.BR Melhoria de Processo do Software Brasileiro
CMMI - Capability Maturity Model Integration
SEI Software Engineering Institute
AP Atributo de Processo
RAP Resultados de Atributo de Processo
GRE Resultado Esperado para o Processo de Gerncia de Requisitos
GPR Resultado Esperado para o Processo de Gerncia de Projetos
EAD Ensino a Distncia
ACATE Associao Catarinense de Empresas de Tecnologia
PERT - Program Evaluation and Review Technique
WBS - Work Breakdown Structure
ISO International Organization for Standardization

9
Sumrio
1 Introduo............................................................................................................12
1.1 Apresentao..............................................................................................12
1.2 Objetivo Geral ............................................................................................12
1.3 Objetivos Especficos.................................................................................12
1.4 Motivao...................................................................................................13
1.5 J ustificativa.................................................................................................13
1.6 Organizao deste documento....................................................................14
2 Engenharia de Software.......................................................................................14
2.1 O que software.........................................................................................14
2.2 Crise do Software.......................................................................................15
2.3 ISO/IEC 12207 Processos do Ciclo de Vida do Software......................16
2.3.1 Processo Fundamental................................................................................17
2.3.2 Processo Organizacional ............................................................................17
2.3.3 Processo de Apoio......................................................................................18
2.3.4 Modelos de Ciclo de Vida.....................................................................19
2.3.4.1 Modelo de Ciclo de Vida Cascata.....................................................19
2.3.4.2 Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3]........20
2.3.4.3 Modelos de Ciclo de Vida Evolucionrio.........................................23
2.3.4.4 Modelos de Ciclo de Vida V.............................................................24
2.3.5 Vantagens e Desvantagens dos Modelos de Ciclo de Vida...................25
3 Padres de Qualidade de Processo de Software..................................................26
3.1 ISO/IEC 15504 Avaliao do Processo de Software..............................26
3.2 CMMI [10]................................................................................................29
3.2.1 Abordagem Contnua.................................................................................31
3.3 MPS.BR Melhoria de Processo do Software Brasileiro..........................32
3.3.1 Guias e Documentao MPS.BR...............................................................34
3.3.2 Conceitos Importantes no MPS.BR...........................................................35
3.3.3 Nveis de Maturidade no MPS.BR.............................................................36
3.3.4 Processo......................................................................................................36
3.3.5 Estrutura de Processos e Nveis do MPS.BR.............................................37
4 Implantao do MPS.BR na Ilog Tecnologia......................................................43
4.1 Ilog Tecnologia..........................................................................................43
4.2 Atividades para Implantao do MPS.BR..................................................44
4.2.1 Primeira Atividade - Conscientizao........................................................44

10
4.2.2 Segunda Atividade Diagnosticao da Situao Atual ...........................44
4.2.3 Terceira Atividade Treinamento.............................................................45
4.2.4 Quarta Atividade Mapeamento dos Processos........................................45
4.2.5 Quinta Atividade Detalhamento dos Processos Mapeados.....................45
4.2.6 Sexta Atividade Treinamento do Processo Organizacional ....................46
4.2.7 Stima Atividade Avaliao Interna nos Projetos da Empresa...............46
4.2.8 Oitava Atividade Simulados....................................................................46
4.3 Preparao para Avaliao Oficial .............................................................46
4.3.1 Descrio dos Processos.............................................................................47
4.3.2 Processo de Fornecimento.....................................................................47
4.3.3 Planejamento do Projeto........................................................................55
4.3.4 Encerrar o Projeto..................................................................................67
4.3.5 Gerncia de Mudanas de Requisitos....................................................68
4.3.6 Monitorao do Projeto.........................................................................74
4.3.7 Atributos de Processo............................................................................78
4.4 Avaliao....................................................................................................80
4.5 Ferramentas Utilizadas...............................................................................80
4.5.1 Eclipse Process Framework EPF................................................................80
4.5.2 J ExpChannel...............................................................................................81
4.5.3 SVN............................................................................................................82
4.5.4 Pacote Microsoft Office.............................................................................82
4.5.5 Enterprise Architect....................................................................................83
5 Concluses...........................................................................................................84
5.1 Trabalhos Futuros.......................................................................................85

11
Resumo
Este trabalho relata a implantao do MPS.BR nvel G na empresa
Ilog Tecnologia. Alm disso, revisa os principais conceitos de
engenharia de software e padres de qualidade de processo de software
como a ISO/IEC 15504, CMMI e MPS.BR.

Abstract
This document describes the deployment of MPS.BR level G at
Ilog Technology company. Moreover, it reviews the main concepts
about software engineering and quality standard of software process as
ISO/IEC 15504, CMMI and MPS.BR.

E palavras-chave: ISO/IEC 12207, ISO/IEC 15504, MPS.BR, CMMI, Engenharia de
Software e Melhoria de Software.

12

1 Introduo
1.1 Apresentao
O desenvolvimento de software est entre as mais promissoras atividades realizadas
em Santa Catarina. Estimam-se 1500 empresas de Tecnologia em Santa Catarina, cujo
faturamento de 1 bilho de reais
1
. Nesse contexto pode ser percebida a importncia de
se ter um processo de desenvolvimento de software para que a produo seja
potencializada no estado e conseqentemente no pas. Dentre os principais fatores
limitadores do crescimento das empresas de desenvolvimento de software est o caos em
que essas operam, na maioria das vezes. Freqentemente essas empresas at tem
processos informais de desenvolvimento que so abandonados sempre que ocorre algum
problema como, por exemplo, atraso no cronograma ou mudana de prioridade do projeto
na empresa. Para esse contexto foi criado o MPS.BR, que o programa de melhoria de
processos de software.
O MPS.BR mais adequado a realidade brasileira se comparada ao CMMI por
exemplo. Uma vez que dividido em sete nveis, equivalentes ao CMMI, porm mais
adequado a realidade das empresas de micro e pequeno porte, que podem implantar o
modelo em etapas menores. Alm disso, o MPS.BR custa em torno de quatro vezes
menos que a certificao CMMI.
O MPS.BR coordenado pela Associao para Promoo da Excelncia do Software
Brasileiro, a Softex, que vem realizando esforos para obter o reconhecimento
internacional do MPS.BR como garantia de qualidade, uma vez que um modelo
equivalente ao CMMI.
1.2 Objetivo Geral
Implantar o MPS.BR nvel G na empresa Ilog Tecnologia.
1.3 Objetivos Especficos
Estudar o MPS.BR;
Mapear os processos necessrios para a implantao do MPS.BR nvel G;
1 Mercado Brasileiro de Software - Panorama e Tendncias - Abes 2008


13
Institucionalizar, ou seja, descrever e implantar, os processos de gerncia de
projetos e gerncia de requisitos, requeridos para obter o nvel G do MPS.BR;
Realizar simulados de avaliao do MPS.BR;
Obter o nvel G do MPS.BR;
1.4 Motivao
A falta de metodologia para desenvolvimento de software certamente o principal
fator de fracasso nos projetos de desenvolvimento de software em pequenas e micro
empresas. Na maioria das vezes, o projeto tem um dono na empresa, que diz o que deve
ser feito. Porm se o dono do projeto for substitudo o projeto ser executado de uma
forma diferente. A execuo das atividades dos projetos acontece de forma catica, com o
cronograma apertado, muitas vezes impossvel para ser mantido mas que foi imposto pelo
cliente. Freqentemente o software resultante desses projetos tem baixa qualidade, difcil
manuteno e nenhuma documentao.
A motivao mostrar que possvel uma micro empresa seguir uma metodologia
de desenvolvimento de software, que produza um produto com qualidade levando em
conta as caractersticas de uma micro empresa.
1.5 Justificativa
Haja vista o imenso potencial brasileiro no mercado de software, produzir um
produto com qualidade e com preos acessveis so caractersticas imprescindveis para
manter-se competitivo neste mercado. Estas caractersticas: qualidade e competitividade
podem ser obtidas desde que a empresa adote uma metodologia de desenvolvimento de
software que a permita detectar oportunidades de melhorias e pontos fortes do seu
processo.
A razo para adotar uma metodologia conhecida como o CMMI ou MPS.BR que
essas metodologias j se mostraram eficientes, o que reduz o tempo de implantao de
um processo para desenvolvimento de software.
Alm da qualidade e competitividade, seguir uma metodologia conhecida um
diferencial competitivo em relao a empresas que seguem metodologias prprias, que
no so conhecidas ou que no tem metodologias/processos.

14
1.6 Organizao deste documento
Este trabalho est organizado em 5 captulos.
O primeiro captulo traz a introduo ao contedo a ser apresentado neste documento,
como a apresentao do tema, o objetivo geral, os objetivos especficos, motivao e
justificativa.
O segundo captulo traz informaes sobre a Engenharia de Software e Ciclo de Vida do
Software, assuntos introdutrios para melhor entendimento dos demais temas abordados
neste documento.
O terceiro captulo discorre sobre os principais padres de qualidade para processo de
desenvolvimento de software.
No quarto relatado como ocorreu a implantao do MPS.BR na Ilog Tecnologia.
O quinto captulo traz as concluses obtidas a partir deste trabalho assim como os
trabalhos futuros.
2 Engenharia de Software
2.1 O que software
Software : (1) Instrues (programas de computador) que quando executadas,
produzem a funo e o desempenho desejados; (2) estruturas de dados que permitem que
os programas manipulem adequadamente a informao; e (3) documentos que
descrevem a operao e ouso dos programas. Pressman, 1995.
Segundo Pressman, para entender o que software necessrio que sejam verificadas
as caractersticas que o difere de outros produtos criados pelo homem. O software como
sendo o resultado de um sistema lgico, no toma forma fsica quando pronto como o caso
do hardware, por exemplo. As principais caractersticas que diferem o software dos demais
produtos so as seguintes: O software desenvolvido por engenharia: Assim como os
demais produtos manufaturados, o software precisa ser projetado. A diferena est na forma
de construo deste uma vez que no fsico no trivial saber exatamente o que se tem
pronto ou quanto ainda falta para finaliz-lo. Enfim, uma das grandes dificuldades na
construo do software para obter as mtricas do projeto. O software no se desgasta:
Diferente dos demais produtos produzidos pelo homem, o software no desgasta com o
passar do tempo. Porm, ainda segundo Pressman, o software deteriora, pois ao longo da
vida o software sofre modificaes que so como pontos de insero de defeitos, o

15
que ao passar do tempo aumenta o nmero de falhas que o software poder apresentar. A
maioria dos softwares feita sob medida: Na maioria das vezes a construo de um software
parte do zero, ou seja, no existem componentes que simplesmente combinados formam o
software.
2.2 Crise do Software
No incio dos anos 80 a crise do software atraiu a ateno das empresas e governo
americano. Nessa poca o congresso americano verificou o impacto que a tecnologia tinha
sobre a economia americana e na competitividade global dos Estados Unidos. O congresso
verificou que o impacto da desordem vivida na poca seria desastroso uma vez que a
tecnologia dava forma ao futuro. A concluso foi de que a melhor forma de se ter um futuro
em ordem seria organizar o presente.
A maior causa da crise do software que as mquinas tornaram-se vrias ordens de
magnitude mais potentes! Em termos diretos, enquanto no havia mquinas, programar
no era um problema; quando tivemos computadores fracos, isso se tornou um problema
pequeno e agora que temos computadores gigantescos, programar tornou-se um
problema gigantesco.
Edsger Dijkstra na sua apresentao The Humble Programmer,
Em 1984, o congresso americano fundou uma organizao chamada Software
Engineering Instituite (SEI), com uma equipe formada pelos mais importantes centros de
pesquisa sobre o assunto nos EUA. Essa equipe ficou hospedada na Universidade Carnegie-
Mellon em Pittsburgh. O objetivo do SEI trabalhar para estabelecer normas e metodologias
no campo de desenvolvimento de software para ajudar a Amrica a manter a
competitividade frente aos esforos tecnolgicos no mundo. O SEI cumpriria esse objetivo
atravs de programas de pesquisa, treinamentos e desenvolvimento profissional [11]. A
primeira definio de engenharia de software foi proposta por Fritz Bauer em 1969, que a
seguinte:
O estabelecimento e uso de slidos princpios de engenharia para que se possa obter
economicamente um software que seja confivel e que funcione eficientemente em
mquinas reais.
Segundo Pressman (1995), a engenharia de software deriva da engenharia de
sistemas e de hardware, e que abrange um conjunto de trs elementos fundamentais que
possibilitam o controle do processo de desenvolvimento de software e oferecem

16
uma base para a construo de software de alta qualidade, produtivamente. Os trs
elementos fundamentais da engenharia de software, tambm chamados como Paradigmas da
Engenharia de Software, so:
Mtodos: Proporcionam orientaes sobre como construir o software;
Ferramentas de Engenharia de Software: automatizam os mtodos para
construo de software;
Processos de Engenharia de Software: que formam a ligao entre mtodos e
ferramentas para que o software seja construdo.
Ainda segundo Pressman, esses trs elementos fundamentais passam por trs fases
genricas, a saber:
Definio: identificar a funo do software a ser desenvolvido. Nessa fase
acontecem a anlise de requisitos e anlise e projeto do software.
Desenvolvimento: executa o que foi planejado, nessa fase ocorrem os testes e
codificao do software.
Manuteno: correes, adaptao e melhorias no software.
2.3 ISO/IEC 12207 Processos do Ciclo de Vida do Software
A ISO/IEC 12207 Standard for Information TechnologySoftware life cycle process
guia como estruturar e gerenciar o todo ciclo de desenvolvimento de software,
proporcionando assim a viso geral de todo o processo. Essa norma contm um conjunto de
processos, atividade e tarefas que podem ser adaptadas a cada tipo de projeto de software.
Esse conjunto de processos, atividades e tarefas cobrem o software desde a sua criao
at sua aposentaria.
Ciclo de vida a estrutura que contm processos, atividades e tarefas envolvidas no
desenvolvimento, operao e manuteno de um produto de software, abrangendo a vida
do sistema desde a definio de seus requisitos at o trmino de seu uso.
NBR ISO/IEC 12207
Uma passagem completa por quatro fases: concepo, elaborao, construo e
transio. O espao de tempo entre o incio da fase de concepo e o final de transio.
IBM/Rational, Glossrio do RUP
A norma ISO/IEC 12207, crida em 1995 revisada em 2002 e 2004 estabelece um

17
framework padro para definio do ciclo de vida de software. O objetivo da ISO/IEC 12207
que cliente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e desenvolvedores
utilizem a mesma estrutura de processos, com terminologias bem definidas, que podem ser
referenciadas pela indstria de software. Para isso foram definidos trs macro processos: o
processo fundamental, processo organizacional e processo de apoio. [1]
2.3.1 Processo Fundamental
O processo fundamental contempla a contratao, desenvolvimento, operao e
manuteno dos produtos de software ao longo do ciclo de vida do software.
O processo Fundamental abrange as atividades de aquisio, fornecimento,
desenvolvimento, operao e manuteno [1].
Aquisio: atividades para contratar a organizao que
desenvolveu o sistema, software ou servio.
Fornecimento: atividades dos fornecedores, da organizao
que provem o sistema ou o servio que precisa ser adquirido.
Desenvolvimento: papis e atividades para desenvolvimento
do software.
Operao: atividades para operao do produto de software e
suporte operacional aos usurios;
Manuteno: atividades de manuteno do software. Isso
inclui a gesto de mudanas, migrao e fim do ciclo de vida do software.
2.3.2 Processo Organizacional
O processo organizacional auxilia o desenvolvimento de processos, produtos e
recursos a serem utilizados nos projetos para que a organizao atinja seus objetivos de
negcio. No processo organizacional, encontram-se as seguintes atividades: gesto, infra-
estrutura e recursos, melhoria e treinamento.
Gesto: atividades bsicas de gesto, incluindo gesto de projetos
relacionada ao ciclo de vida do software.
Infra-estrutura e Recursos: os recursos e infra-estrutura para os processos
realizados pela organizao ao longo do ciclo de vida do software.

18
Melhoria: atividades bsicas que a organizao necessita para controlar,
medir e melhorar seu processo de ciclo de vida do software.
Treinamento: define as atividades para prover um treinamento adequado.
2.3.3 Processo de Apoio
O processo de apoio auxilia e contribui para o sucesso e qualidade dos outros
processos envolvidos no ciclo de vida do software. No processo de Apoio encontram-se
as seguintes atividades [1]: documentao, gesto de configurao, garantia da qualidade,
verificao, validao, auditoria e resoluo de problemas.
Documentao: atividades para registrar as informaes produzidas ao
longo do ciclo de vida do software.
Gesto de Configurao: define as atividades de gesto de configurao.
Garantia da Qualidade: atividades objetivamente para garantir que o
software produzido est de acordo com as especificaes de requisitos e
aderente aos planos estabelecidos. As tcnicas de revises compartilhadas,
auditorias, verificao e validao podem ser usadas para garantia da
qualidade.
Verificao: atividades para verificao do software e servios em
diferentes profundidades de acordo com o projeto do software.
Validao: atividades para validao do software de acordo com o projeto
do software.
Auditoria: atividade para determinao da conformidade com os requisitos,
planos e contrato. Este processo pode ser empregado pela equipe auditora e
equipe auditada.
Resoluo de Problemas: processo de anlise e remoo dos problemas,
inclusive no-conformidades, independente da causa raiz, descobertos
durante a execuo dos processos ao longo do ciclo de vida do software.
Abaixo est a ilustrao de como est estruturada a norma ISO/IEC 12207:

19

Figura 1 Estrutura da Norma ISO/IEC 12207 Fonte: NBR ISO/IEC 12207
2.3.4 Modelos de Ciclo de Vida
O modelo de ciclo de vida do software consiste de todas as atividades desde a
criao at a aposentadoria deste. A escolha do modelo de ciclo de vida uma das mais
influentes decises para o sucesso do projeto em questo, pois se adequada contribui para
que o processo de desenvolvimento do software seja eficiente, seja obtido um produto com
mais qualidade alm de minimizar os riscos inerentes ao processo. Assim como a escolha de
um modelo de ciclo de vida inadequado ou a falta de um pode fazer que haja muito
atividades desnecessrias e frustrao ao longo do ciclo de vida do software. [31]
2.3.4.1 Modelo de Ciclo de Vida Cascata
Ainda que largamente desprezado como ineficiente, o modelo cascata o mais
antigo e usado at hoje. Pois fcil para ser entendido, explicado e demonstrado. Para
projetos que tem um cronograma seqencial, um modelo de ciclo de vida eficiente. Porm
quando os riscos do projeto so altos o suficiente para requerer mais flexibilidade no
cronograma o modelo cascata desfavorvel quando comparado com outros modelos de
ciclo de vida mais sofisticados [1]. No modelo cascata, o projeto planejado em uma
seqncia de fases (Figura 2). Cada fase definida em termos de entradas, sadas e

20
tarefas. No final de cada fase, a fase revista em uma reunio que deve ser conduzida para
verificar quais tarefas foram executadas, e que sadas esto prontas para a prxima fase [1].
aconselhado o uso do modelo de ciclo de vida cascata nas seguintes ocasies [3]:
O contrato de trabalho est completo, correto e no-ambguo.
Os requisitos e critrios de aceitao so completos, corretos e no
ambguos.
O trabalho pode ser completado sem restries.
Mudanas nos requisitos ou projeto no acontecero a necessidade do
cliente esttica.
O problema e soluo so bem entendidos e claramente definidos.
No sero cometidos erros durante a identificao de requisitos ou
planejamento do projeto.


Figura 2 Modelo de Ciclo de Vida em Cascata Fonte: [1]
2.3.4.2 Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3]
Existem vrios modelos de ciclo de vida das famlias incrementais e iterativas que
foram desenvolvidos nos anos 80, para progressivamente resolver os problemas do

21
modelo cascata. Isto inclui incrementos em mini-cascatas, modelos iterativos e espirais e
modelos evolucionrios.
Ciclo de Vida Incremental [3]
O modelo de ciclo de vida incremental similar ao modelo cascata, porm o trabalho
agrupado em pequenos ciclos seqenciais, e cada ciclo segue o modelo cascata conforme
Figura 3. Esse modelo eficiente quando o conjunto de requisitos do projeto tem alto risco
de sofrer mudanas, assim se os requisitos tiverem de ser modificados o oramento ficaria
menos comprometido do que se tivesse sido utilizado um modelo seqencial. [19]

Figura 3 - Modelo de Ciclo de Vida Incremental - Fonte: [1]

22
Ciclo de Vida Iterativo
No modelo iterativo (Figura 4), o projeto dividido em ciclos que so repetidos,
permitindo que o trabalho seja revisto e refinado [3]. Dessa forma o software liberado em
forma de uma srie de implementaes que so gradualmente mais completas, uma vez que
as disciplinas de desenvolvimento, entendimento dos requisitos e planejamento da
arquitetura so percorridas vrias vezes (uma vez a cada iterao). [20]

Figura 4: Modelo de Ciclo de Vida Iterativo. Fonte [36]
Ciclo de Vida Espiral [1]
No modelo de ciclo de vida espiral (Figura 5) so permitidas mltiplas interaes
entre atividades similares do projeto [1]. O progresso representado como um espiral
iniciando no centro. A dimenso radial representa o custo acumulado atualizado e a
dimenso angular representa o progresso atravs da espiral. Cada setor da espiral
corresponde a uma fase do desenvolvimento. No modelo original foram propostas as
seguintes quatro fases [21]:
Determinao de objetivos, alternativas e restries: fase onde ocorre o
comprometimento dos envolvidos e o estabelecimento de uma estratgia
para alcanar os objetivos.
Avaliao de alternativas identificao e soluo de riscos: feita a anlise
de risco.
Desenvolvimento do produto: neste quadrante pode-se considerar o
modelo cascata;

23
Avaliao do produto para iniciar um novo ciclo [21]

Figura 5 Modelo de Ciclo de Vida em Espiral - Fonte [1]
2.3.4.3 Modelos de Ciclo de Vida Evolucionrio
O modelo evolucionrio (Figura 6) foi desenvolvido para ajudar a quebrar o software
em pedaos que podem ser entregues para o cliente o mais cedo possvel. Nesse modelo o
software desenvolvido em ciclos do modelo cascata. Nas fases de operao e manuteno
ocorre a sobreposio dessas fases com o desenvolvimento da nova fase. [21]

24

Figura 6: Modelo de Ciclo de Vida Espiral. - Fonte: [1]
2.3.4.4 Modelos de Ciclo de Vida V
O modelo de ciclo de vida em V descreve revises nas atividades como um teste
antecipado, com objetivo de detectar erros precocemente ao longo do ciclo de
desenvolvimento. [3] No modelo de ciclo de vida V existem avaliaes, verificaes,
validaes e testes em todas as etapas do processo de desenvolvimento de software,
conforme ilustra a figura 7. O trabalho pode ser prosseguido quando todos os produtos de
uma fase do projeto se encontrem em conformidade com as exigncias de verificao e
validao da organizao. [22]

25

Figura 7 - Modelo V - Fonte: [3]
2.3.5 Vantagens e Desvantagens dos Modelos de Ciclo de Vida
A tabela abaixo apresenta algumas das vantagens de desvantagens dos modelos de
ciclo de vida de desenvolvimento de software apresentados anteriormente [3].
Modelo de
Ciclo de Vida
Vantagens Desvantagens
Cascata
Passos bem definidos fazem a
gerncia do projeto e gesto de
recursos mais fceis.

Erros nos requisitos e projeto no
so encontrados at a fase de
teste, se torna caro para reparar.
No permite mudanas nos
requisitos.
Incremental
Permite que grandes problemas
sejam quebrados em problemas
menores para serem entregues a
uma equipe.
No resolve problemas do
modelo cascata, a menos que
combinado com os modelos de
ciclo de vida iterativo, espiral ou
evolucionrio.

26
Iterativo/Espiral
Permite mudanas e o cliente
envolvido ao longo do ciclo de
vida;
Alguns usurios acham fcil de
gerenciar o tempo;
Permite o refinamento dos planos
e idias;
Teste acontece cedo falhas
podem ser encontradas mais
cedo. reas importantes podem
ser testadas primeiro;
Tempo para testar e fazer testes
de regresso so elevados;
Bastante tempo entre o incio e
produo;
Alguns usurios acham que no
to fcil para gerenciar por
estgios;
Pode ser difcil controlar custos e
tempo;
Menos clareza nos marcos do
projeto;
Evolucionrio
Assim como o modelo de ciclo de
vida iterativo e espiral, mais
adequado aos marcos, menor
tempo entre incio e produo,
entregas para reas importantes
primeiro.
Assim como os modelos de ciclo
de vida iterativo/ espiral, riscos
por falhas podem continuar se
propagando se os testes forem
insuficientes.
Modelo V
Fcil de gerenciar, de acordo com
os critrios da ISO 9000.
Teste contnuo e custo benefcio
em termos de defeitos
encontrados e facilidade para
consertar.
Necessita de muitos recursos para
testar todos os derivados do
projeto;
No comeo o ciclo de vida pode
parecer caro e burocrtico;
Tabela 1 Vantagens de Desvantagens dos Modelos de Ciclo de Vida - Fonte [3]
3 Padres de Qualidade de Processo de Software
Os padres de qualidade de processo de software mais conhecidos so a ISO/IEC
15504, CMMI e MPS.BR. Foram utilizados como base para o MPS.BR, foco deste trabalho,
a ISO/IEC 12207, ISO/IEC 15504 e CMMI como base para sua concepo.
3.1 ISO/IEC 15504 Avaliao do Processo de Software
A ISO/IEC 15504 - Standard for Information TechnologySoftware process
assessment foi publicada em 2004, com base no projeto SPICE (Software Process
Improvement and Capability dEtermination). Essa 1
A ISO/IEC 15504 define um modelo referncia de processos considerados essenciais
para a engenharia de software no mundo [6]. A ISO/IEC 15504, cuja estrutura pode ser vista
na (Figura 9), descreve duas dimenses a serem consideradas para avaliar a evoluo e
capacidade dos processos, a primeira dimenso define os processos que devem ser

27
avaliados e a segunda dimenso define as escalas utilizadas para medio da capacidade dos
processos avaliados [6]. Na primeira dimenso esto os processos: cliente-fornecedor,
engenharia, suporte, gesto e organizao [6].
Cliente-Fornecedor consiste dos processos que afetam clientes, suporte
ao desenvolvimento e transio do software ao cliente.
Engenharia - consiste dos processos para especificar, implementar, fazer
manutenes no sistema e produzir documentao aos usurios.
Suporte consiste dos processos que podem ser empregados por
qualquer outro processo ao longo do ciclo de vida do software.
Gesto consiste do processo que contm prticas de natureza genrica,
que podem ser usadas por qualquer gestor em qualquer projeto ao longo
do ciclo de vida do software.
Organizao consiste do processo que estabelece as metas do negcio
da organizao e desenvolvimento dos processos, produtos, recursos e
bens que quando usando por projetos, ajudam a organizao a atender
suas metas.
Na segunda dimenso da norma ISO/IEC 15504, esto os critrios para classificar os
processos em cada nvel [6]:
Nvel 0 Incompleto: produtos de trabalho e sadas dos processos no so
identificados facilmente;
Nvel 1 Executado: execuo pode no ser rigorosamente planejada e
executada. Porm indivduos da organizao reconhecem que o processo
deve ser executado e existe a aceitao de que o processo executado e
necessrio. Existem produtos de trabalhos do processo identificados e
declarao de realizao do que foi proposto;
Nvel 2 Gerenciado: execuo do acordo especificado nos procedimentos
planejada e executada. Produtos de trabalho esto conforme as
especificaes nas normas e requisitos. A distino primria do nvel 1
Executado que a execuo do processo planejada e gerenciada e os
progressos acontecem de acordo com o processo definido.
Nvel 3 Estabelecido: processo estabelecido de acordo com um processo
padro definido e eficiente, baseado em boas prticas de

28
engenharia de software. A distino principal do Nvel 2 Gerenciado
que o processo no Nvel 3 Estabelecido planejado e gerenciado usando
processos normalizados baseado em boas prticas de engenharia de
software
Nvel 4 Repetvel Medies detalhadas de desempenho so coletadas e
analisadas. Conduzindo para o entendimento quantitativo da capacidade
do processo e melhoria da habilidade de repetio. Desempenho
fortemente gerenciado. A qualidade dos produtos de trabalho
qualitativamente sabida. A principal distino em relao ao Nvel 3
Estabelecido que o processo quantitativamente entendido e
controlado;
Nvel 5 Otimizado processo quantitativamente efetivo e metas
eficientes para desempenho so estabelecidas, baseadas nas metas de
negcio da organizao. Contnuo processo de monitorao, metas so
estabelecidas para gerar um feedback quantitativo, melhorias so
alcanadas atravs de anlises de resultados. Processo otimizado envolve
idias inovadoras, tecnologias e mudanas em processo ineficazes para
atingir as metas ou objetivos da organizao.
A avaliao de acordo com a ISO/IEC 15504 prov um modelo para medio em
desenvolvimento de software. Os dados reunidos das avaliaes podem ser usados para
guiar o processo de melhoria contnua, conduzindo ganhos em produtividade, qualidade de
produtos e entregas [6].
Classificao dos processos da ISO/IEC 15504 avaliados em seis nveis, conforme a
Figura 8, abaixo:

Figure 8: Nveis de Classificao dos Processos ISO/IEC 15504 Fonte: [6]

29

A figura abaixo contm a estrutura da norma ISO/IEC 15504:

Figura 9 Estrutura da norma ISO/IEC 15504 - Fonte: ISO/IEC 15504 [9]
3.2 CMMI [10]
O CMMI foi criado pelo SEI no ano 2000 e teve a verso 1.1 lanada em 2002. O
CMMI foi criado para integrar e evoluir os modelos: SW-CMM - Capability Maturity Model
for Software, IPD-CMM Integrated Product Development e CMM SECM EIA 731, System
Engineering Capability Model. Alm de tornar-se compatvel com a norma ISO/IEC 15504
[10]. Os principais objetivos alcanados ao criar o CMMI foram: eliminar inconsistncias
entre os modelos existentes, implementar melhorias no modelo CMM, estar compatvel com
a norma ISO/IEC 15504 e contemplar a forma de representao contnua. O CMMI permite
duas representaes, por estgios e contnua.
A representao contnua utiliza os nveis de capacidade para[10] avaliao. A tabela 2
ilustra as duas representaes, por estgios e contnua. Pode-se perceber que as duas

30
representaes so muito parecidas. As duas contm os mesmos componentes e estes
componentes tm a mesma hierarquia e configurao. A diferena principal que na
representao contnua o foco na capacidade de processo como forma de mensurar o nvel
de capacidade.
J na representao por estgios o foco na maturidade da organizao, medida por
nveis de maturidade [10]. Nveis de capacidade so aplicveis em organizaes em busca de
melhoria de processo em reas de Processos individuais. Estes nveis so o meio para
incrementar a melhoria dos processos correspondendo a uma determinada rea de processo
[10].
Existem seis nveis de capacidade numerados de 0 a 5. Nveis de Maturidade so
aplicveis a organizaes cujo processo de melhoria deve ser alcanado atravs de mltiplas
reas de processo. Estes nveis so a base para prever os resultados para os prximos
projetos da organizao [10]. Existem cinco nveis de maturidade, numerado de 1 a 5. A
tabela a seguir mostra a comparao dos 6 nveis de capacidade com os 5 nveis de
maturidade:
Representao
Contnua
Representao por
Estgios

Nvel de Capacidade Nvel de maturidade
Nvel 0 Incompleto No aplicvel
Nvel 1 Repetvel Inicio
Nvel 2 Gerenciado Gerenciado
Nvel 3
Gerenciado
Quantitativamente
Gerenciado
Quantitativamente
Nvel 4
Gerenciado
Quantitativamente
Gerenciado
Quantitativamente
Nvel 5 Otimizado Otimizado
Tabela 2 - Comparao entre Nveis de Maturidade e Nveis Capacidade Fonte: [10]
Na representao contnua preocupa-se com a seleo de uma rea de processo
particular para melhoria e o nvel de capacidade desejado para aquela rea de processo.
Neste contexto, se o processo repetvel ou incompleto importante. Ento, o nome
incompleto o ponto de partida para a representao contnua [10].

31
A representao por estgio focada na maturidade da organizao, se os processos
esto repetveis ou incompletos, esse no o foco principal. Ento, o nome incio o ponto
de incio da representao por estgios [10].
O nvel de capacidade e nvel de maturidade provm o caminho para medir o quo bem a
organizao pode e faz a melhoria dos seus processos.
3.2.1 Abordagem Contnua
Nvel de Capacidade 0 - Incompleto
Um processo incompleto um processo no repetvel ou parcialmente repetvel. Um
ou mais objetivos especficos das reas de processo no esto satisfeitos [10].
Nvel de capacidade 1 Repetvel
No nvel de capacidade 1 o processo caracterizado como um processo repetvel. O
processo repetvel o processo que satisfaz os objetivos especficos da rea de processo, isto
, suporta e habilita o trabalho necessrio para adquirir capacidades. [10]
Nvel 2 de capacidade Gerenciado[10]
No nvel de capacidade 2 o processo caracterizado como um processo gerenciado.
Um processo gerenciado repetvel (nvel 1), tem a infra-estrutura bsica para
suportar o processo, isto , planejado e executado em acordo com polticas, por
trabalhadores competentes e pessoas que tem recursos adequados para produzir sadas
controladas. Envolve stakeholders relevantes, revisado, monitorado e controlado e
avaliado se est aderente aos processos. A disciplina no processo, refletida pelo nvel de
capacidade 2 ajuda a assegurar que prticas existentes so retidas mesmo durante os
momentos de presso. [10]
Nvel de capacidade 3 - Definido[10]
O nvel de capacidade 3 caracterizado como o processo definido. Um processo
definido gerenciado (nvel 2 de capacidade) faz parte da cultura da organizao, o
conjunto de processos padro est de acordo com os demais processos da organizao, como
guias, produtos de trabalho, medies e outros processo de melhoria. [10] A principal
diferena entre os nveis de capacidade 2 e 3 o escopo das normas, descries de processo
e procedimentos. No nvel de capacidade 2, a norma, descrio de processo e procedimentos
podem ser um pouco diferentes em cada instncia especfica dos processos. No nvel de
capacidade 3, os padres, descries de processo e procedimentos para o

32
planejamento de projeto esto de acordo com os processos padro da organizao. Outra
crtica distino que no nvel de capacidade 3, processos so tipicamente descritos mais
rigorosamente que no nvel de capacidade 2. O processo definido deixa mais claros o
estados das propostas, entradas, critrios de entrada, atividades, papis, medies, passos de
verificao, sadas, e critrios de sada. No nvel de capacidade 3, processos so gerenciados
com mais pr- atividade usando um entendimento das inter-relaes entre as atividades de
processo e detalhadas medies dos processos, produtos de trabalho e seus servios. [10]
Nvel de Capacidade 4 Gerenciado Quantitativamente [10]
No nvel de capacidade 4 o processo caracterizado como processo gerenciado
quantitativamente. Processo gerenciado quantitativamente definido (nvel de capacidade 3)
e controlado usando estatstica e outras tcnicas quantitativas. Objetivos quantitativos para
a qualidade e desempenho do processo so estabelecidos e usados como critrio no processo
gerenciado. Qualidade e desempenho do processo so entendidos em termos estatsticos e
so gerenciados por toda a vida do processo. [10]
Nvel de Capacidade 5 Otimizado [10]
No nvel de capacidade 5 o processo caracterizado como um processo otimizado.
Um processo otimizado gerenciado quantitativamente (nvel de capacidade 4) e
melhorado sistematicamente. O foco de um processo otimizado a melhoria contnua do
desempenho do processo atravs de melhorias incrementais e inovaes [10].
3.3 MPS.BR Melhoria de Processo do Software Brasileiro
O MPS.BR um programa para Melhoria de Processo do Software Brasileiro, est
em desenvolvimento desde dezembro de 2003 e coordenado pela Associao para
Promoo da Excelncia do Software Brasileiro (SOFTEX), contando com apoio do
Ministrio da Cincia e Tecnologia (MCT), da Financiadora de Estudos e Projetos
(FINEP) e do Banco Interamericano de Desenvolvimento (BID).
Guia Geral
Dentre os objetivos do MPS.BR est o de definir e aprimorar um modelo de melhoria e
avaliao do processo de software apropriado ao contexto das micro, pequenas e mdias
empresas, uma vez que o CMMI, que o principal modelo de melhoria de software
existente, no o mais adequado em termos de estrutura e custos s empresas deste porte,
que so maioria no Brasil. Um outro objetivo do MPS.BR ser reconhecido nacional e

33
internacionalmente como modelo de melhoria de processos para a indstria de software.
O MPS.BR alm do processo de melhoria, estabelece o mtodo de avaliao das
empresas e processo de aquisio. Foi desenvolvido baseado nas normas ISO/IEC 12207
Processos de Ciclo de Vida de Software, suas emendas 1 e 2, na ISO/IEC 15504 Avaliao
de Processo e CMMI. Dessa forma est de acordo com o contedo do CMMI-DEV [12].
A equivalncia entre os modelos CMMI, representao por estgios e MPS.BR pode
ser verificada na tabela abaixo:
Comparao entre Nveis
de Maturidade
CMMI e MPS.BR
CMMI MPS.BR
5 A
4 B
3 C
-- D
-- E
2 F
-- G
1 No
definido
Tabela 3 - Comparao entre nveis de maturidade CMMI e nveis de maturidade MPS.BR
A documentao do MPS.BR est dividida em trs componentes: o Modelo de
referncia, Mtodo de Avaliao e Modelo de Negcio, que so documentados atravs de
guias, conforme figura abaixo [12].

34

Figura 10 Estrutura da Documentao do MPS.BR Fonte: Guia Geral MPS.BR [12]
3.3.1 Guias e Documentao MPS.BR
No Guia Geral est descrito o Modelo de Referncia do MPS.BR. Ou seja,
os processos e em funo de seus resultados esperados, os nveis de
maturidade e capacidades. Esses elementos descrevem a estrutura a ser
implementada pela organizao que deseja ter seus processos em
conformidade com o MPS.BR [12].
O Guia de Aquisio contm as boas prticas para a aquisio de software
e servios correlatos [12].
O Guia de Avaliao contm o mtodo e descrio dos papis participantes
de uma avaliao de maturidade no MPS.BR [12].
O Modelo de Negcios contm as regras para tornar-se uma instituio
implementadora do MR-MPS, assim como para tornar-se uma instituio
avaliadora. Alm disso, contm orientaes para organizao de grupos de
empresas para implementao e avaliao no MPS.BR, chamado de projeto
cooperado e informaes para obter a certificao de consultores de
aquisio e treinamentos. [12]
Guias de Implementao: faz parte do conjunto de documentos de apoio ao
MPS.BR. Estes guias fornecem orientaes para implementar nas
organizaes os nveis de maturidade descritos no modelo de referncia,
detalhando os processos contemplados nos respectivos nveis de

35
maturidade e os resultados esperados com a implementao dos processos.
Para cada nvel de maturidade existe uma guia de implementao. [13]
Todos os guias do MPS.BR esto disponveis no website da Softex: www.softex.br.
3.3.2 Conceitos Importantes no MPS.BR
Atributo de processo uma caracterstica mensurvel da capacidade do
processo aplicvel a qualquer processo [ISO/IEC 15504-1, 2004].
Perfil do processo um conjunto de pontuao de atributos de processo
para um processo avaliado [ISO/IEC 15504-1, 2004].
Resultado esperado do processo resultado observvel do sucesso do
alcance do propsito do processo [ISO/IEC 12207:1995/Amd 1:2002].
A capacidade do processo representada por um conjunto de atributos de
processo descritos em termos de resultados esperados. A capacidade do
processo expressa o grau de refinamento e institucionalizao com que o
processo executado na organizao. No MPS, medida que a
organizao evolui nos nveis de maturidade, um maior nvel de
capacidade para desempenhar o processo deve ser atingido pela
organizao [12].
No MPS.BR existem cinco atributos de processo. Cada atributo de processo (AP) est
detalhado em termos de resultados esperados deste atributo de processo (RAP) [12]. Para o
nvel G devem ser contemplados dois atributos de processo, o AP 1.1 e AP 2.1.
AP 1.1 O processo executado
RAP1. O processo atinge seus resultados definidos.
AP 2.1 O processo gerenciado
RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo;
RAP 3. A execuo do processo planejada;
RAP 4 (para o Nvel G)7. A execuo do processo monitorada e ajustes so
realizados para atender aos planos;
RAP 5. Os recursos necessrios para a execuo do processo so identificados e
disponibilizados;

36
RAP 6. As pessoas que executam o processo so competentes em termos de
formao, treinamento e experincia;
RAP 7. A comunicao entre as partes interessadas no processo gerenciada de
forma a garantir o seu envolvimento no projeto;
RAP 8. O estado, atividades e resultados do processo so revistos com os nveis
adequados de gerncia (incluindo a gerncia de alto nvel) e problemas pertinentes
so tratados.
3.3.3 Nveis de Maturidade no MPS.BR
O MPS.BR estabelece sete nveis de maturidade que mostram os patamares da evoluo
dos processos da organizao, caracterizados pelos estgios de implementao de melhorias
nos processo da organizao[12]. Os nveis de maturidade so os seguintes:
A Em otimizao Equivalente ao nvel 5 CMMI;
B Gerenciado Quantitativamente Equivalente ao nvel 4 do CMMI;
C Definido Equivalente ao nvel 3 do CMMI;
D Largamente Definido Parcialmente de acordo com o nvel 3 do CMMI;
E Parcialmente Definido - Parcialmente de acordo com o nvel 3 do CMMI;
F Gerenciado Equivalente ao nvel 2 do CMMI;
G Parcialmente Gerenciado - Parcialmente de acordo com o nvel 2 do CMMI;
A organizao obtm determinado nvel de maturidade quando atende aos propsitos de
todos os resultados esperados nos processos e atributos de processo do respectivo nvel de
maturidade. A diviso em estgio, baseada no CMMI-SE-SW, tem graduao diferente para
possibilitar mais etapas durante a implementao, mais adequado ao contexto das micro,
pequenas e mdias empresas. Alm disso, ter mais nveis possibilita que os resultados de
melhorias sejam visualizados mais rapidamente [12].
3.3.4 Processo
Os processos no MPS.BR so descritos em termos de propsito, resultados esperados e
informaes adicionais. O propsito descreve o objetivo geral a ser atingido durante a
execuo do processo [12]. Os resultados esperados do processo estabelecem os resultados a
serem obtidos com a efetiva implementao dos processos em determinado nvel. Estes

37
resultados podem ser evidenciados por um artefato produzido ou uma mudana significativa
de estado ao se executar o processo [12].
3.3.5 Estrutura de Processos e Nveis do MPS.BR
Nvel Processo Atributo de Processo
A
Anlise de Causas de Problemas
e Resoluo-ACP
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2, AP 4.1 AP 4.2, AP 5.1 e AP
5.2
B
Gerncia de Projetos GPR
(evoluo)
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP
3.2, AP 4.1 e AP 4.2
Gerncia de Riscos GRI
Desenvolvimento para
Reutilizao DRU
Anlise de Deciso e Resoluo
ADR
C
Gerncia de Reutilizao GRU
(evoluo)
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e
AP 3.2
Verificao VER
Validao - VAL
Projeto e Construo do Produto
PCP
Integrao do Produto ITP
D
Desenvolvimento de Requisitos
DRE
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e
AP 3.2
Gerncia de Projetos GPR
(evoluo)
Gerncia de Reutilizao GRU
Gerncia de Recursos Humanos
GRH
Definio do Processo
Organizacional DFP
E
Avaliao e Melhoria do
Processo Organizacional AMP
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e
AP 3.2

38
Medio MED
Garantia da Qualidade - GQA
Gerncia de Configurao
GCO
F
Aquisio AQU
AP 1.1, AP 2.1 e AP 2.2
Gerncia de Requisitos GRE
G
Gerncia de Projetos - GPR
AP 1.1 e AP 2.1
Tabela 4 - Estrutura de Processos e Nveis do MPS.BR - [MR-MPS.BR] Fonte: [12]
Cada processo tem um propsito e seus resultados esperados. No nvel G, esto os
processos Gerncia de Projetos e Gerncia de Projetos. Os atributos de processo a serem
atendidos nesse nvel so o AP 1.1 e AP 2.1 [12], conforme citado anteriormente.
O propsito do processo Gerncia de Projetos :
O propsito do processo Gerncia de Projetos identificar, estabelecer, coordenar e
monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um
produto e/ou servio, no contexto dos requisitos e restries do projeto. [12]
Guia Geral
Os resultados esperados para o Processo de Gerncia de Projetos so [12]:
GPR 1. O escopo do trabalho para o projeto est definido
Espera-se que a organizao tenha artefatos que mostrem o trabalho a ser realizado
para criar o produto que satisfaa as necessidades especificadas para o projeto.
Um exemplo de artefato que atenderia a esse resultado seria a EAP do projeto.

GPR 2. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando
mtodos apropriados
Espera-se que a complexidade das tarefas a serem executadas tenha sido estimada
atravs de mtodos adequados.

GPR 3. O modelo e as fases do ciclo de vida do projeto so definidas

39
Espera-se que a organizao tenha adotado um modelo de ciclo de vida para seus
projetos de desenvolvimento de software.

GPR 4. (At o nvel F). O esforo e o custo para a execuo das tarefas e dos produtos
de trabalho so estimados com base em dados histricos ou referncias tcnicas
Este resultado espera que a organizao estime o esforo para as atividades do
projeto baseada em mtodos estatsticos adequados e que essas estimativas tenham
sido documentadas.

GPR 5. O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de
controle, so estabelecidos e mantidos
Espera-se que tenha sido estabelecido o oramento e cronograma para o projeto.
Espera-se ainda que o cronograma e oramento sejam mantidos atualizados ao longo
da execuo do projeto.

GPR 6. Os riscos do projeto so identificados e o seu impacto, probabilidade de
ocorrncia e prioridade de tratamento so determinados e documentados
Espera-se que os riscos aos quais o projeto est exposto sejam identificados, e que o
impacto, probabilidade de ocorrncia e prioridade no tratamento tenham sido
documentados e monitorados ao longo do projeto.

GPR 7. Os recursos humanos para o projeto so planejados considerando o perfil e o
conhecimento necessrios para execut-lo
Esperam-se nesse resultado artefatos que mostrem que os recursos humanos que
executaro as atividades do projeto tenham sido escolhidos baseados no perfil e
conhecimentos necessrios para executar a atividade do projeto.

GPR 8. As tarefas, os recursos e o ambiente de trabalho necessrios para executar o
projeto so planejados.
Nesse resultado so esperados artefatos que mostrem que a infra-estrutura necessria

40
para executar cada atividade do projeto tenha sido planejada e disponibilizada ao
longo do projeto.

GPR 9. Os dados relevantes do projeto so identificados e planejados quanto forma de
coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los,
incluindo, se pertinente, questes de privacidade e segurana
Nesse resultado esperam-se artefatos que mostrem que os dados do projeto sejam
gerenciados ao longo da execuo dos projetos.

GPR 10. Planos para a execuo do projeto so estabelecidos e reunidos no Plano do
Projeto
Nesse resultado esperam-se artefatos que mostrem o planejamento da execuo do
projeto, por exemplo, um plano de projeto que relacione as informaes deste entre
si.

GPR 11. A viabilidade de atingir as metas do projeto, considerando as restries e os
recursos disponveis, avaliada. Se necessrio, ajustes so realizados
Nesse resultado esperam-se artefatos que mostrem que a viabilidade para atingir as
metas do projeto tenha sido avaliada.

GPR 12. O Plano do Projeto revisado com todos os interessados e o compromisso com
ele obtido
Nesse resultado espera-se que todos os envolvidos com a execuo do projeto
conheam e se comprometam com o Plano de Projeto.

GPR 13. O progresso do projeto monitorado com relao ao estabelecido no Plano do
Projeto e os resultados so documentados
Nesse resultado espera-se que haja um documento que registre as monitoraes do
projeto, ou seja, se existe um controle entre as diferenas do que foi planejado e o
que est sendo realizado no projeto.

41

GPR 14. O envolvimento das partes interessadas no projeto gerenciado
Nesse resultado esperam-se artefatos que mostrem que as partes interessadas no
projeto esto sendo envolvidas, assim como, o comprometimento com as atividades
do projeto mantido.

GPR 15. Revises so realizadas em marcos do projeto e conforme estabelecido no
planejamento
Neste resultado espera-se que sejam realizadas revises nos marcos/milestones do
projeto. Espera-se que alm de programas essas revises sejam efetivamente
realizadas no projeto.

GPR 16. Registros de problemas identificados e o resultado da anlise de questes
pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes
interessadas
Neste resultado espera-se que sejam identificados e analisados os problemas
ocorridos ao longo do projeto. Esse resultado freqentemente atendido nas
atividades de monitorao do projeto.

GPR 17. Aes para corrigir desvios em relao ao planejado e para prevenir a repetio
dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua
concluso
Nesse resultado espera-se que os desvios significativos em relao ao que foi
planejado esto sendo tratados de forma a prevenir a repetio dos problemas.
esperado tambm que os problemas sejam acompanhados e resolvidos ao longo do
ciclo de vida do projeto. Esse resultado pode ser atendido com a abertura de aes
corretivas para os problemas ocorridos.

O propsito da Gerncia de Requisitos :
O propsito do processo Gerncia de Requisitos gerenciar os requisitos dos
produtos e componentes do produto do projeto e identificar inconsistncias

42
entre os requisitos, os planos do projeto e os produtos de trabalho do projeto
Guia Geral
Os resultados esperados do processo de Gerncia de Requisitos so:
GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos
Nesse resultado esperam-se artefatos que o fornecedor de requisitos e responsvel
por alterar requisitos estejam identificados assim como se espera um documento que
represente o entendimento dos requisitos pelos envolvidos.

GRE 2. Os requisitos de software so aprovados utilizando critrios objetivos
Neste resultado esperam-se que tenham sido definidos critrios para avaliao e
aceitao dos requisitos do sistema.

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho
estabelecida e mantida
Nesse resultado espera-se que os requisitos sejam rastreados horizontal e
verticalmente, ou seja, necessrio mostrar que se pode partir de um requisito e
chegar o documento que descreve a necessidade que o originou e tambm partindo
deste mesmo requisito possvel chegar ao cdigo criado para atend-lo.

GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando
identificar e corrigir inconsistncias em relao aos requisitos
Nesse resultado esperam-se artefatos que mostrem que as mudanas de requisitos
tenham refletido em atualizaes nos artefatos impactos por essa mudana.

GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto
Nesse resultado espera-se que a cada mudana de requisito tenha sido realizada a
anlise de impacto desta mudana antes da sua implementao, assim como o
histrico de mudanas solicitadas deve estar disponvel para e equipe do projeto.


43
Os demais processos e seus propsitos para todos os nveis de maturidade do MPS.BR
podem ser verificados no Guia Geral do MPS.BR no website da Softex.
4 Implantao do MPS.BR na Ilog Tecnologia
4.1 Ilog Tecnologia
A Ilog Tecnologia uma micro empresa especializada no desenvolvimento de
sistemas sob demanda. Foi fundada em 1997 e at o ano de 2007 dedicou-se ao
desenvolvimento e evoluo dos seus produtos para educao distncia. Em 2007 os
direitos autorais dos produtos de educao distncia foram vendidos a empresa Datasul
Educao Corporativa.
Desde ento a Ilog tem se dedicado ao desenvolvimento de sistemas sob demanda.
Na mesma poca em que a Ilog vendeu os direitos autorais dos seus produtos de
EAD iniciou o processo de implantao do MPS.BR nvel G, atravs de um projeto
cooperado coordenado pela ACATE. Em junho e julho de 2008 ocorrero as avaliaes
para obter o nvel G do MPS.BR.
Estrutura Hierrquica da Ilog

Figura 11 Organograma Ilog Fonte Ilog


44
Diretor Executivo: detm a autoridade mxima na Ilog. Responsvel por
traar as direes que a empresa deve seguir.
Gerente da Qualidade: Responsvel por manter os projetos desenvolvidos
pela Ilog de acordo com os processos desenvolvidos, assim como evoluir
os processos da organizao sempre que necessrio.
Coordenador de Projetos: Responsvel pelo andamento de todos os projetos
na Ilog tecnologia.
Gerente de Projetos: Responsvel pelo andamento do projeto a que este
gerencia junto com o Coordenador de Projetos.
Analista de Sistemas: Responsvel pela anlise e projeto do sistema a ser
desenvolvido, assim como estimativas de esforo.
Desenvolvedor: Responsvel pela codificao do software.
Designer: Responsvel pelo projeto e criao das interfaces dos sistemas
produzidos pela Ilog.
Esses so os papis que participam da unidade dentro da Ilog, chamada Ilog Servios
que ser avaliada segundo o MPS.BR nvel G.
4.2 Atividades para Implantao do MPS.BR
O projeto de implantao do MPS.BR nvel G est sendo implementado pela
Incremental Tecnologia, formada basicamente por pesquisadores do Laboratrio de
Qualidade e Produtividade de Software da Universidade de Vale do Itaja - Univali. Esses
pesquisadores foram os implementadores, de acordo com o Modelo de Negcio, do MPS.BR
nvel G na Ilog.
4.2.1 Primeira Atividade - Conscientizao
A primeira atividade realizada pelos implementadores foram apresentaes sobre o
tema aos funcionrios da Ilog para que esses se conscientizassem da importncia de se ter
um processo de desenvolvimento de software.
4.2.2 Segunda Atividade Diagnosticao da Situao Atual
A segunda atividade para a implantao do MPS.BR nvel G foi a diagnosticao do
processo de software existente na empresa, mesmo que informal. Essa etapa foi

45
muito importante uma vez que a empresa estava se reestruturando aps mudana de foco de
educao a distncia para desenvolvimento de software sob demanda. O diagnstico foi
realizado pelos implementadores. Que realizaram entrevistas individuais com funcionrios e
alta direo da Ilog. Essas entrevistas puderam mostrar as vises sobre os processos
existentes do ponto de vista dos funcionrios e alta direo.
4.2.3 Terceira Atividade Treinamento
A terceira atividade realizada para implantao do MPS.BR foram os treinamentos
ministrados pelos implementadores sobre os processos do nvel G do MPS.BR. Foi
ministrado tambm um treinamento sobre o MPS.BR para que todos tivessem o mesmo
entendimento do assunto. A carga horria dos cursos foram as seguintes:
Viso Geral do MPS.BR 8 horas
Gerncia de Projetos 16 horas
Gerncia de Requisitos 8 horas
4.2.4 Quarta Atividade Mapeamento dos Processos
Aps a etapa dos treinamentos, iniciaram-se os trabalhos para o mapeamento dos
processos da Ilog. Desde ento os implementadores passaram a freqentar a Ilog
semanalmente para orientar e avaliar o que havia sido realizado. Ao iniciar a atividade de
Mapeamento dos Processos foi constatado que seria necessrio elaborar alm dos processos
de Gerncia de Requisitos e Gerncia de Projetos os processos de Fornecimento e
Encerramento de Projetos.
Para mapear os processos foi utilizada a tcnica de brainstorm orientada pelos
implementadores, para que todos os resultados esperados do MPS.BR mapeado fossem
atendidos pelo processo. O processo foi mapeado baseado na experincia dos profissionais
da Ilog e dos implementadores. O mapeamento aconteceu em reunies em que de acordo
com o processo a ser mapeado as pessoas envolvidas eram convocadas para darem sua
contribuio. Como resultado das reunies de mapeamento era obtido um fluxograma com o
processo mapeado.
4.2.5 Quinta Atividade Detalhamento dos Processos Mapeados
Com o processo mapeado era possvel iniciar a etapa de detalhamento deste
processo. O detalhamento do processo implicava em decidir como deveria ser

46
realizada cada atividade mapeada no processo. Isso era decidido em reunies, geralmente
com Gerente de Projetos, Analista de Sistemas e Gerente da Qualidade. Depois de decidido
como deveria ser realizada cada atividade do processo, essas atividade eram formalizadas
como atividades do processo. Para registrar o detalhamento dos processos foi utilizada a
ferramenta chamada Eclipse Process Framework - EPF. Essa ferramenta foi escolhida por
ser livre e mais flexvel.
4.2.6 Sexta Atividade Treinamento do Processo Organizacional
Aps ter o processo totalmente documentado foi realizado o treinamento sobre o
processo para todos os funcionrios da Ilog. A partir de ento o processo foi considerado
institucionalizado, ou seja, foi considerado oficial para os prximos projetos a serem
desenvolvidos na organizao.
4.2.7 Stima Atividade Avaliao Interna nos Projetos da
Empresa
Aps a institucionalizao dos processos, os novos projetos passaram a ser avaliados
quanto consistncia em relao aos processos. A avaliao do Projeto era realizada pelo
Gerente da Qualidade. Nessas avaliaes foram detectadas muitos pontos fracos e erros
cometidos no desenvolvimento dos processos, alm dos problemas do projeto avaliado.
4.2.8 Oitava Atividade Simulados
Os implementadores realizaram trs simulados de avaliao ao longo da implantao.
Alm disso, contrataram um avaliador do oficial MPS.BR para realizar um simulado de
avaliao. Nos primeiros simulados foram abertas inmeras aes corretivas e detectados
pontos fracos do projeto e processo respectivamente. O que foi diminuindo gradativamente
medida que o processo era repetido.
4.3 Preparao para Avaliao Oficial
Conforme o processo de avaliao do MPS.BR foram escolhidos dois projetos para
serem avaliados. O objetivo do projeto avaliado era fazer um sistema para realizar uma
avaliao do clima organizacional em empresas brasileiras, que foi dividido em duas etapas
a serem avaliadas como projetos independentes na avaliao oficial do MPS.BR.

47
Esse projeto iniciou-se em Maro de 2008 e finalizou em J unho de 2008.
4.3.1 Descrio dos Processos
Para obter o MPS.BR nvel G a empresa precisa ter implantado os processos de
Gerncia de Projetos e Gerncia de Requisitos. Para Implantao desses processos,
conforme citado anteriormente, sentiu-se a necessidade de criao de mais processos para
darem apoio aos processos do nvel G. Por isso foram criados os processos de Fornecimento,
que descreve como devem ser as etapas que antecedem o planejamento de um projeto. Alem
deste, foi criado o Processo de Encerramento, que descreve as aes a serem realizadas ao
final de cada projeto. O processo de Gerncia de Projetos foi dividido em dois: Processo de
Planejamento de Projeto e o Processo de Monitorao, para que fossem executados com
mais cuidado.
4.3.2 Processo de Fornecimento
O processo de Fornecimento descreve as atividades a serem realizadas antes de se ter
o valor a ser cobrado pelo projeto solicitado. O objetivo deste processo analisar a
solicitao recebida para obter o valor a ser cobrado pelo projeto mais prximo possvel do
desejado. Um grande desafio na criao deste processo foi mant-lo gil de forma que a
empresa no perdesse uma oportunidade por ter de ficar analisando para obter o exato valor
do projeto e tambm que a Ilog conseguisse obter um valor que no a prejudicasse. O
Processo de Fornecimento mapeado pode ser visualizado na figura a seguir:

48



Figura 12 Processo de Fornecimento Fonte: Ilog Tecnologia

49
Fazer Anlise de Viabilidade
O que e como realizada
Esta a primeira atividade realizada quando recebida uma requisio de
projeto de um cliente, pois caso se trate de um projeto invivel ser
despendido o mnimo tempo e esforo possvel. A realizao dessa atividade
basicamente uma reunio entre Coordenador de Projetos e Direo para
avaliar a viabilidade do projeto solicitado. Para isso so verificados critrios
previamente definidos em um template desenvolvido para essa atividade.
Dificuldades encontradas para execuo da atividade
No foram sentidas dificuldades para execuo desta atividade, uma vez que
bastante simples, pois se trata de realizar uma reunio.
Dificuldades para Definio desta tarefa no processo
A definio dos critrios de viabilidade foi a tarefa mais trabalhosa no
detalhamento desta atividade. Essa definio foi realizada em reunies entre
Gerente de Qualidade e Coordenador de Projeto e Direo.
Resultado Esperado atendido
A tarefa de fazer anlise de viabilidade atende ao GPR 4. A viabilidade de
atingir as metas do projeto, considerando as restries e os recursos
disponveis, avaliada. Se necessrio ajustes so realizados.

Cadastrar como Oportunidade
Essa uma atividade interna da Ilog, no foi criada para atender resultados
esperados no MPS.BR. Significa basicamente registrar no sistema de CRM
da Ilog uma oportunidade de trabalho para a empresa, uma vez que s
executada se a solicitao de projeto considerada vivel.

Elaborar Termo de Abertura
O que e como realizada
Essa a terceira atividade realizada no Processo de Fornecimento, tem como
objetivo iniciar o projeto formalmente na Ilog, ou seja, determinar o Gerente

50
do Projeto, cadastrar o projeto no sistema de Gerncia de Projetos da empresa
e determinar o ciclo de vida a ser seguido pelo projeto. Espera-se como sada
desta atividade a autorizao ou no direo da Ilog para que a equipe
trabalhe no projeto solicitado. Para cadastrar o projeto no sistema de
Gerncia de Projetos da Ilog o Coordenador de Projetos deve descrever o
projeto, seus objetivos, premissas e restries, justificativas e o escopo
preliminar do projeto. A Direo da Ilog deve autorizar a equipe ou no a
trabalhar no projeto solicitado, atravs de um e-mail.
Dificuldades encontradas para execuo da atividade
A principal dificuldade encontrada para executar essa atividade a escolha
do ciclo de vida do projeto to cedo. As opes de ciclo de vida podem ser:
ciclo de vida para projetos com menos de 4 semanas, ciclo de vida para
projetos com mais de 4 semanas e ciclo de vida para projetos de manuteno.
Alm disso, no foram encontradas mais dificuldades para execuo desta
atividade, uma vez que necessrio basicamente preencher um template no
sistema de gerenciamento de projetos.
Dificuldades para Definio desta tarefa no processo
A principal dificuldade para definio desta atividade foi a definio do ciclo
de vida dos projetos da Ilog. O sistema de gerenciamento de projetos obriga
que o projeto tenha um ciclo de vida para ser cadastrado. A parte da definio
do ciclo de vida foi realizada com o auxlio dos implementadores
(Incremental). A Ilog optou por utilizar os modelos de ciclo de vida Iterativo
e Incremental combinados, isso significa que o projeto passa por iteraes
que geram releases, conforme especifica o ciclo de vida iterativo. O que d a
caracterstica incremental no modelo que em algumas fases o projeto passa
por todo o processo. [33]
Resultado Esperado atendido
Essa atividade atende a dois resultados esperados do MPS.BR:
GPR 1. O escopo do trabalho para o projeto est definido. - Essa atividade
d incio para definio do escopo do projeto.
GPR 3. As fases do ciclo de vida do projeto so definidas. nessa

51
atividade que definido o ciclo de vida que o projeto seguir.

Realizar o Entendimento Preliminar
O que e como realizada
Essa atividade realizada pelo Gerente de Projetos com o Cliente. O objetivo
obter a confirmao do cliente de que o escopo preliminar do projeto foi
entendido corretamente. As informaes constantes do documento
Entendimento Preliminar so basicamente as mesmas informaes do Termo
de Abertura. Caso o escopo do projeto seja considerado fcil de ser entendido
essa atividade no precisa ser realizada, uma vez que a prxima atividade
Elaborar o Documento de Viso j define o escopo do projeto. A razo de
se realizar essa atividade para que no de se despenda esforo realizando a
atividade seguinte Elaborar o Documento de Viso que naturalmente
necessitar de muito esforo se o escopo no est completamente entendido
por Gerente de Projeto e Cliente e tambm para que no sejam criadas
expectativas que no sero atendidas no final do projeto.
Dificuldades para definio desta tarefa no processo
No houve dificuldade para definio desta tarefa, uma vez que ela baseada
no preenchimento de um template. A realizao desta atividade est
condicionada ao modelo de ciclo de vida escolhido, que deve ser o modelo de
ciclo de vida para mais de 4 semanas.
Resultado Esperado atendido
Essa atividade serve como base para que o processo organizacional da Ilog
atenda ao resultado esperado: GPR 1. O escopo do trabalho para o projeto
est definido. Uma vez que se realizada ajudar na definio do escopo do
projeto.

Elaborar o Documento de Viso
O que e como realizada
nessa atividade que a Ilog, baseada nas atividades anteriores, define o
escopo do projeto. Para isso o Gerente de Projetos preenche um

52
template com todas as informaes necessrias para deificao do escopo do
projeto nesse estgio do processo. O preenchimento desse template exige
vrias reunies com o Cliente para que se obtenham todas as informaes
necessrias para definir o escopo do projeto.
Dificuldades para definio desta tarefa no processo
A definio desse template foi uma das mais importantes etapas da
implantao do MPS.BR, uma vez que o projeto ainda no foi aceito pelo
cliente e esta atividade demanda esforo relativamente alto investido pelo
Gerente de Projetos. Ao mesmo tempo em que essa atividade a base para
que se obtenha o valor a ser cobrado o mais prximo possvel do que a Ilog
deseja. O template utilizado foi criado baseado no template previamente
utilizado pela Ilog como Documento de Viso.
Resultado Esperado atendido
Essa atividade atende parcialmente o resultado esperado GRP 1. O escopo
do trabalho para o projeto est definido.

Identificar Requisitos
O que e como realizada
Essa atividade realizada pelo Analista de Sistemas, baseado no Documento
de Viso, criado na atividade anterior. Os requisitos identificados so
registrados no sistema Enterprise Architect - EA. Essa atividade serve como
base para todo o Processo de Gerncia de Requisitos. E realizada no
Processo de Fornecimento para facilitar a obteno do valor a ser cobrado
pelo projeto. Para que os requisitos sigam um padro, independente do
Analista de Sistemas que os identificaram, foi criado um checklist com
critrios de aceitao para cada requisito. Esse checklist preenchido pelo
Analista de Sistemas antes de registrar os requisitos no EA.
Dificuldades para definio desta tarefa no processo
No foram encontradas dificuldades para definio desta tarefa, o nico fator
que gerou discusses ao longo do detalhamento do processo se seria melhor
identificar requisitos antes ou depois de se ter o aceite do Cliente. Decidiu-se

53
realiza-la antes do aceite do cliente pois essa atividade serviria de base para
que se obtivesse uma estimativa de esforo mais prxima do real, o que
facilitaria a obteno do valor a ser cobrado. Decidiu-se somente identificar
os requisitos nessa etapa do processo e no aprofundar para as demais etapas
de projeto do sistema.
Resultado Esperado atendido
Essa atividade serve de base para o Processo de Gerncia de Mudana de
Requisitos. Alm disso, o fato de os requisitos passarem por critrios de
aceitao, atende ao resultado esperado GRE 2. Os requisitos de software
so aprovados utilizando critrios objetivos
Template Utilizado
Checklist aceitao de requisitos:
Figura 13 Template checklist Aceitao de Requisitos Fonte: Ilog Tecnologia
Definir durao, esforo e papis
O que e como realizada
Espera-se nessa atividade definir superficialmente o tempo total para a
execuo do projeto, assim como o esforo de cada papel para executar as
atividades do projeto. Para essa atividade necessrio que se saiba as
atividades do projeto, mesmo que superficialmente. A execuo dessa
atividade inicia com o gerente de projetos, baseado no escopo do projeto,
definindo as atividades do projeto e registrando-as no sistema de
gerenciamento de projetos. Em seguida deve ser estimado o esforo para
realizar cada atividade do projeto. O mtodo a ser utilizado, uma vez que no
se tenham histricos o PERT.
Aps definido o esforo para executar cada tarefa, deve ser identificado quais

54
papis, como analistas de sistemas, designer, desenvolvedores e testadores
para realizar as atividades do projeto. Aps essas etapas o Gerente de
Projetos pode definir a durao do projeto.
Dificuldades para definio desta tarefa no processo
Essa foi uma das atividades mais complexas de ser definida, especialmente as
atividades para definio da durao e esforo para o projeto. O grande
problema encontrado para realizar essa tarefa foi a falta de maturidade da
empresa para aplicar os mtodos de definio de esforo mais usados como
anlise por ponto de funo e pontos por caso de uso. Por isso, inicialmente
optou-se por utilizar-se o mtodo Wideband Delphi, que baseado na
experincia de especialistas, porm verificou-se que a Ilog no tinha recursos
humanos suficientes para utilizar o mtodo corretamente. Finalmente optou-
se pela utilizao do mtodo de estimativas PERT.
Resultado Esperado atendido
Essa atividade serve como base para as tarefas que atendem aos resultados
esperados: GPR 2. As tarefas e os produtos de trabalho do projeto so
dimensionados utilizando mtodos apropriados., GPR 7. Os recursos
humanos para o projeto so planejados considerando o perfil e o
conhecimento necessrios para execut-lo. e GPR 4 O esforo e o custo
para a execuo das tarefas e dos produtos de trabalho so estimados com
base em dados histricos ou referncias tcnicas
Template Utilizado
Template para Estimativa de Esforo utilizando o Pert:


Figura 14 Template para Estimativas de Esforo PERT Fonte: Ilog Tecnologia
Elaborar Proposta Comercial

55
O que e como realizada
Essa atividade consiste basicamente de preencher o template Proposta
Comercial com as informaes advindas do sistema de gerenciamento de
projetos. Essa tarefa objetiva criar o documento a ser enviado para o cliente
informando o valor a ser cobrado pelo projeto solicitado. Esse template foi
criado em reunies entre coordenador de projeto, diretor e gerente da
qualidade.

Encaminhar Proposta e Receber o Aceite Formal
O que so como realizada
Essas tarefas visam formalizar o meio como a proposta deve ser enviada ao
cliente e posteriormente como deve ser recebido o aceite do cliente para a
proposta enviada.
4.3.3 Planejamento do Projeto
O objetivo deste processo o planejamento do projeto em todas as suas etapas. Em um
futuro prximo espera-se utilizar o histrico de projetos j encerrados para um planejamento
mais preciso do projeto. Nesta etapa onde acontece o planejamento do sistema a ser
desenvolvido, o esforo, prazos, como ocorrer a monitorao do projeto. O processo de
Planejamento de Projeto mapeado pode ser visualizado na figura a seguir:

56


Figura 15 Processo de Planejamento de Projeto Fonte: Ilog Tecnologia

57
Planejar a Gerncia de Dados
O que e como realizada
Essa a primeira atividade do processo de Planejamento do Projeto, serve
como base para todas as prximas atividades, uma vez que orienta como
devem ser tratados os dados do projeto. Essa atividade visa garantir que os
dados do projeto sejam adequadamente coletados, armazenados e a forma
como devem ser acessados. Para essa atividade foi criada uma planilha, na
qual constam todos os artefatos utilizados ao longo de todo o processo
organizacional, sua localizao, formato, para que serve e permisses de
acesso. No processo de Planejamento de Projeto o Gerente de Projetos deve
selecionar os artefatos que sero utilizados ao longo do projeto e em seguida
excluir o que no ser utilizado. Todos os artefatos utilizados no processo
seguem as orientaes contidas nesse documento.
Dificuldades para definio desta tarefa no processo
A maior dificuldade constatada ao longo da execuo desta atividade foi a de
manter a planilha de dados atualizada quando o processo comeou a ser
utilizado, pois esse mudava freqentemente o que implicava em mudanas e
redefinies nos dados do projeto.
Resultado Esperado atendido
Essa atividade atende o resultado esperado GPR 9. Os dados relevantes do
projeto so identificados e planejados quanto forma de coleta,
armazenamento e distribuio. Um mecanismo estabelecido para acess-
los, incluindo, se pertinente, questes de privacidade e segurana.
Template Utilizado

Figura 16 Template para Plano de Gerncia de Dados Fonte: Ilog Tecnologia

58
Estabelecer Plano de Comunicao
O que e como realizada
Essa atividade pode se dizer que a continuao da atividade anterior,
Planejar a Gerncia de Dados, pois orienta como deve ocorrer a comunicao
entre as pessoas envolvidas no projeto. No Plano de Comunicao
encontram-se os mesmos artefatos listados no Plano de Gerncia de Dados,
seus responsveis, quem deve ser comunicado caso o artefato seja
modificado, o meio de comunicao a ser utilizado e o que o documento
proporciona. Na atividade Estabelecer Plano de Comunicao o Gerente de
Projetos deve selecionar os artefatos que sero utilizados no projeto, os
mesmos do plano de gerncia de dados, e preencher a coluna da
periodicidade que pode variar de projeto para projeto.
Dificuldades para definio desta tarefa no processo
Nessa atividade foram encontradas as mesmas dificuldades da atividade
anterior.
Resultado Esperado atendido
Essa atividade auxilia o atendimento do resultado esperado: GPR 14. O
envolvimento das partes interessadas no projeto gerenciado.
Template Utilizado
O template utilizado como Plano de Comunicao pode ser visualizado abaixo:

Figura 17 Template para Plano de Comunicao Organizacional Fonte: Ilog Tecnologia


59
Criar Plano de Projeto
O que e como realizada
Essa atividade orienta como criar o Plano de Projeto do projeto. Esse
documento contm as informaes do projeto relacionadas entre si. Ou seja,
nesse documento que o Gerente de Projeto ou qualquer outro papel
encontrar as informaes de que necessitada para executar o projeto.
Dificuldades para definio desta tarefa no processo
Quando o processo estava sendo definido houve dvidas sobre como
concentrar todas as informaes do projeto de templates e do sistema de
gerenciamento de projeto em um outro documento, se essas informaes
seriam duplicas. As dificuldades para manter a consistncia. Sendo assim,
optou-se por criar o plano de projeto com links para os templates e pginas
do sistema de gerenciamento de projetos, para que se evitasse inconsistncias
e sempre se tenha um plano de projeto atualizado.
Resultado Esperado atendido
A principal atividade atendida GPR. 10 Planos para a execuo do projeto
so estabelecidos e reunidos no Plano do Projeto.

Detalhar Requisitos
O que e como realizada
Nessa atividade o Analista de Sistemas complementa a atividade do Processo
de Fornecimento - Identificar Requisitos. nessa atividade que o Analista de
Sistemas identifica os casos de uso, matriz de rastreabilidade entre os
produtos de trabalho, prototipar as telas do sistema, identifica as regras de
negcio, identifica os fluxos base e fluxo de exceo do sistema, ou seja,
nessa atividade realizada a anlise do sistema. Essa atividade registrada
no sistema EA.
Dificuldades para definio desta tarefa no processo
A maior dificuldade para executar essa tarefa foi a falta de prtica com o
sistema EA e a falta de experincia em UML algumas vezes.

60
Resultado Esperado atendido
O resultado esperado do MPS.BR atendido com essa tarefa GRE 3. A
rastreabilidade bidirecional entre os requisitos e os produtos de trabalho
estabelecida e mantida

Detalhar Escopo
O que e como realizada
Essa atividade basicamente montar o Work Breakdown Strucutre WBS do
projeto. Nessa atividade o Gerente de Projetos deve, baseado no ciclo de
vida, documento de viso e detalhamento de requisitos do projeto identificar
quais atividades devem ser executadas em cada fase do ciclo de vida do
projeto. Essas atividades devem poder ser executadas com esforo entre 8 e
80 horas conforme sugere o Guia de Implementao do MPS.BR nvel G. O
WBS do projeto montado no sistema de gerenciamento de projetos pelo
Gerente de Projetos
Dificuldades para definio desta tarefa no processo
Ao foram sentidas dificuldades ao longo da execuo e definio desta tarefa.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado GPR 1. O escopo do trabalho
para o projeto definido.

Estimar Tamanho do Projeto
O que e como realizada
Essa atividade tem como objetivo dimensionar o tamanho do software a ser
desenvolvido, independente de se saber o esforo que ser necessrio para
desenvolv-lo. Essa atividade no processo da Ilog bastante simples, o
Gerente de Projetos deve registrar o nmero de atividades do WBS no Plano
de Projeto e depois quando o projeto encerrado deve ser registrado o
nmero de atividades do WBS em uma planilha, onde sero registradas a
mesma informao dos prximos projetos desenvolvidos pela Ilog. A tcnica

61
escolhida pela Ilog para obter o tamanho do software atravs do nmero de
atividades do WBS. Saber o tamanho do software atravs do nmero de
atividades do WBS no traz informao til, especialmente nos primeiros
projetos realizados de acordo com os processos desenvolvidos, j que no se
tem histrico de tamanhos de outros projetos. A idia de se obter o tamanho
do software atravs do nmero de atividades da WBS conseguir relacionar
o nmero de atividades do WBS com uma faixa de esforo para desenvolv-
lo. Dessa forma o Gerente de Projetos poderia obter a informao do tempo
necessrio para finalizar o projeto antes de saber o esforo para isso, ou de
acordo com a necessidade do projeto, saber se vantajoso aumentar a
capacidade de produo para determinado projeto ou no.
Dificuldades para definio desta tarefa no processo
A tcnica mais utilizada para estimar o tamanho do software a Anlise por
Ponto de Funo - APF. No comeo da Implantao a Ilog tentou-se utilizar
essa tcnica para obter o tamanho do software, mas foi verificado que seria
necessria maior maturidade para utiliz-la, ento se optou por mensurar o
tamanho do software atravs do nmero de atividades do WBS do projeto, at
que se tenha histrico e maturidade para utilizar a tcnica de Anlise por
Pontos de Funo.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado do MPS.BR GPR2 - As tarefas
e os produtos de trabalho do projeto so dimensionados utilizando mtodos
apropriados

Detalhar Estimativas
O que e como realizada
Nessa atividade realizada a estimativa de esforo para cada atividade a ser
realizada no projeto. O mtodo utilizado para isso o PERT, ou seja, um
especialista faz a estimativa pessimista, realista e otimista do esforo a ser
despendido para realizar as atividades. Essas medidas so aplicadas na
frmula do PERT e o esforo para cada atividade obtido.

62
Dificuldades para definio desta tarefa no processo
Mesmos problemas relatados para na atividade Definir Esforo, Durao e
Papis.
Resultado Esperado atendido
GPR 4 O esforo e o custo para a execuo das tarefas e dos produtos de
trabalho so estimados com base em dados histricos ou referncias tcnicas
Template Utilizado
Mesmo template utilizado na atividade Identificar Esforo, Papis e Durao
no processo de Fornecimento.

Estabelecer Cronograma de Atividades
O que e como realizada
Para cria o cronograma do projeto o Gerente de Projetos estabelece a
dependncia entre as atividades para poder determinar o menor tempo de
execuo do projeto. Aps essa etapa, o Gerente de Projetos estabelece as
datas para incio e fim de cada atividade. Essa etapa acontece no sistema de
gerenciamento de projetos, a partir da WBS previamente estabelecida.
Dificuldades para definio desta tarefa no processo
A maior dificuldade para realizar esta atividade estava no seqenciamento
das atividades direto no sistema gerenciamento de projetos, por uma s
pessoa. Ento se decidiu realizar essa atividade em uma reunio com
analistas de sistemas e alguns desenvolvedores para que esses juntos
estabelecessem a seqncia das atividades. Para essa reunio o Gerente de
Projetos escreve cada atividade em um papel, para que formem um WBS do
projeto ao final da reunio.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado GPR 5. O oramento e o
cronograma do projeto, incluindo marcos e/ou pontos de controle, so
estabelecidos e mantidos.


63
Planejar Riscos
O que e como realizada
A atividade de planejamento de riscos significa identificar o maior nmero de
possveis riscos aos quais o projeto estar exposto ao longo de sua execuo.
Para isso foi criada uma lista com os riscos mais comuns, que acessada pelo
Gerente de Projetos para que sejam selecionados os riscos aos quais o projeto
em planejamento estar exposto. Aps identificao dos riscos, o Gerente de
Projetos os registra no sistema de gerenciamento de projetos para que sejam
classificados quanto ao seu impacto, a probabilidade e a prioridade.
possvel registrar outros riscos alm dos da lista.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para criar a utilizar essa atividade.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado GPR 6. Os riscos do projeto so
identificados e o seu impacto, probabilidade de ocorrncia e prioridade de
tratamento so determinados e documentados.

Informar Marcos do Projeto ao Financeiro
O que e como realizada
Essa uma atividade interna da Ilog, serve basicamente para que o setor
financeiro acompanhe a situao do projeto e possa assim programa-se para
fazer as cobranas, caso necessrio.

Planejar e Alocar Infra-Estrutura
O que e como realizada
nessa atividade que o Gerente de Projetos deve planejar e alocar a infra-
estrutura necessria para o projeto. Essa atividade realizada baseada em um
checklist em que constam todos os recursos fsicos da Ilog.
O Gerente de Projetos deve registrar nesse documento as datas em que os
recursos sero utilizados e seus responsveis. Deve ainda acrescentar os

64
recursos especficos necessrios para o projeto em planejamento e em
seguida referenciar este checklist no Plano de Projeto. Uma das dificuldades
encontradas ao executar essa atividade foi listar todos os possveis softwares
a serem utilizados ao longo do projeto, assim como a infra-estrutura de rede
necessria para o projeto.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para criar ou executar essa atividade.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado: GPR 8. As tarefas, os recursos
e o ambiente de trabalho necessrios para executar o projeto so planejados.

Planejar e Alocar Recursos Humanos
O que e como realizada
Nessa atividade o Gerente de Projetos o Gerente de Projetos identifica qual
recurso tem o perfil e qualificaes para executar cada atividade do projeto.
Para executar essa atividade foram criados os seguintes documentos:
- Descrio de Papeis Documento que lista todos os papis na Ilog, suas
responsabilidades, e qualificaes necessrias para o cargo. O template
utilizado para criar este documento pode ser visualizado na Figura 18 abaixo.
- Mapa de Habilidades e Competncias: Relaciona as habilidades,
competncias e experincias anteriores dos recursos humanos da Ilog. O
template utilizado para criar este documento pode ser visualizado na Figura
19 abaixo
- Currculo dos Recursos: Contm informaes sobre os projetos que o
recurso j participou e reas de interesse de cada um
Baseado nesses documentos o Gerente de Projetos pode identificar o perfil e
competncias de cada recurso para realizar a atividade do projeto. Aps essa
etapa gerente de projetos deve marcar como alocados os recursos no sistema
gerenciador de projetos da empresa.

65
Dificuldades para definio desta tarefa no processo
A maior dificuldade dessa atividade manter os documentos atualizados a
medida que os recursos humanos passam por treinamentos.
Resultado Esperado atendido
Essa atividade atende ao resultado esperado GPR 7. Os recursos humanos
para o projeto so planejados considerando o perfil e o conhecimento
necessrios para execut-lo.
Template Utilizado
- Descrio de Papis:

Figura 18 Template para Descrio de Papis Fonte: Ilog Tecnologia


- Mapa de Habilidades e Competncias:

Figura 19 Template para Mapa de Habilidades e Competncias Fonte: Ilog Tecnologia

66

Estabelecer Oramento
O que e como realizada
Nessa atividade o Gerente de Projetos registra no sistema gerenciador de
projetos os custos levantados ao longo do planejamento da infra-estrutura e
outros itens como viagens e treinamentos para o projeto. No sistema
gerenciador de projetos esto registrados os custos-hora de cada recurso,
sendo assim, se o esforo para executar as atividades do processo for sabido,
conseqentemente sero sabidos os custos do projeto. Dessa forma o sistema
calcula o oramento do projeto.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para realizar essa atividade.
Resultado Esperado atendido
Essa atividade atende ao Resultado Esperado GPR 5. O oramento e o
cronograma do projeto, incluindo marcos e/ou pontos de controle, so
estabelecidos e mantidos.

Fazer Reunio de Comprometimento;
O que e como realizada
Essa a atividade que o Gerente de Projetos apresenta o Plano de Projeto
para a equipe do projeto, Cliente e Direo da Ilog. Essa atividade serve para
que as pessoas conheam o Plano de Projeto, discutam e sugiram
modificaes para em seguida registrar o seu comprometimento com o Plano
do Projeto. Essa atividade registrada em uma ata de reunio.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para realizar essa atividade.
Resultado Esperado atendido
O resultado esperado pelo MPS.BR atendido nessa etapa GPR 14. O
envolvimento das partes interessadas no projeto gerenciado.

67
Template Utilizado
Ata de Reunio de Comprometimento:


Figura 20 - Template para Ata de Reunio de Comprometimento Fonte: Ilog Tecnologia

4.3.4 Encerrar o Projeto
Esse processo descreve as atividades a serem realizadas sempre que se considera um
projeto encerrado. O objetivo principal deste processo fazer com que as informaes do
projeto encerrado possam ser usadas no planejamento de projetos futuros. As atividades
compreendidas nesse processo so:
Repassar Informaes do Projeto
O que e como realizada
Nessa atividade o Gerente de Projetos repassa ao Coordenador de Projetos
informaes sobre a execuo do projeto, para que este possa Coordenar a
Equipe sempre que forem necessrias manutenes e suporte ao projeto. Essa

68
atividade realizada atravs de uma reunio entre os dois gerentes e
registrada em uma ata de reunio.

Registrar Situao atual do projeto
O que e como realizada
O Gerente de Projetos deve registrar o esforo real realizado para executar o
projeto, os riscos ocorridos, quais foram as medidas de contingncia ou como
foi a mitigao dos riscos que no ocorreram. Quais foram os problemas
ocorridos ao longo do projeto e suas aes corretivas. Essa atividade ocorre
em uma reunio entre Gerente de Projeto e Gerente da Qualidade.

Registrar Lies Aprendidas
O que e como realizada
Nessa atividade o Gerente da Qualidade registra as lies aprendidas no
projeto no Sistema Gerenciador de Projetos para que sejam acessadas em
planejamentos de projetos futuros. Essa etapa tambm o momento em que
Gerente da Qualidade pode atualizar o processo ou templates com as
melhorias identificadas ao longo da execuo do processo.
4.3.5 Gerncia de Mudanas de Requisitos
O objetivo do processo de Gerncia de Requisitos assegurar que qualquer mudana nos
requisitos do sistema seja analisada de forma que o impacto das mudanas seja conhecido e
tratado. O processo de Gerncia de Mudana de Requisitos pode ser visualizado a seguir:

69


Figura 21 Processo de Gerncia de Mudana de Requisitos Fonte: Ilog Tecnologia

70
Classificar Solicitao
O que e como realizada
Nessa atividade o Gerente de Projetos deve classificar o pedido do cliente em
reporte de bug, dvida a respeito do projeto ou solicitao de mudana de
requisitos. De acordo com o pedido recebido o gerente de projetos deve dar o
devido encaminhamento. Que pode ser atende a solicitao do cliente, no
caso de bug ou dvida ou traduzir a solicitao em requisito quando a
solicitao do cliente for para mudana de requisito.

Atender a Solicitao do Cliente;
O que e como realizada
O Gerente de Projetos deve atender a solicitao do Cliente quando este pedir
esclarecimento sobre o projeto ou reportar bugs encontrados em possveis
primeiras verses do sistema previamente disponibilizadas.

Traduzir Solicitao em Requisito
O que e como realizada
Nessa atividade o Gerente de Projetos encaminha a solicitao de mudana
de requisitos para um Analista de Sistemas para que este traduza a solicitao
recebida em requisito. Para isso o Analista de Sistemas utiliza o checklist
Critrios de Aceitao de Requisitos, mesmo utilizado na atividade
Identificar Requisitos.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para executar essa atividade.
Resultado Esperado atendido
O resultado atendido com essa atividade GRE 2. Os requisitos de software
so aprovados utilizando critrios objetivos.


71
Fazer Anlise de Impacto
O que e como realizada
Nessa atividade o Analista de Sistemas e Gerente de Projetos analisam o
impacto que a mudana solicitada acarretar no Plano do Projeto. Aps
analisar o impacto, o Gerente de Projetos deve negociar com o cliente as
mudanas necessrias para atender a mudana de requisito solicitada.
Dificuldades para definio desta tarefa no processo
Essa atividade a mais complicada de ser realizar na processo de gerncia de
mudana de requisitos. Pois exige disciplina do Gerente de Projetos e Cliente
para que esses faam, registrem e negociem os impactos no Plano de Projeto
antes de realizar as mudanas solicitadas efetivamente.
Resultado Esperado atendido
GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas
visando identificar e corrigir inconsistncias em relao aos requisitos.
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.
Template Utilizado
Requisio de Mudana de Requisito

72

Figura 22 Template para Requisio de Mudana de Requisitos Fonte: Ilog Tecnologia

Realizar Negociao
O que e como realizada
A partir das informaes obtidas na Anlise de Impacto, Gerente de Projetos
e Fornecedor de Requisitos devem negociar as modificaes no Plano de
Projeto decorrentes da solicitao de mudana.
Dificuldades para definio desta tarefa no processo
Apesar de ser uma tarefa fcil de ser executada foi bastante penosa para ser
executada, uma vez que envolvia o Cliente e que este no tinha
disponibilidade para realiz-la. Exceto esse problema a tarefa sempre foi
executada sem maiores problemas.
Resultado Esperado atendido
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto
GPR 12. O Plano do Projeto revisado com todos os interessados e o
compromisso com ele obtido

73
Template Utilizado
Mesmo documento utilizado na atividade Fazer Anlise de Impacto.

Alterar Plano
O que e como realizada
Caso as modificaes discutidas na atividade Realizar Negociao forem
aceitas pelo Cliente, Gerente de Projetos e Analista de Sistemas devem
modificar Plano de Projeto para contemplar as modificaes requisitadas.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para realizar essa tarefa.
Resultado Esperado atendido
GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas
visando identificar e corrigir inconsistncias em relao aos requisitos

Documentar e Comunicar Stakeholders
O que e como realizada
O Gerente de Projetos deve comunicar a todos os envolvidos sobre as
mudanas ocorridas no Plano de Projeto e obter o comprometimento dos
mesmos com a nova verso do Plano de Projeto.
Dificuldades para definio desta tarefa no processo
A maior dificuldade para executar essa tarefa esteve em disciplinar as pessoas
para que sempre a executassem.

Obter Comprometimento com as Alteraes no Projeto
O que e como realizada
Sempre que o Plano de Projeto atualizado necessrio que os envolvidos
no projeto comprometam-se com a nova verso do Plano de Projeto.
Essa atividade realizada atravs de uma reunio com os envolvidos nas

74
atividades modificadas no Plano de Projeto.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para realizar essa atividade.
Resultado Esperado atendido
GPR 14. O envolvimento das partes interessadas no projeto gerenciado.

4.3.6 Monitorao do Projeto
O processo de monitorao do projeto visa garantir que o projeto esta seguindo o que
foi planejado e que os problemas encontrados sejam tratados. O processo de monitorao
pode ser visualizado na figura a seguir:

75

Figura 23 Processo de Monitorao de Projetos Fonte: Ilog Tecnologia
Monitorar o Plano
O que e como realizada
Essa atividade tem como objetivo, orientar ao Gerente de Projetos como verificar se a execuo do projeto est de acordo com o
planejamento realizado. Para essa atividade o Gerente de Projetos deve observar os indicadores de projeto como andamento do cronograma,
custos do projeto, esforo, aderncia ao processo, aes corretivas, gerncia dos dados e envolvimento dos interessados. Essas informaes
(Planejadas e Realizadas) devem ser registradas no template chamado Status Report. A partir do preenchimento desse template o Gerente de
Projetos deve realizar uma reunio com o time do projeto. Nessa atividade podem ser abertas aes corretivas de acordo com as diferenas
entre a situao atual e planejada para o momento. Para cada um dos itens verificados em cada status report existe um critrio para que seja
aberta uma ao corretiva. Esses critrios so especificados no Plano de Projeto. A periodicidade para realizar as monitoraes definida
no Plano de Projeto.


76
Dificuldades para definio desta tarefa no processo
A principal dificuldade sentida ao executar essa atividade foi a falta de
disciplina para execut-la na periodicidade estipulada. Assim como a demora
para preencher o template sobre a situao planejada e realizada, j que a
ferramenta de gerenciamento de sistemas no tem essa funcionalidade.
Resultado Esperado atendido
GPR 15. Revises so realizadas em marcos do projeto e conforme
estabelecido no planejamento.
GPR 16. Registros de problemas identificados e o resultado da anlise de
questes pertinentes, incluindo dependncias crticas, so estabelecidos e
tratados com as partes interessadas.

Fazer Revises em Marcos
O que e como realizada
As revises em marcos so as monitoraes do projeto direcionadas para a
direo da Ilog e Cliente. Sempre que possvel, as entregas do projeto eram
realizadas nas datas marcadas como marcos do projeto. nessa etapa
tambm que anlise de viabilidade para dar continuidade no projeto
verificada. Essa atividade realizada atravs de reunio e registrada em um
ata de reunio. A direo e cliente do projeto nem sempre precisam participar
dos marcos do projeto, uma vez que eles podem acontecer frequentemente e
no haver novidades para a direo e cliente. o gerente de projeto quem
decide se ocorrer a reunio no marco ou no. Essa atividade atende ao
resultado
Dificuldades para definio desta tarefa no processo
Mesmas dificuldades para realizar a atividade Monitorar o Projeto
Resultado Esperado atendido
GPR 5. O oramento e o cronograma do projeto, incluindo marcos e/ou
pontos de controle, so estabelecidos e mantidos.

77
Template Utilizado
Para registrar que o marco ocorreu ou est planejado utilizado o mesmo
template das reunies de monitorao/status report.

Estabelecer Aes Corretivas
O que e como realizada
Essa atividade visa dar o correto encaminhamento aos problemas encontrados
ao longo da execuo do projeto. Nessa atividade o gerente de projetos
registra no template Aes Corretivas os problemas considerados
significativos no projeto, ou seja, os problemas que podem ter impacto
significativo no planejamento do projeto. Nesse template o Gerente de
Projetos registra o problema ocorrido, o que ser feito para resolv-lo, a
anlise das causas, prazos, responsveis e o que foi efetivamente realizado
para resolver a causa do problema e o problema ocorrido.
Dificuldades para definio desta tarefa no processo
A principal dificuldade ao realizar essa atividade foi a de que o template para
registro das aes corretivas ficou maante para ser preenchido devida a
anlise de causas e registro de verificaes da eficcia da ao corretiva
executada. Por isso o template foi simplificado de forma que a ao corretiva
continuasse atendendo ao MPS.BR nvel G e que no ficasse to complicada
para ser registrada.
Resultado Esperado atendido
GPR 16. Registros de problemas identificados e o resultado da anlise de
questes pertinentes, incluindo dependncias crticas, so estabelecidos e
tratados com as partes interessadas.

Revisar Plano de Projeto
O que e como realizada
Essa atividade serve para orientar o Gerente de Projetos como proceder para
atualizar o Plano de Projeto sempre que as aes corretivas influenciarem

78
algum dos itens do Plano de Projeto.
Dificuldades para definio desta tarefa no processo
No houve dificuldades para realizar essa tarefa.
Resultado Esperado atendido
GPR 10. (At o nvel F). Planos para a execuo do projeto so
estabelecidos e reunidos no Plano do Projeto.

4.3.7 Atributos de Processo
No nvel G do MPS.BR os dois atributos de processo e seus resultados esperados so:
AP 1.1 O processo executado
RAP 1. O processo atinge seus resultados definidos.
Para esse resultado no foram listados os artefatos, basta verificar se o processo
atinge seus resultados esperados.

AP 2.1 O processo gerenciado
RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo.
Foram criadas polticas organizacionais para os processos de Gerncia de
Projetos e Gerncia de Requisitos na Ilog. Esses artefatos atendem ao RAP 2.

RAP 3. A execuo do processo planejada.
Esse resultado pode ser visualizado atravs dos artefatos que registram as
atividades referentes ao processo, como: estimar esforo, realizar reunies de
monitorao ou realizar o processo de gerncia de requisitos no cronograma
do projeto.

RAP 4. A execuo do processo monitorada e ajustes so realizados para atender
aos planos.
Esse resultado atendido quando nas reunies de monitorao so registradas as

79
verificaes se as tarefas referentes ao processo esto sendo realizadas conforme
o planejado. Isso pode ser visualizado nas atas de reunio de monitorao.

RAP 5. Os recursos necessrios para a execuo do processo so identificados e
disponibilizados.
Para atender a esse resultado, preciso mostrar que os recursos necessrios para
executar o processo esto disponveis. Nesse caso pode-se mostrar que existe
pelo menos um recurso humano para executar o processo e que esse recurso tem
ao seu dispor a infra-estrutura necessria para isso.

RAP 6. As pessoas que executam o processo so competentes em termos de
formao, treinamento e experincia.
Esse resultado pode ser visualizado em um documento que descreva as
habilidades e competncias que o recurso humano precisa ter para assumir
determinado papel e um outro documento que registre as habilidades e
competncias que o recurso humano tem. Se o recurso humano que executa
as atividades do processo tenha as competncias e habilidades requisitadas o
resultado esperado pode ser considerado atendido.

RAP 7. A comunicao entre as partes interessadas no processo gerenciada de
forma a garantir o seu envolvimento no projeto.
Esse resultado atendido quando se mostra que o Plano de Comunicao da
empresa foi seguido. Para isso pode-se mostrar um registro de comunicao
programada para acontecer que tenha ocorrido conforme esperado.

RAP 8. Mtodos adequados para monitorar a eficcia e adequao do processo so
determinados.
Esse resultado atendido quando na monitorao do projeto ou no decorrer do
projeto detectam-se melhorias ou correes a serem realizadas nos processos da
empresa. Os registros dessa mudana so os artefatos esperados para atender a
esse resultado de atributo de processo. Dentre esses artefatos podem

80
ser citados a ata de monitorao, as verses do processo antes e depois da
mudana ou as comunicaes de mudana do processo.
4.4 Avaliao
A avaliao oficial do MPS.BR ocorrer em duas etapas, conforme guia da avaliao do
modelo, na primeira etapa o avaliador analisar a planilha que contm todos os artefatos
gerados ao longo da execuo do processo. Esses artefatos so relacionados a cada resultado
esperado do modelo. dessa forma que o avaliador verificar se os resultados esperados
esto sendo atendidos pelo processo. No final da avaliao o avaliador relatar os resultados
requeridos pelo modelo, mas que no podem ser considerados atendidos atravs artefatos
verificados.
A Ilog ter um prazo para resolver os problemas apontados pelo avaliador. Aps esse
perodo, o avaliador verificar se os itens apontados na primeira etapa foram corrigidos.
Alm disso, ocorrero entrevistas com funcionrios que participaram do projeto
avaliado, para que o avaliador verifique se o processo entendido e realizado por todos
da mesma forma.
4.5 Ferramentas Utilizadas
4.5.1 Eclipse Process Framework EPF
A ferramenta utilizada para dar apoio criao e manuteno dos processos na Ilog, foi
o Eclipse Process Framework, o EPF. uma ferramenta livre criada pela Eclipse
Foundation, bastante flexvel, uma vez que possibilita que o usurio crie a prpria estrutura
para criar os processos. No caso da Ilog a estrutura do processo ficou organizada conforme a
seguir:

81

Figura 24 Estrutura de Dados de Desenvolvimento de Processo Fonte: Ilog Tecnologia
4.5.2 JExpChannel
O J ExpChannel foi a ferramenta utilizada para o Gerenciamento de Projetos. Esse
sistema foi desenvolvido pela empresa J Experts e ao longo da implantao a J Experts
adequou muitas das funcionalidades do J ExpChannel para que atendessem aos resultados
esperados do MPS.RB nvel G, o que facilitou a implantao dos processos. As principais
atividades do processo realizadas no J ExpChannel foram:
Termo de Abertura;
Ciclo de Vida;
Proposta Comercial;

82
Cronograma;
Oramento;
Recursos Humanos;
Informaes para Status Report;
Monitorao;
Aes Corretivas;
Abaixo est um screenshot de uma tela do J ExpChannel:

Figura 25 Relatrio de Alocao de Recursos no J ExpChannel. Fonte: [35]
4.5.3 SVN
O SVN foi o sistema escolhido para controle de verses dos documentos do processo.
4.5.4 Pacote Microsoft Office
O pacote Microsoft Office foi muito utilizado ao longo do detalhamento do processo,
uma vez foi utilizado para criao e utilizao dos templates e demais documentos do
processo.

83

4.5.5 Enterprise Architect
O Enterprise Architect, o EA foi o sistema utilizado para desenvolver a modelagem do
sistema assim com realizar o processo de gerncia de mudana de requisitos. Neste sistema
ficavam os seguintes artefatos:
Matriz de Rastreabilidade (entre requisitos, casos de uso e documento de viso);
Lista de Requisitos do Sistema;
Diagrama de Classes;
Casos de Uso do Sistema;


84
5 Concluses
A implantao do MPS.BR uma excelente oportunidade para a indstria de software
brasileiro, que h muito tempo convive com o caos no processo de desenvolvimento de
software devido a falta de um modelo que se adequasse a sua realidade. Seja devido aos
preos elevados ou ao prprio modelo, incompatvel com o contexto de pequenas e mdias
empresas. Em um futuro prximo o MPS.BR pode ser a base para o aumento da
competitividade brasileira na indstria de software no mundo, devida a compatibilidade
deste com o CMMI.
CMMI uma barreira para que empresas de at mdio porte no concorram com as
empresas de grande porte.
Apesar de ter sido criado com o foco na realidade de pequenas e mdias empresas, a
implantao e especialmente a manuteno do MPS.BR implantado no uma tarefa trivial
uma vez que precisa modificar a cultura e forma de trabalho de profissionais, na maioria das
vezes, experientes. Muitas vezes a equipe no entende a razo de se ter que realizar
determinadas atividades do processo devido ao tamanho da empresa. Um exemplo dessa
dificuldade foi a disciplina para registro de comunicaes entre a equipe, uma vez que
mais rpido virar-se para o lado e conversar com o colega do que escrever um documento
com a mesma comunicao.
A implantao do nvel G na Ilog trouxe muitos benefcios empresa e
conseqentemente a seus clientes.
A maior dificuldade aps a implantao foi manter o processo rodando quando os
projetos apresentam problemas, ou seja, convencer as pessoas para que mantivessem a
disciplina para executar o processo, mesmo em momentos de crise nos projetos.
Dentre os benefcios observados podem ser destacados a maior previsibilidade do que
seria feito tanto para a Ilog quanto para o Cliente. O controle de ambos sobre o que est
acontecendo no projeto. Assim como a agilidade para atender aos requisitos para participar
de concorrncias pblicas (licitaes), devido a documentao existente advinda do
processo.
Uma outra questo interessante foi a introduo das tcnicas de modelagem de
sistemas mais detalhada, de forma que seja possvel ter uma documentao tcnica dos
sistemas desenvolvidos completa.

85
Foi muito importante o apoio da Direo da Ilog no processo, alm disso, pode-se
perceber que os funcionrios estavam satisfeitos com o trabalho realizado, a cada nova
mudana eles participavam, e sempre sugeriam melhorias.
A proximidade com a instituio implementadora foi fundamental para que a
implantao ocorresse.

5.1 Trabalhos Futuros
Implantao dos demais nveis do MPS.BR;
Integrao dos templates, que contm as informaes necessrias para atender ao
modelo, aos sistemas da empresa;
Realizar a Garantia da Qualidade nos projetos desenvolvidos pela empresa;
Manuteno evolutiva dos processos existentes;
Automatizao das tarefas operacionais geradas pelo processo;

86
Referncias Bibliogrficas
Crise do Software
[24] Thayer, Richard H. Christensen, Mark J . Software Engineering. J ohn Wiley &
Sons, 2005.
[25] A Crise do Software. Disponvel em
http://letshyve.wordpress.com/2007/04/25/artigo-a-crise-do-software/ acessado em
maro de 2008.
[26] Sisson, Martin Chito. Avaliao e Melhorias no Processo de Construo de
Software. UFSC 2007.

12207
[1] Schmidt, Michael E.C. Implementing the IEEE Software Engineering Standards,
SAMS, 2000.
[2] UNESP Apresentao Viso Geral da Norma ISO/IEC 12207, 2006.
[3] Evans, Isabel. Achieving Software Quality through Teamwork. Artech House,
2004.
[4] NBR ISO/IEC 12207 Tecnologia de Informao Processos de Ciclo de Vida
de Software: 1998.
[19] Contart, Solues em Engenharia e Gesto - Ciclo de Vida Incremental.
Disponvel em http://www.dromostg.com.br/sol_engsoft3_4.aspx , acessado em
novembro de 2007.
[20] Rational Software Corporation. Conceitos Iterao .Disponvel em
http://www.wthreex.com/rup/process/workflow/manageme/co_phase.htm, acessado em
novembro de 2007.
[21] Prado, Moacir de Sousa. Engenharia de Software. Disponvel em
http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html, acessado em novembro de
2007.
[22] Engenharia de Programao. Disponvel em
http://w3.ualg.pt/~pventura/ep/aulas_tp/t1_g5.pdf, acessado em novembro de 2007.

87

[31] McConnell, Steve. Rapid Development: Taming Wild Software Schedules.
Microsoft Press. 1996.
[36] Figura Arquitetura Geral do RUP. Disponvel em:
http://pts.datasus.gov.br/processos/fluxos/tst_conceitosbasicos.htm, acessada em julho
de 2008.

15504
[6] Bustard, David. Kawalek, Peter. Norris, Mark. Systems Modeling for Business
Process Improvement, Artech House Boston, 2000.
[7] Fernandes, J orge. Apresentao Spice e ISO 15504, 2004. Disponvel em
http://www.cic.unb.br/~jhcf/MyBooks/iess/SPICE/SPICE-26slides.pdf, acessado em
novembro de 2007.
[9] ISO/IEC TR 15504-2:1998(E) - Information technology Software process
assessment Part 2: A reference model for processes and process capability.
1998.
[32] Bustard, David. Kawalek, Peter. Norris, Mark. Systems Modeling for Business
Process Improvement. Artech House. 2000.

CMMI
[8] Fagundes, Eduardo Mayer. Capability Maturity Model for Software. Disponvel
em http://www.efagundes.com/artigos/CMM.htm, acessado em novembro de 2007.
[11] Paulk, Mark C. Weber, Charles V. Garcia, Suzanne M. Chrissis, Mary Beth.
Bush, Marilyn. Key Practices of the Capability Maturity ModelSM, Version 1.1 -
Technical Report - CMU/SEI-93-TR-025 - ESC-TR-93-178. 1993.
[27] Lahoz, Carlos. SantAnna, Nilson. Os Padres ISO/IEC 12207 e 15504 e a
Modelagem de Processos da Qualidade de Software. 2003.
[10] Software Engineering Institute. Improving processes for acquiring better
products and service. CMMI for Acquisition, Version 1.2, November 2007.
Technical Report CMU/SEI-2007-TR-017 - ESC-TR-2007-017.

88

MPS.BR
[12] SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia
Geral, J unho 2007, Verso 1.2. Disponvel em http://www.softex.br/mpsbr/_guias/.
Acessado em novembro de 2007.
[13] SOFTEX, MPS-BR - Melhoria de Processo do Software Brasileiro, Guia de
Implementao Parte 1 Nvel G, Dezembro de 2006b. Disponvel em
http://www.softex.br/mpsbr/_guias/. Acessado em novembro de 2007.
[33] Thiry, Marcello. Gerncia de Projeto Projeto Cooperado MPS.BR ACATE
2007/2008. 2007.
EPF
[19] IBM Rational. The Eclipse Process Framework Project. Disponvel em
http://www.ibm.com/developerworks/rational/library/05/1011_kroll/ Acessado em
30/03/08.
JExpChannel
[35] Disponvel em www.jexperts.com.br. Acessado em maio de 2008.