BT endüstrisi neden diğer endüstrilerde olduğu gibi hızlı ve büyük projeler sunamıyor?


509

National Geographic'in MegaStructures serisini izledikten sonra , büyük projelerin ne kadar hızlı tamamlandığına şaşırdım. Ön çalışmalar (tasarım, özellikler vb.) Kağıt üzerinde yapıldıktan sonra , büyük projelerin gerçekleştirilmesi sadece birkaç yıl veya bazen birkaç ay sürer .

Örneğin, Airbus A380 "19 Aralık 2000'de resmen başlatıldı" ve "2005 Mart ayı başlarında" , uçak zaten test edildi. Aynı şey büyük petrol tankerleri, gökdelenler vs. için de geçerli.

Bunu, yazılım endüstrisindeki gecikmelerle karşılaştırarak, çoğu BT projesinin neden bu kadar yavaş ya da daha kesin olduğunu merak ederek, neden yeterince hızlı ve hatasız olamayacaklarını, aynı ölçekte yeterli insanlara verildiğini anlayamıyorum?


Airbus A380 gibi projeler her ikisinde de mevcut:

  • Öngörülemeyen başlıca riskler: Bu ilk yapılan uçak olmasa da, yine de teknolojinin sınırlarını zorluyor ve daha küçük uçaklar için iyi çalışan şeyler, fiziksel kısıtlamalar nedeniyle daha büyük olan için işe yaramayabilir; Aynı şekilde, henüz kullanılmayan yeni teknolojiler kullanılıyor, çünkü Boeing 747'nin yapıldığı 1969'da mevcut değildi.

  • Genel olarak insan kaynakları ve yönetimle ilgili riskler: projenin ortasında bırakan insanlar, tatildeyken birine ulaşamama, normal insan hataları vb.

Bu risklerle insanlar çok kısa sürede bu büyük uçakları gibi projeleri başarmakta ve teslimat gecikmelerine rağmen, bu projeler hala oldukça başarılı ve yüksek kalitededir.

Yazılım geliştirmeye gelince, projeler bir yolcu uçağı kadar büyük ve karmaşık değildir (hem teknik olarak hem de yönetim açısından) ve gerçek dünyadan öngörülemeyen riskleri biraz daha azdır.

Yine de çoğu BT projesi yavaş ve geç kaldı ve projeye daha fazla geliştirici eklemek bir çözüm değil (on geliştirici ekibinden iki bine geçmek bazen projeye daha hızlı, bazen değil, bazen de zarar verecek Projeyi tamamlayıp tamamlamama riskini arttırın).

Halen teslim edilenler genellikle ardışık servis paketleri ve düzenli güncellemeler gerektiren birçok hata içerebilir (böcekleri orijinal ürüne yapıştırmak ve uçağın çarpmasını önlemek için haftada iki kez her Airbus A380'de "güncellemeler kurmayı hayal edin").

Bu farklılıklar nasıl açıklanabilir? Özel olarak, yazılım geliştirme endüstrisinin büyük ölçekli, neredeyse kusursuz ürünleri çok hızlı bir şekilde teslim etmek için binlerce kişiyi tek bir projede yönetebilmek için çok genç olması nedeniyle mi?


127
İlginç soru. Yazılım endüstrisindeki ortalama bir işçinin kalitesinin, her mühendisin sıkı ve yoğun bir derece tamamladığı ve muhtemelen de kendi şartını kazandığı inşaat mühendisliğinden daha az yetenekli ve nitelikli olduğunu söylemeye cazip davranıyorum. Ayrıca, büyük yazılımların (örneğin bir işletim sistemi, MS Office) karmaşıklık alanı muhtemelen bir uçaktan bile daha büyüktür. Kesinlikle daha başarısız yerler! Ve son bir önemli nokta: çoğu yazılım az ya da çok çalışır, kötü yazılmış olsa bile ve çok para sıkarsa ... kesinlikle başarısızlığın maliyeti normalde bir uçaktan çok daha düşüktür!
Noldorin,

155
Aslında bu endüstrilerden herhangi birinde (ancak PR'de değil) çalışan birini bulun ve onlara "kusursuz kusursuz projeler" hakkında sorun. Acı dolu kahkahalar kazanacağınızı garanti edebilirim.
Michael Borgwardt,

151
Bir yazılım projesinin gerçekleştirilmesi saniyeler veya dakikalar alır; IDE'nizde "derle" ye tıkladığınızda ne olur. Diğer taraftan, programlama tasarımdır . A380'in tasarımı ne kadar sürdü?
Karınca

53
Bu TV programı bir yutturmaca. Sadece başarılı projeleri yayınlıyorlar. Herhangi bir kanal izleyicilerin dikkatini çekecek programlar yapar.
pandu

117
Her Airbus A380'e haftada iki kez "güncelleme" yapmayı düşünün ... 'Eğitimsiz pilotlar düğmeleri rastgele iterken, sürekli olarak uçağı savunan düşman robotlarını hayal edin. İddiaya girerim düzenli yamalara ihtiyacın olacak.
Nathan Long,

Yanıtlar:


337

Ed Yourdon'un Ölümü March , bu meta tipi soruların bir kısmına değiniyor.

Genel olarak, yazılım endüstrisi büyük projelerle karşılaşan pek çok şeye sahip değil.

  • Standardizasyon ve iş öğesi dökümü.

    • Bu kesinlikle daha iyi bir hale geldi, ancak tasarım yapıları hala büyük bir sistemi parçalamak için orada değil. Bazı açılardan, yazılım belirli bir proje için neyin gerekli olduğu konusunda hemfikir olamaz, bu sayede işleri parçalara ayırabilir .
    • Havacılık, bina inşaatı, otomobil vb. Hepsi tamamen paralel gelişime izin vermek için oldukça sıkı arayüzlere sahip çok bileşen odaklı mimarilere sahiptir. Yazılım hala ilgili alanlarda çok fazla kanamaya izin veriyor.
  • Başarılı, benzer projelerden oluşan geniş bir yapı. A380 , Airbus'un inşa ettiği ilk büyük uçak değildi . Dışarıda pek çok büyük yazılım uygulaması var, ancak birçoğu veya başka yönleriyle çarpıcı biçimde acı çektiler ve “başarılı” olarak adlandırılmaya yaklaşamadılar.

  • Çok sayıda benzer ve başarılı projede çalışan geniş bir tasarımcı ve inşaatçı grubu. Başarılı proje sorunuyla ilgili olarak, orada bulunan insan yeteneğine sahip olmamak, işleri tekrarlanabilirlik açısından çok zorlaştırır.

  • "Asla" aynı şeyi iki kez inşa etmeyin. Birçok yönden, bir uçak diğer herhangi bir uçak gibi. Kanatları, motorları, koltukları vb. Var. Büyük yazılım projeleri nadiren kendilerini tekrar eder. Her işletim sistemi çekirdeği önemli ölçüde farklıdır. Dosya sistemlerindeki eşitsizliklere bakın. Ve bu konuda, kaç tane benzersiz benzersiz işletim sistemi var? Büyük olanlar bir noktada temel bir maddenin klonları haline gelir. AIX , Solaris , HP-UX , ... tekrar AT&T System V'ye haber veriyor . Windows, her bir yinelemede inanılmaz miktarda sürükledi. Linux değişkenleri genellikle hepsi Linus'un başlattığı aynı çekirdeğe geri döner. Bunu ortaya koyuyorum, çünkü varyantlar gerçekten eşsiz, patentli işletim sistemlerinden daha hızlı yayılma eğilimindedir.

  • Gerçekten kötü proje tahmini. Tekrarlanabilirlik faktörü çok düşük olduğundan, ne kadar büyük olacağını ve bir şeyin ne kadar uzun süreceğini tahmin etmek zordur. Proje yöneticileri ve Yönetim'in ellerini koyamayacağı ve gerçekte ne yapıldığını göremediği göz önüne alındığında, zaman çizelgelerine ilişkin gerçekçi olmayan beklentiler ortaya çıkıyor.

  • KG / KK, daha büyük projeler için olması veya olması gerektiği kadar vurgulanmamaktadır. Bu, bileşenler arasında daha gevşek arayüzlere sahip olmak ve bileşenlerin nasıl çalışması gerektiğine dair katı özelliklere sahip olmamaya dayanır. Bu gevşeklik, istenmeyen sonuçlara ve böceklerin içine sızmasına izin verir.

  • Sürekli ölçülebilir nitelikler. Genel olarak, insanlar X dilinde veya programlamada çalıştıkları yıllardan bahseder. Zaman, kalibre veya beceri kalitesinin yerine geçiyor. Daha önce birçok kez bahsedildiği gibi, iyi programlama yeteneği ile röportaj yapmak ve bulmak zordur. Sorunun bir kısmı “iyi” tanımının çok öznel kalmasıdır.

Negatif olmak istemem ve sanırım yazılım endüstrisi bulunduğumuz yerden önemli adımlar attı. Bu gibi forumlar ve diğerleri, tasarım ilkelerinin konuşmasını ve tartışılmasını desteklemeye gerçekten yardımcı oldu. Yazılım mühendisleri için "temel" bilgiyi standartlaştırmaya çalışan kuruluşlar var. Kesinlikle iyileştirmeye yer var, ancak sektörün oldukça kısa bir süre içinde uzun bir yol kat ettiğini düşünüyorum.


23
Çok iyi cevapların arasından kabul etmek için bir cevap seçmek zordu, ancak en yüksek oylara sahip olmamasına rağmen nihayet bunu seçtim. Aslında, hem bu cevap hem de m3thddman'ın sorusu kesin olarak BT endüstrisinde bu tür bir özelliğin bulunmasının nedeni olarak, gelecekte açığı kapatmak için ne yapılması gerektiğini anlamamıza yardımcı oluyor . M3th0dman tarafından verilen cevapla karşılaştırıldığında, bu çok daha ayrıntılı görünüyor.
Arseni Mourzenko

3
+1 ama şunu ekleyeyim, yazılım zihnin alanında var olduğu için neredeyse sınırsız olanaklara sahiptir, oysa her bir uçağın sınırlı koşullara uyması gerekir.
Spencer Rathbun

5
Çok iyi cevap verdi. İlginç bir örnek olarak - büyük bir uçağın, süreç veya şirket geçmişi olmayan bir grup insan tarafından tasarlanıp uygulanıp uygulanmadığını düşünün. Gördüğüm yazılım projelerinin% 90'ı böyle yapılıyor. Tarihsel ve süreçli deneyimli mimarlar ve şirketler ile diğer% 10 ise çok daha başarılı görünüyor. Buna bir örnek olarak, insanların başarısız olduklarında ölmelerine neden olan yazılımın ardındaki geliştirme sürecine bakın.
Bill K,

7
Bence yanlış cevabı kabul ettin. Danny Woods haklıydı, diğer endüstrilerdeki başarısızlıklar da bu kadar sık ​​ve programlama onun tasarımını oluşturmuyor. Yazılım dünyasında inşaat derleyici tarafından yapılır ve neredeyse ücretsizdir. Asıl sorunuz çok anlatıyordu Kâğıt üzerinde ön çalışma (tasarım, özellikler vb.) Yapıldıktan sonra, fiziksel bir yapının tasarım ve özellik çalışması, yapının nasıl yapılacağına dair tam bir özelliktir. Yazılım dünyasında bununla eşleşen tek şey koddur. Kod tasarımdır, derleme yapımdır.
Michael Brown

5
Ancak sorunun kendisi hatalı. Bununla birlikte, kendi eksikliklerimiz için eleştirel bir göze ihtiyacımız var. Yazılım endüstrisinde başarısız projeleri olan tek firma gibi davranmak gülünçtür. "Tüm tasarım yapıldıktan sonra" demek de aynı şeyi söylüyor. Programlamanın bir tasarım etkinliği olduğu konusunda hemfikir olmasanız bile, yazılım için yapılan ayrıntılı, demir kaplı tasarım ne sıklıkta görülür? İnsanlar yazılım üzerinde belirsiz özellikler veriyorlar çünkü bu değişikliklerin tüm çözümü nasıl etkileyebileceğine dikkat etmeden doğru olmadıklarında yazılımı değiştirmeyi umuyorlar.
Michael Brown

452

Cevap şaşırtıcı basit: o 'diğer sektörlerde' do yüksek başarısızlık oranı vardır. Sadece yanlış şeyleri karşılaştırıyoruz. Yazma yazılımı genellikle 'inşa' olarak adlandırılır ve bu yüzden diğer endüstrilerdeki üretim veya inşaat aşamalarıyla karşılaştırırız. Ama eğer bakarsanız, hiç inşaat değil: tasarım . Yazılım tasarımları kodla yazılır ve yazılım derleme veya anında yorumlama yoluyla bilgisayarlar tarafından yapılır.

Diğer endüstrilerdeki birçok tasarım ya tahmin edilenden daha uzun sürüyor, daha pahalıya mal oluyor ya da hiç bitmiyor. Tanıdık geliyor mu?

Peki, yazılımı planlarken ne yapıyoruz? Hala tasarlıyoruz ama daha erken bir aşamada.

Yazılımda, üretim notu yoktur. Nihai bileşenin oluşturulması (nispeten) ucuzdur ve bu nihai ürünün kopyalanması hem mükemmel hem de etkili bir şekilde ücretsizdir - yapı eserlerini kopyalarsınız.


47
OP'de belirtilen sektörde bile, Havacılık, Boeing 787 Dreamliner ve JSF F-35'in her ikisinde de önemli gecikmeler oldu. Geçen hafta, Sidney'deki büyük alışveriş merkezlerinden birinde bir otopark çöktü. Sydney çok sıkı inşaat standartlarına sahip ama hatalar oluyor.
teambob

23
Bunun bin katı. : Hatta Sorunun zamanlama bağlantı projesi 1988 kaynak kodu itibaren gelişiminde aslında olduğu tasarımını gösteriyor developerdotstar.com/mag/articles/reeves_design.html
PKH

2
F-35, Hubble Telescope gibi pek çok büyük proje, yazılımın geliştirilmesinden dolayı gecikti. Hubble aslında yazılımın hazır olmadığı için yıllarca depoya oturdu.
MrLane

11
@ MrLane: Gerçek dünyada böyle çalışır. Donanımın ne zaman yapılması ve yazılımın ne zaman yapılması gerektiğine dair bir zamanlama belirlenir. Donanım tasarımcıları yazılım ekibine bir ICD sağlar, böylece sw ekibi donanım olmadan kodlarını yazabilir. Donanım, zamanlamasını çok fazla değiştiriyor ve arayüzlerini sık sık sw ekibine bildirmeden, hw sorunları üzerinde çalışacak şekilde değiştiriyor. Sonunda, hw tür çalışır ve çok geç teslim edilir. Tabii ki sw beklenmedik hw "özellikleri" sayısız nedeniyle çalışmaz. Çünkü donanım sorunlarını düzeltmek daha ucuz ...
Dunk

11
sw ekibinin artık ICD'deki değişiklikleri dahil etmesi ve buggy donanımı için geçici çözümler bulması gerekiyor. Öyleyse, hw çok geç teslim edilmesine ek olarak, şimdi sw takımı da buggy donanımını tamir ediyor, kim geç kalmakla suçlanıyor? Yazılım ekibi henüz bitmedi. Geç kalan yazılımdır. Herkes her zaman elektrik, mekanik ve sistem mühendisliği program çizelgelerine bağlı kalıyor ve daha sonra da yeniden yazılmaya ve ekstra gereksinimlere sahip olmaya zorlanıyor. Tek gördükleri sw takımının hala kodlama yaptığı. Böylece, yazılım geç kaldı.
Dunk

180

Bazı rakamlara işaret etmek:

  1. Uygulama başladıktan sonra gereksinimlerin değişimi ; örneğin, ilk Airbus A380 fabrikada yaratılmaya başladığında, eğer biri 200 daha fazla koltuk isterse, bunların oraya konacağına inanamıyorum; ancak büyük bir yazılım projesinde programcılar geliştirmeye başladıktan sonra bile 5 kullanıcı daha eklenebilir.
  2. Karmaşıklık - büyük yazılım projeleri son derece karmaşıktır; muhtemelen tasarlanan ve geliştirilen en karmaşık projeler;
  3. Mimarlık ve tasarım aşamasında yeterli kaynak harcanmıyor ;
  4. Alan olgunlaşmamışlığı - yazılım mühendisliği, diğer mühendislik kız kardeşleriyle karşılaştırıldığında nispeten genç bir disiplindir; Bunun iki sonucu vardır: a) Çok fazla buluşsal ve iyi uygulama yoktur; b) Çok fazla deneyimli uzman değil;
  5. Matematiksel kanıt eksikliği - çoğu durumda matematiksel biçimsel yöntemler bir yazılımın gerektiği gibi çalıştığını kanıtlamak için kullanılmaz; bunun yerine test kullanılır. Bu, matematiğe daha çok güvenen diğer mühendislik alanlarında da geçerlidir; Bunun nedeni karmaşıklık kadar;
  6. Rush - birçok menajerin ulaşılmaz süreleri var; bu nedenle son tarih nedeniyle kodun kalitesi ikinci sıradadır.

