Desenvolvendo software para apoio à pesquisa

Dentre os enormes desafios de utilizar a Engenharia de Software e seus princípios, está o de desenvolver sistemas e software para apoio à pesquisa científica. Focando melhor, aquele software desenvolvido por um ou mais pesquisadores, especialistas em algum domínio de conhecimento, e sua equipe normalmente constituída por orientados de mestrado e doutorado, trabalhando em laboratórios de pesquisa em  ambiente acadêmico. Normalmente essas equipes conhecem muito bem o domínio de conhecimento, conhecem todas as técnicas da área, mas do ponto de vista de computação têm conhecimento raso e, se incluirmos técnicas da engenharia de software, aí é que a coisa fica preta. Com sorte, um ou outro membro da equipe cursou disciplinas de computação na sua graduação, ou até se formou em computação, e consegue dar alguns pitacos na condução dos projetos.  A linguagem de programação que domina nesses ambientes é o Fortran, campeão disparado. Claro, a linguagem e o ambiente variam muito atualmente, mas o Fortran continua sendo o preferido, o que é explicado pela microeconomia como uma “externalidade de rede“: quanto mais usuários tiver, a tendência é que o nível de adoção continue crescendo.  Já existe um enorme acervo de bibliotecas de funções e pacotes com os mais diversos objetivos, o que facilita o desenvolvimento pelo enorme nível de reutilização que essas bibliotecas permitem.
downloadMas o que caracteriza esse tipo de software? Antes, melhor a gente caracterizar o tamanho do problema a que estamos nos referindo. O foco da postagem é em sistemas grandes, desenvolvidos por equipes distribuídas geograficamente, cada uma desenvolvendo a parte do software em que tem competência no domínio de conhecimento. Por exemplo, para os sistemas destinados a previsões e estudos de clima e mudanças climáticas são necessários grupos especializados em águas, ar, terra, subsolo, insolação, que são todos interligados e uma área de conhecimento influencia direta ou indiretamente as demais. Os subsistemas são desenvolvidos localmente por cada equipe, e depois têm que ser integrados em um sistema único que funcione adequadamente considerando as influências mútuas de um elemento no outro. Vejam, por exemplo, o sistema de previsão e estudos climáticos do MetOffice, de Londres, que talvez seja o maior e o mais conhecido no mundo. Explorem o site, vejam a quantidade de informação de boa qualidade refinada por séries históricas, e o número grande de sistemas, cada um responsável por um aspecto da natureza afetando o clima. Uma excelente referência no Brasil é o INCT em mudanças climáticas, explorem para verem a quantidade de grupos e áreas de conhecimento envolvidas.
O que caracteriza em parte esse tipo de problema é: -funcionalidades e requisitos imprevisíveis, apenas uma parte inicial é possivel levantar e especificar. A maior parte surge por emergência e vai sendo agregada na medida da necessidade, o que caracteriza um alto nível de mudanças e acréscimos em requisitos, o fator fatal em desenvolvimento de sofware organizacional; -o desenvolvedor é, via de regra, o próprio pesquisador especialista no domínio, que prefere ele próprio meter a mão na massa a ter que ficar explicando necessidades e requisitos a desenvolvedores que não entendem o domínio de conhecimento tanto quanto o especialista. Além disto, vejo que o especialista-desenvolvedor desenvolve software como um desafio intelectual que dá prazer; -o mercado para esse tipo de software é muito restrito, não atinge o mercado corporativo e seus principais usuários são os próprios pesquisadores e grupos de pesquisa envolvidos, o software é considerado um laboratório virtual para desenvolvimento de pesquisas. Eventualmente, o software pode ter impacto econômico e ser adotado por governos, por exemplo; -não existem prazos de entrega do software, o desenvolvimento vai indo e funcionalidades vão sendo agregadas ao pacotão já existente, sem muito planejamento no sentido que é comum na engenharia de software tradicional; -a escolha de uma linguagem como a Fortran protege os grupos de desenvolvimento contra mudanças tecnológicas, a enorme comunidade usuária garante essa proteção, o interesse econômico é enorme.    
E a engenharia de software, como fica nesses casos? Já analisei esse caso a convite do Grupo de Pesquisas em Interação Atmosfera-Biosfera  do DEA – Departamento de Engenharia Agrícola da UFV, em um dos encontros do INCT realizados aqui na UFV. Fiz uma palestra para o grupo, falando sobre a questão da Engenharia de Software sob o ponto de vista do que eles fazem. Os desafios são enormes, pois o problema não aceita soluções tradicionais da engenharia de software, como por exemplo a adoção de um processo rígido e cheio de passos e artefatos para o desenvolvimento do software. Esse modelo se aplica muito bem a desenvolvimento de software organizacional, que tem características bem diferentes. Talvez se apliquem modelos baseados em agilidade, como mostrei nas transparências, mas mesmo assim o desafio é muito grande. São várias equipes desenvolvendo software de maneira distribuída, com integração a posteriori. Somente a integração da comunicação entre esses grupos, estabelecimento de algum padrão de desenvolvimento que permita a integração sem maiores problemas e adoção de práticas mínimas da engenharia de software já seria um desafio muito grande, muito maior que o usual. Além disto, uma enorme base de software legado já existe, com pouca ou nenhuma documentação disponível, o que dificulta enormemente possíveis alterações e ajustes, tudo teria que ser feito diretamente no código, um perigo que conhecemos muito bem. Alguma coisa poderia ser feita na base do “desta data em diante, vamos desenvolver de outra forma”, deixando o legado como já se encontra e só mexendo nele quando for muito necessário. 
Depois disto, continuando o trabalho de pesquisa do nosso grupo de Engenharia de Software do Departamento de Informática da UFV (atualmente não existe mais o grupo), fomos visitar outros laboratórios da UFV que também desenvolvem software de apoio à pesquisa, e os problemas são os mesmos. Na época, por falta de recursos no projeto, não foi possível estabelecer uma colaboração com o grupo do DEA, o que foi uma pena, poderiamos ter avançado alguns poucos passos no problema. Continua sendo uma área e um enorme desafio aberto.

(José Luis Braga, MEI, Treinamento em Informática) (este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Viçosa, MG)

Obs.: a formatação do artigo ficou péssima. Publiquei usando o Firefox, que surpreendentemente não está correspondendo às expectativas nas versões mais recentes, muitas falhas estranhas. Tive que usar os negritos para evidenciar que naquele ponto tem um parágrafo. Tentei editar no Chrome e no Explorer, não resolveu nada, e os recursos de edição do editor do WordPress são restritos. Para piorar, numa das tentativas de edição, o Firefox  mudou o tamanho da letra na versão publicada, embora na edição isso não apareça. Infernal!

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com: ,
Publicado em Engenharia de Software, Pesquisa
2 comentários em “Desenvolvendo software para apoio à pesquisa
  1. willian farago disse:

    Ótimo artigo Zé, temo que no projeto desenvolvido com o pessoal da medicina (simulador do sistema imunológico) isso ocorra, na verdade acho que já está acontecendo. No mundo corporativo isso também deve ser muito comum, já presenciei um caso, o sistema vai crescendo e os requisitos vão aparecendo e são acoplados sem um estudo que leve em conta todo o projeto.

  2. Fabrício Murta disse:

    É uma colcha de retalhos orientada a projetos. Cada um faz o seu projeto e publica. Se não tiver publicação não tem valor, se não tem valor não tem bolsa. Em que ponto a integração de diversos projetos terá valor? Será viável, para o tempo médio que os projetos duram, e dado que os individuais não foram feitos com nenhum foco em integração e reuso de código?

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: