Yazılım endüstrisinin düzenlenmesi [kapalı]


85

Birkaç yılda bir kişi yazılım endüstrisi için daha sıkı bir düzenleme önermektedir.

Bu IEEE makalesi son zamanlarda konuya dikkat çekiyor.

Kamuyu fiziksel veya finansal riske maruz bırakan sistemler için programlar yazan yazılım mühendisleri, yetkinliklerine göre test edileceğini bilseydi, düşünme devam eder, koddaki kusurları ve hataları azaltır - ve belki de pazarlıkta birkaç hayat kurtarırdı.

Bunun değeri ve değeri konusunda şüpheliyim. Aklıma göre, bunu önerenlerin toprağa kavuşturması gibi görünüyor.

Bu benim için şunu kast ediyor:

Sınav, konunun ustalığını değil temel bilgileri test eder.

çünkü büyük başarısızlıklar (örneğin THERAC-25 ) karmaşık görünüyor, “temel bilginin” hiçbir zaman önlenmesi için yeterli olmayacağı ince konular.

Yerel meseleleri görmezden gelme (bazı yargı alanlarında Mühendistenin mevcut korumaları gibi):

Amaçlar asildir - şarlatanlardan / şarlatanlardan 1 kaçının ve bu ayrımı yazılımlarını alanlara daha belirgin hale getirin. Yazılım endüstrisinde daha sıkı bir düzenleme yapmak orijinal amacına ulaşabilir mi?

1 Tıp mesleğinin tam olarak düzenlemesi olarak yapılması amaçlanmıştır.


3
Umarım Thomas Owens buna cevap verir, çünkü mükemmel bir cevabı olduğunu biliyorum.
maple_shaft

3
İnsanların bu konuda ne söyleyeceklerini duymak istediğim kadar, Stack Exchange Soru ve Cevap formatına uygun bir tartışma sorusu gibi geliyor.
PersonalNexus

12
Açıkçası, Hükümetin teknolojiyi
düzenlerken ne kadar delice

3
Bir endüstri her gün değiştiğinde nasıl düzenlenebilir?
Jon Raynor

4
Daha sonraları sık sık hatalara neden olan bu "yeterince iyi" durumların çoğu yönetim / pazarlamanın hataya neden olmadığını söyledi: "GEMİ GEMİSİ GEMİ!"
Aren

Yanıtlar:


105

Yazılım mühendislerinin güvercinlere tıp uzmanları veya muhasebecilerle aynı sınıflandırmada yer alabileceği görüşü, çözmeye çalıştıkları "sorunun" cahil bir görüşüdür. Bu konuda fikrimi vermeden önce, bu yasaları öneren düzenleyici kurumun başkan yardımcısı Bay Thornton'ın bazı argümanlarını yıkalım.

Thornton, “Tıpkı doktorlar, muhasebeciler ve hemşireler gibi profesyonel meslek mensuplarının lisanslı olması gibi yazılım mühendisleri de olmalıdır” diyor. “ Yazılım yazmak için bir müteahhit seçerken halkın bir tür güvenceye güvenebilmesi gerekiyor .”

- Mitch Thornton, IEEE Ruhsat ve Tescil Başkan Yardımcısı

Bu yüzeyde çok makul geliyor. Sonuçta, "başarıyla düzenlenmiş" sayılabilecek diğer endüstriler var. Başarıyla düzenlenmiş olarak, eğer sarı sayfalarda bir doktora bakarsanız, akredite bir üniversitede tam bir eğitim almış olduğundan ve bir çok sınavdan geçip ikametgahı tamamladığından emin olabilirsiniz. İşte bazı "başarıyla düzenlenmiş" endüstriler (profesyonel personel açısından).

  • Avukatlar
  • Doktorlar
  • Muhasebeciler
  • Nükleer mühendisleri
  • Berberler ( şaka yapmıyor )

Ne de olsa, hiç kimsenin bu tümörü pankreasınızdan çıkarmasını veya o nükleer santralin şehir dışındaki santrifüjleri üzerinde çalışmasını istemiyorsunuz. Yazılım mühendisleri için neden benzer kısıtlamalar olmamalıdır?

Sadece programları “halk sağlığını veya güvenliğini, güvenliğini, mülkünü veya ekonomisini tehlikeye atabilecekler” denenebilecekler ”

Bu belirsiz bir ifadedir ve liberal yorum ve uygulamaya açıktır. Apple Inc. veya Facebook'un Amerikan ekonomisinin ayrılmaz bir parçası olduğu tartışmasını yapabilirim - hükümeti kendileri için kod yazması için özel bir lisansa ihtiyacım var, çünkü siteyi yetersizlikle yıkarsam Amerikan’a zarar verebilirim ekonomi? Son işimde yanlışlıkla bir tahıl asansörünü hatalı bir cron işi ile kapattım - muhtemelen yiyecek tedarikini tehlikeye atarım.

Bu teklifin gerçek niyetinden kaçındığımın farkındayım. Bunun arkasındaki fikir, yeni Jetta'nıza Kilitlenme Önleyici Fren Sistemi kodunu yazan kişinin, Kilitlenme Önleyici Fren Sistemi kodunu yazması için yetkin ve uygun şekilde lisanslanmış olmasını sağlamaktır. Jetta'nızda.

İşte sorun şu: bu gün ve çağda yazılım mühendisliği her şeyi kapsar ve muhtemelen her disiplini test edemezsiniz. İş kuralları çok spesifik ve disiplinden disipline çok çeşitli. Bir Jetta'da ABS sistemi için kod yazan varsayım mühendisimiz, bir Elantra'da ABS sistemi için tamamen farklı bir şeyler yazıyor olabilir. Yeniden sertifikalandırılması gerekiyor mu?

Peki ya tüm bu türev disiplinleri için test yaparsanız? Bir an için, bir e-ticaret web sitesinde çalışan her programcının, e-ticaret özellikli bir programcı olarak onaylandığını varsayalım. Yani? Bu aniden, bu programcıların ve şirketlerin gerçekten gerekli onaylamaları yapacakları ve PCI uyumluluğunu sağlayacakları anlamına mı geliyor ? Olsalar bile - aksaklıklar yine olacak.

Sınav, IEEE Ruhsat ve Tescil Komitesi başkan yardımcısı Mitch Thornton'a göre, konuyla ilgili ustalık değil temel bilgileri test edecek.

