Gerência do Tempo em Projetos de Software

Transcrição

1 UNIVERSIDADE FEDERAL FLUMINENSE LATEC - Laboratório de Tecnologia, Gestão de Negócios e Meio Ambiente Gerência do Tempo em Projetos de Software Monografia apresentada no curso MBA em Gerência de Projetos LATEC UFF como requisito para obtenção do diploma de especialista. Dário Loureiro Marcello Doederlein Polito Márcio Mangorra Orientador: Prof. Mário Sampaio Niterói RJ 2006

2 FOLHA DE APROVAÇÃO

3 AGRADECIMENTOS Ao nosso orientador, Prof. Mário Sampaio, que nos apoiou neste trabalho e sempre se prontificou a nos atender a qualquer momento. A todos os professores do curso que nos deram conhecimento para o engrandecimento das nossas vidas profissionais. A todos os amigos e amigas da GPR4 que tornaram as aulas e os almoços sempre agradáveis. À funcionária Tânia Regina Gomes da Silva que sempre nos atendeu com presteza, nos dando todo o apoio necessário. Aos funcionários do LATEC que contribuíram para que a infra-estrutura do curso estivesse sempre adequada para o bom andamento das aulas. E, finalmente, agradecemos às nossas famílias que, durante os vários finais de semana onde estivemos ausentes de nossos lares, nos apoiaram e nos incentivaram para atingirmos nosso objetivo.

4 RESUMO Em projetos de software, o tempo é sempre visto como uma incógnita. Planejar e controlar o prazo de um projeto de software é uma tarefa difícil e que nem sempre fornece o resultado desejado. Por ser o software um elemento maleável e de difícil medição, torna-se árduo o cumprimento do prazo estimado. Por meio de pesquisa bibliográfica, este trabalho tem por objetivo abordar fatores que possam influenciar no prazo de projetos de software, apontando causas e soluções para a melhoria da gerência do tempo neste tipo de projeto. Os resultados deste trabalho indicam que o tempo em projetos de software está relacionado a diversas áreas do gerenciamento de projetos. Palavras-chave: Gerenciamento de projeto. Projeto de software. Gerência do tempo.

5 ABSTRACT Time in software projects is always a mystery. Planning and controlling the time in software projects is a hard task so that the software projects almost never finish on time. Since softwares are extremely flexible and because we cannot measure then easily, the project estimated time is not reached frequently. Through the bibliographical research, the goal of this work is to show elements that can influence the time in software projects, finding out problems and solutions so as to improve project management in software projects. Final results show that time in software projects is related to many project management areas. Keywords: Project management. Software Project. Time management.

6 SUMÁRIO 1. INTRODUÇÃO O PROBLEMA OBJETIVOS AS QUESTÕES ENVOLVIDAS JUSTIFICATIVA DELIMITAÇÃO DO TRABALHO METODOLOGIA ESTRUTURA DO TRABALHO O TEMPO CONSIDERAÇÕES FILOSÓFICAS SOBRE O TEMPO O Tempo Absoluto A Visão Grega O Tempo Relativo A Visão Moderna O Tempo Subjetivo A Visão Subjetiva (Santo Agostinho) O Tempo como um fluxo A Visão de Henri Bergson UMA REFLEXÃO QUANTO AO TEMPO GERENCIAMENTO DE PROJETOS E O TEMPO Conceituação Gerência do Tempo do Projeto O Gerenciamento do Tempo nas demais áreas do conhecimento PROJETOS DE SOFTWARE PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE MODELOS DE DESENVOLVIMENTO DE SOFTWARE... 41

7 4. ESTIMATIVAS DE TEMPO EM PROJETOS DE SOFTWARE MEDIÇÃO DO TAMANHO E ESTIMATIVA DE UM SISTEMA DE SOFTWARE CONSTRUÇÃO DO CRONOGRAMA FATORES QUE AFETAM O PRAZO EM PROJETOS DE SOFTWARE PLANEJAMENTO E CONTROLE DO CRONOGRAMA ESCOPO RECURSOS HUMANOS COMUNICAÇÃO RISCOS CUSTOS QUALIDADE INTEGRAÇÃO SÍNTESE DOS FATORES RELACIONADOS AO PRAZO PROPOSTAS PARA A MELHORIA DA GERÊNCIA DO TEMPO FATORES INFLUENCIADORES CRITICAL CHAIN PROJECT MANAGEMENT (CCPM) AGILE PROJECT MANAGEMENT (APM) BOAS PRÁTICAS CONSIDERAÇÕES FINAIS CONCLUSÃO REFERÊNCIAS... 82

8 8 1. INTRODUÇÃO 1.1 O PROBLEMA Devido à abrangência de tecnologia existente no mercado, às diversas formas de modelagem de sistemas e aos diversos tipos de linguagens de programação, tornam-se difíceis estimativas de tempo precisas em projetos de software. O tempo sempre foi um fator importante em projetos. Tanto é que a própria definição de projeto faz referência ao tempo, pois projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (PMBOK, 2004, p. 5). Portanto, todo projeto deve ter uma data de início e uma data de término bem definidas. As empresas não mais podem se dar ao luxo de não levar o tempo em consideração ou considerá-lo em um patamar de pouca significância. Projetos que possuam estimativas precisas de tempo dão às empresas a capacidade de tornar seu planejamento estratégico cada vez mais eficaz. Uma pesquisa realizada pelo PMI do Rio de Janeiro, no seu relatório Estudo de Benchmarking em Gerenciamento de Projetos 2005, mostra em determinados itens que o prazo é um fator de preocupação das empresas com relação aos projetos. Com relação ao aspecto mais considerado nos planejamentos de projetos, o prazo é citado como o mais relevante, sob uma perspectiva geral. Sob uma perspectiva de setor, as empresas de Tecnologia da Informação entrevistadas colocaram o prazo e o escopo como máxima relevância.

9 9 Figura 1 - Aspectos mais considerados no planejamento de projetos sob uma perspectiva geral. Fonte: Project Management Institute seção Rio de Janeiro Estudo de Benchmarking em Gerenciamento de Projetos 2005 Figura 2 - Aspectos mais considerados no planejamento de projetos sob uma perspectiva por setor. Fonte: Project Management Institute seção Rio de Janeiro Estudo de Benchmarking em Gerenciamento de Projetos 2005 A pesquisa mostra também que, sob uma perspectiva geral, o não cumprimento dos prazos estabelecidos é o fator mais citado com relação aos problemas que ocorrem com maior freqüência nos projetos. Sob uma perspectiva de setor, as empresas de Tecnologia da Informação são as que mais se preocupam com as estimativas erradas de prazo e com o não cumprimento dos prazos estabelecidos.

10 10 Figura 3 - Problemas que ocorrem com maior freqüência nos projetos sob uma perspectiva geral. Fonte: Project Management Institute seção Rio de Janeiro Estudo de Benchmarking em Gerenciamento de Projetos 2005 Figura 4 - Problemas que ocorrem com maior freqüência nos projetos sob uma perspectiva por setor. Fonte: Project Management Institute seção Rio de Janeiro Estudo de Benchmarking em Gerenciamento de Projetos OBJETIVOS O objetivo geral deste trabalho é estudar os processos de gerenciamento do tempo especificamente em projetos de software. Os objetivos específicos deste trabalho visam:

