Tuesday, January 25th, 2022

Yazılım Mühendisliği Neden Diğer Mühendislik Disiplinleri Gibi Değildir ve Oyunu Nasıl Değiştirir?

2014 itibariyle dünya çapında 11 milyondan fazla profesyonel yazılım geliştiricisi olduğu tahmin ediliyor. 1973’te programcı olarak başladığımda, çalıştığım ilk şirketteki gri sakallılardan biri bana bazı tavsiyelerde bulundu. “Hiç değişmeyen şeyleri öğrenin” dedi.

Altı yıl önce 1967’de üniversiteye başladığımda, gittiğim okulda Bilgisayar Bilimi adında bir anadal yoktu ve bu yüzden lisans ve lisansüstü çalışmalarımı Matematik alanında birkaç bilgisayar programlama dersi alarak yaptım. Bu, çoğumuzun 70’lerde yazılım geliştiricileri olarak başlama şeklimizdi.

Yazılım Mühendisliği terimi o zamanlar yeniydi ve 1968 NATO Yazılım Mühendisliği Konferansı’nda ortaya çıktı. O zamanki düşünce, o sırada “yazılım krizi” olarak adlandırılan ortak bütçe, zamanlama ve kalite sorunlarını ele almak için mevcut mühendislik yöntemlerini yazılım geliştirmeye uygulamamız gerektiğiydi. Sonuç olarak, çoğu insanın Yazılım Mühendisliği olarak düşünmeye başladığı şey, inşaat, mekanik ve elektrik mühendisliği dahil olmak üzere diğer mühendislik disiplinlerine büyük ölçüde benzeyen faaliyetleri içerir.

Yüzeyde bu fikir mantıklı görünüyor. Diğer mühendislik disiplinlerini (örneğin bir köprü, bir bina, özel bir donanım parçası, bir elektrik devre kartı) kullanarak bir şey inşa ettiğinizde, gereksinimleri belirlemeniz, bir çözüm tasarlamanız, uygulamanız ve test etmeniz gerekir. Bu adımların tümü yazılım için de anlamlıdır. Dolayısıyla, bu perspektiften, yazılım mühendisliğinin bu diğer mühendislik disiplinlerine benzemesi gerektiği kesinlikle tartışılabilir. Ancak, son kırk yılda yazılım geliştirme hakkında öğrendiklerimize ve günümüzün yazılım geliştiricilerine nasıl öğrettiğimize daha yakından baktığınızda, bu benzetme hızla bozulur.

1990’larda bilgisayar programlama, Bilgisayar Bilimi denilen şeyin çok büyük bir parçası haline geldiğinden, birçok Üniversite Bilgisayar Bilimleri müfredatlarına “Yazılım Mühendisliği” başlıklı bir ders eklemişti. O zamanlar bu dersleri vermek için kullanılan popüler ders kitapları arasında Ian Sommerville’in “Yazılım Mühendisliği” adlı ders kitabı da vardı. 1992’den 1994’e kadar Binghamton Üniversitesi’nde Yazılım Mühendisliği öğretmek için bu ders kitabının Dördüncü Baskısını kullandım. Bugün, Ian Sommerville’in ders kitabı dünya çapında birçok Üniversitede hala kullanılmaktadır – şu anda Dokuzuncu Baskısındadır. Bu bir soruya yol açar:

Öğrencilerimize Yazılım Mühendisliğinin temellerini öğrettiği varsayılan bir ders kitabını neden yaklaşık 3-4 yılda bir revize etmemiz gerekiyor?

İnşaat Mühendisliği, Makine Mühendisliği ve Elektrik Mühendisliğinde kullanılan ders kitaplarına bakarsanız, bu kitapların büyük çoğunluğu neredeyse sık sık revizyon gerektirmez. Bunun neden böyle olduğunu anlamak için dünyadaki çoğu Üniversitede “Yazılım Mühendisliği” adı altında öğretilenlere daha yakından bakmamız gerekiyor.