Kesinlikle soruya cevap vererek - diğerlerinin programcılardan (özellikle teslimat zamanında) çok yüksek beklentileri olduğuna ve büyük yazılımların ne kadar zor programlandığını tam olarak anlamadıklarına inanma eğilimindeyim.


55
Yazılımda yapılan resmi matematiksel kanıt, genellikle doğru olarak yapmanın neredeyse imkansız olduğu gerçeğinin yanı sıra, nihayetinde programı iki kez yazmaktan (bir kez gerçek programlama dilinde ve bir kez resmi kanıtlama dilinde) ve her ikisinin de doğrulanmasından başka bir şey değildir. sürümleri tamamen aynı.
tdammers

5
Tdammers, ikisine aynı anda yazmanıza yardımcı olacak araçlar var: Coq, OCaml veya Scheme'de bir programın sertifikalı bir Coq programından çıkarılması için "program çıkarma" özelliğini destekler.
jkff

66
"Uygulama başladıktan sonra gereksinimlerin değişmesi". Buna "tuvalet problemini taşımak" diyorum. Bir ev inşa ediyorsunuz, banyoya son dokunuşlar yapıyorsunuz ve ev sahibi tuvaleti farklı bir yerde istiyor. Onlara maliyet hesaplamasını yapıyorsun. "Neden bu kadar, sadece 8 metre uzakta tuvaleti istiyorum?" Daha sonra tuvalete taşınabilmek için yeni bir sıhhi tesisat yapmanız, açık duvarlar / döşemeler vb. Geç değişiklikler her zaman pahalıdır.
Lazy DBA

7
Uçağı test etmenin bir yazılımı test etmekten çok daha zor olduğunu söyleyebilirim. Uçakta, yarattığınız tüm matematiksel sihir, yarattığınız yazılım simülatörünün veya rüzgar türbinlerinin orada olduğunuzda işlerin nasıl yürüdüğünü yansıtmayacağını anladığınızda işe yaramaz hale gelir. Yazılımdaki resmi kanıt, mühendislikte yapılan resmi kanıt ile karşılaştırıldığında imkansız olan zor bir problemdir.
Lie Ryan

2
Listenizdeki 1 numara en önemli IMO, buna iki şey daha eklerim: -Kısa zaman diliminde (örneğin 'iletişim protokolünü değiştirelim!') Çok büyük değişiklikler yapılabilir. Kısa vadede, ancak bunların çoğu projeyi uzun vadede yönetmeyi çok zorlaştırıyor. - Yazılımın çalıştığı ortamdaki değişiklikler, kısa bir süre içinde büyük ölçüde değişebilir. Bir uçağın temel binaları aynı kalacak olsa da (fırtınalarda uçmalı, sağlam pistlere inmeli, ..), örneğin işletim sisteminin yeni sürümü çıkarsa bir yazılım tamamen bozulabilir.
sydd,

140

Sorunun öncülü biraz kusurlu. Hem A380 hem de Boeing 787 yıllar sonunda teslim edildi.

A380 durumunda gecikme, CATIA tasarım yazılımının farklı ve biraz uyumsuz versiyonlarını kullanarak Fransız ve Alman Airbus birimlerinden kaynaklandı . Bu uyumsuzluk kendisini uçağa tam olarak uymayan kablo demetleri olarak gösterdi.

En yaygın kullanılan uçak tasarım yazılımı olan CATIA ile ilgili yanlış bir şey yoktu, ancak birileri yazılım yapılandırma topunu düşürdü.

Boeing 787 ayrıca yazılımla ilgili gecikmelerden de muzdarip, ancak problemlerinin çoğu ağırlık kontrolü ve standart altı parçaların tedarikçiler tarafından teslim edilmesi gibi daha geleneksel yeni uçak problemleriydi.

