gerenciamento de

8/13/2019 Gerenciamento De

1/84

RGIS EDUARDO GRANDCHAMP

GERENCIAMENTO DE

PROJETOS DE SOFTWARE

Taubat SP

2002


2/84


GERENCIAMENTO DE

PROJETOS DE SOFTWARE

Taubat SP

2002

Monografia apresentada para obteno do

Certificado de Especializao pelo Curso de

Ps-graduao em MBA - Gerncia deProduo e Tecnologia do Departamento de

Economia, Contabilidade, Administrao e

Secretariado da Universidade de Taubat.

Orientador: Prof. Dr. Marco Antnio Chamon


3/84

GRANDCHAMP, R. E.Gerenciamento de Projetos de Software. 2002. 82 f.Monografia (Especializao MBA em Gerncia de Produo e Tecnologia)Departamento de Economia, Contabilidade, Administrao e Secretariado,Universidade de Taubat, Taubat, 2002.


4/84


GERENCIAMENTO DE PROJETOS DE SOFTWARE

UNIVERSIDADE DE TAUBAT, TAUBAT, SP

Data: _________________________

Resultado: _____________________

COMISSO JULGADORA

Prof. Dr. Antonio Pascoal DelArco Jnior UNITAU

Assinatura___________________________________

Prof. Dr. Jos Luis Gomes da Silva UNITAU

Assinatura___________________________________

Prof. Dr. Marco Antnio Chamon UNITAU

Assinatura___________________________________


5/84

Dedico este trabalho minha me, Maria Eugnia Grandchamp e em memria

de meu pai, Nilton Grandchamp, os quais sempre me apoiaram e incentivaram

a caminhar cada vez mais longe.


6/84

AGRADECIMENTOS

Agradeo ao Prof. Dr. Marco Antnio Chamon, que me orientou de formaobjetiva e me apoiou at o ltimo instante.

Ao Prof. Dr. Edson Aparecida de Arajo Querido de Oliveira, o qual dirigiu todo

o curso com seriedade e dedicao.

A meus colegas de curso com quem compartilhei conhecimentos e emoes.

A meus amigos que me agentaram falar do curso de MBA durante um ano emeio, sem nunca reclamar.

E enfim a todos que direta ou indiretamente me auxiliaram durante todo este

perodo, que considero como mais alguns metros escalados rumo ao topo.


7/84

GRANDCHAMP, R. E. Gerenciamento de Projetos de Software. 2002. 82 f.Monografia (Especializao MBA em Gerncia de Produo e Tecnologia)Departamento de Economia, Contabilidade, Administrao e Secretariado,Universidade de Taubat, Taubat, 2002.

Esta pesquisa tem por objetivo apresentar ferramentas, tcnicas e mtodos de

gerenciamento de projetos de software. Tais ferramentas, tcnicas e mtodos foram

levantados a partir de uma pesquisa bibliogrfica, feita com material publicado, livros,

artigos em peridicos e materiais disponibilizados na Internet.

A fim de avaliar o quanto as informaes disponveis nas bibliografias

condizem com a realidade do gerenciamento de projetos de softwareexistente no

mercado, foi elaborado um estudo de campo por meio de entrevistas realizadas com

gerentes e desenvolvedores de softwareem trs empresas e um instituto de pesquisa,

todos localizados no Vale do Paraba.

Sabendo das dificuldades encontradas nesta atividade, e tambm da tradio

que os projetos de softwarepossuem de no serem cumpridos conforme o planejado,

espera-se que este estudo fornea subsdios para que tais projetos possam gerar

resultados mais precisos.

Palavras-chave: Gerenciamento, Software, Planejamento.


8/84

GRANDCHAMP, R. E. Management of Software Projects . 2002. 82 p. Monograph(Specialization - MBA in Management of Production and Technology) Department ofEconomy, Accounting, Administration and Secretary, University of Taubat, Taubat,2002.

This research has for objective to present tools, techniques and methods of

software project management. Such tools, techniques and methods have been

gathered from the available bibliography, such as books, scientific papers, and

material available in the Internet.

In order to evaluate if the available information corresponds to the reality of the

management of software projects, an empirical study was elaborated throughinterviews accomplished with managers and software developers in three companies

and one research institute, located in the Vale do Paraba.

Knowing about the difficulties found in this activity, and also of the tradition that

the software projects possess of they be not executed as planned him, it is waited that

this study supplies subsidies so that such projects can generate more precise results.

Key-words: Management, Software, Planning.


9/84

SUMRIO

RESUMO 5

ABSTRACT 6

LISTA DE TABELAS 10

LISTA DE FIGURAS 11

1 INTRODUO 12

1.1 Objetivos 13

1.2 Organizao do Trabalho 13

2 O ESSENCIAL EM ADMINISTRAO DE PROJETOS 15

2.1 Complexidade e Incerteza 16

2.2 Programas e Subprojetos 17

2.3 Ciclo de Vida do Projeto 17

2.4 Definio de Objetivos 19

2.5 Processos da Gerncia de Projetos 21

2.5.1 Planejamento 22

2.5.2 Execuo 24

2.5.3 Controle 25

2.5.4 Encerramento 27

3 GERENCIAMENTO DE PROJETOS DE SOFTWARE 29

3.1 Mtricas de Software 30

3.1.1 Comparao Histrica 31

3.1.2 COCOMO (Constructive Cost Model) 31

3.1.3 Anlise de Pontos de Funo 32

3.1.4 Anlise de Distribuio de Atividades 33

3.1.5 Mtodo Delphi 33

3.1.6 Estimativa de esforo de Integrao e Teste de Sistema 34

3.2 Qualidade de Software 34

3.2.1 Modelo de Processo CMM 35


10/84

3.2.2 Norma NBR 13.596 36

3.3 O Ciclo de Vida do Software 37

3.3.1 Fases do Ciclo de Vida 37

3.3.1.1 Definio de Requisitos de Usurio 38

3.3.1.2 Definio de Requisitos de Software 40

3.3.1.3 Projeto de Arquitetura 40

3.3.1.4 Projeto Detalhado e Produo 40

3.3.1.5 Transferncia 41

3.3.1.6 Operaes e Manuteno 41

3.3.2 Abordagens do Ciclo de Vida 423.3.2.1 Abordagem do Tipo Cascata 42

3.3.2.2 Abordagem do Tipo Incremental 42

3.3.2.3 Abordagem do Tipo Evolucionria 43

4 O GERENTE DE PROJETOS E SUA EQUIPE 45

4.1 O Conhecimento Tcnico 46

4.2 A Escolha da Equipe 47

4.3 Desenvolvimento da Equipe 47

5 O PLANEJAMENTO DO PROJETO DE SOFTWARE 49

5.1 Gerenciamento do Escopo 51

5.1.1 Estrutura Analtica do Projeto 52

5.2 Planejamento de Recursos e Durao 55

5.3 Sequenciamento das Atividades 57

5.3.1 Diagrama de Rede ou Grfico PERT 57

5.3.2 Cronograma de Barras ou Grfico de Gantt 58

5.4 Estimativa de Custos 59

6 GERENCIAMENTO DE RISCO 62

6.1 Fatores de Experincia 62

6.2 Fatores de Planejamento 62


11/84

6.3 Fatores de Tecnologia 63

6.4 Fatores Externos 63

7 O CONTROLE DO PROJETO DE SOFTWARE 65

7.1 Anlise do Valor do Trabalho Realizado 66

7.2 Relatrios de Desempenho 68

8 VERIFICAO E VALIDAO DO SOFTWARE 70

9 ENCERRAMENTO DO PROJETO 72

10 MATERIAIS E MTODOS 73

11 RESULTADOS DA PESQUISA 76

12 ANLISE DOS RESULTADOS 7913 CONCLUSO 81

REFERNCIAS BIBLIOGRFICAS 82


12/84

LISTADE TABELAS

Tabela 1 Matriz de Designao de Responsabilidades 45

Tabela 2 Lista de atividades de um EAP 53

Tabela 3 Clculo da variao do custo 67

Tabela 4 Clculo da variao do prazo 68


13/84

LISTA DE FIGURAS

Figura 1 As fases de um projeto 18

Figura 2 Exemplo genrico de ciclo de vida do projeto 19

Figura 3 Ligaes entre os grupos de processo em cada fase do projeto 21

Figura 4 Sobreposio dos grupos de processo em cada fase do projeto 22

Figura 5 Interao entre as fases do projeto 22

Figura 6 Modelo de ciclo de vida de um projeto de software 39

Figura 7 Abordagem do tipo cascata 42

Figura 8 Abordagem do tipo incremental 43

Figura 9 Abordagem do tipo evolucionria 44

Figura 10 Processo de Planejamento do Projeto de Software 50

Figura 11 Forma esquemtica de um EAP 53

Figura 12 Exemplo de Diagrama de Redes 57

Figura 13 Exemplificao de Caminho Crtico e Folga 58

Figura 14 Exemplo de Cronograma de Gantt 59

Figura 15 Tpica distribuio dos custos durante a execuo de um projeto 61

Figura 16 Curva S dos custos acumulados durante o projeto 61

Figura 17 Grfico da anlise do valor do trabalho realizado (EVA) 69


14/84

1 INTRODUO

H pelo menos duas dcadas so apresentadas palestras, publicados livros e

revistas sobre as dificuldades relacionadas a gerncia no desenvolvimento de

software . Existem pesquisas que indicam que os maiores equvocos so cometidos na

fase inicial de planejamento, no processo de anlise de requisitos e nas estimativas

de custo, enquanto outras sugerem que estes ocorrem na forma como feito o

controle das atividades durante a produo do produto.

Em estatstica divulgada por Selner (1999) d-se conta de que 87% dos

projetos de software analisados sofreram desvios de cronograma, 56% dos projetos

excederam o custo estimado e em 45% dos projetos foi constatado que o resultado

dos produtos de softwareeram inadequados s necessidades de negcio a que sepropunham apoiar.

neste ponto que muitos se sentem atrados a afirmar que software um

problema, pois se pode observar que alguns ciclos de vida de desenvolvimento de

sistemas excedem o prprio ciclo de desenvolvimento do produto que ser controlado

por ele, por exemplo em automveis e aeronaves, onde estes se tornaram elementos

crticos.

Talvez problema no seja a expresso correta a ser usada, mas sem dvida

