Yazılım geliştirme bir mühendislik disiplini midir?


16

Yazılım geliştirme mühendislik olarak düşünülebilir mi? Hayır ise, mühendislik disiplini olarak nitelendirilebilmesi için eksik olan şeyler nelerdir? Buna bağlı olan bir programcı ve yazılım mühendisi arasındaki fark hakkında Yığın taşması bu soru .

Carnigie Mellon Üniversitesi'nde CMMI standartlarını belirleyen ve sürdüren Yazılım Mühendisliği Enstitüsü bulunmaktadır. Bu gelişmeyi mühendisliğe dönüştürecek bir şey mi?


Yanıtlar:


20

Yazılım geliştirme mühendisliği mi? Hayır ise, bu şekilde kalifiye olmak için eksik olan şeyler nelerdir?

Evet, yazılım mühendisliği bir mühendislik disiplinidir.

Wikipedia, mühendisliği "matematik, bilimsel, ekonomik, sosyal ve pratik bilgilerin yanı sıra yapıları, makineleri, araçları, sistemleri, bileşenleri, malzemeleri icat etmek, yenilik yapmak, tasarlamak, inşa etmek, bakımını yapmak, araştırmak ve geliştirmek için" matematik uygulaması "olarak tanımlar. , süreçler, çözümler ve kuruluşlar. " Yazılım mühendisliğinin sonucu, insanların yaşamlarını iyileştirebilecek bir yazılım sistemidir ve bilimsel, matematiksel, ekonomik, sosyal veya pratik bilgilerin bir kombinasyonunu içerebilir.

Akademik ve profesyonel olarak nasıl görüldüğü açısından değişir. Yazılım mühendisliği programları ABET tarafından mühendislik programları olarak akredite edilebilir. Yazılım mühendisleri IEEE üyesi olabilir. Bazı şirketler yazılım mühendisliğini bir mühendislik disiplini olarak görürken, diğerleri bunu yapmaz.

Bu konuda en iyi kitap Steve McConnell'in Profesyonel Yazılım Geliştirme: Kısa Çizelgeler, Yüksek Kaliteli Ürünler, Daha Başarılı Projeler, Geliştirilmiş Kariyer . Yazılım mühendisliğini bir meslek, bir zanaattan bir mesleğe evrim, yazılım geliştirme bilimi, yazılım mühendisliği ve yazılım mühendisliği arasındaki farkı (yazılım geliştiren mühendislere yazılım uygulamalarına mühendislik uygulamaları uygulamak gibi bir örnek olay incelemesi) içeriğimi içeriyor ), sertifikalandırma ve lisanslama ve etik.

Glenn Vanderburg, 2010 ve 2015 yılları arasında bir dizi konferansta "Gerçek Yazılım Mühendisliği" adında bir dizi görüşmenin yanı sıra "Craft, Engineering ve Programlama Özü" (2011'de açılış konuşması) ve "El Sanatları ve Yazılım Mühendisliği" (2011'de QCon Londra'da verilmiştir). Bu görüşmelerin yazılım mühendisliğinin neden bir mühendislik disiplini olduğu konusunda oldukça kapsamlı bir argüman olduğunu düşünüyorum.

Vanderburg'un görüşmelerinde kısaca ortaya koyduğu bir tartışma, 1992'de Jack W. Reeves tarafından (ve yine 2005'te tekrar ziyaret edildi) yazılım tasarımının ne olduğu ve kodun yazılım mühendisliği tasarım faaliyetlerinin nasıl çıktısı olduğu konusudur ( bu da C2 wiki'de tartışıldı). Spesifikasyon ve modellemenin yazılım tasarımı olduğu ve kodun yazılım tasarımı olduğu eski düşünce okullarından uzaklaştığınızda, yazılım mühendisliği ve diğer mühendislik disiplinleri arasındaki ilişkilerin bir kısmı daha kolay anlaşılır hale gelir. Bazı farklılıklar ve bu farklılıkların nedenleri, yazılım geliştirme ekonomisinin diğer birçok disiplinden çok farklı olduğunu gördükten sonra daha da belirgin hale gelir - tasarım ucuz (çoğu durumda ücretsizdir), tasarım ise pahalı kısımdır.

Bu [CMMI] gelişimi mühendisliğe dönüştürecek bir şey mi?

Hayır. CMMI, yazılım geliştirirken ne tür faaliyetlerin yararlı olduğu konusunda kuruluşlara yol gösteren bir süreç iyileştirme çerçevesidir. Mühendislik disiplinleri genellikle bir mühendislik sürecine sahiptir. Böyle bir sürece sahip olmak, yüksek kaliteli projelerin başarıyla tamamlanması için önemlidir. Bununla birlikte, CMMI (veya başka herhangi bir süreç çerçevesi veya metodolojisi) sadece tek bir araçtır - bunu kullanmak bir geliştiriciden mühendise sihirli bir şekilde ilerlemenizi sağlamaz. Ancak, bir tür süreci takip etmemek, bence, mühendislik projesi olmayan bir projenin işaretidir.

Ayrıca, yazılım mühendisliği kursları / sertifikaları hakkında ne düşünüyorsunuz?

Diğer insanların içine koyduğu kadar değerlidir. Yararlı dersler var ve işe yaramaz dersler var. Değerli sertifikalar ve yazdırıldıkları kağıda değmeyen sertifikalar vardır. Kursu kimin onayladığı veya akredite ettiği veya mevcut işinize mevcut işinize ve nereye gitmek istediğinize sertifika veren birçok faktör vardır.


9

Tipik bir mühendislik geçmişinden geliyor, ancak yazılım geliştirmede kariyer yapıyor, her iki dünya arasında büyük benzerlikler görüyorum. Belki de mühendisliğin tam tanımından ayrı olarak, pratikte yazılım geliştirmenin fiziksel bir ürün geliştirmekten farklı olmadığını görüyorum. En azından bence çok farklı olmamalı.

İster bir uçak, ister bir yazılım uygulaması tasarlayın, her ikisi için:

  • tasarım yapmak
  • alt sistemleri ve bileşenleri tanımlar
  • prototip yapmak
  • testleri belirleme ve yürütme
  • vb.

Başka bir cevapta yazılım tasarlamanın farklı olduğunu bir yerde okudum çünkü programlamaya başlamadan önce her şeyi tasarlamıyorsunuz. Aslında daha az bir ölçüde fiziksel bir ürün tasarlarken de durum böyle. Tasarım ve prototip oluşturma ve test yinelemeli bir süreçtir.

Ayrıca yazılım projeleri büyüdükçe, uçak gibi karmaşık ürünler tasarlamaya benzer net alt sistemler, bileşenler ve arayüzler tanımlamak daha da önem kazanmaktadır.

Bu yüzden yazılım geliştirmeyi mühendislik olarak görüyorum.


2
Deneyiminizi paylaştığınız için teşekkür ederiz, birçok "geliştiricinin" mühendisliğin gerçekte ne olduğu hakkında hiçbir fikri yoktur. Şerefe!
LeWoody

7

Yazılım mühendisliği diye bir şeyin olduğunu iddia ediyorum.

Mühendislik, bilimsel bilginin problemlerin çözümüne sistematik olarak uygulanmasını içerir. Bugün ele alınan sorunların karmaşıklığı, bir elektrik mühendisi tarafından bir üretim süreci tasarlamada bir devre veya bir kimya mühendisi ya da bir cihazın oluşturulmasında bir makine mühendisi tarafından ele alınan sorunlardan farklı değildir.

Mevcut planları (bu durumda gelişme) uygulamak için uygulamalı bir yaklaşımın olması, diğer alanlarda başkalarının bu planları (ör. İnşaat işçisi) yürütmesine benzerdir.

Çoğu geliştiricinin de yazılım mühendisliği görevleri taşıdığı ve eğitimimizin genellikle programlamada değil, yazılım mühendisliğinde olduğu doğrudur. Yani bir inşaat mühendisi yapmazken ellerimizi kirletiyoruz.

Bununla birlikte, bir programlama dili ve programı uygulama becerisi bir mühendise dönüşmez: Mevcut kodlarının dışındaki karmaşıklıkları ve sorunları tam olarak anlamayan geliştiricilerden payımla tanıştım.

CMU ile ilgili sorunuza gelince: Bir standardın veya uygulamanın (örn. CMMI) uygulanması, bir kişinin çalışmasını otomatik olarak mühendisliğe dönüştürmez. Bununla birlikte, yeni uygulamalar sağlamak için bilimsel araştırma yapan organizasyonların olması, yine mühendislik gibi bir şeyin olduğunun bir işaretidir.


5

Hayır, mühendislik değil. Biz o kadar bilimsel değiliz ve bu devlet mühendisliği testlerinden hiçbirini geçmek zorunda değiliz. Aslında, test eksikliği nedeniyle bazı yerlerde kendinize bir yazılım "mühendisi" demek yasadışıdır.


Aslında, nerede yaşadığınıza bağlıdır. Quebec'te, mühendislik dereceniz, sınavlarınız vb.
Olmadıkça

Kanıt sunun, lütfen.
Thomas Owens

1
İşte, Ordre des ingenieurs SSS bölümünden. oiq.qc.ca/cgi-bin/…
Kena

2
Ne yaptığınıza bağlıdır. P. Eng tanımına hak kazanan yazılım mühendisliği dereceleri vardır. Nükleer santralleri kontrol etmek veya birilerini marslara göndermek için yazılım geliştiriyorsanız, muhtemelen bir mühendis olmanız gerekecektir.
17'de tloach

Mühendislik toplumlarının çoğunun SE'yi tanımamasının nedenleri politik ve ekonomiktir: çok az üniversite resmi olarak yazılım mühendisliği derecesini verir. En iyi ihtimalle, bunu küçümseyebilir veya yüksek lisans yapabilirsiniz.
Uri

5

IMHO 'yazılım mühendisliği' terimi, sadece bir 'programcı' olmaktan ziyade (az bir düşünce ya da yaratıcılıkla bazı mekanik süreçlerin tonlarını taşıyan) geliştiricinin yaptığı şeyleri daha iyi tanımlamaya çalışmak için üretildi.

Şahsen ben, bir geliştiricinin pragmatik programcılar tarafından savunulan bir 'zanaatkâr' olarak ortaya çıkan benzetmesini tercih ederim.

Tarihsel olarak, insanlar yazılım yaratmayı imalatla analoglaştırmaya çalıştılar. Bence Jack Reeves, Yazılım Tasarımı Nedir makalesinde bu fikri itibarsızlaştırmak için oldukça iyi bir tartışma yaptı .


Ancak imalat sadece bir mühendislik alanıdır. Yazılım geliştirme! = Üretiminin ilgi çekici olduğunu, ancak yazılım geliştirmenin mühendisliğin bir parçası olup olmadığı konusundaki bir argümanla doğrudan ilgili olmadığını iddia eder. Uçak tasarımı da üretim gibi değil, her ikisi de mühendislik alanları.
MarkJ

5

Wiki'den:

Mühendislik:

Yazılım mühendisliği, yazılımın geliştirilmesi, işletilmesi ve bakımına sistematik, disiplinli, ölçülebilir bir yaklaşımın uygulanması ve bu yaklaşımların incelenmesidir; yani mühendisliğin yazılıma uygulanması.

Yazılım geliştirme

Yazılım geliştirme, yazılım ürünleri ile sonuçlanan faaliyetler kümesidir. Yazılım geliştirme, araştırma, yeni geliştirme, değiştirme, yeniden kullanım, yeniden mühendislik, bakım veya yazılım ürünleri ile sonuçlanan diğer faaliyetleri içerebilir. [1]

Özellikle yazılım geliştirme sürecinin ilk aşaması pazarlama, mühendislik, araştırma ve geliştirme ve genel yönetim dahil olmak üzere birçok departmanı içerebilir.

Yani oldukça benzerler ve aynı şey anlamına da gelebilirler.


1
İşlev adım aslında "yazılım geliştirme mühendisi" içeriyor ... gerçekten karıştı: s
fretje

4

Başlangıç sayfası : en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

–Noun 1. motorlar, köprüler, binalar, madenler, gemiler ve kimyasal tesislerin inşasında olduğu gibi fizik veya kimya gibi saf bilimler bilgisinin pratik uygulamasını yapma sanatı veya bilimi.

Yazılım oluşturmanın, matematik ve bilgisayar bilimlerinin pratik bir uygulaması olduğunu ve uygulamaya bağlı olarak herhangi bir sayıda saf bilimin potansiyel uygulaması olduğunu söyleyebilirim.

[EDIT] FWIW, kendime yazılım mühendisi değil, yazılım geliştiricisi diyorum, bu yüzden bu konuda kişisel bir payım yok.


3

Bana göre bir Yazılım Mühendisi ve Yazılım Geliştirici iki farklı şeydir.

Yazılım mühendisliğini planlama yapan biri olarak görüyorum , gelişimin hangi yaşam döngüsünün alacağı, gereksinimler / spesifikasyonlar vb. Yapıyor ... Temel olarak, bir yazılım mühendisi birçok belge ile ilgilenir. Bu bir yazılım geliştiricisi ve / veya proje yöneticisi tarafından gerçekleştirilebilir.

Bir yazılım geliştiricisi bir programcı ile daha yakından ilişkilidir ancak veritabanı yönetimi gibi diğer alanlarda daha fazla beceriye sahiptir.

Ortaya çıkarmak için ilginç bir şey Mimarlık . Projenin yaşam döngüsü için hangi donanımın / yazılımın gerekli olacağını bulmakla ilgilenen biri.


Yazılım geliştirmenin yazılım mühendisliği kategorilerinden biri olduğuna inanıyorum.
LeWoody

1

Burada "Hayır" ile gideceğim. Kardeşim makine mühendisidir ve mühendisliği "Ucuz Olma Sanatı" olarak tanımlamaktadır:

"Mühendisler işleri mümkün olan en hızlı şekilde, mümkün olan en düşük maliyetle ve mümkün olan en az malzemeyle yapmakla daha fazla ilgileniyorlar . "

Tepki olarak, yazılım geliştirmeyi (yazılım mühendisliği değil - aslında temelde iki ayrı alandır) "Verimli Olma Sanatı" olarak tanımlamaya geldim:

"Geliştiriciler mümkün olan en hızlı şekilde, mümkün olan en düşük maliyetle ve mümkün olan en az tekrarlamayla işlerin yapılmasını istiyorlar. "

Aradaki fark bu cümlelerin son bölümünde.


Komik ve gerçek "Mühendislik" kavramına iyi görünüm.

Başka birinin onunla hemfikir olduğunu ona bildireceğim - memnun olmalı. : D

2
En azından bazı durumlarda buna katılmıyorum. Havacılık endüstrisi ve NASA için ucuzluktan önce birçok mülk yerleştirecek insanları tanıyorum. Mühendis ihtiyaçları dengelemede iyidir.
Uri

Bana çok kötü bir fikir gibi geliyor. Gerçekleri destekleyebilir misiniz?
Jeremy

Bekle ... Kafam karıştı. Kimin görüşü yıpranmış? Benim mi yoksa erkek kardeşimin mi?

1

Yazılım geliştirme mühendisliği mi?

Hayır. Mühendis olmak, projenizin bir sebep-sonuç zaman çizelgesini takip ettiği anlamına gelir - bina kodlarını takip edersiniz, bu nedenle binanız düşmez (veya en azından varsa suçlanamazsınız). Yazılım yazarken, tüm yönergeleri takip edebilirsiniz (ve aralarından seçim yapabileceğiniz çok farklı yönergeler var!) Etkisiz işlevsel diller).