Hem A380 hem de B787, ilk uçakta yapısal sorunlar yaşandıktan sonra kanat tasarımlarını değiştirmek zorunda kaldı.

Tüm alanlarda insanlar için büyük karmaşık projeler zordur.


10
Kabul. Yazılımın fiziksel malzemeden "daha özensiz bir şekilde üretildiği" yönünde yanlış bir tutum olduğunu düşünüyorum, çünkü kötü yazılım çok görünen düzeltmelerle bitiyor, artı herkes bozuk yazılımlarla uğraşmak zorunda. Eğer bir uçak bir saçmalıksa ve üzerinde bazı işler yapmak zorunda kalırlarsa geri göndermezsiniz, bu, çoğu durumda, teknisyenin büyük bir kusur olmadığı sürece kendi aralarında şikayet ettiği bir şeydir . Ve bunlar da olur.
Ben Brocka,

6
Bence, örnekler kusurlu olsa bile, soru hala duruyor. İstatistiksel olarak kanıtlanmış, yazılım projelerinin daha büyük nihai maliyetlere sahip olduğu ve tahmin edilenden daha uzun sürdüğü kanıtlanmıştır.
Euphoric

18
Ticari bir uçak sisteminin tasarımı ve uygulanması gereği büyük ve kitlesel karmaşık BT projesinin tamamlanmasını, birini içerir unutulmamalıdır sahiptir tam ve doğru işlevsel olması.
Pointy

6
Ve A380’in 2010’a kadar hatırı sayılır bir hatırlama olduğu düşünülürse, o zaman bile “kusursuz” demezdim.
Muhammad Alkarouri,

3
Ayrıca, özellikle askeri anlaşmalar olmak üzere, LOTS konsept uçakları yıllar içinde finanse edildi ve iptal edildi. Uçaklar hiç iyi bir örnek değil, çünkü uzun yıllar veya on yıllar sonraya kadar (sınıflandırılmış) başarısızlıkların çoğunu duymuyoruz.
SilverbackNet

112

Burada gökdelen adam. Sorunuza cevap verebilir miyim bilmiyorum ama kesinlikle konudaki çeşitli öğelere ışık tutabilirim. Binalar gerçekten çok hızlı gerçekleşiyor. Büyük bir kısıtlama yerel (düzenlemeler). Ancak genel olarak, yüksek bir binanın başından sonuna kadar 3 ila 10 yıl sürer.

Yeni bir bina ile yeni bir yazılım projesini karşılaştırmanın çok doğru olmadığını düşünüyorum. Yeni bir bina, bir çekirdeğin veya işletim sisteminin yeni bir sürümüne daha yakındır. Bu bakımdan yazılım geliştirme çok daha hızlıdır. Müşteriden asla kaydolan yüksek riskli bir görev olacağından asla sıfırdan inşa etmeyiz. Binalarda tasarım ve geliştirme çalışmalarının çoğu, kanıtlanmış ve tamamlanmış projelerin türevidir.

Kişisel deneyimden, her on projeden sadece biri inşa edilebilir. Süreç tasarım odaklı olmaktan ziyade geliştirme odaklı, yani çelik fiyatı gibi bir şey tüm proje artarsa, tasarım sürecin en ucuz bileşeni olduğu için pencereden çıktı ya da tasarlandı.

Tasarım konseptin şematik olması, tasarım geliştirme için iki ila altı ay, bir mimar ekibi, planlama danışmanları, yapı mühendisleri, rüzgar mühendisleri, hizmet mühendisleri, miktar ve maliyet danışmanları, sörveyörlerin detaylarına ve inşaat belgelerine altı ay daha erişilebilirlik mühendisleri ve liste devam ediyor ...

Sanal olana karşı fiziksel argüman çok kesin değil. Ayrıca esas olarak sanal araçlarla çalışıyoruz ve ayrıca son ürünümüzden hem zaman hem de ölçek uzaktayız. Çoğu durumda mockup ölçeğinde binaların özelliklerini bile test edemiyoruz ve ne olabileceğini tahmin etmek için simülasyonu kullanıyoruz.

Karmaşıklık bakımından farklılıklar var, ama genel olarak belki de aynı. Sadece birbirimizle ilişkili birimlerimiz ve çoklu seviyeli soyutlamalar ve arabirimler seviyelerimiz yok, aynı zamanda insanlar iletişimi zorlaştıran sürecin küçük bölümlerinde çok uzmanlaşmıştır.

Tasarım ve geliştirme argümanına gelince, bence her iki süreç de tasarım temelli. Bunları birbirinden ayırmak akademik olarak güzel görünüyor ama işlerin nasıl yürüdüğünü bilmiyorsanız tasarım yapmak mümkün değil. Sadece başarısızlık riskini arttırıyorsunuz.

Genel olarak, OP'nin sorusuna göre (potansiyel olarak yanlış) olan tahminim, programlamanın mühendislikten çok bir sanat olduğunu gösteriyor. İnsanlar neden zevk alır ve hatta bedavaya alır, ifade ve zarafet bulurlar? Bilgisayar bilimi aynı zamanda (kalayda olduğu gibi) mühendislikten çok bir bilimdir. Neden sadece mevcut parçaları birleştirmek yerine algoritmaları ispatlamaya çalışıp işleri daha iyi hale getirmeye çalışıyorsun? Bunun bir anlamı olup olmadığından emin değil; Ben yazılımcı değilim.

Yazılım tasarımı ve geliştirmesiyle beni etkileyen bir husus, medyanın kendisiyle ilgili. Bilgisayarlar insan merkezli çalışmaları çok doğal yapıyor. Her şey çok açık ve çok az tolerans var. Bu yolla zihinsel olarak çalışmak zordur ve bazıları içeride karmaşıklığı boşa harcayarak onunla kurtulun. Başka hiçbir şey yapmazsa bunun bununla bir ilgisi olabilir mi?


2
+1 İçgörü için teşekkürler. "işlerin nasıl yürüdüğünü biliyorsanız tasarım yapmak" -> "işlerin nasıl yürüdüğünü bilmiyorsanız tasarım yapmak"?
tokland

Hey oluşturucu, bu yazı için bazı düzenlemeler önerdim, bence mükemmel puanların var, sadece biraz gramer temizlemeye çalıştım.
Steven 16

Programlamanın mühendislikten ziyade bir sanat olduğu konusunda kesinlikle hemfikirim. Yaratıcılık yazılım tasarımında çoğunlukla temel bir unsur olarak görüyorum.
Lanzafame

1
Hem bir inşaat mühendisi hem de bir yazılım mühendisi olarak çalışan deneyimime dayanarak, büyük bir yazılım projesinin ve bir kulenin benzer bir karmaşıklığa sahip olduğu iddiasına katılmıyorum, yazılım karmaşıklığının çok daha yüksek olduğunu söyleyebilirim. Muhtemelen bunun bir çok nedeni vardır, fakat önereceğim tek şey mühendislikte bir sürü kıpırdatma odası olması; inşaat tasarımının üst sınırı neredeyse her zaman maliyetle verilir ve bu yumuşak bir kısıtlamadır. Yazılımların kesin olması gerekir , çünkü bilgisayarlar belirsizliği iyi ele almazlar. Döşeme çalışmıyor mu? Bir sürü çelik eklerseniz haklıdır.
Simon Robb,

Bazı insanlar zevk için bina tasarlar ve yapar . İşverenime söyleme, ama şimdi şunu düşünüyorum ki yazılımlarımın bazıları Sagrada Familia'ya benziyor : Kendine özgü, çok fazla süs, hiç bitmedi; ama ilginç tasarım, inşa etmek ve kullanmak eğlenceli ve hala ayakta.
Peter A. Schneider

44

O zaman bunların tasarımı ne kadar sürdü? Yıl? İki? On yıl? Tasarım bir şeyi inşa etmenin en karmaşık kısmıdır, yapımın kendisi kolaydır.

Bu makaleye dayanarak, yazılım geliştirmenin çoğunlukla tasarım belgesinin kaynak kodun kendisi olduğu tasarım süreci olduğu yavaşça anlaşılmaktadır. Ve tasarım süreci, üretim sürecinden tamamen farklıdır. Tecrübeli insanlar gerektirir ve planlaması mümkün değildir, çünkü küçük ihtiyaç değişiklikleri bile projenin genel mimarisinde büyük değişikliklere neden olabilir. Bu anlayış, son tasarım belgesi olarak kod kalitesini iyileştirmeye ve tıpkı rüzgar tünellerinde uçak modellerini test ettikleri gibi tasarım sürecinin bir parçası olarak test ve hata ayıklamaya odaklanan çevik metodolojilerin temelidir .

Yapının kendisi derleyiciler tarafından otomatik olarak yapılır. Ve bu sayede bütün ürünleri birkaç dakika içerisinde üretebiliyoruz.

Yazılım projelerinin büyük gecikmelerle ve şişirilmiş maliyetlerle bitmesinin nedeni, yöneticilerin hala böyle bir tasarım sürecini tahmin edebileceklerini, tahmin edebileceklerini ve planlayabileceklerini düşünmeleridir. Bu gerçekte geçerli olduğundan daha sık geri tepti. Yine de, insanları katı bir inşaat sürecine bağlayarak, sonuçta çoğunlukla artan maliyetlerin ve kaçırılan son teslim tarihlerinin tersi olmasına rağmen, bir şekilde kaliteyi artırabileceklerini düşünüyorlar.


2
"Bu anlayış çevik metodolojilerin temelidir". Kesinlikle. Şelale yöntemi gökdelenler için anlam ifade ediyor: temeli dökmeden önce plandaki her detayın tam olmasını istiyorsunuz. Fakat gökdelenlerin yıkılması ve yeniden inşası, derleme kodu gibi olduğu gibi serbest ve hemen hemen yakın olsaydı, muhtemelen yinelemeli bir süreç kullanırsınız.
Nathan Long,

22
@NathanLong: Özellikle her üç yılda bir yeni beton biçimleriyle ortaya çıkmışlarsa ve birileri birden fazla asansörü tek bir şaftta nasıl çalıştırabileceğinizi anladı ve aniden çelik artık soğuk değildi ve herkes çerçevelerini karbondan inşa etmeye karar verdi. lif. Bunun gibi şeyler yazılım endüstrisinde her zaman devam eder.
TMN

2
"yazılım geliştirme çoğunlukla tasarım belgesinin kaynak kodun kendisi olduğu tasarım sürecidir" siz sadece gözlerimi açtınız. Teşekkürler.
Bro Kevin D.

@TMN Bir gökdelen inşa ederken, iç mekanın renk paletini değiştireceklerini düşünün çünkü doğru görünmüyor. Bu binanın herhangi bir bileşeni için geçerlidir. Tek bir şaft üzerinde birden fazla asansör çalıştırmayı denemek bir şeydir, ancak hepsini asansöre bağlamaya çalışmadan önce farklı tedarikçiden 20 asansör test etmek zorunda kalacaksınız ...
Loïc Faure-Lacroix

@ LoïcFaure-Lacroix: Mühendisler 20 farklı asansörü test edebilirler, devs ilk önce duydukları blog yazısında tarif edilenleri kullanır. Sonra bina açıldığında ve asansörlerle ilgili bir sorun olduğunda, onları inşa eden şirketin artık var olmadığını keşfederlerdi. Farklı bir tedarikçiden değişiklik almaya çalıştıklarında, orijinal asansörlerinin standart olmayan bir şaft kullandıklarını keşfettiler ...
TMN

39

Airbus A380'in tasarımının ortasında birisinin bir toplantıya katıldığını ve "Heh, üçlü uçak olarak inşa edebilir mi?" Dedi. Diğerleri de "Evet, evet. Üç kanatlı. Daha fazla kanat daha iyi." Gelecek yıllar, A380 tasarımını üçlüye dönüştürmek için harcanıyor. Başka bir toplantıda, biri, "Üçlü bir uçak mı? Bu eski. Bir çift kanatlı istiyoruz. Sadece kanatlardan birini çıkarın." Der.

Ya da bir köprü inşaatı projesinin ortasında birileri, “Heh, biz sadece bir nakliye firması ile anlaşma yaptık. Köprüden 40 fit daha yüksek olmaları gerekiyor, çünkü gemileri çok daha uzun. Onları düzelt.” ."

Bunlar, irili ufaklı yazılım projelerinin endişe verici oranda başarısızlıkla sonuçlanmasının sebeplerinden bazılarıdır.


8
Bu tam olarak olan şey. Yönetim türleri veya müşterileri her 10 saniyede bir fikrini değiştirir ve bu da geliştiricileri sinirlendirir. Son işimden böyle bir saçmalıktan dolayı ayrıldım
Erin Drummond


21

BT'de çalışan makine mühendisliği geçmişine sahip biri olarak, BT'de düşük başarı oranının nedenlerini merak ettim.

Bu konudaki diğerleri gibi ben de sık sık BT'nin olgunlaşmamasına, detaylı standartların olmamasına (evet, ben ciddiyim, basit bir cıvatanın standart sayfasını kontrol ettiniz mi?) Ve standardize olmadığına bağladım. bileşenler ve modüller.

Bina inşası veya gemi inşası gibi diğer endüstriler de çok daha fazla "dövülmüş patikaya" sahiptir: -özelleştirilmiş biçimde- tekrar tekrar kullanılan belirli bir çözüm prototipinin bilgisi ve deneyimi. Farklı boyut ve amaçtaki binaların, gemilerin veya uçakların neden bu kadar benzer göründüğünü hiç merak ettiniz mi? (elbette kuralın istisnaları var ...)

Bunun nedeni, bu prototiplerin iyi araştırılmış, iyi anlaşılmış, genel olarak kullanılmış ve kanıtlanmış bir sicile sahip olmasıdır. Başka türlü yapılamadığı için değil. BT standardizasyonunda nadiren durum söz konusudur: (büyük) projeler aynı anda ve aynı insanlarla aynı anda araştırma ve teslimat yapan bileşenleri yeniden icat etme eğilimindedir !

Bunlar kaçınılmaz olarak geliştirilmesi ve servis edilmesi pahalı olan bir kereye mahsus ürünlere yol açmakta ve hataya açıktır ve belirsiz koşullarda öngörülemeyen şekillerde başarısız olmaktadır. Ve bu nedenle, elbette, bu ürünler çok daha eski, yazılmakta ve eşit derecede büyük maliyetlerle sadece biraz daha iyi ürünlerle değiştirilmektedir. BT ihtiyacı, orta çağ esnafını verimli fabrikalara dönüştüren endüstriyel devrime eşdeğerdir.

Bununla birlikte, BT'yi gerçekten benzersiz kılan faktörler var. Bahsedilen diğer sektörlerin aksine, BT gerçekten her yerdedir: modern yaşamımızın her alanında kullanılır . Bu, BT'nin bu kadar ilerlemesini sağladığı ve yaptığı sonuçları sunma yeteneğine sahip olduğu küçük bir mucize.


5
+1. Standardizasyon için iyi bir örnek (basit bir cıvatanın standart levhası). BT'de nadir görülen normalize edilmiş bileşenlerdir. Kayıt formlarını alın: her web sitesi kendi kendini yeniden yaratır ve pek çoğu kayıt formlarının unicode, boş dizeler, dizeler çok uzun süre vb.
İle

1
@MainMa: kötü bir örnek, düğmelerinizi, metin kutularını, seçenek kutularını, seçenek kutularını divs'ten oluşturuyor musunuz? Hayır, tarayıcının form öğelerini yeniden kullanırsınız; ve tarayıcılar İşletim Sisteminin form öğelerini kullandı.
Lie Ryan

4
Yerliler hakkında konuşmayı tercih ettim, kontrolleri değil. Biraz rastgele web sitesi alın. Şifre için Çince karakterler kullanabilir misiniz? 25 karakterlik şifreler kullanabilir misiniz? Parola veya kullanıcı adına bir boşluk koyarsanız ne olur? Tüm bunlar normalleştirilebilir, ancak değil, her insan her proje için tekerleği yeniden
yaratıyor

4
BT'yi "zanaatkâr" dan "fabrikalara" değiştirmek mümkün olmayabilir. Fabrikalar daha önce yaratılmış bir işlemi yürütüyorlar. Bir fabrikada çalışan işçiler, süreçlerini çok az veya hiç insan düşüncesi olmadan yürütürler. Birçok fabrika, bu gerçeğe bağlı olarak insanların yerini aldı. Yazılımda bir işlem yürütmüyorsunuz, bir tane yaratıyorsunuz. Yazılım oluşturmak, fabrikayı tasarlamaktan çok fabrikayı ve süreçlerini tasarlamaya benzer. Her ne kadar yazılım oluşturma standartlardan faydalanabilse de, temelde bir fabrika olamaz.
mike30

@ArseniMourzenko, "cıvatalar için veri sayfalarını" (yani takımlar, ekipman) "kayıt formları standartları" ile karşılaştırmak kötü bir karşılaştırmadır. Kayıt formları "çatı" veya "ön kapı" gibi olacaktır (aslında, bunları yapmanın bir zil yolu vardır). Bir cıvatanın karşılaştırması işlemci boru hattı davranışına benzer. İhtiyacımız olan hiçbir yere yakın değil: güvenilir işletim sistemi ( titizlikle tanımlanmış özelliklere sahip, "kullanılan montaj seçeneklerine bağlı olarak veri diske çarpabilir" değil) ve aynen geliştirme araçları (standart için kodun% 90'ını kontrol edebilmeleri gerekir) özellikleri)
sehe

15

Korkarım ifadenize katılmıyorum.

Airbus ve Boeing, uçak yapan şirketlere iki örnektir. Uçak yapan kaç firma var? Çok az, kaç şirketin yazılım ürettiği ile karşılaştırırsanız.

Bir yazılım projesini vidalamak için bir uçak projesini vidalamak da aynı derecede kolaydır. Uçak giriş endüstrisinde, yazılım endüstrisinde olduğu gibi, yalnızca giriş engeli çok düşükse, birçok başarısız uçak projesini göreceksiniz.

Arabalara bakın; Çok dayanıklı ve son derece gelişmiş otomobiller üreten yüksek kaliteli üreticiler (Think Land Rover, Mercedes) var ve onları tamir etmek zorunda kalmadan bir yıl dayanamayacak otomobiller yapanlar var (Kia veya Cherry'yi düşünün). Bu, biraz daha düşük giriş engeli olan bir sektör için mükemmel bir örnek, daha zayıf oyuncular almaya başladınız.

Yazılım farklı değil. Öte yandan, çok sayıda buggy ürününüz var, Windows, Office, Linux, Chrome veya Google Arama, zamanında teslim edilen ve uçakla aynı kalitede olan çok yüksek kaliteli projeler.

Birçok insanın özlediği diğer nokta, bir araba, bir tanker veya bir yaşam gerçeği olarak gördüğümüz bir uçağın bakımına ne kadar bakım yapılması gerektiği. Her uçak kalkıştan önce teknik bir kontrolden geçmelidir. Aracınızı her birkaç kilometrede bir kontrol etmeniz ve yağ değişimi, lastik değişimi gibi düzenli işler yapmanız gerekir.

Yazılımın da buna ihtiyacı var. Yalnızca insanlar tanılama, önleme veya denetleme yazılımının durumunu ve kalitesini mekanik / fiziksel ürünlerle olduğu kadar uzun süre harcarsa, bunun gibi daha az açıklama beklerdim. Başlatmadan önce uygulamanızın günlüklerini okuyor musunuz? Peki .. eğer bir uçak olsaydı ;-)


5
Windows sık sık zamanında teslim edilmedi (Longhorn, yani Windows Vista, aslında 2003 yılında gönderilmeliydi). Office'i bilmiyorum, ancak açıkça belirttiğiniz diğer yazılım projelerinin çoğunun zaman çizelgeleri yok veya sürümleri o kadar sık ​​ki sürümde hangi özellikleri içeriyorsa hazırlar ve hazır olana kadar her şeyi zorlarlar. .
Ken Bloom,

2
Bu, yüksek kaliteli yazılıma daha iyi bir örnektir: 420.000 hat ve hatasız: Space Shuttle'ı destekleyen yazılım . Dikkat edin, bu tür bir kaliteyi elde etmenin çok büyük bir maliyeti vardı.
dodgy_coder

@ dodgy_coder, Güvenli bir uçak inşa etmek de ucuz değildir ;-)
Karim Agha

1
@ PaulNathan terbiyeli çok öznel;)
James Khoury

3
@KarimA .: Güvenli bir uçak inşa etmek ucuz değildir, ancak bir uçağı güvenli hale getiren şeyin büyük bir kısmı yazılımdır ... Bu yüzden uçak tasarımının önemli bir kısmı aslında yazılım tasarımıdır!
korku

10

Dijital yapı taşları 1 veya 0 olabilir.

Mekanik bir tasarım, tolerans seviyesine sahiptir. Mükemmel perçinlerden daha azını bir köprüye koyabilirim ve büyük olasılıkla düşmeyecektir, ancak bir kez bile bir 1'in tüm programda başarısız olabileceği bir 0 koyma örneği bile koda düşebilir.

Hesaplamanın mantıklı ve etkileşimli olması nedeniyle, herhangi bir küçük değişiklik bile olsa ciddi başarısızlığa neden olabilir.


21
Bir keresinde birisinin "Son kapı kolunu eve geri koyarsanız, evin tamamı patlarsa, inşaat sadece programlama gibi olurdu" dediğini duydum.
Morgan Herlocker

9

Sık sık aynı şeyi merak etmişimdir. Kesinlikle (zaman zaman) ne yaptığımız hakkında hiçbir fikri olmayan bir grup amatör gibi hissediyoruz . Yöneticileri veya diğer dış etkenleri suçlayan açıklamalardan hoşlanmıyorum - biz geliştiricilerden yarattıklarımızdan sorumlu olmalıyız.

Hataların ucuz olduğu bir işte olduğumuzu düşünüyorum . Yama yazılımı bir gökdeleni yeniden inşa etmek veya satılan her cep telefonunu geri çağırmakla karşılaştırıldığında ucuzdur.

Bu, böceklerin günlük yaşamın bir parçası olduğu bir kültür yarattı . Bir omuz silkme ile kabul edilirler. Bazı hatalar muhtemelen kaçınılmaz olsa da, günlük çalışmamıza hâkim olmalı mı? QA'nın sorun olmaya değdiğini hissetmeyen yöneticileri tamamen anlıyorum, çünkü tam olarak böcek beklemiyorlar. Hatasız kod üretmek için her türlü çabayı göstermeyen programcıları anlamıyorum, çünkü hataları düzeltmek çok sıkıcı.

Temelde bunun bir kültür sorunu olduğuna inanıyorum ve değişeceğini umuyorum.


5
Hatasız kod üretmek için her türlü çabayı göstermeyen programcıları anlıyor musunuz, çünkü bu iki kez daha uzun sürecek ve yönetim dün
Beta,

4
Bu, diğer endüstriler için de geçerli olmaz mı? Dış etkenlerin var olmadığını inkar etmiyorum, ama bir değişimin içeriden gelmesi gerektiğine inanıyorum. Yazılım mühendisleri kendi alanlarındaki uzman rollerini üstlenirlerse, tavsiyelerine ve tahminlerine saygı duyulur ve yönetim tarafından tahmin edilemezdi. Yoksa saf mı olacağım?
waxwing

2
Bir müşteriyi ara sıra ziyaret ettiğimde ve programladığım ürünü kullanmalarını izlerken çok şaşırdım. Çalışmalarını çok zorlaştıran hatalar ve işlevler var ve bir programcı olarak, kullanıcı için ne kadar kolay hale getirilebileceğini görüyorum, ancak kullanıcı bundan rahatsız olmadığını, bildirmek için.
Awe

7

Mühendislik standartları ve uygulamaları BT'de (bağımsız bir endüstri olarak) havacılık sektöründen çok farklıdır . Bu belki de en kolay, BT uzmanlarının havacılık alanındaki standart belgelerle karşılaştığında nasıl tepki verdiklerini düşünerek anlaşılıyor . Örneğin, son zamanlarda İnternet'te dolaşan Joint Strike Fighter C ++ Standartları .

Birçoğu, eğlence veya hevesli istifalarını dile getirir (bu şekilde yapabilmeyi isterdim); ve çoğu, tüketici ürünlerini bu şekilde teslim etmenin pratik bir yolu olmadığını iddia ederek alay etmeye yanıt veriyor. Bu, tüketicilerin değil yönetimin beklentileri göz önüne alındığında bile doğru olabilir. Birkaç hafta boyunca sadece kodlayan ve kodlayan, hiçbir şeyi demonte etmeyen kodlayıcılar için büyük bir güvensizlik var. Tanrı, sadece iki haftalığına bir şeyler tasarlayan kodlayıcıya yardım eder . Uçaklarda öyle değil.

Yazılımda, insanlar gerçekten şu anda bir şey olmasını bekliyorlar. Tabii, mantık devam ediyor, gerçekten sağlam olması biraz zaman alacak; ama bir hafta içinde basit terimlerle anlatılan karmaşık bir şeye sahip olamaz mıyız ? Ayrıca, dürüst ve karmaşık terimlerle açıklanan karmaşık şeylerin hayal gücünü nadiren heyecanlandırdığını; ve bu nedenle birçok mühendis, basit şeylerin yaratıcı bir şekilde bir araya getirilmesi hayali bir dünyada suçluluk duyuyor (zor işlerin yapıldığı bir dünyanın aksine).


5

Benden bir şeyler:

1- Standartlar ve parçalar: Uçak üreticisi , geliştirici değil. Tamamen emin değilim, ama tahminimce bir çok parça dış kaynaklı. Kendi elektronik / enstrümanlarını yapmıyorlar, bir şirketten koltuk alıyorlar, motorlar muhtemelen başka bir yerde geliştiriliyor, vs.

Yazılım projeleri ise, hemen hemen her zaman sadece bazı küçük çerçeveler / yardımcılar ile sıfırdan başlar.

2- Pazara girme zamanı: Uçaklar için zaman kritik bir konu değil. Bahse girerim Airbus'un tasarımı bitmeden yıllar önce tamamlanmış ve o dönemde gerçekleşebilecek her türlü büyük atılımı ihmal etmeyi seçmişlerdir. (Araba üreticileri için aynı, örneğin, şu anda geliştirdikleri en son teknoloji 5-10 yıl içinde sokaklara vuracak.)

Yazılım için çok çevik olmanız gerekiyor, şimdi büyük bir projeye başlarsam ve herhangi bir değişiklik yapmadan geliştirmek için üç yıl sürersem, şansım oldukça yüksek, artık mevcut olmayan teknolojiye güveniyorum ya da ürünüm tamamen modası geçmiş. Bu da çok fazla sorun sunuyor.

3- Serbest bırakma döngüsü ve sürümleri. - Bir uçak "serbest bırakıldığında" tamamen bitmesi gerekir. Gecelik sürümlerde veya benzeri sürümlerde kararlı beta sürümleri yoktur. Ek olarak, bir kez yapıldığında, sadece küçük bir şekilde değiştirilebilir. Mevcut bir boeing'e 100 koltuk ek bir seviye ekleyemezsiniz, bu mümkün değildir.

Öte yandan, yazılım genellikle yalnızca “işe yarayan” ancak artması gereken ürünleri tamamlamayan artımlı değişikliklere sahiptir. Ayrıca, BT’de "ek olarak, 50 ton daha ekleyen uçağımıza başka bir bagaj bölmesi ekleyelim" demek sıra dışı değil.


5

Bence cevap oldukça basit:

1) Fiziksel inşaat ve uygulama, insanlar olduğu sürece buralarda olmuştur - fiziksel projelerin uygulanması için yöntem ve tekniklerimizi geliştirmek için binlerce yıldır. Tamamen yeni ve farklı bir beceri seti gerektiren yazılım 'inşaatı' 50 yıldan daha eski değil - henüz yeterince zamanımız olmadı.

2) Sanal yapı daha zordur - aklınızda herhangi bir fiziksel gerçekliğe sahip olmayan şeyleri 'görmek' zorundasınız. Ürününüzün neye benzemesi gerektiğini ve onu oluşturmak için atması gereken adımları bilmeden önce birçok bilgiyi analiz etmenizi ve özetlemenizi gerektirir. Bir köprü veya bina inşa ederken öyle değil.

3) Bir yazılım arızasının veya hatanın kaynağını bulmak, fiziksel mühendislik yaparken olduğundan çok daha zordur. Eğer bir kiriş sıkışırsa, burkunun nerede olduğunu görüyorsunuz ve onu tutan ve arızalanan destekleri görüyorsunuz, vb. Fiziksel yapıların olduğu gibi fizik ve matematik yasaları.


4

Jack Ganssle'ın gömülü muse'undan bir makalenin yazılı bir kopyasını kullanarak cevap vermeye çalışacağım. Bu her yerde firmware olduğunu söylese de, zihinsel olarak onu yazılımla değiştirin.

Neyle karşılaştırılmış?

Firmware, evrendeki en pahalı şeydir. Eski Lockheed Martin CEO'su Norman Augustine, "Augustine Yasaları" adlı harika kitabında, savunma topluluğunun karşılaştığı bir sorun hakkında açıklayıcı bir hikaye anlatıyor. Yüksek performanslı bir savaş uçağı, birbiriyle çelişen ihtiyaçların hassas bir dengesidir: yakıt menzili - performans. Hıza karşı ağırlık. 70'lerin sonunda savaşçıların eskisi kadar ağır olduğu görülüyor. Her zaman daha büyük karlar peşinde koşan müteahhitler, çok fazla maliyet katabilecekleri, ancak hiçbir şey ağırlamadıkları için boşuna bakıyorlardı.

Cevap: bellenim. Sonsuz maliyet, sıfır kütle. Aviyonik artık savaşçının maliyetinin yarısından fazlasını oluşturuyor. En son Amerikan dövüşçüsü F-22'yi göz önüne aldığınızda, bir milyar insanın havalesinin üçte birine mal olduğunu düşündüğünüzde bu büyük bir değişiklik. Augustine, bu hikayeyi anlattığı zaman, neredeyse neşeyle boğuşuyor.

Fakat yazılım neden bu kadar pahalı? Tom DeMarco bir kez bu soruyu şu üç kelimeyle cevapladı: neye göre? Göreceli olarak sıkıcı iş vakalarını tartışmaya devam etti, ancak bu cevap aklımda yıllarca yankılandı. Neyle karşılaştırılmış? Yazılım ile rutin olarak benzeri görülmemiş karmaşıklıkta ürün davranışları yaratıyoruz. Elbette, kod pahalıdır. Fakat asla medeniyet tarihinde hiç kimse bu kadar karmaşık bir şey inşa etmedi.

Vikipedi'den utanmadan kaldırılan ve doğruluk açısından kontrol edilmeyen şu kabarcık türünü göz önünde bulundurun:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

110 tane boşluksuz karakter, belki de bir veya iki saat içinde attı. Yazılımımız olmadığını ve başka bir strateji kullanarak bir sıralama yapmak zorunda olduğunu varsayalım. Neye mal olacak?

