O que é Engenharia de Software Empírica?

Neste artigo você vai ver:

Estamos sempre buscando tornar o processo de desenvolvimento de soluções mais ágil e efetivo. E um conceito que tem muito a contribuir para isso é a Engenharia de Software Empírica.

Quer entender melhor o que é  Engenharia de Software, o conceito de empirismo e como a  Engenharia de Software Empírica pode tornar o seu processo de desenvolvimento melhor? Então continue lendo!

O que é Engenharia de Software?

A Engenharia de Software é uma área da computação que investiga e aplica métodos, técnicas, processos e ferramentas nas mais diversas etapas do processo de desenvolvimento de software.

Para você ter ideia, Engenharia de Software abarca do planejamento de requisitos, passando por gerência de projetos, qualidade de software, teste de software, até questões como ética e aspectos econômicos. 

Devs utilizam essas práticas para desenvolver sistemas mais complexos, de forma produtiva e com qualidade.

Software: do nada até a onipresença em 50 anos

A área da Engenharia de Software é relativamente nova, com seu nascimento em meados da década de 60. Até então, a indústria estava mais preocupada em construir soluções de hardware para executar alguns poucos programas. 

Com a popularização dos computadores, novas soluções de software foram demandadas pelos usuários. Avançando rápido pelos 50–60 anos seguintes, hoje, poucos são os modelos de negócio que não envolvem software de alguma forma. Como popularizado por Marc Andreessen, Software está engolindo o mundo

Mas nem tudo são flores. 

Embora ferramentas como IDEs, compiladores e linguagens de programação tenham evoluído muito ao longo dos anos, muitos bugs ainda passam despercebidos pelos times de desenvolvimento e são observados apenas pelo usuário final. 

De forma análoga, embora vários processos de desenvolvimento tenham sido introduzidos, ainda é comum ouvir histórias de projetos de software que foram entregues com prazo atrasado e orçamento comprometido. 

Fred Brooks tinha razão 

Como antecipado por Fred Brooks em seu seminal livro, O Mítico Homem Mês (1975), parte desse cenário advém de dois tipos de problemas de complexidade: a complexidade essencial e a complexidade acidental. 

A complexidade essencial está relacionada ao desafio de escrever código que interage com ambientes complexos (por exemplo, um sistema bancário distribuído) mas ao mesmo tempo precisam ser codificados de forma que essa complexidade seja abstraída de outros usuários do software e, ainda assim, precisam ser de fácil modificação. 

Já a complexidade acidental está relacionada ao estado das ferramentas e processo que utilizamos. Quem nunca viu seu sistema operacional travar, sem motivo aparente? E a IDE que fechou depois que você tentou fazer uma refatoração? E aquele framework JavaScript que só tinha a documentação do Hello World

O avanço das práticas e ferramentas trouxe um terceiro complicador: hoje em dia temos várias opções de ferramentas para a mesma tarefa. Saber qual a mais adequada não é uma escolha simples, pois depende de variáveis como complexidade do projeto, experiência do time de desenvolvimento, tempo esperado para entrega do projeto, etc. 

Por mais que eu prefira Kotlin e Micronaut no IntelliJ, faz sentido adotar essa pilha de tecnologia em um projeto com prazo apertado e em que a maior parte do time é experiente em C#? Parece que não. 

Dificilmente haverá uma única solução para todo tipo de problema. Em outras palavras, não existe bala de prata, termo cunhado também por Fred Brooks. Não existe (e possivelmente nem existirá) um único processo, técnica ou ferramenta que vai conseguir acelerar a produtividade de todo e qualquer time de desenvolvimento. 

No mar de opções, o que pode nos ajudar a decidir o que é mais adequado pro meu time/projeto? Como podemos tomar decisões na engenharia de software de maneira mais assertiva?

O que é o Empirismo?

Todos nós aprendemos por experiência. 

O empirismo é um ramo da filosofia que teoriza que o conhecimento deve advir através da experiência. As ideias do empirismo diferem, por exemplo, do raciocínio matemático, em que os problemas são resolvidos através da lógica e de regras bem formuladas. 

Quando se fala em um estudo empírico, nosso interesse é realizar um teste que compara aquilo que se sabe (ou que achamos que sabemos; as nossas crenças) com o que se observa na saída do teste. 

Esses testes, quando construídos e executados de forma rigorosa, desempenham um papel fundamental na ciência moderna. Em particular, eles nos ajudam a entender como e porque as coisas funcionam, o que nos permite confrontar nosso entendimento com evidências coletadas dos dados.

Como testamos uma crença?

Esse ramo da ciência não é nada novo; data da época de Galileu e seu experimento de jogar bolas de tamanhos diferentes do alto da torre de Pisa para testar se o tempo de descida era independente do tamanho das bolas. 

Embora simples, Galileu mostrou como se construir um experimento rigoroso: ele parte de uma crença ou hipótese (acho que a bola mais pesada vai cair primeiro), ele usa uma metodologia rigorosa para testar se hipótese faz sentido (consecutivas vezes, as bolas de tamanho diferentes foram jogadas na mesma condição), e avalia o resultado alcançado (alguém embaixo da torre observou a descida das bolas).

