Estimação de Prazos, Recursos e Custos em Projetos de Software (PDF)

Parte III - Organização e Planeamento Detalhado do Projeto ========================================================== 7 - Estimativa de Prazos, Recursos e Custos ------------------------------------------- ### 7.1 O Problema em Perspetiva Estimar, de forma eficaz, o esforço (recursos e prazos) e...

Parte III - Organização e Planeamento Detalhado do Projeto ========================================================== 7 - Estimativa de Prazos, Recursos e Custos ------------------------------------------- ### 7.1 O Problema em Perspetiva Estimar, de forma eficaz, o esforço (recursos e prazos) e o custo do desenvolvimento de software constitui uma das atividades simultaneamente mais difíceis e mais importantes deste tipo de projeto. No coração do processo de estimar há dois desafios: - - Só então será possível prever com precisão o esforço necessário para desenvolver o produto. Sem uma estimativa adequada e fiável não é possível um planeamento e controlo eficazes do projeto. Subestimar um projeto conduz à afetação de menos recursos que o necessário, à redução do âmbito do esforço de garantia da qualidade e ao estabelecimento de um prazo demasiado curto. Isto, por sua vez, resulta em stress do pessoal, software com qualidade inferior e perda de credibilidade, à medida que os prazos inicialmente estabelecidos vão sendo sucessivamente ultrapassados. Por outro lado, sobrestimar um projeto pode revelar-se quase tão pernicioso - a lei de Parkinson entra em ação, o que significa que o projeto irá demorar tanto quanto a estimativa, embora tenha sido sobrestimado. Torna-se claro, assim, que uma estimativa exata constitui uma componente crítica dos alicerces de qualquer projeto de sucesso. O processo de estimar custos baseia-se num conjunto de técnicas e procedimentos que a organização usa para chegar a uma estimativa. A estimativa dos custos e dos recursos nunca será uma ciência exata, em virtude de existirem demasiadas variáveis a afetar potencialmente o esforço necessário para desenvolver o software e o respetivo custo técnicas, políticas, humanas e organizacionais. É importante compreender o que significa a palavra "estimar". A definição aqui seguida é a seguinte: \"Estimar: a melhor visão do futuro, baseada no conhecimento e informação disponíveis hoje.\" \[DeMarco, 1986\] Não se espera que, por inferência, se acerte sempre; o que se quer é acertar de uma maneira geral. Porque é tão difícil estimar o esforço e os custos do projeto? Podemos encontrar várias respostas para esta questão: - - - - Vários fatores podem conduzir a estimativas fracas ou imprecisas: - - - - No entanto, a estimativa dos projetos de software pode ser transformada numa série de passos sistemáticos que forneçam estimativas com níveis aceitáveis de risco. Para isso, é fundamental seguir algumas regras simples: - - - Um modelo de estimativa eficaz considera três elementos: dimensão, complexidade e fatores de risco. Quando avaliados em conjunto, esses elementos resultam numa estimativa precisa (Figura 7.1). Figura 7.1 - Elementos da estimativa A dimensão do projeto pode ser avaliada com o auxílio de várias técnicas. A que proporciona a maior precisão e fiabilidade é a análise dos pontos de função. Métodos alternativos, como a contagem de linhas de código do COCOMO20, estão dependentes de informação que só está disponível em fases adiantadas do processo de desenvolvimento. ### 7.2 Dificuldade das Estimativas Embora seja absolutamente necessário obter uma estimativa realista dos projetos, esta atividade é uma das mais difíceis do desenvolvimento de software. Vamos ver, em seguida, alguns dos constrangimentos que tornam esta atividade tão difícil e que é necessário ultrapassar: - - - - - Sabe-se que, de vez em quando, o \"impossível\" acontece, mas é raro e muito caro. ### 7.3 Quem Deve Estimar? É da responsabilidade do gestor de projeto a efetivação de estimativas precisas do esforço (recursos e prazos) e do custo do projeto. Isto é particularmente verdadeiro para projetos concursos concorrenciais, em que uma proposta demasiado elevada relativamente aos concorrentes pode resultar na perda do contrato, ou uma proposta demasiado baixa pode redundar num prejuízo sério para a organização. Em sistemas complexos e de grande dimensão, um erro significativo de estimativa pode fazer a diferença entre o lucro e o prejuízo. Constitui uma visão de certo modo consensual que quem vai estar envolvido na implementação deverá ser envolvido na estimativa. Se os programadores forem envolvidos nas estimativas, estas serão mais precisas e aqueles terão mais motivação para atingir os objetivos que fixaram. Em oposição a isto está a visão de que a estimativa deve ser realizada por uma equipa independente, como forma de obter uma estimativa não enviesada. Embora o entusiasmo de alguns elementos possa ser compensado pela precaução de outros, os perigos desta atividade de grupo é que alguns elementos podem dominar. Do mesmo modo, quando se retira a uma tarefa a responsabilidade individual, um grupo tem mais tendência para adotar uma posição mais conservadora (menos arriscada). Para reduzir este problema, pode usar-se a técnica Delphi, que tem como objetivo remover as considerações políticas do processo de estimar, na medida em que as estimativas são anónimas e não enviesadas. Uma publicação de Tom DeMarco \[DeMarco, 1986\] foca as equipas de estimação em maior detalhe. Este autor sugere o estabelecimento de um grupo de estimação separado do estágio de desenvolvimento. Deste modo, os elementos do grupo não terão qualquer interesse no desenvolvimento, sendo o seu desempenho baseado na capacidade dos grupos de desenvolver estimativas que convergem rapidamente para os custos reais de um projeto. ### 7.4 Estimar a Partir da EDT Estimar o projeto a partir do conhecimento das atividades de nível mais baixo da EDT- os pacotes de trabalho - é um processo com três passos elementares: - - - #### 7.4.1 Estimar o Esforço para a Realização das Atividades Uma vez estimada a dimensão do software a produzir, pode deduzir-se a estimativa do esforço necessário para realizar cada uma das atividades. A conversão da dimensão do software para o esforço total do projeto só pode ser realizada se tiver sido definido o ciclo de vida do desenvolvimento e o modelo de desenvolvimento que é seguido para especificar, desenhar, desenvolver, testar e instalar o software. Um projeto de desenvolvimento envolve muito mais do que apenas a codificação realidade, a codificação constitui frequentemente a parte mais reduzida do esforço total. Escrever e rever documentação, implementar protótipos, desenhar os produtos e rever e testar o código constitui a principal porção do esforço total do desenvolvimento. A estimativa do esforço do projeto exige que se identifiquem e estimem, e depois se adicionem todas as atividades que é necessário realizar para construir um produto com a dimensão estimada. #### 7.4.2 Variabilidade do Esforço O esforço necessário para levar a cabo as atividades é uma variável aleatória. Como não podemos conhecer os fatores que estarão em jogo quando estiver a decorrer o trabalho de uma atividade, não podemos saber exatamente quanto tempo irá demorar. Existirão, evidentemente, para cada atividade, estimativas variadas com diversos graus de precisão. Um dos principais objetivos do gestor de projeto, ao estimar o esforço das atividades, é definir a atividade a um nível de detalhe tal que as estimativas tenham um desvio reduzido. À medida que o trabalho do projeto vai sendo concluído, o gestor de projeto é capaz de melhorar as estimativas iniciais de atividades calendarizadas para as fases mais adiantadas do projeto. Há várias causas para a variação do esforço real das atividades: - - - - #### 7.4.3 Métodos para Estimar o Esforço das Atividades Estimar o esforço das atividades constitui um desafio. A equipa pode estar em terreno familiar para algumas atividades e em terreno desconhecido relativamente a outras. Seja qual for o caso, é necessário produzir uma estimativa que seja mais do que uma simples \"adivinhação\". Em muitos projetos, as estimativas irão melhorando à medida que a equipa sabe mais sobre os produtos do projeto. É muito comum refazerem-se várias vezes o planeamento e as estimativas. Para as estimativas iniciais do planeamento, ao nível das atividades, há seis práticas consideradas adequadas: - - - - - - ##### 7.4.3.1 Experiência Anterior Algumas das atividades na EDT atual podem ser similares a atividades realizadas noutros projetos já concluídos. A experiência recolhida no tipo e duração dessas atividades já concluídas pode ser usada para estimar a duração da atividade presente. Embora nalguns casos isto possa exigir extrapolação de resultados, na maioria das situações fornece estimativas bastante boas. ##### 7.4.3.2 Dados Históricos Qualquer boa metodologia de gestão de projetos inclui um repositório do projeto onde se registam (entre muitas outras coisas) as durações estimadas e reais das atividades. Este registo histórico pode ser usado noutros projetos. Os dados registados tornam-se a base de conhecimento da organização para o processo de estimar. Esta técnica difere da anterior, na medida em que recorre a um registo histórico em vez de confiar apenas na memória. Os dados históricos podem ser usados de formas bastante sofisticadas. **Exemplo:** Uma empresa de software construiu uma base de dados com o histórico de durações de atividades, na qual estão registadas as durações estimada e a real, as características da atividade, o conjunto de aptidões das pessoas que nela trabalharam e outras variáveis consideradas úteis pela organização. Como a organização constrói produtos para o mercado, a precisão das estimativas revela-se de importância crucial. O conselho que se pode dar aqui é: se existir valor acrescentado no uso de uma ferramenta particular, então ela deve ser usada. ##### 7.4.3.3 Opinião de Especialistas Quando o projeto envolve tecnologia (hardware e/ou software) de ponta, ou que está a ser usada pela primeira vez na organização, pode não existir experiência local, ou mesmo profissionais habilitados, nessa tecnologia. Nestes casos, a organização terá de apelar a especialistas exteriores - empresas de consultoria ou empresas não concorrentes que usem a tecnologia. ##### 7.4.3.4 Técnica Delphi Na ausência do conselho de peritos, a técnica Delphi pode produzir boas estimativas. Trata-se de uma técnica de grupo que extrai e resume o conhecimento do grupo, para chegar a uma estimativa \[Schmidt, 1997\]. Esta técnica foi inicialmente desenvolvida na Rand Corporation no final da década de 1940, como uma forma de efetuar previsões sobre eventos futuros. A técnica foi usada, mais recentemente, como um meio de orientar um grupo de pessoas informadas, para um consenso de opinião sobre um determinado assunto \[Schmidt et al., 2000\] \[Miguel, 2013\]. Após o grupo ter sido informado acerca do projeto e da natureza da atividade, a cada indivíduo no grupo é perguntado qual a sua melhor estimativa para a duração da atividade. Os resultados são tabulados e apresentados, tal como ilustrado na Figura 7.2, num histograma denominado primeira ronda. Figura 7.2 - Técnica Delphi Aos participantes cujas estimativas caem nos quartis extremos é pedido que as justifiquem. Após escutar os respetivos argumentos, é pedido a cada membro do grupo que volte a apresentar uma estimativa. Os resultados são apresentados num histograma designado por segunda ronda e as estimativas extremas novamente defendidas. Segue-se uma terceira estimativa cujo histograma é designado por terceira ronda. São permitidos ajustamentos finais. A média da terceira estimativa é usada como a estimativa do grupo. Embora a técnica pareça muito simplista, tem demonstrado ser eficaz na ausência de conselho de peritos. ##### 7.4.3.5 Técnica dos Três Pontos ou PERT A duração da atividade é uma variável aleatória. Se fosse possível repetir a atividade várias vezes em circunstâncias idênticas, as durações apresentariam variações, podendo apresentar-se fortemente agrupadas em torno de um valor central ou amplamente dispersas. Na primeira situação, disporíamos de informação considerável sobre a duração da atividade, ao passo que na segunda teríamos pouca ou nenhuma informação. Em qualquer instância da atividade embora não se saiba em que extremo a duração irá cair, é possível fazer avaliações probabilísticas. A técnica dos três pontos ou PERT - Program Evaluation and Review Technique fornece um modelo para fazer isso. Para usar o método, é necessário dispor de três estimativas da duração da atividade - otimista, pessimista e mais provável. O tempo otimista é definido como a mais curta duração que se poderá ter (ou que já se teve), no caso de tudo correr como esperado. O tempo pessimista corresponde à duração que se poderá experimentar (ou que se experimentou no passado), se acontecer tudo aquilo que pode correr mal e mesmo assim a atividade for concluída. Finalmente, a duração mais provável é aquela que ocorre mais frequentemente. Para aplicar este método, utiliza-se a memória coletiva de profissionais que já trabalharam em atividades similares, mas acerca das quais não há registo histórico. A Figura 7.3 é uma representação gráfica da técnica dos três pontos. Figura 7.3 - Técnica PERT ##### 7.4.3.6 Técnica Delphi Wide-band Combinando a técnica Delphi e a técnica dos três pontos, temos a técnica Delphi wide- -band. À semelhança da técnica Delphi, envolve um painel. No entanto, em vez de uma única estimativa, é pedido aos membros do painel, em cada iteração, que deem as suas estimativas otimista, pessimista e mais provável para a duração da atividade escolhida. Os resultados são compilados e quaisquer estimativas extremas removidas. São calculadas as médias para cada uma das três estimativas, as quais são depois usadas como a estimativa otimista, pessimista e mais provável para a atividade. ### 7.5 Estimar a Duração das Atividades #### 7.5.1 Duração de um Projeto Antes de se poder estimar a duração do projeto, é necessário garantir que todos trabalham a partir de uma definição comum. A duração de um projeto é o período de tempo em dias de trabalho úteis, excluindo fins de semana, feriados, períodos de férias, tempo de formação, períodos de doença, etc. A duração é diferente de esforço de trabalho, o qual é o trabalho necessário para concluir uma atividade (este esforço pode ser efetivado em períodos consecutivos ou não). **Exemplo:** Uma empresa possui uma atividade que lhe exige o envio de um documento ao advogado do seu cliente, para ser revisto, assinado e posteriormente devolvido. Este processo demora geralmente 10 dias úteis a ser concluído, antes de o documento regressar à origem. A empresa sabe que o advogado do seu cliente demora cerca de 30 minutos para rever e assinar o documento. À questão \"qual é a duração?\", a resposta é \"10 dias\". No entanto, o esforço de trabalho, por parte do advogado, é de 30 minutos. É importante compreender a diferença entre tempo de trabalho e tempo de calendário. Suponhamos que se estimou que uma certa tarefa precisava de 5 horas de trabalho ininterrupto e concentrado para ser concluída. Em condições normais de trabalho, quem realizar essa tarefa irá demorar certamente mais que 5 horas. Tendo como base os dados mostrados na Figura 7.4: se o executor pudesse estar 100% concentrado no seu trabalho, necessitaria de 5 horas para o concluir. Essa pessoa seria certamente única, na medida em que é francamente provável que o seu trabalho seja interrompido por mensagens de email, chamadas telefónicas, reuniões, refeições, com colegas, etc. Vários estudos realizados apontam para perdas compreendidas entre 25% e 35%. Se usarmos o limite inferior de 25%, a tarefa demorará cerca de 6h40. Se aplicarmos o limite superior, a tarefa poderá demorar cerca de 7h45. conversas Figura 7.4- Tempo de calendário versus tempo de trabalho Isto sem interrupções! Se considerarmos que cerca de 30% do tempo restante respondida, problemas com o sistema informático, falhas de corrente, interrupção pelo chefe a pedir que resolva um assunto urgente, um telefonema dos companheiros de golfe preenchido com interrupções inesperadas - chamada telefónica com uma questão a ser \- a tarefa poderá demorar 11 dias a ser concluída! É neste tempo de calendário que estamos interessados, ao efetuar as estimativas, pois é a verdadeira duração da atividade. No entanto, para efeitos de custeamento, o que conta é o tempo de trabalho realmente despendido na atividade (no caso do exemplo, 5 horas). #### 7.5.2 Número de Recursos versus Duração da Atividade A duração de uma atividade é influenciada pelo número de recursos que lhe forem atribuídos. Dizemos influenciada porque não existe uma relação necessariamente direta entre os dois fatores - recursos e duração. Dwayne Philips é uma conhecida autoridade em gestão de projetos, tendo escrito um apreciável número de obras sobre o tema. Este autor enuncia uma regra que é necessário recordar: \"Se a dimensão da equipa triplica, a produtividade apenas duplica\" \[Philips, 1998\]. O que, na realidade, se está a dizer é que existe um excesso/sobrecarga de comunicações em qualquer projeto e, quanto maior o projeto, maior a necessidade de ter este fenómeno em consideração. As estimativas do esforço de trabalho necessário podem ser afetadas. Isto significa normalmente que é necessário identificar, estimar e incluir no plano mais atividades. Além disso, a adição de mais pessoas ao projeto incrementa o risco do próprio projeto. Quanto mais pessoas trabalharem numa atividade, mais provavelmente uma estará ausente, maior a possibilidade de se cometer um erro e maior a possibilidade de cada um tentar fazer as coisas \"à sua maneira\". O terceiro passo no processo de estimar é a determinação do prazo do projeto, a partir da estimativa do esforço. Isto envolve geralmente estimar o número de pessoas que irão trabalhar no projeto, o que irão fazer (a EDT), quando irão começar a trabalhar no projeto e quando terminarão. Uma vez na posse desta informação, é necessário convertê-la num prazo de calendário. Mais uma vez, podem ser usados dados históricos dos projetos anteriores da organização, ou modelos de dados da indústria, para prever o número de pessoas que serão necessárias para um projeto de uma dada dimensão e o modo como o trabalho pode ser decomposto e calendarizado. Se não se dispuser de mais nada, pode usar-se a seguinte regra empírica para obter uma ideia aproximada do tempo total de calendário necessário \[McConnel, 1992\]: prazo em meses = 3,0 x (meses de esforço) 1/3 As opiniões divergem sobre o número que se deverá colocar: 2,0 ou 2,5 em vez de 3,0. Somente por tentativa é possível ajuizar qual o número adequado para os nossos projetos. ### 7.6 Determinar os Requisitos de Recursos A equipa de planeamento deve incluir gestores de recursos - do PMO, caso exista - ou seus representantes, pois, além de estar a definir a EDT e a estimar a duração das atividades, está igualmente a estimar as necessidades de recursos. A prática que se preconiza tem demonstrado ser eficaz. Primeiro, criar uma lista de todos os recursos necessários ao projeto. Para recursos humanos, listar apenas o nível de aptidão ou o tipo de função. Não nomear pessoas específicas, mesmo que exista apenas uma pessoa na organização com as aptidões exigidas. Segundo, quando a EDT for apresentada, as necessidades em recursos podem ser igualmente relatadas. Acontece frequentemente o gestor de projeto conhecer o recurso específico e ser confrontado com a pergunta: devemos incluir essa pessoa no plano? Se ela for incluída e não estiver disponível quando for necessária, como é que essa situação afeta o plano do projeto? Se essa pessoa for altamente especializada e capaz, e essa informação é usada para estimar a duração da atividade em que é suposto ela trabalhar, o gestor de projeto pode vir a enfrentar um problema. Se não for possível substituí-la por um outro indivíduo com as mesmas aptidões, isso irá criar uma derrapagem com efeito dominó sobre o prazo global do projeto? O gestor de projeto tem de ponderar estas decisões. ### 7.7 Estimar o Custo Existem muitos fatores a considerar quando se estima o custo total de um projeto trabalho, aquisição e leasing de hardware e software, viagens para reuniões ou testes, telecomunicações (por exemplo, chamadas interurbanas e internacionais, videoconferências, linhas dedicadas para testes, etc.), cursos de formação, espaço de escritório, etc. A forma exata como se calcula o custo total do projeto depende do modo como a organização distribui os custos. Alguns custos podem não ser atribuídos a projetos individuais, sendo refletidos indiretamente através de \"custos de estrutura\". Pode obter-se um custo do trabalho mais preciso se for usada uma taxa específica para cada tipo de posição no projeto (por exemplo, técnico, gestão da qualidade, gestão do projeto, documentação, suporte, etc.). O gestor de projeto terá de determinar qual a percentagem do esforço total do projeto que deverá ser atribuída a cada posição. Mais uma vez, os dados históricos ou os modelos da indústria podem ajudar. ### 7.8 Técnicas para Estimar o Esforço Vimos no ponto 6.4.8 como estimar o esforço, o prazo e o custo de um projeto a partir da abordagem de-baixo-para-cima das atividades do projeto que compõem a EDT. É a abordagem analítica das estimativas. No entanto, essa estimativa pode ser efetuada de uma forma global, isto é, numa abordagem de-cima-para-baixo, através do recurso ao mesmo tipo de metodologias que para a abordagem analítica (por analogia, por dados históricos e pela técnica Delphi) ou a ferramentas algorítmicas. É a abordagem holística. - O primeiro passo para uma estimativa eficaz do projeto consiste na estimativa precisa da dimensão do software. As fontes de informação relativas ao âmbito do projeto devem, sempre que possível, começar com descrições formais dos requisitos - por exemplo, uma especificação dos requisitos do cliente, um pedido de proposta, uma especificação de sistema ou uma especificação de requisitos para o software. A Figura 7.5 ilustra de forma esquemática o processo básico de estimar. Figura 7.5 - Processo básico de estimar Se o gestor de projeto estiver a (re)estimar o projeto em fases já avançadas, podem usar- -se documentos do desenho para providenciar detalhes adicionais. A falta de uma descrição formal do âmbito não deve constituir impedimento para a realização de uma estimativa inicial do projeto. Por vezes, à partida tem-se apenas uma descrição verbal ou um esboço em papel. Em qualquer das situações, o gestor de projeto deve comunicar o nível de risco e de incerteza a todos os intervenientes, e deve refazer a estimativa logo que disponha de mais informação sobre o âmbito. A dimensão do produto de software pode ser estimada de duas formas: - - #### 7.8.1 Análise dos Pontos de Função Em 1970, Allan Albrecht, da IBM, introduziu o método dos pontos de função. O desenho original foi refinado e expandido num posterior documento de medida da produtividade, divulgado em 1984, o qual introduzia no domínio público um sistema de pontos de função utilizável \[Albrecht, 1984\] \[Varun et al., 2013\]. **A análise dos pontos de função** é um método de medida da dimensão de projetos de software, baseado na visão do utilizador final sobre as funções requeridas para a aplicação, independentemente da tecnologia, ferramentas ou linguagem de programação utilizadas. Os pontos de função classificam estas visões nas seguintes funcionalidades: - - - - - A cada uma destas visões é atribuído um peso diferente, conforme se vê na Tabela 7.1. Nos estágios iniciais do ciclo de vida do desenvolvimento, cada um dos tipos de função mencionados torna-se exposto a nível funcional e é-lhe atribuído um valor ponderado com base nestas métricas-padrão. O total destes tipos de função ponderados transforma-se nos pontos de função não ajustados (Unadjusted Function Points - UFP). Tabela 7.1 - Visões funcionais e fatores de ponderação Os UFP tornam-se ajustados através da avaliação de 14 características gerais do sistema, que medem os requisitos que afetam a aplicação na sua globalidade. Cada característica geral do sistema é classificada numa escala de grau de influência, que varia entre 0 (não presente) e 5 (forte influência). A Tabela 7.2 identifica as 14 características gerais do sistema que devem ser avaliadas. **Visão Funcional** - - - - - - - - - - - - - - **Fator de Ponderação:** - - - - - - - - - - - - - - - Tabela 7.2 -- Características gerais do sistema a avaliar no método dos pontos de função A soma das pontuações das 14 características ordenadas constitui o grau de influência (Degree of Influence - DI) total e é convertido num **fator de complexidade técnica** (Technical Complexity Factor - TCF) através do uso da seguinte formula: TCF = 0,65 +0,01 \* DI Os **pontos de função** (Function Points - FP), ou a dimensão relativa do sistema, são calculados pela seguinte expressão \[Varun et al., 2013\]: FP= UFP\* TCF Como os pontos de função são derivados da informação disponível após a especificação de requisitos, mas antes do desenho, as estimativas estão disponíveis no princípio do ciclo de vida. Este é um dos motivos por que o método dos pontos de função tem tanto sucesso. Os pontos de função medem a dimensão de um projeto de software. Duas métricas de pontos de função frequentemente calculadas são os pontos de função implementados por pessoa/mês e pontos de função implementados por mês de calendário. Os pontos de função implementados por pessoa/mês indicam a quantidade de esforço aplicado no desenvolvimento do sistema. **Exemplo:** Uma aplicação com 500 pontos de função, desenvolvida por 10 pessoas em 10 meses, tem uma taxa de produtividade de 5 pontos de função por pessoa/mês. Os pontos de função implementados por mês de calendário indicam a velocidade com que o sistema pode ser desenvolvido. No exemplo acima, foram implementados 50 pontos de função por mês de calendário. As métricas estritas de pontos de função forçam o gestor de projeto e o engenheiro de sistemas a pensar em termos de pontos de função, ou a ter uma métrica que corresponda a um certo nível de produtividade em pontos de função por pessoas e mês de calendário. Carper Jones \[Jones, 1997\] ajuda a ultrapassar esta lacuna, ao apresentar taxas de produtividade para aplicações comerciais, sistemas de informação geográfica (SIG) e sistemas militares. Os pontos de função devem ser contados por peritos. Tal desencadeou a formação do International Function Point Users Group (IFPUG)21, uma organização que publica e promove (entre outras coisas) linhas de orientação de contagem-padrão para a análise de pontos de função. As últimas regras de contagem estão definidas na release 4.3.1 do Function Point Counting Practices Manual, produzido e mantido pelo IFPUG, e que tem contribuído para o sucesso e normalização dos pontos de função, a nível mundial. Diversos estudos têm evidenciado que a análise de pontos de função é bastante consistente com a realidade. Vários investigadores liderados por Kemerer \[Kemerer et al., 1992\] publicaram um volumoso estudo de 65 projetos de processamento transacional de Management Information Systems (MIS), no Massachussets Institute of Technology (MIT). E descobriram uma consistência de ± 12%. ### 7.9 Estimar a Partir de Uma Data de Fim Fixada Os projetos têm, muitas vezes, uma data de fim especificada, que não é negociável. **Exemplos:** - - Se o gestor de projeto já sabe de quanto tempo dispõe, a única coisa que pode fazer é negociar o conjunto de funcionalidades que pode implementar no lapso de tempo disponível. Como o tempo disponível é sempre pouco em comparação com aquilo que se tem de fazer, a funcionalidade tem de ser priorizada e selecionada de modo a poder entregar-se um pacote coerente de software. Trabalhar em sentido inverso não significa que se saltem passos no processo básico de estimar descrito anteriormente. Ainda é necessário dimensionar o produto - embora, neste caso, ele tenha de ser decomposto num conjunto de peças do produto a entregar, que se e estimar o esforço, o tempo e o custo. É aqui que as podem selecionar, ou remover ferramentas de apoio ao processo de estimar podem ser realmente úteis. Tentar ajustar um conjunto de funcionalidades num intervalo de tempo fixo exige a simulação de um certo número de cenários (análise what if?). Fazer isso manualmente exigiria demasiado tempo e esforço - algumas ferramentas possibilitam a elaboração de várias opções, de forma fácil e rápida. ### 7.10 Precisão das Estimativas As estimativas efetuadas no início do projeto não são tão precisas como as estimativas realizadas mais tarde. É um facto simples que adquirimos mais conhecimento à medida que o projeto avança. As estimativas serão sempre sujeitas a caprichos da natureza e outros eventos imprevisíveis. Apenas podemos esperar adquirir algum conhecimento ao longo do projeto que nos permita melhorar as estimativas. No modelo de planeamento do projeto de-cima-para-baixo, começamos com estimativas "aproximadas\", com o objetivo de melhorar a respetiva precisão numa fase mais adiantada do projeto. A gestão e o cliente devem estar conscientes desta abordagem. Muitas pessoas têm o hábito (errado) de assumir que um número, uma vez escrito, é absolutamente correto e inviolável, independentemente das circunstâncias em que o número foi determinado. A estimativa de software é um processo de refinamento gradual. No início do projeto existe apenas uma imagem difusa do que se tem de construir. O resto do projeto consumido a tornar essa imagem mais nítida. Como a imagem do software a construir não está clara, a estimativa do tempo e do esforço necessários para o construir será igualmente pouco precisa. Somente quando o software a desenvolver fica mais nítido, é que a estimativa se torna mais clara. Daí o argumento de que a estimativa do projeto de software é um processo de refinamento gradual. Sempre que é gerada uma estimativa, todos gostam de saber o grau de proximidade dos números face à realidade. O problema é que não é possível saber isso até ao final do projeto - e a equipa tem de viver com essa incerteza. Naturalmente, o gestor de projeto quer que todas as estimativas sejam tão precisas quanto possível, em função dos dados disponíveis no momento da sua realização. E, claro, o gestor de projeto não quer apresentar a estimativa de uma forma que inspire um falso sentido de confiança nos números. Mas o que é que significa uma estimativa \"precisa\"? A precisão é uma indicação do grau de proximidade de algo, face à realidade. **Exemplo:** Uma estimativa de dimensão de 70 a 80 milhares de linhas de código (MLC) pode ser a mais precisa que é possível obter no final da fase de especificação de requisitos de um projeto. Se simplificarmos a estimativa para 75 MLC, pode parecer mais minuciosa mas, na realidade, é menos precisa. Se a estimativa precisa da dimensão for um intervalo, em vez de um valor único, então todos os valores calculados a partir dessa estimativa (por exemplo, esforço, prazo, custo) devem ser igualmente representados como um intervalo. Se, durante o ciclo de vida de um projeto, forem efetuadas várias estimativas à medida que o produto é especificado com maior detalhe, o intervalo irá diminuir e a estimativa aproximar-se-á daquilo que eventualmente serão os valores dos custos para o produto ou sistema que se está a desenvolver. Esta característica das estimativas está graficamente representada na Figura 7.6, através do denominado cone de incerteza. Figura 7.6-Convergência das estimativas (adaptado de: \[Boehm et al., 2000\]) Pode, evidentemente, ter-se em consideração outros fatores importantes que afetam a precisão das estimativas, como, por exemplo: - - - - - ### 7.11 Compreender os Compromissos O trabalho real do projeto começa após a elaboração da estimativa - encontrar uma combinação de funcionalidade, prazo, custo e dimensão da equipa que possa ser aceite pela gestão e pelo cliente. É aqui que se revela fundamental uma sólida compreensão das relações entre estas variáveis e que é muito útil dispor de diferentes estimativas do projeto, que revelem os compromissos, para estabelecer os limites desejáveis. Durante esta fase de \"ajustamento\" é importante ter em mente algumas regras simples: - - - - - - Figura 7.7 - Relação entre custo e prazo, num projeto de software - - - - É interessante observar as reações das pessoas que estão a aprender a estimar projetos quando se lhes pede que efetuem várias estimativas para um projeto usando várias opções. A maioria das pessoas, ao analisar os resultados, fica assustada com as consequências dos diferentes compromissos. A Tabela 7.3 mostra um exemplo de três opções diferentes p um projeto com 75 MLC. Tabela 7.3 - Três diferentes estimativas para um projeto com 75 MLC Como se pode ver na Tabela 7.3, embora a diferença entre o prazo nominal e o menor prazo possível para o projeto seja apenas de um pouco mais de 2 meses, para atingir esse prazo o pico do pessoal teria de aumentar em quase 10 pessoas e o custo aumentaria mais de 870 000€. Estes resultados levantam duas questões: - - Se para alguns projetos a importância da diminuição do prazo pode justificar qualquer custo, para outros (eventualmente a maioria) não. Nem todos os projetos apresentam diferenças tão significativas entre opções de estimativas; no entanto, a relação dimensão/esforço/prazo/pessoal/custo segue algumas regras básicas que não se podem contornar. A posse de várias estimativas disponíveis, enquanto se discute a estimativa de um projeto, assegura que todos os envolvidos podem ver essas regras básicas em ação e podem tomar decisões devidamente informadas. ### 7.12 Estimar Projetos de Manutenção e Novos Desenvolvimentos A indústria de software realiza muitos mais trabalhos de manutenção e melhoria sobre produtos existentes do que desenvolvimentos completamente novos. A maioria dos projetos de manutenção é uma combinação de desenvolvimento novo e adaptação de software existente. Embora os passos que conduzem à estimativa já descritos ainda se possam aplicar a projetos de manutenção e melhoria, têm de se considerar algumas questões: - - - - Alguns modelos existentes procuram tratar este problema. No entanto, neste momento, existe muito mais suporte, orientação e discussão disponíveis para estimar novos desenvolvimentos do que para estimar projetos de manutenção e melhoria. ### 7.13 Estimar Pequenos Projetos Muitas pessoas trabalham em projetos de dimensão reduzida, que são caracterizados por incluírem uma ou duas pessoas e terem um prazo de menos de 6 meses. Os atuais modelos não estão calibrados para pequenos projetos, de modo que a sua utilidade é reduzida, ou mesmo nula, a não ser que possam ser adequadamente ajustados mediante uso de dados históricos dos projetos pequenos de uma organização. As estimativas para pequenos projetos estão fortemente dependentes das aptidões do(s) indivíduo(s) que realiza(m) o trabalho e, por isso, são mais bem estimados diretamente por quem está designado para o trabalho. Uma abordagem como o Personal Software Process (PSP) de Watts Humphrey \[Humphrey, 1989\] tem uma aplicabilidade muito maior na estimativa de pequenos projetos. ### 7.14 Estimar um Projeto num Novo Domínio Como é que se estima um projeto num novo domínio aplicacional em que a nossa organização não tem experiência anterior? Se for um \"projeto de ponta\", também ninguém terá qualquer experiência anterior. A primeira vez que fazemos algo, estamos a lidar com muito mais incertezas e a única forma de proceder é usar de extrema precaução e gerir cuidadosamente o projeto. Estes projetos são sempre de alto risco e geralmente subestimados, independentemente do processo usado para estimar. Conhecendo estes dois factos, o gestor de projeto deve: - - - Um passo-chave que muitas vezes não é seguido é a escolha de um modelo de processo (ciclo e vida do projeto) que absorva da melhor forma a incerteza de projetos deste tipo. Um ciclo de vida iterativo, como o modelo de entregas incrementais, em que o trabalho é realizado em partes, ou o modelo em espiral, em que se efetua uma revisão das estimativas e uma avaliação do risco antes de prosseguir para cada nova etapa, constitui frequentemente uma abordagem mais eficaz que o tradicional modelo em cascata. ### 7.15 Aptidão para Desenvolver Software A aptidão para desenvolver e entregar software de uma forma oportuna e económica está dependente de um conjunto de fatores de risco. Esses fatores incluem questões como o modelo do processo de software que será usado, os níveis das aptidões do pessoal (incluindo pessoal do utilizador) que irá estar envolvido, o nível de automatização que será utilizado e as influências do ambiente fisico (por exemplo, as condições do desenvolvimento) e empresarial (por exemplo, os requisitos legais e da concorrência). A realidade é que existem numerosos fatores que influenciam a nossa capacidade para desenvolver software em tempo oportuno e com elevada qualidade. O Quadro 7.1 mostra alguns exemplos de fatores influenciadores que devem ser avaliados, a fim de produzir uma estimativa precisa. **Gestão:** - - - - **Construção:** - - - - - **Definição:** - - - - - **Testes:** - - - - - - **Desenho:** - - - - - **Ambiente:** - - - - - Quadro 7.1 - Fatores influenciadores do processo de estimar A chave para o uso eficaz destes fatores reside no desenvolvimento de uma baseline histórica de desempenho. As organizações deverão desenvolver perfis que reflitam o ritmo de entregas para um projeto de uma dada dimensão, complexidade e fatores de risco. Esta informação, por seu turno, pode ser usada para prever e explorar cenários simulados (análise what if?) em projetos futuros. ### 7.16 Algumas Sugestões Úteis Eis algumas sugestões destinadas a tornar o processo de estimar mais preciso e fiável: \- - - - - - - -