Qualquer um que vive na área já deve ter visto o clássico ciclo de vida do desenvolvimento de sistemas. Salvo pequenas variações para cada modelo ou peculiaridades de cada projeto, o tal ciclo seria composto do estudo de viabilidade, análise, modelagem, implementação e implantação. Há quem considere a fase de testes uma fase independente, o que não faz grande diferença prática.

Se não há grandes divergências quanto ao ciclo em si, o caro leitor já deve estar curioso para saber do que trata este texto ou está tentado a abandonar a leitura por aqui. Antes que isto ocorra, esclareço: o objeto deste texto é a causa da briga entre analistas e programadores: o tamanho e importância das fases. São basicamente quatro perguntas :

• Quando começar a implementação, ou seja a codificar ?
• Pode a implementação concorrer no tempo com a análise ? E com a modelagem ?
• Quando termina a fase de modelagem ?
• A mesma pessoa que fez a análise pode fazer a codificação ?

Hoje os tempos são outros, ao mesmo tempo que as máquinas evoluíram a ponto de diminuir a importância de parte da atividade pré- codificação, como o famoso teste de mesa, as ferramentas de desenvolvimentos evoluíram para interfaces visuais e amigáveis. O resultado é que quase todo mundo hoje é capaz de desenvolver sistemas. Esses dois fatores combinados resulta numa desvalorização da fase de análise.

Uma pessoa é capaz de criar algo funcional usando algo como o Visual Basic, sem sequer imaginar o que seja objeto, classe, método ou mensagem. Mas não só os leigos são adeptos do Visual Drag and Drop, Just do it, muitos bons profissionais da área abandonaram grande parte do seu conhecimento teórico e também adotaram a metodologia Just in Time de desenvolvimento. Toda esta gente é tecnicamente um programador de sistemas, surge até o que tem-se chamado de Analista Programador, na verdade um programador com salário mais alto.

Tudo correria bem, cada grupo e suas convicções trabalhariam tranqüilamente, se não houvesse o encontro na mesma esquipe de membros dos dois grupos. Tudo transcorre bem no início, nas fases de estudo de viabilidade e de requisitos. As divergências aparecem quando a fase de projeto começa a se alongar e os programadores começam a ficar ansiosos para codificar. Normalmente o que se faz é buscar tarefas periféricas para ir distraindo o programador até que os analistas consigam adiantar o projeto até um ponto satisfatório.

O analista:

• No desenvolvimento sem análise, gasta-se cerca de 80% do tempo refazendo código e corrigindo bugs. A troca de um membro da equipe é muito mais traumática.

O programador:

• O cliente paga pelo programa rodando, pelo código. ë muito mais complicado justificar o tempo gasta, sem código para ser mostrado. A análise não interessa para o cliente.

De fato ambos os argumentos são pertinentes, de modo que não há como definir de que lado está a razão. A grande questão é como administrar e tirar o máximo proveito de uma equipe mista.

Cada um tem de atuar onde é mais forte. Não adianta muito forçar um programador a fazer análise. Logo, até que haja código a ser escrito, os programadores estarão subaproveitados. Uma boa análise certamente decomporá o sistema em módulos com funcionalidade própria. Alguns módulos podem ser definidos quase que totalmente logo no início do projeto. Um exemplo usual é a comunicação como banco de dados, mas há diversas outras possibilidades. Numa equipe onde a utilização de recursos é otimizada, esses módulos serão projetados o quanto antes e ,enquanto são projetados os demais módulos, os programadores já estarão trabalhando na codificação dos módulos iniciais.

• Pode a implementação concorrer no tempo com a análise ? E com a modelagem ?

Não há nada que impeça que os programadores estejam codificando um módulo, enquanto os analistas sequer analisaram um outro módulo. Fazendo a analogia com as clássicas árvores de busca, basta que o desenvolvimento seja feito, pelo menos em parte, em profundidade e não em largura , como os analistas tendem a pensar de início.

• Quando termina a fase de modelagem ?

Há uma máxima na computação que diz que um sistema jamais estará realmente finalizado, sempre há o que alterar, corrigir ou melhorar. Um erro que muitos de nós cometemos é não manter a sincronização entre a análise, o modelo e a implementação. Muitas vezes é tão prático corrigir um bug ou fazer uma alteração, que sequer passa-nos pela cabeça voltarmos ao modelo. Quando estamos utilizando ao máximo os recursos que dispomos, o modelo está ao lado da implementação e , ao contrário do que possa parecer, o trabalho dos analistas não terminará antes que o dos programadores.

• Quando termina a fase de modelagem ?

Esta é a pergunta mais fácil de responder: NUNCA. Se um sistema jamais está pronto e se o projeto deve estar sincronizado com a implementação, o projeto, da mesma forma, jamais estará concluído.

• A mesma pessoa que fez a análise pode fazer a codificação ?

Até pode, mas será que estaremos tirando o máximo dos recursos disponíveis? Evidentemente que não. Pelé era um bom goleiro, chegou até a atuar nesta posição algumas vezes, por quê então ele não jogava metade do tempo no gol e outra metade como ponta de lança ?

Afinal quando será desligado o último mainframe ?