RGIS EDUARDO GRANDCHAMP

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Taubat SP

2002

RGIS EDUARDO GRANDCHAMP

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Monografia

apresentada em

para

obteno Gerncia

do de

Certificado de Especializao pelo Curso de Ps-graduao MBA -

Produo e Tecnologia do Departamento de Economia, Contabilidade, Administrao e Secretariado da Universidade de Taubat.

Orientador: Prof. Dr. Marco Antnio Chamon

Taubat SP

2002

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.

RGIS EDUARDO GRANDCHAMP

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___________________________________

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.

AGRADECIMENTOS

Agradeo ao Prof. Dr. Marco Antnio Chamon, que me orientou de forma objetiva 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 e meio, 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.

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 software existente no mercado, foi elaborado um estudo de campo por meio de entrevistas realizadas com gerentes e desenvolvedores de software em 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 software possuem 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.

GRANDCHAMP, R. E. Management of Software Projects . 2002. 82 p. Monograph (Specialization - MBA in Management of Production and Technology) Department of Economy, 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, 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 through such as books, scientific papers, and

interviews 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.

SUMRIO
RESUMO ABSTRACT LISTA DE TABELAS LISTA DE FIGURAS 1 INTRODUO 1.1 Objetivos 1.2 Organizao do Trabalho 2 O ESSENCIAL EM ADMINISTRAO DE PROJETOS 2.1 Complexidade e Incerteza 2.2 Programas e Subprojetos 2.3 Ciclo de Vida do Projeto 2.4 Definio de Objetivos 2.5 Processos da Gerncia de Projetos 2.5.1 Planejamento 2.5.2 Execuo 2.5.3 Controle 2.5.4 Encerramento 3 GERENCIAMENTO DE PROJETOS DE SOFTWARE 3.1 Mtricas de Software 3.1.1 Comparao Histrica 3.1.2 COCOMO (Constructive Cost Model) 3.1.3 Anlise de Pontos de Funo 3.1.4 Anlise de Distribuio de Atividades 3.1.5 Mtodo Delphi 3.1.6 Estimativa de esforo de Integrao e Teste de Sistema 3.2 Qualidade de Software 3.2.1 Modelo de Processo CMM 5 6 10 11 12 13 13 15 16 17 17 19 21 22 24 25 27 29 30 31 31 32 33 33 34 34 35

3.2.2 Norma NBR 13.596 3.3 O Ciclo de Vida do Software 3.3.1 Fases do Ciclo de Vida 3.3.1.1 Definio de Requisitos de Usurio 3.3.1.2 Definio de Requisitos de Software 3.3.1.3 Projeto de Arquitetura 3.3.1.4 Projeto Detalhado e Produo 3.3.1.5 Transferncia 3.3.1.6 Operaes e Manuteno 3.3.2 Abordagens do Ciclo de Vida 3.3.2.1 Abordagem do Tipo Cascata 3.3.2.2 Abordagem do Tipo Incremental 3.3.2.3 Abordagem do Tipo Evolucionria 4 O GERENTE DE PROJETOS E SUA EQUIPE 4.1 O Conhecimento Tcnico 4.2 A Escolha da Equipe 4.3 Desenvolvimento da Equipe 5 O PLANEJAMENTO DO PROJETO DE SOFTWARE 5.1 Gerenciamento do Escopo 5.1.1 Estrutura Analtica do Projeto 5.2 Planejamento de Recursos e Durao 5.3 Sequenciamento das Atividades 5.3.1 Diagrama de Rede ou Grfico PERT 5.3.2 Cronograma de Barras ou Grfico de Gantt 5.4 Estimativa de Custos 6 GERENCIAMENTO DE RISCO 6.1 Fatores de Experincia 6.2 Fatores de Planejamento

36 37 37 38 40 40 40 41 41 42 42 42 43 45 46 47 47 49 51 52 55 57 57 58 59 62 62 62

6.3 Fatores de Tecnologia 6.4 Fatores Externos 7 O CONTROLE DO PROJETO DE SOFTWARE 7.1 Anlise do Valor do Trabalho Realizado 7.2 Relatrios de Desempenho 8 VERIFICAO E VALIDAO DO SOFTWARE 9 ENCERRAMENTO DO PROJETO 10 MATERIAIS E MTODOS 11 RESULTADOS DA PESQUISA 12 ANLISE DOS RESULTADOS 13 CONCLUSO REFERNCIAS BIBLIOGRFICAS

63 63 65 66 68 70 72 73 76 79 81 82

LISTA DE TABELAS

Tabela 1 Matriz de Designao de Responsabilidades Tabela 2 Lista de atividades de um EAP Tabela 3 Clculo da variao do custo Tabela 4 Clculo da variao do prazo

45 53 67 68

LISTA DE FIGURAS

Figura 1 As fases de um projeto Figura 2 Exemplo genrico de ciclo de vida do projeto Figura 3 Ligaes entre os grupos de processo em cada fase do projeto Figura 4 Sobreposio dos grupos de processo em cada fase do projeto Figura 5 Interao entre as fases do projeto Figura 6 Modelo de ciclo de vida de um projeto de software Figura 7 Abordagem do tipo cascata Figura 8 Abordagem do tipo incremental Figura 9 Abordagem do tipo evolucionria Figura 10 Processo de Planejamento do Projeto de Software Figura 11 Forma esquemtica de um EAP Figura 12 Exemplo de Diagrama de Redes Figura 13 Exemplificao de Caminho Crtico e Folga Figura 14 Exemplo de Cronograma de Gantt Figura 15 Tpica distribuio dos custos durante a execuo de um projeto Figura 16 Curva S dos custos acumulados durante o projeto Figura 17 Grfico da anlise do valor do trabalho realizado (EVA)

18 19 21 22 22 39 42 43 44 50 53 57 58 59 61 61 69

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 software eram inadequados s necessidades de negcio a que se propunham 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 desenvolvimento tende 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.

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 as principais 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.

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 . O captulo 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.

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 um problema, oportunidade ou interesse de uma pessoa ou organizao, (MAXIMIANO, 1997, p. 20). Os projetos podem envolver uma nica pessoa ou milhares. Podem exigir menos d o 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.

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 s o 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;

 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, comp lexidade 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

atividades que normalmente estariam em seqncia) (PMI, 2000, p. 12).

Abaixo as quatro fases mais comuns no ciclo de vida dos projetos: Preparao: tambm chamada de conceituao ou concepo. Nessa fase define-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:

 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).

Um projeto, como qualquer outro empreendimento que no tenha um objetivo bem-definido para orientar seus passos, certamente andar em volta de si mesmo ou tomar um caminho errtico, o que, no raramente, tem acontecido (VALERIANO, 1998, p. 184). Um projeto deve possuir apenas um objetivo para que sua conduo seja feita com mais certeza e definies mais slidas quanto aos resultados desejados. Mesmo assim, se surgirem mltiplos objetivos, ser necessrio fixar apenas um como principal e os outros como secundrios. Mas como separar ento o principal dos secundrios? Segundo Valeriano (1998), basta saber quais objetivos podem ser sacrificados ou modificados e qual aquele que deve ser mantido a todo o custo. A importncia da clareza e do conhecimento do objetivo por todos os envolvidos tem tanto valor que em diversas pesquisas j realizadas sobre os fatores crticos para o sucesso de um projeto, este aspecto quase sempre vem encabeando a lista, a frente de fatores importantes como apoio da alta gerncia, planejamento e monitoramento, entre outros. O objetivo no pode ser escrito por um simples enunciado, deve ser redigido com todo o rigor necessrio. Para isso algumas recomendaes podem ser teis para uma boa redao de objetivo. Assim, a redao do objetivo deve conter os componentes citados abaixo, conforme proposto por Valeriano (1998): ao: definida por um verbo, no infinitivo preferencialmente, e que deve iniciar a declarao do objetivo: projetar, desenvolver, construir, desenvolver, etc.; objeto: sobre o qual a ao se exerce e/ou da qual ele resulta: uma ponte, um equipamento, um software etc.; requisitos, restries ou condies complementares: de desempenho, de tempo, de qualidade etc. Alguns exemplos de redao de objetivo: Desenvolver novos motores para superar os problemas e restries que a legislao do meio ambiente cria para os motores de veculos. Realizar atividades de educao, sade e saneamento para ajudar a comunidade a se desenvolver e superar problemas de desnutrio e mortalidade infantil. Colocar um homem na Lua at o fim da dcada (J.F. Kennedy, fixando o objetivo do denominado Programa Espacial Norte-americano).

 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 atingilo.

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.

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.

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 mais uma 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 do planejamento 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;

 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;

 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: fornecedores. gerenciar os relacionamentos com os

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 e outras 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;

 Controle da Qualidade: monitorar resultados especficos do projeto para determinar se eles atingem padres adequados de qualidade, e identificar aes para eliminar as causas de desempenhos insatisfatrios; Relato de Desempenho: coletar e divulgar informaes de desempenho. Isto inclui relatrios de status, medidas de progresso, e novas estimativas do projeto; Controle das Respostas aos Riscos: responder a alteraes dos riscos durante o curso do projeto.

Essas informaes so comparadas ao desempenho que o projeto est conseguindo atingir na realidade para possibilitar que as seguintes perguntas sejam respondidas: Da forma como est sendo realizado, o projeto atingir seus objetivos? Os resultados produzidos correspondem aos objetivos? As datas previstas esto sendo respeitadas? O projeto est andando conforme o cronograma, atrasado ou adiantado? necessrio refazer a programao? O consumo de recursos corresponde ao previsto? O projeto precisar de mais ou menos recursos do que o previsto? Que aes devem ser tomadas deste ponto em diante para assegurar que o projeto atinja o resultado?

Valeriano (1998) ainda cita dois aspectos importantes que devem ser considerados quanto ao controle. O planejamento, deve anteceder a execuo e o controle, mas estes dois devem ter incio ao mesmo tempo para logo fechar o circuito, ao incluir, de volta, o planejamento ou, mais apropriadamente, o replanejamento. Qualquer retardo no incio do controle pode resultar em graves danos, a atuao tardia do controle pode ser traumatizante por passar a agir em um processo que vinha evoluindo sem este convvio, fato que ainda pode ser agravado pelo grau de deteriorao havido e pelas conseqentes medidas necessrias. O controle deve ser considerado um componente natural e necessrio em todos os sistemas. Ele , atualmente, muito mais preventivo que corretivo, por atuar sobre as causas e sobre os processos, em vez de atacar as conseqncias ou retrabalhar os defeitos.

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

tempo, mas a transio de um projeto para outro tambm, por isso sempre importante planejar o tempo necessrio para essas avaliaes e transies do final. At este ponto o estudo se preocupou em expor os conceitos e mecanismos mas comuns e necessrios para o gerenciamento de projetos, porm no entrando em detalhes de ferramentas e tcnicas para que isto seja feito. Tais detalhes sero abordados deste ponto em diante onde ser enfatizado o foco do trabalho, os projetos de software .

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 c usto 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.

3.1 Mtricas de Software

As mtricas de software vm se tornando um dos principais tpicos na engenharia da informao, com a crescente exigncia de seus consumidores pela qualidade, rapidez, comodidade e baixo custo de implantao e manuteno. impossvel no enxergar tais tcnicas como alavanca para um produto de melhor qualidade, com custos adequados. Mas existem ainda muitas barreiras que impedem os profissionais da rea de utilizar tais tcnicas ou de faz -lo de modo adequado. Acredita-se que o ato de medir e estimar so a parte mais importante de um projeto de sistema bem-sucedido, e alguns fatos como a falta de maturidade, o desinteresse das empresas de desenvolvimento de sistemas e a baixa popularidade deste assunto entre os profissionais da rea de informtica so algumas das principais causas para o insucesso e o alto custo dos sistemas de informao.
O termo mtrica de software refere-se mensurao dos indicadores quantitativos do tamanho e complexidade de um sistema. Esses indicadores so, por sua vez, utilizados para confrontar os desempenhos observados no passado, a fim de derivar previses de desempenho futuro. (GOMES, 1999, p. 50).

