Metodoloji Arayışı - In Search Of Methodology

Cockburn'den yaptığım özetlere çok beğendiğim bir makalesiyle devam edeceğim: In Search of Methodology:

IBM´in metodoloji danışmanlığı grubu OO metodolojileri araştırdı.

Çok sayıdaki OO metodolojisinden hangisini kullanmalıyız, sorusu yerine, bir OO metodolojisinin hangi unsurunu kullanmalıyız? Kabullenmeyi etkileyen şey nedir? Çeşitli yöntemlerin güzel özelliklerini nasıl entegre edebiliriz?

OO çok popülerleşti. Ancak uygulayıcıların çoğunun acemi oluşundan dolayı, yeterli bir olgunluk oluşmadı.

Bir metodolojinin kullanılabilir olması şu özelliklere bağlı:

Basit, etkili ve düşük iş yükü oluşturması. Kabullenme ve kullanışlılık, grubun iş alışkanlıklarını değiştirme yeteneğine bağlı. Ayrıca bürokratik işlere olan toleransına bağlı. Her ikisi de düşüktür. Mühendislik kökenli gruplarda daha yüksek.

Dizayn tekniklerinin faydalı olması için karmaşık olması gerekmiyor. En çok kullanılan ve fayda sağlayan iki teknik: Use caseler ve sorumluluklar. Bunlar aşamalı geliştirme (incremental development) ile de uyumlu. Ayrıca dizayn kalıpları gibi yeni fikirler için alan bırakıyorlar.

Araştırma bulguları:

- Geliştiriciler, doğrudan son ürüne yönelmemiş dizayn etkinliklerine zaman harcamak istemiyorlar.

- Elle (manuel) dizayn dokümanlarının güncellenmesi işinden hoşlanmıyor. Bunu yapmıyorlar.

- Yeni iş alışkanlıklarını öğrenmek için sınırlı zaman veriliyor.

- Geliştiriciler metodolojinin sevmedikleri yönlerini genellikle uygulamıyorlar.

Bürokratik işlerden kaçınılıyor. Bunun sebebi geliştiricilerin bu konuda yetkiye sahip olmaları. Veya değilse bile organizasyonun metodolojinin bu yönlerinin uygulanıp uygulanmadığını takip edememeleri. Proje yöneticisi de çoğu zaman metodolojinin yıkıldığının farkında değil.

Basit yöntemler:

Yukarıdaki sorunlar olmakla birlikte, iyi geliştirciler iyi sistemler tasarlamaya devam ediyor. Bunlarla yapılan görüşmeler, bunların basit, etkili ve verimli teknikleri tutarlı olarak yürüttüklerini gösteriyor.

Sorumluluk:

Sorumluluk temelli tasarımın en çok kullanılan ve etkili bir dizayn tekniği olduğu ortaya çıktı.

Sorumluluk sistem tasarımının gerekçesini oluşturur. Ancak yapısal tasarımda da sorumluluk kavramı vardı. Fark ne?

Nesne tasarımında sorumluluklar aynı zamanda hem tanımlanır hem de dağıtılır. Yapısal analizde tanımlanır ancak dağıtılmaz.

Ancak herkes sorumlulukların bulunup dağıtılması işini aynı kalitede yapmaz.

Yeni gelenler bile hemen bu işten dolayı ya bir rahatlık ya da bir rahatsızlık hissi alıyor.

Use case:

Sorumluluklar bir nesnenin veya alt sistemin bir fonksiyonu nasıl gerçekleştirdiğini gösterir. Ama niçini göstermez. Bunu senaryolar ve use caseler sağlar.

Use Case nedir?

Sistemle aktör arasındaki bir işlem diyaloğu...

Bu tanımda maksat eksik. Niçin?

Jacobson yeni yazılarında, daha kaba işlem ve senaryo seçiminin daha inceltilmiş seçimlerden daha faydalı olduğunu söylüyor.

Bir teyp cihazını düşünelim. Her bir İleri Sar, Play, Geri Sar düğmesi bir use case olabilir. Veya...

"Bu düğmelere niye basıyoruz?"

"Kasette belirli bir yeri bulmak için."

Öyleyse tek tek düğmeler değil, düğmelerin belirli bir kombinasyonu aslında bir use case. Veya şöyle diyelim: "Kasette belirli bir yeri bulmak için basıyoruz."

Use case, bir "kullanım zarfıdır". Zarfın kapağında, maksadı yazar. İçindeyse, bu maksadın nasıl gerçekleştiği, bu da başka use caseler, senaryolar ve kullanım zarflarıyla olur.

Use caselerin maksatlarının toplamı, bir sistemin ihtiyaçlarının en kısa ve okunabilir tarifidir.

Devirli geliştirme (iterative development):

Yapılan görüşmeler şunu gösterdi. Devirli geliştirme, projenin başarılı olup olmayacağının çok iyi bir ayırt edicisidir. Çok az yönetici bunun mantığını ve mekaniğini anlamış.

Niçin böyle?

Birinci sebep, aşamalı geliştirme, proje yöneticilerinin çalışma alışkanlıklarını etkiliyor. Halbuki bu insanların, değişme becerileri geliştiricilerden daha yüksek değil.

İkinci sebep, aşamalı geliştirme için karmaşık ve muğlak tanımlar kullanılmış. Spiral, küp, "gestalt round trip"... Bunların yerine daha basit tarifler gerekiyor.