İmalat ve Yazılım Geliştirme [kapalı]


10

Genellikle yazılım endüstrisinin üretime kıyasla olgunlaşmamış olduğu söylenir. Özellikle işleme dayalı olma konusunda.

Soru : Geliştiriciler olarak imalat sanayinin süreçlerinden öğrenebilir miyiz? Süreçlerini benimsemek yazılım geliştirme başarısını artırabilir mi?

Benim düşüncem : Üretimde bir ürünün yaratılması büyük ölçüde süreç odaklı. Her insanın takip ettikleri belirli bir görev kümesine sahip olduğu bir fabrikanız olabilir. Bir işçi (veya robot) bir vidayı gün boyunca sıkabilir. Ardından süreçteki bir sonraki görev bir sonraki uzman tarafından gerçekleştirilir. İşçiler (ve robotlar) süreçten caydırmaz veya "anında" bir şey uydurmaz. Parçalar süreç boyunca çalkalanır ve çıktı bitmiş bir üründür. İyi çalışıyor ve şirketler% 99.99966 hatasız ürün elde ediyor. Şirketler zaman içinde verimsizlikleri ortadan kaldırıyor. Bu etkileyici ve olgun bir endüstrinin işareti olabilir.

Üretimde tanımlı bir süreç, kelimenin tam anlamıyla bitmiş ürünü yaratabilir. Yazılımda böyle olduğunu sanmıyorum. Kaynak kontrolü, kod inceleme, check-in sayfaları, gereksinim toplama, SDLC vb. Süreçlerimiz olabilir. Ancak bu süreçlerin yürütülmesi kendi başına bitmiş bir ürün oluşturmaz. Bu süreçler faydalı olabilir, ancak gerçek yaratılış ile diktir.

Şirketinizin, bir suçlunun yüzlerini bulmak için milyonlarca resim arayacak yazılım oluşturmak için sözleşmeli olduğunu varsayalım. Süreç odaklı ağır ortama rağmen, geliştirici bir şeyler yaratmaya çalışmalıdır. İşleri anında yapmak üretim ruhuna aykırıdır. Bir robot düşünmeden iyi bir üretim süreci gerçekleştirilebilir.

Henüz bir insanın zihninde küflenmemiş olan karmaşık algoritmaların yaratılması için, olayları anında yaratmak bir zorunluluktur. Yazılım geliştirme bir sürecin takip edilmesi değil, bir bilgisayar tarafından gerçekleştirilecek süreçlerin oluşturulmasıdır. Bu temel bir fark. Gelişimin etrafında ne kadar dik süreç oluşturursak olalım, yaratılış söz konusu olduğunda her zaman “anında” yapmaya başlayacağız.

Konuştuğum herkes üretim zihniyeti ile aynı fikirde. Düşüncelerimde yalnız mıyım?


1
FYI: Bu soruyu sormam için beni motive eden şey bir CMMI kitabıydı. Yazılım oluşturmayı üretimle karşılaştırdı ve Soft.Ind'yi sonuçlandırdı. olgunlaşmamıştı.
Lord Tydus

3
Aynı alanda daha doğru bir benzetmenin, fabrikanızı tasarlamak ve kurmakla ilgili mühendislik olacağını söyleyebilirim. Yaratıcı / zor bitler burada gerçekleşir. Gerisi sadece somun ve civata, tıpkı bizim için geri kalanı sadece 1s ve 0s.
Benjol

1
Yazılım mühendisliği üretim ile karşılaştırılamaz. Zanaatkarlık ile karşılaştırılır. Bu endüstriyel bir sürece indirgenemez.
mouviciel

1
Yazılım geliştirme olarak adlandırılmasının bir nedeni vardır . Yazılım üretimi değil . Ürün geliştirmeye karşı ürün geliştirmeyi düşünün.
tehnyit

