Apostila Gerencia de Projetos de Software

CURSO DE PS-GRADUAO
LATO SENSU (ESPECIALIZAO) A

DISTNCIA
MELHORIA DE PROCESSO DE SOFTWARE
LIVRE
Gerncia de Projetos
de Software
Ana Cristina Rouiller
Universidade Federal de Lavras - UFLA

Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE
Lavras MG
Parceria
Universidade Federal de Lavras - UFLA
Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE
Reitor
Antnio Nazareno Guimares Mendes
Vice-Reitor
Elias Tadeu Fialho
Diretor da Editora
Marco Antnio Rezende Alvarenga
Pr-Reitor de Ps-Graduao
Joel Augusto Muniz
Pr-Reitor Adjunto de Ps-Graduao Lato Sensu
Marcelo Silva de Oliveira
Coordenao do curso
Ana Cristina Rouiller
Guilherme Bastos Alvarenga
Marcelo Silva de Oliveira
Presidente do Conselho Deliberativo da FAEPE
Luiz Antnio Lima
Editorao
Centro de Editorao Quality Group
Impresso
Grfica Universitria/UFLA
Ficha Catalogrfica Preparada pela Diviso de Processos Tcnicos da
Biblioteca Central da UFLA
Rouiller, Ana Cristina

Gerncia de Projetos de Software/Ana Cristina Rouiller.
Lavras: UFLA/FAEPE, 2008.
85 p.:il. (Curso de Ps-graduao Lato

Sensu (Especializao) a Distncia Produo de Software (com
nfase em Software Livre)
Bibliografia
1. Sistema de informao. 2. Tecnologia de informao. 3.

Gerenciamento de software. 4. Software. 5. Projeto. 6. Gerncia. I.
Universidade Federal de Lavras. II. Fundao de Apoio ao Ensino,
Pesquisa e Extenso. III. Ttulo.
Nenhuma parte desta publicao pode ser reproduzida,

por qualquer meio, sem a prvia autorizao da FAEPE.
SUMRIO
Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE....................................................................................2
Parceria..........................................................................................................145
Reitor ............................................................................................................145
Vice-Reitor.....................................................................................................145
Diretor da Editora...........................................................................................145
Pr-Reitor de Ps-Graduao.......................................................................145
Pr-Reitor Adjunto de Ps-Graduao Lato Sensu....................................145
Coordenao do curso..................................................................................145
Presidente do Conselho Deliberativo da FAEPE .........................................145
Editorao .....................................................................................................145
Impresso......................................................................................................145
145
Introduo 7
1.1 Projeto e a Gerncia de Projetos..........................................................................9
1.2 Motivao e Relevncia da Gerncia de Projetos..............................................10
1.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11
1.4 Estrutura do Mdulo............................................................................................12
Modelos, Padres e Normas e a Gerncia de PRojetos 14
2.1 Processos de Gerenciamento da ISO/IEC15504................................................14
2.2 PMBOK................................................................................................................18
2.2.1 Gerncia de integrao de projetos........................................................19
2.2.2 Gerncia de escopo de projetos..............................................................20
2.2.3 Gerncia de tempo de projetos...............................................................21
2.2.4 Gerncia de custo de projetos.................................................................21
2.2.5 Gerncia da qualidade de projetos.........................................................22
2.2.6 Gerncia de recursos humanos de projetos...........................................22
2.2.7 Gerncia de comunicao de projetos....................................................22
2.2.8 Gerncia de risco de projetos..................................................................23
2.2.9 Gerncia de aquisio de projetos..........................................................23
2.3 Modelagem do Sistema de Processos dE Empresa de Software......................24
2.4 Elementos essenciais para criar um processo de gerncia de projetos.............25
2.5 Consideraes.....................................................................................................27
Poltica Organizacional e Padres ADotados para A definio do ProGer 30
3.1 pOLTICA oRGANIZACIONAL Considerada para o ProGer..............................30
3.1.1 Caracterizao da empresa....................................................................30
3.1.2 Metas pretendidas com a gerncia de projetos......................................32
3.2 Modelos, NOrmas e Padres Utilizados para a Definiao do ProGer................32
ProGER: Processo de Gerncia de Projetos de Software 36
4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................36
4.1.1 Controle e avaliao................................................................................39
4.2 Stakeholders .......................................................................................................41
4.3 Artefatos .............................................................................................................42
4.3.1 Documento de requisitos.........................................................................44
4.3.2 Proposta tcnica......................................................................................48
4.3.3 Proposta Comercial ................................................................................50
4.3.4 Plano de Projeto......................................................................................52
4.3.5 Relatrio de teste.....................................................................................55
Nome 55
Assinatura 55
4.3.6 Ata de reunio.........................................................................................55
4.3.7 Relatrio de visitas tcnicas....................................................................56
RELATRIO VISITA TCNICA.......................................................................58
Solicitante: 58
Data Solicitao: 58
Local: 58
Data Entrega Servio: 58
Problema / Requisio...............................................................................................................................................58
Nome 58
Assinatura 58
4.3.8 Relatrio de aceite...................................................................................58
4.3.9 Ordem de Servio....................................................................................60
ORDEM DE SERVIO....................................................................................60
Solicitante: 60
Data Solicitao: 60
Local: 60
Data Entrega Servio: 60
Nome 60
Assinatura 60
4.4 Fluxos de Trabalho .............................................................................................60
4.4.1 Fluxo de captao de projetos................................................................61
4.4.2 Fluxo de execuo de projetos ...............................................................65
4.4.3 Fluxo de avaliao de projetos................................................................69
4.5 Consideraes ....................................................................................................71
Ferramentas para APOIO Automatizado ao ProGer 65
5.1 Ferramentas Utilizadas em Conjunto com o ProGer..........................................67
5.1.1 Microsoft Word ........................................................................................67
5.1.2 Microsoft Project .....................................................................................67
5.1.3 Microsoft excel.........................................................................................68
5.1.4 Mantis......................................................................................................68
5.1.5 FreeVCS..................................................................................................69
5.1.6 Microsoft outlook......................................................................................69
5.1.7 Microsoft Windows Live Messenger........................................................69
5.1.8 Base de acompanhamento de projetos...................................................70
CONCLUSO 77
REFERNCIAS BIBLIOGRFICAS 79
APNDICE A 86
APNDICE B 1
LISTA DE FIGURAS
FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de
projeto e engenharia do produto 8
FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504 15
FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19
FIGURA 2.3 reas do gerenciamento de projetos do PMBOK 20
FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de
software 24
26
FIGURA 2.5 Modelo para criao de processo de gerenciamento de projetos de
software 26
FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva 31
FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37
FIGURA 4.2 Ciclo PDCA de controle de processos 40
FIGURA 4.3 Organograma sugerido 42
FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43
TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos
projetos 43
TABELA 4.2 Sugesto de padro para nomeao dos artefatos 43
FIGURA 4.5 Sugesto de contedo para um documento de requisitos 47
FIGURA 4.6 Sugesto de contedo para uma proposta tcnica 50
FIGURA 4.7 Contedo para uma proposta comercial 52
FIGURA 4.8 Sugesto de contedo para um plano de projeto 55
FIGURA 4.9 Modelo de relatrio de teste 55
FIGURA 4.10 Modelo de ata de reunio 56
FIGURA 4.11 Modelo de relatrio de visita tcnica 57
FIGURA 4.12 Modelo de relatrio de aceite 58
FIGURA 4.13 Modelo de uma ordem de servio 59
FIGURA 4.14 Primitivas do flowchart 60
FIGURA 4.15 Resumo do fluxo de captao de projetos 61
TABELA 4.3 Sugesto de categorizao de nveis de profissionais para uma
empresa de pequeno porte 62
FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto
63
TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos 63
FIGURA 4.17 Resumo do fluxo de execuo de projeto 65
66
TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos 67
FIGURA 4.19 Resumo do fluxo de execuo de projetos 68
TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos 69
TABELA 4.7 Relao de alguns procedimentos do proger e as reas de
conhecimento do PMBOK. 70
FIGURA 5.1 Viso do cadastramento de projetos 71
FIGURA 5.2 Viso do cadastramento de fases do projeto 71
FIGURA 5.3 Viso do cadastramento de macro-atividades 72
73
FIGURA 5.4 Viso do apontamento de horas nas macro-atividades 73
74
FIGURA 5.5 Viso de projetos por fase e cliente 74
74
FIGURA 5.6 Viso das horas gastas nos projetos 74
FIGURA 5.7 Uma viso das horas gastas por colaborador 75
75
FIGURA 5.8 Viso diria do trabalho do executor 75
LISTA DE TABELAS
projeto e engenharia do produto 8
FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504 15
FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19
FIGURA 2.3 reas do gerenciamento de projetos do PMBOK 20
software 24
26
software 26
FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva 31
FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37
FIGURA 4.2 Ciclo PDCA de controle de processos 40
FIGURA 4.3 Organograma sugerido 42
FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43
projetos 43
TABELA 4.2 Sugesto de padro para nomeao dos artefatos 43
FIGURA 4.5 Sugesto de contedo para um documento de requisitos 47
FIGURA 4.6 Sugesto de contedo para uma proposta tcnica 50
FIGURA 4.7 Contedo para uma proposta comercial 52
FIGURA 4.8 Sugesto de contedo para um plano de projeto 55
FIGURA 4.9 Modelo de relatrio de teste 55
FIGURA 4.10 Modelo de ata de reunio 56
FIGURA 4.11 Modelo de relatrio de visita tcnica 57
FIGURA 4.12 Modelo de relatrio de aceite 58
FIGURA 4.13 Modelo de uma ordem de servio 59
FIGURA 4.14 Primitivas do flowchart 60
FIGURA 4.15 Resumo do fluxo de captao de projetos 61
empresa de pequeno porte 62
63
TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos 63
FIGURA 4.17 Resumo do fluxo de execuo de projeto 65
66
TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos 67
FIGURA 4.19 Resumo do fluxo de execuo de projetos 68
TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos 69
conhecimento do PMBOK. 70
FIGURA 5.1 Viso do cadastramento de projetos 71
FIGURA 5.2 Viso do cadastramento de fases do projeto 71
FIGURA 5.3 Viso do cadastramento de macro-atividades 72
8 EDITORA UFLA / FAEPE Gerncia de Projetos de Software
73
FIGURA 5.4 Viso do apontamento de horas nas macro-atividades 73
74
FIGURA 5.5 Viso de projetos por fase e cliente 74
74
FIGURA 5.6 Viso das horas gastas nos projetos 74
FIGURA 5.7 Uma viso das horas gastas por colaborador 75
75
FIGURA 5.8 Viso diria do trabalho do executor 75
1
INTRODUO
A Engenharia de Software tem por finalidade auxiliar na construo de software

da melhor maneira possvel [Pressman1995]. Desde os anos 1960, quando a frase
the software crisis foi pronunciada, muitos problemas desta rea foram identificados,
e muitos deles ainda persistem, tais como [Gibbs1994]:
Previso pobre desenvolvedores no prevem adequadamente quanto
tempo e esforo sero necessrios para produzir um sistema de software
que satisfaa s necessidades (requisitos) dos clientes/usurios. Sistemas
de software so geralmente entregues muito tempo depois do que fora
planejado;
Programas de baixa qualidade programas de software no executam o
que o cliente deseja, conseqncia, talvez, da pressa para se entregar o
produto. Os requisitos originais podem no ter sido, completamente,
especificados ou podem apresentar contradies e isto pode ser descoberto
muito tarde durante o processo de desenvolvimento;
Alto custo para manuteno a manuteno pode ser corretiva, quando
ocorrem enganos (erros, falhas) no sistema j entregue, ou evolutiva quando
novas caractersticas so adicionadas ao sistema de software. Ambas so
caras quando o sistema original foi construdo sem uma arquitetura clara e
visvel;
Duplicao de esforos difcil compartilhar solues ou reusar cdigos,
em funo das caractersticas de algumas linguagens adotadas, por falta de
confiana no cdigo feito por outra pessoa e at mesmo pela
ausncia/deficincia de documentao das rotinas e dos procedimentos j
construdos.
Para solucionar alguns destes problemas muitas empresas de software tm

adotado metodologias de desenvolvimento de software. Todavia, os paradigmas
metodolgicos para desenvolvimento de software tm sido considerados somente em
termos de um mtodo de anlise/projeto/implementao, isto , um conjunto de
conceitos, tcnicas e notaes. Esta viso elimina os aspectos tecnolgicos,
contextuais e organizacionais que potencialmente existem dentro de um processo de

software.
De forma geral, podemos dividir as funes de uma empresa de software em

trs grupos principais [Garg1996]:
definir, analisar, simular, medir e melhorar os processos da organizao;
construir o produto de software;
medir, controlar, modificar e gerenciar os projetos de software.
Estes trs grupos so abordados, respectivamente, pela engenharia do

processo, pela engenharia do produto e pelo gerenciamento de projeto. O
relacionamento entre estes grupos mostrado na Figura 1.1 [Garg1996].
A engenharia do produto encarregada do desenvolvimento e manuteno

dos produtos e servios de software. A principal figura da engenharia do produto a
metodologia de desenvolvimento, que engloba uma linguagem de representao, um
modelo de ciclo de vida e um conjunto de tcnicas. Os ambientes tradicionais de
desenvolvimento de software tm se preocupado essencialmente com a engenharia
do produto, assumindo um processo implcito e tendo como foco o produto. Todavia,
a engenharia do produto por si s insuficiente para suprir as necessidades de uma
organizao que desenvolve software e torn-la mais produtiva e adequada s
exigncias do mercado.
Experincias passadas
Requisitos do processo
Engenharia do
processo
Requisitos do projeto
Modelo do Requisitos do produto
processo
Gerenciamento de
projeto
Processo de
desenvolvimento
Engenharia do
produto
Produto de
software

projeto e engenharia do produto
Introduo 9
A engenharia de processo tem como metas a definio e a manuteno dos

processos de uma organizao. Ela deve ser capaz de facilitar a definio, a anlise
e a simulao de um processo, assim como estar apta a implant-lo, avali-lo, medi-
lo e melhor-lo. A engenharia de processo pode ser vista como uma extenso da
funo tradicional da garantia de qualidade e trata os processos de software de uma
forma sistemtica, com um ciclo de vida bem definido. Contudo, a grande maioria das
organizaes que desenvolvem software sente muita dificuldade em entender, definir
e gerenciar estes processos. As empresas de software devem buscar os seus
prprios ambientes para existirem e operarem. Abordagens da indstria
manufatureira, por exemplo, no tm demonstrado serem adequadas indstria de
software.
O gerenciamento de projeto objetiva assegurar que processos particulares

sejam seguidos, coordenando e monitorando as atividades da engenharia do produto.
Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e
monitorar as atividades, as tarefas e os recursos necessrios para um projeto
produzir um produto e/ou servio, de acordo com seus requisitos. Todavia, gerenciar
projetos de software uma atividade complexa devido a uma srie de fatores, tais
como: dinamicidade do processo, grande nmero de variveis envolvidas, exigncia
de adaptabilidade ao ambiente de desenvolvimento e constantes alteraes no que
foi planejado. Estes fatores dificultam o trabalho das equipes de desenvolvimento na
medio do desempenho dos projetos, na verificao de pontos falhos, no registro de
problemas, na realizao de estimativas e planejamentos adequados.
Este mdulo se concentra nas reas de engenharia de processo e

gerenciamento de projetos.
1.1 PROJETO E A GERNCIA DE PROJETOS
Um projeto pode ser definido como um empreendimento temporrio com o

objetivo de criar um produto, servio ou resultado nico [PMBOK2000] A
temporalidade de um projeto significa que um projeto deve possuir um inicio e um fim
definido e estabelecido. O final pode ser quando os objetivos do projeto forem
alcanados, ou quando ele cancelado (por se chegar a uma concluso de que os
objetivos no podero ser alcanados ou pela mudana das necessidades).
A meta da gerncia de projetos conseguir exceder as necessidades e

expectativas dos stakeholders1[PMBOK2000]. Todavia, satisfazer ou exceder estas
necessidades envolve um balanceamento entre as vrias demandas concorrentes em
relao aos itens abaixo:
escopo, tempo, custo e qualidade (objetivos do projeto);
1
Stakeholders so os indivduos ou as organizaes que esto ativamente envolvidos em um projeto,
cujos interesses podem afetar positivamente ou negativamente o resultado da execuo do projeto [PMBOK2000].
stakeholders com necessidades e expectativas diferenciadas; e

requisitos identificados (necessidades) e requisitos no identificados
(expectativas).
1.2 MOTIVAO E RELEVNCIA DA GERNCIA DE PROJETOS
Alguns estudos e pesquisas que foram realizados nos anos 1990 demonstraram
que o gerenciamento de projeto a causa mais evidente das falhas na execuo e
entrega de produtos e servios de software. O SEI-Software Engineering Institute
constatou, j em 1993, que o principal problema que aflige as organizaes de
software gerencial e preconizou que: as organizaes precisam vencer o seu
buraco negro que o seu estilo de gerenciar de maneira informal, sem mtodos e
sem tcnicas [Paulk1993].
Um estudo conduzido pelo DoD-Department of Defense [DOD1994] indicou que

75% de todos os sistemas de software falham e que a causa principal o pobre
gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o
problema no de desempenho tcnico.
O estudo realizado pelo Standish Group [Standish1995], chamado de relatrio

do Chaos, focou a indstria de software comercial. Esse estudo identificou que: as
empresas dos Estados Unidos gastaram $81 bilhes em projetos de software que
foram cancelados em 1995; 31% dos projetos estudados foram cancelados antes de
estarem concludos; 53% dos projetos de software que foram concludos excederam
mais do que 50% a sua estimativa de custo; somente 9% dos projetos, em grandes
organizaes, foram entregues no tempo e oramento previstos; para organizaes
de pequeno e mdio porte os nmeros melhoraram em 28% e 16%, respectivamente.
Este relatrio aponta o gerenciamento de software como sendo a razo para o
sucesso ou a falha de um projeto de software.
Atravs de uma anlise e acompanhamento de cem projetos de software,

Jones [Jones1996] relata: os seis primeiros dos dezesseis fatores associados aos
desastres do software so falhas especficas no domnio do gerenciamento de
projeto, e os trs dos outros dez fatores restantes esto indiretamente associados s
praticas de gerenciamento pobre.
Walker [Walker1997] conclui que: o desenvolvimento de software ainda

imprevisvel; somente 10% dos projetos de software so entregues com sucesso
dentro das estimativas de oramento e custo; a disciplina de gerncia mais um
discriminador de sucesso ou falha do que so os avanos tecnolgicos e a
quantidade de softwares jogados fora, e que tem necessidade de re-trabalho, so um
indicativo de processo imaturo.
Introduo 11
Muitas pesquisas enfatizam que o gerenciamento a principal causa do

sucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento de
projetos de software ainda pouco abordado e praticado nas empresas de software
[Machado2001]. Jones [Jones1999] destaca que a ausncia de um processo de
gerenciamento apropriado, aliado s estimativas deficientes de custo e de tempo,
umas das principais causas das falhas dos projetos de software.
Os principais padres e normas para SPA/SPI (Software Process Assessment/

Software Process Improvement)2 tm colocado o gerenciamento de projetos como um
dos requisitos bsicos para que uma empresa inicie a melhoria de seu processo.
Contudo, a introduo de padres e normas dentro das organizaes de software tem
se mostrado complexo demais, alm de causar uma sobrecarga de trabalho
significativa. Segundo Belloquin [Belloquin1999], estes padres e normas definem
prticas que devem ser realizadas, porm no determinam como execut-las.
Ns acreditamos que a existncia de procedimentos padronizados e de fcil

compreenso pode ser de grande valor, fornecendo uma orientao aos gerentes de
projeto e dificultando a ocorrncia de falhas graves de gerenciamento por falta de
experincia.
1.3 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE
J em 1989, Humphrey [Humphrey1989] constatou que: a ausncia de prticas

administrativas no desenvolvimento de software a principal causa de srios
problemas enfrentados pelas organizaes, tais como: atrasos em cronogramas,
custo maior do que o esperado e presena de defeitos, ocasionando uma srie de
inconvenincias para os usurios e enorme perda de tempo e de recursos.
Ainda hoje esta afirmao tem sido confirmada por diversos autores. Na atual
cultura das organizaes de software o planejamento, quando ocorre, feito de forma
superficial [Weber1999] [Sanches2001]. Muitos projetos de software so realizados
sem um planejamento de como a idia modelada pelo levantamento de requisitos e
necessidades dos clientes pode ser transformada em produto.
Os gerentes de projeto de software esto desacostumados a estimar

[Vigder1994]. Quando estimam, costumam basear-se em estimativas passadas,
mesmo sabendo que elas podem estar incorretas (no sabem tambm precisar o
quanto elas esto incorretas). H gerentes que se recusam a estimar somente por
julgarem perda de tempo, uma vez que correm o risco de obter resultados incorretos
e, portanto, estarem desperdiando tempo.
2
Exemplos de SPA/SPI so: CMM, CMMI, BootStrap, ISO9000, ISO/IEC15504, ISO12207, entre outros.
Boas estimativas de custo, esforo e prazo de software requerem um processo

ordenado que defina a utilizao de mtricas de software, mtodo e ferramenta de
estimativa. As empresas de software, de forma geral, no detm conhecimentos e
recursos para isso [Vigder1994].
Estimar, medir e controlar um projeto de software so tarefas difceis, pois o

desenvolvimento de software uma atividade criativa e intelectual, com muitas
variveis envolvidas (como metodologias, modelos de ciclo de vida, tcnicas,
ferramentas, tecnologias, recursos e atividades diversas). Os gerentes inexperientes
tentam cumprir prazos dando a mxima velocidade na fase inicial e esto
despreparados para os momentos de impasse, quando os ajustes so inevitveis.
A dinamicidade do processo de software dificulta tambm o gerenciamento

efetivo de projetos de software, devido s alteraes constantes nos planos de
projetos, redistribuio de atividades, incluso/excluso de atividades, adaptao de
cronogramas, realocao de recursos, novos acordos com os clientes, entregas
intermedirias no previstas etc. Um projeto de software tambm deve adaptar-se ao
ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do
pessoal ou equipe.
Outros fatores ainda agravam os problemas de gerenciamento de projetos de

software em empresas de pequeno e mdio porte, tais como: inexistncia de um
processo definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura
em processos, pouco treinamento em engenharia de software, imaturidade
metodolgica, crescimento ocorrido por demanda, falta de experincia administrativa
por parte dos gerentes e diretores e falta de definio das metas organizacionais.
1.4 ESTRUTURA DO MDULO
Alm deste captulo introdutrio, este mdulo est organizado em mais cinco
captulos e dois apndices. O captulo 2 aborda padres, normas e modelos que
definem boas prticas para a gerncia de projetos de software. Este captulo tambm
prope um modelo com elementos essenciais para a construo de um processo de
gerncia de projetos. A inteno deste captulo apresentar ao aluno conceitos que
julgamos importante para a criao de um bom processo de gerncia de projetos de
software. Os captulos 3, 4 e 5 apresentam um exemplo de processo de gerncia de
projetos de software para empresas de pequeno e mdio porte. Nestes captulos ser
apresentado o ProGer Processo de Gerncia de Projetos de Software, que um
processo que pode ser aplicado para empresas de pequeno e mdio porte. Estes trs
captulos objetivam mostrar ao aluno um exemplo de como um processo de gerncia
de projetos de software que pode ser utilizado para melhorar o desempenho de uma
empresa. Por fim, o captulo 6 realiza uma concluso geral sobre os temas abordados
neste mdulo.
Introduo 13
EXERCCIOS DE FIXAO:
1. Tente relembrar, sem consultar o texto deste captulo, quais so as principais dificuldades
encontradas pelas empresas de software para gerenciar seus projetos.
2. No frum virtual, coloque algumas consideraes sobre a dificuldade da gerncia de projetos.
Voc concorda com as dificuldades citadas neste captulo? Existem outras dificuldades que
voc j observou e queira compartilhar conosco?
3. No incio do captulo foi apresentada uma pesquisa realizada por Gibbs em 1994. Esta
pesquisa demonstrou que a Engenharia de Software, em diversos aspectos, ficou estagnada
desde 1960, quando foi publicado o texto The Software Crisis. Os mesmos problemas
apresentados em 1960 eram os de 1994. Voc acha que existe algum fator histrico que
merea destaque para esta estagnao da Engenharia de Software? Voc acredita que este
quadro ainda o mesmo atualmente (dez anos depois)? Vamos discutir isso no frum?
4. Por que os modelos e padres para SPA/SPI aconselham que se inicie o processo de
melhoria com a gerncia de projetos? Por que as metodologias de desenvolvimento esto
sendo colocadas como uma etapa seguinte?
5. Gerenciar projetos de software diferente de gerenciar projetos de manufatura? Por que
voc tem esta opinio? Compartilhe suas idias no frum virtual.
6. Neste captulo foi apresentada uma pesquisa do Standish Group, de 1995, sobre alguns
problemas da indstria de software dos Estados Unidos. Em 2001 foi realizada uma pesquisa
similar. Voc conhece esta pesquisa? Os indicadores continuam os mesmos? Como se
comportou a indstria de software dos Estados Unidos de 1995 para 2001? Compartilhe esta
pesquisa e sua opinio no frum virtual.
7. Voc concorda com a afirmao da seo 1.1 que diz que um projeto cria um produto,
servio ou resultado NICO? (Pense um pouco a respeito e depois leia a seo 1.2 do
PMBOK).
8. Voc concorda com a afirmao da seo 1.1 que diz que um projeto deve ter caracterstica
TEMPORAL? (Pense um pouco a respeito e depois leia a seo 1.2 do PMBOK).
9. Qual a diferena entre escopo do projeto e escopo do produto/servio? (pesquise no
PMBOK).
2
MODELOS, PADRES E NORMAS E
A GERNCIA DE PROJETOS
Os estudos realizados na dcada de 1990 sobre gerenciamento de projetos de

software deixaram evidente que as prticas de gerenciamento de projetos devem ser
melhoradas para que os projetos de software tenham sucesso. Dada esta
preocupao, muitos modelos e normas para SPA/SPI evoluram, principalmente com
a incluso de prticas gerenciais para os projetos de software; exemplos so: CMM
[Paulk1993] para CMMI [CMMI:2000]; o adendo norma ISO12207 [ISO12207:1995]
em 2001 [ISO12207:2000] e os novos processos de gerenciamento inseridos na
ISO/IEC15504 no decorrer de sua confeco.
Contudo, Machado [Machado2001] demonstrou recentemente que apesar das

pesquisas evidenciarem que o problema da indstria de software mais gerencial do
que tcnico, a gerncia de projetos no est sendo considerada como deveria.
Atravs da comparao das prticas de gerenciamento propostas nos padres e
normas para SPA/SPI com as contidas no PMBOK Project Management Body
Knowledge3 [PMBOK2000], concluiu-se que os requisitos de gerenciamento de
projeto no esto representados devidamente nos modelos [Machado2001]. O
gerenciamento de projeto de software tem sido priorizado h pouco tempo pelas
organizaes que definem padres e normas para software.
A ISO/IEC15504 quem aborda o gerenciamento de projetos de software de

forma mais completa [Wang1999]. Ela estabelece um conjunto de prticas bsicas
que devem ser seguidas para o sucesso do gerenciamento de projetos de software.
Desta forma, optamos por destacar neste captulo os processos de gerenciamento de
projetos proposto pela ISO/IEC15504. Este captulo tambm apresentar as reas de
conhecimento do PMBOK.
2.1 PROCESSOS DE GERENCIAMENTO DA ISO/IEC15504

O PMBOK e suas reas de conhecimento est em detalhes nas sees seguintes. O texto completo do
3
PMBOK se encontra no material complementar do ambiente virtual.

Modelos, Padres e Normas e a Gerncia de Projetos 15
Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization

for Standardization/International Electrotechnical Commission estabeleceu um projeto
denominado SPICE-Software Process Improvement and Capability Evaluation
[Dorling1993], que objetivava chegar a um consenso entre os diversos mtodos de
avaliao do processo de software. Este projeto, posteriormente, gerou o relatrio
tcnico ISO/IEC15504 [ISO/IEC15504:1-9:1998].
A ISO/IEC15504 atualmente uma norma que representa um padro

internacional emergente que estabelece um framework para construo de processos
de avaliao e melhoria do processo de software. Este framework pode ser utilizado
pelas empresas envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a
aquisio, fornecimento, desenvolvimento, operao, evoluo e suporte do software.
A ISO/IEC15504 no um mtodo isolado para avaliao e sua caracterstica
genrica permite que possa ser utilizada em conjunto com uma variedade de
mtodos, de tcnicas e de ferramentas.
Nove documentos compem a ISO/IEC15504. Alguns tm carter normativo

(como a ISO/IEC15504-2, ISO/IEC15504-3 e ISO/IEC15504-9) e outros possuem
carter informativo (como a ISO/IEC15504-1, ISO/IEC15504-4, ISO/IEC15504-5, ISO/
IEC15504-6, ISO/IEC15504-7 e ISO/IEC15504-8). A ISO/IEC15504-2 define um
modelo de referncia de processo e um modelo de capacitao do processo (Figura
2.1) que pode compor a base para a definio e avaliao de um processo de
software. Este modelo de referncia possui uma abordagem bidimensional.
Nvel Nome dos Atributos

Processos do Ciclo de Vida 5 Processo Otimizado
Atributos de mudana do processo
Categoria Atributos de melhoria continua
4 Processo Previsvel
X
Atributos de medida do processo
Atributos de controle do processo
3 Processo Estabelecido
Atributos de definio do processo
CUS ENG SUP MAN ORG Atributos de recursos do processo
2 Processo Gerenciado
Atributos de gerencimento do desempenho
Atributos do gerenciamento de artefatos
............. 1 Processo Executado
Atributos de desempenho do processo
Processo Atributos de melhoria continua
0 Processo Incompleto
Dimenso de Processo Dimenso de Capacidade

FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504
A primeira dimenso auxilia os engenheiros de processo na definio dos

processos necessrios em uma empresa, assim como sua adequao
ISO/IEC15504. A segunda dimenso, similar ao CMM, tem por objetivo determinar a

capacidade do processo da empresa, avaliando-o atravs de um conjunto de
atributos preestabelecidos. Os atributos de processo esto agrupados nos nveis de
capacidade e podem ser aplicados em todos os processos descritos na organizao
para determinar a maturidade do processo.
Cinco grupos de processos so definidos pela ISO/IEC15504-2:

1. Fornecedor-Cliente (CUS-Custormer-Supplier): so os processos que de
alguma forma impactam diretamente o cliente, dentre eles o suporte para
desenvolvimento e transaes de software para o cliente, fornecimento de
operaes corretas e uso do produto de software ou servio;
2. Engenharia (ENG-Engineering): esta categoria agrupa os processos que
especificam, implementam e mantm o produto de software, sua relao com
o sistema e a documentao do cliente;
3. Suporte (SUP-Support): so processos que podem ser empregados em
algum dos outros processos e em vrios pontos no ciclo de vida do software,
objetivando dar suporte a eles;
4. Gerenciamento (MAN-Management): so processos que contm prticas
gerenciais que podem ser utilizadas por algum que gerencia algum tipo de
projeto ou processo dentro do ciclo de vida do software;
5. Organizao (ORG-Organization): so processos que estabelecem as
finalidades dos processos de desenvolvimento e da organizao, do produto e
dos recursos que, quando utilizados por projetos na organizao, realizaro as
metas do negcio.
A categoria de processo MAN (Management process category) quem

estabelece os processos de gerenciamento para a empresa, que esto subdivididos
em quatro grupos:
MAN.1 Processo de gerenciamento organiza, monitora e controla o incio e o

desempenho de qualquer processo ou funo dentro da empresa, alcanando as
metas do negcio de maneira efetiva;
MAN.2 Gerenciamento de projetos identifica, estabelece, coordena e monitora

atividades e recursos necessrios para que um projeto realize um produto ou servio
de acordo com seus requisitos;
MAN.3 Gerenciamento da qualidade monitora a qualidade dos produtos e

servios realizados pelos projetos e garante que eles satisfaam ao cliente;
MAN.4 Gerenciamento de riscos identifica e mitiga os riscos dos projetos,

continuamente, atravs do ciclo de vida de um projeto.
Apesar dos quatros agrupamentos estarem envolvidos no gerenciamento de

projetos, vamos descrever apenas o grupo MAN.2, que est subdividido em 12
prticas bsicas:
MAN.2.BP1 Define o escopo do trabalho, ou seja, o trabalho que deve ser

feito por um projeto, estabelecendo que metas devem e podem ser atingidas
considerando os recursos disponveis e as restries;
MAN.2.BP2 Determina a estratgia de desenvolvimento, avaliando as opes

disponveis para alcanar as metas do projeto, estabelecendo os riscos e as
oportunidades que a estratgia deve considerar;
MAN.2.BP3 Seleciona um modelo de ciclo de vida para o projeto que

apropriado ao escopo, magnitude e complexidade do projeto;
MAN.2.BP4 Estabelece as tarefas estimando seu tamanho e os recursos

necessrios para completar o trabalho, avaliando as opes disponveis para alcance
das metas do projeto e levando em considerao os riscos e as oportunidades;
MAN.2.BP5 Estabelece a estrutura de diviso do trabalho, as entregas e a

seqncia das tarefas, levando em conta os recursos requeridos e a estratgia
adotada;
MAN.2.BP6 Identifica os requisitos da infra-estrutura, ou seja, os elementos

do ambiente e os recursos humanos necessrios para suportar a estratgia e a
execuo do projeto;
MAN.2.BP7 Estabelece o cronograma do projeto, baseado na estrutura de

diviso do trabalho, estimativas realizadas e elementos da infra-estrutura
considerados;
MAN.2.BP8 Aloca responsabilidades, identificando os indivduos especficos e

os grupos necessrios para garantir a realizao do que foi acordado no projeto;
MAN.2.BP9 Identifica as interfaces entre os elementos no projeto e com

outros projetos e unidades organizacionais;
MAN.2.BP10 Estabelece e implementa os planos de projeto, fornecendo um

mecanismo para garantir que os projetos sero formalmente desenvolvidos,
implementados, mantidos e estando disponveis para todos os envolvidos no projeto;
MAN.2.BP11 Compara o planejado no plano de projeto com o que est sendo

executado;
MAN.2.BP12 Corrige os desvios quando os objetivos do projeto no esto

sendo alcanados.
Os processos de gerenciamento comeam a ser necessrios na ISO/IEC15504

somente a partir do nvel 2 de capacidade e esto distribudos conforme mostra a
Tabela 2.1.
TABELA 2.1 Distribuio dos processos de gerenciamento nos nveis de

capacidade da ISO/IEC15504
Nveis de Capacidade Categorias de Processo de Gerenciamento

1. Processo Executado
2. Processo Gerenciado MAN.1, MAN.2, MAN.3, MAN.4
3. Processo Estabelecido MAN.1, MAN.2
4. Processo Previsvel MAN.2, MAN.3, MAN.4
5. Processo Otimizado MAN.3
2.2 PMBOK
O PMI Project Management Institute uma associao de profissionais de

gerenciamento de projetos que existe desde 1969. Esta associao criou em 1986 a
primeira verso do PMBOK Project Management Body of Knowledge4. O PMBOK
um guia que descreve a somatria de conhecimento e as melhores prticas dentro da
profisso de gerenciamento de projetos. um material genrico que serve para todas
as reas de conhecimento, ou seja, tanto para construo de um edifcio como para a
produo de software.
A meta do gerenciamento de projetos, segundo o PMBOK, conseguir exceder

as necessidades e expectativas dos stakeholders. Todavia, como j visto no captulo
1, satisfazer ou exceder estas necessidades envolve um balanceamento entre as
vrias demandas concorrentes em relao:
escopo, tempo, custo e qualidade (objetivos do projeto);
stakeholders com necessidades e expectativas diferenciadas; e
requisitos identificados (necessidades) e requisitos no identificados
(expectativas).
O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos

em cinco grupos (figura 2.2): processos de inicializao, processos de planejamento,
processos de execuo, processos de controle e processos de finalizao.
O PMBOK o material mais importante que foi gerado pelo PMI, contudo, esta instituio possui
42
diversos outros documentos e relatos que so bastante relevantes para a gerncia de projetos. Para se
aprofundar no assunto, voc pode consultar o material complementar do ambiente virtual ou visitar o site
http://www.pmi.org/ .
FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK
Os processos de inicializao autorizam o incio do projeto ou de uma fase do

projeto. Os processos de planejamento definem e refinam os objetivos do projeto,
Processos de Processos de
Inicializao Planejamento
Processos de Processos de
controle execuo
Processos de
finalizao
selecionando as melhores alternativas para realiz-lo. Os processos de execuo

coordenam pessoas e outros recursos para a realizao do projeto, baseando-se no
planejamento. Os processos de controle monitoram e medem o progresso do que
est sendo executado, com o intuito de tomar aes corretivas quando necessrias.
Os processos de finalizao formalizam o aceite e a finalizao do projeto ou de uma
fase do projeto.
Os processos do PMBOK esto organizados por reas de conhecimento, que se

referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro
destas reas de conhecimento os cinco grupos de processos acima descritos podem
ocorrer. A figura 2.3 mostras as 9 reas de conhecimento do PMBOK.
A seguir descreveremos os processos de cada rea de conhecimento do

PMBOK. Todos os processos descritos, das reas abaixo, interagem uns com os
outros e tambm com os processos das demais reas de conhecimento. Cada
processo pode envolver esforo de um ou mais indivduos ou grupos de indivduos,
dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo
menos uma vez em cada fase do projeto.
2.2.1 Gerncia de integrao de projetos

A gerncia de integrao engloba os processos necessrios para garantir que

os vrios elementos de um projeto sejam propriamente coordenados. Objetiva
realizar as negociaes dos conflitos entre objetivos e alternativas do projeto com a
finalidade de atingir ou exceder as necessidades e expectativas de todas as partes
interessadas. Envolve o desenvolvimento e a execuo do plano de projeto e o
controle geral das mudanas.
Essa rea de processo incluiu os seguintes processos principais:

desenvolvimento do plano do projeto - agregar os resultados dos outros
processos de planejamento, construindo um documento coerente e
consistente;
execuo do plano do projeto - levar a cabo o projeto atravs da
realizao das atividades nele includas;
controle geral de mudanas - coordenar as mudanas atravs do projeto
inteiro.
FIGURA 2.3 reas do gerenciamento de projetos do PMBOK

Gerncia de
Projeto
Gerncia de Gerncia de Gerncia de

Integrao Escopo Tempo

Custo Qualidade Recursos
Humanos

Comunicao Risco Aquisio
2.2.2 Gerncia de escopo de projetos
A gerncia do escopo do projeto inclui os processos requeridos para assegurar

que o projeto inclua todo o trabalho necessrio, e to somente o trabalho necessrio,
para complementar de forma bem sucedida o projeto. A preocupao fundamental
compreende definir e controlar o que est ou no includo no projeto.

iniciao - comprometer a organizao a iniciar a prxima fase do projeto;

planejamento do escopo - desenvolver uma declarao escrita do escopo
como base para decises futuras do projeto;
detalhamento do escopo - subdividir os principais subprodutos do projeto
em componentes menores e mais manejveis;
verificao do escopo - formalizar a aprovao do escopo do projeto;
controle de mudanas de escopo - controlar as mudanas do escopo do
projeto.
2.2.3 Gerncia de tempo de projetos
A gerncia de tempo do projeto objetiva garantir o trmino do projeto no tempo

certo. Consiste da definio, ordenao e estimativa de durao das atividades e de
elaborao e controle de cronogramas.
Essa rea incluiu os seguintes processos principais:

definio das atividades - identificar as atividades especficas que devem
ser realizadas para produzir os diversos subprodutos do projeto;
seqenciamento das atividades - identificar e documentar as relaes de
dependncia entre as atividades;
estimativa da durao das atividades - estimar a quantidade de perodos
de trabalho que sero necessrios para a implementao de cada atividade;
desenvolvimento do cronograma - analisar a seqncia e as duraes das
atividades e os requisitos de recursos para criar o cronograma do projeto;
controle do cronograma - controlar as mudanas no cronograma do
projeto.
2.2.4 Gerncia de custo de projetos
A gerncia de custo tem por objetivo garantir que o projeto seja executado
dentro do oramento aprovado. Consiste no planejamento dos recursos, estimativa,
oramento e controle de custos.

planejamento dos recursos - determinar quais recursos (pessoas,
equipamentos, materiais) e que quantidade de cada deve ser usada para
executar as atividades do projeto;
estimativa dos custos - desenvolver uma estimativa dos custos dos
recursos necessrios implementao das atividades do projeto;
oramento dos custos - alocar as estimativas de custos globais aos itens

individuais de trabalho;
controle dos custos - controlar as mudanas no oramento do projeto.
2.2.5 Gerncia da qualidade de projetos
A gerncia da qualidade objetiva garantir que o projeto satisfar as exigncias

para as quais foi contratado. Consiste no planejamento, garantia e controle de
qualidade.

planejamento da qualidade - identificar quais padres de qualidade so
relevantes para o projeto e determinar a forma de satisfaz-los;
garantia da qualidade - avaliar periodicamente o desempenho geral do
projeto, buscando assegurar a satisfao dos padres relevantes de
qualidade;
controle da qualidade - monitorar os resultados especficos do projeto para
determinar se eles esto de acordo com os padres de qualidade relevantes
e identificar as formas para eliminar as causas de desempenhos
insatisfatrios.
2.2.6 Gerncia de recursos humanos de projetos
A gerncia de recursos humanos objetiva garantir o melhor aproveitamento das

pessoas envolvidas no projeto. Consiste no planejamento organizacional, alocao
de pessoal e definio de equipe.

planejamento organizacional - identificar, documentar e designar as
funes, responsabilidades e relacionamentos de reporte dentro do projeto;
montagem da equipe - conseguir que os recursos humanos necessrios
sejam designados e alocados ao projeto;
desenvolvimento da equipe - desenvolver habilidades individuais e do
grupo para aumentar o desempenho do projeto.
2.2.7 Gerncia de comunicao de projetos
A gerncia de comunicao tem por objetivo principal garantir a gerao

adequada e apropriada, coleta, disseminao, armazenamento e disponibilizao da
informao.

planejamento das comunicaes - determinar as informaes e

comunicaes necessrias para os interessados: quem necessita de qual
informao, quando necessitaro dela e como isso ser fornecido;
distribuio das informaes - disponibilizar as informaes necessrias
para os interessados do projeto da maneira conveniente;
relato de desempenho - coletar e disseminar as informaes de
desempenho. Inclui relatrios de situao, medio de progresso e
previses;
encerramento administrativo - gerar, reunir e disseminar informaes para
formalizar a concluso de uma fase ou de todo o projeto.
2.2.8 Gerncia de risco de projetos
A gerncia de risco objetiva maximizar os resultados de ocorrncias positivas e

minimizar as conseqncias de ocorrncias negativas. Consiste na identificao,
quantificao, tratamento e controle dos riscos do projeto.

identificao dos riscos - determinar quais os riscos so mais provveis de
afetar o projeto e documentar as caractersticas de cada um;
quantificao dos riscos - avaliar os riscos, suas interaes e possveis
conseqncias;
desenvolvimento das respostas aos riscos - definir as melhorias
necessrias para o aproveitamento de oportunidades e respostas s
ameaas;
controle das respostas aos riscos - responder s mudanas nos riscos no
decorrer do projeto.
2.2.9 Gerncia de aquisio de projetos
A gerncia de aquisio tem por objetivo principal obter bens e servios

externos organizao executora. Consistem na seleo de fornecedores,
planejamento de aquisio, planejamento de solicitao, solicitao de propostas e
administrao e encerramento de contratos.

planejamento das aquisies - determinar o que contratar e quando;
preparao das aquisies - documentar os requisitos do produto e
identificar os fornecedores potenciais;
obteno de propostas - obter propostas de fornecimento conforme
apropriado a cada caso (cotaes de preo, cartas-convite, licitao);
seleo de fornecedores - escolher entre os possveis fornecedores;

administrao dos contratos - gerenciar o relacionamento com os
fornecedores;
encerramento do contrato - completar e liquidar o contrato incluindo a
resoluo de qualquer item pendente.
2.3 MODELAGEM DO SISTEMA DE PROCESSOS DE EMPRESA DE

SOFTWARE
Como j estudado anteriormente em outros mdulos do curso, um processo

pode ser definido como um conjunto de atividades inter-relacionadas que
transformam um conjunto de entradas em resultados [ISO12207:1995]. Segundo a
ISO15504 [ISO15504:1-9:1998], processo de software um conjunto de processos
utilizados por uma organizao de software ou um projeto de software para planejar,
gerenciar, executar, monitorar, controlar e melhorar as atividades que esto
relacionadas com software.
O trabalho de Wang [Wang1999] apresenta um framework unificado de um

sistema de processo para uma organizao de software. A figura 2.4 mostra este
modelo, que est dividido em trs agrupamentos principais: o modelo do processo, o
modelo de avaliao do processo e o modelo de melhoria do processo.
Modelagem do sistema de
processo
Modelo de avaliao do Modelo de melhoria do

Modelo do processo
processo processo
Mtodo de Modelo de Modelo de

Subsistema do Subsistema do Subsistema do Modelo de
determinao melhoria melhoria
processo processo de processo de capacidade do
da capacidade baseado em baseado em
organizacional desenvolvimento gerenciamento processo
do processo avaliao Benchmark
Escala do Escala da Escopo da Determinao Agregao de Agregao da

desempenho capacidade do capacidade do da capacidade capacidade do capacidade da
da pratica processo processo do processo projeto organizao

software
O modelo do processo utilizado para descrever a organizao, sua

categoria, sua hierarquia, o inter-relacionamento e as instncias dos seus processos.
O modelo de processo descrito por [Wang1999] identifica trs conjuntos de

subsistemas: processo organizacional, processo de desenvolvimento de software e
processo de gerenciamento. Os processos organizacionais regulam as atividades que
so geralmente praticadas em uma empresa acima do nvel de projeto. Os processos
de desenvolvimento e de gerenciamento so interativos e, em paralelo, atuam sobre
o projeto.
O modelo de avaliao do processo serve para definir procedimentos para

avaliar os pontos fortes e fracos dos processos da organizao, alm de identificar os
pontos para melhoria. Atravs do modelo de melhoria do processo podem-se
definir procedimentos sistemticos para uma efetiva melhoria do desempenho dos
processos da empresa mudando os processos correntes ou adicionando a eles novos
processos para correo ou melhoria de problemas identificados. O processo de
melhoria vem a seguir do processo de avaliao e o relacionamento entre eles forma
um ciclo repetitivo at o processo da organizao estar otimizado. Exemplo o plan-
do-check-act descrito por Campos [Campos1992].
Diversos modelos, normas e padres definem certificao, avaliao e melhoria

para o processo de software, entre eles podemos citar: a ISO9000 [ISO9000-3:1997],
CMM/CMMI [Paulk1993] [Paulk1997] [CMMI:2000], ISO15504 [ISO15504:1-9:1998] e
BootStrap [Kuvaja1993] [Kuvaja1994].
Apesar das empresas de software durante muito tempo negligenciarem a

especificao e o gerenciamento de seus processos, estes sempre existiram. Porm,
no h um consenso de que tipo de processo de software deva ser utilizado em uma
organizao, pois alguns processos se adequam melhor a certos tipos de aplicaes
do que outros. Alm disso, uma empresa pode, inclusive, possuir diversos padres de
processos de software sendo utilizados em projetos distintos.
O reconhecimento das necessidades dos modelos de processo de software tem

deixado um amplo campo de trabalho em muitas direes. As organizaes que
desenvolvem software tm verificado que definindo seus processos podem melhorar
sua eficcia e a qualidade dos produtos e servios que realizam.
A seo seguinte apresenta um modelo que utilizaremos nos prximos captulos

para definir um processo para gerncia de projetos para uma empresa de software, o
ProGer - Processo de Gerncia de Software.
2.4 ELEMENTOS ESSENCIAIS PARA CRIAR UM PROCESSO DE GERNCIA DE

PROJETOS
Algumas propostas de processo para gerncia de projetos de software podem

ser encontradas na literatura. O fluxo de gerncia de projetos do RUP [Rational
Unified Process] um exemplo. Contudo, estes processos no devem ser adotados
em uma empresa sem que se leve em considerao alguns outros elementos que
julgamos essenciais.
Desta forma, propomos que ao criar um processo de gerncia de projetos para

uma empresa de software deve-se considerar seis elementos essenciais, como
mostra a Figura 2.5: a poltica organizacional, os padres, o processo de
gerenciamento, os procedimentos, os treinamentos, e as ferramentas5.
Poltica
Padres
Organizacional
restringe o processo
Processo de gerenciamento de
projetos de software
implementado atravs de
Procedimentos
so apoiados por
Ferramentas de gerenciamento
Treinamento
de projetos de software

software
A poltica organizacional estabelece as leis e as regras que governam ou

restringem as operaes da empresa. Ela identifica os requisitos aceitveis do
processo e/ou formas de se realizar o projeto. A poltica organizacional estabelece
tambm as metas e os objetivos que a organizao deseja alcanar.
Os padres definem as operaes e os critrios de aceitao para a execuo

de servios e produtos da empresas. Os padres e normas para SPA/SPI e as
metodologias podem, por exemplo, ser utilizados para a definio dos padres da
organizao.
5
Esta recomendao se aplica tambm a outras reas de processo e no somente a gerncia de
projetos.
Um processo de gerenciamento de projetos de software descreve como a

organizao gerencia a execuo de seus servios e produtos, de acordo com a
poltica organizacional e os padres adotados.
Nos captulos seguintes definiremos o ProGer, que um modelo para gerncia

de projetos de software. O ProGer pode auxiliar as empresas de software na
organizao inicial de seu negcio atravs do uso de artefatos de alto nvel e de
baixa complexidade, em conjunto com um modelo de ciclo de vida para os projetos e
o estabelecimento de fluxos de trabalho.
Os processos so implementados atravs de procedimentos. Os fluxos de

trabalho, por exemplo, podem especificar esses procedimentos, ou seja, as
instrues passo-a-passo de como o processo deve ser executado. A poltica
organizacional que restringe e expande o processo de gerncia de projetos,
adaptando-o realidade da empresa e estabelecendo procedimentos especficos,
dependendo do projeto.
As ferramentas determinam algum apoio automatizado para os procedimentos

do processo, seja auxiliando na execuo das atividades como para obteno de
mtricas para posterior avaliao do processo.
Os treinamentos possibilitam dar aos recursos humanos da empresa o

conhecimento e habilidades necessrias para executarem os procedimentos do
processo.
2.5 CONSIDERAES
Como j dito anteriormente neste captulo, os padres e normas para SPA/SPI

podem ser utilizados com o intuito de definir, avaliar e melhorar os processos de uma
empresa. Todavia, apesar da sua importncia, eles ainda esto sendo pouco
considerados pelas empresas [Lindvall2000]. Diversos motivos dificultam o uso
destes padres, dentre eles o fato de que a definio e uso de um processo de
software envolvem uma complexa inter-relao de fatores organizacionais, culturais,
tecnolgicos e econmicos.
A complexidade destes modelos tambm dificulta sua implantao em empresas

de pequeno porte, j que foram construdos para o mbito de empresas estruturadas
e estabilizadas. Porm, acreditamos que a grande ameaa implantao destes
padres e normas, nas empresas, o dia-a-dia da empresa que absorve
praticamente todos os recursos existentes. Sendo esse um projeto interno, de longo
prazo e com resultados tambm de longo prazo, h uma tendncia acomodao,
fazendo com que as atividades sejam proteladas por diversas vezes at a
desistncia.
No que se refere ao gerenciamento de projetos de software especificamente,

estamos de acordo com as concluses realizadas nos trabalhos [Fernandes1989] e
[Maidantchik1999]: apesar do esforo da comunidade de engenharia de software em
definir modelos e padres para a construo de um efetivo processo de
gerenciamento de projetos, a maioria das empresas ainda sente dificuldade em
definir os seus processos e no gerenciam os seus projetos de forma satisfatria.
O gerenciamento de projetos de software , de fato, pouco abordado e praticado

e, porque no dizer, negligenciado. Os ambientes tradicionais das empresas tm
dado suporte, em geral, somente engenharia, assumindo um processo implcito e
tendo como foco principal o produto. Acreditamos que esta viso limita as empresas
no que diz respeito tomada de decises, ao estabelecimento e obteno de metas
organizacionais, determinao de pontos para melhoria, estipulao de prazos
para entrega de produtos e at mesmo obteno de uma certificao.
O PMBOK e os modelos de SPA/SPI podem ser utilizados para criar um

processo padro para gerenciamento de projetos de software. Estes modelos renem
boas prticas para as empresas. Contudo, a implantao destes padres exige um
investimento importante dos envolvidos, para conceber um processo que venha
alavancar o negcio, facilitar a vida dos envolvidos e no criar burocracia somente
para atender aos requisitos descritos no modelo. Alm disso, estes modelos
descrevem o que deve ser feito e no como faz-lo.
Algumas iniciativas j foram realizadas com o intuito de descrever o como

utilizar normas e padres de SPA/SPI em uma empresa. Contudo, estes frameworks
acabam sendo to complexos quanto os modelos que os originou e esto descritos
tambm para o mbito de empresas estruturadas.
Os prximos captulos deste mdulo apresentam um exemplo de processo para

gerncia de projetos de software que foi construdo considerando os seis elementos
essenciais apresentados neste captulo. O captulo 3 define a poltica organizacional
e os padres adotados. O captulo 4 traz o processo propriamente dito, com seu
modelo de ciclo de vida para os projetos, fluxos de trabalho, artefatos, stakeholders,
mtricas, etc. O captulo 5 relaciona algumas ferramentas que podem ser utilizadas
em conjunto com o processo.
EXERCCIOS DE FIXAO:
1. Considerando o ambiente em que trabalha, que prticas bsicas da ISO/IEC15504 de
gerncia de projetos voc acredita estar satisfazendo?
2. Considerando que uma das maiores dificuldades da gerncia de projetos de software a
constante mudana do escopo, leia a rea de conhecimento Gesto de Escopo do
PMBOK e coloque a sua opinio sobre o que acredita ser aplicvel para empresas de
software no frum virtual.
3. Considerando as 9 reas de conhecimento do PMBOK, escolha a que julga mais relevante
para o seu ambiente profissional. Leia atentamente esta rea no PMBOK e troque idia no
frum virtual de como voc poderia institucionaliz-la em sua empresa (ou departamento).
4. Voc concorda com os elementos essenciais para a criao de um processo para gerncia
de projetos? Que elementos voc julga estar faltando? Que elementos voc
desconsideraria? (Coloque a sua opinio no frum virtual).
3
POLTICA ORGANIZACIONAL E
PADRES ADOTADOS PARA A
DEFINIO DO PROGER
Este captulo apresenta a poltica organizacional e as metas adotadas para a

criao do processo de gerncia de projetos de software, denominado ProGer. Este
captulo estabelece dois dos seis elementos essenciais definidos na seo 2.4 deste
mdulo.
3.1 POLTICA ORGANIZACIONAL CONSIDERADA PARA O PROGER
Como visto no captulo anterior, a poltica organizacional estabelece as leis e

regras que governam ou restringem as operaes da empresa de software. Ela
identifica os requisitos aceitveis do processo e/ou formas de se realizar o projeto. A
poltica organizacional estabelece tambm as metas e os objetivos que a empresa
deseja alcanar. De forma simplista, vamos definir a poltica organizacional baseado
em dois aspectos: (1) caracterizao da empresa e (2) metas que a empresa
pretende atingir com a gerncia de projetos.
3.1.1 Caracterizao da empresa
O modelo de processo para gerenciamento de projetos de software apresentado

neste mdulo dever ser aplicvel para empresas de pequeno e mdio porte. A
classificao do porte de uma empresa de software pode ser realizada considerando
diversos fatores, entre eles podemos citar: faturamento, fora de trabalho e
comercializao anual bruta. Ns adotamos a classificao do porte da empresa
baseada na fora de trabalho, dada pelo MCT-Ministrio da Cincia e Tecnologia
[MCT]:
micros de 1 a 10 pessoas;
pequenas de 11 a 50 pessoas;
mdias de 50 a 100 pessoas;
grandes mais de 100 pessoas.
Poltica Organizacional e Padres Adotados para a definio do ProGer 31
Ns optamos por considerar estas classes de empresas de software devido ao

fato de serem a grande maioria. A Figura 3.1 apresenta um grfico, tambm retirado
do [MCT], que mostra a predominncia deste tipo de organizao com percentuais
superiores a 80%, desde 1995.
43 1993
41 42
1995
38
35 36 1997
30 1999
Percentual
20 19 20
15
13
8
6 7 7
Micro Pequena Mdia Grande
FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva
O MCT ainda preconiza que se forem considerados os servios terceirizados,

que so muito comuns nas reas de produo de servios e produtos de software, o
percentual de empresas de grande porte diminui significativamente, aumentando o rol
de empresas de pequeno e mdio porte. Estudos realizados tambm em outros
pases, como o de [Standish1995], tambm estabeleceram a predominncia de
empresas de pequeno e mdio porte no setor computacional.
Outras motivaes nos fizeram optar por abordar, para o nosso exemplo, as
empresas de pequeno e mdio porte. Segundo Laitinen [Laitinen2000], as empresas
desta classe so as que mais urgentemente necessitam de formalizao de
procedimentos para gerenciamento e controle de seus projetos. Tambm afirma que,
a utilizao de padres e normas para SPA/SPI est sendo pouco considerada por
esta classe de empresas [Lindvall2000]. Devido ao fato destes modelos terem sido
originalmente desenvolvidos para o mbito de empresas bem estruturadas e
departamentalizadas, ou seja, tipicamente para o mbito de grandes empresas, isso
dificulta ainda mais a orientao para empresas de pequeno e mdio porte
[Belloquim1999].
Outros fatores ainda agravam os problemas de gerenciamento de projetos de

software em empresas de pequeno porte, tais como: inexistncia de um processo
definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em

processos, pouco treinamento em engenharia de software, imaturidade metodolgica,
crescimento ocorrido por demanda, falta de experincia administrativa por parte dos
gerentes e diretores e falta de definio das metas organizacionais.
Consideramos tambm que a empresa para a qual estamos criando o processo

de gerncia de projetos atua no mercado da seguinte forma:
desenvolve produtos baseados nas necessidades especficas dos clientes,
tipo atelier;
possui produtos prprios que so customizados para as necessidades
especficas dos clientes;
presta servios de instalao de sistemas de outras empresas.
Outras caractersticas que consideramos para esta empresa:

possui projetos de curta, mdia e longa durao;
no utiliza metodologia para desenvolvimento de software;
possui uma diretoria comprometida em melhorar o processo de software e
introduzir padres.
3.1.2 Metas pretendidas com a gerncia de projetos
As principais metas que pretendemos alcanar com a implantao do processo

de gerncia de projetos seriam tornar possvel (atravs de um modelo simplificado de
processo de gerenciamento de projetos de software) obter em uma empresa de
pequeno e mdio porte:
melhoria da satisfao do cliente;
melhoria da qualidade dos produtos gerados;
melhoria da qualidade do processo;
melhoria do gerenciamento dos recursos humanos;
melhoria da comunicao interna e externa da empresa;
melhoria do desempenho das estimativas de esforo, custo e prazo;
melhoria do estabelecimento das metas organizacionais;
melhoria na identificao dos riscos.
3.2 MODELOS, NORMAS E PADRES UTILIZADOS PARA A DEFINIAO DO

PROGER
O ProGer, modelo que ser apresentado no prximo captulo, foi concebido

considerando os padres da engenharia de processo e do gerenciamento de
projetos. Foi especificado tendo como base os modelos e padres de SPA/SPI,
principalmente, a ISO15504 [ISO15504:1-9:1998] e o CMMCapability Maturity Model

[Paulk1993], as metodologias para desenvolvimento de software (como o RUP-
Rational Unified Process [Philippe1998] e o OPEN Process [Graham1999]), os
procedimentos e normas para gerenciamento de projetos (como o PMBOK-Project
Management Body of Knowledge [PMBOK2000], TQC-Total Quality Control
[Campos1992] e [Royce1998]) e nos estudos empricos realizados em empresas de
software de pequeno e mdio porte.
Inicialmente para a especificao do ProGer, realizamos um estudo vertical nas

normas e padres para SPA/SPI, considerando somente o gerenciamento de projetos
para a construo de nosso modelo padro. Contudo, ns observamos atravs de
estudos empricos que os padres e normas para SPA/SPI eram insuficientes como
insumo bsico para a definio de um modelo padro para o gerenciamento de
projetos em uma empresa. Um trabalho que enfatiza esta observao apresentado
por Machado [Machado2001] que apresenta a relao das reas de conhecimento do
PMBOK em comparao com dois importantes modelos, o CMM e a ISO/IEC15504
(ver tabela 3.1).
Machado [Machado2001] afirma, e ns concordamos com ele, que ainda temos

muito que evoluir em relao s prticas de gerncia para alcanarmos o
conhecimento contido no PMBOK. Desta forma, passamos a considerar os processos
descritos no PMBOK para o ProGer. Porm, apesar do PMBOK ser um guia mais
completo na rea de gerenciamento de projetos ele no considera as peculiaridades
da execuo de servios e produtos de software. Ns, ento, unificamos estes dois
universos em um meta-processo que levou em considerao a simplicidade e
facilidade para ser utilizado em empresas de pequeno e mdio porte.
A seguir mostraremos uma tabela comparativa entre as reas de

conhecimento do PMBOK, o CMM e a ISO/IEC15504.
TABELA 3.1 Comparao entre as reas de conhecimento do PMBOK, o CMM

e a ISO/IEC15504
PMBOK CMM ISO/IEC15504

Integrao Gerncia de projeto integrada Gerncia organizacional
Escopo Planejamento de acompanhamento Gerncia de projeto
Gerncia de requisitos Gerncia de Requisitos
Tempo Acompanhamento e controle. Gerncia de projeto.
Mas, no enderea especificamente essa Mas, no enderea
questo especificamente essa questo.
Custo Acompanhamento e controle. Gerncia de projeto.
Mas, no enderea especificamente essa Mas, no enderea
questo especificamente essa questo.
Aquisio Gerncia de Contratos com fornecedores No tem processos que trate
especificamente essa questo.
Ela coberta na norma pela
Aquisio e Fornecimento e
gerenciada da mesma forma que
um projeto interno organizao
Recursos A prpria concepo do modelo diz que devem Recursos Humanos
Humanos se ter habilidades para executar, mas no Gerncia do Conhecimento
menciona explicitamente a necessidade de
gerenciamento de recursos humanos atravs dos
projetos da organizao
Comunicao Gerncia de Configurao cobre parcialmente Gerncia de Configurao cobre
esse processo. A prpria concepo do modelo parcialmente esse processo.
diz que os processos devem ser comunicados, Mas, no menciona explicitamente
mas no menciona explicitamente a necessidade esse processo
de comunicao dos produtos dos projetos para
todos os envolvidos
Risco Gerncia de Risco Gerncia de Risco
Garantia de Garantia de qualidade de produto e processo Gerncia da Qualidade
Qualidade
EXERCCIOS DE FIXAO:
1. Que outros elementos voc consideraria para definir a poltica organizacional para a
construo de um processo de gerncia de projetos de software? Voc acha que a
caracterizao da empresa e as metas (como apresentado neste captulo) so suficientes?
Discuta no frum virtual suas sugestes e opinies.
4
PROGER: PROCESSO DE GERNCIA
DE PROJETOS DE SOFTWARE
Este captulo apresenta o ProGer - Processo de Gerncia de Projetos de

Software, que um exemplo de modelo de processo para gerncia de projetos de
software para pequenas e mdias empresas de software. Este modelo pode auxiliar
as empresas de software na organizao inicial de seu negcio. O ProGer est
apresentado neste captulo atravs de: um modelo de ciclo de vida para os projetos
(seo 4.1); da definio dos stakeholders (seo 4.2); da definio dos fluxos de
trabalho (seo 4.4); dos artefatos gerados no processo (seo 4.3) e de sugestes
de estimativas e mtricas para avaliao do desempenho da execuo dos projetos
(seo 4.4).
Ns objetivamos com este captulo fornecer um exemplo prtico de como se

pode definir um processo para a gerncia de projeto de software de forma organizada
em uma empresa de software.
4.1 MODELO DE CICLO DE VIDA PARA PROJETOS DE SOFTWARE
Segundo o PMBOK [PMBOK2000], um modelo de ciclo de vida para projetos

tem por objetivo definir o incio e o fim de um projeto. Este modelo pode ser dividido
em fases e geralmente aborda dois aspectos principais: (1) que trabalho deve ser
feito em cada fase, e (2) quem deve estar envolvido em cada fase.
No que se refere aos projetos de software, diversos modelos de ciclo de vida j

foram descritos, alguns exemplos so: o modelo espiral [Boehm1988] e o modelo
baseado em contrato [Graham1999]. O PMBOK [PMBOK2000] reconhece estes
modelos como sendo representativos para o desenvolvimento de projetos de
software. Como tal, eles esto muito focados na construo de um produto ou servio
de software, isto , esto fortemente associados aos aspectos da engenharia e
desconsideram etapas do projeto que antecedem e sucedem a confeco do produto
propriamente dito. Estas etapas so importantes para que uma empresa possa
realizar uma avaliao mais eficaz do projeto.
PROGER: Processo de Gerncia de Projetos de Software 37
Ns definimos um modelo de ciclo de vida para projetos de software

identificando fases desconsideradas nos modelos tradicionais, ou mesmo
considerados superficialmente, como o caso do RUP-Rational Unified Process. O
ProGer est dividido em cinco fases distintas (Figura 4.1): a prospeco, a proposta,
a execuo, a garantia e o encerramento. Em todas as fases devem ser aplicadas as
etapas do modelo de processo para gerenciamento de projetos proposto pelo
PMBOK [PMBOK2000].
Um projeto de software pode ser iniciado em qualquer uma das fases, com
exceo do encerramento. permitido que fases possam ser eliminadas do projeto,
isto , no h imposio de um fluxo rgido a ser seguido. A seguir, descreveremos
cada uma das fases do modelo de ciclo de vida. Os artefatos gerados em cada fase
esto representados na seo 4.1 deste captulo.
Prospeco
Proposta
Execuo
Garantia
Encerrament
o
FIGURA 4.1 Modelo de ciclo de vida de projetos de software
A fase de prospeco o perodo do ciclo de vida do projeto no qual so

identificadas as necessidades de um cliente, ou uma demanda de mercado
percebida pela empresa. A construo de um prottipo para uma demanda
observada pela empresa um exemplo de atividade desta fase. A caracterstica
principal desta fase a ausncia de um pedido formal por parte de um cliente, isto ,
uma requisio comercial. Nesta fase j se inicia o esforo tcnico e comercial da
empresa. Palestras sobre produtos, construo de prottipos e levantamento de
requisitos so exemplos de atividades que podem ocorrer nesta fase. Os elementos
da empresa que podem estar envolvidos nesta etapa so: gerentes, diretores e
tcnicos.
Considerando os processos de gerenciamento do PMBOK [PMBOK2000], a

inicializao desta fase dada por requisies informais de clientes, solicitao de
apresentao de produtos e identificao de uma demanda aprovada pela diretoria
da empresa. O planejamento desta fase bastante diverso, podendo ir desde simples
agendamentos de reunies at a confeco de planos de projeto para execuo de
um prottipo. A execuo determinada por palestras, apresentao de produtos e
construo de prottipos. A finalizao ocorre quando o cliente envia um pedido
formal para a execuo de um servio ou produto, o cliente avisa que no deseja o
que foi apresentado ou a empresa estabelece a continuidade ou descontinuidade do
esforo para uma demanda que foi observada.
Na fase de proposta, ocorre a formalizao de uma proposio da empresa

para um determinado cliente interno ou externo. As caractersticas principais desta
fase so: a existncia de uma requisio formal, a delimitao do escopo do projeto e
o processo decisrio do que dever ser realizado. As atividades principais desta fase
so a elicitao ou refinamento dos requisitos, e a confeco de propostas tcnicas e
comerciais.
A inicializao desta fase dada por requisies formais de clientes (um

exemplo uma carta convite solicitando um produto ou servio). O planejamento
desta fase estabelece quem e quando ser realizada cada atividade pertinente
confeco de uma proposta tcnica e/ou comercial. A execuo de um projeto na
fase de proposta determinada pela execuo de atividades como: delimitao do
escopo do projeto, levantamento dos requisitos do produto ou servio, estudo de
novas tecnologias, clculo de custos, elaborao de estimativas de tamanho e
esforo, anlise dos riscos, etc. Os modelos para planejamento de projetos podem
ser utilizados na etapa de execuo da fase de proposta. Dois exemplos destes
modelos podem ser vistos em Sanches [Sanches2001] e na [ISO9000-3:1997]. A
finalizao da fase de proposta ocorre quando o cliente envia um pedido solicitando a
execuo ou o cancelamento da proposta para o desenvolvimento de um produto ou
servio. A empresa tambm pode optar por cancelar uma proposta enviada para um
cliente.
A fase de execuo se caracteriza pela realizao de um escopo definido por

um projeto, considerando os recursos da organizao e um cronograma especfico.
Nesta fase so realizadas comumente as atividades de engenharia do produto de
software. Os principais artefatos gerados so: a especificao tcnica, os artefatos de
engenharia, o aceite do cliente e a comunicao ao cliente. A comunicao intensiva
com os clientes pode ocorrer nesta fase devido a atrasos, reviso de cronogramas,
revises tcnicas, incluso de novos requisitos, entre outros.
A inicializao da fase de execuo dada por uma autorizao interna para a

execuo do projeto. O planejamento prev a construo de um plano de projeto que
envolve atividades como: decompor requisitos, estimar em detalhes o tamanho do

software, estimar recursos do projeto, elaborar cronograma e negociar
compromissos. O modelo do ciclo de planejamento de projetos de software descrito
pela ISO9000-3 [ISO9000-3:1997] pode ser utilizado nesta etapa. Nesta etapa
prevista a confeco da estrutura de diviso de trabalho (WBS Work Breakdown
Structure), ou seja, a diviso do trabalho total do projeto em fases e atividades
independentes. O PMI guia a confeco de WBSs no trabalho [PMIWBS].
Nesta etapa tambm se define o modelo de ciclo de vida e a metodologia que

sero utilizados no desenvolvimento do projeto. A etapa de execuo determina a
realizao de atividades previstas no plano de projeto. A finalizao da fase de
execuo do modelo de ciclo de vida dos projetos se d com a entrega do produto ou
servio ao cliente. A obteno de um aceite do cliente (interno ou externo empresa)
determina o trmino da fase de execuo. A empresa e/ou cliente tambm pode
cancelar um contrato e desta forma finalizar um projeto sem que tenha sido terminada
a sua execuo.
Aps a execuo do projeto, o perodo de garantia estabelece um esforo

tcnico, para a reviso de alguns problemas encontrados aps o trmino do projeto.
A durao deste perodo depende do acordo realizado com o cliente. Os artefatos
desta fase geralmente so os mesmos da fase de execuo, s que dizem respeito
s modificaes e s correes do que j fora realizado e entregue ao cliente.
A inicializao desta fase acontece quando a empresa obtm o aceite formal do

cliente no trmino da execuo de um projeto. O planejamento prev o
estabelecimento de recursos que estaro disponveis para atender o cliente na fase
de garantia. Todavia, este estabelecimento prvio pode no existir. Na etapa de
execuo so realizadas as atividades para adequao do produto ou servio s
solicitaes do cliente. A finalizao da fase de garantia ocorre quando o prazo
determinado no contrato entre a empresa e o cliente findar.
No perodo de encerramento o projeto dado como finalizado. Todo o trabalho

proposto foi concludo, aceito e garantido. Outros tipos de encerramentos podem
ocorrer, tais como, os decorrentes de cancelamento de contratos. A inicializao
desta fase ocorre quando o prazo de garantia do projeto findar ou quando um projeto
em prospeco, proposta ou execuo for cancelado. No h etapas de
planejamento, de execuo e de finalizao.
4.1.1 Controle e avaliao
Pontos de avaliao so utilizados para sincronizar as expectativas dos

stakeholders atravs do ciclo de vida do projeto [Kerzner2001] [PMBOK2000]. A
definio de alguns pontos de avaliao permite a observao de problemas na
execuo do que fora planejado e possibilita uma ao corretiva antes do trmino do

projeto.
O ponto mais importante de avaliao de um projeto um milestone, que

usualmente o evento em que o projeto passa de uma fase para outra. Os pontos de
avaliao menores (intrafases) so altamente dependentes do projeto e da cultura
organizacional [Royce1998] e so mais importantes de serem considerados
principalmente na fase de execuo do modelo de ciclo de vida de projetos
propostos. Ns aconselhamos que sejam considerados os pontos de avaliao
descritos no modelo de ciclo de vida do desenvolvimento adotados pelo projeto para
a fase de execuo.
A aplicao do modelo PDCA Plan Do Check Act [Campos1992] em todas as

fases do modelo de ciclo de vida tambm pode ser considerada. O ciclo PDCA de
controle (Figura 4.2) objetiva a prtica do controle de processos e pode ser utilizado
para manter e melhorar as diretrizes de controle de um modelo de processo. O
estabelecimento de metas para cada fase importante para que o processo esteja
em constante melhoria. Os itens de controle podem considerar faixas de valores
padro como, por exemplo: qualidade-padro, custo-padro, prazo-padro,
quantidade-padro, entre outros.
P
A
(Plan)
(Action) Definir
as metas
Atuar
corretivamente Definir os
mtodos que
permitiro atingir as
metas propostas
Educar e
Verificar os treinar
resultados da
tarefa executada
Executar
a tarefa
C (coletar
dados)
(Check) D
(DO)
FIGURA 4.2 Ciclo PDCA de controle de processos
A ISO15504 [ISO15504:1-9:1998] e o CMM/CMMI [Paulk1993] [CMMI:2000]

definem tambm indicadores de desempenho do processo que podem ser
considerados para realizao de avaliaes para o modelo de ciclo de vida dos
projetos. O uso de checklist para cada ponto de avaliao definido tambm

bastante til.
4.2 STAKEHOLDERS
O PMBOK [PMBOK2000] define stakeholders como sendo os indivduos ou as

organizaes que esto ativamente envolvidos em um projeto. Ns estabelecemos,
para efeito de simplificao, um conjunto mnimo de elementos para a empresa que
podero estar envolvidos em um projeto. Estes elementos e suas funes esto
apresentados a seguir:
diretor responsvel por estipular as metas e diretrizes da empresa;
gerente comercial responsvel por manter a interface entre a empresa e o
cliente. deve estar apto a perceber demandas de mercado e a estabelecer
parcerias para construo de solues mais completas para clientes. realiza
tambm renegociaes de prazos e preos de projetos em execuo;
gerente de tecnologia responsvel por pesquisar e estabelecer as
tendncias tecnolgicas futuras da empresa. d apoio ao desenvolvimento
dos produtos/servios e dissemina o conhecimento tcnico da empresa;
gerente de projetos responsvel pelo gerenciamento e acompanhamento
de todos os projetos de software da empresa ou de uma rea especfica. faz
alocao e planejamento dos recursos da empresa como um todo ou da rea
de sua responsabilidade. revisa o planejamento feito pelo lder de projeto e
acompanha o uso adequado de metodologias e padres da empresa;
gerente de processo e qualidade estabelece metas, juntamente com a
diretoria, visando melhoria do processo de software e qualidade dos
produtos/servios gerados pela empresa. encarregado pela padronizao e
em auxiliar a gerncia de projetos no acompanhamento dos projetos da
empresa;
lder de projeto responsvel por planejar e gerenciar a execuo de um
projeto especfico;
tcnico neste grupo se encontra os desenvolvedores de forma geral, tais
como: engenheiros de software, administradores de sistemas de workflow,
analistas de sistemas, administradores da infra-estrutura, analistas de
negcio, arquitetos de dados, administradores de banco de dados, web
designers, entre outros;
cliente organizao ou setor da empresa que solicita a execuo de um
servio e/ou produto de software;
empresa sub-contratada outra empresa a quem pode ser delegada a
execuo de algumas atividades do projeto de software.
A Figura 4.3 apresenta uma proposta de organograma para uma empresa de

software, representando uma hierarquia entre os stakeholders.
DIRETOR Gerente Comercial

Gerente de Tecnologia
Cliente Gerente de Processo e Qualidade
Gerente Projetos
Empresa Subcontratada
Lder da Equipe 1 Lder da Equipe 2 Lder da Equipe n
Tcnicos Tcnicos Tcnicos
FIGURA 4.3 Organograma sugerido
4.3 ARTEFATOS
Artefato pode ser definido como um conjunto de informaes que produzido,

modificado ou usado por um processo. Ns estabelecemos um conjunto mnimo de
artefatos considerado crticos para o gerenciamento de projetos de software de uma
empresa. Estes artefatos so: documentos de requisitos, propostas tcnicas,
propostas comerciais, relatrios de teste, atas de reunio, relatrios de visitas
tcnicas, planos de projeto, ordens de servio e relatrios de aceite. A Figura 4.4
apresenta estes artefatos e a influncia existente entre eles.
FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto
Proposta Tcnica Documento Requisitos
Relatrio Visita
Proposta Comercial Tcnica
Plano de
Projeto Relatrio de Aceite
Ordem de Servio
Relatrio de Teste Ata de Reunio
Os pargrafos seguintes descrevem os artefatos, suas caractersticas principais

e os responsveis por sua confeco. Ressaltamos que, o ProGer est focado mais
em artefatos de gerenciamento do que em artefatos de engenharia.
A Tabela 4.1 mostra os artefatos que podem ser gerados nas respectivas fases
do modelo de ciclo de vida dos projetos descritos na seo 4.1.
projetos
Fase Artefatos
Prospeco Documentos de requisitos e atas de reunio.
Proposta Documentos de requisitos, propostas comerciais, propostas tcnicas, atas de
reunio.
Execuo Documentos de requisitos, relatrio de teste, relatrios de aceite, planos de
projeto, ordens de servio e relatrios de visitas tcnicas.
Garantia Relatrios de teste, atas de reunies, ordens de servio e relatrios de visita
tcnica.
Encerramento Atas de reunio.
Ns recomendamos que as instncias dos artefatos sejam armazenadas em

uma rea comum, na pasta de seus respectivos projetos. Estabelecemos um padro
para nomeao dos artefatos visando facilitar o acesso aos documentos. A Tabela
4.2 mostra este padro.
TABELA 4.2 Sugesto de padro para nomeao dos artefatos
Artefato Padro para Nomeao Exemplo

Documentos DocumentoRequisitos + _ + Cdigo_Projeto + _+ DocumentoRequisitos_DVX121-
de Requisitos Nmero_Verso 01_01

Propostas PropostaTcnica + _ + Cdigo_Projeto + _+ PropostaTcnica_DVX121-01_0
Tcnica Nmero_Verso 1
Proposta PropostaComercial + _ + Cdigo_Projeto + _+ PropostaComercial_DVX121-01
Comercial Nmero_Verso _01
Planos de PlanoProjeto + _ + Cdigo_Projeto + _+ PlanoProjeto_DVX121-01_01
Projeto Nmero_Verso
Relatrio de RelatorioTeste + _ + Cdigo_Projeto + _+ Data RelatorioTeste_DVX121-01_200
Teste (ano-mes-dia) + _ + [Nmero_Sequencial] 1-01-01_01
Atas de AtaReuinio + _ + Cdigo_Projeto + _+ Data AtaReunio_DVX121-01_2001-
Reunio (ano-mes-dia) + _ + [Nmero_Sequencial] 01-01_01
Relatrios de RelatrioTcnico + _ + Cdigo_Projeto + Data RelatrioTcnico_DVX121-01_2
Visita Tcnica (ano-mes-dia) + _ + [Nmero_Sequencial] 001-01-01_01
Relatrios de Aceite + _ + Cdigo_Projeto + _+ Aceite_DVX121-01_01_01
Aceite Nmero_Aceite + _ + [Nmero_Verso]
Ordens de Ordem+ Cdigo_Projeto + _+ NmeroOrdem Ordem_DVX121-01_01
Servio
4.3.1 Documento de requisitos
Um requisito descreve uma condio ou aptido que um produto de software ou

servio deve possuir para satisfazer um contrato ou uma requisio de um cliente da
empresa. O documento de requisitos registra todos os requisitos funcionais e no-
funcionais deste produto ou servio.
Este artefato pode possuir diversas verses com nveis de refinamento

diferenciados e deve ser descrito sempre em uma linguagem que pode ser entendida
tanto por engenheiros de software quanto pelo cliente. A Figura 4.5 apresenta uma
sugesto de contedo para este artefato. O apndice A deste mdulo apresenta um
template para a confeco de um documento de requisitos.
O documento de requisitos pode ser confeccionado em projetos que se

encontram em todas as fases, com exceo da fase de encerramento. O mais
comum sua confeco nas fases de prospeco e proposta, com o refinamento
sendo realizado na fase de execuo. Este artefato pode ser feito por gerentes de
projeto, gerentes comerciais, lderes de projeto e tcnicos.
Contedo do Documento de Requisitos

Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE....................................................................................2

Parceria..........................................................................................................145
Reitor ............................................................................................................145
Vice-Reitor.....................................................................................................145
Editorao .....................................................................................................145
Impresso......................................................................................................145
145
Introduo 7
2.2 PMBOK................................................................................................................18
2.5 Consideraes.....................................................................................................27
4.2 Stakeholders .......................................................................................................41
4.3 Artefatos .............................................................................................................42
4.3.2 Proposta tcnica......................................................................................48
FIGURA 4.5 Sugesto de contedo para um documento de requisitos

4.3.2 Proposta tcnica
Uma proposta tcnica apresenta uma proposio de prestao de servios para

um determinado cliente. Serve como instrumento para o acompanhamento do servio
prestado ou a confeco de um produto. Este artefato pode ser confeccionado por
qualquer elemento da empresa, dependendo da habilidade e dos conhecimentos que
este possui no escopo que est sendo abordado. Porm, sempre deve ser revisada
pelo gerente de processo e qualidade e/ou gerente de projeto.
O documento de requisitos pode ser especificado dentro da proposta tcnica ou

estar como um anexo desta. A Figura 4.6 apresenta uma sugesto de contedo para
uma proposta tcnica. O apndice A deste mdulo apresenta um template para a
confeco de uma proposta tcnica.
Contedo da Proposta Tcnica

Parceria..........................................................................................................145
Reitor ............................................................................................................145
Vice-Reitor.....................................................................................................145
Editorao .....................................................................................................145
Impresso......................................................................................................145
145
Introduo 7
2.2 PMBOK................................................................................................................18
2.5 Consideraes.....................................................................................................27
4.2 Stakeholders .......................................................................................................41
4.3 Artefatos .............................................................................................................42
4.3.2 Proposta tcnica......................................................................................48
FIGURA 4.6 Sugesto de contedo para uma proposta tcnica
4.3.3 Proposta Comercial
Este artefato apresenta uma proposta comercial de prestao de servios para

um determinado cliente e dever servir como o instrumento legal para o
acompanhamento do servio prestado. Os termos aqui estabelecidos foram definidos
a partir das informaes constantes na proposta tcnica quando j conhecida e aceita
pelas partes envolvidas. Deve contemplar acordos referentes a preo, pagamento,
garantia e multas. A confeco de uma proposta comercial de responsabilidade dos
gerentes comerciais, porm deve ser aprovada pelo diretor.
A Figura 4.7 sugere um contedo para uma proposta comercial. Um framework

para construo de uma proposta comercial pode ser visto no Apndice A.
Contedo da Proposta Comercial

Parceria..........................................................................................................145
Reitor ............................................................................................................145
Vice-Reitor.....................................................................................................145
Editorao .....................................................................................................145
Impresso......................................................................................................145
145
Introduo 7
2.2 PMBOK................................................................................................................18
2.5 Consideraes.....................................................................................................27
4.2 Stakeholders .......................................................................................................41
4.3 Artefatos .............................................................................................................42
4.3.2 Proposta tcnica......................................................................................48
FIGURA 4.7 Contedo para uma proposta comercial
4.3.4 Plano de Projeto
Um plano de projeto um documento formal e aprovado que utilizado para

gerenciar a execuo de um projeto [PMBOK2000]. Um plano de projeto delimita o
escopo da execuo do projeto levando em conta as condicionantes (opes de
deciso) escolhidas pelo cliente e anteriormente aprovadas na proposta tcnica e
comercial.
A estrutura de diviso do trabalho (WBS Work Breadkdown Structure ou EAP

Estrutura Analtica do Projeto) o elemento central deste artefato, ou seja, a diviso
do trabalho total do projeto em etapas e atividades independentes. Alm da WBS,
este artefato tambm deve apresentar os padres e tcnicas adotadas, a metodologia
e o modelo de ciclo de vida do desenvolvimento, os artefatos que sero utilizados e
gerados, as ferramentas necessrias, o cronograma de atividades com os recursos
alocados, e os critrios para concluso das atividades e etapas do projeto.
O plano de projeto serve de guia para o lder de projeto acompanhar o

andamento dos trabalhos e so confeccionados por lderes de projeto com aprovao
do gerente de projeto e/ou gerente de processo e qualidade. A Figura 4.8 apresenta
uma sugesto de contedo para um plano de projeto. Um modelo de plano de projeto
pode ser visto no Apndice A.
Contedo do Plano de Projeto

Parceria..........................................................................................................145
Reitor ............................................................................................................145
Vice-Reitor.....................................................................................................145
Editorao .....................................................................................................145
Impresso......................................................................................................145
145
Introduo 7
2.2 PMBOK................................................................................................................18
2.5 Consideraes.....................................................................................................27
4.2 Stakeholders .......................................................................................................41
4.3 Artefatos .............................................................................................................42
4.3.2 Proposta tcnica......................................................................................48
FIGURA 4.8 Sugesto de contedo para um plano de projeto
4.3.5 Relatrio de teste
Um relatrio de teste tem por finalidade o registro dos testes realizados em

conjunto com os clientes (validao dos requisitos do projeto). Serve de documento
base para a especificao de novos requisitos, e anlise e previso para a realizao
de alteraes no produto ou servio de software. Deve possuir a concordncia dos
usurios que esto envolvidos no processo de teste.
importante durante a confeco deste artefato que seja feita uma referncia
aos requisitos que esto sendo testados. Este artefato confeccionado por tcnicos
e/ou lderes de projeto e pode ser utilizado para validar um nico ou um agrupamento
de requisitos ao mesmo tempo. A Figura 4.9 apresenta um modelo para relatrio de
casos de teste.
RELATRIO DE TESTE
PROJETO <NOME DO PROJETO>
CLIENTE <NOME DO CLIENTE>
CONTRATO: <IDENTIFICADOR DO CONTRATO>
Nome do Projeto
Data do Teste
Repetio deste teste [ ]1o [ ]2o [ ]3o [ ]4o [ ]5o [ ]6o [ ]7o [ ]8o [ ]9o [ ]10o [ ]11o [ ]12o
Relato do Teste e Observaes
Empresa <Empresa> <Cliente> <Cliente>

Nome
Assinatura
FIGURA 4.9 Modelo de relatrio de teste
4.3.6 Ata de reunio

As atas de reunio devem registrar todas as reunies internas e externas da

empresa descrevendo os tpicos discutidos e as metas estabelecidas. As atas de
reunio podem ser confeccionadas por qualquer pessoa da empresa e devem conter
a rubrica e aceite de todos os participantes da reunio. A Figura 4.10 apresenta um
modelo para este artefato.
ATA DE REUNIO
PROJETO <NOME DO PROJETO>
CLIENTE <NOME DO CLIENTE>
CONTRATO: <IDENTIFICADOR DO CONTRATO>
Redator: <nome do redator da ata>Data/Hora Incio: <hora incio>Local: <local onde foi realizada a
reunio>Data/Hora Fim: <hora fim>
1. OBJETIVO
<objetivo da reunio>
2. PARTICIPANTES
<relacionar nomes, funes dos participantes>
3.TPICOS DISCUTIDOS/DEFINIES Rubricas
<descrio do tpico>
<detalhamento da definio>
4. PRXIMAS AES
<detalhar a ao>
Responsvel: <nome do responsvel >
5. PRXIMA REUNIO
<data da prxima reunio, se for o caso>
6. OBSERVAO
Esta ata foi redigida por <Nome Redator/e-mail/fone>. Qualquer dvida ou discordncia, favor entrar em contato com o redator.
FIGURA 4.10 Modelo de ata de reunio
4.3.7 Relatrio de visitas tcnicas
Os relatrios de visitas tcnicas tm por objetivo registrar uma visita ao cliente,

solicitada para resolver um determinado problema ou para elicitar algum
procedimento novo. Estes relatrios geralmente so confeccionados por tcnicos e
lderes de projeto. A realizao da manuteno que envolva uma visita no cliente
registrada por este artefato. A Figura 4.11 apresenta um modelo de relatrio de visita
tcnica.
RELATRIO VISITA TCNICA

Nome do Projeto:
Nome do Cliente:
Identificador do Contrato:
Solicitante: Data Solicitao:
Local: Data Entrega Servio:
Problema / Requisio
Soluo
Observao

Nome
Assinatura
FIGURA 4.11 Modelo de relatrio de visita tcnica
4.3.8 Relatrio de aceite
Um relatrio de aceite tem por finalidade obter o aceite do cliente e avaliar o

quo satisfeito ele ficou com o produto ou servio, e estabelecer metas para a
resoluo dos problemas encontrados. Ns definimos dois tipos de relatrios de
aceite: parcial e final. A Figura 4.12 apresenta um modelo para este artefato.
O relatrio de aceite parcial estabelece a finalizao de uma etapa do projeto.

Esta etapa pode ser prevista pela ocorrncia de um milestone ou mesmo pelo
estabelecimento de entregas parciais do servio ou produto. Um exemplo pode ser o
aceite do documento de requisitos revisado e detalhado. O relatrio de aceite final
objetiva delimitar o evento que estabelece que o projeto entra na garantia.
FIGURA 4.12 Modelo de relatrio de aceite
Os relatrios de aceite utilizam o documento de requisitos como base e

registram a satisfao do cliente, a estratgia para resoluo dos problemas
RELATRIO DE ACEITE (FINAL/PARCIAL)

Projeto: <Nome do Projeto> Cliente: <Nome Cliente> Contrato: <Nmero Contrato>
Responsvel: <Lder ou gerente de projeto, responsvel pelo aceite> Aceitao: <Nmero >
Revisor(es): <clientes/usurios envolvidos no aceite> Data: <Data da Aceite>
I . REQUISITOS
REQUISITO DESCRIO AVALIAO
FUNCIONAL
<cdigo do <descrio do requisito> <OK, no conforme, conforme com restries>
requisito>
...
...
REQUISITO NO DESCRIO AVALIAO

FUNCIONAL
<cdigo do requisito> <descrio do requisito> < OK, no conforme, conforme com restries>
...
...
II . PRODUTOS ENTREGUES
PRODUTO OBSERVAO AVALIAO
<nome do <descrio da observao> < OK, no conforme, conforme com restries>
produto>
...
...
III . NO-CONFORMIDADES
<Nesta seo devem ser relacionados os desvios identificados e "como e quando" sero tratados.>
ITEM RESPONSVEL AES E PRAZOS
<descrio do item a ser <nome do responsvel> < como ser solucionado, data>
tratado>
...
...
IV . SATISFAO DO CLIENTE COM RELAO AO SERVIO

ITEM OBSERVA AVALIAO
O
Qualidade do atendimento < observao> < excepcional ,bom, razovel,insuficiente, pssimo>
Qualidade dos produtos
entregues
...
V . CONCLUSO
Servio Considerado Conforme
Servio Considerado Conforme com Restrio
Servio Considerado No-Conforme
VI . OBSERVAO:
apontados pelo cliente e estabelecimento de novas metas para correo de no-

conformidades. Um relatrio de aceite pode ser confeccionado por um lder de projeto
e/ou gerente de projeto. O apndice A apresenta um template para este artefato.
4.3.9 Ordem de Servio
Uma ordem de servio registra uma requisio formal de um cliente para a

realizao de um servio em projetos que esto em execuo ou j foram concludos.
A ordem de servio preenchida pelo cliente e entregue ao lder do projeto. A
liberao do servio solicitado necessita do aval do gerente de projeto ou gerente de
processo e qualidade para que possa ser realizado. A Figura 4.13 apresenta um
modelo para este artefato.
ORDEM DE SERVIO
Nome do Projeto:
Nome do Cliente:
Identificador do Contrato:
Solicitante: Data Solicitao:
Local: Data Entrega Servio:
Solicitao
Custo Associado
Observao

Nome
Assinatura
FIGURA 4.13 Modelo de uma ordem de servio
4.4 FLUXOS DE TRABALHO
Os fluxos de trabalho (workflows) representam uma seqncia de atividades que

so executadas em um negcio para produzir um resultado de valor para algum ator
do negcio. De forma mais especfica, um fluxo de trabalho define as atividades que
devero ser realizadas, a interconexo entre estas atividades, os atores envolvidos e

os produtos (artefatos, produtos de manufatura, comunicao, etc.) que sero
gerados para satisfazer uma necessidade do negcio. A ordem da execuo de um
fluxo de trabalho pode ser serial, paralela e/ou condicional.
Os fluxos de trabalho podem ser descritos informalmente ou formalmente.

Fluxos de trabalho formais so descritos atravs de linguagens apropriadas, as WDLs
(Workflow Description Languages). Algumas destas linguagens so derivadas de
modelos conceituais conhecidos na engenharia de software como statecharts
[Kappel1995]. Outras, todavia, usam suas prprias estruturas conceituais como em
[Casati1995] e [Rouiller1998]. Ns optamos por descrever os fluxos utilizando
flowchart descrito em [Kerzner2001], por ser mais simples e permitir que sejam
declarados tambm os executores de cada atividade. A Figura 4.14 apresenta as
primitivas que o flowchart utiliza para descrever os fluxos de trabalho.
Elipses mostram materiais, informaes ou

aes (entradas) que iniciam o fluxo ou para
mostrar o resultado do trmino (sada) do
fluxo
Um retngulo ou caixa usado para mostrar

uma tarefa ou atividade que deve ser
executada no fluxo
Smbolo que mostra pontos no fluxo onde

uma questo est sendo realizada ou uma
deciso requerida
Um crculo com uma letra ou um nmero

A identifica uma quebra no fluxo que
continuada na mesma pgina ou em outra
pgina
Setas mostram a direo do fluxo
FIGURA 4.14 Primitivas do flowchart
No ProGer estabelecemos trs fluxos de trabalho para uma empresa de

pequeno ou mdio porte: fluxo de captao de projetos, fluxo de execuo de
projetos e fluxo avaliao de projetos. Estes fluxos especificam os procedimentos que
so utilizados ao longo do modelo de ciclo de vida dos projetos apresentado na seo
4.1. O Apndice B apresenta em detalhes os fluxos do ProGer. A seguir faremos uma
apresentao sucinta destes fluxos.
4.4.1 Fluxo de captao de projetos
O fluxo de captao de projetos define os procedimentos e artefatos que devem

ser gerados pela empresa quando ocorre a identificao de uma demanda ou
solicitao de um servio ou produto pelo cliente. Este fluxo termina quando uma
proposta comercial entregue ao cliente ou um produto, servio ou prottipo de uma
demanda que foi visualizada finalizado. Cancelamentos podem ocorrer por parte do
cliente ou da empresa. Este fluxo de trabalho utilizado nas fases de prospeco e
proposta do modelo de ciclo de vida para projetos de software.
A Figura 4.15 apresenta um resumo do fluxo de captao de projetos. O fluxo

completo est definido no Apndice B deste mdulo.
Incio
Cliente solicita servio

ou uma devmanda
visualizada
Levantamento de
requisitos
Confeco do
documento de
requisitos
Confeco de
plano de
projeto
S
Construo de Execuo das
prottipo? atividades do
plano de projeto
N
Confeco e
aprovao de
proposta tcnica
Confeco e
aprovao de
proposta comercial
Proposta comercial
entregue ao cliente
Trmino
FIGURA 4.15 Resumo do fluxo de captao de projetos
A confeco de propostas tcnicas, propostas comerciais e planos de projeto

necessitam de estimativas de tempo e custo, necessrias para a realizao do
escopo proposto no projeto. Diversas tcnicas de estimativas existem com o intuito
de prever tamanho, esforo, prazo e custo para produtos e servios de software, tais
como [Trindade2000] [Braga1996] e [Boehm1981]. Muitas destas tcnicas requerem
uma grande variedade de fatores de entrada, incluindo dados histricos, medidas de
complexidade de sistemas, anlise de equipes de desenvolvimento, algumas
restries de projeto e estimativas do volume de cdigo (o tamanho do projeto).
Porm, para que as tcnicas sejam efetivas a empresa deve encontrar as condies
apropriadas ao seu negcio [Sanches2001].
As empresas de pequeno porte possuem de forma geral algumas limitaes que

devem ser consideradas para a escolha da tcnica a ser utilizada nas estimativas de
seus projetos de software, entre elas podem citar: recursos de pessoal limitado, alto
rodzio de pessoal, imaturidade metodolgica, projetos executados sem planejamento
detalhado, requisitos realizados geralmente por apenas um elemento da empresa,
plano de risco e plano de contingncia no considerados e processo ad-hoc.
O trabalho de Sanches [Sanches2001] traz uma reviso bibliogrfica dos

mtodos e tcnicas utilizadas na fase de elaborao de estimativas e nas demais
fases do processo de planejamento, bem como um levantamento preliminar das
ferramentas disponveis para apoio s tarefas. Porm tambm conclui que, os
mtodos para as estimativas, planejamento e controle das atividades devem ser
simples, rpidos, eficazes e apresentados em uma linguagem mais aderente aos
negcios empresariais. Ns tambm acreditamos que as empresas de pequeno porte
devem utilizar tcnicas simples para estimar produtos e servios de software, porm
estas tcnicas devem estar formalizadas e entendidas pelos elementos da empresa
envolvidos no processo.
Uma tcnica que pode ser utilizada para estimar est focada no conhecimento e
capacidade de estimar das pessoas. Desta forma, est apto a estimar qualquer
pessoa da empresa, dando prioridade quelas que possurem mais experincia na
tecnologia que ser empregada, maiores conhecimentos do escopo do produto e/ou
servio, e conhecimentos da organizao que solicitou a execuo do projeto
(cliente).
Sugere-se que esta estimativa seja realizada baseada nos requisitos que o
projeto deve satisfazer. Para cada requisito do produto, ou servio detalhado no
documento de requisitos, uma quantidade de esforo em horas deve ser estimada.
Esta quantidade de horas deve considerar de preferncia sempre um profissional de
nvel mdio. A Tabela 4.3, confeccionada atravs da observao de realizamos em
projetos em algumas empresas de pequeno porte, apresenta um exemplo de como
os nveis de profissionais podem ser considerados.

empresa de pequeno porte
Projeto:
Nvel do Roteamento
Profissionalde Caminhes Categoria de Profissionais
Requisito:1[RF001] Cadastramento de Rotas dos
Gerentes especializados eCaminhes Dresser na minerao de
consultores
Tamandu
2 Gerentes e tcnicos masters
Tipo de atividade: Engenharia de software
3
Complexidade :03 Lderes de projetos e tcnicos seniores
4 essencial Tcnicos juniores
Prioridade:
Horas previstas
5 para realizao: 24
Tcnicos trainees e estagirios
Nvel de profissional considerado: 3
A previso em horas determina o esforo que ser despendido para a execuo

do requisito no projeto. Quando da confeco do plano de projeto, por exemplo,
pode-se fazer uma estimativa mais precisa do tempo real que ser gasto
estabelecendo para cada requisito a ser realizado um profissional especfico ou nveis
de profissionais e quantidade necessria de profissionais.
A estimativa de custo monetrio para o projeto pode ser realizada baseando-se

na quantidade de horas previstas para a realizao de cada requisito do projeto e no
custo da hora do profissional considerado na estimativa. A estimativa de prazo do
projeto feita atravs da distribuio da disponibilidade dos recursos humanos que
executaro as atividades do projeto.
A Tabela 4.4 trs um resumo de mtricas que podem ser utilizadas no fluxo de
captao de projetos de software. Maiores detalhes e pontos de medio podem ser
vistos no Apndice B.
TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos
Mtricas Sugeridas no Fluxo de Captao de Projetos

T1 = Tempo de atendimento solicitao do cliente;
T2= Tempo gasto para a confeco de uma proposta tcnica/comercial
T3= Tempo gasto para a avaliao de uma demanda observada
T4= Tempo estimado para a realizao do prottipo
T5= Tempo gasto para a construo de um prottipo
T6= Tempo gasto para correo das no-conformidades do prottipo
T7= Tempo gasto para a validao do prottipo
HE = Horas estimadas para a realizao de um requisito de um de projeto
THE (Total de horas estimadas para o projeto) = Somatrio de todas as HE
V = Valor do salrio ms do profissional
VH(Valor hora do profissional) = V / 170
XE (percentual do esforo estimado para o requisito no projeto) = HE / THE * 100
CE (custo estimado para o requisito) = HE * VH
TCE (total do custo estimado para o projeto) = somatrio de todos CE do projeto
4.4.2 Fluxo de execuo de projetos
O fluxo de execuo de projetos se inicia aps a aprovao de uma proposta

comercial ou liberao da diretoria para a execuo de um projeto interno da
empresa. O trmino deste fluxo se d quando todo o escopo do projeto foi realizado.
Excees deste fluxo incluem: (1) a alterao do documento de requisitos aps seu
detalhamento, (2) cancelamento do projeto por parte da empresa ou do cliente e (3) o
cliente no deu um aceite satisfatrio implicando na necessidade de um novo plano
de projeto. Este fluxo de trabalho ocorre na fase de execuo do modelo de ciclo de
vida para projetos de software. A Figura 4.17 apresenta um resumo do fluxo de
execuo de projetos. O fluxo completo est definido no Apndice B deste mdulo.
Incio
Anlise da proposta
tcnica/comercial
aprovada
Confeco e
aprovao do
plano de projeto
Execuo das
atividades do
plano de projeto
Problemas/ Determinao da Realizao das

novos estratgia para resoluo alteraes no
requisitos? S dos problemas plano de projeto
Obteno do
aceite do projeto
Planejamento Realizao
necessrio dos ajustes das atividades
ajustes ? S de ajuste
Produto/Servio
entregue ao cliente
Trmino
FIGURA 4.17 Resumo do fluxo de execuo de projeto
Aps a anlise da proposta tcnica e comercial, inicia-se no fluxo de execuo

de projetos a elaborao de um plano de projeto, que define a estrutura de diviso
total do trabalho do projeto em etapas e atividades independentes. Outros elementos
tambm so definidos antes de efetivamente iniciar os trabalhos do projeto, tais
como: as tcnicas, metodologias, ferramentas e o modelo de ciclo de vida de
desenvolvimento que sero adotados; artefatos que sero utilizados e gerados;
riscos; cronograma de atividades; e critrios para concluso das atividades e etapas
do projeto. O plano de projeto serve de guia para o lder de projeto acompanhar o
andamento dos trabalhos e delimita o escopo da execuo do projeto, levando em
conta as condicionantes escolhidas pelo cliente e anteriormente aprovadas na
proposta tcnica e comercial.
Uma atividade a ser realizada em um projeto determinada por um requisito

funcional ou no-funcional a ser cumprido. Uma tarefa uma ocorrncia da execuo
desta atividade. Sempre que uma tarefa for executada, o executor deve estimar o
percentual de realizao do requisito. Uma classe de tipo de atividade deve sempre
ser associada ao requisito durante a confeco do plano de projeto, como por
exemplo: engenharia de software, capacitao pessoal e coordenao.
Ns propomos que quando uma tarefa for executada, o executor estabelea que
tipo de atividade realizou. No caso de engenharia de software, um tipo de atividade
poderia ser: levantamento de requisitos, anlise, projeto, implementao e teste.
Desta forma, o apontamento de uma tarefa para uma atividade (requisito) de um
projeto pode ser feito como apresentado na Figura 4.18.
O apontamento (registros) de todas as horas gastas nos requisitos do projeto, e
Projeto: Roteamento de Caminhes

Requisito: [RF001] Cadastramento de Rotas dos Caminhes Dresser na minerao de
Tamandu
Tipo de atividade: Engenharia de software
Subclasse da atividade : Projeto
Data da execuo da atividade: 12/12/2001
Total de horas gastas: 10 horas
Percentual realizado do requisito: 10%
Problemas encontrados: ok
Observaes: xxx xxxx xxxx
suas respectivas taxas de realizao so utilizados para obteno de algumas

mtricas. A taxa de realizao, por exemplo, permite que os lderes de projeto
possam visualizar o quanto o projeto evoluiu. O registro dos problemas encontrados
em campo, durante o apontamento das horas, auxilia os lderes para a identificao
de problemas e determinao de estratgias para a sua resoluo. Ns
recomendamos, para empresas de pequeno porte, que o apontamento de horas seja
feito uma vez ao dia, de preferncia no incio do expediente.
O fluxo de execuo de projetos dado como finalizado aps o cliente validar e

aceitar o produto ou servio de software que foi encomendado. Durante as atividades
de validao, algumas no-conformidades podem ser encontradas e a empresa deve
estabelecer estratgias para a realizao dos ajustes (que sero registradas nos
documentos de aceite parcial e final).
A Tabela 4.5 apresenta algumas mtricas que podem ser utilizadas no fluxo de
execuo de projetos para auxiliar o acompanhamento dos projetos e posterior
anlise do desempenho do projeto. Maiores detalhes e pontos de medio podem ser
vistos no Apndice B.
TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos
Mtricas Sugeridas no Fluxo de Execuo de Projetos

T8 = Tempo gasto para validar um requisito
T9 = Tempo gasto para realizar e validar um requisito
T10 = Tempo gasto para confeccionar e aprovar o plano de projeto
T11 = Tempo para obteno do aceite do produto/servio realizado
T12 = Tempo gasto para correo das no-conformidades do produto/servio
T13 = Tempo gasto para a validao do produto/servio
h = horas gastas para execuo de uma tarefa de um requisito em um plano de projeto
(apontamento dirio)
x = percentual realizado do requisito (estimativa dada pelo executor ao trmino do
apontamento de uma h)
H = somatrio de h do requisito em um plano de projeto (apontamento total tempo gasto
para realizar o requisito)
TH (Total de horas gastas para a execuo de um plano de projeto) = Somatrio de todas as
H
TX = (percentual esforo real j gasto para a realizao do requisito do projeto) = H / TH *
100
TTX (percentual de realizao do projeto) = somatrio de todas (HE / THE * x) * 100 do
projeto
4.4.3 Fluxo de avaliao de projetos
O fluxo de avaliao de projetos estabelece atividades que comparam o que foi

planejado para ser executado e o que foi efetivamente realizado. A Figura 4.19
apresenta um resumo do fluxo de avaliao de projetos. O fluxo completo est
definido no Apndice B deste mdulo.
O fluxo de avaliao de projetos permite que a empresa possa ter subsdios

para tomar decises de melhoria do processo de software. A anlise do desempenho
de um projeto de software depende das metas que a empresa pretende atingir com a
melhoria de seu processo. Um exemplo de algumas anlises que poderiam ser feitas
inclui: anlise da satisfao do cliente; desempenho das estimativas (esforo, prazo e
custo); anlise das possveis causas para os problemas encontrados em campo;
desempenho dos recursos humanos; verificao se o trabalho realizado foi dentro do

escopo inicialmente pretendido; etc.
Incio
Anlise do
desempenho do
projeto
Identificao de
melhorias para
o processo
N
Melhorias
aprovadas?
Introduo de
melhoria no
processo
Trmino
FIGURA 4.19 Resumo do fluxo de execuo de projetos
A anlise do desempenho do projeto fornece subsdios para que melhorias

possam ser identificadas para o processo de software. Um exemplo pode ser a
anlise do desempenho das estimativas, que possibilita a determinao de quais
recursos humanos esto mais aptos a estimar para que clientes. Isto possibilita que a
empresa direcione estes elementos para a realizao de planejamentos mais
realsticos de prazo e custo para o projeto.
Aps identificar as possveis melhorias para o processo de software

necessrio que estas melhorias sejam aprovadas antes de sua efetiva implantao
na empresa. A aprovao ou no de uma melhoria para o processo depende das
metas pretendidas pela organizao.
A Tabela 4.6 apresenta algumas mtricas que podem ser utilizadas no fluxo de
avaliao dos projetos. Maiores detalhes e pontos de medio podem ser vistos no
Apndice B.
TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos
Mtricas Sugeridas no Fluxo de Avaliao de Projetos

T14 = Tempo gasto para analisar o desempenho do projeto
T15 = Tempo gasto para aprovar e implantar melhorias no processo atravs da anlise do
projeto
T16 = Tempo gasto para planejar, executar e analisar um projeto
XF (percentual de falha da estimativa do requisito) = (HE H) / HE * 100
TXF(percentual de falha da estimativa do projeto) = (THE TH) / THE * 100
TCF(percentual de falha na estimativa de custo do projeto) = (TCE TC) / TCE * 100
CEF (percentual de falha na estimativa de custo do requisito) = (CE C) / CE * 100
4.5 CONSIDERAES
Objetivamos com este captulo apresentar um exemplo de processo de gerncia

de projetos que pode ser utilizado em empresas de pequeno e mdio porte. O
processo aqui apresentado j foi utilizado como base para a modelagem do processo
de gerncia de projetos de algumas empresas de software. O experimento mais
significativo do uso deste processo est relatado em Rouiller [Rouiller2001], que
descreve o acompanhamento de 81 projetos de software em uma empresa de
pequeno porte. Este trabalho tambm apresenta um framework conceitual para a
construo de ferramentas para apoiarem a gerncia de projetos.
A Tabela 4.7 apresenta alguns procedimentos utilizados pelo ProGer que esto
relacionados s reas de conhecimento definidas pelo PMBOK.

conhecimento do PMBOK.
rea do Procedimentos do ProGer

Conhecimento
desenvolvimento e acompanhamento do plano de projeto
controle da execuo do plano de projeto
resoluo de problemas durante a execuo
Gerncia de controle das verses e mudanas dos artefatos
Integrao reunies peridicas para estabelecimentos de metas e de acordos
uso dos fluxos de trabalho
reviso dos artefatos
definio do escopo do projeto atravs documento de requisitos
aprovao do documento de requisitos pelo cliente
Gerncia de reviso da especificao do documento de requisitos
Escopo de Projetos uso do modelo de ciclo de vida e seus artefatos associados
uso dos artefatos ordem de servio e relatrio de teste para identificar novos
requisitos
refinamento dos requisitos antes de dar incio s atividades do projeto
definio da rastreabilidade entre os requisitos
Gerncia de estimativa da durao das atividades dos requisitos do projeto
Tempo apontamento de esforo gasto para desenvolver as atividades
acompanhamento peridico da evoluo do projeto
Gerncia de Custo estimativa de custos para cada atividade do projeto baseada no esforo
apontamento de esforo gasto para desenvolver as atividades
anlise dos dados histricos de outros projetos
determinao de metas de qualidade a serem atingidas
avaliao peridica do projeto, baseado nas metas de qualidade desejada
Gerncia da avaliao da satisfao do cliente atravs do relatrio de aceite
Qualidade registro e anlise dos problemas na execuo dos projetos
realizao de estimativas e avaliao do desempenho dos projetos
uso do ciclo PDCA
controle da disponibilidade dos recursos
registro das funes e responsabilidade de cada recurso
Gerncia de uso dos fluxos de trabalho
Recursos Humanos desenvolvimento e acompanhamento do plano de projeto
identificao das habilidades dos recursos humanos
acompanhamento e anlise do desempenho dos recursos humanos
definio de milestones e reunies peridicas
uso dos fluxos de trabalho
Gerncia de reunies peridicas
Comunicao disseminao do conhecimento adquirido pelos recursos humanos da empresa
identificao dos riscos do projeto e estabelecimento de planos de contingncia
Gerncia de Risco desenvolvimento e acompanhamento do plano de projeto
Gerncia de desenvolvimento da proposta comercial
Aquisio desenvolvimento do documento de requisitos
EXERCCIOS DE FIXAO:
1.Considerando as metas que a empresa de software pretendia alcanar com a
implantao de um processo de gerncia de projetos (identificada no captulo 3 deste
mdulo), quais delas voc acredita ser possvel alcanar considerando o ProGer?
Identifique em que pontos do ProGer voc pode obter informaes para poder ter
subsdios para efetuar a melhoria pretendida (Discuta isso no frum virtual). Lembrando
que as metas pretendidas so:
Melhoria da satisfao do cliente;
Melhoria da qualidade dos produtos gerados;
Melhoria da qualidade do processo;
Melhoria do gerenciamento dos recursos humanos;
Melhoria da comunicao interna e externa da empresa;
Melhoria do desempenho das estimativas de esforo, custo e prazo;
Melhoria do estabelecimento das metas organizacionais;
Melhoria na identificao dos riscos.
2.Leia o estudo de caso da utilizao do ProGer em uma empresa de pequeno porte.
Este estudo se encontra no material complementar do ambiente virtual.
3.Quais as reas de processo e as prticas bsicas do modelo CMMI que o ProGer
satisfaz? (o modelo CMMI est no material complementar). Crie uma tabela com este
comparativo, inclua sugestes de melhorias em artefatos e fluxos para tornar o ProGer
aderente ao CMMI e apresente suas justificativas. (Pode ser utilizada a ISO15504
tambm para este exerccio).
4.Se a sua empresa desejasse implantar um processo de gerncia de projetos, de que
forma voc o faria? (apenas para meditar).
5
FERRAMENTAS PARA APOIO
AUTOMATIZADO AO PROGER
Alm de outros fatores, realizar o gerenciamento de projetos sem automao

impossibilita a obteno de algumas mtricas e informaes gerenciais de forma mais
eficiente, alm de exigir grande interveno humana. Contudo, os ambientes de
gerenciamento de projetos disponveis no mercado no so especficos para
software, dificultando o processo.
A engenharia de processo tem se esforado no sentido de definir modelos e

padres para a construo de um efetivo ambiente para o processo de software.
Exemplos podem ser vistos em [Cromer1999] [Gates1997] [Machado1999] e
[Maidantchik1999]. O reconhecimento da importncia dos processos e o crescimento
da cultura de processo tm levado as empresas criao de ambientes de software
mais eficientes, um exemplo o PSEEs - Process-Centered Software Engineering
Environment. Os PSEEs integram tanto os requisitos do produto, que so o foco da
engenharia de software, como os requisitos do processo, que so o foco do
gerenciamento do projeto e da engenharia de processo.
Apesar de reconhecer a importncia do processo de software e sua natureza

dinmica, os PSEEs so ambientes ainda complexos e de difcil utilizao [Reis2000].
Muitos problemas desta abordagem ainda no esto bem resolvidos, como os
mecanismos para integrao. No conceito mais amplo de PSEEs ainda inexistem
ferramentas disponveis para uso efetivo pelas empresas. De forma geral so mais
comuns os gerenciadores de processos, que so uma camada dos PSEEs. Todavia,
estes gerenciadores desconsideram alguns elementos importantes no gerenciamento
de projetos tais como: o acompanhamento do plano de projeto, o controle da
execuo dos projetos, o registro dos problemas encontrados em campo, o registro
das estimativas e o apontamento do esforo. O trabalho de Reis [Reis2000] faz uma
retrospectiva e anlise dos PSEEs.
Outra abordagem que pode ser utilizada para gerenciamento de projetos o

WFMSs - Workflow Management Systems. O WFMSs so sistemas que foram
originalmente construdos para a indstria manufatureira e para utilizao em

processos de negcio. Desta forma, no consideram a dinamicidade do processo de
software. Os WFMSs tambm trabalham com o conceito da instanciao de um
processo pr-definido, e cada processo de software nico. possvel tomar como
base processos padres de software, mas no instanci-los como feito na
manufatura. Reis [Reis2000] estabelece que existe pouca diferena entre PSEEs e
produtos workflow (fluxo de trabalho), com exceo que produtos de workflow
provem suporte mais direto a processos organizacionais. Ns concordamos com
esta colocao. Flexibilizar e simplificar o PSEEs e WFMSs seria uma tarefa
necessria para a construo de ambientes que pudessem realizar o gerenciamento
dos projetos nas empresas, principalmente no que se refere obteno de mtricas
para introduo de melhorias em curto prazo.
As ferramentas para CSCW-Computer-supported Cooperative Work exploram o

uso do computador para facilitar e garantir o trabalho colaborativo entre as pessoas.
As ferramentas de CSCW podem ser utilizadas tambm com o intuito de gerenciar
projetos. Contudo, uma ferramenta de CSCW frouxa e no permite o
estabelecimento das responsabilidades e interdependncia entre as atividades a
serem realizadas em um plano de projeto de software. Elas impossibilitam um
controle mais efetivo da execuo se desconsiderarmos a confeco de um aplicativo
especfico projetado sobre esta plataforma.
Algumas ferramentas para gerenciamento de projetos podem ser encontradas

no mercado, contudo no so especficas para software. Melo [Melo2000] apresenta
alguma destas ferramentas, descrevendo suas caractersticas, funcionalidades e
seus pontos fortes e fracos. Todavia estas ferramentas, em sua maioria, possibilitam
somente o registro da estrutura da diviso do trabalho do projeto, tornando o
acompanhamento do projeto de software precrio. A confeco dos planos est
desatrelada dos processos da empresa impossibilitando manter a integridade com os
elementos do processo de software. A dinamicidade da execuo de um projeto de
software tambm dificulta o acompanhamento do projeto utilizando estes tipos de
ferramentas, que propem a criao de novas verses do documento original.
Comparar o que foi planejado com o executado uma atividade que somente pode
ser realizada manualmente. Alm disso, a maioria destas ferramentas no permite o
apontamento do esforo durante a execuo das atividades do projeto e o controle de
acesso geralmente precrio, baseado em acesso ao documento e no atividade
do projeto.
O trabalho de Moura [Moura2000] relaciona algumas ferramentas que podem

ser utilizadas para a gesto de projetos de software.
Ferramentas para Apoio Automatizado ao ProGer 67
Nas prximas sees apresentaremos um exemplo de conjunto de ferramentas

que j foi adotada em conjunto com o ProGer, que serve como sugesto para apoiar
o processo definido no captulo 4.
5.1 FERRAMENTAS UTILIZADAS EM CONJUNTO COM O PROGER
5.1.1 Microsoft Word
Editor de textos, utilizado para a elaborao dos seguintes documentos:

proposta tcnica;
proposta comercial;
documentos de requisitos;
status report;
matriz de rastreabilidade;
pauta de reunio;
cronograma de entrega;
plano de iteraes;
plano de gerncia de configurao;
relatrios em geral.
O Word tambm utilizado em alguns outros documentos intermedirios aos

citados acima, como por exemplo documentos de informaes sobre requisitos de
produtos ou servios de software, avaliaes iniciais de prospeces ou propostas,
motivos de cancelamento de propostas etc.
O MS Word pode ser substitudo por um outro editor de texto open source como
o Open Office Writer (http://www.openoffice.org/product/writer.html).
5.1.2 Microsoft Project
Ferramenta proprietria da empresa Microsoft.
Ferramenta utilizada para se determinar cronograma do projeto. Estipula prazos

de entrega de todos os artefatos do projeto, permite alocar prioridades a atividades e
projetos, delimitar a disponibilidade de recursos, definir prazos para atividades, etc.
Utilizado para gerar os seguintes documentos:

cronograma de entrega;
wbs (estrutura analtica do projeto).
O MS Project pode ser substitudo por outra ferramenta open source para
gerenciamento de projetos, como o dotProject (http://www.dotproject.net/).
5.1.3 Microsoft excel
Planilha eletrnica utilizada para elaborao de tabelas e/ou grficos que podem
ser utilizados em conjunto com o MSWord na elaborao dos seguintes documentos:
status report;
matriz de rastreabilidade;
time sheet;
relatrio de controle dos requisitos: implementado, testado;
relatrio de controle de bugs: corrigido, testado, atualizado;
cronograma de entrega.
O MS Excel pode tambm ser substitudo por uma alternativa open source como
o Open Office Calc (http://www.openoffice.org/product/calc.html).
5.1.4 Mantis
O Mantis um issue tracker open source.
Dentre os inmeros usos do Mantis podemos citar o de reportar e gerenciar

mudanas. Utilizada, entre outras, para elaborao dos seguintes documentos:
status report;
documento de requisitos (quando se trata de requisitos adicionais, ou
requisitos que ainda no esto bem definidos pelo cliente);
relatrio de controle de bugs.
Mais informaes a respeito das funcionalidades da ferramenta podem ser

encontradas no seguinte endereo: http://www.mantisbt.org/.
Existem inmeras outras opes de issue trackers que podem ser utilizados no
lugar do Mantis, exemplos: Bugzilla (http://www.bugzilla.org/) e Eventum
(http://dev.mysql.com/downloads/other/eventum/).
5.1.5 FreeVCS
Ferramenta freeware.
Ferramenta de controle de verses de arquivos, importantssima para gerncia

de configurao.
Pode ser utilizada como ferramenta de apoio para praticamente todos os

artefatos e documentos de um projeto.
Mais informaes a respeito das funcionalidades da ferramenta podem ser

encontradas no seguinte endereo: http://www.thensle.de/
Existem opes open source para realizar o controle de verso como o popular
Subversion (http://subversion.tigris.org/).
5.1.6 Microsoft outlook
Ferramenta de envio e recebimento de e-mails, utilizado como ferramenta de

apoio para elaborao e refinamento dos seguintes documentos:
proposta tcnica;
proposta comercial;
Mais informaes a respeito de preos, licenas e funcionalidades da

ferramenta podem ser encontradas no seguinte endereo:
http://www.microsoft.com/outlook/.
Uma alternativa open source o Thunderbird (http://www.mozilla.com/en-

US/thunderbird/).
5.1.7 Microsoft Windows Live Messenger
Ferramenta utilizada para fazer reunies e vdeo conferncias, inclusive.
Essa ferramenta sncrona permite que o gerente tire dvidas com um cliente que
esteja fisicamente longe e a qualquer momento que o mesmo esteja conectado.
Tambm pode ser utilizada como apoio elaborao e refinamento dos seguintes
documentos, entre outros:
proposta tcnica;
proposta comercial;
Mais informaes a respeito de licenas e funcionalidades da ferramenta podem

ser encontradas no seguinte endereo: http://get.live.com/messenger/overview
5.1.8 Base de acompanhamento de projetos
A ferramenta, especfica para gerenciamento de projetos, intitulada Base de

Acompanhamento de Projetos, foi construda tendo como base o ProjectSpace6
[Rouiller2001] e considera as particularidades do ProGer. Esta ferramenta foi
construda na plataforma Lotus-Notes, que um ambiente adequado para trabalho
cooperativo e que envolve muita colaborao humana.
A Figura 5.1 mostra uma viso do cadastramento de projetos. A notificao ao

gerente de processo e qualidade e ao diretor feita automaticamente quando um
novo projeto criado.
Cada projeto inicia-se em uma fase especfica, baseada no modelo de ciclo de

vida de projetos descritos pelo ProGer. Para cada fase so associados os recursos
que sero utilizados e quem ser o responsvel pelo projeto. A Base de
Acompanhamento de Projetos permite a notificao aos executores e a convocao
de reunies. Lembrando que, um projeto pode ser iniciado em qualquer fase, com
exceo do encerramento. A Figura 5.2 apresenta uma viso do cadastramento da
fase do projeto.
O ProjectSpace um framework conceitual que pode ser utilizado para a construo de ferramentas
6
para gerenciamento de projetos de software e foi concebido considerando os padres da engenharia de

processo e do gerenciamento de projetos.
FIGURA 5.1 Viso do cadastramento de projetos
FIGURA 5.2 Viso do cadastramento de fases do projeto

Aps a criao de um projeto em uma determinada fase macro-atividades7 so

criadas pelo lder de projeto. O gerente de projeto notificado da criao de todas as
macro-atividades, assim como os executores. Para uma macro-atividade pode ser
atribudo um ou mais executores. O lder de projeto deve fazer uma previso do
esforo em tempo que ser gasto para a realizao da macro-atividade, alm de
determinar a sua complexidade. A Figura 5.3 mostra uma viso do cadastramento de
uma macro-atividade.
FIGURA 5.3 Viso do cadastramento de macro-atividades
Posteriormente, os executores registram os tempos gastos (apontamento de

horas) nas macro-atividades, relacionando o tipo de atividade realizada. O executor
faz uma estimativa da realizao da macro-atividade, neste momento. Problemas
encontrados em campo so notificados ao lder de projeto, neste momento. A Figura
5.4 mostra uma viso do apontamento de horas nas macro-atividades.
7
As macro-atividades representam os requisitos funcionais e no-funcionais do produto ou servio de
software e possuem uma subclasse de atividade associada.
FIGURA 5.4 Viso do apontamento de horas nas macro-atividades
Informaes gerenciais tambm podem ser obtidas atravs de relatrios

solicitados pela gerncia e diretoria. A Figura 5.5 apresenta uma viso dos projetos
por fase e cliente, apresentando os requisitos dos projetos e as respectivas taxas de
realizao. Uma viso do esforo gasto em horas nos projetos dada pela Figura
5.6.
FIGURA 5.5 Viso de projetos por fase e cliente
FIGURA 5.6 Viso das horas gastas nos projetos
A Figura 5.7 apresenta uma viso mostrando as horas apontadas por executor
em projetos na Base de Acompanhamento de Projetos. A Figura 5.8 mostra a viso
diria do trabalho do executor.
FIGURA 5.7 Uma viso das horas gastas por colaborador
FIGURA 5.8 Viso diria do trabalho do executor

EXERCCIOS DE FIXAO:
1. Voc julga importante a utilizao de ferramentas especficas de gerncia de projetos? Por
que quase toda organizao de software geralmente constri uma ferramenta proprietria
(como a Base de Acompanhamento de Projetos) quando inicia a automatizao do
processo de gerenciamento? Compartilhe sua opinio no frum virtual.
2. Fornea sugestes de outras atividades do ProGer que poderiam ser apoiadas usando
uma ferramenta que voc conhece.
3. Que ferramentas gratuitas ou open source voc conhece para apoiar a gerncia de
projetos de software? Voc j as utilizou? Compartilhe seu conhecimento no frum virtual.
6
CONCLUSO
Este mdulo apresentou conceitos bsicos da gerncia de projetos de software,

enfatizando sua relevncia e dificuldade de implantao nas empresas. Abordamos
tambm, no captulo 2, alguns modelos para a construo de um processo para
gerncia de projetos. Os captulos seguintes apresentaram um exemplo de processo
de gerncia de projetos de software. A seguir realizaremos algumas consideraes.
As dificuldades de se implantar um processo para gerenciamento de projetos

em empresas de software esto, principalmente, na falta de cultura em qualidade que
as organizaes possuem (principalmente as de pequeno e mdio porte). O alto
rodzio de pessoal e o constante deslocamento de recursos humanos para suprir a
demanda de um outro projeto, tambm, dificulta o bom desempenho de um processo
de gerenciamento de projetos de software. Realizar o gerenciamento dos projetos
sem a automao de alguns procedimentos do processo uma tarefa muito rdua, e
porque no dizer, que quase inviabiliza a obteno de dados para a melhoria do
processo. Infelizmente, poucas ferramentas so apropriadas ao gerenciamento de
projetos de software.
Apesar de sua relevncia, temos observado que o gerenciamento de projetos

nas empresas de software ainda realizado geralmente de forma ad-hoc, causando
inmeros prejuzos organizao, inclusive financeiros. Contudo, existe uma forte
tendncia ao surgimento de novos trabalhos nesta rea. Isso pode ser observado
atravs dos processos includos nos padres e normas para SPA/SPI e em estudos e
publicaes realizados nos ltimos anos.
Acreditamos que a comunidade de software deva, em breve, considerar mais as

experincias adquiridas e apresentadas pelo PMI-Project Management Institute. Isso
inclui a realizao de certificao para seus gerentes de projeto, assim como j
ocorre com linguagens e tecnologia, garantindo uma melhor qualidade dos projetos
que executam. Notamos tambm uma tendncia dos adquirentes de produtos e
servios de software em exigirem gerentes de projetos certificados pelo PMI, para
terem mais garantia de que a execuo de seus projetos estar de acordo com a
especificao pretendida nos contratos.
Na construo de um processo para gerncia de projetos, os padres e normas

para SPA/SPI se mostram eficientes, contudo, no so suficientes. O PMBOK
possibilita um melhor entendimento e uma ampliao mais eficaz dos conhecimentos
da rea de gerenciamento de projetos para a rea de software.
Esperamos que este mdulo tenha contribudo para elucidar a relevncia do

gerenciamento de projetos nas empresas de software e tambm possibilitado ao
aluno mecanismos para que este possa se aprofundar no tema.
7
REFERNCIAS BIBLIOGRFICAS
[Bellouquim1999] Belouquim, A. CMM em Pequenas Organizaes: Seria Mesmo

Possvel? Developers Magazine, Janeiro, 1999.
[Boehm1981] Hoehm. B. Software Engineering Economics. Eglewood Cliffs, Prentice-

Hall Inc. 1981.
[Boehm1988] Boehm, B. A Spiral Model for Software Development and

Enhancement, Computer, vol. 21, n. 5, maio 1988.
[Braga1996] Braga, A. Anlise de Pontos por Funo. Rio de Janeiro: Infobook, 1996.
[Campos1992] Campos, V. F. TQC:Controle da Qualidade Total, Fundao Christiano

Otooni, 7a. edio 1992.
[Casati1995] Casati, F and Ceri, S. and Pernici, B and Pozzi, G. Conceptual Modelling
of Workflows. International Conference on Object-Oriented and Entity-Relationalship -
OOEF95, Gold Coast, Austrlia, 1995.
[CMMI:2000] CMMI Model Componentes Derived from CMMI SE/SW, Version 1.0
Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 2000.
[Cromer1999] Cromer, T. & Horch, J. From the many to the one-one companys path
to standardization. IEEE, 1999.
[DOD1994] Defense Science Board, Report of the Defense Science Board Task force
on Acquiring Defense Software Commercially, Wahington D.C., Junho, 1994.
[Dorling1993] Dorling, A. Software Process Improvement and Capability

Determination, Software Quality Journal, vol2, N. 4,1993.
[Fernandes1989] Fernandes, Aguinaldo Aragon & Kugler, J. L. C. Gerncia de

Projetos de Sistemas. Rio de Janeiro, LTC, 1989.
[Garg1996] Garg, P. K. Process-centered Software Engineering Environments.

Published by IEEE Computer Society Press, Los Alamitos, CA 90720-1264, 1996.
[Gates1997] Gates, L. P. How to Use the Software Process Framework. Special

Report CMU/SEI-97-SR-009, 1997.
[Gibbs1994] W. Gibbs. Software's Chronic Crisis. Scientific American Magazine,

setembro, 1994.
[Graham1999] Graham, I. S & Henderson-Sellers, B. & Younessi, H. The OPEN

Process Specification, Addison Wesley Longman Inc. outubro, 1999.
[Humphrey1989] Humphrey, W. S. Managing the Software Process, Addison Wesley

Longman Inc, 1989.
[ISO12207:1995] ISO/IEC 12207, Information Technology Software Life-Cycle

Processes, International Standard Organization, Geneve,1995.
[ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement:

Information Technology Amendement to ISO/IEC 12207, verso PDAM 3, novembro
2000.
[ISO15504:1-9:1998] ISO/IEC TR 15504, Parts 1-9: Information Technology

Software Process Assessment, 1998.
[ISO9000-3:1997] ISO9000-3, Quality management and Quality Assurance Standards

part 3: guidelines for the application of ISO 9001 to the development, supply and
maintenance of software. International Standard Organization, Geneve, 1997.
[Jones1996] Jones, C. Patterns of Software Systems Failure and Success.

International Thomson Computer Press, Boston, Massachusetts, 1996.
Referncias Bibliogrficas 81
[Jones1999] Jones, C. Software Project Management in the 21st Century. American

Programmer, Volume XI, N. 2, fevereiro 1999.
[Kappel1995] Kappel, G. and Rusch-Schott, S. and Retschitzegger, W. Rule Patterns

for Designing Active Object-Oriented Database Applications. Technical Report
TR-07/95, Linz- Austria, 1995.
[Kerzner2001] Kerzner, H. Project Management - A System Approach to

Planning,Scheduling, and Controlling, 7 ed., New York, John Wiley & Sons Inc.,2001.
[Kuvaja1993] Kuvaja, P. et all BOOTSTRAP: Europes assessment method, IEEE

Software, vol 10, N. 3, 1993
[Kuvaja1994] Kuvaja, P. et al. Software Process Assessment & Improvement The

BOOTSTRAP Approach, Blackwell, 1994.
[Laitinen2000] Laitinen, M. & Fayad, M & Ward, R. Software Engineering in the Small.
IEEE Software, setembro/outubro, 2000.
[Lindvall2000] Lindvall, M. & Rus, I. Process Diversity in Software Development, IEEE

Software, julho/agosto 2000.
[Machado1999] Machado, L. F. D. C. Modelo para Definio de Processos de

Software na Estao Taba, dissertao de mestrado, COPPE/UFRJ, 1999, Rio de
Janeiro, RJ.
[Machado2001] Machado, C. A. & Burnett, R. C. Gerncia de Projetos na Engenharia

de Software em Relao as Prticas do PMBOK. XII CITS - Conferncia Internacional
de Tecnologia de Software. Junho, 2001.
[Maidantchik1999] Maidantchik, C. & Rocha, A R. C. & Xexeo, G. B Software

Process Standardization for Distributed Working Groups. In Proceedings of the 4 th
IEEE International Software Engineering Standards Symposioum, Curitiba, Paran,
Brasil, maio de 1999.
[MCT] http://www.mct.gov.br, acessado em dezembro de 2001.

[Melo2000] Melo, E. F. & Moura, H. P. WebManager: uma ferramenta para

planejamento e gerenciamento de projetos de software, trabalho de graduao,
Centro de Informtica, Universidade Federal de Pernambuco, agosto, 2000.
[Paulk1993] Paulk, M. & Curtis, B. & Crissis, M & Weber, C. Capability Maturity Model
for Software, Version 1.1, Technical report CMU/SEI-93-TR-24, Software Engineering
Institute, Pittsburgh, fevereiro, 1993.
[Paulk1997] Paulk, M. C & Weber, C. V & Curtis, B. & Chrissis, M. B. The Capability
Maturity Model: Guidelines for Improving the Software Process. Carnegie Mellon
University, Software Engineering Institute, Addison-Wesley Longman Inc, 1997.
[Philippe1998] Philippe, K. The Rational Unified Process: an Introduction. Addison-

Wesley Object Technology Series, 1998.
[PMBOK2000] A Guide to the Proiject Management Body of Knowledge, PMI-Project

Management Institute, Newtown Square, Pennsylvania, USA, 2000.
[PMIWBS] PMI Project Management Standards Program.

http://www.pmi.org/standards/.
[Pressman1995] R. S. Pressman. Software Engineering: A Practitioner's Approach.

McGraw-Hill, 3 ed., 1995.
[Reis2000] Reis, C. A. L., Ambientes de Desenvolvimento de Software e seus

Mecanismos de Execuo de Processos de Software, Exame de Qualificao de
Doutorado, PPGC-UFRGS, 2000.
[Rouiller2001] Rouiller A. C. Gerenciamento de Projetos de Software para Empresas

de Pequeno Porte. Doutorado em Cincia da Computao pela UFPE. Engenharia de
Software e Qualidade de Software, 2001.
[Royce1998] Royce, W. Software Project Management: a unified framework. Addison

Wesley Longman, 1998, USA.
[Sanches2001] Sanches, R. & Jnior, W. T. Proposta de um Modelo de Processo de

Planejamento de Projeto de Software para Melhoria de Gerenciamento de Projetos.
XII CITS - Conferncia Internacional de Tecnologia de Software, junho, 2001.
Referncias Bibliogrficas 83
[Standish1995] The Standish Group, Chaos,

www.standishgroup.com/visitor/voyahes.html, acessado em dezembro de 2001.
[Trindade2000] Trindade, A. L. P Contructive Cost Model.

http://metricas.tw.eng.br/htmls/cocomo-b-html, acessado em dezembro de 2001.
[Vigder1994] Vigder, M. R. & Kark, A. W. Software Cost Estimation and Control.

National Research Council Canada. Institute for Information Technology, 1994. http://
wwwsel.iit.nrc.ca/abstracts/NRC37116.abs, acessado em dezembro de 2001.
[Walker1997] Walker, E. Managing Successful Iterative Development Projects: A

Seminar on Software Best Practices, version 2.3, Rational Software Corporation,
Menlo Park, California, 1997.
[Wang1999] Wang, Y. & Court, I. & Ross, M. & Staples, G. & King, G. & Dorling, A.
Quantitative Evaluation of the SPICE, CMM, ISO9000 and BOOTSTRAP,
Transactions of IEEE, agosto, 1999.
[Weber1999] Weber, K. C Qualidade e Produtividade em Software. 3 ed. So Paulo:

Makron Books do Brasil Ltda, 1999.
8
APNDICE A
Neste apndice sero apresentados os seguintes artefatos do ProGer:
1. Proposta Comercial
2. Proposta Tcnica
3. Documento de Requisitos
4. Plano de Projeto
5. Relatrio de Aceite
6. Relatrio de Teste
7. Ordem de Servio
8. Funcionalidades
9
APNDICE B
Neste apndice sero apresentados os seguintes encartes, anexos ao mdulo

Gerncia de Projetos de Software:
1. Fluxo de captao de projetos de produtos e servios de software;
2. Fluxo de execuo e avaliao de projetos de produtos e servios de
software.

Apostila Gerencia de Projetos de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Gerencia de Projetos de Software

Enviado por

Direitos autorais:

Formatos disponíveis

CURSO DE PS-GRADUAO

LATO SENSU (ESPECIALIZAO) A

Ana Cristina Rouiller

Universidade Federal de Lavras - UFLA

Rouiller, Ana Cristina

85 p.:il. (Curso de Ps-graduao Lato

1. Sistema de informao. 2. Tecnologia de informao. 3.

Nenhuma parte desta publicao pode ser reproduzida,

A Engenharia de Software tem por finalidade auxiliar na construo de software

Para solucionar alguns destes problemas muitas empresas de software tm

contextuais e organizacionais que potencialmente existem dentro de um processo de

De forma geral, podemos dividir as funes de uma empresa de software em

Estes trs grupos so abordados, respectivamente, pela engenharia do

A engenharia do produto encarregada do desenvolvimento e manuteno

FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de

A engenharia de processo tem como metas a definio e a manuteno dos

O gerenciamento de projeto objetiva assegurar que processos particulares

Este mdulo se concentra nas reas de engenharia de processo e

1.1 PROJETO E A GERNCIA DE PROJETOS

Um projeto pode ser definido como um empreendimento temporrio com o

A meta da gerncia de projetos conseguir exceder as necessidades e

stakeholders com necessidades e expectativas diferenciadas; e

1.2 MOTIVAO E RELEVNCIA DA GERNCIA DE PROJETOS

Um estudo conduzido pelo DoD-Department of Defense [DOD1994] indicou que

O estudo realizado pelo Standish Group [Standish1995], chamado de relatrio

Atravs de uma anlise e acompanhamento de cem projetos de software,

Walker [Walker1997] conclui que: o desenvolvimento de software ainda

Muitas pesquisas enfatizam que o gerenciamento a principal causa do

Os principais padres e normas para SPA/SPI (Software Process Assessment/

Ns acreditamos que a existncia de procedimentos padronizados e de fcil

1.3 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE

J em 1989, Humphrey [Humphrey1989] constatou que: a ausncia de prticas

Os gerentes de projeto de software esto desacostumados a estimar

Boas estimativas de custo, esforo e prazo de software requerem um processo

Estimar, medir e controlar um projeto de software so tarefas difceis, pois o

A dinamicidade do processo de software dificulta tambm o gerenciamento

Outros fatores ainda agravam os problemas de gerenciamento de projetos de

1.4 ESTRUTURA DO MDULO

Os estudos realizados na dcada de 1990 sobre gerenciamento de projetos de

Contudo, Machado [Machado2001] demonstrou recentemente que apesar das

A ISO/IEC15504 quem aborda o gerenciamento de projetos de software de

2.1 PROCESSOS DE GERENCIAMENTO DA ISO/IEC15504

PMBOK se encontra no material complementar do ambiente virtual.

Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization

A ISO/IEC15504 atualmente uma norma que representa um padro

Nove documentos compem a ISO/IEC15504. Alguns tm carter normativo

Nvel Nome dos Atributos

Dimenso de Processo Dimenso de Capacidade

A primeira dimenso auxilia os engenheiros de processo na definio dos

ISO/IEC15504. A segunda dimenso, similar ao CMM, tem por objetivo determinar a

Cinco grupos de processos so definidos pela ISO/IEC15504-2:

A categoria de processo MAN (Management process category) quem

MAN.1 Processo de gerenciamento organiza, monitora e controla o incio e o

MAN.2 Gerenciamento de projetos identifica, estabelece, coordena e monitora

MAN.3 Gerenciamento da qualidade monitora a qualidade dos produtos e

MAN.4 Gerenciamento de riscos identifica e mitiga os riscos dos projetos,

Apesar dos quatros agrupamentos estarem envolvidos no gerenciamento de

MAN.2.BP1 Define o escopo do trabalho, ou seja, o trabalho que deve ser

MAN.2.BP2 Determina a estratgia de desenvolvimento, avaliando as opes

MAN.2.BP3 Seleciona um modelo de ciclo de vida para o projeto que

MAN.2.BP4 Estabelece as tarefas estimando seu tamanho e os recursos

MAN.2.BP5 Estabelece a estrutura de diviso do trabalho, as entregas e a

MAN.2.BP6 Identifica os requisitos da infra-estrutura, ou seja, os elementos

MAN.2.BP7 Estabelece o cronograma do projeto, baseado na estrutura de