Qual é o papel atual do programador no projeto de um sistema na industria de software brasileira? Eu digo que é de pedreiro e explico o motivo!
No inicio da era da informática, a atividade de programação era tudo em um projeto de software. A criação de um sistema era considerada uma arte. Cabia ao programador criar sistemas que controlavam os misteriosos e novos computadores utilizando uma linguagem compartilhada entre eles e as máquinas. Essa atividade era executada por “gente estranha”, normalmente engenheiros que viravam a noite se dedicando a entender a língua das máquinas de modo a poder “conversar” com elas. Os sistemas criados por eles, normalmente, eram muitos específicos e muito ligado ao hardware. Muitas vezes, a programação era considerada uma ação secundária e vinculada ao projeto de hardware.
Com a evolução dos computadores e sua rápida disseminação, surgiram novas linguagens de programação de modo a facilitar criação dos softwares e a permitir que eles fossem compartilhados entre máquinas diferentes e pudessem realizar as mais diversas tarefas. O software, nesse momento, começa a ocupar um papel importante nas organizações, sendo responsável pela automatização de diferentes tarefas. O hardware se torna secundário e o software assume a frente.
Com a crescente demanda por novos sistemas, a forma de programação artesanal do inicio do período não é a mais adequada. Projetos de software executados de forma empírica tornaram a manutenção e a evolução dos sistemas difícil, muitas vezes impossível e com a crescente complexidade e o tamanho dos novos sistemas, o custo de mantê-los e evolui-los fez com que fosse adotada uma abordagem cientifica para seu desenvolvimento, surgindo assim, a Engenharia de Software.
A Engenharia de Software definiu metodologias para disciplinar o projeto de software e acabar com o modelo impírico de desenvolvimento, definindo ações que deveriam ser realizadas para que se fosse obtido sucesso nos projetos.
Pela metodologia adotada, a programação tornou-se uma tarefa de menor importância para o desenvolvimento de sistemas, onde as atividades principais (atividades que compõem o projeto de software) seriam o planejamento do projeto de software, á analise de requisitos e o projeto de arquitetura e de dados. Vejam que falo de atividades e não de processo, como cascata, prototipação etc. Para a engenharia de software, essas as atividades são essenciais e independentes do processo adotado, sendo que, um projeto deve sempre ser constituido dessas ações e a codificação dever ser feita com base nos artefatos gerados por elas conforme relatado em PRESSMAN95:
“Por causa do esforço aplicado no projeto o código se desenvolverá com pouca dificuldade. Uma margem de 15 a 20% do esforço global pode ser conseguido” pag. 146“A Engenharia de software considera a boa codificação como consequencia de um bom projeto. O código é revisado para que possa ter estilo e clareza, mas deve, por outro lado, ser diretamente relacionado ao projeto detalhado” pag. 194
Essa metodologia é disseminada e exemplificada dizendo que a codificação é o assentamento dos tijolos do sistema de software. Nesses exemplos é utilizada a programação orientada a objetos para demonstrar como o programador deve, a partir do projeto especificado, construir elementos, como objetos, que constituirão o sistema, de forma similar como um pedreiro cria elementos, como paredes, que se transformarão em uma edificação.
Essa metodologia fez surgir as fabricas de softwares que acabam por transformar a programação em uma atividade fabril, pois cabe ao agora ao programador apenas codificar o projeto conforme ele foi feito.
Assim, sutilmente, o programador se transforma em pedreiro, apenas executando o que foi projetado. Não que isso assuma uma conotação pejorativa ou que ele tenha se tornado um programador braçal ou que não seja mais necessário uma alta qualificação para o cargo, mas porque sua atividade deixa de ser altamente intelectual e criativa para se tornar manufatureira. Isso é demonstrado na em reportagem da revista Exame nº 896 sobre a atividade de programador nas fábricas de software brasileiras:
“O trabalho é repetitivo e nem sempre requer criatividade. Sentados em baias e munidos de computadores simples, eles passam o dia inteiro digitando os códigos que construirão ou atualizarão os sistemas dos clientes. A produção é organizada como numa linha de montagem: ao cumprir uma etapa, o programador passa o serviço adiante e pega a próxima tarefa. É comum que esses profissionais nem saibam exatamente para que serve o software que estão criando, porque o desenvolvimento é quebrado em vários pedaços e distribuído entre equipes diferentes, que não têm uma visão abrangente do projeto. É como se cada uma delas recebesse instruções para desenhar uma peça de um quebra-cabeça sem saber como é a imagem completa”
A disseminação dessa metodologia e sua utilização pelos meios acadêmicos no ensino faz com que os próprios profissionais, que se dedicam a programação, não acreditem que seja necessário entender o funcionamento de um sistema para codifica-lo. Para eles é necessário apenas entender a tecnologia utilizada para codificação e como ela se integra com a estrutura de dados e a arquitetura utilizada.
Essa nova abordagem disciplinou o desenvolvimento de software, porém criou novos problemas, como o atraso no cronograma, sistemas que não atendiam bem as necessidades ou que demoravam tanto para serem entregues que a necessidade original já havia mudado e embora os sistemas não sejam caóticos, como os feitos de maneira empírica, ainda apresentavam dificuldades de manutenção e evolução após a a entrega.
Notou-se também que as técnicas criadas e os processos adotados para implementa-las acabavam por burocratizar o desenvolvimento. Para resolver o problema foram criados novos processos, como prototipação e o modelo espiral que refinavam o tradicional processo cascata. Embora esses novos processos tivessem algum excito muitos dos problemas continuaram a existir.
Em meios aos novos problemas criados pela metodologia adotada pela engenharia de software surge uma nova proposta para guiar o projeto de software, o Desenvolvimento Ágil. Essa nova visão da uma importância menor para as atividades que até então eram consideradas fundamentais para o desenvolvimento de software e prioriza um projeto focado na codificação a partir das necessidades dos clientes.
Essa nova abordagem marca o inicio do desenvolvimento interativo (e não iterativo do modelo espiral), onde a participação do cliente é fundamental, guiando o desenvolvimento e tendo muito sucesso, tanto que, muitas empresas tem direcionados seus esforços em adota-las, porém, nem sempre, com muito sucesso!
Muitos são os fatores que contribuem para o fracasso da adoção de métodos ágeis, entre eles, a necessidade de quebra de um paradigma criado pela engenharia de software tradicional, onde a codificação é uma atividade secundária do projeto.
Nas metodologias ágeis, como XP, a codificação assume o papel fundamental e todos os esforços devem ser feitos para que ela seja conduzida da melhor maneira possível. Nessa nova abordagem, o código representa o negócio e não uma tarefa realizada por “construtores” e sim, uma atividade intelectual, onde é necessário inteligência e criatividade.
Para isso é necessário que se entenda que o software representa o “projeto” e não os artefatos. O código fonte deixa de ser os tijoĺos do sistema e passa a ser a planta que o engenheiro criou, só que ao contrário de um projeto cívil ou mecânico onde, a tarefa de construção é longa e complicada, nessa nova abordagem o projeto é construído por um compilador ou interpretador (não é a toa que essa tarefa é chamada de “build”). As outras atividades que antes eram consideradas principais se tornam auxiliares na construção do sistema, diminuindo muito suas responsabilidades.
Um exemplo clássico dessa visão equivocada da codificação é que é tido que XP não pode ser utilizada em todos os tipos de projeto, justamente, porque o código seria modificado o tempo todo! Como construir uma casa onde o cliente a todo o momento altera posição das paredes? Ou como entregar somente um quarto ou a cozinha? Pelo paradigma tradicional isso faz sentido, mas pelo novo modelo, como o código representa o projeto e não as paredes, é possivel altera-lo até chegar a algo que atenda suas necessidades. Na verdade, esse é o mesmo processo adotado pela arquitetura para construção de edificações, móveis, etc. O arquiteto civil levanta junto aos seus clientes suas necessidades e, com base nelas, cria um projeto. Com base nesse projeto são feitas renderizações e modelos 3D, que são exibidos ao cliente que em contrapartida fornece seu feedback ao arquiteto, que realiza as alterações necessárias. Sendo assim, o cliente pode ter certeza que o projeto elaborado atende suas necessidades e, somente após isso, ele é executado.
No desenvolvimento de software, podemos obter feedback do cliente pela utilização de diagramas UML, através da interação dele com o software parcialmente pronto e até mesmo através da entrada e saída de dados em testes unitários. É possivel também, liberar módulos totalmente funcionais para uso dos clientes, como se fossem protótipos de um equipamento ou uma parte da edificação que pode ser habitada, mas ao contrário da edificação (mas que é possivel com o protótipo) é possível é alterar esse módulo para que ele atenda as necessidades do cliente.
Esse processo interativo guia a codificação, de modo que, o código represente fielmente o negócio do cliente e ao analisa-lo ou a sua documentação, torna-se possível entender facilmente seu funcionamento e o que ele se propõe a resolver. Essa é a ideia central por traz do projeto dirigido pelo domínio (Domain Drive Design - DDD).
Referências:
Aldo Dórea vs Fred Brooks acessado em 06/04/2011
Fábricas de informação - Revista Exame nº896 acessado em 06/04/2011
PRESSMAN95: Engenharia de Software, Roger S. Pressman
Nenhum comentário:
Postar um comentário