İşte vuruş! Temel bilgi eksikliği asla bir problem değildir. Kilitlenme önleyici frenlerim çalışmayı durdurmadı çünkü Chuck bir kontrol yapısı ile mücadele ediyordu. Başarısız oldular çünkü ABS'nin arka lambalardaki elektriksel kısa devre nedeniyle kapandığı ve güç uygun şekilde yönlendirilmediği için bir aksaklık vardı. Ya da başka birşey.

Yazdığım insülin pompası yazılımı çalışmıyor çünkü temel becerilerim yok; durdu çünkü Avrupalı ​​takım arkadaşım metrik sistemi kullandığında insülin dağılımını nasıl ölçtüğümde bir hata vardı.

Bu geliştirme aşamasında açıklayabileceğiniz bir şey, ancak bir sertifikasyonla asla test edemezsiniz .

İşte bu "sertifikalandırma" yürürlüğe girerse ne olacak: olayların sayısı tamamen aynı kalacak. Neden? Çünkü bir ABS veya insülin pompasının arızalanmasının asıl sorununu ortadan kaldırmak için hiçbir şey yapmaz .


33
+1 mükemmel cevap. Özellikle de: "Temel bilgi eksikliği sorun değil."
Jonathan Henson

4
Harika cevap, ancak yazılım mühendisliğini yalnızca programcıların bakış açısından ele alıyor. Gerçek yazılım mühendisliği, gerçekte birden fazla beceri ve disiplin, iş analisti, kalite güvencesi, proje yönetimi, vb. İçeren bir takım çabasıdır. ve yanlış test. OP testi bunlardan bahsetti mi? Tabii ki değil çünkü programcılar için.
maple_shaft

3
Tüm IEEE fikrinin baştan aşağıya çöp olduğunu düşündüğümü de eklerdim. Hükümetin yapması gereken tek şey sorunu çözmek için işi. Herkese verdikleri zararlardan herkesi sorumlu tutun. Bu tek başına sorunla ilgilenecek
Jonathan Henson

16
"Temel bilgi eksikliği hiçbir zaman sorun değildir" ile aynı fikirde değilim. Aslında çoğu zaman olduğu sorunu. Yeni programcılar (veya daha eskileri) girdi temizliğini ne kadar sıklıkla ihmal eder? Köşe davası doğrulaması? Fiziksel sistemler için bir sensör okuyabilirim. Açık veya kapalı olabilir. Peki ya kırık? Yazılımım nasıl söyleyebilir? O zaman bu konuda ne yaparım? Açık mı yoksa kapalı mı? Bu tür "temel" şeyler gerçekten sık sık sorun yaratır.
sdg

3
@JonathanHenson O zaman yine, SQL enjeksiyonunun çoğu örneğini tam olarak öyle - temel bilgiden yoksun ... ama genel olarak iyi bir yazı olarak görüyorum. +1.
Jeff Ferland

72

Tıbbi düzenleme sayesinde kimsenin ölmediği için şanslı olduğu, finansal düzenleme sayesinde kimsenin sahtekarlıktan zarar görmediği, konut düzenlemesi sayesinde kimsenin evi kapatılmadığı, berber düzenlemesi sayesinde kimsenin saçını kestirmediği, uçakların çökmediği uçak düzenlemesi sayesinde.

Açıkçası, düzenlemenin varlığı, eksiklik veya başarısızlık olmadığı anlamına gelmez. Tersine, kusurların veya hataların varlığı, düzenlemelerin bu kusurları veya başarısızlıkları önleyeceği anlamına gelmez. Yazılım mühendisleri zaten güvenlik açısından kritik öneme sahip endüstrilerin üyeleri olarak düzenlenmiştir ve bu endüstrilerin dışında çok az ihtiyaç vardır.


10
+1 "Yazılım mühendisleri zaten güvenlik açısından kritik öneme sahip endüstrilerin üyeleri olarak çoktan kontrol altına alınmışlar ve bu sektörlerin dışında çok az ihtiyaç var"
Trevor Boyd Smith

3
Bu cevabın alay tonunu sevmiyorum. Düzenlemeye hiç gerek olmadığını söylüyorsunuz, çünkü düzenleme hiçbir sorunu çözmez mi?
Fred Foo

8
Belli bir noktadan öte, daha fazla düzenleme nadiren daha fazla problem çözer diyorum . İnsanları öldürebilecek makinelerde bazı yazılım test uygulamalarını zorunlu kılmak mantıklıdır. Bir diploma programının sonuna bir temel beceri sertifikasyon sınavını atmak sadece bürokrasi ekler.
Karl Bielefeldt

2
@ ustalar, hükümetin bir füze ya da yüksek standartlara uyulması gerektiğine inandığı bir şeyle uğraşıyorsa Karl'a katılıyorum, seçtikleri standarda göre kendi programcılarını ve mühendislerini işe almalarına izin verin. Özel sektör zaten kamu riskinden para kazanmamalı - bu faşizmdir. Özel bir sektörün, halkı baştan tehlikeye sokmasına izin verilmemelidir. En çok neye ihtiyaçları olduğunu bilenler risk almakta olanlardır. Kendi işlerini halletmelerine izin ver. Ve evet, Lockheed-Martin ve benzerlerinin bunu yaptığını biliyorum. Olmasına izin verilmemeliydi.
Jonathan Henson,

3
Geçen yıl ya da öylesine bir süredir kredi kartı detaylarını kaybeden büyük şirketlerin sayısını göz önünde bulundurarak, tatmin edici bir öz düzenleme olmadığını söyleyebilirim. Bu sistemlerin hayati öneme sahip olmadığını iddia edebilirsiniz - ancak insanların cepleri üzerindeki etkisi bu olayları takip etmek kadar zor olabilir.
HorusKol

32

Tarih, göstermiştir ki, mükemmel bir zanaatkar ile vasat olan arasındaki fark, herhangi bir nesnel ölçü ile test edilemeyeceğine inanıyorum. Temel bilgi, temel bir bilginin nasıl uygulanacağı konusunda gerçekten nesnel bir şekilde öğretilemeyen veya ölçülemeyen büyük bir programcı, bilgelik ve deneyim yapmaz.

Ayrıca, bu testler genellikle birkaç vızıltı kelimesi ve somut prosedürler olarak ortaya çıkmakta ve başlayacak önemli bir şeyi ölçmekte başarısız olmaktadır.