2
Yaklaşık bir buçuk yıl önce felaketle sonuçlanan 35W köprüsünden birkaç mil uzakta yaşıyorum. Mühendis olmak, batırmaya karşı bağışık olduğunuz anlamına gelmez.
David Thornley

David ile hemfikirim. Hem yazılımda hem de yapımda bilimsel bir 'neden-sonuç' metodolojisini takip edebileceğinizi düşünüyorum. Bu, ikisinin de sorunlara karşı bağışık olmadığı anlamına gelmez.
Jeremy

Belki de fark, riskli kodu test etmenin daha kolay olmasıdır.
kleineg

1

Bir mühendisi (mekanik, yapısal, yazılım), anlaşılan ihtiyaçlara ve bu ihtiyacı karşılamak için malzemelerin ne ve nasıl uygulanacağına dair anlayışı temel alarak ürünü tasarlayan biri olarak görüyorum.

Örneğin, genellikle farklı çelik mukavemetlerini arayan ve gerekli malzemeleri ve bunların nasıl uygulanması gerektiğini hesaplamak için fizik kurallarını uygulayan bir yapısal mühendis görebilirsiniz. Yapısal mühendislik bunun en iyi örneğidir, çünkü her zaman inşa etmeden önce ne inşa edeceğinize dair bir taslak (şartname) elde edersiniz. Bu her zaman yazılımda olmaz.

Bana göre bir yazılım mühendisi ve bir programcı arasındaki fark, mühendisin herhangi bir kod yazmadan önce üretilecekler için şartnameyi inşa edebilmesidir, burada bir programcı ya kodu sadece bir başkasının spesifikasyonlarına dayanarak yazar veya bunlardan biri şartname olmadan kod yazan vahşi batı programcılar. Ayrıca, mühendis derecesine sahiptir.

Bir inşaat işçisi ile bir yapısal mühendis arasındaki farkı bir programcı ile yazılım mühendisi arasındaki farka benzetiyorum.

Açıklığa kavuşturmak için, sadece bir üniversite diplomam var, bu yüzden kendime mühendis diyemem.


1
Kodlamadan önce bir şartname bulmak her zaman mümkün değildir ve kodlamanın ürünü tasarladığı konusunda iyi bir tartışma yapabilirim. Yazılımda, bitmiş bir ürünün kopyalarını üretmek önemsizdir.
David Thornley

Tamamen düşünülmüş bir tasarımdan önce kodlamanın, tasarımın kodun evriminin bir yan etkisi olmasını sağladığını iddia ediyorum. Tasarım koddan önce veya sonra gelebilir. Tasarımı tasarlar, sonra kodu kodla uygularsınız veya kodu uygularsınız ve kod tamamlandıktan sonra tasarımınızın gerçekte ne olduğunu fark edersiniz (ve genellikle bir yazılım parçasına bakabilir ve hangi siparişin takip edildiğini bilirsiniz). Kodlamak için hiçbir şeyiniz olmayacağından SOME belirtimi olmadan asla kod yazamazsınız. Bu şartnamenin yazıldığı anlamına gelmez. Sadece kafanın içinde olabilir.
Jeremy

Tasarımı kod yazmaktan ayırıyorsunuz ve bunlar iki farklı şey değil. Kod yazma düşük seviyeli tasarımdır. "Tasarımın bir yan etki olarak gerçekleşmesine izin vermek ..." genellikle doğru ifade değildir: tasarım ne olursa olsun bir yan etki olarak gerçekleşir. Bu, özellikle orijinal gereksinimler belirsiz, yetersiz belirlenmiş veya esnek olduğunda, bu alandaki normal durumdur.
David Thornley

1

"Mühendislik" terimini 2 temel nedenden dolayı yazılım geliştirmeyi tanımlamak için en uygun olarak kabul etmem:

  • Endüstri, sivil, deniz veya makine mühendisliği gibi geleneksel mühendislik disiplinlerinden kaynaklanan birçok eski fikir, kavram ve "altın kurallar" taşır. İşbölümünde kurallar, üretim süreçleri, kalite standartları hakkında konuşuyorum ... Bunlar çoğunlukla yazılım için çok az geçerlidir.

  • Programlamanın diğer disiplinlerden daha fazla neye sahip olduğunu (ve bunun çok daha fazla ve çok farklı olduğuna inanıyorum) ve geliştiricilerin geleneksel mühendislik alanları. Yazılımın sanal ve önemsiz doğası bunda büyük bir rol oynamaktadır.