Mas o pessoal usa mesmo isso?

Ao longo dos anos, o conhecimento empírico, ou seja, aquele que adquirimos através da experiência, observação ou coleta de dados, se tornou basilar em diversas áreas do conhecimento. Muitos dos avanços recentes da Medicina, por exemplo, devem-se ao emprego de técnicas de experimentação, como estudo de casos e experimentos controlados. 

Você sabia que, no passado, lavar as mãos era um conselho médico controverso? Somente no século 19 que um experimento feito pelo médico austríaco Ignaz Semmelweis evidenciou que limpar as mãos com uma solução de cal clorada (e não lavar com sabão) era capaz de reduzir drasticamente as taxas de mortalidade materna.

Não é surpresa que recentemente diversas disciplinas passaram a adotar uma prática mais orientada a testes e experimentação. Basta lembrar, por exemplo:

  • (1) da física, com o estudo que deu origem a primeira foto de um buraco negro. 
  • (2) da manufatura, com os testes que os automóveis passam nas fábricas.
  • (3) da psicologia, com o experimento que evidenciou o viés de quando quem avalia tem simpatia pela pessoa avaliada (Efeito Halo). 

A lista vai longe.

Mas e a Engenharia de Software Empírica?

De forma análoga a disciplinas como Medicina, Psicologia e Biologia, na engenharia de software nós não podemos confiar apenas na nossa experiência e no pensamento lógico. A Engenharia de Software, na verdade, é um mar fertil para coleta de dados e experimentos

Como pessoas que trabalham com software, precisamos experimentar com as técnicas, processos e ferramentas que utilizamos, para entender como realmente elas funcionam, quais são seus limites, ou como podemos melhorá-las. 

Exemplos de estudos de Engenharia de Software Empírica

Embora a área de Engenharia de Software Empírica esteja na sua infância, estudos recentes apresentam resultados interessantes e provocadores. Por exemplo: 

Você como pessoa programadora, já deve ter parado pra pensar sobre como algumas decisões poderiam ser tomadas se alguns dados fossem analisados previamente. 

A Engenharia de Software Empírica existe para apoiar as equipes de desenvolvimento, através de evidências trazidas por experimentos. Estas  evidências, por sua vez, podem ser ultimamente utilizadas para apoiar a tomada de decisões das equipes.

A função dos times de pesquisa em engenharia de software empírica, por sua vez, é entender a natureza dos processos e dos produtos, e seu relacionamento. Ambos aspectos são importantes, mas um é bem mais desafiador de investigar do que o outro, como veremos a seguir.

Quais outros experimentos podemos fazer?

Quando falamos de produtos, o material de estudo já está disponível, na forma de repositório de código, e seus dados e metadados de commits, bugs, pull-requests que resolvem bugs, além, é claro, do código-fonte. 

No entanto, experimentos com processos são bem mais desafiadores de serem conduzidos, pelo simples fato de ter seres humanos envolvidos. Realizar experimentos se torna mais complicado pois existem muitas variáveis; e estas são difíceis de controlar.

Uma pergunta simples (mas que poderia ajudar diversos times de desenvolvimento): qual é a duração ideal de uma Sprint? 

Realizar um experimento para responder essa pergunta precisa levar em consideração variáveis como: 

  • Qual o tamanho do time?  
  • Qual a experiência do time? 
  • O que bloqueia o time? 
  • Qual a área de atuação do projeto? 
  • Qual a criticidade do projeto? 
  • Como é o relacionamento com o cliente? 
  • O quão familiarizado está o time com a tecnologia, projeto e cliente? etc. 

E para que a resposta seja satisfatória, é necessário haver dados suficientes para cada variável de interesse.

Como Engenharia de Software Empírica pode ajudar os times

Trazer para o ambiente de trabalho profissionais de pesquisa com habilidades em Engenharia de Software Empírica pode contribuir para diminuir as decisões que são tomadas com base em crenças e culturas pré-estabelecidas. 

Com isso, é possível ajudar o time justamente a confrontar essas crenças com dados da realidade, além de disseminar a prática do método científico para resolver problemas empresariais.

A Zup, como empresa de tecnologia, tem investido em um grupo de pesquisa que atua nas linhas de engenharia de software e inteligência artificial. 

Afinal, na Zup Edu acreditamos que combinar o conhecimento acadêmico com a experiência técnica pode ser chave para construção de times de desenvolvimento mais críticos, com decisões orientadas a evidências e assertivas.

E aí, o que achou da Engenharia de Software Empírica? Se ficou com alguma dúvida ou tem algum ponto para complementar é só trazer nos comentários!

Capa do artigo sobre Engenharia de Software Empírica onde temos um jovem programador escrevendo um código de programa sentado no local de trabalho com três monitores.
Foto de Gustavo Pinto
Pesquisador
Uso metodologia científica pra testar as crenças dos times de desenvolvimento. Será que Kotlin é mesmo melhor que Java? Será que multirepos é melhor que monorepos? Será mesmo?

Este site utiliza cookies para proporcionar uma experiência de navegação melhor. Consulte nossa Política de Privacidade.