Yazılım endüstrisi bir lonca geliştirmek isterse, bu konuya yaklaşmanın daha iyi bir yolu olabilir. Bununla birlikte, merkezileşme yalnızca mükemmelliği yok etme gücüne sahiptir: onu yaratma.

Ek olarak, bu önlemin önlemeye çalıştığı sorunlar muhtemelen herhangi bir şekilde bir test tarafından yakalanmayacaktır. Her neyse, @ThomasOwens'ın buna cevap vermesini görmek isterim.

En azından Amerikan ideolojisinden hükümetin rolü ne olurdu, kusurlu veya güvensiz yazılımlarının yol açtığı mal hasarlarından yazılım şirketlerini sorumlu tutmak. Bu, şirketleri kendi standartlarını uygulamalarını ve bu konuda kişisel sorumluluk almaya teşvik eder. Bu her zaman daha iyi bir çözümdür ve sınırlarını aşan merkezi bir hükümet içermemektedir.

Güncelleme

Dün gece bir bira içerek ondan biraz daha fazla düşündüm.

Tıp alanını düzenleyen tek şey, bir para hariç tüm paradigmaları yok etmekti. Amaçları nazikçe "şarlatan" olarak anılan homeopatik ve naturopatik doktorları ayıklamaksa, o zaman böyle bir düzenleme başarılı olmuştur. Ancak, böyle bir şeyin yasayı yazanlar dışında herkes için karlı olduğunu kabul etmiyorum. Bunun ne yaptığını bir düşün. Sağlık hizmetlerinin maliyetini sürdürülemez seviyelere yükseltti, MD'lerin sorumluluk seviyelerini büyük ölçüde artırdı ve tüketicinin seçim ve piyasadaki kendi belirleme yetkisinin tümünü kaldırdı. Tıp camiasında fikirler için daha fazla pazar yok ve tıp hakkında yeni tedaviler ve düşünce yolları baskılanıyor. Dahası, alana girme engeli inanılmaz derecede yüksektir ve sonuç olarak iyi bir MD sıkıntısı çekiyoruz. s. Ek olarak, düzenleyici kurumlar doktorların arzını kontrol etme yetkisine sahiptir, böylece doktorlara ödenen fiyatı da kontrol edebilirler.

Gerçekten de, tıbbi düzenlemelerden elde ettiğimiz bazı kazanımlar var, ancak maliyetler tamamen yüksek.

Aynı şey, böyle bir düzenlemenin kabul edilmesi halinde yazılım mühendislerine de olacaktır. Şimdi görebiliyorum, düzenleyici kurumlar nesne yönelimli programlamanın tek tasarım standardı olduğuna karar verecek ve işlevsel ve prosedürel programcıların uygulama yapmasına izin verilmeyecek. Sonra bize kendi hafızamızı yönetmemize izin verilmediğini söylemeye başlayacaklar çünkü güvenli değil. Sonra tüm boğazlarımızı JAVA ve C # 'ya sıkıştırıp Oracle ve Microsoft daha hızlı ve mutlu olurken kullanmamız gerektiğini söyleyecekler. Yenilik boğulacak ve yaratıcılık yasaklanacak. Microsoft ve Google mevzuatı yazacak, bu nedenle pazarın kuralları kendi karlılığına ve sosyal refahına karşı bükülecek.

Ayrıca, herkese bilgisayarların hobi ve akademik bir çaba olarak başladığını hatırlatmama izin verin. 80'li ve 90'lı yılların Unix savaşları dışında ücretsiz işletim sistemlerimiz, ücretsiz derleyicilerimiz, ücretsiz programlarımız vb. Vardı ... Bu hızla sona erecekti. Richard Stallman, Linus Torvalds ve Dennis Richtie'nin bize soracağı dünya yavaş yavaş varoluştan kaybolacak.

Özetle, "Size saat başı 25 dolar karşılığında bir wordpress CMS sitesi tasarlayacağım" veya "500 dolar için herhangi bir iPhone uygulaması" ile yarışmaktan yoruldum mu? Pek sayılmaz, neden? Çünkü yaptığım işte çok iyiyim ve istediğim müşteriler mükemmellik için para ödeyecekler. Bir projeyi bağımsız olarak veya iş yerimde tuttuğumda, kendi başıma ve itibarımdan dolayı f * & ^ risklerimi üstlenirim. Bu nereye gidersem gideyim beni takip edecek. Ayrıca, çoğu insan ödedikleri parayı aldıklarını bilir. Bana sadece çim adamlarını ödedikleri bedelini ödemeye razı olan bir müşteri, zaten uğraşmak için bir kabus olacak. Hükümet, hizmet sağlayıcılarını zararlarını telafi etmeye zorlamak için yasal yapıyı düzeltmiş olsaydı, bu alanda halen istihdam edilen çok az sayıda kötü programcı olurdu.

Bu arada, hala kötü doktorlarımız var, tek fark, onları piyasadan çıkarmak için çok az güç olduğudur. Kendi eylemlerinin sorumluluğunu üstlenmeleri gerekiyorsa, müşterileri üzerinde yetersiz bir hasara yol açma şansı olmadan, işsiz kalırlardı.


8
Genel olarak ifadenizin itirazına katılıyor olsam da, bunun en ilginç kısmını ilk cümle olarak görüyorum. Yazılım geliştirmeyi bir problem olarak nitelersiniz , ki bu tam olarak problemdir . Bir değil zanaat bir asma köprüyü; bir mühendis bir asma köprü, etkinliğini ve güvenliğini sağlamak için. Yazılım mühendisleri, onlara hangi unvan verdiğiniz önemli değil, mühendislerden ziyade zanaatkarlar gibi davranıyor.
Eric Lippert

4
@ Jonathan Henson: Genelde kesinlikle yapmazlar. Joel Testinde birçok dükkan sıfır puan alıyor. ( Joelonsoftware.com/articles/fog0000000043.html onlar hususunda ise) olmamalı , bu bir iş kararı değil ahlaki bir karar. Bütün bunlar paraya mal olur: çok ve çok para. Bir uçak kontrol sistemi kuruyorsanız, bu masrafları üstlenmeniz uzun vadede karlı olur; Bir facebook oyunu inşa ediyorsanız, belki de değil.
Eric Lippert

