BT

O desenvolvimento de software nunca será engenharia?

por Gustavo Castro em 19 Jul 2011 |

John Sonmez defendeu recentemente em um post para o ElegantCode que, por fatores peculiares, o desenvolvimento de software não pode seguir os princípios comuns à engenharia.

O desenvolvimento de software nunca vai obedecer a princípios de engenharias rígidas como muitas outras práticas de engenharia.

Para sustentar sua tese, o autor compara a criação de software com a construção de pontes, apoiando-se no fato da construção de software ser algo recente e dinâmico:

A engenharia tem sido trabalhada há centenas de anos; amadureceu ao ponto em que se tornou uma ciência mensurável . O desenvolvimento de software teve apenas algumas décadas para evoluir  e ainda é imaturo como uma disciplina de engenharia.

Para destacar uma possível falta maturidade do desenvolvimento de software o autor compara a evolução da forma de desenvolver software com a evolução do jogo de poker. Afirma que devido ao surgimento dos campeonatos online os jogadores de poker ganharam experiência de décadas em apenas alguns anos. A comparação com o poker é bem interessante, fazendo isso o autor procura apresentar que a maturidade do desenvolvimento de software não será um problema por falta de evolução.

Nos últimos 10 anos profissionais de poker com décadas de experiência começaram a ser batidos por prodígios de 19 anos de idade. [...] A estratégia do torneio de poker mudou completamente e  o jogo evoluiu talvez 500 anos em cinco.

Em seguida o autor reafirma que desenvolver software é diferente de qualquer tipo de engenharia, indicando que a construção de pontes segue requisitos fixos:

A construção de pontes seguem um conjunto fixo de requisitos similares para todas as pontes, mas o desenvolvimento de software parte de um grande vazio, de caprichos e declarações ambíguas.

Para concluir seu ponto de vista, o autor afirma que a construção de software tem mais em comum com a de cirurgiões.

O texto gerou repercussão, especialmente negativa. Vejam um desses comentários:

“Eu não concordo com sua afirmação de que o desenvolvimento de software nunca será de engenharia. Penso exatamente o contrário. Quanto mais eu trabalho na área, mais eu entendo que pode se tornar uma engenharia. É apenas uma questão de como você define Engenharia. Por outro lado, eu concordo apenas o tamanho não resolve tudo: não há uma abordagem de engenharia definitiva e irrefutável software” - Rodrigo Gonçalves

Em post recente publicado no HXA notes, é apresentado outro um ponto de vista sobre a Engenharia de Software. Nesse pequeno artigo, o autor afirma que o objetivo da engenharia de software é refletir a fluidez humana. Para ele,  a engenharia de software tenta ser algo entre o abstrato e o concreto, entre o requisito e a matéria.

Não de trata da melhor maneira de abstração, mas sim a melhor forma de mudar as abstrações.(...) Pode-se dizer que ‘mudar’ é um tipo mais generalizado de criação.

Para ele, autor, a engenharia de software está entre os requisitos oferecidos e os recursos disponíveis, agindo como o facilitador entre as partes.

A engenharia de software é colocada entre (as partes) como atividade sistemática para mantê-los juntos.

Nesse aspecto, a engenharia deixa de ter a conotação clássica das demais engenharias. E para você, a Engenharia de Software pode ser realmente considerada uma engenharia no sentido clássico?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Sim...ou não! by Rafael Pedroso

Gustavo, eu penso que atualmente pela pouca maturidade, o desenvolvimento de software está mais para arte do que para engenharia. Entretanto, acredito que a tendência é se aproximar do sentido clássico da engenharia.

Concordo plenamente! by Jim Mayal

Concordo plenamente com John Sonmez. Software é algo muito novo, ainda não consegue - se é que conseguirá - ser domado pelas velhas estruturas.
O desenvolvimento de um software beira a arte, basta olhar sobre os ombros dos 'gigantes' (google, facebook, microsoft, etc...).
Não acredito na antiga engenharia, como base de um produto imaterial, assim como o velho modelo de gestão caiu por terra quando apareceram os 'construtores do futuro', ou seja os desenvolvedores do software.
Lidar com pessoas inteligêntes requer gestão inteligênte, assim como, construir algo inteligente (e dinâmicos) como um software, deve, não requerer estruturas rígidas.
Afinal, não se calcula o 'peso' de um software como se faz com o peso de uma ponte sobre um pilar.