Yazılım geliştirme uzun zamandır "sadece başka bir mühendislik disiplini" olarak görülüyor. Ölçüldüğünden beri tanıdığımız yazılım projelerinin başarısızlık oranları göz önüne alındığında, gelişimi tamamen yeni bir hayvan olarak kabul etmenin, gerçekten özel bir malzeme ve uygulama yaşam döngüsünü tamamen farklı bir üretim döngüsü olarak kodlamanın ve umutsuzca denemeyi bırakmanın tam zamanı onlara eski tarifler uygulamak için.


0

Evet, iyi bir ürüne ulaşmak için standartlar ve ilkeler uygulanabilmelidir. Bunu zorlaştıran şey, müşterinin zihniyetidir (sadece kod - değişmesi çok pahalıya mal olmamalı), ürünün makine koduna ne yapması gerektiğini kodlamak (kodlamak için sözlü / yazılı dil) ve " kalite". Kalite tanımınız benim değil.

Ayrıca tekrarlanabilirlik. Bir takım gereksinimleri karşılayın ve iki takıma verin. Aynı şeyi dışarı çıkarabildiğinizde (ekipler birbirleriyle konuşmadan) mühendisliğe oldukça yakınsınız.

Diğer mühendislik alanlarında da cezalar ve katı bir gözden geçirme ve imzalama vardır. Hesap verebilirlik.


0

Hayır. Yazılım Mühendisliği mühendislik değildir. Benim düşünceme göre, fark ilgili yaratıcılık miktarında. Örneğin, İnşaat Mühendisliğinde yaratıcılık çok az olabilir veya hiç olmayabilir. Bu iyi birşey.

Bir köprü inşa etmek için bir dizi spesifikasyonunuz var (nehrin bu tarafından diğer tarafa bu sayıda araba almam gerekiyor).

Bundan şunu çıkarabilirim:

  1. ihtiyacım olan yol şeridi sayısı (hükümet tarafından tanımlanan standart bir hesaplamayı kullanarak);
  2. desteklemem gereken yükler (hükümet tarafından tanımlanan hesaplamaları kullanarak)
  3. bu yükleri desteklemek için kullanmam gereken malzemeler (bir dizi farklı tedarikçiden alabileceğim standart malzemeler veya daha sonra doğru özelliklere sahip olduğunu kanıtlamak zorunda olduğum standart olmayan malzemeler kullanarak).

Ardından, hesaplamalarımı doğru yaptığımdan emin olmak için tasarımı üçüncü bir taraf (başka bir şirket) tarafından onaylayıp kontrol etmeliyim.

Daha sonra, köprü gerçekten inşa edildiğinde, iş kalifiye insanlar tarafından standart bir şekilde yapılacaktır. Daha önce yüzlerce, belki de binlerce kez yaptıkları işleri yapacaklar.

Beni yanlış anlamayın, her inşaat mühendisliği projesi farklıdır, ancak her yeni uygulama / web sitesi geliştirdiğimde işler farklı şekilde yapılır.


0

Evet, geliştirmenin bir mühendislik alt kümesi olduğunu tahmin ediyorum:

  • Yazılım mühendisliği, tartışmayı geliştirmeden önce gelen ilk belirtimi ("burada ne tür bir yazılıma ihtiyacımız var?") İçerir.
  • "Mühendislik", aynı zamanda, kesinlikle kalkınma ile ilgili olan ancak tartışmalı olarak "inşaat" ın kapsamı dışında olan Kalite Güvence Sürecinin tanımlanmasını da içerebilir.

