Artigos Canal Mais Artigo Engenharia de Software 12 - Estimativas de Software - Fundamentos, Técnicas e Modelos – Parte 2

Esse artigo faz parte da revista Engenharia de Software 12 edição especial. Clique aqui para ler todos os artigos desta edição

Planejamento

Estimativas de Software - Fundamentos, Técnicas e Modelos – Parte 2

O COCOMOII e uma introdução ao seu processo de calibração

 

 

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, 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 diferentes atos, 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 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 um 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.

COCOMOII

No artigo da edição anterior, os fundamentos para estimativas profissionais foram apresentados; algumas técnicas de estimativa exploradas, ainda que superficialmente; e foi feita a introdução sobre o COCOMOII. O objetivo deste texto é dar seqüência na exploração desse modelo e conhecer os passos comuns necessários à realização de qualquer estudo de produtividade e da aplicação dos seus resultados no planejamento de projetos de software. Nesse processo, vários dos conceitos básicos e gerais apresentados na edição anterior se mostram úteis e aplicados ao modelo de estimativas em questão.

A definição das fases da produção de software numa perspectiva gerencial e dos marcos que as delimitam

Um dos primeiros desafios ao conceber um modelo de custos para a engenharia de software é estabelecer um conjunto de premissas que permitam utilizar o modelo consistentemente entre diferentes organizações de software, usando diferentes abordagens e estratégias para entregar os produtos de software demandados pelos seus clientes.

O COCOMOII define e estabelece uma série de premissas que viabilizam esse objetivo. Elas também permitem que o modelo seja de muito valor na realização de estudos de produtividade na medida em que facilita a normalização na elaboração de estimativas (dados previstos), e a subseqüente análise do que foi realizado (dados realizados).

O primeiro passo nessa exploração do COCOMOII é construir um conhecimento daquilo que o modelo define e estabelece como premissa. Nesse processo, a divisão do projeto em fases (não necessariamente em disciplinas como análise de requisitos, modelagem, codificação e testes, por exemplo) é o primeiro passo nessa construção.

As fases devem ser externas à função de desenvolvimento e manutenção de software de tal forma que possam ser usadas para fins de planejamento de alto nível, quando ainda se tem poucos detalhes sobre o objeto do trabalho e os riscos de escopo e produtividade associados ao mesmo ainda são muitos. Os responsáveis pela elaboração do COCOMOII não têm a intenção de revolucionar no que diz respeito a essa definição nas fases do desenvolvimento de software e buscam usar o que é geralmente aceito pela comunidade de engenharia de software: a estratégia de desenvolvimento em cascata e a abordagem denominada de processo unificado.

A Figura 1 é chave para o entendimento do COCOMOII e será mais explorada na medida em que for sendo construído o conhecimento sobre o modelo. Neste ponto, ela ilustra os marcos entre as fases das diferentes estratégias de desenvolvimento citadas.

Figura 1. Fases do ciclo de vida e a sua integração com o COCOMOII

As fases de iniciação, elaboração, construção e transição são aquelas definidas pelo Rational Unified Process (RUP), enquanto as fases de planos e requisitos, projeto preliminar, projeto detalhado, codificação e testes de unidade, testes e integração são aquelas encontradas em projetos utilizando um ciclo de vida em cascata (waterfall). O COCOMOII identifica e posiciona marcos comuns entre essas duas diferentes estratégias de desenvolvimento citadas, esse nivelamento é estabelecido com base nos produtos que se espera receber do projeto nesses marcos. Isso permite: (a) que sejam feitas estimativas por fase, o que facilita o planejamento na medida em que as diferentes fases têm maior intensidade de determinados tipos de trabalho com diferentes perfis de recursos humanos necessários; (b) que o responsável pela estimativa se localize no tempo, no momento do projeto e, com isso, possa estabelecer o quanto já deveria ter sido feito e o quanto resta a fazer; e (c) que haja condições para uma análise de produtividade econômica (considerado como um requisito necessário para estimativas de qualidade).

A Tabela 1 descreve os acrônimos dos marcos apresentados na Figura 1. A definição desses marcos não é do COCOMOII, que buscou usar padrões reconhecidos e estabelecidos, estando sua qualificação completa fora do escopo deste texto.

 

Marcos para Gestão do Processo

Waterfall

RUP

LCR – Revisão de Conceito do Ciclo de Vida (Life Cycle Concept Review)

IRR – Revisão de Prontidão de Concepção

SRR – Revisão de Requisitos do Software (Software Requirements Review)

LCO – Revisão de Objetivos do Ciclo de Vida (Life Cycle Objectives Review)

PDR – Revisão de Projeto do Produto (Product Design Review)

LCA – Revisão da Arquitetura do Ciclo de Vida (Life Cycle Architecture Review)

CDR – Revisão de Projeto Crítico (Critical Design Review)

IOC – Capacidade Operacional Inicial (Initial Operational Capability)

UTC – Critério de Teste de Unidade (Unit Test criteria)

PRR – Revisão de Liberação do Produto (Product Release Review)

SAR – Revisão de Aceitação do Software (Software Acceptance Review)

 

Tabela 1. Marcos conforme a estratégia de processo de desenvolvimento para fins de gestão

Na experiência do autor deste texto, ainda há na comunidade de profissionais de TI brasileira uma certa dificuldade em compreender a dinâmica nos processos de desenvolvimento iterativos e incrementais. Muitos utilizam o vocabulário e a terminologia do RUP, porém trabalham na verdade com um desenvolvimento em cascata.

De forma simplificada, estratégias de desenvolvimento baseadas no processo unificado buscam a realização de atividades de levantamento de requisitos em determinados pacotes de trabalho enquanto já há codificação ou modelagem de outros.

Observar o processo unificado não impede que haja fases definidas para fins de gerenciamento externo. Independentemente da estratégia de desenvolvimento utilizada, os clientes, aqueles que patrocinam o empreendimento, esperam uma série de produtos por eles reconhecidos e aceitos conforme o ciclo de vida do desenvolvimento evolui. Alguns desses produtos são definidos entre esses últimos e os responsáveis pela função de desenvolvimento no âmbito do próprio projeto já em execução e com base em princípios previamente definidos.

Por exemplo, uma empresa atuante em todo o país é responsável pela evolução de seu produto de gestão de recursos humanos em janelas sucessivas de três meses (time box). Nesse cenário, é a quantidade e tamanho das demandas que se ajusta ao prazo, e não o contrário. Procura-se atender ao maior número possível de demandas de melhorias em cada versão com um estoque de trabalho essencialmente constante. Quem cumpre o papel de demandante da função de desenvolvimento é a função de planejamento, que pode ser vista como um preposto interno, do cliente externo.

A unidade de gestão originalmente utilizada no processo de atendimento das demandas é o resultado da ação de um arquiteto de software, técnico, e não tem associado a ela um significado para os profissionais da função de planejamento. Essa unidade de gestão torna-se um pacote de trabalho que passa por diferentes etapas durante o seu atendimento na função de desenvolvimento. O processamento desse pacote de trabalho segue uma estratégia essencialmente em cascata. As etapas existentes para fins de acompanhamento do progresso são relativas a cada pacote de trabalho individualmente, e não para o projeto como um todo.

Em outras palavras, o cliente não tem condição alguma de acompanhar o seu atendimento e fica numa posição em que tem que confiar que a função de desenvolvimento atingirá os objetivos estabelecidos em comum. Esse cenário impede uma gestão externa à função de desenvolvimento. Falta uma unidade de gestão que: (a) tenha significado para a função de planejamento; (b) possa ser medida de forma relevante à função de planejamento; (c) apóie o planejamento e acompanhamento das fases relativas à execução do projeto como um todo.

Para mudar essa situação, foi estabelecida uma unidade de gestão com significado para o departamento de planejamento que cumpre o papel de uma Ordem de Serviço, e foram definidas fases para o acompanhamento do projeto como um todo. São elas: Negociação/Planejamento da Versão; Concepção; Elaboração; Construção; e Transição. A fase de Negociação/Planejamento de Versão compreende:

a)     Estimativas de escopo e esforço – elaboração do cronograma macro considerando um prazo total de três meses para as fases de concepção, elaboração, construção e transição usando os percentuais do prazo em cada fase (Tabela 2).

 

Esforço

Prazo

Negociação / Planejamento

8,54%

50,00%

Concepção

11,56%

13,33%

Elaboração

12,70%

66,67%

Construção

64,36%

66,67%

Transição

2,85%

16,67%

Tabela 2. Distribuição do esforço e prazo.

Os percentuais descritos na Tabela 2 foram obtidos por aproximação do esforço gasto no cenário atual onde não há utilização de fases externas e servem de referência preliminar. Na medida em que houver a institucionalização das mudanças propostas, esses percentuais devem ser revistos e gradualmente cumprirão um papel mais importante na definição do cronograma macro citado.

b)     Definição, para cada ordem de serviço, de quais serão os produtos esperados para que a fase de Elaboração seja considerada concluída. A política é que a especificação funcional das ordens de serviço mais críticas esteja concluída e os riscos arquiteturais prioritários estejam resolvidos. Nesse ponto, espera-se que até 40% do prazo tenha se passado e até 25% do esforço consumido.

c)     Marco de término: conjunto com todas as ordens de serviço da versão com o escopo validado e a primeira planilha de contagem de PF por produto.

d)     ...

Quer ler esse conteúdo completo? Tenha acesso completo