Engenharia ? Pode até ser

A minha palestra sobre uma desmistificação da engenharia de software foi feita ontem. Não me sai tão bem como eu gostaria, mas não tão mal como eu temia.

Gostaria agora de consagrar uns posts aos assuntos tratados. Em primeiro lugar a questão do termo "engenharia" de software, que foi no final das contas o tema central da palestra.

Na profissão, esse assunto não é novo, longe disso. Um debate existe há décadas sobre o fato do desenvolvimento ser "arte" ou "engenharia". Paralelamente, existe muito debate sobre as qualificações necessárias para poder atuar como "engenheiro" de software. Há quem defende que desenvolvimento de software é criação, outros que dizem que uma formação en ciência da computação é imprescindível e que o problema hoje na profissão é a mediocridade (falta de formação formal).

Os slides da presentação estão disponíveis online

Meu ponto é um pouco diferente. Esta discussão de especialistas é bastante interessante e na verdade fundamental para a profissão. Mas quando quero desmistificar o termo "engenharia" de software, não é para dizer que desenvolvimento não é engenharia. Meu objetivo é de desmentir certas idéias ligadas a este termo e que levam a estratégias erradas.

Principalmente, a idéia segundo a qual a construção do software se faz na programação, na base de uma planta baixa que são os diagramas UML feitos durante a análise e o desenho. Chama arte, chama engenharia, chama como quiser. O código É a planta baixa.

Portanto, o processo de desenvolvimento não deve ser considerado um processo industrializado de construção, mas sim um processo de criação do plano que servirá à construção. Com toda a incerteza ligada a esta descoberta de um espaço desconhecido.

E o processo de desenvolvimento (que define quem faz o que e quando) deve gerenciar esta incerteza da melhor forma. E o melhor jeito que temos hoje é usar um processo iterativo e adaptativo, que vai permitir acompanhar o trabalho de perto e responder rapidamente às dificuldades encontradas no caminho.

Uma opinião defende que, se este processo de criação é tão incerto, é por falta de maturidade dos nossos conhecimentos na área (o que chamam de "body of knowledge"). A engenharia de software seria hoje na mesma situação do que era a da engenharia elétrica uns dois seculos atrás. Seria bom se a ciência da computação pudesse trazer mais métodos formais de verificação da correção (correctness) de um sistema.

De novo, a questão é interessante para o profissional mas este não é o problema do cliente. No estado atual dos nossos conhecimentos as idéias que denfendi na palestra são as que melhor permitem atingir o nosso objetivo: traduzir uma necessidade funcional em software.


Referências

Jim Waldo, "Software Engineering and the Art of Design"
http://www.artima.com/weblogs/viewpost.jsp?thread=7600
(os comentários são particularmente interessantes)

Steve McConnell, "Software Engineering is not Computer Science"
http://www.stevemcconnell.com/psd/04-senotcs.htm

Jack W. Reeves, "What is Software Design"
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Richard P. Gabriel, "The Road not Taken"
http://dreamsongs.com/NewFiles/RoadNotTaken.pdf

Cees de Groot, "Art, Science, Engineering, Craft - Approaches to Building Software"
http://www.cdegroot.com/articles/2000-art-science-engineering-craft/