Kod Tamamlama , "yapıyı" kodlama ve hata ayıklama (ve yorumlama) ile eşanlamlı olarak tanımlar, ayrıca önceden ayrıntılı tasarım ve daha sonra birim ve entegrasyon testi ile de tanımlar. Bölüm 1, Yazılım Yapımına Hoş Geldiniz (PDF) , genel Yazılım Geliştirme Yaşam Döngüsü'ndeki (Sorun Tanımı, Yazılım Mimarisi, Düzeltici Bakım, vb. Dahil ) birçok konuyu listeleyerek başlar ve ardından,

Şekilde görüldüğü gibi, inşaat çoğunlukla kodlama ve hata ayıklamadır, ancak ayrıntılı tasarım, inşaat planlaması, birim testi, entegrasyon, entegrasyon testi ve diğer faaliyetleri de içerir. Bu, yazılım geliştirmenin tüm yönleri hakkında bir kitap olsaydı, geliştirme sürecindeki tüm faaliyetlerin güzel dengeli tartışmalarını içerecektir. Ancak bu inşaat tekniklerinin bir el kitabı olduğu için, inşaat üzerine ters bir vurgu yapar ve sadece ilgili konulara değinir. Eğer bu kitap bir köpek olsaydı, inşaatı bitirir, tasarım ve testte kuyruğunu sallar ve diğer geliştirme faaliyetlerinde havlardı.


0

Yazılım geliştirme mühendisliktir.

Yazılım mühendisliğinin neden mühendis standardını karşılamadığına dair başkaları tarafından yapılan birkaç tartışma:

Bazıları mühendislerin kamu yararı için "şeyler" tasarlama işinde olduklarını söylüyor - ICBM'ler, Tanklar, vb. Kamu yararı mı? Bazıları evet diyebilir (iyi bir saldırı iyi bir savunmadır), diğerleri hayır diyebilir. Ancak, kimsenin yeni nesil tank hedefleme sistemini tasarlayan adamın bir mühendis olduğunu kabul edeceğini sanmıyorum. Kamu malı öznel olabilir. Her halükarda yazılım bol kamu yararına vardır, bu yüzden nokta her iki şekilde tartışmalıdır.

Diğerleri mühendislerin inşa etmediklerini tasarladığını söylüyor. Çeşitli "makine mühendisleri kaynak yapmıyor" tipinde yorumlar gördüm. Makine mühendislerinin, başka bir şeyin uyguladığı detaylı tasarımlar - planlar ürettiklerini iddia ediyorum . Eğer bir makine mühendisi bir plan üretir ve bunu bir CNC makinesine beslerse, bu onları artık makine mühendisi yapmaz - çünkü bir kişi yerine bir makine gerçekleştirdi mi? Kaynak kodun, uygulamayı yapan bir makineye beslenen ayrıntılı bir plan olduğunu ve bunun bir CNC makinesine bir MechE besleme kodundan nasıl farklı olduğunu göremediğimi iddia ederim. Ve şimdi 3 boyutlu yazıcılarımız var, bu makine mühendislerinin sonunu gösteriyor mu? Şimdi mekanik geliştiriciler mi?

Lisans göründüğüm diğer konu. Şu anda sadece birkaç ülkede lisans yazılım mühendisleri. Yazılım mühendislerinin (şimdiye kadar) ABD çapında lisansı yoktur (Bence sadece Texas bunu yapıyor). Bazıları bunu yazılım mühendisliğinin mühendislik olarak adlandırılmaması gerektiğini belirtmek için kullanmıştır. Yazılım mühendisleri için PE geliyor. Ancak daha felsefi bir düzeyde, bazı eyalet yasa koyucularının yazılım geliştirme mühendisliğini çağırmayı tercih etmeleri (veya etmemeleri) gerçeği etkilemez.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.