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
|
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. "
[...] continue lendo...