11 11 abordar métodos e ferramentas usados para as estimativas e controle do tempo em projetos de software; apontar fatores que, de forma direta ou indireta, afetam o prazo em projetos de software; propor melhorias para o gerenciamento do tempo em projetos de software. 1.3 AS QUESTÕES ENVOLVIDAS O Standish Group, empresa localizada em Massachusetts, EUA, publica desde 1994 um relatório chamado CHAOS Report, onde são colocadas informações sobre levantamento de projetos na área de tecnologia da informação. O CHAOS Report de 2000 mostra que, em média, os projetos gastam 63% de tempo a mais para terminarem. Por isso, um controle eficaz do tempo é um dos pontos chaves para o sucesso de projetos de software. Fatores impactantes do tempo tais como escopo, controle de mudanças, motivação da equipe e produtividade são abordados neste trabalho. 1.4 JUSTIFICATIVA A expectativa tanto por parte do cliente quanto por parte da gerência sênior para que o projeto termine dentro do prazo desejado é uma das grandes pressões sofridas pelo Gerente de Projeto. Cabe ao mesmo saber lidar com tal pressão e saber planejar, executar e controlar adequadamente o projeto ao qual foi designado. 1.5 DELIMITAÇÃO DO TRABALHO

12 Este trabalho foca primariamente o planejamento e controle do tempo em projetos de software. Porém, questões como escopo, custo e qualidade não podem ser esquecidos dentro do universo de gerenciamento de projetos. Técnicas e ferramentas de planejamento e controle do tempo em projeto de software são abordadas neste trabalho. Por fim, é feito um resumo das questões a serem levadas em consideração quando se coloca o tempo como a principal restrição em projetos de software METODOLOGIA Este trabalho foi feito baseado em uma pesquisa bibliográfica realizada em bibliografias relacionadas a gerenciamento de projetos e engenharia de software, artigos publicados em revistas especializadas em gerenciamento de projetos, artigos publicados na internet, monografias e dissertações. 1.7 ESTRUTURA DO TRABALHO O capítulo 2 do presente trabalho aborda os conceitos de tempo e da gerência do tempo. No capítulo 3 são abordados os processos e os principais modelos envolvidos no desenvolvimento de software. O capítulo 4 dispõe sobre as técnicas usadas nas estimativas das atividades dos projetos de software. No capítulo 5 são mostrados os principais fatores que afetam, diretamente ou indiretamente, o prazo em projetos de software. No capítulo 6 é feito uma análise do exposto nos capítulos anteriores, listado fatores que podem acarretar atrasos nos projetos e propomos que determinados pontos sejam observados para uma melhor gerência do tempo. Além disso, no capítulo 6, são mostradas duas abordagens para a melhora da gerência do tempo: CCPM (Critical Chain Project Management) e APM (Agile Project Management).

13 13 2. O TEMPO 2.1 CONSIDERAÇÕES FILOSÓFICAS SOBRE O TEMPO Como se define o tempo? Não se tem uma única definição precisa e imediata sobre o tempo e em razão disto é fato que esta questão tem intrigado os filósofos desde a antiguidade, gerando considerações interessantes a respeito como as visões grega, moderna e subjetiva O Tempo Absoluto A Visão Grega Segundo Platão, o tempo é uma idéia, uma abstração. A noção de tempo é de absoluto, o tempo de Deus. Aristóteles retifica e torna mais precisa a visão platônica ao associar o tempo a uma teoria do movimento. Não se tem no presente um sentido que nos forneça a percepção direta do tempo. Essa percepção está associada à percepção de movimento, isto é, das distintas posições no espaço ocupadas por um mesmo objeto ao longo de uma outra dimensão que se chama tempo. Essa analogia com as dimensões do espaço parece natural. Forma-se a idéia do antes e do depois atribuindo ao tempo uma dimensão linear constante, com uma direção única e irreversível do passado, através do presente indo para o futuro. Os gregos criaram a geometria baseada numa noção abstrata do espaço composta por entes geométricos: planos, retas, pontos. Por analogia, percebe-se o tempo como uma quarta dimensão necessária para descrever o movimento. Então, espaço e tempo se tornam entes geométricos, nos quais as coisas e os acontecimentos estão contidos. As dimensões de espaço e tempo são infinitas em dois sentidos. Num sentido elas não têm começo nem fim. No outro

14 sentido, uma reta pode ser subdividida infinitamente em segmentos cada vez menores, sem nunca chegar ao elemento geométrico básico do espaço que seria o ponto. Tem-se aí o paradoxo. O espaço tem por característica essencial (atribuída pela nossa percepção) a extensão das coisas e assim do próprio espaço. Porém, o elemento primário do espaço geométrico é um ponto que não tem extensão em si. Da mesma forma, a característica essencial do tempo é a duração. Mas o elemento básico do tempo é um instante que não dura. Como fazer então para pensar num todo composto de elementos que não possuem justamente a principal característica deste todo? Para Platão o tempo é esta quarta dimensão que está lá, absoluta, eterna e imutável. Muitos mantêm esta noção de tempo que se baseia nas coordenadas que vai de menos infinito a mais infinito. Portanto, o tempo é denominado morfologicamente (pela forma como o vimos) como um substantivo, sendo, portanto, uma coisa em si. Esta concepção do tempo como uma dimensão eterna e absoluta independente das coisas a cujo movimento serve de medida, permanece também em Aristóteles e segue na filosofia ocidental também através de Newton que relativiza o espaço, mas postula a necessidade de um tempo absoluto que sirva de medida ao movimento (SANTOS, MALUF et al., 2004). A analogia da reta ajuda a entender muitos aspectos do tempo e é bastante instrumental. Mas será que entender o tempo como uma coisa em si mesmo que abstrata, não gera confusões e enganos ao se lidar com ele? O Tempo Relativo A Visão Moderna Foi Gottfried Wilhelm Leibniz filósofo e matemático contemporâneo de Newton, no século XVII o primeiro a questionar a visão do tempo como dimensão absoluta e eterna e formulou a concepção relativista de que tempo não é uma coisa, mas sim o acontecer das

15 coisas. Para Leibniz, o tempo é mais um verbo do que um substantivo, isto é, o tempo deixa de ser uma coisa absoluta que existe independentemente das outras coisas. A noção de tempo dependerá de que existam coisas e que estas coisas mudem, pois sem a ocorrência de eventos (sucessão de acontecimentos) não há tempo. Ou seja, sem as coisas ali colocadas, um ponto no espaço não difere de outro, nem um instante no tempo não difere de outro se não houver a sucessão destes instantes. Para Leibniz o tempo nada mais é do que a seqüência dos eventos. E evento é qualquer mudança de estado de qualquer coisa. Há duas classes de eventos: os objetivos e os subjetivos. Os eventos objetivos implicam sempre num tipo de movimento ditado pelo tempo do Universo, já, portanto, determinados. Não podem ser controlados ou administrados por serem movimentos involuntários. Os eventos subjetivos são peculiares a cada um e somente são observados pela mente que os experimenta, seja este fruto de idéias, emoções e sentimentos. São operações resultantes de sinapses cerebrais, mas nem por isso podem ser reduzidos a simples movimentos ou previsíveis. Este tempo é o da interação de cada mente com o mundo objetivo, marcando a experiência da vivência do tempo. Para esses eventos subjetivos, o grau de controle é bem razoável e a qualidade da vida é dada exatamente pela intensidade e valoração (positiva ou negativa) desta classe de eventos. A Teoria da Relatividade Geral de Einstein no século XX veio a confirmar a noção de Leibniz do tempo como sucessão de eventos, ao prever matematicamente e provar experimentalmente que as dimensões espaciais são alteradas pelo tempo, que é também uma grandeza relativa. O tempo, em Platão, é um tempo ideal (o Tempo de Deus). O tempo, em Leibniz, é o tempo das coisas (o Tempo do Universo). 15

16 O Tempo Subjetivo A Visão Subjetiva (Santo Agostinho) Santo Agostinho se questiona sobre a visão do tempo como algo perceptível objetivamente e conclui que o tempo é algo inteiramente subjetivo. Ele questiona a existência do passado, que não mais existe e sim a memória deste, de um evento ocorrido (o presente do passado). É a mente que guarda na memória o conhecimento de um evento acontecido. Ele também questiona a existência do futuro, que para ele nada mais é do que uma expectativa (o presente do futuro). O futuro é sempre imaginado, o que varia é o grau de probabilidade calculado pela nossa mente com base nos conhecimentos das leis de causa e efeito. Esse conhecimento pode nos dar a noção de certeza em relação ao futuro, criando a noção presente de que ele é real e que existe (SANTOS, MALUF et al., 2004). Ele novamente questiona, agora sobre a existência do presente. Como pode existir se ao nos conscientizarmos deste instante agora, este já nos fugiu e virou passado imediatamente (o presente do presente)? Se o presente permanecesse sempre presente e não se tornasse passado, não se teria mais tempo e sim eternidade, por sua constância. Santo Agostinho determina que esses três tempos (passado, presente e futuro) somente existem no nosso espírito e em nenhum outro lugar. Sendo o presente do passado (a memória); o presente do presente (a atenção); o presente do futuro (a expectativa). Portanto tempo só existe na mente e não há tempo objetivo O Tempo como um fluxo A Visão de Henri Bergson Quando nos perguntamos o que é o agora, a resposta nunca é a noção de um instante etéreo. A noção de presente envolve uma situação que dura, que integra o passado imediato ao futuro iminente. O fato é que o agora é hoje e dura 24 horas. O presente então é um momento com duração (gordo de passado e grávido de futuro). O presente dura enquanto passa.

17 Para Bergson (filósofo francês do início do século XX) ver o tempo apenas como uma sucessão de eventos é uma analogia espacial, quantitativa e fragmentada. Um evento isolado nada mais é do que uma operação mental sem correspondência na nossa vivência do tempo e por ser isolado, não existe. O que existe é um fluxo de movimentos e sensações. A verdadeira percepção do tempo é a de um fluxo contínuo e permanente como algo que dura. Esta noção é irredutível a grandezas mensuráveis e é apreensível apenas por intuição. A crítica de Bergson na visão de Leibniz desloca a consideração do instante, do momento, isto é, do fracionamento do tempo-movimento-no-espaço, para um plano secundário. Bergson concebe o tempo como movimento-fluxo, como processo contínuo e essencialmente uno, como um vir-a-ser-permanentemente, porém sempre contingente. A verdadeira essência do tempo é a apreensão imediata e intuitiva de um eterno fluir, de algo que dura, dentro e fora de cada um de nós. O tempo é a própria duração. A ênfase de Bergson na duração como aspecto primordial do tempo e no caráter de mudança e permanente desta, não deve ser confundido com a analogia espacial da visão clássica do tempo como uma dimensão permanente e imóvel. Duração é uma percepção subjetiva com intensidade de experiência mais do que medida objetiva. Um minuto de dor dura mais do que um minuto de distração. Isto é, toda dimensão subjetiva é dimensionada pela intensidade das emoções experimentadas mais do que pela quantidade de eventos contados racional e objetivamente. É este encadeamento de sensações que constitui a duração. A duração é a sucessão das mudanças qualitativas dos nossos estados de consciência que fundem sem contornos precisos e sem possibilidades de medição. O que se tira destas visões é que Amar a vida é amar o tempo. Tempo é aquilo do que a vida é feita, como disse Benjamin Franklin. O tempo é muito mais que um recurso 17

18 meramente econômico. O tempo é vida. Portanto, administrar o tempo de forma eficaz é viver bem e ser feliz UMA REFLEXÃO QUANTO AO TEMPO Segundo Biondillo (2005), constantemente ouvimos várias reclamações a respeito da falta de tempo. Uma das frases mais proferidas pela grande maioria das pessoas ao redor do mundo é: não tenho tempo. Muito estranho que assim seja, pois se há uma coisa que todos nós temos é exatamente tempo. Podemos não ter saúde, dinheiro, relacionamentos, mas tempo nós temos. Nem que seja para desperdiçá-lo com as preocupações. Pode-se achar meio forte a afirmação acima, mas é exatamente assim que as colocações sobre não ter tempo o tempo todo podem estar começando a se mostrar. Já se cogita inclusive a possibilidade de se classificar essa quase epidemia cosmopolita de falta de tempo crônica como um distúrbio comportamental. Essa situação global nos leva a questionar sobre o fato de que o problema central não é a falta de tempo em si, mas a maneira como vivenciamos e utilizamos nosso tempo. Existe uma seletividade natural inerente a cada indivíduo e priorizar esse processo seletivo deveria ser uma constante na vida, pois no fundo, todos nós sabemos o que é melhor fazer com esse tempo que nos foi concedido entre o nascimento e a morte. Mas escolher o que fazer com o seu tempo obedece a uma ordem que alia tendências e necessidades especiais e individuais, muita responsabilidade e grande dose de renúncia. Não é apenas o tempo cronológico (do relógio e dos calendários) que conta, mas o tempo psicológico: um tipo de tempo que é percebido apenas individualmente e é diferente de pessoa para pessoa. Como exemplo pode-se citar a mãe de um recém-nascido. Sabe-se de antemão que 80% do seu tempo será dedicado ao seu filho, pois é uma prioridade essencial, hereditária e naturalmente pré-selecionada, mas esta mesma mãe pode-se questionar a quantas andam sua

19 percepção, suas sensações e seus sentimentos em relação à utilização desse tempo cronológico. Essa é a única maneira de não se deixar contaminar por padrões préestabelecidos de como se deve utilizar o nosso tempo e em especial nosso tempo livre. Esses padrões sugerem que se deve usar todo o nosso tempo de modo a estar sempre produzindo seja lá o que for e de preferência de modo frenético e ininterrupto. Estamos vivendo uma época em que o movimentar-se muito foi confundido com o movimentar-se bem; em que o fazer muito foi confundido com o fazer bem; em que o saber quase nada sobre muita coisa foi confundido com o saber bem e profundamente sobre alguma coisa. Mas o mais caótico seja o fato de já termos há muito tempo confundido os períodos em que não temos nada para fazer com períodos de perigosa ociosidade, obtusidade, falta de iniciativa, de competência e de inteligência. Afinal, pior do que ter tempo para nada é ter tempo e não ter nada para fazer GERENCIAMENTO DE PROJETOS E O TEMPO Você ama a vida? Então não desperdice tempo, pois é dele que a vida é feita. (Benjamin Franklin) Conceituação Há uns 4,5 mil anos, os egípcios começaram a construção da pirâmide de Quéops. Heródoto, historiador grego, escreveu que essa pirâmide tomou 20 anos do trabalho de 100 mil camponeses. Empilharam só nessa pirâmide, 2,3 milhões de blocos de granito e de pedra calcária que pesavam em média 2,5 toneladas. Foi um dos primeiros projetos de que se tem notícia. Hoje, as empresas modernas têm à disposição projetos cujo gerenciamento sofisticouse, transformando-se quase em uma ciência.

