Bilgisayar Mühendisliği

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

2014 yılı itibariyle dünya çapında 11 milyondan fazla profesyonel yazılım geliştiricisi olduğu tahmin edilmektedir. 1973’te programcı olarak başladığımda çalıştığım ilk şirkette greybeards biri bana bazı tavsiyelerde bulundular. “Hiç değişmemiş şeyleri öğren” dedi.

Altı yıl önce 1967’de üniversiteye başladığımda, katıldığım okulun Bilgisayar Bilimleri adında bir branşı yoktu ve bu yüzden matematik alanında lisans ve yüksek lisans eğitimimi yaptım. Bu şekilde çoğumuz geri 70’li yıllarda yazılım geliştiricileri olarak başladı.

Yazılım Mühendisliği terimi 1968 NATO Yazılım Mühendisliği Konferansı’nda yeniydi. O zamanki düşüncemiz, o dönemde “yazılım krizi” olarak anı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üşündüğü şey, inşaat, mekanik ve elektrik mühendisliği gibi 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 (örn. bir köprü, bina, özel bir donanım parçası, bir elektrik devrekartı) kullanarak bir şey oluşturduğunuzda gereksinimleri belirlemeniz, bir çözüm tasarlamanız, uygulamanız ve test etmeniz gerekir. Tüm bu adımlar yazılım için de anlamlıdır. Bu açıdan bakıldığında yazılım mühendisliğinin diğer mühendislik disiplinlerine benzemesi gerektiği söylenebilir. Ancak, son kırk yılda yazılım geliştirme hakkında öğrendiklerimizi ve bunu günümüzün yazılım geliştiricilerine nasıl öğrettiğimizi daha yakından incelediğinizde, bu benzetme hızla bozulur.

1990’lar dolana kadar, bilgisayar programlama bilgisayar bilimi denilen şeyin büyük bir parçası haline geldiği için, birçok üniversite Bilgisayar Bilimleri müfredatına “Yazılım Mühendisliği” başlığı taşıyan bir ders eklemişti. O dönemde bu dersleri öğretmek için kullanılan popüler ders kitapları arasında Ian Sommerville’in “Yazılım Mühendisliği” adlı ders kitabı yer aldı. 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’s ders kitabı hala dokuzuncu baskısında dünya çapında birçok üniversitede kullanılmaktadır. Bu bir soruya yol açar:

Neden yaklaşık olarak her 3-4 yılda bir, öğrencilerimize Yazılım Mühendisliği’nin temellerini öğreten bir ders kitabını gözden geçirmemiz gerekiyor?

İnşaat Mühendisliği, Makine Mühendisliği ve Elektrik Mühendisliği’nde kullanılan ders kitaplarına bakarsanız, bu kitapların büyük çoğunluğu neredeyse bu kadar sık revizyon gerektirmez. Bu durumun neden olduğunu anlamak için, dünyanın dört bir yanındaki üniversitelerde “Yazılım Mühendisliği” adı altında nelerin öğretildiğine daha yakından bakmamız gerekir.

Daha yakından baktığınızda, yeni nesil yazılım profesyonellerimize, şu anda yazılım uygulamaları ve yöntemleri açısından popüler olan her şeyi öğrettiğimizi göreceksiniz. Günümüzde popüler yazılım uygulamaları ve yöntemleri Çevik, Kullanım Örnekleri, Kullanıcı Hikayeleri, RUP, XP, Scrum Yalın, PSP, TSP gibi buzzwords tarafından bilinir ve liste uzayıp gidiyor …

Yazılım Mühendisliği öğretiminde bu yaklaşımın sorunu, yazılım uygulamalarının ve yöntemlerinin sık sık gelip gitmesi ve gelip gitmeye devam etmesidir, bu yüzden Sommerville’in ders kitabını sürekli olarak güncellemesi gerekir. Bu başka bir soruya yol açar:

Peki ya 1973’te çalıştığım ilk şirkette bana hiç değişmeyen şeyleri öğrenmemi söyleyen gri sakal? Bana kötü tavsiye verdi mi? Değilse, yazılım mühendisliği nde asla değişmeden değişen şeyler le ilgili olarak yeni nesil yazılım profesyonellerimize ne öğretiyoruz?

Bu soruları yanıtlamadan önce, önce geri adım atalım ve birkaç farklı soru soralım:

Yazılım Mühendisliği’nde hiç değişmeyen bir dizi şey gerçekten var mı?

Eğer varsa, ne olduklarını biliyor mmıyız?

Eğer ne olduklarını biliyorsak, onlara yeni nesil yazılım profesyonellerimize tutarlı bir şekilde ders veriyor muyum?

Yazılım mühendisliği temel böyle bir dizi aslında var. Bu inanç, uluslararası bir gönüllü grubunu bu temel leri kodlamak için görevlendirmiştir. Amaç, bu temel yazılım geliştiricileri gerçek yazılım professi olarak hazırlamak için yardımcı bizim yeni nesil öğretilmesi içinonals.

Bu girişimde yer alan gönüllüler (SEMAT – Yazılım Mühendisliği Yöntem ve Teorisi olarak da bilinir) 2010 yılından beri bu görev üzerinde çalışmaktadırlar. Geçtiğimiz yıl SEMAT, uluslararası standartlar konsorsiyumu object management group’un resmi bir OMG standardı olarak “Essence”ı benimsediklerini açıklamasıyla önemli bir kilometre taşına ulaştı.

Bu da birkaç soruya daha yol açar:

Bugün yazılım geliştiricilerimize öğretilen ve son 40 yıldır Yazılım Mühendisliği adı altında öğretilen Öz standardı ne kadar farklı?

Ve:

Farklılıklar gerçekten birçok hala ortak bütçe ile ilgili yazılım endüstrisi veba inanıyorum sorunları ile yardımcı olacak ve aşırı çalışır ve kötü yazılım kalitesi zamanlama?

Bir açıdan, Essence’ın yakaladığı yeni bir şey değildir. Essence standardı, Paydaşlar, Fırsat, Gereksinimler, Yazılım Sistemi, Takım, Çalışma ve Çalışma Şekli gibi ortak sözcükleri içerir. Ama başka bir açıdan Ne Essence yakalar dramatik yeni. Aslında, bazıları “eski muhafız” birçok bile anlamak büyük zorluk olacağını bir “paradigma kayması” diyoruz.

Essence’ı kullanırken ilgili değişiklikler hakkında size bir fikir vermek için 1970’lerin sonlarında bir programcı olarak ilk günlerime tekrar geri dönüyorum. O günlerde ben yüksek performanslı uçaklar uçmak için pilotlar eğitmek için yazılım sistemleri geliştirme uçuş simülasyon etki alanında çalıştı. 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 özel 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ı olmak 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. Çünkü benim kayıt / oynatma yazılımı ile mümkün olduğunu açıklamak için zaman almıştı pilot eğitmen işini kolaylaştıracak ek özellikler tasavvur etmeye başladı. Fikirlerini bir kusur formuna yazdı.

Ancak proje yöneticim, bu isteklerin kapsam içinde mi yoksa kapsam dışı mı olduğunu müşteriyle tartışmak istemedi. Onun görüşü– o zamanlar ve bugün de görüntülenen pek ç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ğundan, bunu değiştirmek kolay olarak görme eğilimindeyizdir. 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 şekillerde değiştirme becerisi, program yöneticileri ve müşteriler de dahil olmak üzere yazılım geliştiricileri ve paydaşları arasında var olan dinamikleri tamamen değiştirir. Bu farkın kendine örnek olmasının bir yolu, kullanıcılar yazılıma alıştıkça, pilot eğitmen müşterimin 1970’lerin sonlarında yaptığı gibi yazılımdaki değişikliklerin işlerini kolaylaştırabileceği yeni yollar görmeleridir.

Artık deneyimlerinden biliyoruz ki, yazılım mühendisliğinin etkili profesyonel yazılım mühendisliği uygulamaları için kritik öneme sahip başka boyutları da vardır. Bu diğer boyutlar bizi kodun değiştirilme kolaylığının ötesine götürür. Bugüne kadar, bu ek boyutlar hak ettikleri ilgi yakın hiçbir yerde almadım.

