SOFTWARE: Argumentos Clássicos de Brooks

Este texto reflete o entendimento do autor, em apertada síntese, do artigo No Silver Bullet – Essence and Accident in Software Engineering de Frederick P. Brooks, Jr., publicado em 1986.

A construção do artefato de software bem como o gerenciamento de seu processo de desenvolvimento representa um dos grandes desafios das organizações contemporâneas, especialmente, aquelas que têm as operações de negócios sustentadas por sua plataforma de tecnologia da informação. Nesse esteio, o projeto de construção/manutenção de software deve ter um ciclo de vida rápido e, ainda, capaz de produzir artefatos confiáveis, facilmente integráveis e de simples utilização. 

Porém, conforme ensina Brooks (1986), o desafio supra não é simples devido à complexidade intrínseca dos artefatos de software e suas propriedades, quais sejam: complexidade, conformidade, mutabilidade e invisibilidade.

 Ainda, segundo Brooks (1986), a construção de software envolve tarefas essenciais e acidentais estas relacionadas basicamente com a conversão da solução em uma linguagem de programação adequada à plataforma em que será utilizada; aquelas responsáveis pela modelagem das estruturas conceituais que compõem à entidade de software. – Infere-se dos ensinamentos de Brooks que o conjunto que contempla as alternativas para melhorar o processo de construção de software deve contemplar elementos otimizadores das atividades essenciais e acidentais. 

Todavia, em que pese tenha havido avanços no suporte ao desenvolvimento das atividades com características acidentais (linguagem de programação de alto nível; ambientes de programação integrado, etc.); certo é que, com o tempo, a utilidade marginal dessas melhorias se tornou decrescente. Isso porque as maiores dificuldades da engenharia de software estão: a) no levantamento e entendimento dos requisitos, bem como, na modelagem conceitual da solução conforme as expectativas dos responsáveis pelas áreas de negócios; b) no desenvolvimento de uma solução em conformidade/integração com a plataforma tecnológica existente na organização; e d) por fim, nos esforços relativos a garantia da qualidade e confiabilidade do software antes do rollout.

– Não foi por outro motivo que Brooks disse: “Acredito que a parte difícil da construção de software seja a especificação, projeto e teste dessa construção conceitual(...)”. 

É inegável que houve avanços nos modelos de desenvolvimentos de software, especialmente, o surgimento do modelo espiral [proposto por Barry W.  Boem] que incentiva a identificação dos requisitos por meio de protótipos; bem como, a produção evolutiva do software por meio do desenvolvimento iterativo e incremental. Ambos recomendados por Brooks. – Oportuno, destacar a imperiosidade dos testes dos artefatos produzidos [isoladamente e/ou em conjunto] para identificar falhas e maximizar a qualidade do novo release da aplicação; inclusive, essa tarefa pode ser realizada com o auxilio de sistema especialista [conforme ensina Brooks] de vária maneiras: sugerindo regras de interface, aconselhando sobre estratégias de teste, oferecendo dicas de otimização, etc. 

Devido a complexidade intrínseca do software, não se pode afirmar que a utilização do conjunto de técnicas supramencionada é condição necessária e suficiente para garantir a construção do artefato de software com agilidade e qualidade. Notadamente, porque, no contexto, a qualidade/capacitação das pessoas envolvidas é fator critico de sucesso. – Notório é que se faz necessário capacitar os profissionais que atuam conjuntamente no processo de construção de software: o designer especialmente em ferramentas e técnicas inovadoras para suportar o processo de modelagem conceitual do artefato; já o gestor técnico além capacitação na área tecnológicas, deve-se privilegiar os processos de gerenciamento de projetos. 

Adicionalmente, Brooks recomenda que seja considerada como alternativa para equação da complexidade do processo de construção de software: a compra de uma solução de software que possa atender as necessidades da organização. 

Considerando-se o supra exposto e as dificuldades modernamente conhecidas, tangenciadas por Brooks, no que se refere as preocupações do gestor técnico durante as etapas de construção de software; no que tange a estouros de cronogramas e orçamentos; além do elevado volume de defeitos do artefato. Deduz-se que é importante utilizar uma metodologia de construção de software combinada com uma metodologia (ou conjunto de processos) de gerenciamento de projetos para que todos os envolvidos tenham a mesma visibilidade da evolução das atividades essenciais e acidentais durante o ciclo de vida do projeto. 

Portanto, parafraseando, Brooks, o processo de desenvolvimento de software é complexo e as vezes aterrorizador; mas a equação do problema deve ser atacada com foco, metodologias, técnicas inovadoras, teste de software, outsourcing e capacitação de pessoas. – Ou seja, não existe uma única solução mágica!

 Manoel dos Santos da Silva é Advogado; Especialista em sistemas de Informação pela FGV-SP [CEAG]; e Mestre em engenharia de Computação pelo IPT-SP.

Fonte: F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986); The University of North Carolina at Chapel Hill Department of Computer Science CB#3175, Sitterson Hall Chapel Hill, NC 27599-3175