um grande desafio a ser enfrentado, j que a cada dia o processo de desenvolvimentotende a se otimizar, seja visando a economia de recursos, ou buscando ganho de

competitividade dentro do mercado atual.

O presente trabalho tem como meta apresentar ferramentas e tcnicas que

podem auxiliar em todo o ciclo de vida do desenvolvimento, concentrando-se em

especial na etapa de planejamento, onde sero abordadas entre outros aspectos as

ferramentas utilizadas para mtricas de software,as quais podem minimizar muitas as

discrepncias existentes nas mensuraes do projeto. Outro fator de muita relevncia

neste setor abordado durante a pesquisa a questo dos riscos envolvidos, devido a

ser uma rea muito dinmica e de grande impacto.

Tambm dado enfoque a algumas caractersticas de grande importncia para

o mercado, como a relao entre gerente e equipe e a qualidade do software. Esta

ltima muito cobrada pelos clientes devido ao grande nmero de ocorrncias de

insatisfao.


15/84

Aps a reviso da literatura apresentado um estudo de campo realizado com

gerentes e desenvolvedores com o intuito de traarmos, ainda que parcialmente, o

cenrio existente atualmente nas empresas de grande porte com relao a

desenvolvimento de software, quais ferramentas utilizam, os problemas enfrentados e

como so solucionados.

Ao fim espera-se com este estudo poder contribuir com a rea de

gerenciamento de projetos atravs de uma fonte de consulta que fornecer

informaes e parmetros importantes para todos os envolvidos com a gerncia de

desenvolvimento de software.

1.1 Objetivo

O objetivo desta pesquisa demonstrar as ferramentas e tcnicas que podem

auxiliar o gerenciamento de um projeto de software por executivos que exercem ou

exercero funes relacionadas ao setor, procurando sempre esclarecer e guiar de

forma objetiva e consistente os caminhos para uma atuao bem sucedida.

Tambm tem-se como objetivo do trabalho mapear como os projetos em

questo so gerenciados em empresas de grande porte e centros de pesquisa do Vale

do Paraba.

Dessa forma, pretende-se, por meio de uma pesquisa bibliogrfica, levantar asprincipais ferramentas disponveis para o gerenciamento de projetos, em particular

aquelas que so especficas para a rea de software. Alm disso, com um trabalho de

campo entrevistas com gerentes de projetos e desenvolvedores de sistemas, vai se

buscar uma viso de como essas ferramentas esto disseminadas nas organizaes

do Vale do Paraba que trabalham com projetos de software.

1.2 Organizao do trabalho

O captulo 1 a introduo, onde encontram-se delimitados as idias e

objetivos que se pretende discutir ou alcanar. O captulo 2, o essencial em

administrao de projetos, apresenta as caractersticas e as fases que a maioria dos

projetos possuem.


16/84

No captulo 3, gerenciamento de projetos de software, que o objeto de

pesquisa comea a ser tratado. Este o captulo que possui as informaes mais

importantes quando nos referimos a software pois ele trata de aspectos fundamentais

na concepo e desenvolvimento do produto como, mtricas, qualidade e ciclo de vida

do software.

O captulo 4, o gerente de projetos e sua equipe , trata do aspecto social do

estudo, onde discutido a relao entre gerentes e desenvolvedores e como isto pode

afetar o projeto.

O planejamento do projeto de software o captulo 5. Neste ponto tcnicas

de planejamento j conhecidas so explanadas, porm com enfoque nas

peculiaridades do desenvolvimento de software.

Os riscos do projeto so abordados no captulo 6, gerenciamento de risco. Ocaptulo 7, controle do projeto de software, destina-se apresentao de tcnicas

utilizadas durante a evoluo do desenvolvimento.

Os captulos 8 e 9, verificao e validao do software, e encerramento do

projeto respectivamente, mostram os aspectos necessrios para que o projeto seja

finalizado com sucesso.

O capitulo 10, materiais e mtodos, apresenta as ferramentas utilizadas para

a obteno dos dados existentes nesta pesquisa.

Os captulos 11 e 12, resultados da pesquisa e anlise dos resultados ,apresentam os dados obtidos com o trabalho de campo e anlise feita sobre os

mesmos.

O capitulo final, concluso, reservado para o fechamento do estudo, com as

constataes e comprovaes obtidas durante a pesquisa.


17/84

2 O ESSENCIAL EM ADMINISTRAO DE PROJETOS

Este captulo destina-se a apresentar alguns tpicos essenciais necessrios ao

bom andamento de qualquer projeto, independente de sua natureza ou rea de

aplicao.

De um modo geral, podemos dizer que as organizaes comumente executam

trabalhos que envolvem servios continuados e/ou projetos. Ambas as atividades

possuem caractersticas comuns, ou seja, so executados por pessoas, trabalham

com recursos limitados e so planejados, executados e controlados. Eles diferem,

porm, em alguns aspectos: enquanto os servios continuados so repetitivos, os

projetos so temporrios e nicos. Assim definiu-se que projetos so

empreendimentos finitos, que tm objetivos claramente definidos em funo de umproblema, oportunidade ou interesse de uma pessoa ou organizao, (MAXIMIANO,

1997, p. 20).

Os projetos podem envolver uma nica pessoa ou milhares. Podem exigir

menos do que cem horas de trabalho como um milho delas. So desenvolvidos

dentro ou fora das fronteiras da organizao, pas ou nao. Abaixo alguns exemplos

de projetos:

Desenvolvimento de um novo produto ou servio;

Implementao de uma mudana na estrutura organizacional da empresa; Planejamento de um novo veculo;

Desenvolvimento ou aquisio de um sistema de informao;

Construo de prdios e casas.

Alm das variaes citadas acima a maioria dos projetos possui caractersticas

muito presentes na sua composio:

Relao entre fornecedor e cliente ou usurio, que pode ter encomendado ou

comprado uma soluo ou idia, ou que a avaliar quando for desenvolvida.

A satisfao do cliente ou usurio um dos principais critrios para avaliar o

grau de sucesso do projeto;

Projetos apresentam incertezas. Partem de um problema presente para

desenvolver uma soluo desconhecida no futuro. Quanto maior o grau de

desconhecimento, maior a incerteza e o risco;

Necessitam de administrao por meio de tcnicas especficas, as quais

pode proporcionar maior possibilidade de xito.


18/84

O resultado do projeto o desenvolvimento da soluo ou atendimento do

interesse do cliente, dentro de restries de tempo e outros recursos. Para definir o

grau de sucesso do resultado do projeto, preciso verificar se esses critrios foram

atendidos. No alcanar os objetivos, no realiz -lo dentro do prazo previsto, ou

consumir recursos alm do oramento, significa comprometer dimenses importantes

do desempenho esperado.

2.1 Complexidade e Incerteza

Dois critrios importantes e muito utilizados para dividir os projetos em

categorias nitidamente distintas, so complexidade e incerteza.

A complexidade de uma situao mede -se pelo nmero de variveis

que contm. Quanto maior o nmero de variveis a serem

administradas, mais complexa a situao se torna. Nenhuma

situao totalmente simples ou linear. Certas situaes, porm,

so intrinsecamente mais complexas que outras. (MAXIMIANO,

1997, p. 24).

Alguns dos fatores que aumentam a complexidade na administrao de

projetos so a multidisciplinaridade ou diversidade de profisses e conhecimentos

necessrios para a sua realizao, grande nmero de pessoas envolvidas, disperso

geogrfica, grande volume de informaes a serem processadas.

A incerteza pode ser medida pelo grau de desconhecimento a respeito dos

resultados ou de como alcan-los. Os projetos que provavelmente tm maior grau de

incerteza so os de pesquisa e explorao, onde com freqncia no se sabe como

iro terminar. Menos incertos so os projetos de desenvolvimento de novos produtos,

os quais possuem elevado grau de clareza, porm esto sujeitos interferncia de

inovaes tecnolgicas, que podem alterar as condies de execuo.

Complexidade e incerteza podem se combinar e compor um sistema cartesiano

composto das seguintes possibilidades.

Incerteza menor, complexidade menor: possuem elevado grau de certeza,

pois apresentam poucas variveis. Tendem a tornar-se atividades rotineiras;

Incerteza menor, complexidade maior: possuem resultados claramente

definidos, porm elevado grau de risco;


19/84

Incerteza maior, complexidade menor: geralmente envolvem poucas pessoas

ou um pequeno nmero de campos do conhecimento trabalhando juntas em

atividades cujo resultado incerto;

Incerteza maior, complexidade maior:os grandes projetos multidisciplinares,

que se decompem em projetos menores, representam esta categoria.

2.2 Programas e Subprojetos

Devido ao tamanho de alguns empreendimentos, alguns termos so usados

para definir hierarquias ou subdivises, mas exprimem idias muito parecidas. Entre

eles esto o programa e subprojeto, os quais refletem muito mais essa hierarquia

dos projetos interligados e sua dimenso, do que propriamente conceitos diferentes.

Programa um grupo e projetos gerenciados de uma forma coordenada, a

fim de se obter benefcios que, de uma forma isolada, no se obteria (PMI, 2000, p. 8,

grifo do autor). Um exemplo de programa seria um Programa para um avio XYZ,

onde inclui-se os projetos de desenho e desenvolvimento da aeronave.

Subprojeto. Os projetos so muitas vezes divididos em componentes mais

gerenciveis ou subprojetos. So freqentemente contratados de outra empresa ou

outra unidade funcional dentro da mesma organizao (PMI, 2000, p. 10, grifo do

autor).

2.3 Ciclo de Vida do Projeto

O ciclo de vida do projeto comumente define o trabalho tcnico que deve ser

realizado em cada fase de um projeto e quem deve estar envolvido. A seqncia das

fases do ciclo de vida de um projeto, tais como solicitaes para design, construo ou

especificao para manufatura, geralmente envolve alguma forma de transferncia de

tecnologia.

As fases do ciclo de vida so especficas de cada tipo de projeto e

variam de uma empresa para outra. Na maioria dos casos, porm, o

ciclo de vida dos projetos tem quatro fases principais. Normalmente,

antes que uma fase termine, a prxima fase iniciada. Esse

processo de sobrepor as fases do projeto chamada fast tracking

(compresso do cronograma do projeto pela superposio de


20/84

atividades que normalmente estariam em seqnc ia) (PMI, 2000, p.

12).

Abaixo as quatro fases mais comuns no ciclo de vida dos projetos:

Preparao: tambm chamada de conceituao ou concepo. Nessa fasedefine-se o objetivo e os planos preliminares do projeto;

Estruturao: predominam as atividades de detalhamento dos planos

operacionais e a definio da equipe encarregada do empreendimento;

Desenvolvimento e Implementao: quando os planos so colocados em

prtica e o projeto comea a ser concretizado;

Encerramento:neste ponto o projeto atingiu o resultado previsto.

Esta seqncia abriga, de forma compacta, projetos cujos objetivos so itens

materiais, como softwares e projetos de P & D. As descries do ciclo de vida do

projeto podem variar, ser muito ou pouco detalhadas, utilizar-se de ferramentas como

formulrios, diagramas e listas de verificao. Estas abordagens detalhadas so

freqentemente chamadas de metodologia de gerncia de projeto.

As fases descritas no so imveis nem totalmente seqenciais, elas se

sobrepem, porm nota-se a predominncia de cada uma delas, de acordo com o

andamento das atividades. A Figura 1 exemplifica a afirmao expressa acima.

Fonte: VALERIANO, 1998, p. 24

Figura 1 As fases de um projeto

A maioria das descries do ciclo de vida de projeto apresenta algumas

caractersticas em comum:


21/84

O custo e a quantidade de pessoas envolvidas so baixos no incio, crescem

no decorrer e se reduzem prximo ao trmino, como ilustrado na Figura 2;

No incio do projeto o risco e as incertezas so altas e estas tendem a

diminuir medida que o projeto caminha para o trmino;

A capacidade das partes envolvidas de influenciar as caractersticas e custo

do projeto final vai se reduzindo com o tempo, principalmente porque o custo

de mudanas e correo de erros geralmente aumenta medida que o

projeto se desenvolve.

Fonte: PMI, 2000, p. 12

Figura 2 Exemplo genrico de ciclo de vida

Mesmo que muitos ciclos de vida de projeto apresentem nomes de fases

similares com resultados de trabalho similares, poucos so idnticos.

2.4 Definio de Objetivos

O objetivo o ponto fundamental do projeto, para onde o esforo e as aes

devem ser dirigidas. Somente depois dele ser definido de forma clara e inequvoca

que se deve pensar no planejamento, nas fases e no ciclo de vida do projeto.

Objetivos so resultados esperados de alguma ao ou deciso.

Podem receber diferentes designaes: metas, misses, finalidades,

propsitos. No h conveno que estabelea designaes

especficas. Objetivo o termo genrico para todas as idias que

indicam alguma espcie de resultado que se espera alcanar

(MAXIMIANO, 1997, p. 42).


22/84


23/84

importante ressaltar que o objetivo do projeto aquilo que vai ser aceito pelo

cliente, portanto imprescindvel evitar deslizes, tal como indicar aquilo que

aparentemente possa ser o objetivo, quando na verdade trata-se do meio para atingi-

lo.

2.5 Processos da Gerncia de Projetos

A gerncia de projetos possui uma caracterstica muito intensa de interao,

onde uma ao numa rea geralmente afeta as outras. Por exemplo, uma mudana de

escopo quase sempre altera o custo e talvez o cronograma do projeto. A gerncia de

projetos tem a funo de administrar de forma efetiva essas interaes e esta tarefa

feita atravs de processos. Um processo uma srie de aes que geram um

resultado (PMI, 2000, p. 27), e estes podem ser divididos em quatro grupos:

planejamento, execuo, controle e encerramento.

Os grupos de processos se relacionam pelos resultados que produzem, ou seja

o resultado ou sada de um torna-se entrada para outro. Por exemplo, o planejamento

alimenta a execuo, no incio e a cada atualizao, com um plano do projeto

documentado. Estas conexes so mostradas na Figura 3.

Fonte: PMI, 2000, p. 28

Figura 3 Ligaes entre os grupos de processo em cada fase do projeto

Alm disso, assim como acontece com as fases do projeto, os grupos de

processos so contnuos. Eles so formados por atividades que se sobrepem,

ocorrendo em intensidades variveis ao longo de cada fase do projeto. A Figura 4

ilustra a sobreposio e variao dos grupos de processos dentro de uma fase.


24/84

Finalmente, as interaes dos grupos tambm extrapolam as fases. Por

exemplo, aps a finalizao e aceitao da fase de design, gerado um documento

que define a descrio do produto para a fase de implementao seguinte. Este

relacionamento entre os grupos de processo e as fases exemplificado na Figura 5.

Fonte: PMI, 2000, p. 29

Figura 4 Sobreposio dos grupos de processo em cada fase do projeto

Fonte: PMI, 2000, p. 29

Figura 5 Interao entre as fases do projeto

2.5.1 Planejamento

Conforme afirma Valeriano (1998, p. 176), o futuro inevitvel [...]

necessrio que estejamos preparados para receb-lo. E o planejamento o processo

que visa ao estabelecimento, com antecedncia, das decises e das aes a serem

executadas em um dado futuro, para atingir um objetivo definido, em um certo prazo.


25/84

Planejar tomar decises que permitem iniciar o projeto e conduzir

suas fases de maneira segura, esclarecendo as incertezas a serem

enfrentadas. O processo de planejamento deve fornecer informaes

detalhadas para o andamento de uma fase do projeto, bem como

informaes preliminares sobre as fases seguintes. Quanto maisuma nova fase se aproximar, mais detalhes devero ser includos. O

grau de detalhes no processo de planejamento diretamente

proporcional aproximao de uma nova fase. O detalhamento

progressivo dos planos, medida que novas fases se aproximam,

chama-se rolling wave planning (planejamento por ondas

sucessivas) (PMI, 2000, p. 29).

O planejamento fundamental para um projeto, pois ser necessrio executar

algo que no tinha sido feito antes. Apesar disso, alguns dos processos doplanejamento tm dependncias bem definidas e por isso so executados na mesma

seqncia, na maioria dos projetos. Estes processos podem ser chamados de

processos essenciais de planejamento, e incluem:

Planejamento do Escopo:desenvolvimento de declarao escrita do escopo,

com base para futuras decises no projeto;

Detalhamento do Escopo: subdiviso dos principais subprodutos do projeto

em componentes menores;

Definio das Atividades:identificao das atividades especficas que devem

ser realizadas para produzir os diversos subprodutos do projeto; Sequenciamento das Atividades: identificao e documentao das

dependncias entre as atividades;

Estimativa da Durao das Atividades:estimao do nmero de perodos de

trabalhos (prazos) que sero necessrios para completar as atividades

individuais;

Desenvolvimento do Cronograma: criao do cronograma do projeto a partir

da anlise da seqncia das atividades, suas duraes, e as necessidades

de recursos;

Planejamento dos Recursos: determinao dos recursos (pessoas,

equipamentos, materiais) que devem ser utilizados, e em que quantidades,

para a realizao das atividades do projeto;

Estimativa dos Custos:alocao da estimativa dos custos globais aos itens

de trabalho individuais;


26/84

Desenvolvimento do Plano do Projeto: agregao dos resultados dos outros

processos de planejamento, construindo um documento coerente e

consistente.

Em projetos de pequeno porte o planejamento pode ser feito por quem recebeu

a incumbncia de elaborar a proposta ou pelo gerente j designado. Em casos de

grande envolvimento, especialmente naqueles projetos multidepartamentais, os quais

envolvem grande complexidade tcnica e administrativa, ou nos projetos de alto

risco,o gerente dever ser assistido por uma equipe de planejamento. O trabalho em

equipe traz para o planejamento o conhecimento dos especialistas, imprescindvel

obteno das melhores solues, de maior consistncia nas decises, e, fator

importante, inicia um indispensvel comprometimento dos futuros participantes

(VALERIANO, 1998, p. 182).

2.5.2 Execuo

A essncia da execuo a realizao dos planos para atingir o resultado

esperado. Da mesma forma que todos os outros processos administrativos, a

execuo do projeto no um momento especfico, limitado no tempo. A execuo

um processo administrativo, que se aplica a todas as fases do projeto. No entanto, a

execuo o processo predominante na fase de desenvolvimento e implementao.A execuo eficaz o prolongamento natural de um projeto bem planejado. Executar

significa tomar decises e coloc-las em prtica (MAXIMIANO, 1997, p.38).

Em todas as fases do projeto, o processo de execuo est presente.

medida que os planos so realizados, as fases se completam, criando a necessidade

de detalhar os planos para a execuo da fase seguinte. Conforme o PMI (2000, p. 32)

entre os processos de execuo esto:

Execuo do Plano do Projeto: levar a cabo o plano do projeto atravs da

realizao das atividades nele includas;

Verificao do Escopo: aceitar formalmente os resultados (escopo) do

projeto;

Garantia da Qualidade:avaliar regularmente o desempenho geral do projeto,

com o objetivo de prover confiana de que o projeto ir satisfazer os padres

estabelecidos de qualidade;

Desenvolvimento da Equipe: desenvolver habilidades das pessoas e da

equipe, enquanto grupo, para melhorar o desempenho do projeto;


27/84

Distribuio das Informaes: disponibilizar as informaes necessrias, e

no momento adequado, s partes envolvidas;

Pedido de propostas:obter, conforme apropriado a cada caso, as propostas

de fornecimento dos produtos e/ou servios pretendidos;

Seleo de Fornecedores:escolher entre os possveis fornecedores;

Administrao de Contratos: gerenciar os relacionamentos com os

fornecedores.

A execuo de qualquer projeto ou fase envolve atividade fsica ou intelectual

para atingir o resultado esperado. Os padres de realizao da atividade variam muito

de caso para caso. Como sempre, tudo depende do tipo de projeto, de seus objetivos,

do ciclo de vida, da competncia da equipe, da disponibilidade de recursos, entre

outros fatores. s vezes, o planejamento e a execuo ficam muito distantes entre si eoutras vezes atua-se de forma paralela.

2.5.3 Controle

Uma vez decidido para onde ir (como, quando etc.), deve-se procurar seguir o

roteiro traado, sendo necessrio, portanto, cumprir o ritual do controle em todas as

suas etapas. Conforme Maximiano (1997), controlar consiste em acompanhar a

execuo de alguma ao e compar-la com a inteno ou ao planejada. Controlar uma forma de assegurar a realizao de objetivos ou a preservao de um padro

de desempenho.

O desempenho do projeto deve ser medido regularmente para identificar as