Kodu değiştirdiğinizde gereksinimleri de etkiliyor olabilirsiniz ve daha önce test edilmiş yazılım sistemindeki diğer yetenekleri de etkiliyor olabilirsiniz. Kodu değiştirmek, ek çalışma, ek sınama, muhtemelen destekleyici kullanım kılavuzlarında değişiklikler ve benzeri… Tüm bunlar bütçeyi ve zamanlamayı etkiler ve yazılımın kalitesine ek risk oluşturur.

Bir yandan yazılım kodunu değiştirme yeteneği yazılım sektörüne hızla büyük bir güç getirirken, aynı zamanda yazılım profesyonellerinin kararlaştırılan çalışma şekillerine, ek işi yapmak için gereken etki ve zamana ve planlanmamış hızlı değişiklikler yaparken risklere giderek daha fazla uyum sağlamaları gerektiği anlamına gelir. Son on yıl içinde çevik hareket yazılım topluluğunun paydaşlar ile erken ve sürekli etkileşimin önemi ve yazılım geliştiricilerin kendi çalışmalarının maliyetini tahmin önemi de dahil olmak üzere 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,ey de önceki mühendislik deneyimlerinden farklılıklar getirmek bu diğer boyutların kritik önemini öğrendim. Bu farklılıklar, yazılım geliştiricilerin etkili yazılım profesyonelleri olmak 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 bana incelemek için çalıştığı kitabın taslak kopyasını gönderdi. İlk SEMAT çalışmalarında çok aktif olmayı planlayan Watts Humphrey, SEMAT çalışmalarının hızlandırılması gibi hastalandı ve benden planlı çabasını elde etmesine yardım etmem istendi. Ağustos ayı sonlarında aynı yıl Watts bana sadece birkaç ay onun vefat ından önce aşağıdaki e-posta gönderdi. O başkalarıyla bu e-posta paylaşabilirsiniz kabul etti:

Paul, yorumlarından, sanki benim kitap, bunun için minnettarım noktası var gibi geliyor …. doğru cevap ve semat ile takip en çok ilgi mi, nasıl yazılım profesyonelleri düzgün eğitimli ve profesyonel tutum ve beceriler uygun bir dizi daha sanayi almadan önce sağlamak olabilir ilgilidir. Umuyorum ki SEMAT çabası sonunda akademik topluluğun programlarını profesyonel gibi davranmaları ve kendilerini yönetmeleri için yazılım profesyonellerine yeniden odaklanmalarını sağlamak için bu dürtüye öncülük edebilecektir.

Bunu yaptıkları zaman, mezunları kendi yönetimi ile müzakere ve üstün iş yapmak mümkün olacak …. İşte profesyonellerin yapması gereken budur… Bu yönde iyi bir başlangıç yazılım insanlar kendi çalışmalarını ölçmek zorunda gerekliliği onları ikna etmek olacaktır. Yazılım çalışmaları, söylediğimiz gibi, bilgi çalışması olduğundan, herhangi bir gerçekten doğru önlemler yazılım profesyonelleri 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 kariyer tamamladıktan sonra Yazılım Süreci Programı’nı kurandaki Yazılım Mühendisliği Enstitüsü’nün bir üyesi oldu. 2003 yılında Ulusal Teknoloji Madalyası ile ödüllendirildi.

Bugün Watts, akademik camiada devam eden SEMAT çalışmalarıyla yüreklendirilirdi. 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, Dr. Mira Kajko-Mattson’ın rehberliğinde İsveç’teki KTH Royal Institute of Technology’de birinci ve ikinci yıl yazılım mühendisliği derslerinde kullanılıyor. Ayrıca Abd’de Carnegie-Mellon West Dr Cecile Peraire tarafından öğrencilerle yapılan Essence alan çalışmaları olmuştur. SEMAT topluluğu için bir sonraki adım, Öz’ün endüstriyel projelerde gerçek kullanım ve ölçülen sonuçlarla ilgili vaka çalışmalarını yayınlayarak endüstride nasıl yardımcı olabileceğini göstermektir.

Etiketler
Daha Fazla Göster

İlgili Makaleler

Bir cevap yazın

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

Başa dön tuşu
Kapalı
Kapalı