O desenvolvimento de software nunca será engenharia?
- Compartilhar
-
- |
Marcar como favorito
Favoritos
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?
Sim...ou não!
by
Rafael Pedroso
Concordo plenamente!
by
Jim Mayal
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
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
Regulamentação é tudo
by
Fábio Costa Silva
Re: Regulamentação é tudo
by
Allan Araujo
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
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
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
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
Sds
Tá mais pra jardinagem
by
Julio Faerman
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
Tudo eh uma questao de responsabilidade
by
Juan Pereira
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
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
Re: Regulamentação é tudo
by
Fábio Costa Silva
Re: Tá mais pra jardinagem
by
Antonio Nascimento
quanto há usuário não é engenharia mas arquitetura
by
michel miotto barbosa
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
.
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
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/.
Conteúdo educacional
Desenvolvendo para o novo Firefox OS
André Garzia 19 Jun, 2013
Desenvolvimento de jogos no Android
Anderson Leite 13 Jun, 2013
Olá visitante
Você precisa cadastrar-se no InfoQ Brasil ou Login para enviar comentários. Há muitas vantagens em se cadastrar.Obtenha o máximo da experiência do InfoQ Brasil.
Dê sua opinião