variaes do plano. Estes desvios so analisados dentro dos processos de controle.

Na medida em que so identificados desvios significativos, realizam-se ajustes ao

plano atravs da repetio dos processos de planejamento que sejam adequados

quele caso. Controlar tambm inclui tomar aes corretivas, antecipando-se aos

problemas. Abaixo seguem os grupos de processo de controle conforme PMI (2000,

p.33):

Controle Geral de Mudanas: coordenar as mudanas atravs de todo o

projeto;

Controle de Mudanas do Escopo: controlar as mudanas no escopo do

projeto;

Controle do Cronograma:controlar as mudanas no cronograma do projeto;

Controle de Custos:controlar as mudanas no oramento do projeto;


28/84


29/84

2.5.4 Encerramento

O encerramento de um projeto vai alm da entrega ou demonstrao de um

resultado. Todos os produtos definidos dentro do escopo devem ser apresentados e

avaliados positivamente para que o projeto possa ser considerado bem-sucedido. O

prazo, estipulado em um regulamento ou contrato deve ter sito respeitado, ou as

prorrogaes devem ter sido autorizadas ou previstas.

Assim como em planejamento, execuo e controle, o PMI (2000, p. 34) define

dois processos de encerramento:

Encerramento Administrativo: gerar, reunir e disseminar informaes para

formalizar o trmino da fase ou projeto;

Encerramento dos Contratos: completar e liquidar o contrato, incluindo a

resoluo de qualquer item pendente.

O encerramento de um projeto tambm a oportunidade para

determinar o grau de sucesso ou insucesso e refletir sobre esses

dois conceitos. A definio operacional de sucesso a satisfao do

cliente com o resultado. Se o cliente mostrar-se satisfeito, o projeto

ser considerado sucesso. Assim, o conceito de sucesso subjetivo.

Depende de o cliente julgar positivamente o resultado de acordo com

algum dimenso, critrio ou indicador de desempenho (MAXIMIANO,

1997, p. 88).

Alguns indicadores importantes de desempenho e sucesso so os seguintes:

Inovao Tecnolgica: refere-se capacidade de um projeto de pesquisa e

desenvolvimento produzir resultados comercializveis;

Qualidade Tcnica: refere-se ao grau em que os padres tcnicos

especificados foram atingidos, de acordo com o melhor conhecimento tcnico

disponvel;

Custos e Prazos: atendimento das estimativas de tempo e recursos

financeiro feitas no incio do projeto;Avano do Conhecimento: contribuio do projeto para o estado-da-arte em

sua rea de conhecimento.

O encerramento de um projeto , na quase totalidade dos casos, o incio de

outro ou, pelo menos, de uma nova fase. A perspectiva de outro empreendimento

reinicia todos os processos administrativos. No apenas o encerramento consome


30/84


31/84

3 GERENCIAMENTO DE PROJETOS DE SOFTWARE

Os projetos de software acumularam, ao longo do tempo, a reputao de

sempre atrasarem, extrapolarem o uso dos recursos e excederem o oramento, entre

outros contratempos. Pois bem, subestimar o tamanho do software um dos grandes

motivos pelo qual esses problemas muitas vezes se tornam realidade e porque to

difcil o seu gerenciamento. Os modelos de custo dos sistemas de informtica, como

em qualquer outro sistema, geram uma baixa estimativa de custo/prazo/uso de

recursos se as estimativas de tamanho forem baixas.

Em discusses sobre meios para se conseguir fazer com que este problema

seja minimizado, a concluso sempre a mesma, no existe uma frmula precisa para

resolver este problema. necessrio entender sua origem do problema para assim

conseguir super-lo.Boehm (1981) prope trs razes para este problema, que permanecem

coerentes at a atualidade:

1. As pessoas so geralmente muito otimistas todos gostariam que o

software fosse pequeno e fcil. Estimativas altas ocasionam situaes de

confronto, as quais as pessoas geralmente preferem escapar.

2. As pessoas tendem a ter feedback incompleto de experincias anteriores,

possuem fortes lembranas das funes primrias desenvolvidas, o que

corresponde a cerca de 2 a 3 % do desenvolvimento.

3. As pessoas, geralmente, no conhecem todo o trabalho do software. Este

fator tende a interagir com uma lembrana incompleta que produz

estimativa distorcida do produto a ser desenvolvido.

Em resumo, no existe um caminho perfeito para dimensionar o tamanho do

software. No h substituto para o total entendimento do trabalho a ser feito.

Entretanto, o conhecimento das tendncias bsicas do subdimensionamento pode

revelar-se til. De qualquer forma, a melhor estratgia ainda gerenciar

cuidadosamente cada etapa do projeto.Para o caso do desenvolvimento de software, algumas tcnicas especficas de

controle conhecidas sob o nome de mtricas foram aperfeioadas ao longo do

tempo, permitindo um melhor acompanhamento das atividades do projeto.


32/84


33/84

Um acompanhamento mais eficiente do desenvolvimento do projeto.

Existem no mercado de desenvolvimento de software vrios mtodos para

estimativa, alguns amplamente utilizados e outros pouco conhecidos. Dentre os mais

conhecidos e adequados utilizao encontram-se:

Comparao histrica;

COCOMO;

Anlise de Pontos de Funo;

Anlise de Distribuio de Atividades;

Mtodo Delphi;

Estimativa de esforo de Integrao e Teste de Sistema.

Alguns destes mtodos utilizam-se de frmulas empricas, como o caso daAnlise de Pontos de Funo, e portanto til distinguir dois tipos de estimativa: um

primrio ou estimativa atravs de anlise de tarefas, e um secundrio ou estimativa

atravs de frmulas. recomendado que o segundo seja usado somente para validar

e fornecer uma perspectiva a partir do mtodo primrio.

3.1.1 Comparao Histrica

A comparao histrica um mtodo de estimativa de custo que simplesmentecompara o projeto corrente com projetos anteriores. Este mtodo tem timos

resultados quando:

Os custos dos projetos anteriores foram corretamente armazenados;

Os projetos anteriores so similares ao projeto corrente.

Este mtodo tambm pode ser muito til em organizaes que desenvolvem

uma srie de sistemas similares, especialmente quando os clculos de esforo gasto

so guardados para cada pacote de trabalho. Contudo, possveis desvantagens so:

Novos mtodos e ferramentas no podem ser contabilizados nas estimativas;

Prticas de trabalho ineficiente so institucionalizadas, resultando em

desperdcio.

3.1.2 COCOMO (Constructive Cost Model)

O Modelo de Custo Construtivo (COCOMO) uma frmula baseada no mtodo


34/84

de estimativa do custo total do desenvolvimento do software. O dado fundamental para

o COCOMO a estimativa do nmero de linhas de cdigo. Esta tambm a

fragilidade do mtodo, porque:

O nmero de linhas de cdigo somente conhecido ao fim da fase de

modelagem da arquitetura do projeto, o que pode ser muito tarde;

O que constitui uma linha de cdigo pode variar em funo das linguagens

de programao e convenes;

O conceito de linhas de cdigo no se aplica a algumas tcnicas modernas

de programao, chamadas de linguagem visual.

COCOMO oferece um mtodo bsico, intermedirio e detalhado. O mtodo

bsico usa simples frmulas para derivar o nmero total do esforo homem-ms, e o

total de tempo decorrido do projeto, para a estimativa do nmero de linhas de cdigo.O mtodo intermedirio refina o mtodo bsico, multiplicando o resultado

obtido por um fator de ajuste derivado de quinze multiplicadores. Isto pode resultar em

escolhas inadequadas de multiplicadores, porm o COCOMO estabelece critrios para

ajudar na escolha destes. O mtodo detalhado separa um conjunto de multiplicadores

para cada fase.

O mtodo mais indicado para se utilizar intermedirio, pois o detalhado no

agrega valor suficiente se levarmos em conta o esforo utilizado para aplic-lo. O

mtodo bsico fornece um nvel de certeza adequado para as estimativas

preliminares.

3.1.3 Anlise de Pontos de Funo

A Anlise de Pontos de Funo (FPA) estima o custo do projeto atravs das

estimativas de funcionalidades do software. FPA pode conseqentemente ser aplicada

ao final da fase de definio de requisitos.

A unio do FPA estimativa de custo baseada na contagem do nmero de

entradas e sadas do sistema e locais de armazenamento de dados. Estas contagens

ganham um peso, so combinadas e ento multiplicadas pelos direcionadores de

custo, resultando em um valor que representa o nmero de Pontos de Funo.

Este mtodo mais facilmente aplicvel aos sistemas modernos, pois

independe da linguagem de programao e de multiplicadores para produzir uma

estimativa de esforo.


35/84

3.1.4 Anlise de Distribuio de Atividades

A Anlise de Distribuio de Atividades usa as medidas de proporo de

esforo gasto em atividades de projetos anteriores para ento:

Derivar o esforo requerido para cada atividade;

Verificar se a proporo do esforo gasto em cada atividade realstica;

Verificar se o esforo requerido para as atividades futuras proporcional ao

esforo gasto nas atividades j completas.

O mtodo de distribuio de atividades requer dados completos sobre projetos,

os quais sero analisados e reduzidos para derivar a valores de esforo relativo. Como

em todos os mtodos baseados em dados histricos, a estimativa precisa ser

ajustada, a fim de considerar fatores como experincia da equipe, riscos do projeto,novos mtodos e tecnologias e prticas de trabalho mais eficientes.

3.1.5 Mtodo Delphi

O Mtodo Delphi um conveniente caminho para se chegar s estimativas de

custo do software. A suposio do mtodo Delphi de que peritos iro,

independentemente, convergir para uma boa estimativa.

Este mtodo requer vrios peritos em estimativa de custo e um coordenadorpara dirigir o processo. Os passos bsicos so:

1. O coordenador entrega a cada perito uma especificao e um formulrio

onde as estimativas so escritas;

2. Os peritos preenchem os formulrios anonimamente, expondo suas

estimativas (eles podem questionar o coordenador, mas no devem discutir

o problema com os outros envolvidos);

3. Se um consenso no for atingido, o coordenador prepara um resumo de

todas as estimativas e as distribui aos peritos e o processo reinicia do

passo 1.

O resumo deve somente conter os resultados, e no a razo por trs dos

mesmos. Uma pequena variao j aguardada, ento feita uma reunio de reviso

para a discusso das estimativas independentes e para chegar a um resultado