Daha yakından baktığınızda, yazılım uygulamaları ve yöntemleri açısından şu anda popüler olan her şeyi yeni nesil yazılım profesyonellerimize öğrettiğimizi göreceksiniz. Günümüzde popüler yazılım uygulamaları ve yöntemleri Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP gibi moda sözcüklerle biliniyor ve liste uzayıp gidiyor…

Yazılım Mühendisliği öğretimine yönelik bu yaklaşımla ilgili sorun, yazılım uygulamalarının ve yöntemlerinin sıklıkla gelip gitmesi ve gelip gitmeye devam etmesidir, bu nedenle Sommerville’in ders kitabını sürekli olarak güncellemesi gerekir. Bu başka bir soruya yol açar:

1973’te çalıştığım ilk şirkette bana asla değişmeyecek şeyleri öğrenmemi söyleyen o boz sakala ne demeli? Bana kötü tavsiye mi verdi? Değilse, Yazılım Mühendisliği ile ilgili asla değişmeyen şeyler konusunda yeni nesil yazılım profesyonellerimize ne öğretiyoruz?

Bu soruları cevaplamadan önce, bir adım geriye gidelim ve birkaç farklı soru soralım:

Yazılım Mühendisliğinde asla değişmeyen bir takım şeyler gerçekten var mı?

Eğer varlarsa, ne olduklarını biliyor muyuz?

Bunların ne olduğunu biliyorsak, gelecek nesil yazılım profesyonellerimize tutarlı bir şekilde öğretiyor muyuz ki Üniversiteden çıktıklarında kendilerini yazılım profesyonelleri olarak yönetmeye hazır olsunlar mı?

Böyle bir dizi yazılım mühendisliği esası aslında var. Bu inanç, uluslararası bir gönüllü grubunu bu esasları kodlama görevini üstlenmeye motive etti. Amaç, bu temel bilgilerin gelecek nesil yazılım geliştiricilerimize öğretilmesi ve onları gerçek yazılım uzmanları olarak hazırlamalarına yardımcı olmaktır.

Bu girişime dahil olan gönüllüler (SEMAT – Yazılım Mühendisliği Yöntemi ve Teorisi olarak bilinir) 2010 yılından beri bu görev üzerinde çalışıyorlar. Geçtiğimiz yıl SEMAT, uluslararası standartlar konsorsiyumu olan Object Management Group’un bu projede yer aldıklarını duyurmasıyla önemli bir dönüm noktasına ulaştı. “Essence”ı resmi bir OMG standardı olarak benimsemiştir.

Yani bu birkaç soruya daha yol açar:

Essence standardı, bugün yazılım geliştiricilerimize öğretilenden ve son 40 yıldır Yazılım Mühendisliği adı altında öğretilenden ne kadar farklı?

Ve:

Farklılıklar, ortak bütçe, zamanlama fazlalıkları ve düşük yazılım kalitesi açısından yazılım endüstrisini hâlâ rahatsız ettiğine inandığı sorunlara gerçekten yardımcı olacak mı?

Bir açıdan Essence’ın yakaladığı şey yeni değil. Essence standardı, Paydaşlar, Fırsat, Gereksinimler, Yazılım Sistemi, Takım, İş ve Çalışma Şekli gibi ortak kelimeleri içerir. Ancak başka bir perspektiften Essence’ın yakaladığı şey çarpıcı biçimde yeni. Aslında, bazıları buna “eski muhafızların” çoğunun anlamakta bile büyük zorluk çekeceği bir “paradigma kayması” diyor.