Discordo by Allan Araujo

Pelo menos no sentido mais amplo e de definição: "A engenharia é a ciência e a profissão de adquirir e de aplicar os conhecimentos matemáticos, técnicos e científicos na criação, aperfeiçoamento e implementação de utilidades, tais como materiais, estruturas, máquinas, aparelhos, sistemas ou processos, que realizem uma determinada função ou objetivo.Nos processos de criação, aperfeiçoamento e implementação, a engenharia conjuga os vários conhecimentos especializados no sentido de viabilizar as utilidades, tendo em conta a sociedade, a técnica, a economia e o meio ambiente.A engenharia é uma ciência bastante abrangente que engloba uma série de ramos mais especializados, cada qual com uma ênfase mais específica em determinados campos de aplicação e em determinados tipos de tecnologia". pt.wikipedia.org/wiki/Engenharia.

Acho sim que o desenvolvimento de software pode ser encarado como uma atividade de engenharia, respeitadas as particulares do mesmo (requisitos mais instáveis, intangíveis, etc.). Mediante estas particulares, existirão métodos mais apropriados (diferentes de outras engenharias - que já possuem diferenças entre si), ciclos de vida mais adequados, etc.

Re: Discordo by Allan Araujo

Apenas lembrando, que os métodos empíricos aplicados ao desenvolvimento de software têm mais a ver com imaturidade e falta de condições de previsilidade (predição) do que com arte.

Regulamentação é tudo by Fábio Costa Silva

A principal diferença na minha opinião é que engenheiros devem obedecer a uma série de regras e regulamentações, sendo inclusive passíveis de perda de licença de trabalho e outros pormenores legais. Já para as fábricas de software vale a regra do "cada empresa um mundo". Além disso, se você constrói um software com erro de projeto, simplesmente lança uma nova versão(e em muitos casos ainda cobra por isso). Agora construa uma ponte com um erro de projeto pra ver o que acontece...

Re: Regulamentação é tudo by Allan Araujo

Milhares de projetos de engenharia no mundo saem com defeitos e inconformidades. Alguns críticos, boa parte não. Inúmeros são realizados de forma "iterativa e incremental", com versões diferentes sendo entregues.

Pensemos em engenharia de maneira mais ampla:

- Regulamentação profissional: OK, não temos em TI, mas quem disse que isso garante competência? Quantos incompetentes têm OAB, CREA, etc.?

- Maturidade: Quando a engenharia química, civil, aeronáutica, naval, etc. eram menos desenvolvidas, os métodos eram mais empíricos e "menos científicos", apenas com a maturidade é que "boas práticas" começaram a se consolidar como padrão.

- Falta de padronização industrial: Aposto que cada indústria de aplicação de engenharia e cada organização possui seus próprios métodos e ativos intelectuais (pessoas, processos, ferramentas). Mais uma vez aposto que a maturidade trará difusão de boas práticas e que, ainda assim, as organizações terão métodos de trabalho diferentes (embora com similaridades).

- Reuso: boa parte dos engenheiros em outras áreas de atuação não faz uso ostensivo e intensivo de noções de física e de matemática (cálculo, álgebra, etc.) que aprenderam na faculdade. Boa parte desses conhecimentos fica encapsulado através de soluções recorrentes (design patterns? ;)).


Por fim, uma analogia que eu gostaria de fazer:

- Quando uma construtora vai desenvolver um prédio novo, funciona como uma fábrica de software. O problema está bem definido, por isso, é possível trabalhar com um alto gral de padronização e previsibilidade.

- Quando Neimeyer (seria o designer do seu projeto?) vai conceber um novo projeto (e posteriomente uma construtora implementar) há um grau imenso de ineditismo, o problema está menos claro, as eventuais soluções mais imprecisas ainda. Há um alto grau de inovação e improviso. Por isso, métodos empíricos (embora sustentado por heurísticas, boas práticas, etc.) são mais apropriados. Ainda assim, trata-se de métodos de engenharia.


Em TI e desenvolvimento de SW em geral, temos os dois cenários. Ainda assim, não consigo deixar de ver como uma atividade de engenharia (em ebulição e evolução muito rapidamente).

É isso, minha visão particular da questão.