comum.


36/84

3.1.6 Estimativa de esforo de Integrao e Teste de Sistema

O esforo de Integrao e Teste de Sistema depende substancialmente de:

Nmero e criticidade de defeitos em softwaredepois da unidade de teste;

Nmero e criticidade de defeitos aceitveis depois da entrega;

Durao da integrao e testes do sistema;

Tempo mdio para o reparo do defeito.

O esforo requerido para a integrao e teste do sistema pode contudo ser

estimado a partir de um modelo de processo de integrao e teste, supondo o nmero

de defeitos presentes depois de cada unidade de teste. Um tpico modelo de processo

de integrao e teste de sistema contm o seguinte ciclo:

1. A equipe de teste e integrao adiciona componente, descobre defeitos, osreporta para a equipe de modificao de software;

2. A equipe de modificao de softwarerepara os defeitos;

3. A equipe de teste e integrao executa novamente os testes no sistema.

Os valores de esforo de reparo iro variar muito, mas um tpico valor de

meio homem-dia por defeito de cdigo (ESA, 1994).

3.2 Qualidade de Software

Qualidade de software uma preocupao real e esforos tm sido realizados

na busca pela qualidade dos processos envolvidos em seu desenvolvimento e

manuteno. A mesma preocupao existe com o produto de softwaredesenvolvido

onde testes, normas e mtodos so utilizados para verificar sua qualidade.

No entanto, o sistema continua com sua qualidade comprometida, pois as duas

abordagens processo e produto no so integradas. Um processo de qualidade

no garante um produto de qualidade. Percebe-se neste ponto, uma lacuna nos

esforos que vm sendo realizados na busca pela qualidade. O processo, que ir

resultar no produto, concentra seus esforos na busca pela qualidade do modo de

produo e manuteno, enquanto a qualidade do produto focada no produto final,

atravs da constatao de sua qualidade por avaliaes no softwarej acabado.

A qualidade precisa fazer parte, de maneira mais intensa e formal, das

preocupaes do processo de desenvolvimento e manuteno. As caractersticas de

qualidade de um produto de software precisam ser alocadas e verificadas nos


37/84


38/84

possibilidade de atingir metas de custo, cronograma, eficincia e qualidade do produto

final.

3.2.2 Norma NBR 13.596

A Norma NBR 13.596 Tecnologia da Informao Avaliao de produto de

software : caractersticas de qualidade e diretrizes para o seu uso, que foi editada pela

ABNT em 1998, a verso brasileira da Norma ISSO/IEC 9.126 Information

Technology Software product evaluation: quality characteristics and guidelines for

their use, de 1991.

Esta norma estabelece seis caractersticas de qualidade que um produto de

software deve ter; alm de definir um modelo de qualidade de produto e apresentar os

momentos onde a Norma pode ser aplicada. Sua utilizao no obrigatria, o

importante, segundo a prpria Norma, perceber a necessidade de se seguir um

modelo numa avaliao.

As seis caractersticas e as sub-caractersticas definidas, so as seguintes:

1. Funcionalidade: adequao, acurcia, interoperabilidade, conformidade e

segurana de acesso;

2. Confiabilidade : maturidade, tolerncia a falhas e recuperabilidade;

3. Usabilidade : inteligibilidade, apreensibilidade e operacionalidade;

4. Eficincia: comportamento em relao ao tempo e comportamento emrelao aos recursos;

5. Manutenibilidade: analisabilidade, modificabilidade, estabilidade e

testabilidade;

6. Portabilidade: adaptabilidade, capacidade para ser instalado,

conformidade e capacidade para substituio.

Esta Norma pode ser aplicada nos seguintes momentos: na definio dos

requisitos de qualidade de um produto; na avaliao da especificao de softwarepara

verificar se ele ir satisfazer a todos os requisitos de qualidade durante o

desenvolvimento; na descrio de particularidades e atributos do software

implementado como, por exemplo, em manuais de usurio; na avaliao do software

desenvolvido, antes da entrega; e na avaliao do software desenvolvido antes da

aceitao, conforme citado por SantAna e Guerra (2002).


39/84

3.3 O Ciclo de Vida do Software

O ciclo de vida do software pode variar muito entre as empresas,

principalmente se levarmos em considerao o tamanho da organizao. Pequenas

organizaes tendem a ser relativamente informais, os projetos se iniciam de uma

discusso entre o cliente e o gerente do projeto e prosseguem atravs da anlise,

modelagem e implementao sem muitos problemas.

Em grandes organizaes, porm, as coisas so feitas com base muito mais

formal. As vrias comunicaes entre usurios, gerentes, e a equipe de

desenvolvimento so documentadas e cada uma das partes compreende que o projeto

passar por vrias fases antes de ser completado.

Yourdon (1988) cita que quando trabalhava como consultor, visitou

organizaes dos mais variados tamanhos e constatou que muitas vezes existiamgrandes diferenas entre as definies dos ciclos de vida de software dentro da

mesma empresa.

Ultimamente, entretanto, o caminho tomado para o desenvolvimento dos

sistemas tem mudado. Cada vez mais pequenas e grandes organizaes esto

adotando um nico e uniforme ciclo de vida para o projeto. Mas, qual o objetivo de se

ter um ciclo de vida para o projeto? Existem trs objetivos principais:

1. Definir as atividades que sero conduzidas no projeto;

2. Introduzir consistncias entre os vrios projetos da mesma organizao;

3. E fornecer marcos para o controle do gerenciamento e tomada de decises.

importante lembrar que o ciclo de vida no aliviar as dificuldades

das tomadas de decises, a ponderao das alternativas, as

batalhas polticas, as negociaes com os usurios, o apoio moral

necessrio equipe, ou qualquer outra dificuldade de um gerente de

projeto. A nica ajuda que o ciclo de vida do softwarepode fornecer

que ele ir organizar suas atividades, tornando-as mais plausveis,

facilitando o encontro do problema correto na hora certa.

(YOURDON, 1988, p. 45).

3.3.1 Fases do Ciclo de Vida

O ciclo de vida do softwarese inicia quando o produto concebido e termina

quando este j no est disponvel para uso, ele compreende as atividades de

desenvolvimento, operao e manuteno.


40/84

Todos os projetos de software devem ter um ciclo de vida que inclui fases

bsicas citadas abaixo e ilustradas na Figura 6.

Definio de requisitos de usurio;

Definio de requisitos do software;

Definio do projeto de arquitetura do software;

Projeto detalhado e produo do cdigo;

Transferncia da aplicao para operao;

Operaes e manuteno.

O final de cada fase termina com uma reviso, isto deve ocorrer independente

do tamanho do software, sua aplicao ou linguagem de programao. Na Figura 6 as

linhas pretas em negrito marcam as fronteiras do ciclo. Este comea com a entrega do

Documento de Requisitos do Usurio para o desenvolvedor revisar. Aps a aprovaodo documento, trs fases de desenvolvimento transcorrero at que o produto seja

transferido para a operao dos usurios. A entrega de cada fase deve ser revisada e

aprovada antes de prosseguir para a prxima. Depois de um perodo de operaes, o

sistema retirado. Este evento marca o fim do ciclo de vida do software.

Existem seis marcos de progresso durante o ciclo de vida. Eles so mostrados na

Figura 6 como tringulos preenchidos. Tais marcos selecionados so o mnimo

necessrio para uma relao contratual executvel, porm ao longo do projeto novos

marcos devem ser adicionados para medir o progresso das atividades.

3.3.1.1 Definio de Requisitos de Usurio

a fase de definio do problema do projeto. O escopo do sistema deve ser

definido. Os requisitos de usurio devem ser capturados, pode ser atravs de

entrevista ou avaliao, ou construindo prottipos. Especificamente os requisitos de

usurio devem ser identificados e documentados, gerando assim um Documento de

Requisitos de Usurio.

O envolvimento dos desenvolvedores nesta fase varia de acordo com a

familiaridade dos usurios com o software. Alguns usurios podem produzir estes

requisitos com alta qualidade, enquanto outros necessitam da ajuda dos

desenvolvedores.


41/84

Fonte: ESA, 1994, p. 1-3

Figura 6 Modelo de Ciclo de Vida de um projeto de Software


42/84

3.3.1.2 Definio de Requisitos de Software

Esta a fase de anlise do projeto do software.Uma parte vital da anlise de

atividade a construo de um modelo descrevendo o que o sistema far e como. O

principal produto desta fase o Documento de Requerimentos do Software. Este

documento deve ser revisado formalmente pelos usurios, pelos engenheiros de

software e hardware, e pelos gerentes envolvidos.

Durante esta fase um esboo do Plano de Gerenciamento do Projeto de

Softwaredeve ser feito, contendo uma estimativa do custo total do projeto e esforo

necessrio.

3.3.1.3 Projeto de Arquitetura

O objetivo desta fase definir a estrutura do software. O modelo construdo na

fase de requisitos de software o ponto inicial. Este modelo transformado no projeto

de arquitetura, alocando funes e componentes do sistema e definindo o controle e o

fluxo de dados entre eles.

Esta fase deve promover vrias iteraes de projeto. Dificuldades tcnicas ou

partes crticas do projeto tm de ser identificadas.

O produto desta fase o Documento do Projeto de Arquitetura. Este

documento deve ser revisado formalmente pelos usurios, pelos engenheiros desoftware e hardware, e pelos gerentes envolvidos.

Durante esta fase o restante do Plano de Gerenciamento do Projeto de

Softwaredeve ser produzido.

3.3.1.4 Projeto Detalhado e Produo

O objetivo desta fase de detalhar o projeto, codificar, documentar e testar o

software.

Durante esta fase, a integrao e os testes de sistema so feitos de acordo

com os planos estabelecidos na fase de requisitos de software e o projeto de

arquitetura. medida que os testes iro acontecendo tambm necessrio verificar a

qualidade do produto.

Trs so os produtos desta fase: a codificao do software, o Documento

Detalhado do Projeto e Manual do Usurio. Eles devem ser revisados pelos


43/84

engenheiros de softwaree pelos gerentes envolvidos. Ao fim do processo de reviso,

o sistema pode ser declarado pronto para o teste de aceitao.

3.3.1.5 Transferncia

A finalidade desta fase estabelecer se o sistema cumpriu com os itens

existentes no Documento de Requisitos de Usurio. Isto feito instalando-se o

softwaree conduzindo testes de aceitao.