A mtrica de software tem como princpio especificar as funes de coleta de dados, de avaliao e desempenho, atribuir essas responsabilidades a toda a equipe envolvida no projeto, reunir dados de desempenho pertencentes complementao do software, analisar os histricos dos projetos anteriores para determinar o efeito desses fatores e utilizar esses efeitos para pesar as previses futuras. possvel obter os processos para o clculo das mtricas de software atravs da pgina na Internet da ISBSG International Software Benchmarking Standards Group (http://www.isbsg.org.au/) ou SoftwareMetrics ( http://www.softwaremetrics.com). O estabelecimento de mtricas adequadas de um aplicativo permite, entre outras coisas: Melhores oramentos do custo do produto e uma estimativa eficiente do seu valor de mercado; Uma avaliao mais apurada dos recursos necessrios para o desenvolvimento; Uma definio da ordem cronolgica das disponibilidades de recursos, e como dos -los no instante certo da aplicao; O estabelecimento de um cronograma mais efetivo, com menores alteraes;

 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 da Anlise 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 simplesmente compara 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

de estimativa do custo total do desenvolvime nto 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.

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 coordenador para 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.

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 software depois 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, os reporta para a equipe de modificao de software ; 2. A equipe de modificao de software repara 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 software desenvolvido 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 software j 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

produtos intermedirios ao longo do processo e no apenas no produto j acabado. Este procedimento permite que os desvios no produto sejam detectados durante seu desenvolvimento e manuteno, promovendo assim o redirecionamento necessrio ao processo para lev-lo produo de um produto de qualidade. Uma soluo simples para resolver esta lacuna a prtica simultnea das duas abordagens para qualidade de software (processo e produto) como, por exemplo, o modelo CMM ( Capability Maturity Model for Software Modelo de Maturidade e Capacidade para Software), que foca a qualidade do processo de software, e a Norma Brasileira NBR 13.596, que aborda as caractersticas de qualidade de um produto de software .

3.2.1 Modelo de Processo CMM

O CMM, modelo de processo de software desenvolvido pelo SEI ( Software Engineering Institute, da Carnegie Mellon University) a pedido do DoD (Departamento de Defesa dos EUA), descreve os elementos chave de um processo de software eficiente e eficaz, alm de indicar uma maneira evolutiva de transformar um processo de software imaturo, em um processo maduro e disciplinado. Desta forma, este modelo pode ser utilizado tanto para definir o nvel de maturidade de uma organizao, quanto ao seu processo de software, como tambm para orientar um trabalho de melhoria de processo. So definidos cinco nveis de maturidade conforme SantAna e Guerra (2002): 1 Inicial: o sucesso da organizao depende do herosmo das pessoas; 2 Repetvel: a organizao j possui um planejamento para novos projetos baseado em suas especificaes e em experincias de projetos passados similares; 3 Definido: existe um processo de software padro para toda a organizao; 4 Gerenciado: a organizao consegue um controle quantitativo da qualidade de seu processo de software e dos produtos gerados por ele; 5 Otimizado: consegue promover uma melhoria contnua de seu processo de forma organizada e sem prejudicar o bom andamento dos projetos que esto sendo executados.

O CMM abrange prticas de planejamento, gerenciamento, desenvolvimento e manuteno. Quando estas prticas so realizadas, a organizao aumenta sua

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 em relao aos recursos; 5. Manutenibilidade : testabilidade; 6. Portabilidade: adaptabilidade, capacidade para ser instalado, analisabilidade, modificabilidade, estabilidade e

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 software para 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).

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 existiam grandes 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 software pode 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 software se inicia quando o produto concebido e termina quando este j no est disponvel para uso, ele compreende as atividades de desenvolvimento, operao e manuteno.

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 aprovao do 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.

Fonte: ESA, 1994, p. 1-3

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

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 Software deve 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 de software e hardware, e pelos gerentes envolvidos. Durante esta fase o restante do Plano de Gerenciamento do Projeto de Software deve 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

engenheiros de software e 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 software e 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 Software deve 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 Projeto deve 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 software pode 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 ateno quanto 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

O modelo de ciclo de vida do software mostrado 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.

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 software esto 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;

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.

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 e responsabilidades, referentes a atividades especficas, para indivduos em particular. Tabela 1 Exemplo de Matriz de Designao de Responsabilidades PESSOA A FASE Requerimentos Funcional Projeto Desenvolvimento Teste C C C Rv B Rv C Rs Rs Rv C C D P P Rs Rs P E E P Rs E P P P P P F ...

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 previso sempre 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;

- 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 obrigaes contratuais, com a organizao s obre 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 administr ativos, 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.

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: Exper incia 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 o pessoal 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).

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 f ontes 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.

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 software para 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);

Fonte: ESA, 1994, p. 6

Figura 10 Processo de Planejamento do Projeto de Software

 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 n o projeto. Assim, o gerenciamento do escopo do projeto envolve a avaliao de sua viabilidade tcnicoeconmica. 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 escopo deve 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.

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.

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 1 1.1 1.1.1 1.1.1.1 1.1.1.2 1.1.2 1.1.2.1 1.1.2.2 1.1.2.3 1.2 1.2.1 1.2.1.1 1.2.1.2 Projeto Software X Etapa A Atividade 1 Tarefa 1.1 Tarefa 1.2 Atividade 2 Tarefa 2.1 Tarefa 2.2 Tarefa 2.3 Etapa B Atividade 3 Tarefa 3.1 Tarefa 3.2 Atividade

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 planejado para 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 Atividades 1.1. 1.2. 1.3. 1.4. Relacionar todas as etapas do projeto Relacionar as atividades de cada etapa Detalhar as tarefas de cada atividade Identificar os marcos (milestones )

2. Amarrao lgica 2.1. 2.2. Identificar uma referncia (cdigo de identif icao) para cada elemento da lista de atividades Identificar, atravs das referncias acima, as dependncias entre as atividades 3. Anlise crtica 3.1. 3.2. 3.3. 3.4. Teste de suficincia: Faltam elementos na lgica? Teste de necessidade: Sobram elementos da lgica? Teste de consistncia: Executando todas as atividades alcanamos os objetivos estabelecidos? Teste de clareza: Pessoas envolvidas que no participaram de sua elaborao conseguiro compreender a lgica? 4. Programao 4.1. 4.2. 4.3. 4.4. Estimar a durao de cada atividade do nvel mais baixo Relacionar os recursos necessrios em cada atividade Determinar a data de incio (ou trmino) do projeto 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

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 software so: Gerente do projeto; Lder de equipe; Programador;

 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 a f tores 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).

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.

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.

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 mais simples e fcil de desenvolver e atualizar. Ele fornece informaes de andamento do projeto, como tam bm 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 d e 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 as estimativas 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.

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 software especializados 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

projetos, especialmente os maiores, podem ter vrios baselines de 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

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 nunc a 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 software so os fatores de experincia, planejamento, tecnologia e os fatores externos.

6.1 Fatores de Experincia

O gerente de projeto o membro da equipe, cuja performance tem 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 experincias dos fornecedores tambm so fatores chave na estimativa de riscos do projeto. Alguns indicadores de maturidade de fornecedores so: Desenvolvimentos bem sucedidos de sistemas similares; Uso de padres de engenharia de software; Existncia de um programa de melhoria de processos de software.

6.2 Fatores de Planejamento

Preciso nas estimativas de recursos requeridos necessria para se completar o projeto com sucesso. Baixas estimativas so especialmente perigosas se

no houver oramento para recursos adicionais; por outro lado, estimativas excessivas pode resultar em desperdcio e mau aproveitamento dos recursos em outras atividades. Tambm necessrio levar em considerao alguns cuidados com relao equipe. Primeiramente, no dispers-la em diferentes localizaes, pois isto pode gerar uma comunicao pobre. Os gerentes devem alocar sua equipe o mais prximo possvel, permitindo assim maior flexibilidade entre os membros. Tambm no recomendvel que a equipe cresa rapidamente, pois isto pode causar dificuldades de adaptao para os novos membros, ou diminua repentinamente, podendo causar sobrecarga de atividades para os que continuam envolvidos no projeto.

