Planejamento
Estimativas de Software - Fundamentos, Técnicas e Modelos
Como usar de forma consistente PF, COCOMOII, Simulação de Monte Carlo e seu bom senso em estimativas de software
De que se trata o artigo:
Estimar é uma atividade cotidiana, sistematicamente evitada por aqueles responsáveis pela sua execução. Na busca por superar isso, uma série de técnicas e ferramentas surge no cenário do desenvolvimento e manutenção de sistemas. Muitas vezes, no desespero por uma solução imediata, elas são adotadas independentemente de sua adequação ao cenário específico em que serão introduzidas, ou mesmo apenas com um conhecimento superficial quanto ao seu funcionamento. Ferramentas como o COCOMOII, Simulação de Monte Carlo e Pontos de Função não substituem a analista responsável pela estimativa, que enfrenta a confusão entre o que seja uma estimativa técnica, um compromisso pessoal ou uma meta corporativa.
Para que serve:
Nosso objetivo é diferenciar entre esses diferentes atos e como se portar diante de cada um deles; destacar que simples cuidados podem ajudar a produzir estimativas de muito mais qualidade; apresentar como funciona uma série de ferramentas isoladamente e como integrá-las no estabelecimento de um ambiente propício à melhoria contínua da qualidade das estimativas.
Em que situação o tema é útil:
Nas diferentes situações em que um analista deve se relacionar com seus clientes no sentido de fornecer a sua expectativa para prazo, custo, esforço ou escopo no desenvolvimento e manutenção de software. Visa ajudar a esse analista a identificar os diferentes tipos de solicitação e evitar que ele caia em armadilhas que o leve a assumir compromissos inexeqüíveis. Adicionalmente, é útil também àquele profissional que trabalha na definição de processos de desenvolvimento e seleção de métodos e ferramentas para fins de melhorar o processo de estimativa de sua organização.
Dificuldades ao Estimar
Estimar é um ato cotidiano na vida de todos e isso não é diferente no desenvolvimento e manutenção de sistemas. Apesar disso, uma série de dificuldades de diferentes naturezas faz com que muitos profissionais evitem o seu exercício, ou continuamente adiem a comunicação dos seus resultados. Para ilustrar cinco dessas dificuldades, considere um seguinte pedido por uma estimativa: Qual a duração do deslocamento entre o Rio de Janeiro e Niterói?
Ambigüidade, volatilidade ou falta de clareza
A primeira dificuldade em atender esse pedido é que (1) os objetivos da estimativa, seu escopo, seus requisitos, não estão claros ou completos. Por exemplo, qual o meio de transporte para esse deslocamento? Quando se diz Rio de Janeiro, deve-se entender o centro da cidade ou a Barra da Guaratiba (bairro situado a cerca de 60 quilômetros de distância do centro do Rio de Janeiro)? Analogamente, Niterói se refere ao centro da cidade ou a algum outro ponto? O trajeto será feito utilizando um carro ou alguma outra combinação de transportes públicos e privados? Em qual horário?
Veja que essas questões não demandam um grande volume de análise, mas ainda assim muitas vezes elas são desconsideradas, o mesmo acontecendo na prática do desenvolvimento e manutenção de sistemas.
Garantir medições adequadas e referências válidas
A ambigüidade, volatilidade ou falta de clareza do objeto da estimativa, assim como um domínio de problema não muito bem compreendido, não podem ser empecilhos na realização de uma estimativa, afinal estimar também é relativo a predizer face à incerteza.
O conhecimento incompleto não deve ser uma barreira, desde que existam referências nas quais o analista possa se basear. No processo de estimativa, o projeto ou demanda é fracionado em subconjuntos que, individualmente, podem ser designados como uma unidade para execução. Daí surgem outras duas dificuldades: (2) Garantir que os pacotes de trabalho tenham sido adequadamente medidos; e (3) produzir estimativas que estejam consistentes com realizações passadas em outros projetos.
A construção dessas referências requer dados históricos ou o levantamento dos mesmos – é importante identificar quando não há vontade política para isso, mesmo quando há subsídios técnicos para tal, afinal esse tipo de iniciativa transfere poder de indivíduos para a corporação. Para que esses dados tenham valor efetivo para o processo de estimativa, é necessário que haja um tratamento estatístico dos mesmos, que dificilmente é alcançado na esfera do indivíduo, podendo ser empreendido como uma iniciativa organizacional. Isso porque é tipicamente aí que: (a) Processos são estruturados para estimar e descrever o tamanho do produto de software; (b) as estimativas de custo, esforço, prazo e escopo são relacionados aos valores realizados; (c) os modelos de estimativa utilizados são calibrados às condições locais; e (d) os critérios para normalizar as diferenças entre os projetos e produtos são estabelecidos de tal forma que uma simples extrapolação, não normalizada, de taxa de entrega (Homem-Hora / Ponto de Função) não seja a base para a estimativa.
Diferenciar estimativa, meta e compromisso
Entre aqueles que pedem e fornecem estimativas, existe muita confusão entre o que seja: a) fornecer uma estimativa, um ato técnico que pondera os riscos de escopo e produtividade; b) estipular uma meta para o atendimento de uma demanda ou projeto por uma equipe, um ato gerencial ou político; c) assumir um compromisso, uma decisão pessoal.
Uma estimativa é uma avaliação do provável resultado quantitativo de uma variável de interesse, é a representação de uma chance, um número com uma possibilidade de ser realizado, enquanto meta é um objeto a que se dirige algum intento, e compromisso é uma obrigação tácita ou explícita que pode envolver outras pessoas ou ser auto-imposta. "
[...] continue lendo...