Quando o sistema demonstrar prover as capacidades requeridas, o software

pode ser provisoriamente aceito e as operaes iniciadas.

O Documento de Transferncia de Softwaredeve ser produzido durante esta

fase para documentar a transferncia do produto para a equipe de operaes.

3.3.1.6 Operaes e Manuteno

Uma vez que o software entrou em operao, ele deve ser cuidadosamente

monitorado para confirmar se todos os pr-requisitos realmente existem. Quando o

sistema tiver passado por todos os testes de aceitao, ento pode finalmente ser

aceito.

O Documento Histrico do Projetodeve resumir as informaes gerenciais

significantes e que foram acumuladas ao longo do desenvolvimento. Este documento

deve ser editado depois da aceitao final. E deve ser reeditado ao fim do ciclo de

vida, quando ser acrescentada ainda a informao da fase de operao e

manuteno.

Aps a aceitao final, o softwarepode ser modificado para corrigir erros no

detectados nas fases anteriores, ou porque novos requisitos surgiram. A isto se d o

nome de manuteno.

Durante todo o perodo de operao, necessria particular atenoquanto a atualizao da documentao. Informaes como falhas e

erros devem ser guardadas a fim de fornecer dados que possam

estabelecer mtricas de qualidade para os projetos subseqentes

(ESA, 1991, p. 1-7).

3.3.2 Abordagens do Ciclo de Vida


44/84

O modelo de ciclo de vida do softwaremostrado na Figura 6 resume as fases e

atividades que devem existir em qualquer projeto do gnero. A abordagem do ciclo de

vida, baseada nesse modelo, deve ser definida em cada projeto, dentro do Plano de

Gerenciamento do Projeto de Software. Esta seo expe trs das mais usuais e

conhecidas abordagens: Cascata, Incremental e Evolucionria.

3.3.2.1 Abordagem do Tipo Cascata

Este tipo de abordagem est ilustrado na Figura 7. As fases so executadas

seqencialmente, como indicado pelas setas em negrito. Cada fase executada uma

vez, porm iteraes de partes da fase so permitidas para correo de erros,

conforme indicado pelas setas tracejadas.

A entrega do sistema completo ocorre em um nico marco ao fim da fase de

transferncia. Esta abordagem permite uma relao contratual simples.

Figura 7 Abordagem do tipo cascata

3.3.2.2 Abordagem do Tipo Incremental

Esta abordagem caracterizada por parties das fases de detalhamento e

produo, transferncia, e operao e manuteno em unidades mais gerenciveis,

uma vez que o projeto de arquitetura tenha sido definido, conforme ilustrado na Figura

8. O software entregue em vrias verses, cada uma com incremento de

capacidades ou funcionalidades novas.


45/84

Figura 8 Abordagem do tipo incremental

Esta abordagem muito boa para grandes projetos, onde uma simples entrega

no vivel. Isto pode ocorrer em inmeras situaes, tais como:

Certas funes precisam estar funcionando antes de outras;

O tamanho da equipe de desenvolvimento obriga a subdividir o projeto em

vrias entregas;

O oramento considerado ser dividido ao longo dos anos.

A desvantagem desta abordagem que testes de regresso precisam ser

feitos para confirmar se as capacidades existentes no softwareesto compatveis com

uma nova verso. Este aumento de quantidade de testes gera acrscimo no custo do

sistema.

3.3.2.3 Abordagem do Tipo Evolucionria

A abordagem do tipo evolucionria caracterizada pelo desenvolvimento

planejado de mltiplas verses, como ilustrado na Figura 9.Todas as fases do ciclo de vida so executadas para produzir uma verso.

Este tipo de abordagem pode ser usado nos seguintes casos:

Alguma experincia do usurio requerida para refinar e completar os

requisitos (ilustrado na Figura 9 pelas linhas tracejadas dentro da caixa

operao e manuteno);

Alguma parte da implementao pode depender da disponibilidade de

tecnologias futuras;


46/84

Figura 9 Abordagem do tipo evolucionria

Alguns novos requisitos de usurio so antecipados mais ainda no esto

completos;

Alguns requisitos podem ser significantes, mas existe dificuldade de

integrao com outros, ento decide-se transferi-los para a prxima verso.

As extenses tracejadas nas caixas da Figura 9 informam que alguma

sobreposio nas fases de operao e manuteno ocorreu at cada entrega ser

finalizada e aceita.

A desvantagem da abordagem evolucionria que os requisitos iniciais so

muito incompletos, e assim a estrutura inicial do software pode no sustentar a

complexidade de evolues futuras. Reescritas caras podem ser necessrias, ou pior,

solues temporrias podem vir a serem includas no sistema, distorcendo a evoluo.

Nesta abordagem nem todos os requisitos precisam ser totalmente

implementados em cada ciclo de desenvolvimento, porm o projeto de arquitetura

deve contar com todos os requisitos conhecidos.


47/84

4 O GERENTE DE PROJETOS E SUA EQUIPE

Quando um gerente de projetos apontado, ele deve ter em mente que ser

referncia para as funes e responsabilidades do projeto, que podem variar ao longo

do tempo. As funes e responsabilidades do gerente so geralmente crticas na

maioria dos projetos, mas variam significativamente dependendo da rea de aplicao.

Conforme sugere o PMI (2000) as funes e responsabilidades do projeto

devem ser estreitamente ligadas ao detalhamento do escopo do projeto. A Matriz de

Designao de Responsabilidade (RAM) freqentemente utilizada para esse

propsito, como ilustrado na Tabela 1. Em grandes projetos, as RAMs podem ser

desenvolvidas em vrios nveis. Uma RAM de alto nvel pode definir que grupos ou

unidades so responsveis por um determinado elemento do produto, enquanto

RAMs de baixo nvel so utilizadas dentro de um grupo para designar funes eresponsabilidades, referentes a atividades especficas, para indivduos em particular.

Tabela 1 Exemplo de Matriz de Designao de Responsabilidades

PESSOA

A B C D E F ...

Requerimentos C Rv Rs P P

Funcional C Rs P P

Projeto C Rv Rs E P

Desenvolvimento Rv C Rs P P

FASE

Teste C P E Rs P

P participante Rs responsvel Rv requerido na reviso

E requerido na entrada C requerido na comunicao do final da fase

O objetivo do gerente de projeto entregar o produto no tempo certo, com o

oramento e qualidade requerida. Embora a preciso destas responsabilidades varie

de organizao para organizao e de projeto para projeto, o planejamento e previsosempre so includos. Segundo ESA (1991, p. 4), trs reas adicionais de

responsabilidade de gerenciamento so definidas:

Responsabilidades interpessoais, que incluem:

- liderana da equipe de projeto;

- trabalho com o patrocinador, a gerncia superior e os

fornecedores do projeto;


48/84

- representar o responsvel do projeto quando necessrio.

Responsabilidades informais, que incluem:

- monitoramento da performance da equipe e implementao do

plano do projeto;

- disseminao de informaes sobre as tarefas para a equipe do

projeto;

- disseminao de informaes sobre o andamento do projeto para

o patrocinador e gerncia superior;

- atuao como porta-voz da equipe de projeto.

Responsabilidades de deciso, que incluem:

- alocar recursos de acordo com o plano do projeto, e ajustar estes

recursos quando for necessrio;

-

negociar com o patrocinador sobre a interpretao das obrigaescontratuais, com a organizao sobre os recursos consumidos e

com a equipe sobre suas tarefas;

- lidar com imprevisibilidades, como quebra de equipamentos e

problemas pessoais, com o intuito de facilitar o progresso do

projeto.

4.1 O Conhecimento Tcnico

Alm dos conhecimentos administrativos, desejvel que um gerente de

projetos de software tenha tambm alguns conhecimentos tcnicos, que ajudaro na

maioria das tomadas de deciso.Tais conhecimentos incluem as seguintes reas:

Mtodos e ferramentas;

Padres de desenvolvimento e codificao;

Modelo lgico;

Requisitos de software;

Modelo fsico;

Arquitetura do projeto;

Detalhamento do Projeto;

Gerenciamento de configurao;

Verificao e validao;

Garantia de qualidade.


49/84

Em mdios e grandes projetos os gerentes de projeto costumam delegar muita

das rotinas tcnicas de responsabilidade gerencial para os lderes de equipe.

4.2 A Escolha da Equipe

A montagem da equipe corresponde a conseguir que os recursos humanos

necessrios sejam alocados ao projeto. Muitas vezes o recurso desejado pode no

estar disponvel, sendo ento papel do gerente do projeto certificar de que os recursos

disponveis satisfazem os requisitos do projeto. A fim de conduzir melhor este trabalho

de escolha da equipe, o PMI (2000, p. 98) cita algumas consideraes:

Experincia anterior os indivduos ou grupos realizaram trabalhos similares

anteriormente? Eles fizeram isso bem?

Interesses pessoais os indivduos ou grupos esto interessados em

trabalhar nesse projeto?

Caractersticas pessoais os indivduos ou grupos tm caractersticas

prprias para trabalhar como uma equipe?

Disponibilidade a maioria dos indivduos ou grupos desejados estaro

disponveis no momento necessrio?

Em alguns casos, o pessoal pode ser designado previamente ao projeto. Isto

acontece, por exemplo, quando o projeto resultado de uma proposta competitiva e opessoal especificado foi prometido como parte da proposta.

Caso todo o pessoal habilitado esteja comprometido com outros projetos, a

organizao pode lanar mo da contratao de pessoal necessrio para o projeto.

4.3 Desenvolvimento da Equipe

O desenvolvimento da equipe envolve tanto o aumento da

capacidade das partes envolvidas para contribuir individualmente,

quanto o aumento da capacidade da equipe para funcionar como um

time. O crescimento individual (gerencial e tcnico) a fundao

necessria para desenvolver a equipe. O funcionamento como

equipe crtico no que se refere capacidade do projeto alcanar

seus objetivos (PMI, 2000, p. 99).


50/84

O desenvolvimento da equipe tambm muito influenciado pelo sistema de

organizao em que o projeto est inserido, principalmente quando os membros da

equipe respondem tanto gerncia funcional quanto gerncia do projeto. A gerncia

efetiva desses relacionamentos freqentemente um fator crtico de sucesso para o

projeto e, geralmente, de responsabilidade do gerente do projeto. Para que o

