[b]Analistas X Programadores
[color=darkred]Por Ulysses Monteiro Duarte[/color][/b]
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 ?
Os puristas
Para os engenheiros de software puristas clássicos, a alma do sistema está definida na fase de análise e o corpo na fase de modelagem. A implementação não envolve grande inteligência, é como se o sistema já estivesse pronto e a implementação fosse apenas o girar do interruptor para a posição ON. Por mais que esteja crescendo, este grupo ainda é bem pequeno, a grande maioria dos sistemas desenvolvidos já são iniciados pelo código, documentação são alguns comentários esparsos pelos fontes e análise é o conjunto de rabiscos em que resultou a reunião da equipe. O analista purista domina as ferramentas CASE, metodologias, mas normalmente não se aventura a escrever uma linha de código sequer.
Visual Drag and Drop
Há alguns anos desenvolvimento de sistemas era uma coisa absolutamente desconhecida, atividade restrita a um seleto grupo de gênios, nerds ou malucos, simplesmente. A maioria das ferramentas de desenvolvimento era interpretada ou levava horas para compilar um programa de tamanho médio. Ainda no início dos anos 90 era comum os desenvolvedores compilarem seus programas durante toda a noite, para fazer os testes no dia seguinte. Com toda esta limitação técnica, era fundamental um mínimo de análise e teste antes de ser digitada a primeira linha de código, pois um simples erro de sintaxe poderia custar um dia inteiro de trabalho.
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.
O Confronto
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.
Os argumentos
Tanto analistas clássicos, quanto os programadores têm argumentação forte para defender seu ponto de vista.
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.
Boa convivência
Deixando de lado o radicalismo, há sempre uma forma de ter analistas e programadores em harmonia, fazendo com que as diferenças contribuam para o engrandecimento do grupo como um todo. Como fazer isto? A resposta passa pelas quatro questões iniciais:
Quando começar a implementação, ou seja a codificar ?
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 ?
Equipe nota Dez
[color=red]Para montar uma equipe vencedora não basta ter somente elementos vencedores. É necessário que cada elemento esteja atuando no máximo de sua capacidade e maior tempo possível. Os defensores, defendem e os atacantes, atacam. Com idéias simples podemos garantir a máxima produtividade de nossa equipe e, de quebra, contar com elementos satisfeitos, fazendo aquilo que gostam.[/color]
[color=darkred]Mergulhe no assunto [/color]
Bowles, Joseph E. : Foundation Analysis and Design - Ed. Mcgraw Hill
Yourdon, Edward : Modern Structured Analysis ? Ed. Pearson
Booch, Grady : Object-Oriented Analysis and Design With Applications - Addison-Wesley Pub
Rumbaugh, James: Object-Oriented Modeling and Design - Prentice Hall
Jalote, Pankaj : CMM in Practice: Processes for Executing Software Projects at Infosys - Addison-Wesley Pub
[color=red] Para pensar[/color]
Afinal quando será desligado o último mainframe ?