Bir makine mühendisi, mesleğinin bilgisayarlardan çok önce sıralayıcılar yaptığını söyleyebilir. IBM'in 1949 dönemi modeli 82 kart sınıflandırıcı (düşünün http://www.columbia.edu/acis/history/sorter.html bir 4 MHz üzerinde bile yönetmek olabilir bizim kod parçacığı yerine daha az dakikada 650 kartları, işlem hacmi ile) Z80. Tabii ki, model 82 bir seferde bir kartın sadece bir sütununu sıraladı; bir güverte tamamen sıralamak için onlarca pas alabilir.

Bu canavarı tasarlayıp inşa etmek ne kadar sürdü? Yıllar, şüphesiz. Ve işlevselliği, çok daha hızlı olan ve devasa veri kümeleriyle başa çıkabilen kodumuza göre değişir. Fakat bu 1949'du. Elektronik bileşenlerden bir kabarcık türünün FPGA ve VHDL olmadan ya da bir CPU olmadan yapılması ne kadar sürer?

Bir saat içinde, yonga seviyesinin üstünde bir blok blok diyagramı yönetmiştim (bloklar "adder", "16 bit mandal" ve benzeri gibi isimlere sahiptir). Ancak sıralama mantığı açıkça oldukça dağınık olduğundan, bir noktada uygun denklemleri yazmanın çok zor olmadığını varsayarak bir PLD'ye atıldım. Ve, evet, belki de programlanamaz mantık kuralını ihlal eden, ancak herhangi bir makul süre içerisinde kapıları kullanarak tüm bu mantığı tasarlayıp hata ayıklamak, galon gazı gibi bir ihtimal değildir.

16 bit kelime ve adres varsayarak, devrenin bir düzine 16 bit mandal, adders ve benzerine ihtiyacı olacaktır. Artı hafızası. Sıralanmamış verilerin RAM'e nasıl ulaştığı veya sonuçların nasıl aktarıldığı hakkında hiçbir fikrim yok. Bunlar belirtilmemiş tasarım gereksinimleridir. Yalnızca yazılım çözümü, yalnızca işlev prototipini yazarak bu gereksinimleri doğal olarak çözer.

Kaba blok diyagramın şemasına çevrilmesi bir gün sürebilir. Daha sonra bir PCB tasarlama ve üretme, parça sipariş etme ve yükleme (ve beklenmedik ancak kaçınılmaz yaşam sonu sorunları ile başa çıkmak için tasarımını değiştirme) ve daha sonra elbette devre çalışmasını sağlayın. Kurul, parçalar ve uygun test ekipmanları için haftalarca çaba ve paradan bahsediyor olabiliriz.

Bütün bunlar 7 küçük kod satırını değiştirmek için. Çok az gerçek gömülü program 10.000'den az; çoğu bir milyonu aştı. Gerçek, süper boyutlu bir bilgisayar programının yerini almak için ne kadar donanım ve ne kadar mühendislik gerekir?

Elektronik tablo gibi gerçek bir program düşünün. Bir işlemcisiz bir işlem yapmak için ne kadar devre gerekir? Bir şehrin büyüklüğü olabilir.

Bellenim, evrendeki en pahalı şeydir, ancak yalnızca çözdüğü sorunların hayal edilemez karmaşıklığı nedeniyle. Ancak, alternatiflerden çok daha ucuz. Patronunuz sinir bozucu bir şekilde yazılımın neden bu kadar uzun sürdüğünü sorduğunda ne söyleyeceğinizi biliyorsunuz. Neyle karşılaştırılmış?

Bu yüzden orada! Yazılım / bellenim benzersiz bir karmaşıklığa sahiptir.


3

Yazılım mühendisliği ve yönetimi temel olarak diğer pek çok mühendislik alanından farklıdır. Çıktıların fiziksel değildir ve üretim süreci olan tasarım ve geliştirme süreci. Bir yazılımın başka bir kopyasını oluşturmak, esasen sıfır marjinal maliyete sahiptir; tüm masraflar ilk kopyanın geliştirilmesinde bulunur.

Bir yazılım disiplini olarak göreceli yazılım mühendisliği ve yönetimi gençliği nedeniyle, yazılım geliştirme ve mühendisliği bir bütün olarak engelleyen bazı gerçekler (yanlış referanslar ) var ( bu referansa bakınız ).


3
Yazılım geliştirmenin olgunlaşmamış olması üzerine +1. İnşaat Mühendisliği uygulamalarını geliştirmek için birkaç bin yıl oldu. Havacılık ve Uzay yüzlerce olmuştur ve diğer mühendislik disiplinleri dayanmaktadır. Yazılım hala genç. Aynı zamanda normal olarak iyi anlaşılmadı. İnsanlar akışlar arasında köprüler kurabilir ya da çocuklar gibi kağıt uçaklar yapabilirler - aynısı yazılım için de doğru değildir.
Andy Burns,

3

Tüm geliştiriciler eşit olarak yaratılmaz. Bazıları iyidir, bazıları değildir.

Söylediklerimi öğrenmek için her zaman diğer kişilerin kodlarını okumayı deneyin. Çok fazla ekstra mantık ifadesi risk ekleyebilir. Bu riskler hasta davranışlara veya hatalara neden olabilir. Yeterli mantık ifadesi yok ve artık boş referanslarınız var. İyi programcı bunu anlar ve ne ve ne zaman yapacağını bilir. Ama kimse mükemmel değil. Her şey karmaşık. Başkalarının kötü düşünülmüş çalışmalarını ekleyin ve projelerin nasıl tükendiğini görmek kolaydır.


3

Katedrallerin yapımı 100 yıl kadar sürüyordu.

Bazı Airbus uçaklarının çalışması için 1 milyon satır kod gerekiyor.

Bir şeyi ne kadar çok geliştirirseniz, o kadar çok gelişme elde edersiniz, bu nedenle yazılım endüstrisine daha iyi hale gelmeleri için birkaç yüzyıllık deneme hatası verin. veya kusurları.


Köln Katedrali 1248'de başlamış ve 1880'de tamamlanmıştır. 632 yıl.
gnasher729

3

Büyük projeler genellikle büyük kuruluşlarda gerçekleşir. Daha önce hiç bir zaman büyük bir organizasyonda çalışmadıysanız, performansı ve üretkenliği öldürmenin garantisi olan bir şey var: bürokrasi.

Şaşırtıcı bir şekilde, birçok kişi bürokrasinin ne olduğunu bilmiyor (genellikle politika ile karıştırılıyor), hatta bir bürokrasi problemi olsa bile.

Kısa süre önce akıllı kart kimlik doğrulaması için bir proje tamamladık. Başlangıçta üç ayda tahmin edildi. 15 ay sürdü. Gecikmenin maliyeti, bütçesi, kapsamı veya teknik sebepleri yoktu. Kapsam aslında oldukça dardı - yalnızca ayrıcalıkları yüksek olan hesaplar (yönetici hesapları), yaklaşık 1.200 hesap.

Bir diğer önemli faktör, iş ortaklarınızdır. Bu satıcıları içerir. Ortaklarınızın projenize gecikme getirecek bir sorunu varsa, gecikme sorununu çözecek pek bir seçenek yoktur. Doğrudan sizin için çalışmazlar ve bir kişiyi neden olabilecek bir kişiden kovamayabilirsiniz. İş ortağı işten atılabilir veya maddi cezalara veya dezavantajlara maruz kalabilir, ancak bu, projenin gecikmesine neden olduğu gerçeğini değiştirmez. Boeing'de Boeing 787 Dreamliner ile bir mamut tedarik stratejisi uyguladıklarında gerçekleşen tam da buydu .


3

Senin için daha kısa bir sürümüm var:

Yapması kolay veya düzenli olan ne olursa olsun, biz yerine yapmak için bir program yazıyoruz.

Ve sonra bunun yerine meta-süreç ile savaşın.

Bu doğru değil, aslında, ama her gün blog motorları yazmak yerine binlerce blog kuruluyor. Her iş günü, bunlar için özel olarak tasarlanmış veritabanı uygulamaları yazmak yerine binlerce Excel makrosu yazılmaktadır.

Birçoğu burada bahsedilen - başka faktörler var - ama tartışmaya bu noktayı eklemek istedim.


Katılıyorum. Büyük programlar olabilir onlar 3 yılda yüzlerce kez yapmış oldum çünkü kusursuz ve zamanında teslim edilir. Örneğin, bir metin editörü.
Droogans,

Sadece bu değil, daha önce yapılan kusursuz programları sunma biçimimiz eski programı web sitesinden indirip bir kopyasını çıkartmaktır. Ancak bazı nedenlerden dolayı başarılı bir büyük yazılım projesi olarak sayılmaz.
bdsl

3

Sorumluluk eksikliği ... Bir uçak çöktüğünde insanlar dava edilir. Yazılım endüstrisi herhangi bir yazılım kusurundaki sorumluluğunu reddeder, bu nedenle sağlam ve güvenli bir ürün oluşturmak için bir teşvik eksikliği yaratır.


1
Bunu uzun zamandır söylüyorum. Uygulamanız çöktüğünde dava açtıysanız, kod çok daha sağlam olurdu ... Ve dava etmek istediğim çok sayıda şirket var - örneğin MS'i alın: tüm güncellemeleri ve yamaları nedeniyle kaç saat kaybedildiğini ve diğer şeyleri bozan hatalar ve revizyonlar. Kayıp saatler için onları dava ve kalite HIZLI HIZLI artacaktır.
Vektör

Bu durumda, maliyet artacaktır ve özellikler düşecektir.
Jim G.

1
@JimG. Soru, özellik ya da fiyat değil güvenilirlikle ilgiliydi. Elbette daha güvenilir bir ürün yapmak zorunda olmak, tasarım alanınıza daha fazla kısıtlama getirecektir ve diğer yönlerden (özellik ve maliyet) zarar görebilir.
GreyGeek 0

4
Boeing 737'nin bedeli 50-80 milyon dolar. Ne zaman bir taneye başlarsan ödersin-- her yeni ofis açarken mi ödersin? Birisi yazılımımı kullandığında her zaman para kazanıyor olsaydı, kesinlikle güvenilirliğe ithaf olurdum.
FlavorScape

1
@Jim G: 5 tane crappy olandan ziyade, bir ürünün 1 stabil versiyonuna sahip olmayı tercih ederdim.
Giorgio

2

Büyük projelerin çoğu, az sayıda tasarım kısıtı tanımlayabileceğiniz, alt projelerin yüksek derecede ayrılabilirliğine sahiptir; Tüm alt projeler tamamlandığında tüm proje çalışacaktır. Bir alt projede bir şeyler ters giderse, tüm çaba soruya atılmaz; alt projeyi tamamlamak için alternatif yollar aramanız yeterlidir (örneğin farklı bir motor kullanın).