20 Segundo Barcaui (2006), gerenciamento de projetos é assunto sério. Muito se investe em treinamento, processos, ferramentas e estruturas, para aumentar a maturidade de um ambiente de gerenciamento. Mas ainda é possível observar uma série de problemas ligados a essa prática. Muitos deles estão relacionados a uma das variáveis mais imponderáveis e implacáveis de todas: o tempo. Uma verdade incontestável de nossos tempos: projetos atrasam. É difícil quantificar ao certo o custo do atraso. Mas é certo que existe um custo e é certo também que atrasos geram insatisfação. Quanto mais se atrasa um projeto, mais lentamente se obtém o resultado esperado. Em muitos casos isso pode significar a perda de uma oportunidade ou até de um determinado mercado. Muitas vezes o gerenciamento de projetos é confundido com gestão de ferramentas. Muitas empresas começam a investir em sofisticadas ferramentas de software para controle de cronograma e se dizem preparadas para gerenciar projetos. De fato, as empresas estão cada vez mais poderosas e controlando muito mais do que o cronograma. São capazes de controlar todo o portfólio de projetos da empresa, mas não funcionam sozinhas. De nada adianta a melhor ferramenta sem o devido processo e o devido treinamento conceitual do que é gerenciamento de projetos. Gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle, e encerramento. Gerenciar um projeto inclui identificação das necessidades, estabelecimento de objetivos claros e alcançáveis, balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo, adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas (PMBOK, 2004). 20

21 Gerência do Tempo do Projeto De acordo com o PMBOK (2004), o gerenciamento de tempo do projeto inclui os processos necessários para realizar o término do projeto no prazo. A figura a seguir fornece uma visão geral dos processos de gerenciamento de tempo do projeto. Figura 5 - Visão geral do gerenciamento de tempo do projeto. Fonte: Adaptado de PMBOK (2004).

22 22 Os processos de gerenciamento de tempo do projeto incluem os seguintes passos: Definição da Atividade A definição das atividades do cronograma envolve identificar e documentar o trabalho planejado para ser realizado. O processo Definição da atividade identificará as entregas no nível mais baixo da estrutura analítica do projeto (EAP), os quais são chamados de pacotes de trabalho. Os pacotes de trabalho do projeto são planejados (decompostos) em componentes menores, chamados de atividades do cronograma, para fornecer uma base para a estimativa, elaboração de cronogramas, execução, e monitoramento e controle do trabalho do projeto. A definição e o planejamento das atividades do cronograma de forma que os objetivos do projeto sejam atendidos estão implícitos neste processo. Figura 6 - Definição da atividade: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004).

23 Seqüenciamento de Atividades O seqüenciamento de atividades envolve a identificação e documentação dos relacionamentos lógicos entre as atividades do cronograma. As atividades do cronograma podem ser seqüenciadas logicamente usando as relações de precedência adequadas, além de antecipações e atrasos, para dar suporte ao desenvolvimento posterior de um cronograma do projeto realista e alcançável. O seqüenciamento pode ser realizado usando um software de gerenciamento de projetos ou técnicas manuais. As técnicas manuais e automatizadas também podem ser usadas em conjunto. Figura 7 - Seqüenciamento de atividades: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004) Estimativa de Recursos da Atividade A estimativa de recursos da atividade do cronograma envolve determinar os recursos (pessoas, equipamentos ou material) e as quantidades de cada recurso que serão usados e quando cada recurso estará disponível para realizar as atividades do projeto.

24 24 Figura 8 - Estimativa de recursos da atividade: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004) Estimativa de Duração da Atividade O processo de estimativa de durações das atividades do cronograma usa as informações sobre: escopo de trabalho da atividade do cronograma, tipos de recursos necessários, estimativas das quantidades de recursos e calendários de recursos com as disponibilidades de recursos. As entradas das estimativas de duração da atividade do cronograma se originam da pessoa ou do grupo da equipe do projeto que está mais familiarizado com a natureza do conteúdo do trabalho na atividade do cronograma específica. A estimativa de duração é progressivamente elaborada e o processo considera a qualidade e disponibilidade dos dados de entrada. Por exemplo, conforme a engenharia do projeto e o trabalho de design se desenvolvem, dados mais precisos e detalhados ficam disponíveis e a exatidão das estimativas de duração aumenta. Dessa forma, a estimativa de duração pode se tornar cada vez mais exata e de melhor qualidade. O processo Estimativa de duração da atividade exige que a quantidade de esforço de trabalho necessária para terminar a atividade do cronograma seja estimada, que a quantidade prevista de recursos a ser aplicada para terminar a atividade do cronograma seja estimada e

25 que o número de períodos de trabalho necessário para terminar a atividade do cronograma seja determinado. Todos os dados e premissas que dão suporte à estimativa de duração são documentados para cada estimativa de duração da atividade. A estimativa do número de períodos de trabalho necessário para terminar a atividade do cronograma pode exigir que se considere o tempo decorrido como um requisito relacionado ao tipo específico de trabalho. A maioria dos softwares de gerenciamento de projetos para elaboração de cronogramas lidará com essa questão usando um calendário de projeto e calendários de recursos de período de trabalho alternativos que geralmente são identificados pelos recursos que exigem períodos de trabalho específicos. As atividades do cronograma serão trabalhadas de acordo com o calendário de projeto e as atividades do cronograma para as quais os recursos estão atribuídos também serão trabalhadas de acordo com os calendários de recursos adequados. A duração total do projeto é calculada como uma saída do processo Desenvolvimento do cronograma. 25 Figura 9 - Estimativa de duração da atividade: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004).

26 Desenvolvimento do Cronograma O desenvolvimento do cronograma do projeto, um processo iterativo, determina as datas de início e término planejadas das atividades do projeto. O desenvolvimento do cronograma pode exigir que as estimativas de duração e as estimativas de recursos sejam reexaminadas e revisadas para criar um cronograma do projeto aprovado que possa servir como uma linha de base em relação a qual o progresso pode ser acompanhado. O desenvolvimento do cronograma continua durante todo o projeto conforme o trabalho se desenvolve, o plano de gerenciamento do projeto se modifica e os eventos de risco esperados ocorrem ou desaparecem à medida que novos riscos são identificados. Figura 10 - Visão geral do desenvolvimento do cronograma: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004). Dentre as técnicas e ferramentas para o cálculo das datas de início e fim das atividades - respeitando as limitações de recursos e de outras restrições conhecidas - as mais conhecidas são: Método do Caminho Crítico (CPM Critical Path Method);

27 27 Avaliação Gráfica e Revisão Técnica (GERT Graphical Evaluation and Review Technique); Programa de Avaliação e Revisão Técnica (PERT Program Evaluation and Review Technique). É também nesta fase que se faz a análise de redução do cronograma sem o comprometimento do escopo do projeto. Pode-se comprimir a duração através de técnicas como o crashing que geralmente resulta em aumento de custo e, por isso, deve ser analisado como obter a maior compressão com o mínimo aumento de custo e o fast tracking onde atividades que normalmente seriam realizadas em seqüência passam a ser realizadas em paralelo, geralmente gerando retrabalho e aumento de risco. Outras técnicas úteis para a análise de redução do cronograma, como o Nivelamento Heurístico dos Recursos e as Simulações (a mais comum é a Análise de Monte Carlo) são feitas por softwares amplamente utilizados, o que permite uma avaliação rápida sobre diversas alternativas de cronograma. Assim, o Cronograma do Projeto precisa ser desenvolvido com base em dados bastante realistas e analisado no sentido da compressão da duração do projeto sem prejuízo de aspectos de outras disciplinas (por exemplo, custo e qualidade) Controle do Cronograma Controle das mudanças no cronograma do projeto. Esses processos interagem entre si e também com processos de outras áreas de conhecimento. Cada processo pode envolver o esforço de uma ou mais pessoas ou de grupos de pessoas, com base nas necessidades do projeto. Cada processo ocorre pelo menos uma vez em todos os projetos e ocorre em uma ou mais fases do projeto, se o projeto estiver dividido em fases. Embora os processos sejam

28 apresentados aqui como componentes distintos com interfaces bem definidas, na prática eles podem se sobrepor e interagir de maneiras não detalhadas aqui. O controle do cronograma está relacionado a: - Determinação do andamento atual do cronograma do projeto; - Controle dos fatores que criam mudanças no cronograma; - Determinação de que o cronograma do projeto mudou; - Gerenciamento das mudanças conforme elas efetivamente ocorrem. 28 Figura 11 - Visão geral do controle do cronograma: Entradas, ferramentas e técnicas, e saídas. Fonte: PMBOK (2004) O Gerenciamento do Tempo nas demais áreas do conhecimento O Gerenciamento do Tempo e o Escopo do Projeto A Gerência de Escopo do projeto abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para completar de forma bem sucedida o projeto. A preocupação fundamental compreende definir e controlar o que está ou não incluído no projeto. Atualmente os clientes, devido à força que

29 possuem para estabelecer mudanças nas organizações, determinam uns constantes estados de mudança, que por sua vez aumenta a demanda por projetos ou novas requisições do projeto. Cada mudança é um empreendimento, o seja, um esforço temporário que possui início e fim, com a finalidade de produzir um bem. Estas mudanças e ou novas requisições do projeto podem acarretar grandes perdas de tempo que, por sua vez, são altamente nocivas ao cliente e à equipe do projeto O Gerenciamento do Tempo e o Custo do Projeto A Gerência de Custos do Projeto consiste, fundamentalmente, nos custos dos recursos necessários à implementação do projeto. Entretanto, a Gerência de Custos do projeto deve também considerar o efeito das decisões do projeto no custo de utilização do produto do projeto. A Gerência dos Custos do Projeto deve considerar as necessidades de informações das partes envolvidas no projeto. Diferentes interessados podem avaliar os custos do projeto de maneiras diferentes e em diferentes momentos. Fato que torna extremamente necessário não demandar muito tempo nas decisões de modo que possa influenciar os prazos do projeto O Gerenciamento do Tempo e a Qualidade do Projeto Define-se qualidade do projeto como a satisfação das exigências do cliente, o que se consegue através do cumprimento dos requisitos técnicos e da garantia dos resultados. Para tanto, é necessário o envolvimento de todos os stakeholders, entendendo as exigências do cliente e buscando o resultado continuamente. O alcance dos resultados é, portanto, fruto do esforço da equipe desde o planejamento até o controle da qualidade e não um simples acaso.

30 Fazem parte da função gerencial as atividades referentes à determinação de políticas, objetivos e responsabilidades da qualidade, implementação de sistema de qualidade, controle de qualidade e garantia e melhoria da qualidade. Mais que isso, o papel do gerente de projeto, do líder, é fundamental para a determinação das necessidades e para que todos os envolvidos tenham o mesmo objetivo em mente. Os processos relacionados ao gerenciamento da qualidade interagem mutuamente e também com processos de outras áreas de conhecimento dentro do gerenciamento do projeto. Segundo o PMBOK (2004), os processos que compõem o gerenciamento da qualidade são o Planejamento, a Garantia e o Controle da Qualidade e visam à satisfação dos padrões de qualidade requeridos para o projeto, porém, destacando-se a importância da disciplina para o sucesso destes processos. Isso porque qualquer desvio pode levar ao não cumprimento das exigências e à insatisfação do cliente. Além disso, desperdícios de recursos (como o tempo) são gerados pela necessidade de retrabalho para atendimento dos requisitos de qualidade O Gerenciamento do Tempo e os Recursos Humanos do Projeto A Gerência de Recursos Humanos do Projeto descreve os processos necessários para que se empregue de forma mais eficaz o pessoal envolvido no projeto e consiste no planejamento organizacional, na formação de equipe e no seu desenvolvimento. Gerenciar pessoas é bastante subjetivo e para se fazer de forma eficaz é preciso levar em conta diversos fatores de ordem prática, metodológica e organizacional e isso conseqüentemente envolve tempo, como em qualquer outro processo de gerenciamento. A grande questão é que o tempo é uma unidade finita e inelástica. Nesta gerência, em especial, o tempo é preponderante no que diz respeito a: Desenvolvermos familiaridade (sociabilizarmos);

31 31 Contato profissional (lidarmos com a diversidade); Adaptabilidade com a forma peculiar de cada um (aceitação); Estabelecer o ritmo pessoal de trabalho de cada um (performance); Sabermos como motivar e criar sinergia (integração); Incentivar a criatividade. Tudo isso com a finalidade de se formar equipes (times) coesas/integradas, com alto desempenho no âmbito empresarial/mercadológico. A interação entre pessoas que trabalham juntas objetivando o cumprimento de metas se faz necessária primeiramente para a existência/criação de um ambiente que estimule a realização plena de qualquer atividade profissional. Não é da cultura das empresas de um modo geral esse tipo de preocupacão/atenção a essa questão. Costuma-se partir para o trabalho diretamente (ignorando qualquer aproximação inicial para conhecimento das pessoas envolvidas) que é o foco para onde devem convergir todas as atenções, não havendo tempo para essas considerações que não podem ser mensuradas. Surge então um grande paradoxo que é o de como criar tempo para se estruturar essas relações, dar fundamentos consistentes de ordem também emocional, para se desenvolver projetos tendo como oponente a necessidade dos empregados de obterem resultados imediatos e com isso provar sua eficiência e agilidade. O ideal seria que essa interação e conhecimento humano das pessoas que trabalham em grupos já existissem e assim se possa partir para a resolução dos problemas existentes na nossa rotina de trabalho. Sabe-se que administrar recursos humanos é administrar pessoas que participam, interagem e são responsáveis diretas por resultados nas organizações e que estas desempenham determinados papéis. Acredita-se que é nessa definição que se deve ater mais demoradamente. Um questionamento pertinente é: como conter essa reação involuntária e característica de qualquer meio profissional de buscar respostas e soluções imediatas a

32 qualquer preço? Por que se tem essa urgência tão prematuramente sem antes analisar que uma saída mais inteligente poderia ser conseguida se perdêssemos algum tempo desenvolvendo o conhecimento mútuo entre os integrantes de equipes que trabalham com objetivos afins? Talvez conseguíssemos resultados mais eficientes e otimizados devido ao entrosamento das pessoas. Na era da Economia Digital não há como enfatizar essa necessidade específica de tempo retratada devido à falta de parâmetros concretos/lógicos que justifiquem essa atitude ou que estimulem esse pensamento. Nada que faça aparentemente perder tempo sem mérito comprobatório se justifica. Dada a importância inquestionável de se aproveitar ao máximo qualquer tempo, a idéia de usá-lo numa atividade sem fins lucrativos aparentes se torna infundada e desconexa. Esse procedimento de termos de nos relacionar pessoalmente/organizacionalmente em prol de um trabalho a ser realizado depende intrinsecamente do grau de disponibilidade e motivação que nos impulsiona. Quando contamos com a existência de um ambiente favorável e familiar nos sentimos naturalmente mais incentivados/acolhidos e com liberdade para expormos/recebermos/trocarmos idéias, críticas ou qualquer outro tipo de questionamento mais abertamente, desprendidos de certos pudores que teríamos em situações desconhecidas as quais necessitamos nos salvaguardar. Com isso, os ganhos obtidos são visíveis de imediato nas atitudes de cada pessoa perante qualquer problema surgido, assim como as decisões se tornam mais práticas e otimizadas pelo compromisso com os ideais compartilhados e pela união firmada de cada membro. Para isso temos que perder tempo primeiramente criando equipes/times com: 32 Disponibilidade (tempo de dedicação); Características pessoais e interesses similares; Experiência anterior;

33 33 Alto grau de sinergia/integração; Multidisciplinares/criativas; Funções definidas e pró-ativas; Senso de objetivo comum; Alto nível de comunicação/união; Preocupadas com o todo e receptivas a mudanças; Alto grau de comprometimento, sem padrões já pré-estabelecidos e Senso de valorização do grupo como uma unidade. Não há como crer que exista um manual pessoal já dentro de cada um que ensine os procedimentos para se conseguir trabalhar em conjunto, com alto grau de sinergia e interação. Assim como seria utópico idealizar relações profissionais perfeitas ou com alto desempenho de uma hora para outra. Claro que as equipes que se formam para trabalharem juntas tentam ser: integradas, eficientes e focadas num ideal conjunto. Porém, nem sempre conseguimos lidar com os problemas que surgem no decorrer das relações. O tempo para encontrar pessoas dispostas ou receptivas a formação de uma equipe e que entendam os benefícios advindos dessa união não pode ser mensurado. Muitas vezes é questão de convencimento próprio, de cultura e como tal tem seu tempo de maturação para se formar. Há que se considerar também o tempo de aprendizado e valorização desse grupamento. A conscientização que o coletivo é mais vantajoso para cada um do que a existência individual. Saber viver em grupo, trocando informações e interagindo aumenta a eficiência coletiva. No que diz respeito ao Plano de Gerenciamento de Pessoal há que se terem também procedimentos detalhados de cada membro de uma equipe para auxiliar o Plano Geral do

34 Projeto e essa elaboração e acompanhamento também demandam tempo, que nem sempre está disponibilizado por questões de ordem de importância. Pode-se também perder tempo achando recursos humanos que preencham adequadamente os requisitos impostos pelo projeto. Às vezes para encontrar um recurso específico é fundamental não estimarmos esse tempo ou desconsiderarmos essa necessidade. Busca-se com esse tempo em questionamento aqui descrito melhorar o desempenho e os resultados obtidos no decorrer de qualquer projeto que envolva grupo de pessoas, favorecendo o crescimento de uma cultura que valorize o conhecimento coletivo e a integração de pessoas que trabalham para o cumprimento de objetivos comuns. Para isso, o tempo de entrosamento entre cada um é fator decisório para a criação de um grupo de alta performance e com resultados efetivos em qualquer situação O Gerenciamento do Tempo e as Comunicações do Projeto Assim como uma pessoa organizada transmite confiança e calma que se traduzem em realizações, tanto no campo pessoal como no profissional, um projeto organizado também tem mais garantias de sucesso. As comunicações afetam o projeto como um todo, interferindo desde o início no seu prazo. Por isso, faz-se muito importante a preparação de todos os envolvidos no que tange ao recebimento e envio de comunicações relevantes para o projeto. Todos os envolvidos devem estar aptos a gerar e transmitir informações de forma a contribuir para o sucesso do projeto, pois a informação, pela sua importância nos dias atuais, é considerada a chave do sucesso do projeto. Uma razão para se adotar o gerenciamento das comunicações é que isso faz as informações disponíveis fluírem apenas para as áreas e pessoas que realmente necessitam delas e as utilizarão para executar suas atividades. Mas antes disso é preciso que se

35 determinem quais informações são relevantes e para quem devem ser direcionadas bem como quem é responsável por fornecê-las, atentando para a maneira mais adequada de passar a informação em cada situação, garantindo o atendimento das necessidades de informação de cada parte envolvida. O PMBOK (2004), ao tratar do gerenciamento das comunicações do projeto, apresenta processos que vão desde a geração até o descarte adequado de informações. Os principais processos são: 1. Planejamento das Comunicações; 2. Distribuição das Informações; 3. Relato de Desempenho; 4. Encerramento Administrativo. Sob a ótica do tempo pode-se destacar, na fase inicial, a grande contribuição do Planejamento das Comunicações para o sucesso do projeto. Problemas envolvendo falta de informações ocorrem tanto no nosso dia-a-dia que, muitas vezes, acabamos não nos dando conta de que eles são perfeitamente solucionáveis. Sabe-se o quanto isso influencia no projeto, gerando atrasos e queda de qualidade. A tendência, geralmente, é achar que o problema de comunicação é um mal crônico, impossível de resolver, ou até uma questão de cultura da empresa que jamais será mudada. Porém, a partir da elaboração do Planejamento das Comunicações é possível solucionar esses pequenos problemas tão significantes para o projeto. O Plano de Gerenciamento das Comunicações que resulta deste trabalho inicial fornece um mapa de como serão realizadas as comunicações para que sejam atendidas da melhor maneira as necessidades do projeto. A vantagem de se ter um Plano de Comunicação elaborado de acordo com as necessidades específicas do projeto é que não há tempo desperdiçado com a preparação de documentações desnecessárias, muitas vezes meramente 35

36 burocráticas. Ao contrário, tudo é estudado previamente (necessidades de informação de cada parte, urgência das informações, meios disponíveis para distribuição) para que os recursos disponíveis e o tempo sejam utilizados de forma racional sem prejuízo de nenhum aspecto do projeto (qualidade, custo, prazo). Desta forma, evita-se a ocorrência dos esbanjadores de tempo, tais como: reuniões não previamente agendadas e sem um propósito específico, tempo gasto com preparação de documentos desnecessários e acúmulo de papéis sobre a mesa sem que seja dado o devido fim a eles. Um aspecto importante do processo de Distribuição das Informações é que, além de disponibilização de informações já planejadas, ele permite a resposta às informações inesperadas ao longo do projeto. No lugar de informações circulando de forma fragmentada na empresa pode-se, com a distribuição das informações feita de maneira planejada, gerenciar as informações de maneira regular e segura. O processo de Relato de Desempenho fornece dados para a análise de variações e tendências do projeto, podendo levar às requisições de mudanças eventuais correções de escopo ou prazo, por exemplo. Durante o projeto o Relato de Desempenho tem o papel de trazer à tona, em forma de gráficos e tabelas, a situação do projeto. A partir da análise deste material é possível corrigir desvios importantes antes que o prazo do projeto seja comprometido. É nítida a relevância deste processo para a condução do projeto dentro do escopo e para o alcance do prazo, pois suas saídas Relatórios de Desempenho e Requisições de Mudanças são fundamentais para o controle do cronograma do projeto. Caso não seja feito um acompanhamento do desempenho do projeto, pequenos problemas podem se somar até tornarem-se grandes demais para serem controlados. Então, será necessário um investimento grande de tempo para evitar que o prejuízo ao projeto seja maior ainda. 36

37 Sem perder de vista o futuro, o gerenciamento das comunicações é importante também por preservar as informações do projeto em andamento de maneira organizada para consultas de projetos posteriores. Ao final de cada fase do projeto, devem-se armazenar todas as informações importantes e úteis e no processo de Encerramento do Projeto um conjunto completo dos registros do projeto deve ser preparado para arquivamento pelas partes apropriadas. Este banco de dados devidamente organizado torna-se uma fonte valiosa de informações para projetos futuros, não só pelo fato de conter registros de ações de sucesso, mas também pelos registros do que não deu certo no projeto. Isso se traduzirá em ganho de tempo nos projetos que se seguirão O Gerenciamento do Tempo e os Riscos do Projeto Risco de um Projeto é um evento ou condição incerta que, se ocorrer, tem um efeito positivo ou negativo no projeto. Um risco tem uma causa e, se esta ocorrer, uma conseqüência. Por exemplo, a causa pode ser uma requisição de uma folga ou ter-se limitado o pessoal designado para o projeto. Riscos de projeto incluem tanto ameaças quanto oportunidades. Isso tem origem na incerteza que está presente em todos os projetos. Riscos conhecidos são aqueles que têm sido identificados, analisados e pode ser possível planejá-los. Riscos desconhecidos não podem ser gerenciados, embora o gerente do projeto possa considerá-los através de aplicação de uma contingência. Nem todo risco é maléfico. Por exemplo, adotar um fast track em um cronograma que pode ser agilizado é um risco tomado para alcançar uma data mais cedo para conclusão. Riscos que são oportunidades podem ser diligenciados para beneficiar os objetivos do projeto. Com a finalidade de se eliminar ou

38 minimizar os impactos das mudanças e, conseqüente, perdas de tempo no projeto, os seguintes pontos serão explorados: No Planejamento da Gerência de Riscos deve-se encarar riscos de perda de tempo como um risco a ser mitigado. Identificado os riscos de perda de tempo em várias etapas do projeto, porque não incluí-los na tabela de análise de riscos para mitigação? Como demanda a Gerência de Riscos do Projeto, os riscos devem ser conhecidos, pois só então teremos como tratá-lo. Um risco conhecido pode tornar-se um economizador de tempo e até um alavancador de resultados relativos ao tempo do projeto. Abaixo são citados riscos encontrados ao longo do trabalho que, se considerados, podem ser mitigados. 38 Interrupções telefônicas; Visitantes inesperados; Delegação inadequada; Reuniões; Gerência de crise; Pessoal não treinado; Bate papos e atrasos; Ausência de limites claros de autoridade e responsabilidade; Comunicação ineficaz; Indecisão; Ausência de objetivos, prioridades e planejamento. A Análise Quantitativa dos Riscos representa analisar numericamente a probabilidade e conseqüência de cada risco envolvido no projeto. Quantificar perdas de tempo é mais fácil, já que tempo é uma grandeza quantificável e diretamente associada aos custos do projeto. O importante é levar em consideração que o impacto das perdas de tempo pode não só influenciar o prazo e custo do projeto como também benefícios intangíveis, tais como:

39 credibilidade da equipe do projeto, qualidade dos serviços e confiança no gerente e equipe do projeto. O Planejamento de resposta a riscos prevê que os riscos devam ser, na sua magnitude, evitados, transferidos, mitigados ou aceitos. Contudo para o tempo, transferir ou aceitar não seria comum, já que pode-se evitá-los ou mitigá-los. Imagine fazer um seguro que preveja atrasos do cronograma e reembolse o cliente no caso destes ocorrerem. Neste caso, têm-se prêmios altíssimos ou seguradores falindo, tamanho é o risco de perda de tempo em projetos. Administrar o tempo de forma eficiente é mais recomendado. 39

40 40 3. PROJETOS DE SOFTWARE 3.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE O termo software está associado não apenas aos programas de computador, mas a toda documentação associada bem como os dados de configuração para fazer com que estes programas operem corretamente. Esta documentação inclui toda a documentação do sistema bem como a documentação do usuário (SOMMERVILLE, 2003). Processo é um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto especificado de produtos, resultados ou serviços (PMBOK, 2004, p.373). Portanto, um processo de software é um conjunto de ações e atividades interrelacionadas realizadas a fim de produzir um software. Segundo Sommerville (2003), embora existam muitos processos de software diferentes, há quatro atividades fundamentais comuns a todos eles: Especificação de Software onde são definidos os requisitos, funcionalidades e restrições do software; Projeto e Implementação do Software onde é feita a análise e construção do software; Validação do Software onde são feitos os testes das funcionalidades, testes de integração com outros sistemas e testes de aceitação do usuário; Evolução do Software onde são definidas melhorias e modificações para atender às necessidades mutáveis do cliente. Considerando o projeto de um software, serão abordadas neste trabalho somente as três primeiras atividades, pois a última (Evolução do Software) está relacionada à manutenção do software.

41 MODELOS DE DESENVOLVIMENTO DE SOFTWARE O modelo mais clássico de desenvolvimento de software é o chamado modelo em cascata. Este modelo considera que as atividades de Especificação do Software, Projeto e Implementação do Software e Validação do Software são feitas sequencialmente, onde uma atividade só começa quando sua antecessora termina. Especificação Projeto e Implementação Validação Figura 12 - Modelo em Cascata. Fonte: Adaptado de Sommerville (2003). Este modelo se assemelha aos princípios de produção em massa utilizados por Taylor, onde os requisitos são tratados como matérias-primas que são transformadas, gerando artefatos, à medida que avançam pela linha de produção. A fim de garantir a previsibilidade do processo, cada artefato deve ser produzido corretamente e passado para a etapa seguinte. Deste modo, evitar variações é fundamental (TELES, 2005). Outro modelo bastante usado hoje em dia é o chamado Modelo Iterativo e Incremental. Neste modelo as atividades são seqüenciadas diversas vezes em iterações.

42 42 Especificação Especificação Especificação Projeto e Implementação Projeto e Implementação Projeto e Implementação Validação Validação Validação 1º Iteração 2º Iteração 3º Iteração Figura 13 - Modelo Iterativo e Incremental. Fonte: Adaptado de Sommerville (2003). Haverá tantas iterações quantas forem necessárias para a finalização do projeto. Cada iteração representa uma parte do escopo do produto e a cada iteração novos requisitos são levantados e novas funcionalidades são acrescentadas ao software. O software deve ser construído de forma que se adapte facilmente às mudanças, pois uma nova iteração pode fazer com que haja mudanças nos programas de software construídos pela iteração anterior. O grande problema do modelo em cascata está no fato de que o cliente só irá ver o software construído no final do projeto. Desta forma, qualquer mudança acarretará em um custo maior do que se fosse feita no início do projeto. O modelo iterativo e incremental diminui este risco, pois o cliente aprova o que foi solicitado em cada iteração. Porém, a essência dos processos iterativos é que a especificação é desenvolvida em conjunto com o software. Desta forma, isto pode acarretar em conflito com o modelo de suprimento de muitas organizações em que a completa especificação do sistema tem que fazer parte do contrato para o desenvolvimento do sistema (SOMMERVILLE, 2003). Isto significa que no modelo iterativo e incremental não há como saber o que será construído até o final da última iteração.

43 43 4. ESTIMATIVAS DE TEMPO EM PROJETOS DE SOFTWARE De acordo com o PMBOK (2004), para se construir o cronograma de um projeto é necessário seguir os seguintes passos: a. Definição da atividade este processo consiste em identificar e documentar as atividades a serem realizadas tendo-se como base a Estrutura Analítica de Projetos (EAP); b. Seqüenciamento de atividades consiste em identificar e documentar os relacionamentos lógicos (dependências) entre as atividades usando relações de precedência adequadas; c. Estimativas de recursos da atividade este processo possui a finalidade de determinar os recursos bem como suas quantidades para cada atividade. Entendase como recurso qualquer pessoa, equipamento ou material necessário para a realização da atividade; d. Estimativa de duração da atividade é neste processo que se determina a duração de cada atividade, tendo-se como base os recursos disponíveis para sua realização; e. Desenvolvimento do cronograma neste processo têm-se como resultado final as datas de início e término das atividades planejadas do projeto. Este processo, na maioria das vezes, é iterativo, ou seja, a duração das atividades e as estimativas de recursos podem ser revisadas para se criar um cronograma adequado ao projeto. Todos estes processos podem ser usados para se obter um cronograma de um projeto de software através da técnica conhecida como botton-up. Neste tipo de abordagem, o tempo total do projeto é derivado das estimativas de tempo de cada atividade que o compõe. De

44 acordo com o PMBOK (2004), as ferramentas e técnicas que podem ser usadas para a estimativa de tempo de uma atividade são: a. Opinião especializada consiste na consulta a especialistas que conhecem bem o tempo provável da atividade. Membros da equipe também podem ser consultados a respeito de atividades semelhantes em projetos anteriores; b. Estimativa análoga consiste em obter informações sobre o tempo real da atividade em projetos anteriores. A estimativa análoga é mais confiável quando a atividade anterior é exatamente igual, e não semelhante, a atividade que se deseja estimar o tempo; c. Estimativa paramétrica neste caso, usa-se um fator de produtividade para a estimativa de tempo da atividade, multiplicando-se este fator pela quantidade de trabalho para realizar a atividade; d. Estimativas de três pontos neste tipo de estimativa, a duração da atividade pode ser aumentada pelo risco da estimativa original. A estimativa de três pontos baseia-se na determinação de três tipos de estimativas: 44 Estimativa mais provável é aquela onde é levada em conta a duração mais provável da atividade baseada em um cenário realista para a sua realização; Otimista é aquela que se baseia no melhor cenário da estimativa mais provável; Pessimista é aquela que se baseia no pior cenário da estimativa mais provável; A estimativa total é calculada através de uma média ponderada das estimativas mais provável, otimista e pessimista. e. Análise de reservas é um tempo adicionado a cada atividade para eventuais atrasos. Este tempo pode ser um percentual atribuído à estimativa de tempo da

45 atividade, um período fixo de tempo ou um valor decorrente da análise quantitativa de risco do cronograma. Uma outra abordagem para a estimativa de tempo de um projeto é conhecida como top-down. Nesta abordagem, primeiramente o software a ser construído sofre um processo de medição. Tendo-se o tamanho do software, pode-se, a partir de variáveis de produtividade e alocação de recursos, calcular o tempo total do projeto. A partir daí, é construído o cronograma para que as atividades do projeto possam resultar no tempo total encontrado. Na abordagem top-down, o tempo de cada atividade é derivado do tempo total, ao contrário da abordagem botton-up MEDIÇÃO DO TAMANHO E ESTIMATIVA DE UM SISTEMA DE SOFTWARE Um projeto tem por objetivo produzir um bem ou serviço. Dependendo da área envolvida, o produto do projeto pode ser quantificado. Por exemplo: uma construção civil pode ser medida por área construída; um navio pode ser quantificado por área e tonelada; mas como se medir um sistema de software? Segundo Braga (1996), as primeiras tentativas de medir o tamanho de um sistema levaram em consideração a quantidade de linhas de código total do sistema (LOC Lines Of Code). Uma linha de código é um comando ou uma instrução contida no software que deve ser interpretada e executada pelo computador. Este tipo de medição não se apresenta eficaz pelos seguintes motivos: a) LOCs não permitem comparação entre softwares escritos em diferentes linguagens de programação; b) programadores com experiências diferentes na mesma linguagem de programação tendem a escrever o mesmo programa com quantidades de linhas de código diferentes; c) não há como estimar o tamanho de um sistema antes de codificá-lo, a não ser que exista um sistema semelhante usando a mesma tecnologia e realizando as mesmas funções.

46 Uma técnica de medição de sistema que independe de tecnologia e linguagem de programação é a técnica de Análise de Pontos de Função. Esta técnica é baseada na visão do usuário e mede o que é o sistema e não como será, ou foi, desenvolvido (BRAGA, 1996, p.3). Um dos principais conceitos da Análise de Pontos de Função está no fato que as funções do sistema devem ser vistas a partir da perspectiva do usuário e não do analista ou programador. Desta forma, esta técnica permite que este método de medição seja independente de linguagem de programação, banco de dados e experiência do programador. Uma vez determinada a quantidade de pontos de função de um sistema, para se calcular o tempo total do projeto deste sistema é necessário a aplicação de um fator de produtividade. No caso da Análise de Pontos de Função, esta produtividade é medida em horas por ponto de função. Braga (1996) cita que uma equipe novata programando na linguagem COBOL possui uma produtividade de 20 a 50 horas por ponto de função. Já uma equipe experiente para realizar o mesmo trabalho, teria uma produtividade de 5 a 15 horas por ponto de função. Um outro método para se medir o tamanho de um sistema é através do uso de um modelo algoritmo baseado em observações empíricas. O COCOMO (constructive cost model modelo de custo construtivo) é um modelo que apresenta estas características e pode ser usado como base para estimar prazo e custo de um projeto de software. O COCOMO foi derivado pela coleta de dados a partir de um grande número de projetos de software e, em seguida, pela análise desses dados para descobrir fórmulas que fossem mais adequadas às observações (SOMMERVILLE, 2003, p.446). No nível inicial do projeto, o COCOMO usa a seguinte fórmula para a estimativa do esforço: E = A x Tamanho B x M, onde: 46 E esforço expresso em pessoa-mês; A coeficiente igual a 2,5 usado para estimativas feitas no nível inicial do projeto

47 47 Tamanho tamanho do sistema expresso em milhares de linhas de código (KLOC). Este número é calculado estimando-se o número de pontos de função no software e convertendo-o para KLOC com o uso de tabelas-padrão; B Expoente que pode varia entre 1,1 a 1,24 dependendo da novidade do projeto, da flexibilidade de desenvolvimento e do nível de maturidade de processo da organização; M multiplicador que se baseia em um conjunto simplificado de sete projetos e direcionadores de processo derivados. 4.2 CONSTRUÇÃO DO CRONOGRAMA Conforme citado no PMBOK (2004), o desenvolvimento do cronograma é um processo iterativo onde as estimativas de duração das atividades, suas relações lógicas e a alocação de recursos sejam sempre revistas de forma a produzir um cronograma realista. O desenvolvimento do cronograma deve ser feito iterativamente, ou seja, ser elaborado de forma progressiva e repetida até o momento em que seus resultados sejam confiáveis e possam atender aos objetivos do projeto (BARCAUI, 2006, p. 86). Segundo Sommerville (2003), software á algo intangível. Portanto, informações sobre o andamento do projeto e sobre o estado do software que está sendo desenvolvido somente podem ser fornecidas através de documentos. Daí a necessidade de se estabelecer marcos durante o projeto. Um marco é um ponto ou evento significativo no projeto e o gerente de projetos, bem como o cliente, pode avaliar o andamento do mesmo. Portanto, há uma necessidade em se criar marcos no cronograma do projeto.

48 O processo para se desenvolver o cronograma leva em consideração entradas de outros processos e a aplicação de técnicas e ferramentas. Como resultado deste processo, tem-se basicamente as seguintes saídas: 48 O cronograma do projeto, contendo diagrama de rede, gráfico de barras e gráfico de marcos; Dados do modelo de cronograma, contendo marcos, atividades, e documentação de todas as premissas e restrições identificadas; Linha de base do cronograma. De acordo com o PMBOK (2004) o processo de desenvolvimento do cronograma é mostrado na figura a seguir: Figura 14 Processo de desenvolvimento do cronograma. Fonte: PMBOK (2004). Um software de gerenciamento de projetos é peça fundamental para uma boa produtividade deste processo, bem como permite a avaliação de diferentes cenários e a realização dos cálculos necessários para a determinação do caminho crítico, cálculo das folgas e a duração total do projeto (BARCAUI, 2006).