Japonlar bunu denemedi: fiziksel malların üretimine daha uygun bir süreçte yazılım oluşturmak için? Hatırladığım kadarıyla, elbette Japonya tarafından geliştirilen bazı başarılı yazılım başlıkları olmasına rağmen, oldukça yaygın ve eksiksiz bir hata olarak kabul edilir ( bir örnek için Sonic the Hedgehog'u deneyin ).
CVn

Yanıtlar:


36

Yazılım geliştirme ve üretim arasındaki temel fark, yazılım için tasarım aşamasının pratikte her şey olmasıdır. Gerçek üretim (geleneksel imalatta montaj hattı parçası), birkaç dosyayı kopyalamak meselesidir. Yazılımında, ürün tasarım olan ürün.

Yani evet, üretim süreçlerinden öğrenebiliriz, ancak sadece üretim aşamasına değil, tasarım aşamasına bakmamız gerektiğini ve birçok üretim sürecinin pahalı bir üretim zincirinin belirli sınırlamalarıyla başa çıkmak için inşa edildiğini aklımızda tutarsak yazılım için geçerli değildir.

Yazılımda çok iyi çalışan, ancak genellikle ürün tasarımında korkunç bir şekilde başarısız olan bir süreç modeline örnek olarak, yinelemeli tasarım verilebilir - minimal bir prototiple başlarsınız ve her yinelemeyle özellikler eklersiniz. Yeni arka cam düğmesi tasarımının neye benzediğini görmek için bir prototip araba yapmak saçma, ancak yazılımda mantıklı (sadece F5'e basın ve birkaç saniye bekleyin - voilà, sürüşü test etmeye hazır).

Ürün tasarım süreçlerine bakarsak, bakmak için en iyi endüstriler iki kategoriye ayrılır:

  • üretimin emtia oranlarında gerçekleştirilebildiği; örneğin, kayıt endüstrisi (bir CD için fiyatın% 1'i veya daha azı pişirme ve yazdırmadır), grafik ortamı vb.
  • miktarların o kadar düşük olduğu tasarım aşaması en önemli maliyet faktörüdür (lüks ürünler, son derece özelleştirilmiş ürünler, niş pazarlar ...)

Fiziksel üretimden yazılım geliştirmeye kadar olan süreçleri denemek ve uygulamak temel bir hatadır: yazılım geliştirme tekrarlayıcı değildir (işinizde, başka bir iş bulun), sadece kısmen tahmin edilebilir, sadece çok az fiziksel sınırlama vardır ( donanım hızı birdir) ve hem alınan yaklaşım hem de sonuçlar son derece kişisel olabilir. Montaj çizgisi felsefelerini temelde analitik ve yaratıcı düşünme meselesine uygulamak yıkıcı etkilere neden olabilir (ve çoğu zaman).


2
Mükemmel cevap. Yazılım geliştirmede her şey bir prototiptir!
James Anderson

1
Bu iyi bir nokta, ama bence tasarım boyutu abartılı. "Yazılımın maliyetinin% 60'ı bakımdır" ve "bir yazılım projesinin son% 10'u programın% 10'undan çok daha fazla zaman alıyor" gibi, atılan sayıları duyarsınız. Sayılar buradaki fikir kadar önemli değil ve tasarım tamamlandıktan sonra hem bakım hem de parlatma gerçekleşiyor. Tasarım şüphesiz ürünün önemli bir yönüdür, ancak tartışmasız en kolay ve en ucuz kısımdır.
Caleb

3
@Caleb: Bakım, özellikle iyi tasarlanmış bir ürün için, çoğunlukla mevcut üründeki hataları düzeltmekle ilgili değil, özellik ekleme, başka bir deyişle tasarımı ekleme ve değiştirme ile ilgilidir.
Marjan Venema

@Caleb - bu muhtemelen bir üretim hattı ve üretim süreçleri kurmak için geçerlidir. Üretim hattının kurulması, üretim sürecinin en pahalı ve zaman alıcı yönlerinden biridir.
James Anderson

2
@Caleb: Bence burada benzetimimi yanlış anladınız. 'Tasarım' hakkında konuşurken, ürün tasarımından, yani montaj hattının başlamasından önceki süreçten bahsediyorum. Bir yazılım ürününün hem tasarım hem de uygulama aşamaları bu anlamda 'tasarım' iken, üretim kısmı bir sunucuya ikili dosyalar yüklemeye veya nakliye için DVD-ROM'lara indirgenmeye indirgenmiştir. Bir programcı olarak, tüm sunduğunuz bir prototiptir; bakım işleri de dahil olmak üzere yaptığınız her şey geleneksel üretim zinciri benzetmesinde 'tasarım'.
tdammers

10

Aynı yazılımı tekrar tekrar yazmak istiyorsanız (sadece kopyalamak yerine) bunu bir montaj hattı üzerinden çok verimli bir şekilde yapabilirsiniz.

Ancak yazılım oluşturma repetatif bir görev değildir, her modül benzersizdir. Bu nedenle imalat karşılaştırması geçersizdir.


Üretimden ders almak, bir yazılım montaj hattı oluşturmak anlamına gelmez. Üretim, süreç iyileştirme hakkında söylenecek çok şey var ve yazılım geliştirme sürecinde iyileştirmeye dayanabilecek çok şey var.
Caleb

@Caleb: O zaman ne dersiniz? Tam olarak bunu kastettiğini düşündüm.
sevenseacat

1
@Karpie, aynı olmayan şeyler üretirken bile süreç iyileştirme olabilir. Bu ay kaç hata yazdık? Geçen ay? İki ay önce? Bu sayı bir aydan diğerine önemli ölçüde değişirse, nedenini bulmalısınız. İster bir montaj hattında özdeş widget'lar üretiyor olun, isterse son derece yaratıcı bir süreçte uzun metrajlı filmler üretiyor olun, bu herhangi bir işlem için işe yarayan bir şeydir.
Caleb

2

Aradığınız cevabın burada geçerli veya gerçekçi olduğunu düşünüyorum. Bilmek istediğiniz gibi hissettiğim şey, süreçlerimizi daha çok imalat sanayii gibi ayarlayabilmemiz. Bunun yerine asıl sorunun "Kaliteli ürünler üretmek için hangi endüstrinin ve diğer endüstrilerin ne yaptığını bilmek" ne öğrenebiliriz? veya "Yazılım endüstrisi kaliteyi artırmak için ne yapabilir?"

Maalesef bunun cevabı belirsiz çünkü yazılım endüstrisinin kendisi hala cevabı bilmiyor. Buna cevap verebilmek için yazılım endüstrisinin neyin işe yaradığını ve nedenini araştırması gerekiyor? Örneğin, Test Sürüşü Tasarımının (TDD) kalitenin iyileşmesine yol açtığını gösteren çalışmalar vardır. Her ne kadar verimlilik sorunu hala cevaplanmamış gibi görünüyor veya en azından henüz tam olarak anlaşılmamış gibi görünüyor. Kanıt şu ana kadar gösterdiği gibi:

  • Kod incelemeleri mükemmeldir ve en çok hatayı bulmak için gösterilmiştir, ancak bir incelemenin etkinliği, incelemenin ilk saatinden sonra oldukça keskin bir şekilde düşer. Ortalama bir insanın saatte sadece birkaç yüz satır kod okuyabileceği göz önüne alındığında, geliştiricilerin değişiklikleri daha küçük parçalara ayırması gerektiğini gösterir.
  • Bir hatayı bulmak ne kadar uzun sürerse onu düzeltmek o kadar pahalı olacaktır (zaman ve para). Yani bir geliştirici kodu yazarken bulursa maliyet 1 diyoruz. Bir unittest daha sonra bulursa maliyet 10, EVT bulursa maliyet 100'dür.
  • Gereksinimlerin ne kadar karmaşık olduğunu, çözümün ne kadar karmaşık olduğunu ve çözüm ne kadar karmaşık olduğunu gösteren hataların o kadar olası olduğunu gösteren bazı kanıtlar vardır.

Birkaç yıl önce bunlardan bazıları hakkında mükemmel bir konuşma yapan Greg Wilson adında bir adam var. İşte konuşmaya bir bağlantı: Greg Wilson Talk

Buna ek olarak, kendi çalışmalarınıza tekrar bakın ve tanıttığınız hata türlerinin yanı sıra hangi parçalarla mücadele ettiğinizle ilgili temaları bulun diyebilirim. Bu sonuçları derleyin ve daha iyi bir iş yapmanıza yardımcı olmak için farklı yerlerde işleminize eklemek için bir kontrol listesi oluşturun. Şahsen çalışmamın son birkaç yılına baktım ve ortaya koyduğum sorunların bazı ortak temaları olduğunu gördüm. Özellikle şunu buldum

  • Yapıyı kırmama neden olan tüm varyantları yapmayı sık sık hatırlamıyorum.
  • Birçok kez her değişiklik için aşağıdakileri düşünmüyorum. İyi durum, kötü durum ve istisnai durumlar.
  • Olabilecek tüm olası senaryolar. Bunun gerçekten zor olduğunu unutmayın, çünkü birçoğu var.

Hatalarıma bazı temalar bulduğumdan, komut dosyalarıma eklediğim için otomatik olarak kullandığım ve bu sorunları çözmeme yardımcı olan kontrol listeleri oluşturdum. Bu çağrı hakkında yazılmış ve nasıl iyi bir şekilde kullanılabileceklerini anlatan bir kitap vardı. Şahsen ben çok anlayışlı buldum.


2

"Onların" süreçlerini benimsemekle ilgili değil. Bu, yaratıcı çabalar için montaj hattı süreçlerini kullanmanın olağan ve iyi takdir edilen zararlarına sahip olmayan "bazı" süreçleri benimsemekle ilgilidir. Burada dikkat edilmesi gereken en önemli şey, süreçlerin kalitesinin doğrudan ürünün kalitesine dönüştüğü fikridir.

Bu konudaki en iyi süreçler veya ürünler, eldivenli bir el gibi amaçlanan kullanım senaryosuna uyan süreçlerdir. Düşünülmesi gereken şey, gerçek kod yazma kısmının, en azından makroskopik düzeyde, tekrarlayıcı olmayan tek parça ile ilgili olmasıdır. Sürüm kontrolü, hata izleme, planlama, tahminler, ölçümler vb. Gibi diğer tüm yönler ve standart, uyarlanmış ve kanıtlanmış bir sürecin kullanımı en azından bu alanlarda size yardımcı olabilir.

Bu nedenle hayır, yazılım geliştirme süreci montaj hattı üretimine benzeyemez ve bu nedenle "süreçleri" iyi değildir, ancak bir imalat endüstrisindeki ürünün üretim tasarımı / ürün tasarım aşaması ilham almak için olabilir.


1

Soru: Geliştiriciler olarak imalat sanayinin süreçlerinden öğrenebilir miyiz? Süreçlerini benimsemek yazılım geliştirmenin başarı oranını artırabilir mi?

Cevap: Evet, elbette. Yazılım geliştirmenin yaratıcı bir süreç olmasına rağmen, yazılım geliştiricilerinin üretimden öğrenebilecekleri pek çok ders vardır. Yazılım geliştirmenin kendisi bir süreçtir ve diğer birçok işlemi içerir. Bu süreçleri ne kadar iyi tanımlayabilir ve kontrol ederseniz, genel olarak yazılım geliştirme sürecini o kadar iyi kontrol edebilirsiniz. Bu, bir geliştiricinin yaptığı her tuş vuruşunu reçete etmeniz gerektiği anlamına gelmez; sadece bir geliştirici olarak görevleri doğal olarak belirli bir sırayla gerçekleştirdiğiniz ve bu görevlerin sıklıkla yönetilebileceği anlamına gelir. İşte bazı örnekler:

  • hata izleme: Bir hata gözlemlendiğinde veya rapor edildiğinde buna ne olur? Bir kağıt parçasına yazar ve bir 'araştır' sivri ucuna yapıştırır mısın? Daha sonra bu notları birer birer kaldırıyor, araştırıyor ve sonunda 'çözülmüş' başaklara mı taşıyorsunuz? Bunu bir hata raporu aldığınızda başarısız bir şekilde yaparsanız, iyi tanımlanmış, ölçülebilir bir işleminiz vardır ve muhtemelen çok zahmetli olan fantezi, yüksek teknoloji ürünü bir kusur izleme sistemine sahip olandan çok daha iyisinizdir. bazı ekip üyelerinin hataları başka yollarla izleyip izlemediğini.

  • sürüm kontrolü: Çalıştığınız yerde sürüm kontrolünü kullanma şansınız yüksektir ve sürüm kontrolü herkes aynı şekilde kullandığında çok daha yararlıdır.

  • ürün tasarımı: Post-it notlarla kaplı bir duvara dart atarak hangi özelliklerin uygulanacağına karar verir misiniz? Eğer öyleyse, bir sürecin var. Kimsenin bunun harika bir süreç olduğunu iddia edeceğini sanmıyorum, ama en azından bir başlangıç ​​noktası. Süreci değiştirirseniz, önce ve sonra ölçüm yapmadıkça değişikliğinizin gerçekten bir iyileşme olduğunu nasıl anlarsınız? Yapamazsın.

  • kod incelemeleri: Her inceleme için inceleme süreci ve kodlama ölçütleri değişirse bir kod incelemesi yararlı olur mu? Tabii ki değil.

  • yazılım geliştirme yaşam döngüsü: Tüm analiz -> tasarım -> uygulama -> test -> bakım döngüsü açıkça tanımlanması gereken bir süreçtir.

Bu durumların her birinde, bir işlemin gerçekleştirilmesi girdi ve çıktıları ölçmenizi ve yaptığınız değişikliklerin amaçlanan etkiye sahip olup olmadığını belirlemenizi sağlar. Süreçlerin yerinde olmaması, çalışma şeklinizi geliştirmeye çalıştığınızda sadece tahmin ettiğiniz anlamına gelir. Üretimin hepsi budur ve sadece uygun olduklarında ardışık üretim araçlarını ödünç almak mantıklıdır.

Yazılım oluşturmak ve sürdürmek için kullanılan süreçleri tanımlamak ve geliştirmek için ayrılmış bir alan vardır; buna yazılım mühendisliği denir . CMMI hakkında okurken geliştirme süreci hakkında sorularınız olması şaşırtıcı değildir - CMMI, Yazılım Mühendisliği Enstitüsü'nün bir ürünüdür .

Yazılım geliştirme zaten birçok üretim konseptini benimsemiştir:

  • Eli Whitney'in değiştirilebilir parçalarının hem OOP hem de bileşen tabanlı geliştirme üzerindeki etkisini görmek zor .

  • Yazılım geliştirmede kullanılan proje yönetimi teknikleri, üretim için geliştirilenlerden çok farklı değildir. Sadece iki örnek olarak, yazılım dünyası son zamanlarda Toyota'da geliştirilen Kanban konseptini benimsedi ve Gantt grafikleri ilk elektronik bilgisayar üretilmeden çok önce üretimde kullanıldı.

  • İmalat için geliştirilen Six Sigma gibi kalite yönetimi metodolojileri yazılım geliştirmeye uyarlanmıştır.

Süreç odaklı ağır ortama rağmen, geliştirici bir şeyler yaratmaya çalışmalıdır.

Bana birisinin yüz tanıma paketine bir yama eklemek için kendi başına karar vereceğini mi söylüyorsunuz ve tasarımı inceleyerek, izleme sisteminde bir sorun yaratmadan bunu üretim yapısına ekleyecekler mi, kodu sürüm kontrolüne kontrol etmek mi yoksa test arkadaşlarına önce bakmak mı? Sürecimiz bu şeyleri çok iyi nedenlerle gerektirir. Eğer "anında" demek "sürecin dışında" demekse, bu kabul edilemez.

İşleri anında yapmak üretim ruhuna aykırıdır.

Yine, "anında", "sürecin dışında" anlamına gelirse haklısınız. Ancak, üretimin hızlı düşünmeyi ve sorunlara yaratıcı çözümler geliştirmeyi gerektirmediğini düşünüyorsanız yanılıyorsunuz. Üretim sürecinde her türlü sorun ortaya çıkıyor - cupcakes yeterli krem ​​dolgusu yok, boyalı yüzeyler aniden QA'nın çizilme testini geçmeyi bırakıyor, bitmiş parçaların% 20'si önemli bir tutma halkası eksik, hamur karıştırma sistemi kırıldı kritik parça...


+1. Tam olarak düşüncelerim. Ama korkarım, bu popüler bir yanıt olmayabilir, çünkü olgunlaşmamış bir yazılım mühendisliği durumunda, kovboy kodlama yapılır. CMMI içinde bile, L1'de, kahramanlara tanrı olarak ibadet edilir.
Vaibhav Garg

@Vaibhav Garg: İnanıyorum ki uzun vadede, içinde, en iyi sonucu verir sürecinde iş anlamında , kazanır. Kontrollü "yazılım mühendisliği süreci" daha yüksek kalite * hız / maliyet oranıyla sonuçlanırsa kazanır. Bazen kovboy kodlama rahatsız edici derecede iyi sonuçlara yol açıyor gibi görünüyor.
Joonas Pulakka

1
@JoonasPulakka. Katılıyorum, bazen kovboy kodlamanın iyi sonuçlar verdiği görülüyor. Ama buradaki anahtar "bazen" dir. Performansta tekrarlanabilirliği hedefliyorsanız, yaptığınız işte tekrarlanabilir olmanız gerekir. SIPOC'deki P'yi düşünün!
Vaibhav Garg

1
@ JoonasPulakka- 1. seviye organizasyonlar için CMMI Standardından kelimelerin alıntılanması: Bu kuruluşlardaki başarılar, kanıtlanmış süreçlerin kullanımına değil, organizasyondaki kişilerin yeterliliğine ve kahramanlıklarına bağlıdır. Bu kargaşaya rağmen, olgunluk seviyesi 1 örgütleri genellikle çalışan ürün ve hizmetler üretir; ancak, bütçelerini sık sık aşarlar ve programlarını karşılamazlar.
Vaibhav Garg

2
"Bu organizasyonlardaki başarı ... insanların yeterliliğine bağlıdır" Hiçbir sürecin bunu değiştirebileceğini sanmıyorum.
kevin cline
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.