6.3 Fatores de Tecnologia

Inovaes tcnicas representam um risco bvio. Os gerentes de projeto devem avaliar tais evolues durante todo o projeto. Qualquer novo componente, por exemplo, pode causar problemas pois sua capacidade ainda no foi demonstrada. Da mesma forma, a aplicao de novos mtodos deve ser estudada com cuidado, pois freqentemente so imaturos e alguma experincia prtica com o mtodo necessria para refin -lo. Alm disso, normalmente no possuem ferramenta de suporte adequada, tornando ainda mais precria sua utilizao efetiva.

6.4 Fatores Externos

improvvel um projeto obter sucesso sem uma alta qualidade no Documento de Requisitos do Usurio. Esta a base de comparao para as medidas de sucesso. Os gerentes de projeto devem, atravs deste documento, rever os processos assegurar coerncia no conjunto de requisitos disponveis. Interfaces externas, principalmente com sistemas externos, podem ser um risco quanto a definies instveis, pobres ou sem padres. Os gerentes de projeto devem iniciar as discusses com os fornecedores de sistemas externos o mais cedo possvel, j no incio do projeto. Isto assegura que os mesmos esto cientes dos requisitos do projeto o quanto antes. O efeito de entregas atrasadas de sistemas externos pode ser aliviado atravs de: Adio da capacidade temporria de ignorar a ao do sistema externo; e

 Desenvolvimento de um software para simular o sistema externo. Os custos do simulador podem ser trocados com os custos decorrentes do atraso da entrega.

7 O CONTROLE DO PROJETO DE SOFTWARE

Naturalmente mais seguro se antecipar aos problemas e por esta razo investimos tanto no planejamento. No entanto, quase inevitvel que alguns riscos ou surpresas se manifestem durante a execuo do projeto, implicando em custos adicionais, atrasos, incmodos e at mesmo comprometimento dos resultados esperados. Nestas situaes de desvio, o gerente do projeto e sua equipe tm a oportunidade de mostrar e desenvolver suas habilidades e sua criatividade, providenciando as aes corretivas que conduzam o projeto novamente sua trilha original. O gerente do projeto deve adotar uma abordagem quantitativa para mensurar os processos e produtos do software. Isto essencial para o controle efetivo do processo de desenvolvimento de software na organizao. Alguns passos de medio para controle do progresso do software so descritos pela ESA (1994): Avaliar o ambiente do projeto e definir as metas primrias, como o ponto financeiro, qualidade, confiabilidade, etc.; Coletar dados de mtrica e medidas de performance relativa s metas do projeto; Aperfeioar a performance do projeto atualizando os planos para corrigir desvios; Aperfeioar a performance da organizao passando os dados de mtrica e as medies de melhoria de processo de software para a equipe de padres e procedimentos utilizados no projeto. O objetivo de avaliar o ambiente do projeto entender o contexto do mesmo. A meta primria do projeto de software a entrega do produto no tempo certo, com o oramento e qualidade requeridos. A coleta de mtricas e medidas de performance dos processos deve ser feita levando-se em considerao vrios aspectos: Esforo: - quantidade de recurso usado - quantidade de recurso no utilizado Tempo: durao real das atividades em dias, semanas ou meses

 Progresso: -

confronto das datas reais de incio das atividades e as planejadas nmero de pacotes de trabalho completo nmero de problemas de software solucionados

A quantidade de produto produzido pode ser mensurada de vrias maneiras: nmero de linhas de cdigo, excluindo comentrios; nmero de mdulos codificados e unidades testadas; nmero de pontos de funo implementados; nmero de pginas de documentao escrita. Possveis mtricas para mensurar a confiabilidade do produto so: teste de cobertura; complexidade dos mdulos; complexidade dos programas; nmero de reportes de problemas crticos; nmero de mudanas do produto depois da primeira edio ou verso. Os dados de mtrica devem estar disponveis nos relatrios de gerenciamento do projeto para planejamentos futuros e estudos de aperfeioamento de processos de software .

7.1 Anlise do Valor do Trabalho Realizado

A anlise do valor do trabalho realizado (Earned Value Analysis ou EVA) uma tcnica de gerenciamento do progresso, atravs de indicadores de variao monitorados continuamente, durante toda a execuo do projeto.
O objetivo da EVA melhorar a comunicao sobre a situao do projeto, seja encorajando os fornecedores a utilizarem um efetivo sistema de controle gerencial sobre custo e cronograma, seja provendo aos clientes informaes efetivas atravs de medies confiveis e atualizadas[...] (GASNIER, 2000, p. 134).

O conceito simples: medida que o trabalho evolui, o executante da tarefa ou do pacote definido na EAP ganha um valor em moeda corrente, correspondente ao

valor planejado (orado) para aquele resultado. Em determinadas pocas, levantam -se as situaes destas atividades e obtm -se trs custos referentes a esta data, conforme define Valeriano (1998): BCWS (budget cost of work schedule) custo orado do trabalho previsto o valor previsto no oramento e que corresponde s despesas que deveriam ter sito feitas se tudo tivesse corrido como planejado; BCWP (budget cost of work performed) custo orado do trabalho realizado o valor previsto no oramento, correspondente ao que realmente executado; ACWP (actual cost of work performed) custo real to trabalho executado o total das despesas realmente feitas para executar o trabalho. Se os trs valores forem iguais o projeto corre exatamente como previsto no cronograma e no oramento, isto : prazo, custos e realizao fsica esto como planejados. Clculo da variao do custo: CV = BCWP ACWP (custo orado do trabalho realizado custo real do trabalho executado) Uma variao negativa significa que o custo real foi maior do que o planejado. A Tabela 3 exemplifica este conceito. Tabela 3 Clculo da variao do custo Atividades A BCWP[$] ACWP[$] CV 10 9 1% B 15 22 -7% C 10 8 2% D 25 30 -5% E 20 22 -2% F 20 0 20% Total 100 91 -9% foi

Calculo da variao do prazo: SV = BCWP BCWS (custo orado do trabalho realizado custo orado do trabalho previsto)

Um valor negativo significa que o trabalho executado foi menor do que o planejad o. Observa-se que as variaes de prazo so expressas em termos de custos: um atraso custar insumo para ser recuperado e um adiantamento corresponde a uma economia. A Tabela 4 ilustra o clculo da variao do prazo.

Tabela 4 Clculo da variao do prazo Atividades A BCWP[$] BCWS[$] CV 10 10 0% B 15 15 0% C 10 10 0% D 25 10 -15% E 20 20 0% F 20 0 -20% Total 100 65 -35%