1
Hayır, bir mimar damgası bir PE damgası kadar iyidir. Kesinlikle şu anda mühendislik disiplini denilen birçok şeyi bir mimarın yaptığı gibi bir araya getirmemiz gerektiğini söyleyebilirim. Mimari hala bir zanaat olarak düşünülüyor. Her neyse, mühendislik de muhtemelen bir zanaattır, bu yüzden kelimeleri hiçbir şeyden mahrum bırakabilirim.
Jonathan Henson,

1
@Andy, sanırım bu sitenin başlığını softwareengineers.stackexchange.com olarak değiştirmesini istemek için döviz borsasını sormalıyız :)
Jonathan Henson 20

1
@JonathanHenson Offend? Olmaz, endişelenme! :) Linki açıkladığımdan biraz daha açık bir şekilde anlatmalıydım, çünkü yorumunuza tuhaf bir tesadüf oldu.
yannis

23

Silikon Vadisi Haberleri - 31 Haziran 2015

Korku: Sertifikalı olmayan programcı programı iptal etti

"Bir daha asla kaçamayacağım", kurbanı çıkarıyor. Polis araştırıyor.

Suçlu: Dr. H. Acker Jr.'ın lisansı işaretçiyi yanlış kullanmaktan vazgeçti ve sistem dosyasından okumaya çalıştı

Avukat, Yüksek Mahkemeye temyiz edeceğini söyledi.

Duyurular: 1975 yılında sertifikalandırılan Cobol programcılarının en geç 2025’te yeniden sertifikalandırılması gerekir

IEEE sertifikasyonun o zamandan beri değişmediğini onayladı.

Reklamlar: Magic Knowledge Stuffers, Inc ile Sertifika Garantili

21 günde programlama yapmayı öğret.


Bunun tam bir cevap mı yoksa komik bir yorum mu olduğuna karar vermeye çalışıyorum. (Her ikisi de belki?)
Lyndon White

@Oxinabox 31 Haziran tarihi esprili
gnat

İnternethaber.com "10 gün içinde kendinizi programlayın!" hehe
BЈовић

20

Herhangi bir mesleğe düzenleme uygulamak için birkaç farklı yol vardır - iyi tanımlanmış bir bilgi birikimi, bir etik kuralları, eğitim programlarının akreditasyonu, belgelendirme ve lisanslama ve mesleki gelişimin yanı sıra mesleki gelişmeyi destekleyen meslek toplulukları. meslek. Yazılım mühendisliği, bir mesleğin özelliklerinin çoğuna sahiptir.

Yazılım Mühendisliği Bilgi Grubu (SWEBOK) ve Yazılım Mühendisliği Etik ve Mesleki Uygulama Kuralları ile başlamayı düşünmeyi seviyorum . Bunların genel kabul görmesi hâlâ oldukça sınırlı olsa da, kendilerini yazılım mühendisi olarak tanımlayan birisinin bilgi sahibi olması gereken şeyleri ve bu tür bir kişinin profesyonel bir kapasitede nasıl hareket etmesi gerektiğini belirlemek için iyi bir temel teşkil ettiğini düşünüyorum. Bu, bunların zor kurallar olduğu anlamına gelmez, ancak bu belgeler, profesyonel yazılım mühendislerine, yapmaları istenebilecek işle ilgili olanlarla ilgili olarak kılavuzluk eder. SWEBOK zaman zaman ilgili kalmasını sağlamak için revize edilmiştir.

Bir sonraki karakteristik eğitim programlarının akreditasyonu. ABD'de yazılım mühendisliği programlarının akreditasyonu ABET tarafından gerçekleştirilmektedir . Ayrıca bilgisayar bilimi, bilgi teknolojisi, bilgisayar mühendisliği ve diğer bilgisayarla ilgili meslekleri akredite ederler. ABET akredite edilmiş programların gerekliliklerini web sitelerinde yayınlar - yazılım mühendisliği Mühendislik Programı olarak kabul edilir. Akreditasyonun amacı, farklı mühendislik programlarının mezunları arasında, en azından sınıfta öğretilen konu bakımından tutarlılık sağlamaktır. Eğitimin kalitesi hakkında hiçbir şey söylemez.

Mezun olduktan sonra, sınıfta öğrenilen bilgileri (ve bazı durumlarda işte) standart bilgi birikimlerine göre değerlendirmek için sertifikalandırma ve lisanslama kullanılır. Akredite okullar, öğretilecek tanımlanmış bir materyal kütlesine sahip olsalar da, bu materyalin ne kadar iyi öğretildiğine ve programın bitiminde öğrencilerin ne kadar öğrendiğine dair bir ölçüt yoktur. Sertifikalandırma ve lisanslama bunu yapmak için yöntemler sağlar - herkes aynı sınavları alır ve mesleğin temel aldığı çeşitli bilgi birikimlerinde bilgi gösterir. Yazılım mühendisliğinde, IEEE, SWEBOK'ta ( Sertifikalı Yazılım Geliştirme) köklü sertifikalar sunar. Ön yaşlılar ve yeni mezunlar ve için Sertifikalı Yazılım Geliştirme Uzmanıendüstri tecrübesi olanlar için. Bunların değer katması için, SWEBOK'un yazılım mühendisliğinin iyi bir tanımı olduğunu kabul etmesi gerekir.

Son olarak, profesyonel toplumlar mesleğe rehberlik eder, bilgi ve fikir alışverişi için konferanslar ve yayınları kolaylaştırır, akademi ile sanayi arasındaki boşlukları kapatır, vb. Önde gelen iki toplum, IEEE Bilgisayar Topluluğu ve ACM'dir , ancak dünyada başka toplumlar da var. Bunlar, her şeyi güzel bir küçük paket içine sarar ve doğru insanlara bilgi iletilmesine yardımcı olur.

Buradan sorulacak başka sorular var. Yazılımın gelişimi bir mühendislik disiplini midir? Sertifikalandırma veya lisanslama, yazılım mühendislerine herhangi bir değer katıyor mu? Sertifika faydalı mı?

Tüm yazılım geliştirmenin bir mühendislik disiplininin titizliğine ihtiyacı olduğunu sanmıyorum. Bu, bina yazılımı bilimi ve mühendisliği üzerine yapılan deneysel ve bilimsel bir çalışmanın herkese yardımcı olmadığını söylemek değildir. Ancak, en yeni video oyununu geliştirmek, bir kalp pili için gömülü yazılımı geliştirmek veya bir sonraki uzay gemisini oluşturmak arasında büyük fark var. Vurgu hepsinde farklı - üçünden ikisi yetenekli bir mühendisin dikkatini hak ediyor. Diğer mühendislik uygulamalarından öğrenebilir, ancak projeyi başarıyla tamamlamak için bunlara güvenmek zorunda kalmaz.

Sertifika ve lisanslama kabul edilmiş bir bilgi birikimi gerektirir. SWEBOK sağlam bir temel sağlayan iyi bir belgedir ancak yaygın olarak kabul edilmemektedir. Akademik programlarınızı ve sertifikasyon / lisanslama sınavlarınızı uygulayıcılar tarafından kabul edilecek somut bir şeye dayandıramazsanız, gerçekten bir anlamı yoktur. SWEBOK veya alternatif bir belge yaygın olarak kabul edilirse (en azından mühendislik titizliği gerektiren alanlarda), o zaman gerekli bilginin anlaşılmasını ölçmek için belgelendirme veya lisans sınavları kullanılabilir.

Ancak, sertifikasyon ile ilgili göze çarpan bir sorun var - bu bir kitap üzerinde yapılan bir test. Bazı insanlar okuma, öğrenme, ezberleme ve sınavda iyidir. Ancak, bu onların iyi bir mühendis oldukları anlamına gelmez. İnsanlar her zaman çatlaklardan kayıyorlar. Sertifika veya lisans yalnızca tek bir adımdır. Mesleki eğitim ve diğer deneyimli mühendisler tarafından mentorluk yapmak iyi bir pratisyeni yetiştirmek için zorunludur. Ek olarak, insanların kritik ortamlarda pratik yapmalarını önleme yeteneği, topluma ve işletmelere yönelik riskleri azaltmaya yardımcı olabilir.

Bu konunun derinlemesine tartışıldığı güzel bir kitap Steve McConnell'in Profesyonel Yazılım Geliştirme: Daha Kısa Programlar, Daha Kaliteli Ürünler, Daha Başarılı Projeler ve Gelişmiş Kariyer .


Biraz havanın altındayım, bu yüzden eğer bir şeyi kaçırırsam ya da bir şeyin bir anlamı olmazsa beni dürtün ve düzeltirim. Teşekkürler beyler.
Thomas Owens

"üçünden ikisi yetenekli bir mühendisin dikkatini hakediyor" haklısın, uzay aracı yapmak o kadar da zor değil
zzzzBov

+1 konuyla ilgili girişinizi eklediğiniz için teşekkür ederiz. Umarım daha iyi hissedersin.
Jonathan Henson

12

Devlet düzenlemeleri kabul edilirse, ABD'deki yazılım endüstrisi önemli ölçüde sözleşme yapacak, çünkü bu yönetmeliklere uymanın getirdiği maliyet başlangıçlardan daha yüksek olacak ve küçük işletmelerin karşılayabileceği miktarlarda olacaktır.

Bir Hukuk derecesi veya Tıp Doktoru ile ilgili kıtlık ve maliyet, endüstrimizde az ya da çok görünür hale gelecektir. Alternatif olarak, her joe'nun bir sonraki Facebook'u oluşturabileceği iyi değil.

İnsanlar hata yapar ve hiçbir düzenleme felaketlerin gerçekleşmesini önleyemez. İnsan tarafından bilinen yazılım geliştirme için şimdiye kadar en katı gereksinimlere sahip olan NASA'yı düşünün. Hala yazılım hataları var mı? (Evet, evet ve birçok kez, evet!)

Pazar bu sorunları düzenlemelerden çok daha iyi sıralar. Sorun yaratan yazılım üreten şirketler, yaraladıkları kişiler tarafından sorumlu tutulmaktadır. Geri kalanımız onların hatalarını ödemek zorunda değil.


8
Bu cevaba fantastik bir katkı, bu düzenlemeler yürürlükte olsaydı, muhtemelen başlatılmamış olan mevcut yazılım şirketlerinin bir listesi olurdu. Microsoft ve Facebook iyi bir başlangıçtır, çünkü bir sertifikasyon muhtemelen bir derece gerektirecektir (test ile başlayan hemen hemen her meslek bir tane ile başlamazsa bir derece gereksinimi ekler).
psr

1
@maple_shaft, IMO ile doktorları / avukatları yazılım mühendisliği ile karşılaştırmak geçerli değildir. Alanlar karşılaştırmak için çok farklı (neden yazılım mühendisliğini doktorlarla / avukatlarla karşılaştıramayacağınızı görmek için Jarrod Nettles'ın cevabına bakınız).
Trevor Boyd Smith

1
@maple_shaft - Sertifikanın mühendislik kalitesini artıracağını ima ediyorsunuz. Sonuç olacağı konusunda şüpheliyim. Bence çoğu sınava çalışmak için harcanan zaman, daha iyi mühendislik öğrenmek için harcanan zaman değil.
psr

4
Herkesin, doktorların ve avukatların lisanslanmasının doktorların ve avukatların kalitesini artırdığı konusunda kanıtlanmamış bir varsayım yaptığına inanıyorum. Bu varsayımdan çok şüpheliyim. Ruhsat almanın tek yolu doktorların ve avukatların çok fazla ücret talep etmeleri ve bu konuda kimsenin yapabileceği bir şey yok. Bu bakımdan, yazılım mühendislerine lisans vermek için geldim. Bir iota yazılımın kalitesini iyileştirmeyecek, ancak çoğumuzun yazılım geliştiricilerini zenginleştireceği kesin. Haha, hükümet liseli çocuğu lisanssız bir yazılım uygulamasından tutukladığı zaman.
Dunk

1
Tamamen arızanın mahiyetine bağlı olan @maple_shaft - Facebook cevap vermemesi kritik değildir (yatırımcıların ceplerini etkilemenin ötesinde) - Facebook, kişisel bilgilerinizin ve özel mesajların her bir internet kullanıcısı için kullanılabilmesi farklı bir konudur. Ayrıca - kredi kartı ayrıntılarını (Facebook'taki gibi) alan uygulamalar / oyunlar, yanlışlıkla kredi kartı ayrıntılarını serbest bırakmak ciddi sonuçlara neden olur.
HorusKol

11

ACM, 1999'da, IEEE SWEBOK çalışmalarından büyük ölçüde çıkarıldığında lisanslamaya ilişkin bir açıklama yaptı . Kamuya açık SWEBOK belgelerini ve ACM bildirimini inceledikten sonra, ACM'nin görüşünü destekliyorum.

Makaleye baktığımızda, sınava girebilmek için 4-6 yıllık deneyime sahip bir kişi gereklidir; Bu gülünçün ötesinde ve kapıya gülmek gerekir.


10

Bir cihazın yazılım bileşenleri bir uygulama detayıdır. Mesela, kontrol sistemleri endüstrisinde, tüm emniyet cihazları eskiden kablolanmış ve insanlar yazılıma güvenmiyorlardı. Ancak, şimdi Güvenlik Röleleri ve Güvenlik PLC'leri gibi yazılım tabanlı güvenlik cihazları görüyoruz. Bunlara izin verilir, çünkü güvenlik cihazları için endüstri düzenlemelerine hala uymaları gerekir (güvenlik kategorisine bağlı olarak). Bu nedenle, bazı durumlarda cihazların fazladan işlemciye ve iki farklı ekip tarafından yazılan fazladan kodlara ihtiyacı vardır.

Halk tarafından satılması ve tüketilmesi durumunda güvenlik kurallarına uyması gereken üründür. Ürün yazılım içerdiğinden bu kurallar değişmez. Ürünün tüm düzenleyici kriterleri karşıladığından ve yazılım içeriyorsa, yazılımı incelemesi ve bu alanda yetkin olması gerektiğinden emin olmak Mühendisin görevidir . Olmazlarsa, tasarıyı onayladılarsa ve hatalı oldukları ortaya çıkarsa, onlar (veya şirketleri) sorumludur.

Bazı programların daha katı gereksinimler karşılaması gerektiğinden tüm programcıları düzenlemenize gerek yok. Bu tür ürünlerin yazılımı içerdiği durumlarda, yazılım bileşeninin gereklilikleri karşıladığını güvenilir bir şekilde belirleyebilecek iyi geliştirilmiş bir mühendislik disiplinine ihtiyacınız vardır. Eğer bir şey varsa, IEEE'nin anlamı budur: Yazılım Mühendisliğinin nispeten genç olan alanının, diğer mühendislik disiplinlerinin güvenilirlik ve güven düzeyi için geliştirilmesi gerekir.

Gerçekten "programlama" ve "mühendislik" ile ilgili hiçbir ilgisi yok.

Bu, elbette, bizi geliştirici ve mühendis arasındaki farkın çekişmeli sorununa geri getiriyor. Bunlar genellikle düzenli olarak örtüşen iki farklı roldür. Geliştirici kısmı, yazılım yaptığınız anlamına gelir. Rolün mühendislik kısmı, kamu güvenliği için sorumluluk aldığınız tasarımı damgalarsanız anlamına gelir. Sen edebilirsiniz diğeri olmadan biri.


5
+1 IMHO, asıl merak ettiğiniz şey, düzenlemenin üründe değil, mühendis üzerinde olması gerektiğidir. Örneğin, Yangın ve Saldırı Alarmı sistemleri için gereken düzenlemeler (onaylar), yazılımı yazanların değil, yazılımın çalışmasını sağlar. (Düzenlemelerin Birçok sistem elektronik devreler tamamen yapılmış olduğu haliyle tamamen aynı görünüyor.)
jwernerny

8

Yazılım zaten uçak endüstrisinde sıkı bir şekilde düzenlenmiştir. DO-178B'ye bakınız .

Sektörün diğer alt kümelerinin de kendi normları olduğuna eminim.

"Yazılım" bugünlerde çok şey kapsıyor. Her şeyi kapsayan bir düzenlemeye sahip olmanın saçma olacağını düşünüyorum.


4

Yazılım endüstrisinin düzenlenmesi en iyi Kalite Güvence süreçlerinin düzenlenmesi ile yapılır.

Bu zaten yapıldı - büyük yazılım şirketleri çok sayıda test cihazına, KG yöneticisine, otomatik test grubuna, kod inceleme işlemlerine, test işlemlerine, vb. Sahiptir. Amacı diğer şirketler üzerinde yazılım kalite denetimi yapan şirketler de var. Standart kuruluşlar KG ve KG Denetimleri için yönergelere sahiptir.

Bir şirket içinde, bir yazılım mühendisi işlerinin kalitesinden sorumludur. Ancak çekleri ve bakiyeleri şirketin kalite süreçlerindedir.


2
Bu tam olarak benim görüşüm. Havacılık endüstrisi kalite kontrol ve test programlaması için katı kurallara sahiptir. Şirketlerin bilgi varlıklarını denetlemesi ve daha fazla test ve inceleme yapması gerekir. Bunların yazılımın karanlık günleri olduğunu düşünüyorum, çünkü çoğu hala yapılacak doğru şey olduğunu bildiklerini yapmadan köşeleri kesiyor ve geliştiricilerin kendileri sektörü değiştirmeye yetmiyor.
Tjaart

Müthiş nokta - cihazı çalıştıran yazılım, endüstri mühendisliğinde olduğu kadar iyi ve güvenli mühendislik için de şirketin sorumluluğundadır.
Jarrod Nettles,

3

Bu, "yazılımla ilgili sorunları" çözme konusundaki en modern girişimlerle aynıdır. Yasamaya çalışanlar, sorunun kök rotası hakkında çok az bilgiye sahipler. Güvenlik kritik yazılımı geliştirirken öngörülen süreci (ve tabii ki amacını) takip ediyorsanız, uçaklarda, tıbbi cihazların nükleer santralleri için tek bir hatanın asla bir arızaya neden olması yeterli olmayacaktır. Tüm algoritmalar, herhangi biri zarar görmeden yanlış şekilde uygulanabilir.

Hem FDA hem de FTA, risk analizi gerektirir ve buna dayalı bir azaltma stratejisine dayanır. Daha sonraları genellikle herhangi bir hafifletmenin hatalı olduğunu kabul ettiği bir İsviçre peyniri stratejisidir, bu nedenle aynı risk için çoklu hafifletmeler uygulanır (bir hafifletici aynı zamanda birkaç riske de uygulanabilir), her hafifletici madde bakabileceğiniz bir dilim peynir gibidir bir, belki iki dilim bir araya getirilir, ancak yeterince dilim bir araya getirilir ve bu artık mümkün değildir. Azaltmalar mükemmel bir şekilde uygulandığında bile, bu% 100 güvenli bir ekipmana neden olmaz. Eğer risk analizi yanlış ise, hiç kimsenin düşünmediği riskler olacaktır (Y2K).

Mühendisleri, konuyla ilgili bile test edebileceğiniz ve son derece yüksek bir seviyeye ihtiyaç duyacağınız her şeyi test edebilirsiniz, ancak bu çok önemli. Güvenlikle ilgili kritik hataların çoğu entegrasyon hatalarıdır. Bunlar bir mans kodunda hata değildir, ancak iki yazılım sisteminin yazılımı ve donanımı arasındaki yanlış hizalamalar nedeniyle veya bir alfa parçacığı, program sayacını uygun konumundan çıkardığı için ortaya çıkar.

Alanında mantıklı bir testten geçebilecek, son derece deneyimli ve yetenekli geliştiricilere sahip birçok güvenlik kritik sistemindeyim. Daha önce hiç kritik bir kritik hata yapmadığımız bir projede bulunmadım. (Neyse ki, sistemin hiç kimseye zarar verdiği bir yere hiç gelmedim)


1
+1 - Çünkü: "Güvenlikle ilgili kritik hataların çoğu entegrasyon hatalarıdır." Aslında, yaşadığımız tüm süreçte neredeyse hiçbir zaman bir kodlama hatası olmaz. Zamanın% 99.98'i, farklı modüller ve cihazlar arasında nasıl çalışması gerektiğine dair bir anlayış problemidir.
Dunk

@ Dunk, bu aslında Levison'dan bir qoute oldu. Metne eklemek istediğim bir gerçek ama unutmuş gibiyim :)
Rune FS

2

İnsan, şarlatanları hiçbir zaman ortadan kaldıramaz ve tam anlamıyla ortadan kaldıramaz çünkü uzun süren uygulama ve geleneklere rağmen hemen hemen her meslekte, tıp mesleğinde bile var.

Bu ifade üzerine toprak kapmak olsa da, BT’nin her şeyden ne kadar korkutucu geçeceği, tereddütsüz kontrolünü ve yazılım geliştirme düzenlemesini planladığından emin değilim. Aslında IEEE hakkında konuşuyorsanız, kesinlikle düzenleyici bir yönü vardır, ancak IEEE standartlarına uygunluk iradesiz ya da daha azdır ve silah zoruyla değil. Evrensel endüstri standartlarını geliştirmeye çalışıyorlar, böylece hepimiz aynı dili konuşuyoruz ve genel olarak verimliliği arttırıyoruz.

Ayrıca ortaya koydukları standartlar, ortak uygulamaları meşrulaştırmaya yardımcı olur ve nihayetinde makine mühendisliği ya da kimya mühendisliği yerine, daha disiplinli bir mühendislik alanı haline gelmesi için yazılım geliştirme çalışmaları için zemin hazırlar. Yazılım bu hedefe yaklaşırken, hiçbir zaman evrensel olarak bir mühendislik disiplini olarak kabul edilemez.

Asıl sorun, bir yazılım geliştiricisinin hoş bir masaüstü widget yazmaktan, füze rehberlik sistemlerini uygulamaya kadar her şeyi yapması olabilir. Birinde hatanın ciddiyeti ve sonucu diğerinden çok daha yüksektir ve bu nedenle makul şekilde, güvenli ve verimli bir şekilde yaklaşmak için sıkı bir şekilde düzenlenmiş bir mühendislik disiplini gerektirir. Bu, bir köprünün yanlış tasarlanması ve sonuç olarak çökmesi gibi bir şiddeti gibidir. Köprünün tasarımcıları kaliteyi sağlamak için benim mühendislik standartlarına uyuyor olmalılar.


4
Genellikle bu tür düzenlemeler yasal gereklilikler haline de gelir. Örneğin, bir PE gerektiren inşaat mühendisliği
Paul Nathan

Evrensel olarak kabul disipline doğal bir ilerleme kanunla düzenlenmesi yol açar sonuçta özdüzenleme (. Örneğin MPAA) başlar ve bu yüzden iyi noktaya, (FCC, Devlet panoları, vb ...) @PaulNathan
maple_shaft

7
Yazılım geliştirmenin kendi kendini düzenlemeye hazır olduğuna ya da ona yakın olduğuna inanmıyorum. Açıkçası, "gerçek mühendislerin" "gerçek kaliteye" sahip olduğu fikri benim için bir şaka gibi. Uzay mekikleri patladı, roketler yandı, köprüler düştü, binalar çöktü ... vs. Kaliteyi yukarıdan empoze etmeye çalışmak güzel olurdu, ama haha.
Paul Nathan

1
Makine mühendisliğini yazılım mühendisliği ile karşılaştırmak, gerçek dünya mühendislik analoğunun modern işletim sistemleri gibi bir şey için ne olacağını merak ediyor.
SinirliFormsDesigner ile

1
@maple_shaft - Asıl sorun Linux / BSD / grep / vi / Firefox vb. kullanamamanız olacak çünkü resmi bir SE tarafından yazılmıyor. VB'de MSCE sertifikası olan biri iyi olacak.
Martin Beckett

1

Daha sıkı düzenlemeler demezdim, bunun yerine giriş engelleri. Bu bakımdan hak olduğunu düşünüyorum. Artan kalite için bu çok tartışmalıdır.

Şu anda herhangi bir John / Jane Doe bir program yazabilir. Giriş için hiçbir engel yoktur. Senaryo ve web teknolojisi hakkında birkaç kitap al ve kesmeye başla, ya da daha kötüsü, "nasıl yapılacağı" için Googling'e başla.

Toplu bir bütün olarak, belki de giriş engellerini arttırma, endüstriyi daha yüksek bir standarda tutma, hacker / zanaatkardan mühendisliğe, bu tür bir düzenleme içinde bulunduğumuza karar verme zamanına karar verdik.

Bugün programlamada çok fazla vasıfsız kişi var. Kritik sistemler üzerinde çalışıp çalışmadıklarına rağmen hala kod üretiyorlar, hala Büyük Çamur Topları üretiyorlar .

Bu bakımdan, öz düzenleme veya daha uygun bir şekilde giriş için engeller oluşturmak iyi bir şeydir. Çünkü diyoruz ki, hey, sokaktan gelip kendinize bir Yazılım Mühendisi diyemezsiniz. Aslında bir beceri seviyesini düşürmelisin.

Beceriyi düşürmek, sadece bir sınava girmek veya bir "şeref rozeti" almaktan ibaret değil. Bir test sadece bir onaylamadır. Gerçek doğrulama Okul, staj, çıraklık, yaşlılar altında mentorluk yapmak, pratik yapmak, bunun bir parçası.

IEEE'nin neyi başarmaya çalıştığını görebiliyorum, ancak bu noktada sonuçsuz bir alıştırma. Endüstri hızla değişiyor, ürünün kapıdan, "korsan" zihniyetten, vb. Dışarı itilmesi için çok fazla talep var.


+1 veriyorum, çünkü riff raff'ı belirli sistemlerden uzak tutmanın bir yolu olmalı. Ancak, -1 veriyorum çünkü bugün çoğu yazılım bilgisayar korsanları tarafından yeterince geliştirilebiliyor ve maliyetleri düşürmek için bu hizmeti sağlayabilmelerini engellemek kamu yararına karşı. Aynı şekilde, aynı avukatlar ve doktorlar için de geçerli. Yaptıklarının% 90'ı, daha az niteliklere sahip kişilerce oldukça uygun maliyetli ve aynı şekilde yetkin şekilde ele alınabilir. Ancak, bugünün yasaları ile halkı istedikleri şekilde oymakta özgürdürler.
Dunk

İşe alım sürecinde becerilerin değerlendirilmesi gerekmemelidir. Oh bekleyin, İK, insanlara kâğıt referanslar (yazılım geliştirmede uygulanabilir bilgiyi göstermeyen) esas alarak işe alır ve İK personeli, yazılım geliştirme ihtiyaçları / gereksinimleri hakkında kesinlikle hiçbir şey bilmez. Çift başarısız ...
Evan Plaice

0

Makaleyi okumamıştım, ancak soru, yazılım endüstrisi düzenlemesinin insanlığa fayda sağlayıp sağlayamayacağı ile ilgili ise, bunun şartlara bağlı olduğunu düşünüyorum:

  1. Bir bütün olarak endüstri, bazıları hayati öneme sahip (örneğin tıbbi bir cihazda radyasyon dozajını kontrol etme) ve bazıları olmayan ("Hangi Muppet Siz?" Facebook uygulaması) olmayan çok çeşitli alanları kapsamaktadır. Riskli olan uygulamalar için düzenleme için herhangi bir tartışma göremiyorum.

  2. İnsan yasal düzenlemelerle başlamamalı . Aksine, geliştiriciler için bir sertifikasyon programı ile başlamalıdır. Sadece sertifikasyon programının ölçülebilir bir fayda sağlaması durumunda, yasal bir düzenleme söz konusu olmalıdır.

  3. Bir sertifikasyon programı ölçülebilir sonuçlar üretse bile, endüstrinin kesin olarak ticari nedenlerden dolayı bu sertifikayı isteme konusunda standardize etmesi muhtemeldir ve yasal düzenlemelere ihtiyacımız olmaz. ( MCSE gibi delegasyonların var olmasının nedeni budur - şirketler, MCSE'lerin eğitildiği alanlar için MCSE'leri kiralamayı tercih eder.)

  4. Tüm bunların söylediğine göre, hala zarar vermenin ticari anlam ifade ettiği alanlar var (genellikle bunlar negatif dışsallıklar , bazen de bazı kurumlar için pazar gücünün sonucudur ). Örneğin, bir bölgede tek bir yerel hastane olabilir; Bu durumda, arka uç yazılımın kalitesi, bir hastanın aldığı bakım seviyesi için büyük bir fark yaratabilir, ancak hastanın hangi hastaneyi seçtiği kadar bir fark yaratmaz. Hastane daha sonra daha kaliteli geliştiricilere yatırım yapmak için çok fazla iş vakasına sahip değildir. Bu durumda, geliştiricilerin hastanenin kiralamasına izin verildiğini düzenlemek için bir halk sağlığı vakası olabilir.

BENİM NACİZANE FİKRİME GÖRE.


0

Buna cevap vermek zorundayım ...

@JonathanHenson'ın söylediklerinden ve @gnat'ın girişinden bahsettiğimde sorun yok, parası olan insanlar sertifikalı şeyler için ödeyebilir, parası olmayan insanlar veya ülkeler lisanslar için ödeyemez (sertifikalı şeyler için çok fazla) ), peki eğer bu uygulamaya geçerse, yine de isyanlar olacak. Geleneksel (çok geleneksel olmayan) dağıtım yöntemleri kapalı olsa bile, insanlar ilgilenen kullanıcılara yazılım sunmanın yollarını bulacaktır. Başka bir HTTP protokolü veya hatta alternatif bir bütün ağ yığını geliştirmek anlamına gelse bile, sadece bağlantıları tespit edilemez hale getirmeye odaklandı (bunu yapabilen biri için son paragrafa bakın).

Ayrıca, bir şey için ödeme yapma fikri risk altındadır, çünkü dünya gittikçe fakirleştiğinden dolayı, gittikçe daha fazla insan, işler için ödeme yapmak için daha az paraya sahip olacak, hatta FOSS yazılımını kullanan ülkeler bile var. Sertifika (Brezilya ve Hindistan akla geliyor, ama başkaları da var elbette) ve bu ülkelerin bazıları büyüyor, gerçekten büyüyor. Ve yetenekleri bilinmeyen programcılar tarafından yapılan ve sertifikası bilinmeyen yazılımları kullanıyorlar.

Ayrıca, bir tür belgelendirme olsa bile belgelendirme sadece etik bilgisini değil, ahlakı değil, sadece bazı doktorların insanlardan yetkisiz bir şekilde çıkarılmış organları kullandıklarını düşüneceklerdir. Etik kuralları yoktur ve bilerek ya da istemeden özensiz bir kod yazabilirsiniz. FOSS projelerinin çoğunda, potansiyel olarak en yeteneksiz programcılar aynı zamanda başkalarının kodlarını da gözden geçirir ve hataları bulmaya çalışırlar;

Sonunda, güvenlik hakkında daha fazla şey bilen ve güvenlik yazılımını yalnızca belirli hükümet departmanlarından en uzman programcılarla eşleşecek şekilde geliştiren güvenlik şapkaları (siyah şapka korsan grupları değil, beyaz veya gri şapka grupları) hakkında ne diyorsunuz?

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.