Discordo plenamente, falta conhecimento do que é Engenharia by Alexandre Rodrigues

Discordo plenamente. Cursei engenharia de controle e automação industrial (mecatrônica) e a veu ver o desenvolvimento de software não só pode como deve ser encarado como engenharia. A comparação com a construção de uma ponte, feita pelo autor é inválida e demonstra a falta de conhecimento deste sobre engenharia. Não são todos os projetos de engenharia que impõem desafios técnicos mas muitos impõe e cabe aos engenheiros encontrarem novas soluções para resolve-los. Isso vale para o desenvolvimento de software também.
Durante algum tempo trabalhei em uma empresa que desenvolvia soluções de automação para industria. A maioria dos projetos impunha novos desafios, muitos projetos exbiram falhas que eram corrigidas depois do projeto pronto. Nossos equipamentos eram sempre "protótipos" pois era feito apenas um equipamento normalmente. Isso fazia com que os projetos não fossem perfeitos.
Dizer que a regulamentação da profissão deve ser feita porque isso impõe que os projetos serão conduzidos sem defeitos é falho pelos motivos acimas descritos. A regulamentação é importante, mas não porque isso vai evitar projetos sem "falhas"!

Discordo do Texto by Vinicius Serpa

A meu ver criação de software é Engenharia, mas difere das engenharias tradicionais porque o produto da criação é um SISTEMA COMPLEXO ADAPTATIVO. Por isso que uma ponte é diferente, porque ela não se encaixa no ADAPTATIVO da definição do software.

Dessa forma penso que temos uma engenharia, que não necessita de materiais como concreto, aço, etc (a matéria prima é abstrata e composta por oportunidades de negócio e requisitos), tem SIM uma grande quantidade de métodos, como nas engenharias tradicionais, que devem ou não ser aplicados a projetos, dependendo das características (OO, UML, APF, UCP, etc), não existe uma fase não intelectual de execução (a implementação de software pode levantar questões de planejamento a todo momento, diferente de uma obra civil onde isso dificilmente isso acontece) e temos uma característica ADAPTATIVA que torna o projeto maleável e complexo de gerir.

Re: Regulamentação é tudo by Vinicius Serpa

Só pra constar a sua aposta na falta de padronização industrial, eu trabalho em uma empresa de "Engenharia Tradicional" e é isso mesmo que ocorre, cada unidade possui seu próprio método de trabalho.

Re: Discordo plenamente, falta conhecimento do que é Engenharia by Vinicius Serpa

Discordo plenamente. Cursei engenharia de controle e automação industrial (mecatrônica) e a veu ver o desenvolvimento de software não só pode como deve ser encarado como engenharia. A comparação com a construção de uma ponte, feita pelo autor é inválida e demonstra a falta de conhecimento deste sobre engenharia. Não são todos os projetos de engenharia que impõem desafios técnicos mas muitos impõe e cabe aos engenheiros encontrarem novas soluções para resolve-los. Isso vale para o desenvolvimento de software também.
Durante algum tempo trabalhei em uma empresa que desenvolvia soluções de automação para industria. A maioria dos projetos impunha novos desafios, muitos projetos exbiram falhas que eram corrigidas depois do projeto pronto. Nossos equipamentos eram sempre "protótipos" pois era feito apenas um equipamento normalmente. Isso fazia com que os projetos não fossem perfeitos.
Dizer que a regulamentação da profissão deve ser feita porque isso impõe que os projetos serão conduzidos sem defeitos é falho pelos motivos acimas descritos. A regulamentação é importante, mas não porque isso vai evitar projetos sem "falhas"!


Concordo, por aqui não é raro os engenheiros mecânicos realizarem alterações em peças já carregadas. Um projeto pode ser falho não porque não existem métodos perfeitos, mas sim porque são conduzidos por seres humanos.

Já quanto a regulamentação, acredito que ela só não ocorra porque implica em diversas questões não técnicas, inclusive salariais, e (dizem) que isso pode freiar a evolução do mercado (particularmente eu não acredito nem um pouco nisso).

engenharia = engenho + arte by Sergio Vellozo

Se fazer software é combinar engenho e arte então é engenharia.
Sds

Tá mais pra jardinagem by Julio Faerman

Eu acho que pode ser engenharia. Porque para mim (e pro Prof. Schneider) "Engenharia é fazer com 10 o que qualquer idiota faria com 100". E como vemos isso em software :)

Software nunca fica pronto. Fica melhor ou morre. Por isso não dá pra fazer sofware igual se faz prédio.

Software não custa nada pra duplicar. Por isso não dá pra existir "fabrica de software".

Então na minha opnião engenharia pode chamar sim, mas não dá pra usar os mesmos métodos das outras. Software é outro bicho.

Re: Tá mais pra jardinagem by Vinicius Serpa

Eu acho que pode ser engenharia. Porque para mim (e pro Prof. Schneider) "Engenharia é fazer com 10 o que qualquer idiota faria com 100". E como vemos isso em software :)

Software nunca fica pronto. Fica melhor ou morre. Por isso não dá pra fazer sofware igual se faz prédio.

Software não custa nada pra duplicar. Por isso não dá pra existir "fabrica de software".

Então na minha opnião engenharia pode chamar sim, mas não dá pra usar os mesmos métodos das outras. Software é outro bicho.


A analogia com a jardinagem foi uma das piores que já li sobre desenvolvimento de software. O jardim de casa cresce SOZINHO! Basta apenas chuva! E as sementes caem e crescem novas plantas SOZINHO, sem intervenção humana. Lógico que se houver intervenção, o resultado pode ser melhor, ou pior....

Qto ao "pronto" do software, ele fica sim, assim que atender o escopo que foi levantado. No caso de ele "morrer", na verdade o que acontece é que ele se degenera, porque geralmente o software é desenvolvido para atender uma necessidade de negócio, e o negócio muda com o tempo. Assim, ele precisa de Serviços Contínuos (mais conhecida como fase de manutenção) para continuar atribuindo valor para o objetivo ao qual ele foi desenvolvido.

Assim como uma casa de dois dormitórios deixa de atender uma familia que cresce, ou ela sofre uma alteração para ter um terceiro dormitório ou a familia é obrigada a deixar a casa, e ela "morre" para aquela familia. Mas isso é uma outra história.

O que é engenharia by Carlos Oest

No Aurélio encontramos: "Arte de aplicar conhecimentos científicos e empíricos e certas habilitações específicas à criação de estruturas, dispositivos e processos que se utilizam para converter recursos naturais em formas adequadas ao atendimento das necessidades humanas.". Fora a transformação dos recursos naturais, acho que o resto se aplica a software. O que queremos combater é o excessivo formalismo e as comparações com as outras engenharias. Vale a pena ver a palestra do Glenn Vanderburg em confreaks.net/videos/282-lsrc2010-real-software... e os textos de Giusepe Cocco e Gilvan Vilarin sobre trabalho imaterial.

Tudo eh uma questao de responsabilidade by Juan Pereira

Quando uma ponte cai, procura-se o engenheiro responsavel pela obra. Ele eh cobrado pelos requisitios e penalizado se houver algum tipo de negligencia.
E com software, boa parte dos bugs sao pura negligencia (considero desconhecimento de requisitos tambem como negligencia), quem eh responsabilizado nesses casos. Ha algum orgao regulador? Entao sem regulamentacao ou responsabilidades nao ha Engenharia de Software.
O que existe na maioria dos casos sao mestre de obra e pedreiros fazendo software, longe do que eh engenharia de fato.

Re: O que é engenharia by Vinicius Serpa

Carlos Oest,

Assisti a palestra do Glenn Vanderburg e achei excelente. Acho que ele colocou muito bem questões como

"Desenvolvimento ágil de software, longe de ser anti-engenharia, representa a responsável aplicação dos ideais da engenharia para o campo de software."

e a definição proposta

"Engenharia de software é a arte e a ciência de projetar e construir, com economia e elegância, [...] Os sistemas para que eles possam facilmente se adaptar às situações para as quais estão sujeitos.".

Eu não participo da comunidade Ruby mas, baseando por essa palestra, acredito estar muito madura sobre desenvolvimento. Obrigado por compartilhar!

Papel invertido by felipe pires

Talvez eles começem a fazer engenharia como nos fazemos software, e não nos fazer-mos software como eles fazem engenharia, um exemplo disso é como a uml era utilizada antes e como é usada hj com agilidade, acho isso uma evolução. pena que em engenharia nao é tão facil refatorar, uahuahauhua

Re: Regulamentação é tudo by Fábio Costa Silva

O ponto que levantei da regulamentação não necessariamente passa pela formação acadêmica dos profissionais, é relacionado ao fato de que os projetos de engenharia são concebidos para não falhar, ao contrário dos de TI que encaram a presença de bugs como algo normal. Na engenharia os procedimentos de teste são ostensivos, o investimento financeiro é grande e as consequências de uma eventual falha são enormes. É possível sim construir software em moldes semelhantes(por exemplo utilizando métodos formais e verificação de modelo) porém a cultura da área de TI é a de que corretude é caro e que o cliente quer ver telas bonitas. Muitas empresas inclusive entregam sistemas com bugs conhecidos e que chegam a ser grosseiros, apenas para cumprir um prazo irreal e receber a parcela do pagamento.

Re: Tá mais pra jardinagem by Antonio Nascimento

Um jardim não nasce sozinho, mato sim, esse cresce sozinho. É o que acontece com o software, se houver zelo e cuidado durante sua construção você terá um belo jardim. Caso contrário, um tremendo matagal!!!

quanto há usuário não é engenharia mas arquitetura by michel miotto barbosa

eu penso que quando há usuário é arquitetura (mais próxima de arte que engenharia), vai usar metodologia, conceitos amplamente (as vezes nem tanto) aceitos etc.
mas quando não há usuários, para mim é engenharia.
ops, o que seriam usuários? - basicamente eles existem quando são considerados ou participam.
assim, pergunto alguém já viu um usuário da ponte ser entrevistado para compreender como ele vai usar a ponte? eu não. (imagine como seria entrevistar alguem para entender como ele vai usar a ponte).
bem, sei que tem sim arquitetura na construção das pontes - porém ela tbm não entrevista (que eu sei).
assim só facilita a engenharia - é uma etapa da engenharia a frescura que os engenheiros não querem fazer (eles preferem os cálculos, lembra).
isto acontece com software? não!. é preciso e muito usar o usuário, não é?
a arquitetura dá-se para criar o ambiente (percepções, abstrações, usabilidade bla,bla,bla), é software não? então concordo que para software não há engenharia mas arquitetura.
e ai, tu pensa o que?

Desenvolvimento de software não deveria se chamar "ENGENHARIA" by ROLIM FOR COMPUTERS

Concordo com a frase: "A construção de pontes seguem um conjunto fixo de requisitos similares para todas as pontes, mas o desenvolvimento de software parte de um grande vazio, de caprichos e declarações ambíguas".
.
Nunca temos visão, nem mesmo razoável de como um software será no início do seu projeto. E também o desenvolvimento de software é contínuo, ou seja, mesmo depois de entregue (parcial ou completo), ainda depende de mais e mais manutenção por causa dos requisitos mutáveis do usuário.
.
Porém, pode ser considerado uma disciplina. A tomada de decisão pode se basear na experiência alheia. É possível compartilhar técnicas que nos orientam, mas junto com essa ciência sempre haverá aquele lado experiência e "arte".

Muitas metáforas são válidas - depende do enfoque by Arisio Costa

Desenvolver software é amplamente reconhecido como algo complexo, talvez uma das atividades mais complexas para a mente humana, e, em parte devido a isso, já foi associada com diversas metáforas. Em algumas de que me lembro os desenvolvedores são comparados a artistas, artesãos, jardineiros. O processo/indústria de software já foi comparado com a indústria cinematográfica, com a engenharia e com fábricas em geral. Ao ler um artigo do diretor de teatro Aderbal Freire-Filho (Um artista municipal, publicado no O Globo de 25/01/2002) também fiz associações imediatas com nosso contexto de software.
Particularmente, eu nunca gostei do termo Engenharia de Software, e menos ainda de Fábrica de Software, basicamente por achar que transmitem uma idéia de precisão, e previsibilidade científicas, que estão longe existir, se é que existirão algum dia. Como esse é um assunto sobre o qual gosto de conversar, vou produzir um post mais elaborado sobre o mesmo, e espero publicá-lo em breve. Por enquanto fiz um texto abordando a metáfora do jardineiro, cujo esboço já existia há algum tempo, e pode ser visto em desenvolvimentodesoftware.wordpress.com/.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

22 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT