O desenvolvimento de software é uma disciplina de engenharia?

O desenvolvimento de software pode ser considerado engenharia? Se não, quais são as coisas que lhe faltam para se qualificar como uma disciplina de engenharia? Relacionada a esta, há uma pergunta no Stack Overflow sobre a diferença entre um programador e um engenheiro de software .

Existe o Instituto de Engenharia de Software da Universidade Carnigie Mellon que prescreve e mantém os padrões CMMI. Isso é algo que transformará desenvolvimento em engenharia?

É engenharia de desenvolvimento de software? Se não, quais são as coisas que lhe faltam para se qualificar assim?

Sim, a engenharia de software é uma disciplina de engenharia.

A Wikipedia define engenharia como "a aplicação da matemática, bem como do conhecimento científico, econômico, social e prático, a fim de inventar, inovar, projetar, construir, manter, pesquisar, pesquisar e melhorar estruturas, máquinas, ferramentas, sistemas, componentes, materiais. , processos, soluções e organizações ". O resultado da engenharia de software é um sistema de software que pode melhorar a vida das pessoas e pode envolver alguma combinação de conhecimento científico, matemático, econômico, social ou prático.

Em termos de como é visto, academicamente e profissionalmente, isso varia. Os programas de engenharia de software podem ser credenciados pela ABET como programas de engenharia. Os engenheiros de software podem ser membros do IEEE. Algumas empresas consideram a engenharia de software uma disciplina de engenharia, enquanto outras não - é realmente uma brincadeira.

O melhor livro sobre esse assunto é o Desenvolvimento de software profissional de Steve McConnell: cronogramas mais curtos, produtos de maior qualidade, projetos mais bem-sucedidos, carreiras aprimoradas . Ele olha para a engenharia de software como uma profissão, a evolução de um ofício para uma profissão, a ciência do desenvolvimento de software, a diferença entre software de engenharia e software de engenharia (aplicando práticas de engenharia de software contra engenheiros que acontecem software de construção, com um estudo de caso que inclui minha alma mater ), certificação e licenciamento e ética.

Glenn Vanderburg tem uma série de palestras denominadas "Real Software Engineering", realizadas entre 2010 e 2015 em várias conferências, além de duas palestras relacionadas, "Artesanato, Engenharia e a Essência da programação" (dada em 2011 como palestra na RailsConf) e "Craft and Software Engineering" (realizada em 2011 na QCon London). Eu acho que essas conversas são um argumento bastante abrangente sobre por que a engenharia de software é uma disciplina de engenharia.

Um argumento, que Vanderburg menciona brevemente em suas palestras, é o de Jack W. Reeves em 1992 (e revisitado novamente em 2005) sobre o que é design de software e como o código é o resultado das atividades de design de engenharia de software ( isso também é discutido no wiki C2) Depois que você se afasta das escolas de pensamento mais antigas, onde especificação e modelagem são design de software e o código é design de software, algumas das relações entre engenharia de software e outras disciplinas de engenharia se tornam mais facilmente aparentes. Algumas diferenças e os motivos dessas diferenças se tornam ainda mais aparentes depois que você vê que a economia do desenvolvimento de software é muito diferente de muitas outras disciplinas - a construção é barata (quase gratuita, em muitos casos), enquanto o design é a parte cara.

Isso é [CMMI] algo que transformará desenvolvimento em engenharia?

Não. O CMMI é uma estrutura de melhoria de processo que fornece orientação às organizações sobre que tipos de atividades são úteis na criação de software. As disciplinas de engenharia geralmente têm um processo de engenharia. Ter esse processo é importante para a conclusão bem-sucedida de projetos de alta qualidade. Dito isso, o CMMI (ou qualquer outra estrutura ou metodologia de processo) é apenas uma ferramenta - o uso não fará com que você avance magicamente de um desenvolvedor para um engenheiro. No entanto, não seguir algum tipo de processo é, na minha opinião, um sinal de um projeto que não é um projeto de engenharia.

Além disso, qual sua opinião sobre os cursos / certificados de engenharia de software?

É apenas o valor que as outras pessoas colocam nele. Existem cursos úteis e cursos inúteis. Existem certificados valiosos e certificados que não valem o papel em que são impressos. Existem muitos fatores, de quem está endossando ou credenciando o curso ou quem está emitindo o certificado para o seu setor de trabalho atual, para o seu emprego atual e para onde deseja ir.

Vindo de uma formação típica de engenharia, mas fazendo carreira no desenvolvimento de software, vejo grandes semelhanças entre os dois mundos. Aparte talvez da definição exata de engenharia, vejo na prática que desenvolver software não é tão diferente de desenvolver um produto físico. Pelo menos acho que não deve ser muito diferente.

Se você projeta uma aeronave ou um aplicativo de software, para ambos, você precisa:

• fazer desenhos
• definir subsistemas e componentes
• fazer protótipos
• especificar e executar testes
• etc.

Li em outra resposta que o design de software é diferente porque você não projeta tudo antes de iniciar a programação. Bem, na verdade, em menor grau, também é o caso quando você cria um produto físico. Projetar, criar protótipos e testar é um processo iterativo.

Além disso, quando os projetos de software aumentam de tamanho, fica mais importante definir subsistemas, componentes e interfaces claros, o que também é semelhante ao design de produtos complexos, como uma aeronave.

É por isso que considero o desenvolvimento de software uma engenharia.

Eu argumentaria que existe de fato algo como engenharia de software.

A engenharia envolve a aplicação sistemática do conhecimento científico na solução de problemas. A complexidade dos problemas enfrentados hoje não é tão diferente dos enfrentados por um engenheiro elétrico na criação de um circuito ou um engenheiro químico na concepção de um processo de fabricação ou um engenheiro mecânico na criação de um dispositivo.

O fato de também haver uma abordagem prática da aplicação de planos existentes (desenvolvimento neste caso) é simplesmente semelhante ao fato de que em outros campos outra pessoa executa esses planos (por exemplo, o trabalhador da construção).

É verdade que a maioria dos desenvolvedores também realiza tarefas de engenharia de software e que nossa educação geralmente não é em programação, mas em engenharia de software. Então, nós sujamos nossas mãos, enquanto um engenheiro civil não.

No entanto, a capacidade de aplicar uma linguagem de programação e um programa não transforma um em engenheiro: eu conheci minha parcela de desenvolvedores que não têm uma compreensão verdadeira das complexidades e problemas fora do código atual.

Quanto à sua pergunta sobre a CMU: A aplicação de um padrão ou prática (por exemplo, CMMI) não transforma automaticamente o trabalho de uma pessoa em engenharia. No entanto, o fato de existirem organizações que realizam pesquisas científicas para fornecer novas práticas é novamente um sinal de que existe algo como engenharia.

Não, não é engenharia. Não somos tão científicos e não precisamos passar por nenhum desses testes de engenharia do estado. De fato, é ilegal chamar a si mesmo de "engenheiro" de software em alguns lugares devido à falta de testes.

IMHO, o termo 'engenharia de software' foi cunhado para tentar descrever melhor a variedade de coisas que um desenvolvedor faz, em vez de apenas ser um 'programador' (que tem conotações de algum processo mecanicista com pouco pensamento ou criatividade).

Pessoalmente, prefiro a analogia emergente de um desenvolvedor como um 'artesão', defendido por programadores pragmáticos, entre outros.

Historicamente, as pessoas tentaram analogizar a criação de software com a manufatura. Acho que Jack Reeves fez um bom argumento para desacreditar essa idéia em seu artigo O que é design de software .

Do Wiki:

Engenharia :

Engenharia de software é a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software, e o estudo dessas abordagens; isto é, a aplicação da engenharia ao software.

Desenvolvimento de software

Desenvolvimento de software é o conjunto de atividades que resulta em produtos de software. O desenvolvimento de software pode incluir pesquisa, novo desenvolvimento, modificação, reutilização, reengenharia, manutenção ou qualquer outra atividade que resulte em produtos de software. [1]

Especialmente a primeira fase do processo de desenvolvimento de software pode envolver muitos departamentos, incluindo marketing, engenharia, pesquisa e desenvolvimento e gerenciamento geral.

Eles são bem parecidos e também podem significar a mesma coisa.

From Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

–Noun 1. a arte ou ciência da aplicação prática do conhecimento das ciências puras, como física ou química, como na construção de motores, pontes, edifícios, minas, navios e fábricas de produtos químicos.

Eu diria que a criação de software é a aplicação prática da matemática e da ciência da computação e, potencialmente, de qualquer outro número de ciências puras, dependendo da aplicação.

[EDIT] FWIW, eu não me considero um engenheiro de software, mas um desenvolvedor de software, então não tenho interesse pessoal nisso.

Na minha opinião, um engenheiro de software e desenvolvedor de software são duas coisas diferentes.

Eu vejo um engenheiro de software como alguém que faz planejamento, como qual será o ciclo de vida do desenvolvimento, cumprindo requisitos / especificações, etc ... Basicamente, um engenheiro de software lida com muita documentação. Isso pode ser realizado por um desenvolvedor de software e / ou gerente de projeto.

Um desenvolvedor de software estaria mais intimamente relacionado a um programador, mas com mais habilidades em outras áreas, como gerenciamento de banco de dados, etc.

Uma coisa interessante a ser mencionada é arquitetura . Alguém que também esteja envolvido em descobrir qual hardware / software será necessário para o ciclo de vida do projeto.

Eu vou com "Não" aqui. Meu irmão é engenheiro mecânico e descreve a engenharia como "A arte de ser barato":

"Os engenheiros estão mais preocupados em fazer as coisas o mais rápido possível, com o menor custo possível, o menor número possível de materiais " .

Em reação, vim descrever o desenvolvimento de software (não a engenharia de software - são realmente dois campos distintos) como "A Arte de Ser Eficiente":

"Os desenvolvedores estão mais preocupados em fazer as coisas o mais rápido possível, com o menor custo possível, com o mínimo de repetição possível " .

A diferença está na última parte dessas frases.

É engenharia de desenvolvimento de software?

Não. Ser um engenheiro significa que seu projeto segue uma linha do tempo de causa e efeito - você segue os códigos de construção e, portanto, sua construção não cai (ou pelo menos você não pode ser responsabilizado). Com o software de escrita, você pode seguir todas as orientações (e existem tantas diferentes para escolher!) E ainda pode travar / travar / fornecer respostas erradas (a menos que você esteja envolvido no extraordinariamente pequeno campo de escrever programas prováveis ​​ao lado) linguagens funcionais sem efeito).

Eu vejo um engenheiro (mecânico, estrutural, software) como alguém que projeta o produto antes, com base nas necessidades compreendidas e um entendimento do que e como aplicar os materiais para acomodar essa necessidade.

Por exemplo, muitas vezes você pode ver um engenheiro estrutural procurando diferentes forças de aço e aplicando regras da física para calcular os materiais necessários e como eles devem ser implementados. A engenharia estrutural é um excelente exemplo, porque você sempre termina com uma planta (especificação) do que irá construir antes de construir. Isso nem sempre acontece com o software.

Para mim, a diferença de um engenheiro de software e um programador é que o engenheiro é capaz de construir a especificação para o que será produzido antes de escrever qualquer código, onde um programador apenas escreve o código com base nas especificações de alguém ou é um deles programadores do oeste selvagem que escrevem código sem especificações. Além disso, o engenheiro é formado.

Comparo a diferença entre um trabalhador da construção civil e um engenheiro estrutural à diferença entre um programador e um engenheiro de software.

Para esclarecer, eu só tenho um diploma de faculdade, então não posso me chamar de engenheiro.

Eu não consideraria o termo "engenharia" o mais apropriado para descrever o desenvolvimento de software, por 2 razões principais:

• Ele transmite muitas idéias antigas, conceitos e as chamadas "regras de ouro" originárias de disciplinas tradicionais de engenharia, como engenharia industrial, civil, naval ou mecânica. Estou falando de regras na divisão de trabalho, processos de produção, padrões de qualidade ... Na maioria das vezes, isso se aplica apenas marginalmente ao software.

• Ele não descreve de maneira satisfatória o que a programação tem mais do que outras disciplinas (e acredito que tem muito mais e muito diferente) e quais novos desafios os desenvolvedores precisam enfrentar no dia-a-dia em comparação com seus colegas tradicionais. domínios de engenharia. A natureza virtual e imaterial do software desempenha um papel enorme nisso.

O desenvolvimento de software tem sido visto como "apenas mais uma disciplina de engenharia". Considerando as taxas de falha dos projetos de software que conhecemos desde que foram medidos, é hora de reconhecermos o desenvolvimento como um animal totalmente novo, o código como um material realmente especial e o ciclo de vida do aplicativo como um tipo totalmente diferente de ciclo de produção e paramos de tentar desesperadamente para aplicar receitas antigas a eles.

Sim, é preciso poder aplicar padrões e princípios para chegar a um produto decente. O que dificulta é a mentalidade do cliente (é apenas código - não deve custar muito para mudar), a extrema dificuldade em codificar o que o produto deve fazer em código de máquina (linguagem falada / escrita para codificar) e quantificar " qualidade". Sua definição de qualidade não é minha.

Também é repetibilidade. Pegue um conjunto de requisitos e entregue a duas equipes. Quando você consegue fazer a mesma coisa (sem as equipes conversando entre si), você está bem perto da engenharia.

Outras áreas da engenharia também têm penalidades e uma rígida revisão e aprovação. Prestação de contas.

Não. Engenharia de software não é engenharia. Na minha opinião, a diferença está na quantidade de criatividade envolvida. Na engenharia civil, por exemplo, pode haver muito pouca ou nenhuma criatividade. Isto é uma coisa boa.

Para construir uma ponte, você tem um conjunto de especificações (eu preciso obter esse número de carros deste lado do rio para o outro lado).

Disto, posso deduzir:

1. o número de faixas de rodovia necessárias (usando um cálculo padrão definido pelo governo);
2. as cargas que precisarei suportar (usando cálculos definidos pelo governo)
3. os materiais que eu preciso usar para suportar essas cargas (usando materiais padrão, que posso obter de vários fornecedores diferentes, ou materiais não padronizados, que eu tenho que provar que terão as propriedades corretas).

Em seguida, preciso que o projeto seja aprovado e verificado por terceiros (outra empresa) para garantir que eu fiz meus cálculos corretamente.

Então, quando a ponte for realmente construída, o trabalho será realizado por pessoas qualificadas de maneira padrão. Eles farão um trabalho que fizeram centenas, talvez milhares de vezes antes.

Não me interpretem mal, todo projeto de engenharia civil é diferente, mas parece que toda vez que desenvolvo um novo aplicativo / site, as coisas são feitas de maneira diferente.

Sim, eu acho que o desenvolvimento é um subconjunto da engenharia:

• A engenharia de software inclui a especificação inicial ("que tipo de software precisamos aqui?"), Que provavelmente precede o desenvolvimento
• A "engenharia" também pode incluir, por exemplo, a definição do processo de garantia da qualidade, que certamente está relacionado ao desenvolvimento, mas também fora do escopo da 'construção' propriamente dita.

O Code Complete define "construção" como sinônimo de codificação e depuração (e comentários), também com design detalhado previamente e com testes de unidade e integração posteriormente. O Capítulo 1, Bem-vindo à construção de software (PDF), começa listando muitos tópicos no ciclo de vida de desenvolvimento de software geral (incluindo definição de problemas, arquitetura de software, manutenção corretiva etc.) e, em seguida, diz:

Como a figura indica, a construção é principalmente de codificação e depuração, mas também envolve design detalhado, planejamento de construção, teste de unidade, integração, teste de integração e outras atividades. Se este fosse um livro sobre todos os aspectos do desenvolvimento de software, ele apresentaria discussões bem equilibradas de todas as atividades no processo de desenvolvimento. Como este é um manual de técnicas de construção, no entanto, coloca uma ênfase desigual na construção e apenas toca em tópicos relacionados. Se este livro fosse um cachorro, ele se aproximaria da construção, abanava a cauda no design e nos testes e latia nas outras atividades de desenvolvimento.

Desenvolvimento de software é engenharia.

Alguns argumentos apresentados por outros por que a engenharia de software não atende ao padrão de engenheiro:

Alguns dizem que os engenheiros estão no negócio de projetar "coisas" para o bem público - ICBMs, tanques etc. são do bem público? Alguns diriam que sim (um bom ataque é uma boa defesa) outros diriam que não. No entanto, acho que ninguém discordaria que o cara que cria o sistema de segmentação de tanques da próxima geração é um engenheiro. O bem público pode ser subjetivo. De qualquer forma, muitos softwares são de interesse público, portanto, o ponto é discutível de qualquer maneira.

Outros dizem que os engenheiros projetam que não constroem. Eu já vi vários comentários do tipo "engenheiros mecânicos não soldam". Eu argumentaria que os engenheiros mecânicos produzem projetos - projetos detalhados que algo mais implementa. Se um engenheiro mecânico produz um projeto e o envia para uma máquina CNC, isso não faz mais com que ele seja um engenheiro mecânico - porque uma máquina fez a implementação em vez de uma pessoa? Eu argumentaria que o código-fonte é um plano detalhado que é alimentado a uma máquina que executa a implementação e não vejo como isso é diferente de um código de alimentação MechE para uma máquina CNC. E agora temos impressoras 3D, isso significa o fim dos engenheiros mecânicos? Eles agora são desenvolvedores mecânicos?

Licenciamento é o outro tópico que vejo surgir. Atualmente, apenas algumas jurisdições licenciam engenheiros de software. Até o momento, não há licenciamento de engenheiros de software nos EUA (acho que apenas o Texas o faz). Alguns usaram isso como uma razão para afirmar que a engenharia de software não deve ser chamada de engenharia. O PE para engenheiros de software está chegando. Porém, em um nível mais filosófico, apenas porque alguns legisladores estaduais escolhem (ou não) chamar a engenharia de desenvolvimento de software não têm efeito na realidade.