İstatistiksel Analiz

Os processos de desenvolvimento de software, incluindo o de reengenharia, geral- mente são adaptados ao contexto organizacional. No caso do processo de reengenharia, a adaptação geralmente ocorre de acordo com o tipo de reengenharia ser realizada, ou seja, se é uma reestruturação de código, de dados, se deve haver reestruturação da documenta- ção, etc.

Como um dos objetivos do modelo proposto era o de se manter flexível a essas mudanças de estrutura do processo de reengenharia, ele não foi relacionado a um pro- cesso específico. Porém, como este modelo foi baseado no estudo da prática de estimativa de esforço em algumas organizações de desenvolvimento de software, cabe apresentar uma visão geral de como este modelo poderia se comportar no contexto das organizações estudadas.

As organizações apresentam basicamente dois cenários de desenvolvimento de software: as organizações A e B realizam desenvolvimento para clientes externos, logo, seus projetos são de escopo fechado, com o esforço sendo calculado antes do início do

projeto e mantido durante a execução do mesmo. Já as organizações C e D desenvolvem software para clientes internos, o que permite uma maior flexibilidade na realização das estimativas, podendo estas serem replanejadas a cada módulo do projeto.

A Figura 7.7 apresenta uma visão geral de como o modelo proposto pode se com- portar no contexto de projetos com escopo fechado e no de projetos com escopo aberto. Os números 1, 2, 3 e 4 correspondem aos subprocessos de Planejamento da Estimativa, Estimativa, Monitoramento e Calibragem, e Aprendizagem, respectivamente.

O subprocesso de Planejamento Estratégico foi propositalmente omitido, pois con- forme descrito, este processo deve ser realizado anteriormente ao desenvolvimento de um projeto em particular. Negociação  do Projeto  Encerramento  do Projeto  Desenvolvimento  Pós‐ Desenvolvimento  3  1 2 1 2 3 Projetos de Escopo Fechado  Projetos de Escopo Aberto  4  4 

Requisitos  Projeto  Desen. 

Arquitetura  Código/Teste  Recuperação dos  Requisitos  Recuperação  do Projeto  Engenharia Reversa  Engenharia Direta  Reestruturação de 

documentação  Reestruturação de código  Reestruturação de 

dados 

Figura 7.7 – Modelo de Estimativa de Esforço em Diferentes Contextos de Processos de Reengenharia

A seguir, é feita uma descrição de como o modelo proposto pode ser mapeado para esses contextos.

7.7.1 Projetos de Escopo Fechado

No contexto de projetos de escopo fechado, a estimativa de esforço é planejada (subprocesso Planejamento) e realizada (subprocesso Estimativa) antes do início do pro- jeto, em uma etapa de Negociação do Projeto. Isto ocorre pois a estimativas obtidas neste momento (esforço, custo, prazo) servirão como base para a negociação do contrato junto ao cliente.

Neste tipo de projeto, o principal problema para a estimativa é que nem cliente nem fornecedor conseguem antever todo o escopo do projeto. Com isso, as estimativas feitas nesta fase podem se mostrar inadequadas a medida em que o projeto avança e sua real complexidade é identificada.

O modelo proposto auxilia neste problema sugerindo boas práticas para aumentar a confiança nos dados obtidos nesta fase tais como, realização de pré-projeto, realização de workshop, utilizando do conhecimento de especialistas no sistema e alocando equipe com conhecimento no tipo de projeto a ser desenvolvido.

Outro ponto forte do modelo proposto, para este contexto, é o monitoramento do projeto (subprocesso Monitoramento e Calibragem), que auxiliará na identificação de des- vios ou riscos de desvios nas estimativas realizadas. Este acompanhamento constante também é útil para se estabelecer pontos de atualização da base histórica do projeto, prin- cipalmente se esta coleta não é feita automaticamente. Isto evita que dados desatualizados ou incorretos sejam inseridos ao final do projeto, por falta planejamento de atualização constante da base.

Embora a calibragem das estimativas não seja uma alternativa bem vista neste tipo de projeto, principalmente do ponto de vista do cliente, ela pode ser uma alternativa inevitável, diante da ocorrência de grandes desvios, como foi o caso do Projeto 2, analisado durante o Estudo de Caso (Capítulo 5). Assim, o modelo proposto visa garantir que se é inevitável que ocorra calibragem, que essa seja feita com o maior rigor possível e utilizando os dados do próprio projeto como base.

Por fim, o aprendizado das lições do projeto (subprocesso Aprendizagem) auxiliará na melhoria do processo e na tomada de decisão para projetos futuros.

7.7.2 Projetos de Escopo Aberto

No contexto de projetos com o escopo aberto, a cada módulo de execução do projeto pode ser refeito o planejamento (subprocesso Planejamento) e a realização da esti- mativa (subprocesso Estimativa), assim como o monitoramento e calibragem (subprocesso Monitoramento e Calibragem).

Assim como nos projetos de escopo fechado, neste tipo de projeto o principal pro- blema para a estimativa é que nem cliente nem equipe de desenvolvimento conseguem antever todo o escopo do projeto. A diferença é que aqui há flexibilidade para o replaneja- mento das estimativas caso o escopo sofra mudanças significativas.

Esta flexibilidade faz com que o modelo proposto atue como um facilitador do pro- cesso de estimativa, guiando o planejamento e o monitoramento deste processo. As boas práticas e lições aprendidas podem ser aplicadas para execução do processo de estima- tiva da maneira mais completa e eficiente, sem os desafios inerentes de falta de tempo e recursos.

Por fim, assim como nos projetos de escopo fechado, o aprendizado das lições do projeto (subprocesso Aprendizagem) auxiliará na melhoria do processo e na tomada de decisão para projetos futuros

7.8 Conclusões do Capítulo

Este capítulo apresentou a proposta de um modelo de estimativa de esforço para projetos de reengenharia de software, baseado em boas práticas e lições aprendidas da realização deste processo no contexto real de desenvolvimento de software.

Diferentemente das propostas existentes de apoio a estimativa de esforço em re- engenharia, este modelo não visa prover uma forma de cálculo da estimativa, mas o pro- cesso geral de como essa estimativa deve ser realizada, de maneira a mitigar os possíveis desafios existentes.

Entende-se que a estrutura do processo de estimativa dependerá diretamente do processo de reengenharia adotado, por isso o modelo não foi proposto em relação a um pro- cesso de reengenharia específico, mas sim em um nível de abstração que permite aplicar os subprocessos de estimativa de maneira flexível ao processo geral, conforme os exemplos apresentados.