Yazılım projelerinde bu, hem pratik olarak hem de insan doğası açısından mümkün, ancak zordur.

Kısmen, diğer endüstriler, bu tür bir ayrılmanın iyi bir şey olduğunu zor yoldan öğrendiler. Örneğin, Rolls Royce uçak motorlarını kullanacaksanız, yalnızca belirli bir tasarıma sahip kanatlarla çalışan özel Rolls Royce cıvatalarını ve bağlantı noktalarını kullanmanız gerekmez ve ardından Pratt ve Whitney'e geçmeye çalışırsanız, tüm kanadınızı sıfırdan yeniden tasarlamanız gerekir (bu da gövdenin tamamen yeniden tasarlanmasını gerektirir; bu da sırayla farklı bir uçuş eğlence sistemi satın almanızı gerektiren farklı koltuklar almanızı gerektirir). hangi...). Birkaç bağlantı olabilir - motorları sadece bakımsız değiştiremezsiniz - ama büyük projeler genellikle bu tür durumlar minimize edildiğinde daha iyi çalışır.

Ben kendi aralarında temiz arayüzlü küçük yazılım projelerinin bir küme olarak tasarlanmış büyük yazılım projeleri olacağını varsaymaktadır değil büyük proje aslında küçük projelerin küme tarafından çözülür sürece, özellikle sık sık başarısız olurlar. (Bu konuda bir hata yapmak mümkündür.)


2

Yapı yazılımı sistemleri, fiziksel yapıların oluşturulmasından çok farklıdır. Yani, uygulama çok farklı. Örneğin, büyük bir tanker inşa ederken, parçaları bir robot veya elle kaynak yapmak, tüm somunları ve cıvataları sıkmak, boyamak, süslemek, taşımak gibi oldukça basit (ancak kolay değil!) Görevler yaparsınız. ekipman ve mobilya vb. Bütün bunlar gerçekten çok basit şeyler yapmak.

Ancak, yazılım söz konusu olduğunda, çok daha karmaşık bir hal alır . Örneğin, ürünün güvenli bir şekilde oturum açmasını ve kullanıcı kimlik bilgilerini depolamasını tam olarak nasıl uyguluyorsunuz? Hangi kütüphaneleri ve araçları kullanabilirsiniz? Hangi kütüphanelere ve araçlara aşinasınız? Haşlama + tuzlama fonksiyonunu tam olarak nasıl yazıyorsunuz ve güvenli olmasını nasıl sağlıyorsunuz? Bunu birçok şekilde yapabilirsiniz; bu tür şeyler için gerçek pratik tasarım desenlerini ayarlamak imkansızdır . Evet, söz konusu tasarım desenleri do "en iyi uygulamalar" olarak daha küçük bir ölçekte mevcut olan, ancak her yazılım sistemi diğerlerinden çok farklı olduğunu ve aslında imkansız öylesine hızla alan gelişmeler ve değişiklikler yetişmek için.

Bir ev inşa ederken, ana destek duvarlarının yetersiz göründüğünü ve değiştirilmeye ihtiyaç duyduğunu farkettiğiniz bu sorunlarla karşılaşmazsınız; bu, şu ana kadarki ilerlemeyi yok etmenizi ve destek duvarlarını tekrar yaparak tabandan başlamayı gerektiriyor . Tasarım aşamasında bu tür meseleleri ele alıyorsunuz çünkü binanızın ne tür destek duvarlarına ihtiyaç duyduğunu tahmin etmek oldukça basit.

Yine de yazılım ile durum böyle değil. Tüm ürünü tek bir varlık olarak tasarlayamaz ve daha sonra uygulayamazsınız. Yazılım tasarım süreci genellikle yinelemelidir ve ürün uygulanırken ve test edilirken hedefler ve gereksinimler değişir. Bir bütün olarak yazılım geliştirme, işlerin genellikle en az beklendiğinde değiştiği yinelemeli bir süreçtir ve bu tür değişikliklerin çoğu zaman daha fazla iş, daha karmaşıklık ve ne yazık ki ve sonuç olarak daha fazla para, zaman ve zor iş gerektiren zorluklar doğurur.

Dolayısıyla, özünde, büyük projeler sunmanın ve proje zaman çizelgelerini ve yol haritalarını tahmin etmenin zor olmasının nedeni, yazılım geliştirme ve özellikle çalışan tasarımın çok karmaşık alanlardır. Karmaşıklık kök problemdir.


+1 ve fikri daha da ileriye götürmek için, sektör dışındaki insanlar tarafından gerçekçi olmayan beklentilere, mantıksız politikalara ve kullanıma hazır tasarımlara yol açan bu karmaşıklığın farkına varmak bir başarısızlıktır. İngiltere'deki kamu sektörü mükemmel bir örnek. Halka açık bir bina için, yönetimin, çim kesmeden önce uzman görüşü, kapsamlı danışma ve su geçirmez proje planlaması ile tasarımın mükemmel olmasını sağlamaya çalışın. Ancak aynı kişileri yeni bir BT sisteminin önüne koyun ve gereksinimlerinizdeki son dakika değişikliklerini göreceksiniz, db şeması, kullanıcı arayüzü ... "ne kadar zor olabilir? Bu sadece biraz yazmaya"
Julia Hayward

1

Büyük projenin tanımı çarpıktır.

Teknik olarak büyük bir proje zamanında teslim edilebilir ve kusursuz bir şekilde, yıllar içinde birçok kez inşa edilen bir şey olduğu kabul edilir.

  • Bir Pac-Man klonu.
  • Hesap makinesi
  • Bir metin editörü

Düşündüğünüzden eminim ... "ama bunlar küçük projeler! Metin editörü basittir ." Sana katılmıyorum Bilgisayarlar aşırı derecede karmaşık. Kullanıcıları bir işletim sistemine kurmak ve kurmak sadece zaman zaman zor olabilir ve işletim sistemi bile yazmadınız ya da donanımı kurmadınız.

Bahsettiğiniz projeler uzay araştırmalarına benzer büyük projelerdir. Galaktik seyahatler yapmanın ne kadar sürdüğünü nereden biliyorsunuz? Hangi modele dayanıyoruz? Bilinen, bildiğiniz bilinmeyenler, bilinmeyenler ve son olarak da bilinmeyen bilinmeyenler var, yazılım geliştirmede çok fazla şey oldu.

Bence problem beklentidir. Sadece teknoloji olduğu için onu kullanmanın bir süre başarılı olacağı (ya da kullanması akıllıca olacak) anlamına gelmez. Diğer endüstriler yazılım endüstrisi gibi davranırlarsa, on yılın sonunda satılık kara delikli elektrikli süpürgelere sahip oluruz. Veya bazı "vizyon sahibi" bir ay tabanı oluşturmak için kaynaklara sahip olacak ve bir Starbucks'un ziyaretçiler için deneyimi gerçekten "tamamlayacağına" karar verecek. Sorunun yazılım endüstrisi olduğunu sanmıyorum, ancak beklentiler üzerine geldi.


Kara delikli elektrikli süpürgeler? Peki ya işlevsel güvenlik?
Peter Mortensen

İşlevsel güvenlik eksikliği? Bu bir özellik! Kara delikli elektrikli süpürgeyle bir şeyleri temizlemeye çalışırken değişmez yapıların kullanılmasını savunuyoruz.
Droogans

1

Başka pek çok şey olsa olabilir sayılabilir, ben çok temel bir cümle işaret değer olduğunu düşünüyorum. Çoğu ürünün mevcut davranışa uyması amaçlanmıştır. Köklü bir atılım (örneğin, araba) olan bir ürün bile, genellikle mevcut davranışa uyması için yapılmıştır ve basitçe onu daha basit / kolay / daha ucuz / ne yaparsa yapın. Evet, çoğu zaman mevcut davranışlar üzerinde de bazı yan etkiler olur (örneğin, atlar için yemek yerine arabaya yakıt almak), ancak ikincisinin çoğu oldukça küçük bir yan etki olma eğilimindedir.

Buna karşılık, kullanıcıların davranışlarını değiştirmeyen hemen hemen her yazılım (örneğin, işlerini çok daha kolay yapmalarına izin verir) temel olarak 1. günden itibaren tam bir başarısızlık olarak garanti edilir. Daha da kötüsü, büyük yazılım projeleri sadece Kullanıcıların bireysel bir seviyedeki davranışlarını içerir, fakat büyük grupların davranışlarını, genellikle de kuruluşun tamamını kapsar.

Kısacası, yazılımı kendisi tasarlamak genellikle işin en kolay kısmıdır. Zor kısım, halkların işlerini onlar için yeniden tasarlamaktır. Başlamak zor; Sadece işe yaramayacak, aynı zamanda kabul edilecek şekilde de yapmak çok daha zor.


1

Airbus A380 dediğiniz gibi başarılı bir proje değildi. Bir CAD / CAM şirketinde çalışıyorum ve bana farklı firmalarda farklı yazılım versiyonları kullandıkları için (Airbus öncülüğünü de yaptık) birkaç yıl ertelendiğini söylemiştim. Yani, dünyanın farklı yerlerinde farklı bölümler tasarlanıyordu. Ve bütünleşirken tüm tasarımın birleştirilemediğini öğrendiler, bu yüzden onu tek bir versiyonda yeniden tasarlamaları gerekiyor. Bu yüzden baktığımda başarılı olduğunu sanmıyorum. 2-3 yıl önce gelseydi, Airbus için oyun değiştirici olurdu.

Ayrıca sağlam yazılımlarla ilgili olarak, herhangi bir uçağa, arabaya (ABS, EPS, iklim kontrolü vb.) Veya uzay mekiğine bakarsanız, bunları çalıştıran% 50'den fazla yazılıma sahip olduklarını ve çok sağlam olduklarına inanıyorum. Sadece yazılıma daha yakın olduğumuzdan ve daha birçok yazılım programından dolayı daha fazla hata görüyoruz.

Http://www.globalprojectstrategy.com/lessons/case.php?id=23 adresini ziyaret edin ve Airbus A380'in ne kadar başarılı olduğunu görün.


1

Yazılım mühendisliği, mühendislik arka planı ve inşaatta çalışan bir eş. İşlerimizin farklılıkları hakkında uzun tartışmalar (ve argümanlar) yaptık.