O PMI (2000) cita ainda alguns indicadores comumente usados: ndice de desempenho do custo: CPI = BCWP/ACWP, o CPI acumulado (soma de todos os BCWPs individuais divididos pela soma de todos os ACWPs individuais) amplamente utilizado na previso do custo para a concluso do projeto; ndice de desempenho do cronograma: SPI = BCWP/BCWS utilizado para prever a data trmino do projeto. A outra forma de se ilustrar a EVA construindo um grfico da anlise do valor do trabalho realizado, exemplificado na Figura 17.

7.2 Relatrios de Desempenho

Os relatrios de desempenho consistem em coletar e disseminar informaes de desempenho para fornecer aos interessados informaes sobre como os recursos esto sendo utilizados para alcanar os objetivos do projeto. Devem fornecer informaes de escopo, cronograma, custo e qualidade. Algumas ferramentas e tcnicas propostas pelo PMI (2000) para o relato de desempenho so: Revises de desempenho; Anlise da variao; Analises de tendncia; Anlises do valor do trabalho realizado.

Os gerentes de projeto devem ter freqentes discusses com os membros da equipe para que eles estejam sempre atualizados com relao a situao do projeto. Os membros da aquipe devem formalmente reportar o progresso do projeto aos seus gerentes por meio de relatrios de concluso dos pacotes de trabalho.

Fonte: Gasnier, 2000, p. 137

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

8 VERIFICAO E VALIDAO DO SOFTWARE

Verificao o ato de revisar, testar, verificar e documentar itens, processos, servios ou documentos que esto ou no conforme os requisitos especificados. Validao a avaliao do software no final do processo de desenvolvimento para assegurar a conformidade com os requisitos de usurio. Validao , portanto, o fim da verificao (ESA, 1991, p. 2-21).

A verificao essencial para assegurar a qualidade do produto, e pode ser cara e com consumo de grande parte do tempo do projeto, por isso esta atividade deve aparecer no Plano de Gerenciamento do Projeto de Software. As atividades de verificao incluem: Revises tcnica, ensaios e inspees de software; Verificao de requisitos determinados pelos usurios; Verificao do projeto de componentes determinados pelos requisitos de software; Verificao de algoritmos; Testes de integrao; Testes de sistema; Testes de aceitao. Os processos de teste so utilizados para exercitar ou avaliar um sistema ou componente, de forma manual ou automtica para confirmar se os requisitos especificados foram satisfeitos ou identificar diferenas entre os resultados esperados e atuais. A quantidade de tempo gasto com os testes de software freqentemente subestimada. Estas atividades devem ser cuidadosamente especificadas para que possam ser adequadamente oradas. Os gastos aumentam com o nmero de erros presentes antes do incio da fase de testes. Mtodos mais baratos de remoo de erros, como inspeo e ensaio devem sempre ser experimentadas antes do incio dos testes. Os testes de software incluem as seguintes atividades: Planejamento da abordagem e alocao de recursos; Detalhamento da abordagem atravs de vrios tipos de testes; Definio dos dados de entrada, predio dos resultados e condies de execuo em cada especificao de teste;

 Incio da seqncia de testes pela equipe de testes amparada por um procedimento; Registro das execues em um relatrio de testes.
Os testes devem ser produzidos nos mesmos padres do software que ser entregue. O produto e os dados devem ser documentados para monitoramento, como tambm para permitir que tais dados sejam reutilizados posteriormente, verificando-se se a

funcionalidade ou performance do software foi prejudicada por modificaes. Isto chamado de teste de regresso (ESA, 1991, p. 2-26).

Os planos, projetos, casos, procedimentos e relatrios de testes devem ser documentados em um Plano de Verificao e Validao do Software. Os relatrios de aceitao dos testes devem ser anexados ao Documento de Transferncia do Software.

9 ENCERRAMENTO DO PROJETO

Este processo consiste em se verificar e documentar os resultados do projeto, de modo a formal izar a aceitao do produto do projeto pelos patrocinadores, clientes e usurios, e tambm para possibilitar uma reflexo final. importante ressaltar que o projeto s poder ser efetivamente encerrado quando todas as pendncias estiverem sanadas. Quando muito pode-se admitir, em funo da presso dos prazos e sempre a critrio dos patrocinadores, que existam algumas atividades cuja soluo esteja pendente. No entanto estas pendncias devero ser registradas e solucionadas to logo seja possvel. Havendo produtos ou servios contratados de terceiros, na entrega final destes de responsabilidade tica e legal da organizao do projeto a formalizao de um aceite de sua parte. Este aceite deve atestar que o respectivo fornecedor cumpriu correta e satisfatoriamente seu compromisso, em conformidade com as especificaes contratuais, de forma que o mesmo possa tambm realizar seu prprio encerramento administrativo. Este aceite somente poder ser emitido aps a verificao de que no existem pendncias e, naturalmente, no desobriga o fornecedor de suas demais obrigaes, garantias e responsabilidades. A auditoria final dos resultados deve verificar se os objetivos do projeto foram atingidos. A evidncia de pleno sucesso, sucesso parcial ou fracasso dada pelo atendimento das especificaes tcnicas ou fatores crticos de sucesso previamente acordados durante o processo de iniciao.
Para que sejam preservadas as informaes, no encerramento administrativo os registros devem ser revisados e atualizados. A organizao do projeto deve emitir verses finais dos relatrios de desempenho, relatrios de desvios entre realizado e planejado e demais documentos que julgar relevantes. Deve ser processado tambm o fechamento contbil do projeto, o que implica no encerramento de todas as contas relacionadas com o respectivo projeto (GASNIER, 2000, p. 147).

Enfim, esperou-se demonstrar que a prtica do gerenciamento de projetos de software uma necessidade e no um luxo para poucos. No se pode permitir que algum, argu mentando uma estratgia de economia de tempo ou outros recursos, suprima o planejamento e controle de seus projetos.

10 MATERIAIS E MTODOS

O presente estudo pode ser dividido em duas partes: pesquisa bibliogrfica e trabalho de campo. A pesquisa bibliogrfica foi feita atravs de material publicado, livros, artigos em peridicos e materiais disponibilizados na Internet. A segunda parte constituda de resultados obtidos em trabalho de campo, com entrevistas. O objeto do estudo foi abordado de forma qualitativa que, segundo Silva (2001), no requer o uso de mtodos e tcnicas estatsticas. O ambiente natural a fonte direta para a coleta de dados e o pesquisador o instrumento-chave. A coleta de dados foi feita por meio de entrevistas realizadas pelo prprio autor na forma escrita e individual. Foram entrevistados dois gerentes, o primeiro dirige uma empresa especializada em desenvolvimento de software e o segundo responsvel por todo o desenvolvimento de software de uma empresa multinacional de produtos qumicos. Tambm foram entrevistados trs desenvolvedores, dois deles trabalham com desenvolvimento de software em uma empresa aeronutica e o terceiro exerce a mesma funo em um instituto de pesquisa, todas as empresas referenciadas e o instituto de pesquisa esto localizados no Vale do Paraba. Todo o processo ocorreu nos meses de junho e julho de 2002 e cada entrevista durou cerca de uma hora. Para a entrevista foram elaborados dois roteiros, um primeiro direcionado aos gerentes responsveis pelo desenvolvimento de software e outro destinado aos desenvolvedores de programas, expostos abaixo. A entrevista com os gerentes de projeto contemplou os seguintes temas: caractersticas gerais de desenvolvimento de um projeto; equipes de trabalho; controle do projeto, ferramentas e mtricas; qualidade e problemas e dificuldades. As questes apresentadas foram dispostas como indicado a seguir: EVOLUO Em linhas gerais, como voc gerencia um desenvolvimento de software? EQUIPE voc quem define a equipe de desenvolvimento? Como esta definio feita? Quais os critrios? Voc acha importante a equipe conhecer o planejamento do projeto? CONTROLE Geralmente os projetos estouram nos prazos e custos ou no, eles so suficientes? Se hoje os projetos costumam terminar dentro do planejado,

houve algum momento que isto no acontecia? Como voc conseguiu mudar este cenrio? Voc acompanha o desenvolvimento de perto ou delega essa tarefa? Existe um replanejamento quando detectado um desvio no andamento do projeto?

FERRAMENTAS Quais ferramentas voc utiliza para planejar e controlar o desenvolvimento do projeto? Voc costuma montar um WBS? Como isto feito? Ele consegue oferecer uma viso do trabalho a ser desenvolvido? Como voc avalia os custos?

QUALIDADE Como voc valida o software? Voc se preocupa com a qualidade do software? Qual o grau de importncia que voc d a este aspecto? Voc utiliza alguma ferramenta para controlar a qualidade? Os pr -requisitos fornecidos pelo(s) cliente(s) costumam se alterar no decorrer do desenvolvimento? Pouco ou muito? Porque ou o que mais muda em um projeto? Que estratgia usada para colher estes dados?

DIFICULDADES Quais as dificuldades mais freqentes? Onde os softwares costumar apresentar mais problemas? Quando isto mais acontece? As alteraes sofridas durante o decorrer do projeto se do mais por causa de limitaes tcnicas (hardware,software) ou por conta do cliente? O que voc acha que poderia ser feito para melhorar o trabalho? Um segundo roteiro fo i elaborado para os desenvolvedores de software conforme descrito abaixo. Com relao aos desenvolvedores procurou-se abordar os seguintes temas: o relacionamento com seus gerentes; como as especificaes do projeto chegam at eles; se os recursos fornecidos, como cronograma e oramento, so suficientes para o desenvolvimento do trabalho; como se d a evoluo do projeto;

qualidade e aspectos de melhoria. As questes apresentadas foram dispostas como indicado a seguir: RELACIONAMENTO Voc participa de reunies de desenvolvimento durante o projeto? Somente entre os desenvolvedores ou o gerente tambm participa? Os gerentes costumam consultar os desenvolvedores antes de tomar decises que afete diretamente o trabalho? A comunicao da equipe com o gerente costuma ser receptiva? ESPECIFICAES Voc recebe a especificao de forma clara? Existe algum fator que geralmente no bem definido no planejamento (estudo do projeto, treinamento, equipamento etc.) ? Voc acha importante conhecer o planejamento do projeto? RECURSOS Voc costuma reutilizar cdigo? Quais ferramentas e metodologias de desenvolvimento voc utiliza? Geralmente o tempo especificado para o desenvolvimento realista? EVOLUO Os projetos costumam atrasar ou no? Se sim, onde e quando voc acha que ocorrem os atrasos? Durante o tempo em que voc est envolvido no projeto, voc tem mais contato com seu gerente ou voc tambm tem contato com os clientes? Existe algum momento em que voc se aproxima mais de algum dos dois lados?

QUALIDADE Voc conhece o CMM? Os softwares que voc desenvolve tm controle de qualidade? Como isto feito? LIES APRENDIDAS O que voc acha que poderia ser feito para melhorar o trabalho? Onde ou quando acontecem os problemas no sistema? Existem fatores externos que interferem no cronograma? Qual o grau de interferncia?

11 RESULTADOS DA PESQUISA

Nesta seo sero exibidas as informaes colhidas durante as entrevistas com os gerentes e os desenvolvedores de software . A estrutura das informaes ser disposta por temas de relevncia definidos mediante as respostas obtidas com cada grupo de entrevistados.

Gerentes de Desenvolvimento

Quanto aos gerentes de desenvolvimento, podemos analisar as informaes coletadas segundo os temas propostos conforme indicado a seguir. A definio de equipes um fator sobre o qual os gerentes preferem ter o controle. Ambos os entrevistados disseram que eles mesmos fazem as nomeaes e utilizam para isto critrios como a experincia anterior do profissional, a afinidade com a tecnologia que ser empregada ou ainda o perfil psicolgico frente a complexidade do projeto. Tambm concordam que muito importante que todos conheam bem o planejamento do projeto para que os trabalhos transcorram com sinergia. Quando perguntado sobre planejamento e controle pode-se notar que em ambos os casos tcnicas como o WBS no utilizado. O planejamento e controle so feitos utilizando softwares comerciais de gerenciamento auxiliado por ferramentas internas que satisfazem de forma mais abrangente a necessidade de cada negcio. Segundo os gerentes, os custos so avaliados conforme os resultados alcanados com base no planejamento. Foi citado que para melhorar a medio dos custos durante o desenvolvimento est sendo implantado o sistema de mtricas baseado em pontos de funo. Com relao evoluo do projeto os gerentes apresentaram respostas bem semelhantes: ambos possuem lderes de equipe que fazem o acompanhamento de forma mais presente junto aos desenvolvedores. Os dados obtidos por estes lderes so repassados para os gerentes que analisam e reportam a todos os dados que dizem respeito ao andamento do projeto. Ainda como tpico da evoluo do projeto, mais dois aspectos foram questionados, a definio de pr-requisitos e a validao do software. Novamente as respostas foram muito parecidas. Quanto ao primeiro aspecto ambos ressaltaram que

uma das grandes dificuldades no desenvolvimento so as definies dos clientes, que sofrem muitas alteraes durante todo o projeto, muitas vezes at por fatores externos, como mudanas na lei. Para minimizar estes efeitos est sendo usado um acompanhamento mais prximo no momento das definies atravs de analistas de processos. Eles conhecem bem o negcio da empresa e procuram junto aos clientes agregar benefcios nas solicitaes, evitando grandes mudanas. No que se refere a validao do produto, o processo consiste em duas etapas: a primeira feita durante o desenvolvimento, de forma tcnica, atravs de um plano de testes. Passada esta fase o produto testado e validado pela equipe de analistas de negcio, que definem se as funcionalidades implementadas satisfazem as necessidades. Outro tema discutido foi a questo da qualidade de software, e as opinies foram contraditrias, embora ambos a encarem como um fator importante. Apenas um dos gerentes entrevistados possui um processo para validao de qualidade; o outro ainda est definindo uma abordagem para este fim. Ao fim da entrevista com os gerentes foi perguntado o que eles teriam a dizer quanto a aspectos de melhoria para o desenvolvimento. A resposta foi unnime: o que est faltando so padres bem definidos de metodologia para documentao, formalizao e fluxo de informaes. A partir do momento em que estes fatores forem determinados planejamentos futuros podero ser mais bem administrados.

Desenvolvedores De Software

A entrevista com os desenvolvedores de software teve seis temas de discusso: o relacionamento com seus gerentes, as especificaes do projeto, recursos fornecidos, a evoluo do desenvolvimento, qualidade e tambm os aspectos de melhoria. O primeiro questionamento foi quanto ao relacionamento com os gerentes. Na maioria das respostas a relao entre as duas partes bem receptiva, existindo comunicao direta entre ambos quando alguma deciso que interfira em seus trabalhos deve ser tomada. Durante todo o desenvolvimento, porm, o contato maior com o cliente. Quando perguntado sobre como as especificaes do projeto chegavam a suas mos, uma palavra foi sempre citada: incompleta. Em todos os casos os dados para

o desenvolvimento no satisfazem s condies necessrias, o que faz com que novos requisitos apaream durante o ciclo de desenvolvimento. Um dos aspectos mais discutidos durante as entrevistas, foi a questo dos recursos disponveis para o desenvolvimento do trabalho. A grande maioria citou que o planejamento do tempo estimado para as atividades no realista, o que ocasiona freqentes atrasos no projeto. Conforme os entrevistados, dois momentos no so bem planejados: o estudo do projeto e o tempo de treinamento ao usurio. Outro ponto de descontentamento de alguns dos desenvolvedores com relao a compra de equipamentos, que por efeitos burocrticos muitas vezes demora a chegar ocasionando atraso no cronograma. Sobre a evoluo do desenvolvimento, os desenvolvedores tambm tiveram respostas muito semelhantes. Eles citaram que as mudanas de prioridade, entrada de novo requisitos e interferncias externas, principalmente quando necessria a atuao de outras reas envolvidas, so fatores que fazem com que a evoluo do projeto no transcorra de forma simples e constante. Assim como j questionado aos gerentes, tambm foi perguntado aos desenvolvedores sobre qualidade de software, nenhum dos entrevistados utiliza um processo definido pela empresa para o controle de qualidade, embora todos dizem conhecer a tcnica CMM. Ao final, foi perguntado o que poderia ser feito para melhorar o trabalho, e assim como a unanimidade apresentada pelo gerentes, os desenvolvedores citaram vrios fatores de melhoria, tais como, melhores especificaes de requisito por parte dos clientes, planejamentos mais precisos, padronizao e documentao.

12 ANLISE DOS RESULTADOS

Esta seo destina-se a estabelecer a compreenso dos dados coletados, confirmando ou no as informaes do estudo. Analisando os dados coletados durante as entrevistas e tomando por base a reviso bibliogrfica pode-se perceber que a realidade do desenvolvimento de software continua apresentando fatores crticos de impacto no projeto, porm pode-se notar que muitos esforos esto sendo feitos para melhorar este quadro. Dentre as constataes a que se chegou que ao contrrio do que as empresas que fabricam software para a gesto de projetos pensam, os gerentes do setor de informtica preferem utilizar programas proprietrios para a construo e controle de seus projetos. Isto ocorre pela falta de adaptabilidade dos sistemas comerciais em atender as necessidades deste negcio em particular. Pode-se notar que uma das grandes preocupaes e talvez onde, ironicamente, existe maior investimento no controle do custo do projeto, seja no aprimoramento dos softwares proprietrios citado acima ou atravs de utilizao de tcnicas para a estimativa de custos, em destaque a baseada em Pontos de Funo, descrita na seo 3.1.3, Anlise de Pontos de Funo. Outro aspecto de grande preocupao e impacto ao projeto, talvez a maior por sua interferncia em todo o processo, o estabelecimento de requisitos do cliente. Todos os entrevistados, de ambos os grupos citaram que freqentemente existem solicitaes de mudana na definio do projeto durante todo o desenvolvimento. Pode-se dizer que isto dado a dois principais fatores: o primeiro e mais complicado de se resolver, o esquecimento, e segundo a falta de experincia e conhecimento global do negcio por parte do cliente. Este segundo fator est sendo fortemente atacado colocando-se analistas de processo, que entendem do negcio como um todo, mais prximo ao cliente para que cada vez mais os requisitos de projetos se tornem mais refinados e completos. Se por um lado este um problema para os gerentes que tm que rearranjar o planejamento e suportar custos maiores, isto tambm duramente citado pelos desenvolvedores, os quais reclamam que na maioria das vezes, o atraso proporcionado por estas falhas tem que ser recuperado com os recursos existentes, no mesmo prazo anteriormente definido. claramente perceptvel que um dos fatores de maior discordncia entre os dois grupos entrevistados so os prazos estipulados para a entrega dos projetos. Os

desenvolvedores afirmam categoricamente que dificilmente o tempo disponvel para o trmino do trabalho suficiente, em contrapartida os gerentes afirmam, em meias palavras, que no existem atrasos relevantes conforme dito por um gerente quando questionado sobre o assunto, certamente que no estouram (os prazos) pois seno estaramos fechados. No me recordo de nenhum atraso considerado grave.... Ao contrrio do que ocorre com a questo do cronograma, quando se fala em qualidade de software a opinio de todos uma s, ...somos comprometidos com a qualidade. Embora este comprometimento esteja presente em todos os ncleos de desenvolvimento, ainda no existe uma grande agitao quanto a melhorias neste aspecto to cobrado pelo mercado na atualidade. Embora tcnicas como o CMM, citado na seo 2.2.1 e a NBR 13.596, que aborda as caractersticas de qualidade de um produto de software, ilustrado na seo 2.2.2, existam para o auxlio neste setor, nenhum dos entrevistados citou a utilizao da tcnica ou conhecimento da norma, o maior esforo neste sentido relatado por um gerente responsvel pela fbrica de software de uma empresa multinacional foi nossos desenvolvimentos passam por um processo de aprovao tcnica e funcional. Diante de todas as informaes coletadas pode-se concluir em uma palavra o que est faltando para evitar tantos conflitos e desencontros existentes neste setor, organizao. possvel notar esta deficincia atravs das respostas obtidas diante do questionamento sobre aspectos de melhoria, onde todos os participantes da pesquisa citaram fatores como, definio de padres e melhor documentao. Poucas aes como estas poderiam fornecer informaes mais consistentes, para que todas as etapas do projeto seguissem por caminhos menos tortuosos e traumticos. O que pode-se notar que os projetos em questo parecem ser conduzidos sem muito conhecimento especfico, ou muitas vezes sem a importncia que deveriam possuir. As deficincias no gerenciamento comeam desde os aspectos bsicos do projeto, como por exemplo no gerenciamento do escopo do projeto, onde a ferramenta WBS citada na seo 5.1.1 dita essencial pelos estudiosos e escritores do ramo, no utilizada dentro do plano do projeto, comprometendo a viso global do desenvolvimento. Em se tratando do mbito tcnico do estudo as falhas so ainda maiores, as metodologias aplicadas a software muitas vezes no so bem definidas, as tcnicas para definio de pr-requisitos so raramente utilizadas e os padres e mtodos existentes para a garantia da qualidade do software no so seguidos. Espera-se que o aumento de cobrana do mercado sobre este setor faa com que estes aspectos negativos da gerncia de projetos de software sejam sanados em curto prazo.

13 CONCLUSO

Este trabalho permitiu concluir que a rea de gerenciamento de projetos de software dispe no apenas das ferramentas comuns e disponveis para os gerentes de projeto, mas tambm de um conjunto importante de ferramentas e tcnicas especficas, adaptadas especialmente ao desenvolvimento de projetos de software. Entre essas ferramentas e tcnicas encontram-se mtricas prprias para avaliao a priori da complexidade do projeto, o que permite um me lhor planejamento do mesmo, e tambm mtricas de acompanhamento (controle) da evoluo do projeto. Alm disso, foram apresentados modelos especficos para diagnstico e melhorias na rea de qualidade de software, tanto como produto quanto como processo de desenvolvimento, j estabelecidos na forma de normas de qualidade. Entretanto, o trabalho de campo permitiu mostrar que, se as ferramentas existem e so bem documentadas, elas tm pouca penetrao junto aos responsveis pelos projetos de software, pelo menos na amostra pesquisada na regio do Vale do Paraba. Nesse caso, pode-se perceber que, embora gerentes de projeto estejam cientes da existncia e da necessidade do uso dessas ferramentas, a implantao das mesmas na realidade dos projetos ainda bastante precria, apesar dos esforos e avanos que se pode perceber. Dentro os vrios aspectos que podem causar impactos negativos no desenvolvimentos dos projetos de software, pode-se concluir, a partir das anlises feitas, que a falta de definies claras sobre os requisitos do cliente talvez o fator crtico. Uma definio deficiente desses requisitos leva no apenas a um planejamento deficiente da complexidade do projeto (e, conseqentemente, do tempo, dos custos e de outros recursos) como tambm necessidade de alteraes futuras, no planejadas, devido a caractersticas e funes de interesse do cliente que no foram originalmente includas nesses requisitos. Um ponto discordante no discurso dos entrevistados, e que merece destaque, diz respeito ao cumprimento de prazos. Enquanto gerentes minimizam possveis problemas nessa rea, os desenvolvedores de sistemas sos claros ao afirmar a existncia do problema e ao indicar sua origem: falta de definio clara dos requisitos do cliente e sub-avaliao da complexidade do projeto. De um modo geral, parece haver um consenso entre os envolvidos nos projetos de software sobre a necessidade de melhor documentao das atividades do projeto, gerando uma memria confivel que possa servir de base para desenvolvimentos futuros. Essa conscincia e a divulgao, que comea a crescer, das ferramentas gerenciais (em especial para projetos de software), alm das presses do mercado, sinalizam para uma mudana de rumo e um melhor aproveitamento das tcnicas de gerenciamento hoje disponveis.

REFERNCIAS BIBLIOGRFICAS

BOEHM, B. W. Software engineering economics. New Jersey: Prentice-Hall, 1981. ISBN 0-13-822122-7. EUROPEAN SPACE AGENCY (ESA). Guide to software project management . The Netherlands: ESA Publications Division, 1994. Issue 1. ISSN 0379-4059. EUROPEAN SPACE AGENCY (ESA). Software engineering standards . The Netherlands: ESA Publications Division, 1991. Issue 2. ISSN 0379-4059. GASNIER, D. G. Guia prtico para gerenciamento de projetos: manual de sobrevivncia para os profissionais de projetos. So Paulo: IMAM, 2000. 1. ed. GOMES, A. E. Mtricas e Estimativas de Software: O Incio de um Rallye. Developers Cio Magazine , Rio de Janeiro, ano 4 n. 39, p. 50-53, nov. 1999. MAXIMIANO, A. C. A. Administrao de projetos: como transformar idias em resultados. So Paulo: Atlas, 1997. ISBN 85-224-1735-0. PMI. Project management body of knowledge. Minas Gerais: Pmi, 2000. Disponvel em: <http://www.pmimg.org.br/pmbok.html>. Acesso em: 23 ago.2001. SANTANA, M. L.; GUERRA, A. C. Qualidade de Produto ou Qualidade de Processo de Software?. Developers Cio Magazine , Rio de Janeiro, ano 6 n.68, p. 21-23, abr. 2002. SELNER, C. Anlise de requisitos para sistemas de informaes, utilizando as ferramentas da qualidade e processos de software . 1999. Dissertao (Mestrado em Engenharia de Produo) - Programa de Ps-graduao em Engenharia de Produo, Universidade Federal de Santa Catarina, Santa Catarina. Disponvel em: <http:// www.eps.ufsc.br/disserta99/selner/intro.html>. Acesso em: 15 jan. 2002. SILVA, E. L.; MENEZES, E.M. Metodologia da pesquisa e elaborao de dissertao. 2001. Laboratrio de Ensino a Distncia da Universidade Federal de Santa Catarina, Santa Catarina. Disponvel em: <http://www.arquivologia.ufsm.br/ daniel/Projetos/MetodologiadaPesquisa3aedicaoPPGEP.UFSC.pdf>. Acesso em: 26 jan. 2002. VALERIANO, D. L. Gerncia em projetos (pesquisa, desenvolvimento e engenharia). So Paulo: Makron Books, 1998. ISBN 85-346-0709-5. YOURDON, E. Managing the system life cycle . New Jersey: Prentice-Hall, 1988. ISBN 0-13-547530-9.