desenvolvimento da equipe possa ser bem sucedido, o PMI (2000, p. 99) enumerou

algumas ferramentas e tcnicas que podem ser utilizadas:

Atividades de formao da equipe;

Habilidades da administrao geral;

Sistemas de reconhecimento e recompensa;

Alocao de equipe no mesmo espao fsico;

Treinamento.

A resultado do desenvolvimento da equipe a melhoria no desempenho do

projeto, que pode vir de vrias fontes como a melhoria das habilidades individuais ou a

melhoria no comportamento da equipe. O gerente do projeto deve, geralmente,

fornecer informaes para a avaliao do desempenho de quaisquer membros da

equipe com os quais interage de forma significativa.


51/84

5 O PLANEJAMENTO DO PROJETO DE SOFTWARE

Qualquer que seja o tamanho do projeto, um bom planejamento essencial

para que ele seja bem sucedido. Um processo de planejamento de projeto de software

ilustrado na Figura 10. Segundo ESA (1994, p. 6) as cinco principias atividades do

planejamento so:

Definio do escopo;

Definio das atividades;

Estimativa de recursos e tempo;

Definio do sequenciamento das atividades;

Definio do cronograma e do custo.

Este processo pode ser aplicado a todo o projeto ou para uma fase do projeto.Cada atividade deve ser repetida vrias vezes para se ter um plano plausvel. A

princpio, cada atividade da Figura 10 pode ser ligada a outra por meio de feedback,

onde informaes adquiridas em fases posteriores do planejamento so usadas para

revisar decises planejadas anteriormente. Estas aes foram omitidas da figura para

simplific-la, porm a iterao essencial para otimizar o plano.

As informaes necessrias e desejveis para um planejamento de projeto de

software so:

Os documentos de requisitos de usurio, requisitos de software ou projeto de

arquitetura, de acordo com a fase do projeto;

Padres de softwarepara os produtos e procedimentos;

Dados histricos para estimativa de recursos e tempo;

Dados de custo de fornecedor;

Riscos a ser considerados;

Fatores contingenciais, como novas tecnologias;

Datas previstas, como a data de entrega;

Recursos disponveis, como a disponibilidade do grupo.

Os resultado inicial do planejamento do projeto o Plano de Gerenciamento

do Projeto de Software, que deve conter:

Uma definio do modelo do processo, do tipo de abordagem do ciclo de vida

e os mtodos e ferramentas que sero utilizados;

A Estrutura Analtica do Projeto (EAP);


52/84

Fonte: ESA, 1994, p. 6

Figura 10 Processo de Planejamento do Projeto de Software


53/84

A organizao do projeto, a qual define as regras e o relacionamento entre os

nveis hierrquicos do projeto;

O sequenciamento das atividades, definindo as dependncias, o tempo para

serem completadas e as folgas entre cada pacote de trabalho;

Um cronograma do projeto, definindo o incio e o fim de cada pacote de

trabalho;

Uma lista dos recursos necessrios para a implementao do projeto;

Um custo total estimado.

5.1 Gerenciamento do Escopo

O gerenciamento do escopo elucidado por Gasnier (2000, p. 22, grifo do

autor) como sendo

o que define as atividades necessrias e suficientes para que o

projeto seja concludo com sucesso, estabelecendo objetivamente o

que est e o que no est incluso no projeto. Assim, o gerenciamento

do escopo do projeto envolve a avaliao de sua viabilidade tcnico-

econmica. Tambm definimos os critrios para avaliao de que uma

fase ou todo o projeto foi concludo em conformidade, isto no

planejamento do escopo, para, a seguir realizarmos a definio do

escopo, onde elaborada a estrutura analtica do projeto.

O PMI (2000) observa que no contexto do projeto, o termo escopodeve se

referir a:

Escopo do produto aspectos e funes que devam ser includos no produto

ou servio;

Escopo do projeto o trabalho que deve ser feito com a finalidade de

entregar um produto de acordo com os aspectos e as funes especificados.

A concluso do escopo do produto mensurada contra as exigncias,

enquanto a concluso do escopo do projeto mensurada contra o plano. Ambos os

tipos de gerncia de escopo devem ser bem integrados para garantir que o trabalho do

projeto resulte na entrega do produto especificado.


54/84

5.1.1 Estrutura Analtica do Projeto

A Estrutura Analtica do Projeto (EAP), tambm usualmente denominada Work

Breakdown Structure (WBS), define o relacionamento hierrquico do conjunto de

atividades do projeto, tambm chamado de pacotes de trabalho ou work packages.

Dividir o trabalho em pacotes requer um bom entendimento das necessidades

do projeto e do relacionamento lgico existente no modelo do processo. Alguns

critrios para a modelagem dos pacotes de trabalho so citados pela ESA (1994):

Coerncia as tarefas dentro de um pacote de trabalho devem ter o mesmo

objetivo;

Ligao as dependncias entre os pacotes de trabalho devem ser

minimizadas, assim os membros da equipe podem trabalhar

independentemente; Continuidade a produo dos pacotes de trabalho devem ser de tempo

integral para maximizar a eficincia.

Gasnier (2000), cita mais algumas diretrizes para a produo de um EAP de

qualidade:

Evitar atividades de nvel mais baixo superiores a duas semanas, pois

comprometem o processo de acompanhamento;

Evitar atividades relativamente pequenas demais em relao ao tempo total

do projeto. Por exemplo, em um projeto de seis meses, uma atividade com

durao de uma hora pode ser considerada demasiado preciosismo;

Incluir diversos marcos (milestones), isto , eventos de durao zero, de

forma a identificar e facilitar o controle.

Mesmo com alguns critrios estabelecidos, a estimativa de durao de

algumas atividades pode se tornar uma tarefa difcil. Nestes casos, algumas tcnicas

teis so as informaes histricas, analogias com situaes conhecidas,

decomposio e sntese, simulao e avaliao de especialistas.O nvel de detalhamento das atividades deve seguir o nvel de certeza

necessria para se estimar os recursos e os tempos no prximo estgio do

planejamento.

Depois da definio dos pacotes de trabalho, estes devem ser organizados

hierarquicamente, relatando ento cada atividade.


55/84

Servindo ao propsito de comunicar tudo aquilo que deve ser realizado, desde

o incio at a concluso do projeto, a EAP pode ser representada de forma

esquemtica, ilustrado na Figura 11 ou atravs de uma lista de atividades indentada,

exemplificado na Tabela 2. Tambm importante que cdigos de significncia sejam

colocados junto a cada item da estrutura.

Figura 11 Forma esquemtica de um EAP

Tabela 2 Lista de atividades de um EAP

EAP Atividade

1 Projeto Software X

1.1 Etapa A

1.1.1 Atividade 1

1.1.1.1 Tarefa 1.1

1.1.1.2 Tarefa 1.2

1.1.2 Atividade 2

1.1.2.1 Tarefa 2.1

1.1.2.2 Tarefa 2.2

1.1.2.3 Tarefa 2.3

1.2 Etapa B

1.2.1 Atividade 3

1.2.1.1 Tarefa 3.1

1.2.1.2 Tarefa 3.2


56/84

O nmero de pacotes de trabalho em um projeto normalmente aumenta com o

tamanho do projeto. Projetos pequenos (menos de dois homens-ano) devem ter

menos de dez nveis de pacotes de trabalho, e grandes projetos (mais de vinte

homens-ano) podem chegar a mais de cem. Comumente, pequenos projetos utilizam

um ou dois nveis, para projetos mdios de dois a quatro nveis, e para grandes

projetos quatro ou cinco.

Novos pacotes de trabalho devem ser definidos para novas tarefas

identificadas durante o projeto. Algumas organizaes acham mais convenientes criar

um pacote nomeado de trabalho no planejadopara contemplar estas atividades que

surgem em todo projeto.

Gasnier (2000) recomenda que a construo do EAP utilize os passos abaixo,

denominados Estratgia de Contorno:

1. Lista de Atividades1.1. Relacionar todas as etapas do projeto

1.2. Relacionar as atividades de cada etapa

1.3. Detalhar as tarefas de cada atividade

1.4. Identificar os marcos (milestones)

2. Amarrao lgica

2.1. Identificar uma referncia (cdigo de identif icao) para cada elemento

da lista de atividades

2.2. Identificar, atravs das referncias acima, as dependncias entre as

atividades3. Anlise crtica

3.1. Teste de suficincia: Faltam elementos na lgica?

3.2. Teste de necessidade: Sobram elementos da lgica?

3.3. Teste de consistncia: Executando todas as atividades alcanamos os

objetivos estabelecidos?

3.4. Teste de clareza: Pessoas envolvidas que no participaram de sua

elaborao conseguiro compreender a lgica?

4. Programao

4.1. Estimar a durao de cada atividade do nvel mais baixo

4.2. Relacionar os recursos necessrios em cada atividade

4.3. Determinar a data de incio (ou trmino) do projeto

4.4. Determinar as datas de incio e trmino e todas as atividades

considerando as dependncias e os recursos

5. Oramento

5.1. Estimar os custos de cada recurso e de cada atividade


57/84

5.2. Otimizar a programao, nivelando recursos e adiantando ou atrasando

atividades

Aps a definio do escopo, a verificao e formalizao de aceite pelas partes

envolvidas devem ser feitos. A documentao de que o cliente ou patrocinador aceitou

o produto do projeto ou da fase deve ser preparada e distribuda.

5.2 Planejamento de Recursos e Durao

O planejamento dos recursos envolve determinar quais recursos fsicos

(pessoas, equipamentos e materiais) e quais quantidades de cada devem ser usadas

para a realizao das atividades do projeto (PMI, 2000, p. 75).

Ainda, segundo o PMI, para que o planejamento dos recursos possa ser

produzido necessrio possuir algumas prvias informaes, que so:

Estrutura Analtica do Projeto (EAP) identifica os elementos do projeto que

necessitaro de recursos, e conseqentemente, a entrada fundamental do

planejamento de recursos;

Informaes histricas devem ser usadas, quando disponveis, as

informaes histricas relativas aos tipos de recursos que foram requeridos

em trabalhos similares de projetos anteriores;

Declarao do Escopo contm a justificativa e os objetivos do projeto; Descrio do quadro de recursos o conhecimento de quais recursos esto

potencialmente disponveis necessrio para o planejamento dos recursos.

A quantidade de detalhes e o nvel de especializao na descrio do quadro

de recursos variaro durante as fases do projeto;

Polticas Organizacionais as polticas da organizao, relativas tanto ao

quadro de pessoal quanto a aluguel ou compra de suprimentos e

equipamentos, devem ser consideradas durante o planejamento dos

recursos.

Primeiramente, o gerente de projeto deve analisar os pacotes de trabalho,

definir os recursos humanos requeridos e definir alguns padres para o projeto.

Exemplos de padres para projetos de softwareso:

Gerente do projeto;

Lder de equipe;

Programador;


58/84

Engenheiro de teste;

Engenheiro de qualidade de software.

O gerente do projeto tambm pode definir o relacionamento entre os membros

da equipe, estabelecendo efetiva coordenao e controle do projeto, como por

exemplo, a quem cada membro da equipe deve se reportar.

Em seguida o gerente do projeto, com a assistncia de sua equipe e talvez

peritos externos, deve fazer uma anlise detalhada dos pacotes de trabalho e fornecer

uma estimativa de esforo necessrio para complet-los, por exemplo, o nmero de

homens-hora.

Quando possvel, estas estimativas devem ser comparadas aos dados

histricos. Pode-se ajustar os resultados considerando fatores como experincia da

equipe, riscos de projeto, novas tecnologias e prticas de trabalho mais eficientes.Recursos indiretos do projeto so normalmente estimados atravs de dados de

fornecedor e incluem:

Produtos comerciais que faro ou no parte do produto final;

Materiais consumveis;

Facilidades internas;

Servios externos;

Viagens e subsistncia;

Embalagens e despachos;

Seguro.

Frmulas como a COCOMO e a FPA no devem ser utilizadas neste estgio

do planejamento. Elas devem ser usadas como verificao do total do custo estimado

quando o plano estiver completado.

A estimativa da durao da atividade envolve avaliar a quantidade de perodos

de trabalho que provavelmente sero necessrios para implementar cada atividade.

Uma pessoa ou grupo da equipe do projeto que estiver mais familiarizada com a

natureza de uma atividade especfica deve fazer ou, no mnimo, aprovar a estimativa.

A durao dos pacotes de trabalho deve ser calculada a partir da estimativa de

esforo e dos dados de produtividade histrica. Estes dados sero necessrios para a

construo do diagrama de atividades e clculo da durao total do projeto.

A produtividade estimada deve descrever a produtividade mdia e no o

mximo de produtividade. Estudos mostram que funes heterogneas podem

absorver 50% do tempo da equipe, reduzindo a produtividade mdia muito abaixo do

pico (ESA, 1994, p. 20).


59/84

5.3 Sequenciamento das Atividades

O sequenciamento das atividades envolve identificar e documentar as relaes

de dependncia entre as atividades. Estas devem ser seqenciadas corretamente com

a finalidade de suportar o desenvolvimento de um cronograma realstico e alcanvel

(PMI, 2000).

As duas tcnicas mais utilizadas para executar esta atividade so o diagrama

de rede, mais comumente chamado de Grfico PERT (Tcnica de Avaliao e Reviso

de Projetos) e o cronograma de barras, ou Grfico de Gantt.

5.3.1 Diagrama de Rede ou Grfico PERT

Um diagrama de redes representa os pacotes de trabalho de um projeto como

um conjunto de ndulos com setas ligadas entre si, conforme ilustrado na Figura 12.

Uma seqncia de setas define um caminho, ou parte de um caminho durante o

projeto. Caminhos circulares no so permitidos nas redes de atividade. O objetivo da

construo de um diagrama de redes analisar a seqncia e a dependncia das

atividades e identificar os efeitos de possveis alteraes na programao das

atividades.

Figura 12 Exemplo de Diagrama de Redes

Dois importantes subprodutos deste diagrama so o caminho crtico e as folgas

de trabalho, exemplificados na Figura 13. O caminho crtico o caminho mais longo

atravs da rede em termos de durao total das atividades. O tempo para completar o

caminho crtico igual ao tempo para completar o projeto.


60/84

Figura 13 Exemplificao de Caminho Crtico e Folga

A folga de trabalho igual a diferena entre o incio (ou fim) da menor ou maior

data dos pacotes de trabalho, a quantidade de tempo em que cada atividade pode

ser movida sem afetar o tempo total para completar o projeto. Atividades que fazem

parte do caminho crtico, conseqentemente, no tero tempo de folga.

Em geral, somente devem ser includos no diagrama de rede os pacotes de

trabalho que dependem de outro, ou procedimentos de sada utilizados por outra

atividade, isto simplifica o diagrama e no afeta o caminho crtico.

5.3.2 Cronograma de Barras ou Grfico de Gantt

O Cronograma de Barras ou Grfico de Gantt, apresenta as atividades na

forma esquematizada de barras horizontais, cujos comprimentos so proporcionais

aos respectivos tempos de execuo, em folhas onde o cabealho uma linha de

tempo (timeline). Assim, possvel comunicar o plano de ao e o progresso de forma

intuitiva, bem como identificar rapidamente problemas, riscos e oportunidades. A

Figura 14 exemplifica um cronograma de Gantt.Na Figura 14 as setas indicam as dependncias entre as atividades, isto , a

obrigatoriedade de uma atividade sucessora iniciar aps a concluso de uma atividade

predecessora.


61/84

Figura 14 Exemplo de Cronograma de Gantt

Boehm (1981) faz uma comparao entre o Grfico de Gantt e o PERT e expe

que o primeiro possui algumas vantagens em relao ao segundo, por ser maissimples e fcil de desenvolver e atualizar. Ele fornece informaes de andamento do

projeto, como tambm informaes sobre datas, as quais no existem no PERT

padro. Em geral, o Grfico de Gantt preferido para produzir cronogramas simples, e

o PERT aconselhvel para as partes do projeto com complexas dependncias de

relacionamento.

5.4 Estimativa de Custos

A estimativa dos custos envolve desenvolver uma estimativa dos gastos com

recursos necessrios a implementao das atividades do projeto.

Quando o projeto realizado sob um contrato, devem ser tomados

cuidados para distinguir custos estimados de preo. A estimativa dos

custos envolve elaborar uma avaliao quantitativa dos resultados

provveis (quanto custar para a organizao o fornecimento do

produto ou servio envolvido). O preo uma deciso de negcio

quanto a organizao cobrar pelo produto ou servio que usa asestimativas de custo como uma das vrias consideraes (PMI,

2000, p. 76).

O mnimo custo total do projeto a soma de todos os pacotes de trabalho.

Porm, os custos de trabalho devem ser calculados a partir da quantidade total de

tempo gasto por pessoa do projeto. Isto assegura que os tempos gastos por esperas

de pacotes de trabalho sejam includos nas estimativas de custo.


62/84

Atividades com fatores de alto risco devem ser indicadas para incio o mais

cedo possvel e as atividades com folgas devem ser usadas como contingncia.

Algumas estratgias para a reduo do custo do projeto so:

Investir em um planejamento detalhado, evitando perdas e retrabalhos;

Investir em comunicao, transparncia, motivao e comprometimento da

equipe;

Simplificar o escopo, eliminando ou reduzindo o tempo dedicado a atividades

desnecessrias, que no agregam valor ao projeto;

Avaliar a utilizao de recursos mais produtivos;

Procurar utilizar os recursos alocados de forma contnua, evitando

sobrecargas e janelas de descontinuidade;

Negociar antecipadamente com os fornecedores, visando obter custos

reduzidos por escala, perodos de baixa demanda, carga de trabalho, etc.; Procurar evitar horas extras.

O PMI (2000) enumera algumas tcnicas usualmente empregadas para se

estimar os valores relacionados aos custos de projeto:

Estimativas por analogias o custo efetivamente incorrido de um projeto ou

atividade similar pode servir de base para se estimar o custo de um novo

projeto ou atividade;

Modelo paramtrico atravs de parmetros, equaes matemticas e

frmulas prticas pode ser possvel prever alguns dos valores envolvidos; Estimativas bottom-up(de baixo para cima) esta tcnica envolve estimar o

custo individual dos itens de trabalho, depois sumariz-los ou agreg-los para

obter a estimativa total do projeto;

Ferramentas computadorizadas planilhas e softwareespecializados podem

contribuir para o processamento destes dados, utilizando as demais tcnicas

acima.

Geralmente, a alocao de recursos em cada perodo ao longo da execuo de

um projeto apresenta uma distribuio tpica, semelhante a Figura 15.

O grfico dos custos acumulados resulta na conhecida Curva S de utilizao

de recursos, ilustrado na Figura 16.

Na concluso do processo de planejamento do projeto as informaes geradas

so denominadas de Curva S baseline. O baseline do custo o oramento referencial

que ser utilizado para medir e monitorar o desempenho do custo do projeto. Muitos


63/84

projetos, especialmente os maiores, podem ter vrios baselinesde custo para medir

diferentes aspectos de desempenho.

Figura 15 Tpica distribuio dos custos durante a execuo de um projeto

Figura 16 Curva S dos custos acumulados durante o projeto


64/84

6 GERENCIAMENTO DE RISCO

Todos os projetos possuem riscos, porm o importante em um gerenciamento

de risco no buscar elimin-los, pois isso em geral impossvel ou extremamente

oneroso, mas reduzir o potencial de ameaa ao sucesso do projeto.

O gerenciamento de risco nunca deve seguir a premissa otimista que tudo

correr bem. Ao invs disso os gerentes de projeto devem sempre se perguntar o

que mais provvel sair errado?. Isto realismo, no pessimismo.

Os riscos mais comuns em projetos de softwareso os fatores de experincia,

planejamento, tecnologia e os fatores externos.

6.1 Fatores de Experincia

O gerente de projeto o membro da equipe, cujaperformancetem efeito crtico

sobre o projeto. Gerentes inexperientes so um risco significativo, portanto as

organizaes devem igualar a dificuldade do projeto a experincia do gerente.

Um segundo fator de risco, so equipes com experincias, habilidades e

qualificaes insuficientes perante as tarefas designadas. Os gerentes de projeto

devem tomar algumas medidas de reduo de risco, como:

Avaliar a equipe antes de se juntar ao projeto;

Alocar tarefas para a equipe que coincidam com suas experincias,habilidades e qualificaes;

Manter dentro da equipe de projeto pessoas que possuam as habilidades,

experincias e qualificaes apropriadas para tarefas futuras.

As

gerenciamento de

Documents