Essence’ı kullanırken meydana gelen değişiklikler hakkında size bir fikir vermek için tekrar 1970’lerin sonlarında bir programcı olarak ilk günlerimi düşünüyorum. O günlerde, yüksek performanslı uçakları uçurmak için pilotları eğitmek için yazılım sistemleri geliştirmek için uçuş simülasyonu alanında çalıştım. Uzmanlık alanlarımdan biri, eğitmenlerin genç uçak pilotlarını uçuş becerileri konusunda eğitmelerine yardımcı olmak için kayıt/oynatma yetenekleri sağlamak için yazılım yazmaktı.

Üzerinde çalıştığım belirli bir projeyi ve birlikte çalıştığım bir müşteri pilot eğitmenini hatırlıyorum. Öğrenci pilotlarına nerede hata yaptıklarını göstermesine yardımcı olması için kayıt/oynatma yazılımımı nasıl kullanabileceğini ona açıkladıktan sonra, heyecanla yazılımımda değişiklik talep eden bir dizi kusur yazdı.

Program yöneticimle, bu sorunların hiçbirinin aslında kusur olmadığını şiddetle tartıştım. Kayıt/oynatma yazılımımla nelerin mümkün olduğunu açıklamak için zaman ayırdığım için pilot eğitmen işini kolaylaştırabilecek ek özellikler tasavvur etmeye başladı. Fikirlerini, hiçbir zaman teslim etmeyi planlamadığımız ve gereksinimlerin bir parçası olmayan gelişmiş yetenekler olmasına rağmen, bir kusur formuna yazdı.

Ancak proje yöneticim, bu isteklerin kapsam dahilinde mi yoksa kapsam dışı mı olduğunu müşteriyle tartışmak istemedi. Onun görüşü – o zamanlar ve bugün hala görüntülenen birçok yazılım gibi – yazılımı değiştirmenin müşteriyi bir tartışmaya dahil etmekten daha kolay olduğuydu.

Yazılım yumuşak olduğu için, onu değiştirilmesi kolay olarak görme eğilimindeyiz. Donanım gibi değil. Metal kolay bükülmez. Bu bakış açısı, yazılım söz konusu olduğunda tüm oyunu değiştirir.

Yazılım kodunu hızlı ve sonsuz bir şekilde değiştirme yeteneği, yazılım geliştiricileri ile program yöneticileri ve müşteriler de dahil olmak üzere paydaşları arasında var olan dinamikleri tamamen değiştirir. Bu farklılığın kendisini örneklendirmesinin bir yolu, kullanıcılar yazılıma aşina olduklarında, pilot eğitmen müşterimin 1970’lerin sonlarında yaptığı gibi, yazılımdaki değişikliklerin işlerini kolaylaştırabilecek yeni yollar görmeleridir.

Artık, etkin profesyonel yazılım mühendisliği uygulamaları için kritik olan Yazılım Mühendisliğinin başka boyutları olduğunu deneyimlerimizden biliyoruz. Bu diğer boyutlar bizi kodun değiştirilebileceği kolaylığın ötesine götürür. Bugüne kadar, bu ek boyutlar hak ettikleri ilginin yakınından bile geçmedi.

Kodu değiştirdiğinizde, gereksinimleri de etkiliyor olabilirsiniz ve ayrıca önceden test edilmiş yazılım sistemindeki diğer yetenekleri de etkiliyor olabilirsiniz. Kodun değiştirilmesi ek çalışma, ek testler, destekleyici kullanım kılavuzlarında olası değişiklikler vb. anlamına gelir… Tüm bunlar bütçeyi ve programı etkiler ve yazılımın kalitesine ek riskler getirir.

Bir yandan yazılım kodunu hızlı bir şekilde değiştirme yeteneği yazılım endüstrisine büyük güç getirirken, aynı zamanda yazılım profesyonellerinin üzerinde anlaşmaya varılan çalışma şekline, ek işleri yapmak için gereken etki ve zamana giderek daha fazla uyum sağlamaları gerektiği anlamına gelir. , ve planlanmamış hızlı değişiklikler yaparken risk. Son on yıldaki çevik hareket, paydaşlarla erken ve sürekli etkileşimin önemi ve yazılım geliştiricilerin kendi çalışmalarının maliyetini tahmin etmesinin önemi dahil olmak üzere, yazılım topluluğunun Yazılım Mühendisliği ile ilgili bu büyük farkı anlamasına yardımcı olmak için büyük bir hizmet sağlamıştır.

