Estimativas de Esforço em Projetos de Software

Estimativas de Esforço em Projetos de Software

1. DEFINIÇÃO

   • O Gerenciamento de Projetos é a aplicação de conhecimentos, habilidades, e técnicas para projetar atividades que visem atingir ou exceder as necessidades e expectativas das partes envolvidas, com relação ao projeto. O ato de atingir ou exceder as necessidades e expectativas das partes envolvidas, envolve o equilíbrio entre demandas concorrentes de escopo, prazo, custo e qualidade

2. OBJETIVO

   • Um dos objetivos da Gerência de Projetos é identificar, estabelecer, coordenar, e monitorar as atividades, tarefas e recursos necessários de um projeto para produzir um produto e/ou serviço, dentro do contexto dos requisitos e restrições do projeto [ABNT, 1998]. Um segundo objetivo é acompanhar, dirigir e registrar os resultados produzidos e os recursos consumidos no desenrolar da execução do projeto, confrontando-os com o que era esperado pelos planos. Como conseqüência desse confronto o gerente estará capacitado a tomar medidas corretivas racionais, sempre que a execução se desviar mais do que o tolerado do que era esperado.

3. IMPORTÂNCIA E MOTIVAÇÃO

   • O PROBLEMA
     • Os problemas relativos à previsibilidade de projetos constituem uma das preocupações da indústria de software. Em 2000 o tempo realizado dos projetos de software excedia em 50% o tempo planejado no cronograma do projeto. Em 1994 foi relatado que apenas 16% dos projetos de software atingem o seu objetivo dentro do cronograma e do orçamento previstos. A principais causas para isso são estimativas feitas baseadas em informação insuficiente (usualmente sem que a especificação de requisitos esteja disponível), estimativas feitas para satisfazer a direção, e projetos com requisitos demasiadamente flutuantes. Em 2001 os dados mostraram as seguintes estatísticas:
       • 27% dos projetos de software são finalizados no tempo e custo previstos;
       • 40% dos projetos são cancelados antes de finalizarem;
       • 42% dos projetos não apresentam as funcionalidades propostas originalmente
       • 50% dos projetos custam em média 180% a mais da estimativa original
     • Resposta
       • Definir métodos e processos a fim de poder estimar qualitativamente e quantativamente o esforço de projeto de software de forma acurada assim tendo maior visão do todo atingindo um resultado ótimo à custos estimados

4. TIPOS DE ESTIMATIVAS

   • Estimativas de Tamanho
   • Estimativas de Prazo
   • Estimativas de Esforço
   • Estimativas de Custo
   • Estimativas de Recursos Computacionais Críticos
   • Técnicas de Estimativas
     • Estimativas Análogas
       • Esse tipo de estimativa pode ser aplicado tanto para estimativa de tempo quanto para de custos, e baseia-se em opiniões especializadas e informações históricas. O nível de precisão dessa estimativa depende da semelhança do projeto ou das atividades com o histórico disponível.
     • Estimativa ágil: Planning Poker
       • Planning Poker é uma técnica de estimativa voltada para as metodologias ágeis. O Planning Poker pode ser considerado a combinação de três técnicas menos comuns de métodos de estimativas ágeis: opinião de especialista, analogia e desagregação, o que a torna uma prática bastante interativa e prática. Consiste-se na obtenção de estimativa através de um jogo de cartas. A ideia principal é permitir que todos os membros da equipe de desenvolvimento (programadores, testadores, design, analistas, etc.) participem colocando a sua visão de complexidade, levando em consideração o fator tempo e esforço para pontuar a estória e após juntos chegar a um denominador comum na equipe. Nas metodologias ágeis, a equipe não deverá exceder a dez pessoas.
     • Modelo PERT
       • O método PERT (Program Evaluation and Review Technique - Avaliação do Programa e Técnica de Revisão), muitas vezes acompanhado do CPM (Critical Path Method - Método do Caminho Crítico), é uma técnica que permite gerenciar o calendário de um projeto. A sua representação gráfica é como uma rede de tarefas cujo encadeamento permite alcançar os objetivos definidos no projeto. Ele foi concebido pela Marinha dos Estados Unidos para coordenar os trabalhos de vários milhares de pessoas visando a realização das ogivas nucleares POLARIS. Assim, o método PERT implica, na sua fase preliminar, uma segmentação precisa do projeto em tarefas, a estimativa da duração de cada tarefa e a nomeação de um chefe de projeto, encarregado de assegurar o acompanhamento do projeto, de informar, se for o caso, e de tomar decisões caso haja mudanças em relação às previsões.
     • Técnicas de tomada de decisão em grupo (Delphi)
       • A técnica Delphi envolve vários estimadores que dão o valor das estimativas anonimamente, onde suas respostas são comparadas e os resultados são enviados de volta para uma revisão adicional até que se chegue num consenso.
       • Passo 1: Escolha um Facilitador
         • O primeiro passo é escolher um facilitador. O gerente mesmo pode querer assumir esse papel, mas pode ser mais interessante utilizar outra pessoa da organização, com uma postura de neutralidade em relação aos objetivos e resultados do projeto. É importante que o facilitador esteja familiarizado com pesquisas investigatórias e coleta e tratamento de dados
           • Passo 2: Identifique seus especialistas
             • A técnica Delphi é um painel com especialistas. Este painel pode ser a sua equipe de projeto, incluindo o cliente, representantes das partes interessadas, e até mesmo outros especialistas de sua organização ou indústria.Um especialista é “qualquer pessoa com conhecimentos e experiência relevantes de um tópico em particular.”
               • Passo 3: Definir o problema
                 • Qual é o problema ou assunto que você está procurando entender? Para isto é crucial que você forneça uma definição clara e abrangente, para garantir que os peritos entendam exatamente o que estão comentando.
                   • Passo 4: Primeira rodada de perguntas
                     • São aplicadas perguntas gerais para garantir uma compreensão ampla das opiniões dos peritos sobre os eventos futuros. As perguntas podem ser feitas sob a forma de questionários ou de enquetes, de forma a resumir as respostas e assim evitar conteúdos e comentários irrelevantes e facilitar o alinhamento de pontos em comum entre as opiniões
                       • Passo 5: Segunda rodada de perguntas
                         • A segunda rodada deve aprofundar o tema e esclarecer questões especificas, identificadas a partir das respostas da primeira rodada. Da mesma forma, pode-se utilizar questionários e enquetes. Novamente, é necessário reunir e resumir os resultados, remover conteúdos irrelevantes e fixar o olhar no terreno comum, a convergência entre as opiniões. Lembre-se, estamos trabalhando para construir o consenso.
                           • Passo 6: Terceira rodada de perguntas
                             • O questionário final deve se concentrar em apoiar a tomada de decisão em relação ao escopo e aos riscos associados no projeto. E deve concentrar-se na convergência das opiniões, nos pontos em que os especialistas estão de acordo. Em casos mais complexos pode ser interessante, ou necessário, fazer mais de três rodadas para se chegar ao consenso ou ao nível de segurança suficiente à tomada de decisão.
                               • Passo 7: A tomada de decisão
                                 • Espera-se que ao final das várias rodadas os especialistas tenham chegado a um consenso, e a uma visão convergente dos acontecimentos futuros aos quais o projeto está exposto. Agora é hora de analisar muito bem os resultados, e considerá-los na tomada de decisão em relação ao gerenciamento dos riscos negativos e a exploração dos riscos positivos e das oportunidades do seu projeto.
     • Análise de Reservas
       • A análise de reserva consiste no tempo necessário, extra estimativa, para comportar os riscos do projeto caso eles aconteçam. Esse conceito não insere “gorduras” nas estimativas, pois essas reservas só serão usadas se – e somente se – os riscos acontecerem. Como podemos perceber, os riscos que podem ser identificados pelas premissas e/ou restrições devem ser refletidos nas estimativas.
     • Modelo Matemáticos
       • Pontos de Caso de Uso
         • A análise por ponto de função tem como principal objetivo medir a funcionalidade do sistema tendo como base a visão do usuário, de acordo com as seguintes características: É independente da tecnologia utilizada; Auxilia a produção de resultados consistentes; Baseia-se na visão do usuário; Tem significado para o usuário final; Utiliza-se de estimativas; Passível de automação; Dificuldade por possuir relativa subjetividade por refletir a visão do usuário. A análise por ponto de função (APF) é uma das técnicas mais usadas para se medir projetos de desenvolvimento de software. Seu principal objetivo é estabelecer um tamanho considerando a(s) funcionalidade(s) implementada(s), sempre sob o ponto de vista do usuário. A medida independe da tecnologia utilizada e/ou da linguagem de programação em que a(s) funcionalidade(s) foi implementada.
       • Análise de Pontos por Função
         • A análise por ponto de função tem como principal objetivo medir a funcionalidade do sistema tendo como base a visão do usuário, de acordo com as seguintes características: É independente da tecnologia utilizada; Auxilia a produção de resultados consistentes; Baseia-se na visão do usuário; Tem significado para o usuário final; Utiliza-se de estimativas; Passível de automação; Dificuldade por possuir relativa subjetividade por refletir a visão do usuário. A análise por ponto de função (APF) é uma das técnicas mais usadas para se medir projetos de desenvolvimento de software. Seu principal objetivo é estabelecer um tamanho considerando a(s) funcionalidade(s) implementada(s), sempre sob o ponto de vista do usuário. A medida independe da tecnologia utilizada e/ou da linguagem de programação em que a(s) funcionalidade(s) foi implementada.
       • COCOMO
         • O 'método COCOMO' (ou COnstructive COst MOdel) é um modelo de estimativa do tempo de desenvolvimento de um software. É um modelo estático que calcula o esforço de desenvolvimento de software e seu custo, em função do tamanho de linhas de códigos desenvolvidas.
           • FUNÇÕES
             • E = ab(KLOC)bb
             • D = cb(E)db
             • P = E / D
           • Onde E é o esforço aplicado pela pessoa no mês, D é o tempo de desenvolvimento em meses cronológicos, KLOC é o número calculado de linhas de código para o projeto (expressado em milhares), e P é o número das pessoas necessário. Os coeficientes ab, bb, cb e db são dados na seguinte tabela:

Bilder und Dateien der Mindmap