Yazılım mühendisliği yeni şeyler tasarlamakla ilgilidir . Neredeyse temel olan her şey bir yerde açık kaynak kodlu bir kütüphanede yapıldı. Bir yazılım mühendisinin işe alındığı hemen hemen her işte, var olmayan bir şeyi tasarlamak zorundadır.

İnşaat ve çoğu mühendislik şekli gibi bir şeyde, aksi halde yazılımdaki bir “kütüphanede” olacak şeyler zaten tamamen tasarlandı. Bir kule inşa etmek ister misiniz? Sadece birkaç değişiklikle planları kopyalayıp yapıştırın.

Aslında, mühendis olmamaya karar vermemin temel nedenlerinden biri, zamanınızı çoğunu, bir sosyal ağ gibi daha görünür bir şeyi programlamak için kullanabileceğiniz zaman, mevcut bir buluş için% 10'luk bir iyileştirme tasarlayarak geçirmenizdir. .

Mühendislikte pek fazla yeni tasarım yok; son derece yetenekli bir mühendis, mevcut bir tasarımı yeni bir şeye manipüle edebilecek veya üzerinde geliştirebilecek bir kişidir. Ancak hemen hemen her programcının tasarımları değiştirmesi, kırması veya yeni bir şey yaratması bekleniyor.

Geri standartlar dışında, tamamen değişti ne kadar bak montaj vb Java C ++, JavaScript, C #, PHP C'ye ve. 10 ya da 20 yıl öncesinden geri dönüştürülebilecek fazla kod yok. Bunu söylemek çok farklı ... otomotiv veya havacılık endüstrisi, on yıllardır tasarımlarını geliştirmeye devam edebileceğiniz zaman.

Proje yönetimi, yazılımda açıkça zordur . Zaman tahminleri, işi yapan insanlar tarafından en iyi şekilde yapılır , ancak tahmin yapmakla meşgul olduklarında kod yazmazlar . Bu, insanları herhangi bir proje yönetiminden kaçınmaya teşvik eder.

Çoğu zaman, birçok kod belirli kişilere dayanır ve bu insanlar geç kalırsa veya gerçekleştiremezlerse, kod devam etmez. Buna karşılık, bir araba yapmak istiyorsanız, lastik, şasi, akü, motor vb. Montajı için farklı insanları işe alabilirsiniz. Nesneye yönelik ve mevcut çerçeveler bunu mümkün kılar, ancak her şeyi sıfırdan tasarlarken pratik olmayabilir.

Hatalara yazılımda izin verilebilir . Test pahalı olabilir. Yazılımda, bir çökmeyi düzeltebileceğiniz zaman, tüm bu testleri atlamak çok caziptir. Çoğu mühendislik türünde, bir 'çarpışma' ölümcül olabilir.

Aşırı programlama (gerçekte yazılım megaprojects'inde kullanılan) gibi kapsamlı testler kullanan programlama yöntemleriniz var . Ancak, son tarihler (bilerek daha sıkı hale getirilebilir), tüm bu programlamayı atlamak ve böceklerle başlatmak cazip geliyor. Joel Spolsky "her zaman tüm hata tespit" tarzı uzun vadede daha fazla zaman harcamak zorunda kalmadan disiplinsiz bu atlayıp başarısız olur.

Küçük projeler daha iyi . Karım bir keresinde büyük bir şirkette iş bulmamı istedi. Büyük şirketlerin kötü şirketler olduğu ... ... onun için büyük bir şirketin çok kaynağı, tecrübesi, fonksiyonel proje yönetimi ve doğru prosedürleri olduğu iddiasıyla sonuçlandı. Bana göre, büyük bir şirket, zamanınızın çoğunun kod düzeltme, test etme ve dokümantasyon için harcandığı bir dinozor.

10 milyondan az insanın çalıştığı milyon dolarlık BT projelerini gördüm. Daha fazla insan projeyi yavaşlatır ve gereksiz bürokrasiyi eklerdi. WhatsApp milyarlarca dolar değerinde 'küçük' bir projenin örneği. Büyük projeler mümkün değildir, ancak yazılıma değecek milyarlarca dolar üretmek için binlerce insana ihtiyacınız yoktur.


0

Diğer sorularda gerçekten kapsanmayan sebeplerden biri, yazılım alanının yalnızca materyal tabanlı dünyada nadiren meydana gelen bir hızda yenilik yapmasıdır.

Bunun bir nedeni, yazılımın gelişmesinde pozitif bir geri besleme döngüsü olmasıdır; çünkü yazılım (yazılım programlama dilleri, yapım araçları, IDE'ler) yazılım oluşturmak için kullanılır. Bu, Ray Kurzweil'in ivme kazanma hızındaki ilerleme ile sonuçlanan ivme kazanma yasası için en açık örnek . Bir çerçeveyi, programlama dilini, iletişim protokolünü yönettiğinizde , bir sonrakine geçmenin zamanı gelmiştir .

Uçaklar yazılım gibi inşa edildiyse, malzemeyi diğer modellerle değiştiriyor, kapasitelerini ve hızlarını her 18 ayda bir değiştiriyor, her yeni model için motor teknolojisini yeni keşfedilmiş bir şeyle değiştiriyor, aynı zamanda yüzmeye ve dünya dışı bir deniz kabiliyetine bakıyor hayat.

Oh, ve ideal olarak ses komutlarını dinler ve iş geziniz bittiğinde tamamen sürükleyici bir sinema, paintball arena ve karanlık odalı gece kulübü olarak ikiye katlar. Aynı şey! (Sizi A'dan B'ye güvenilir bir şekilde getiren uçaklar yapan şirket, sinema salonu, paintball ve gece kulübü özelliğiyle çıktıktan bir yıl sonra ortaya çıktı.)


Amacını anlamıyorum. İlk olarak, birçok dil oldukça eski. Java yirmi yıldan daha eski. Python neredeyse otuz yaşında. Evet, yeni diller var, ancak her iki yılda bir yeni bir dilde yer almak için bir dili terk etmiyoruz. Yeni bir çerçeve benimsemekle birlikte, IDE veya dil bir ekip için bir yavaşlama faktörü olabilirken, tanıdık araçları kullananları özellikle hızlı bulmuyorum. Ve uçak endüstrisi? Boeing 787 gibi uçakların uygulanması zor olan birçok yeni şey var.
Arseni Mourzenko,

@ArseniMourzenko Peki, Java çıktığında web istemcisi programlama için sıcaktı ve salıncak çıktığında GUI inşası için sıcaktı, ancak her ikisi de sadece birkaç yıl sürdü. Heck, 1990'lardan önce WWW yoktu. Web programlama, uçakların 1910'da bulundukları yerdeydi. Ancak bu hız devam ediyor.
Peter A. Schneider

-1

Benim için yazılım mühendisliğinin karşılaştığı asıl sorun kullanım alanları, kullanıcı ve çapraz platformlar.

Davaları kullanın

Bir uçağın kaç tane kullanım durumu var? Çoğu, sadece bir yerden diğerine uçmak. Belki radar, trafik kontrolü vb. Gibi daha pek çok şey vardır, ancak kullanım durumu açık ve çok fazla değildir. Yazılım mühendisliğinde belirsiz gereksinimleri ve ne istediklerini bilmeyen kullanıcılarla karşı karşıyayız. Farklı kullanıcı farklı konfigürasyon / akışa ihtiyaç duyar, uçak istediği şekilde özelleştirilebilir mi (televizyon ve buzdolabı istiyorum!)?

kullanıcı

Uçağı kim işletiyor? Bir pilot, bir yardımcı pilot, bazı görevliler (sayılırsa) ve kule operatörleri. Hepsi profesyoneldir ve görev tanımları açıktır. Yazılım, diğer bilgisayarlarla ( OpenID veya Google AdSense gibi ) bütünleştirilebilir olması gerekirken, kötü niyetli bilgisayar korsanları ve krakerlerinden bahsetmeksizin noobs ve aptallar tarafından kullanılır . Bir uçak hala füzelerden veya ninja soyguncularından hayatta kalırken aptallar tarafından çalıştırılabilirse, uçağın yazılımla aynı kalitede olduğunu söyleyebilirsiniz.

Çapraz platformlar

Bir uçak sadece dünyanın gökyüzünde uçar. Sisli veya rüzgarlı ya da sıcak, soğuk ve nemli iklimi nasıl kullandıklarından emin değilim, ancak bir uçak farklı çekim seviyesinde uçacak şekilde tasarlanmamıştır ( Mars'a uçabilirse hayret edeceğim ). Bazen bir uygulama, Internet Explorer, Google Chrome , tarayıcı için Firefox ve Safari (üzgünüm Opera ) veya Windows XP / 7/8 veya işletim sistemi için Linux gibi farklı platformlarda hayatta kalmalıdır . Mobil cihazlardan ve farklı çözünürlük ve yönlerden bahsetmiyorum.


-1

Diğer endüstrilerin olaysız bir şekilde projeleri tamamladığını düşünüyorsanız, 1977'de inşa edilen Citigroup Center binası hakkındaki hikayeyi okumalısınız. Her 16 yılda bir fırtına olayı bekleniyor.

Başka bir deyişle, her yıl Citicorp Merkezi ayakta duruyordu, 16'sı bir arada çöküşe geçme şansı vardı.

Orijinal tasarımcılar sorunların farkında değildi, ama neyse ki binada okuyan bir öğrenci tarafından yakalandı.

her şey yolunda görünüyordu - LeMessurier'in söylediği gibi bir telefon aldı. LeMessurier'e göre, 1978'de bir lisans mimarisi öğrencisi, LeMessurier'in binası hakkında cesur bir iddia ile temasa geçti: Citicorp Center'ın rüzgarda havaya uçabileceği.

Tasarım kusurunun gizliliğini korumak için en az sayıda insanın yer aldığı gece kapsamında tam anlamıyla tamirat yapıldı.

Binayı çevreleyen 10 blok yarıçapı için acil durum tahliye planı hazırlandı.

Gece boyunca kaynak yapmışlar ve bina sakinleri işe döndüklerinde şafakta bırakmışlar.

Hikaye, yazar Joe Morgenstern'in bir partide söylendiğini duyana ve LeMessurier ile röportaj yapmasına kadar bir sır olarak kaldı. Morgenstern, 1995 yılında The New Yorker'da hikayeyi kırdı.

Hangi soruyu gündeme getiriyor; Projelerdeki diğer birçok ölümcül tasarım kusurunun, kamuoyu onayı olmadan gizlice onarıldığı veya göz ardı edildiği.

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.