Yazılım mühendisliği topluluğu, diğer mühendislik disiplinlerinden çok şey öğrenmiş olsa da, önceki mühendislik deneyimlerinden farklılıklar getiren bu diğer boyutların kritik önemini de öğrenmiştir. Bu farklılıklar, yazılım geliştiricilerin etkili yazılım uzmanları olabilmeleri için yeni ve farklı şekillerde eğitilmeleri gerektiği anlamına gelir.

SEMAT girişiminin Mart 2010’da başlamasından kısa bir süre sonra, SEMAT’ın ilk imzacılarından biri, üzerinde çalışmakta olduğu bir kitabın taslağının bir kopyasını bana gönderdi. SEMAT çalışmasının başlarında çok aktif olmayı planlayan Watts Humphrey, SEMAT çalışması hazırlanırken hastalandı ve benden planladığı çabayı sürdürmesine yardım etmem istendi. Aynı yılın Ağustos ayının sonlarında Watts, vefatından sadece birkaç ay önce bana aşağıdaki e-postayı gönderdi. Bu e-postayı başkalarıyla paylaşabileceğimi kabul etti:

Paul, Yorumlarınızdan, müteşekkir olduğum kitabımın amacını anlamış gibisiniz…. yazılım uzmanları uygun şekilde eğitilir ve daha endüstriye girmeden önce uygun bir dizi profesyonel tutum ve beceriye sahiptir. Umuyorum ki SEMAT çabası, akademik topluluğun programlarını yazılım profesyonellerine profesyoneller gibi davranmayı ve kendilerini yönetmeyi öğretmeye yeniden odaklamalarını sağlamaya yönelik harekete öncülük edebilecektir.

Bunu yaptıklarında mezunları yönetimleri ile müzakere edebilecek ve daha üstün işler yapabilecekler… Profesyonellerin yapması gereken de bu… Bu yönde iyi bir başlangıç, onları yazılımcıya sahip olmanın gerekliliğine ikna etmek olacaktır. kendi işini ölç. Yazılım işi, dediğimiz gibi, bilgi işi olduğu için, gerçekten doğru olan her türlü önlem yazılım profesyonellerinin kendileri tarafından alınmalıdır. …Watt Humphrey

Watts Humphrey, yazılım kalitesinin babası olarak anılır. IBM’de seçkin bir kariyeri tamamladıktan sonra, Yazılım Süreci Programını kuran Yazılım Mühendisliği Enstitüsü’nün bir üyesi olmaya devam etti. 2003 yılında Ulusal Teknoloji Madalyası ile ödüllendirildi.

Bugün Watts, akademik camiada sürmekte olan SEMAT çalışmasıyla yüreklenmiş olurdu. Yeni Essence standardına dayalı ilk tam Üniversite kursu geliştirildi ve bu yıl Medellin, Columbia’daki Universidad Nacional de Columbia’da Dr. Carlos Zapata tarafından öğrencilere veriliyor ve Essence birinci ve ikinci yılda kullanılıyor İsveç’teki KTH Royal Institute of Technology’de Dr. Mira Kajko-Mattson’ın rehberliğinde yazılım mühendisliği kursları. Ayrıca Amerika Birleşik Devletleri’nde Carnegie-Mellon West’te Dr. Cecile Peraire tarafından öğrencilerle Essence saha çalışmaları yapılmıştır. SEMAT topluluğu için bir sonraki adım, Essence’in endüstriyel projelerde fiili kullanım ve ölçülen sonuçların vaka çalışmalarını yayınlayarak endüstride nasıl yardımcı olabileceğini göstermektir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir