Facebookta Kunt Elektronikten Ali Yıldırım'la CMMI üzerine yazışıyorduk. Orada yazdıklarımı burada yayınlayacağım:
(Özet olarak, CMMI yazılım geliştirme süreçlerinin kaliteli olmasını temin etmeye yönelik bir kalite modeli.)
kişisel görüşüm, cmmi modelinin yazılım sektöründe belirli bir büyüklüğün üzerindeki firmalar için, birinci derecede öncelikli iş olduğu yönünde. neden bu kadar önemli olduğunu düşünüyorum? edward deming adında bir mühendis var. bu adam, başta honda ve toyota olmak üzere japon oto sanayisinin amerika'nın çok üstünde bir kalite ve rekabetçi güce ulaşmasını sağlayan mühendislerden birisidir. deming'in çok meşhur bir sözü var, diyor ki: "bir ürünün kalitesi, ancak o ürünün üretildiği sürecin kalitesi kadar olabilir"
bu çok anlamlı ve aslında sadece imalat sanayine değil, tüm sanatlara uyarlanabilecek bir fikir. ürettiğimiz herhangi bir eser (fikir, ürün, hizmet her neyse), o eseri üretirken kullandığımız yöntemin (araçlar, kurallar, iş akışı vs.) kalitesinden daha iyi olamaz. yöntemin kalitesi, eserin kalitesini belirler.
efqm, iso, 6 sigma, yalın düşünce gibi toplam kalite yönetiminin uygulanmasına yönelik çok sayıda model uzun zamandan beri biliniyor. fakat bu modeller, genellikle imalat veya hizmet ağırlıklı çalışan firmalara özel üretilmiş. yazılım sektörünün içinde, her biri birbirinden çok farklı ürün geliştirme süreçleri yer aldığından, bu modellerin yazılım sektöründe uygulanması uygun olmuyor. cmmi, işte bu eksiği dolduruyor.
cmmi sayesinde yazılım geliştirme işleri, karmakarışık, ne zaman ne olacağı bilinmeyen, hiç kimsenin içeride ne geliştirildiğini bilmediği, tüm projenin başarısının bir iki uzmana bağlı olduğu, öngörülemeyen işler olmaktan çıkıyor. yazılım geliştirme süreci, yönetilebilir ve iyileştirilebilir bir hale geliyor. bu çok önemli bir şey.
sektörün içinde olan herkes bu sektörde ne kadar büyük doğrudan ve dolaylı maliyetlerin olduğunu bilir. gereksinim analizinde uzmanlık, konfigürasyon yönetiminde uzmanlık, bunlar yararlı ve önemli beceriler. fakat bu tip tek tek ayrık alanlarda uzmanlık sağlamak, projelerin kalitesini teminat altına almak için yeterli olmuyor. tüm kritik becerilerde belli bir yetkinlik sağlamak lazım. cmmi bütün bu alanlarda yetkinlik sağlayan, yönlendirici bir model sunuyor.
Cuma, Haziran 26, 2009
Neden CMMI?
Pazartesi, Ekim 20, 2008
Pratik Bir Nesne Modelleme Araci: Mapsys
Mapsys normalde sistem dinamiği modelleri geliştirmek için üretilmiş bir araç. Fakat çok hızlı bir şekilde çizge (bağlantılı öğelerden oluşan bir şema) oluşturma kabiliyeti sunduğu için, bu aracı yazılım geliştirmede nesne modellemesi için de kullanmak çok pratik oluyor.
UML'in sunduğu özelliklerin çoğunu desteklemiyor, Mapsys. Bu normal, çünkü bir UML tasarım aracı değil. Fakat benim için en önemli özelliklerden biri, çok hızlı bir şekilde basit nesne çizgeleri geliştirmek. Bunu yapabilmemi sağlıyor.
Resimde oluşturduğum bir modelden örnek bir kesit gösteriyorum. UML'den biraz farklı bazı yazım standartları kullanıyorum. UML'de nesne başlıkları, "< obje_adı >:@lt class_adı >" şeklinde. Bense şu şablonu kullanıyorum: "< class_adı > @ < obje_adı >"
Bu yazım şeklinin okunabilirlik açısından bir faydası var: Bazen sadece class ismini, bazen sadece obje ismini kullanmak istiyorum. UML'de bunu yapmak mümkün, fakat görsel ayrıştırma çok kuvvetli olmuyor.
Cumartesi, Temmuz 21, 2007
Programlama Kitap ve Makale Ozetleri
Çeşitli programlama kitap ve makalelerine dair aldığım notların linkleri:
Martin Fowler, Refactoring:
http://writer.zoho.com/public/mnuhoglu/Refactoring1
Çok iyi bir kitap. Sade, okunaklı ve kolay anlaşılır program yazmakla ilgili.
Dave Thomas, Programming Ruby:
http://writer.zoho.com/public/mnuhoglu/Programming-Ruby1
Dave Thomas çok iyi bir yazar. Ruby çok güzel bir dil. Fakat ben hala statik dillerde kendimi daha rahat hissediyorum.
James Gosling, Effective Java Programming
http://docs.google.com/Doc?id=a7w6zmv5z8j_30fxhqgd
Çok iyi bir kitap. Java ile programlamaya dair çok önemli kurallar.
Martin Fowler, Enterprise Application Architecture
http://docs.google.com/Doc?id=a7w6zmv5z8j_29gv9bbc
Kurumsal yazılımlarda kullanılması tavsiye edilen mimari çözümlerle ilgili çok iyi bir kitap. Kitapta anlatılan çözümlerin pek çoğu, zaten programcıların kullandığı çerçeveler tarafından otomatik olarak yürütülüyor. Ama yine de altta ne yattığını öğrenmek açısından faydalı bir kitap.
Alistair Cockburn, Writing Effective Use Cases
http://docs.google.com/View?docid=a7w6zmv5z8j_13db45zs
Gereksinim analizi konusunda, gerçekten çok iyi bir kitap bu. Kullanım senaryoları (use case) konusunu çok iyi anlatıyor.
Glenn Meyer, The Art of Software Testing
http://docs.google.com/Doc?docid=a7w6zmv5z8j_17g2rb6d&hl=en
Kent Beck, Test Driven Development
http://docs.google.com/Doc?docid=a7w6zmv5z8j_18cwpmpf&hl=en
Yazılım geliştirme sahasında çığır açıcı kitaplardan biri. Şimdi çok popüler bir konu olan TDD'nin öncü eserlerinden.
Steven John Metsker, Building Parsers with Java
http://docs.google.com/Doc?docid=a7w6zmv5z8j_33gzkkj9&hl=en
Eric Evans, Domain Driven Design
http://docs.google.com/Doc?docid=a7w6zmv5z8j_31djc5sg&hl=en
DDD yazılım tasarımıyla ilgili çok yararlı bir yaklaşım. Çok atıf alan bir eser.
Kent Beck, Extreme Programming
http://docs.google.com/Doc?docid=a7w6zmv5z8j_28hd97w6&hl=en
XP metodolojisinin piyasaya sunulduğu ilk kitap. XP'nin geliştiricisinden.
Herrington, Code Generation in Action
http://docs.google.com/Doc?docid=a7w6zmv5z8j_323z72bk&hl=en
Güzel bir kitap, fakat pek kullanmadığımdan ne kadar yararlı bilemiyorum...
Bauer ve King, Hibernate in Action
http://docs.google.com/Doc?docid=a7w6zmv5z8j_27hrhrbn&hl=en
Hibernate kütüphanesinin geliştiricilerinden bir eser. Hibernate java ve .net platformlarında çok kullanılan bir veritabanı-nesne eşleştirme mekanizmasıdır...
Dave Thomas, Pragmatic Programmer
http://docs.google.com/Doc?docid=a7w6zmv5z8j_238b685p&hl=en
Bu kitabın tarzını çok seviyorum. Sohbet şeklinde, ama çok değerli tavsiyeler içeren bir kitap. Sanki usta bir programcının yanında, programcılığı öğrenmek gibi bir his bırakmıştı bende...
Hibernate Reference
http://docs.google.com/Doc?docid=a7w6zmv5z8j_264qdgb3&hl=en
Hibernate kütüphanesinin resmi kılavuzundan aldığım notlar
Suzanne Robertson, Mastering The Requirements Process
http://docs.google.com/Doc?docid=a7w6zmv5z8j_25dws79k&hl=en
Gereksinim analiz sürecini bu kadar iyi anlatan pek fazla kitap olmadığını düşünüyorum. Çok iyi, hem teorik hem de pratik yönleri olan bir kitap.
SQL in a Nutshell
http://docs.google.com/Doc?docid=a7w6zmv5z8j_20df85qt&hl=en
SQL konusunda hızlı bir referans kitabı
Teach Yourself HTML and CSS in 24 Hours
http://docs.google.com/Doc?docid=a7w6zmv5z8j_19p6v554&hl=en
Alan Cooper, About Face
http://docs.google.com/Doc?docid=a7w6zmv5z8j_15d9bh99&hl=en
Bu eser, kullanıcı arayüzü tasarımı konusundaki en iyi kitaplardan biri olarak gösteriliyor.
Barry Boehm, Balancing Agility and Discipline - A Guide for the Perplexed
http://docs.google.com/Doc?docid=a7w6zmv5z8j_14m3cdpn&hl=en
Metodolojilerle ilgili yaklaşımı çok iyi dengeleyen bir kitap.
Makaleler:
Bu dosyaları pdf olarak box.net'e koymuştum:
ArsDigita:
http://www.box.net/shared/static/m6hxpqmuqv.pdf
Çok iyi bir hikaye. Amerika'daki venture capital mekanizmasının başarılı bir startup firmayı nasıl iflasa sürüklediğini anlatıyor.
Aşamalı Geliştirme (Iterative Development)
http://www.box.net/shared/static/4mmrifni30.pdf
AOP (aspect oriented programming)
http://www.box.net/shared/static/2f2pcp00t4.pdf
BlackMamba: A Swing Case Study
http://www.box.net/shared/static/8qa8ebyigz.pdf
Swing ile yazılım geliştirmeye dair örnek bir uygulama mimarisi...
Data Access with the Spring Framework
http://www.box.net/shared/static/734gjvkyz9.pdf
Eşli Programlama (Pair Programming)
http://www.box.net/shared/static/mb6kgkv1vc.pdf
Exploratory Testing Explained
http://www.box.net/shared/static/416042nqeu.pdf
Cockburn, In Search Of Methodology
http://www.box.net/shared/static/oiiclxxr67.pdf
Joel On Software
http://www.box.net/shared/static/i2vb271uvg.pdf
Joel'in eski yazıları, yazılım geliştirme konusundaki en güzel denemelerden...
Cockburn, Kahve Makinesi
http://www.box.net/shared/static/pullc94o0x.pdf
Nesne odaklı geliştirmeye yönelik güzel bir vaka çalışması.
Paul Graham'ın yazıları
http://www.box.net/shared/static/c55iszibcf.pdf
Paul Graham'ın çok hoş bir yazım tarzı var.
Rethinking Swing Threading
http://www.box.net/shared/static/4mp8k8odri.pdf
Using the Jakarta Commons
http://www.box.net/shared/static/i72y4b8rp1.pdf
Why Functional Programming Matters
http://www.box.net/shared/static/4j0zjorxyl.pdf
Diğerleri:
http://writer.zoho.com/public/mnuhoglu/Diger-Teknik-Kitap-ve-Makaleler1
box.net'teki klasörüme erişmek için:
http://www.box.net/shared/rfdpnqgol9
Pazartesi, Ocak 16, 2006
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.
Etkili Use Case Yazımı - Tavsiyeler
Cockburn'ün kitabından yaptığım özete devam ediyorum:
1. Her use case bir düz yazıdır (makale, prose)
İyi bir makale yazmak için geçerli olan bütün kurallar, use case yazımında da geçerlidir.
2. Kolay okunabilir yaz:
Use casei kimin için yazarız?
İnsanlar için. İnsanların kolay anlaması use caselerin kalite kriteridir. Use caseler kaliteli olmalıdır ki, nihai yazılım kaliteli olsun.
- Doğrudan amaca yönelik ve kısa olsun.
- İsim verirken, aktif fiillerle kullanıcı hedefini belirt.
- Aktif fiiller kullan
3. Tek cümle formu:
- Geniş zaman kullan
- Bir amacı gerçekleştiren bir aktörün dilinden yaz:
"Customer enters card and PIN."
"System validates that customer is authorized and has sufficient funds."
"PAF intercepts responses from the web site, and updates the user's portfolio."
"Clerk finds a loss using search details for "loss"."
Extensionların koşul kısmında farklı bir gramer biçimi kullan. Büyük oranda geçmiş ve : ile ayrılmış olsun.
"Time-out waiting for PIN entry:"
"Bad password:"
"File not found:"
"User exited in the middle:"
"Data submitted is not complete:"
4. Alt use caseleri metnin içine dahil et
Extends ve specializes özelliklerini kullanmaktan kaçın. Karışıklığa sebep oluyor. Normalde nasıl yazacak idiysen öyle yaz:
"Clerk finds a loss using search details for "loss"."
Finds a loss, alt bir use casedir.
5. Hedef seviyesini iyi ayarla
Deniz seviyesindeki amaçların özellikleri:
- Tek kişi tarafından tek yerde ve zamanda yapılır (2-20 dakika)
- İş bittiğinde aktör mutlu olarak ayrılabilir.
- Çok sayıda yaparsa, zam isteyebilir.
9´dan fazla adım varsa, adımları azalt.
- Kullanıcı hareketleri
- Benzer işler (veri girişi)
- Niçin bunu yapıyor?
- İki aktör arasında çok sayıda gidip gelme. Bu tarz bir müzakere sürecinin amacı nedir?
6. GUI´yi dışarıda bırak
- Doküman çok uzar.
- Kırılgan ve değişmeye çok müsait hale gelir.
- GUI kararları erkenden alınmış olur.
Kötü örnek:
2. The system displays the Login screen with fields for username and password.
3. The user enters username and password and clicks ’OK’.
4. The system verifies name and password.
5. The system displays the Main screen, containing function choices.
6. The user selects a function and clicks ’OK’.
7. Başarısızlık durumu
Başarısızlık durumu bütün alt use caseler için de ele alınmalı. Eğer alt use case, ana senaryodan çağrıldıysa, başarısızlık alternatif senaryolar kısmında ele alınır. Eğer alternatif akış içinde ele alındıysa, aynı yerde başarısızlık durumu da çözülür.
8. Bütün paydaşların (stakeholders) korunması:
Bir use case sadece ana aktörün (primary actor) amacına hizmet etmez. Bütün paydaşların beklentilerine hizmet etmeli. Eğer öyle olsaydı zaten, o zaman sadece kullanıcı etkileşimi tarif edilirdi.
Kullanıcı use casei sürer, ancak use case bütün paydaşların beklentilerini (garanti) karşılar.
- Ana aktörün amacı, use casein ismidir.
- Şirketin amacı, ödediği şeyin karşılığını almak.
- Düzenleyici kurum: Şirketin yönetmelikleri uyguladığı. Bir tür log tutulması.
- Paydaşlardan biri, hata durumunda kurtarmaya yönelik amacı vardır. Bu yüzden daha çok log ister.
Son koşullar (guarantees) kısmı, bütün paydaşların beklentilerinin nasıl karşılandığını ifade eder.
Son koşulları, ana senaryodan önce yazmakta fayda var. Çünkü bu sayede senaryo sırasında kimlerin hangi beklentilerini karşılamak gerektiği daha kolay ortaya çıkar.
10. Önkoşullar:
En yaygın önkoşullar, kullanıcının login olması ve yetkili olmasıdır.
Başka önemli bir önkoşul da, bir use casein bir başka use casede sağlanan koşula dayanmasıdır. Mesela bir use casede kullanıcı bir ürünü seçer. İkincisinde bu seçilmiş ürünün bilgisi işlenir.
Dolayısıyla ne zaman ki bir önkoşul varsa, daha üst seviye bir use case vardır.
11. Çek listesi:
İyi bir use casein sağlaması gereken özellikler:
- Use case başlığı: Aktif bir fiil cümlesi mi? Ana aktörün amacını mı ifade ediyor? Sistem bu amacı yerine getiriyor mu?
- Kapsam ve sevyie: Kapsam ve seviye alanları dolduruldu mu?
- Kapsam: Eğer use case bir srs dokümanıysa "kara kutu" olmak zorunda.
- Ana aktör: Ana aktörün davranışı var mı?
- Önkoşullar: Use case içinde hiç kontrol edilmiyorlar, değil mi?
- Paydaşlar: Onlardan hiç bahsediliyor mu?
- Sonkoşullar: Bütün paydaşların beklentileri karşılanıyor mu?
- Asgari garanti: Bütün paydaşların menfaatleri korunuyor mu?
- Ana senaryo: Tetikleyiciden mi başlatılıyor? Adım sırası doğru mu? 3-9 adım arası mı?
- Senaryodaki her adım: Bir amaç ifade ediyor mu? Hangi aktör tarafından yapıldığı belirtiliyor mu? Aktörün amacı açık mı? Amaç seviyesi, use casein amaç seviyesinden tam bir seviye mi düşük? Kullanıcı etkileşimini ifade etmiyor değil mi? Hangi bilginin aktarıldığı açık mı? Adım, "onaylama" yapıyor mu, bir koşulun "kontrol edilmesi" yerine?
- Alternatif adım koşulu: Sistem bunu tespit edebiliyor mu? Sistem bunu ele almak zorunda mı?
- Genel içerik: Sponsor ve kullanıcılara: "Bu sizin istediğiniz şey mi?" "Teslimattan sonra, bunu alıp almadığınızı söyleyebilecek misiniz?" Geliştiricilere: "Bunu gerçekleştirebilir misiniz?"
12. Sürekli açılan bir hikaye
Birçok projede en üst seviyede bir use case tanımlanır: "XXX Sistemini kullan". Bu aslında çok sayıdaki use casei toplayan bir içindekiler tablosu gibidir. Bu use caselerin arasındaki ilişkileri gösterebilir.
İnsanlar bir başlangıç noktası olarak böyle en üst seviye bir use case tanımlamayı faydalı buluyor.
Deniz seviyesindeki use caselerden bir alt seviyeye inince, daha derindeki indigo (lacivert) use caselere erişiriz. Bunlar genellikle sofistike bir adımın kendi başına tanımlanması şeklindedir. Müşteri bul, ürün bul gibi use caseler bu tarz alt fonksiyonlar olarak tanımlanabilir.
Ancak her use casein bakım maliyeti vardır. Bu yüzden bunlarda mümkün olduğunca tutumlu olmak lazım.
Prensip olarak alt seviye use caseler istenildiği kadar derinleştirilebilir.
13. İş kapsamı ve sistem kapsamı
Bir sistemin tasarımında sınırları belirlemek çoğu zaman muğlaklık içerir.
Use caseler tanımlanırken, özellikle, iş use caseleriyle (business) sistem use caseleri arasındaki ayrım net olmalı.
İş use casei, iş operasyonlarıyla ilgilidir. Bir iş akış şemasında, bir sürecin baştan sona gösterilmesindeki use caselerdir. Dolayısıyla iş use casei, otomasyon sisteminin içinde değildir. Sadece belirli adımları otomasyona dahildir.
İş use casei, açık kutu formunda ifade edilir. Sistem use casei ise kapalı kutu.
14. Temel değerler ve farklılaştırmalar
Bir konferansta iki makale, bir düzine kadar önemli hatayı özetledi. Bu makalelerde belirtilen temel değerler şunlardı:
- Amaç temellilik. Use caseler, ana aktörün amaçları ve diğer aktörlerin alt amaçları etrafında oluşur.
- Kuş bakışı perspektifi. Use case, sistemı kuş bakışıyla tasvir eder. İçeriden bir bakışla değil.
- Okunabilir. Use casein veya herhangi başka bir spesifikasyonun nihai amacı insanlar tarafından anlaşılmasıdır. Eğer insanlar kolaylıkla dokümanı anlayamazsa, doküman esas amacını gerçekleştiremez. Bu yüzden gerektiğinde hassasiyetten ve belki hatta doğruluktan bile bir miktar fedakarlık edilebilir. Bu açığı, daha fazla iletişim ve diyalogla kapatırsınız. Ancak eğer ki okunabilirlikten fedakarlık yaparsanız, yazılım geliştiricileriniz/müşterileriniz/yöneticileriniz onları okumaz.
- Çok çeşitli amaçlara hizmet eder.
- Kapalı kutu fonksiyonel ihtiyaçlar
- İş sürecinin yeniden tasarımının ihtiyaçları
- Süreç dokümantasyonu
- İhtiyaçların ortaya çıkarılması ve onaylanması için bir araç
- Test vakalarının belirlenmesi
- Sistemin iç yapısının dokümantasyonu
- Bir tasarım çerçevesinin davranışının dokümantasyonu
- Kapalı kutu ihtiyaçlar. Use caselerin açık kutu ihtiyaçların tanımlanmasında kullanılması durumunda, okunabilirlik düşüyor, daha kırılgan oluyor.
- Alternatif yollar, ana senaryodan sonra. Alternatif yolları, ana senaryonun içine yerleştirmek, anlaşılmayı güçleştiriyor. Jacobson´ın orjinal modeli, daha faydalı.
- Az enerji harcamak. Sürekli olarak use caseleri inceltmeye çalışmak, çok değer eklemiyor. İlk taslak, değerin yarısını zaten inşa ediyor. Cümlelerin ifade ediliş şekli gibi detaylarla oynamak, iletişimi kötüleştiriyor bile. Bunun yerine iş kurallarının tanımlanması, kullanıcı arayüzlerinin, harici arabirimlerin kontrolü gibi diğer ihtiyaçlarla ilgilenmek daha faydalı olur. Tabi ki, projenin kritikliği de inceltme noktasında önemli bir karar kriteri.
Değişebilecek noktalar:
- Numaralanmış adımlar veya basit paragraflar. İnsanlar hangisiyle daha rahat çalışıyorsa, o tercih edilmeli.
- Tam doldurulmuş veya serbest yazılmış. Bazı zamanlar fonksiyonel ihtiyaçların eksiksiz bir şekilde detaylandırılması doğrudur, bazen hafif olarak doldurulması yeterlidir. Dolayısıyla use case şablonları da mutlak bir şekilde dikte edilmemeli.
- Ön iş modellemesi, use caselerle veya use caselersiz. İş sürecinin dokümantasyonu, sistemin fonksiyonel ihtiyaçlarının tanımlanmasından önce de olur, sonra da.
Uygunsuz noktalar:
- Ana başarı senaryosunun içinde "eğer" cümlelelri
- Use case metni yerine, sequence şemaları. Sequence şemaları, use case metninin yerine geçemez. Çünkü,
- okunması daha zordur (özel bir notasyon içerir)
- paydaşların beklentilerinin korunup korunmadığını ifade etmez.
- Okların üzerine yeterli metin yerleştirmek imkansızdır
- Metnin bir pop-up diyalog kutusuna yazılmasını gerektirir. Bu da hikayenin takibini zorlaştırır.
- GUI detaylarının fonksiyonel spesifikasyonlarda yer alması. Bunun yanlışlığı konusunda genel bir uzlaşma vardır.
16. Use caseler sadece bir chapterdır.
Başka chapterlar da var, ihtiyaç analizinde ele alınması gereken: Veri tanımları, iş kuralları, kullanıcı arayüzü tasarımı, iş alanının modeli ve sair. Use caseler bunların hepsinin merkezindeki bir çekirdek gibi.
Bu çok önemli bir nokta. Çünkü çok sayıda ekipte, use caseler ihtiyaç analizinin tümünü içeren bir parça olarak ele alınıyor.
17. Önce genişlik.
Genişlik, derinlikten önce gelir. Düşük hassasiyetten, yüksek hassasiyete doğru gidilmeli. Bu enerjinizi daha verimli yönetmenizi sağlayacak. Şu sıra ile çalışın:
1. Baş aktörler. Bütün baş aktörleri tespit edin. Beyin fırtınası...
2. Amaçlar. Bütün baş aktörlerin bütün amaçlarını listelemek, bütün sistemin tek bir seferde görünmesini sağlamak için son şans olacaktır. Bu listenin tam ve doğru olması için yeterli zaman ve enerjiyi harcamanın getirisi çok olacaktır.
3. Ana başarı senaryosu. Ana senaryo genellikle kısa ve çok açıktır. Alternatif akışları ortaya koymadan önce ana senaryo bir ortaya çıkmalı.
4. Hata ve genişletme koşulları. Nasıl ele alınacaklarının tespit edmeden önce, hangi farklılaşma koşulları olabilir, bunları tespit etmek önemli. Bu da yine bir beyin fırtınası etkinliğidir, araştırmadan ziyade.
5. Düzeltme davranışı. Hata koşullarının ne olacağını önce tespit etmeli. Sonra bunların nasıl düzeltileceği belirlenmeli.
18. 12 adımlık reçete:
1. Sistemin sınırlarını bul
2. Baş aktörleri beyin fırtanası ile listele.
3. Baş aktörlerin amaçlarını beyin fırtanası ile listele.
4. En üst seviye özet use caseleri yaz.
5. Stratejik use caseleri değerlendir ve gözden geçir.
6. Malzemeyi daha iyi anlamak için, bir use casei al ve hikayesini yaz.
7. Paydaşları, menfaatlerini (interest), önkoşullarını ve sonkoşullarını yaz.
8. Ana başarı senaryosunu yaz. Menfaatler ve sonkoşullarla kıyasla.
9. Beyin fırtınası ile, bütün hata ve alternatif başarı koşularını listele.
10. Aktörlerin ve sistemin her alternatifte nasıl davranacağını yaz.
11. Alt use caseleri ayır.
12. En üstten başla ve use caseleri yeniden ayarla. Ekle, çıkar, birleştir. Tamlığı, okunabilirliği ve hata koşullarını gözden geçir.
19. Hataların maliyeti.
Her projenin hassasiyet seviyesi, o proje takımındaki iletişim seviyesine ve projenin kritikliğine bağlıdır. Mesela Chrysler Bordrolama programında, kısa use caseler yeterli olmuştu. Çünkü müşteriyle yazılımcıların arasındaki iletişim çok yüksekti.
20. Blue jeanler tercih edilir.
Kulağa tuhaf gelse de, daha az yazmanın zararı daha çok yazmaya göre daha düşüktür. Eğer şüpheye düşüyorsanız, daha az metin yazın. Daha üst seviye amaçları kullanın. Hassasiyeti düşürün. Böylece kısa ve okunabilir bir dokümanınız olur. İnsanlar, okuyunca, sorularını sorar.
Eğer çok uzun yazarsan, insanlar okumaya üşenecektir. Takım içindeki iletişim azalacaktır.
Bu çok sık yaşanan bir sorundur.
21. Hataları ele al.
Use caselerin en büyük değerlerinden biri, alternatif koşulları isimlendirmektir. Hataları tanımlamak ve bunların nasıl ele alınacağını incelemek, çoğu zaman sistemle ilgili bilinmeyen birçok şeyi (aktörleri, amaçlarını, iş kurallarını) ortaya çıkaracaktır.
Hemen hemen her programcı şöyle bir şeyi yaşar:
If (condition)
then
else ..?.
else kısmına gelince durur. "Bu durumda ne yapılacak?" Hemen kendisi bir şey tahmin eder ve onu kodlar.
Halbuki else kısmında yazılması gereken şey, ihtiyaç dokümanında belirtilmiş olmalıydı.
22. İş ünvanları erken ve geç
İş ünvanları projenin başlangıcında da sonunda da önemlidir. Ama ortasında değil.
İş ünvanlarını başta ortaya çıkararak, sistemin gerçekleştirmesi gereken amaçları ortaya çıkarırsın.
Projenin sonunda yine önemli hale gelir. Çünkü izin seviyelerini ayarlamak, eğitim malzemelerini hazırlamak, paketlemek bu aşamada olur.
Etkili Use Case Yazımı - Use Case Adımları
Alistair Cockburn'ün "Writing Effective Use Cases" adlı kitabı en faydalandığım yazılım mühendisliği kitaplarından biri. Cockburn bu kitabında bir yazılımın davranışsal ihtiyaçlarını (behavioral requirements) keşfetmek ve tanımlamak için kullanılan use case modellerinin nasıl etkili bir şekilde yazılacağını anlatıyor. Kitabın önemli kısımlarını kendim için bundan iki sene kadar önce özetlemiştim. Bloguma bu özetimden bazı kısımları koyacağım. Özetlerin parça parça ve asıl metinin kısaltılmış hali olmasından dolayı, bir telif hakkı ihlaline sebep olmayacağını ümit ediyorum.
Adım cümleleri, her zaman aynı gramer formunda yazılır. Basit tek aktif eylemden oluşan bir cümle:
"User enters name and address."
"At any time, user can request the money back."
"The system verifies that the name and account are current."
"The system updates the customer’s balance to reflect the charge."
1. İlke: Özne - zarf - tümleç - yüklem
2. İlke: Topu kimin attığı çok açıktır.
3. İlke: 3. kişinin gözüyle
İlk başlarda insanlar, sistemin gözünden etkileşimi yazıyor. Halbuki, ne sistem ne de kullanıcı. Üçüncü kişinin gözünden etkileşim tarif edilmeli.
4. İlke: Süreç sürekli olarak ileri doğru ilerler
Her bir adım, ana use casedeki amaçtan bir alt seviye amaca sahiptir.
Before:
1. System asks for name.
2. User enters name.
3. System prompts for address.
4. User enters address.
5. User clicks ’OK’.
6. System presents user’s profile.
After:
1. User enters name and address.
2. System presents user’s profile.
Eğer çok sayıda veri girişi varsa, bunları ayrı ayrı satırlarda madde madde yazabilirsiniz:
Acceptable variant 1:
3. Customer enters name, address, phone number, secret information, emergency contact
phone number.
Acceptable variant 2:
3. Customer enters
- name
- address
- phone number
- secret information
- emergency contact phone number
5. İlke: Bir eylemler kümesidir
Jacobson, bir adımı, alt seviye bir transaction olarak tanımlıyor. Bir transaction çeşitli alt eylemlerden oluşur:
1. Ana aktör bir talepte bulunur ve sisteme veri gönderir.
2. Sistem talebin ve verinin geçerliliğini onaylar
3. Sistem iç durumunu değiştirir
4. Sistem, aktöre sonucu gönderir.
Bütün bu dört eylemi, tek bir adım içinde de anlatmak mümkündür, ayrı ayrı da. Hangi yolun daha iyi olacağı, adımın karmaşıklığına bağlıdır. Aşağıdaki örnekte, aynı adımın farklı şekillerde parçalanması görülüyor:
Version 1.
1. The customer enters the order number. The system detects that it matches the winning number
of the month, registers the user and order number as this month's winner, sends an email to
the sales manager, congratulates the customer and gives them instructions on how to collect
the prize.
Version 2.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month, registers the user and
order number as this month's winner, sends an email to the sales manager, congratulates the
customer and gives them instructions on how to collect the prize.
Version 3.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner, sends an email to
the sales manager, congratulates the customer and gives them instructions on how to collect
the prize.
Version 4.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner, and sends an email
to the sales manager.
4. The system congratulates the customer and gives them instructions on how to collect the
prize.
Version 5.
1. The customer enters the order number.
2. The system detects that it matches the winning number of the month.
3. The system registers the user and order number as this month's winner.
4. The system sends an email to the sales manager.
5. The system congratulates the customer and gives them instructions on how to collect the
prize.
1. versiyon çok karmaşık. 2. versiyon genellikle basit adımlar için uygun. 3. versiyon bu örneğe iyi oturdu. 4. ve 5. versiyonlar da iyi.
6. İlke: Kontrol etmez, onaylar
Sistem bir iş kuralının geçerli olduğunu onaylar. Birçok zaman bunun yerine, sistem şu koşulu kontrol eder, ifadesi kullanılıyor. Bu ifade, süreci açıkça bir adım iletletmiyor. Kontrolün sonucu belli değil. Bir amaç ifade etmiyor. Bunun ardından, şunu yazmak gerekiyor: "Eğer kontrol geçerse ..." "Eğer kontrol geçmezse ..."
Niçinini sorarsak bu tarz ifadeleri düzeltebiliriz. Sistem niçin koşulu kontrol ediyor? Bir kuralın geçerli olduğunu sabitlemek, onaylamak veya temin etmek için.
Before:
2. The system checks whether the password is correct
3. If it is, the system presents the available actions for the user.
After:
2. The system validate that the password is correct
3. The system presents the available actions for the user.
7. İlke: Zamanlama opsiyoneldir
Çoğu adım birbirini takip eder. Ama gerektiğinde bir adımın ne zaman gerçekleşeceğini belirtebilirsiniz.
3 ve 5. adımların arasında, kullanıcı şunu yapar...
Kullanıcı şunu yaptığında, sistem bunu yapar.
8. İlke: İfade: "Kullanıcı, A sistemine B sisteminde iş yaptırtır."
Birçok zaman tasarladığımız sistemin, başka bir sisteme bir iş yaptırtması gerekir. Bu durumda, şöyle diyemeyiz: "Kullanıcı Verileri Çek düğmesine basar. Sistem verileri, MRP sisteminden talep eder."
Bu kullanıcı arayüzü detaylarını açığa çıkarmak olurdu.
İki adım olarak yazabiliriz:
4. User signals to the system to fetch data from system B.
5. The system fetches the background data from system B."
Doğru olsa da, bu uzundur. Daha kolayı:
4. User has the system fetch the z data from system B.
9. İlke: İfade: "x-y adımlarını ... koşuluna kadar tekrarla"
Düz metinle yazıyor olmamızın bir katkısı, tekrarlanan işlemleri, daha kolay bir şekilde ifade edebiliyor olmamızdır.
Tek adım tekrarlanıyorsa:
"Kullanıcı bir veya daha çok ürün seçer."
"Kullanıcı çeşitli ürün katalogları arasından istediği ürünü buluncaya kadar dolaşır."
Eğer birkaç adım tekrarlanacaksa, tekrarlanan bloğun öncesine veya sonrasına tekrarlama ifadesini yaz. Sonrasına yazmak daha kolay anlaşılır.
1. Customer supplies either account identifier or name and address.
2. System brings up the customer's preference information.
3. User selects a item to buy, marks it for purchase.
4. System adds the item to the customer's "shopping cart".
Customer repeats steps 3-4 until indicating that he/she is done.
5. Customer purchases the items in the shopping cart (see use case xxx).
Tekrarlama ifadesini numaralandırmadık. Böylesi daha okunaklı.
Tekrarlamanın bir türü de, x-y adımlarının herhangi bir sırada meydana geleceğini belirtmektir:
1. Müşteri login olur
2. Sistem mevcut ürünleri ve servisleri sunar.
2-4. adımlar herhangi bir sırayla gerçekleşebilir
2. Kullanıcı satın alacağı ürünleri seçer.
3. Kullanıcı ödeme biçimini belirtir.
4. Kullanıcı nakliye adresini verir.
5. Kullanıcı alışverişin bittiğini işaretler
6. Sistem siparişi başlatır. Seçili ürünleri, tercih edilen ödeme biçimine borçlandırır ve nakliye adresine yollar.
Salı, Ocak 03, 2006
Kapsamli Bir Analiz Yontemi: Volere
Hafta sonu ODTÜ'nün kütüphanesinden Suzanne ve James Robertson'ın "Mastering The Requirements Process" adlı kitabını almıştım. Çok güzel bir kitap. Özellikle yazılım sektöründen çıkılarak yazılmış olmakla birlikte, yeni bir sistem veya ürün geliştirme işiyle uğraşan herkese öneririm.
Yöntem anlatan kitapların ne yazık ki az bir kısmı faydalı bir bilgi veriyor. Pek çok kitap ya çok detaya gömülmüş, ya da işe yarar bilgiler içermeyen çok genel ve muğlak bir anlatıma sahip. Robertson'ların kitabı bu yönlerden çok iyi. Hem kapsayıcı bir teoriyle, analiz işinin bütününün resmini gösteriyor. Hem de çok fazla örneklerle anlatımı zenginleştirerek, ne demek istendiğini çok net bir şekilde somutlaştıyor.
Kitap Volere adını verdikleri bir analiz yöntemini anlatıyor. Bu yöntem, bir sistemin gereksinim analizini yaparken, hem izlemeniz gereken süreci adım adım anlatıyor, hem de nihai olarak üretilecek gereksinim spesifikasyon (requirements specification) dokümanının içeriğine yönelik bir şablon sunuyor. Anlatılan süreç, bu dokümanın içeriğine ait bilgilerin hangi aşamalarda nasıl toplanacağını gösteriyor.
Buraya önerdikleri gereksinim spesifikasyon dokümanının şablonunu Türkçe olarak aktarıyorum. (Umarım yazarlar bundan dolayı şikayetçi olmazlar :))
Sistem Kısıtlamaları - tüm sistemi belirleyen kısıtlamalar
1 Sistemin amacı - sistemi geliştirme amacı ve sağlayacağı iş faydası
2 Müşteri ve diğer paydaşlar - sistemle ilgisi olan kişiler
3 Sistemin kullanıcıları - son kullanıcılar
4 Gereksinim kısıtlamaları - çözüme ait kısıtlamalar
5 İsimlendirme uzlaşıları ve tanımlar - terimlerin net anlamları
6 İlgili veriler - sistem üzerinde etkisi olan, dış dünyaya ait veriler
7 Varsayımlar - proje ekibinin yaptığı varsayımlar
Fonksiyonel Gereksinimler - sistemin davranışına ait gereksinimler
8 Sistemin kapsamı - sistemin ele aldığı iş olaylarının sınırı ve yan sistemler/aktörler
9 Fonksiyonel ve veri gereksinimleri - sistemin yapması gereken işlevler ve tutması gereken kayıtlar
Fonksiyonel Olmayan Gereksinimler - sistemin davranış dışı özellikleri
10 Görünüm gereksinimleri - amaçlanan görünüm
11 Kullanışlılık gereksinimleri - son kullanıcıların sistemi kullanabilmesi için gereken özellikler
12 Performans gereksinimleri - ne kadar hızlı ve ne kapasitede
13 Operasyonel gereksinimler - sistemin kullanılacağı fiziksel ortamın gerektirdiği özellikler
14 Bakım ve taşınabilirlik gereksinimleri - sistemin ne kadar değişime uygun olduğu
15 Güvenlik gereksinimleri - sistemin güvenliği, gizliliği ve ürettiği verilerin doğruluğu
16 Kültürel ve politik gereksinimler
17 Yasal gereksinimler - kanunlara uygunluk
Diğer Proje Konuları
18 Açık noktalar
19 3. parti çözümler
20 Yeni sorunlar - sistemin işler hale gelmesiyle ortaya çıkacak sorunlar
21 Productiona geçiş için gerekli işler
22 Geçiş süreci - mevcut sistemden geçiş için yapılması gereken işler
23 Riskler - projenin karşılaşması muhtemel riskler
24 Maliyetler - projeyi geliştirme maliyetine dair ilk tahminler
25 Kullanıcı dokümantasyon planı - kullanıcılara yönelik kılavuzları geliştirme planı
26 Bekleyen gereksinimler - gelecek sürümlere eklenebilecek gereksinimler
Yazarlar, bu gereksinimlerin nasıl toplanacağına yönelik çok detaylı bir süreç tarif ediyorlar. Her bir gereksinimin toplanmasında dikkat edilecek noktalara ve yardımcı olacak araçlara değiniyorlar.
Kitapta bahsedilen gereksinim toplamada kullanılan araçlardan biri, yazarların Requirement Shell olarak adlandırdıkları, benim Gereksinim Kartı diye çevirdiğim bir araç. Her gereksinim, ilk akla geldiğinde bu karta yazılıyor. Kartta şu alanlar bulunuyor:
Gereksinim Kartı
Başlık:
Gereksinim No:
Gereksinim Tipi:
Olay/Use Case No:
Açıklama:
Gerekçe:
İlk Bildiren:
Kabul Kriteri:
Müşteri Memnuniyeti:
Müşteri Memnuniyetsizliği:
Bağımlılıklar:
Çatışmalar:
Kaynaklar:
Tarihçe:
Bütün bu alanların gereksinimin ilk kaydedildiği anda doldurulması gerekmiyor. Sadece gereksinimi unutmamak önemli olan. Gereksinimin bağlı olduğu olay ve use case numaralarıyla ilişkileri burada kaydedilerek, bütün gereksinim analizi, iş olaylarının ve use caselerinin etrafında yapılandırılıyor.
Kullanılacak analiz sürecini yazarlar çok kapsamlı olarak tarif ediyorlar. Ben biraz bunu oldukça basitleştirerek kendime göre bir süreç çıkardım. O da şu şekilde:
Analiz Süreci
Sanırım burada yazdığım başlıklar belki ilk bakışta pek anlamlı görünmeyecektir. Ancak resmin bütününü tek bir blog yazısında göstermek istediğimden detaylara giremiyorum. Umarım ilerideki yazılarımda fırsat buldukça bunların detaylarına girebilirim. Ancak bu arada siz eğer bulabiliyorsanız kitabı okuyabilir veya http://www.volere.co.uk/ adresinden daha detaylı bilgi alabilirsiniz.
Cuma, Aralık 30, 2005
Compile Edilmis Kodlarin Versiyon Yonetimi
Compile edilmiş kodlar konfigürasyon yönetim (veya versiyon kontrol) aracı tarafından yönetilmeli mi, yönetilmemeli mi? Farklı yazılım ekipleri, bu soruya farklı cevap veriyor. Bazı ekipler, compile edilmiş dosyaları da konfigürasyon yönetim aracında saklıyor, bazı ekipler sadece kaynak kodlarını saklıyor.
Ben, sadece kaynak kodlarını konfigürasyon yönetim aracında saklamanın doğru olduğu görüşündeyim. Bu konuyla ilgili, “Pragmatic Version Control with Subversion” kitabından bir alıntıyı aşağıya kopyalıyorum. Aşağıdaki alıntıda otomatik olarak üretilen tüm dosyalar (compiled classlar ve diğerleri) ele alınmış:
What about Generated Artifacts?
If we store all the things needed to build the project,
does that mean we should also be storing all the generated
files? For example, we might run JavaDoc to
generate the API documentation for our source tree.
Should that documentation be stored in the version
control system’s repository?
The simple answer is “no.” If a generated file can
be reconstituted from other files, then storing it is simply
duplication. Why is this duplication bad? It isn’t
because we’re worried about wasting disk space. It’s
because we don’t want things to get out of step. If we
store the source and the documentation, and then
change the source, the documentation is now outdated.
If we forget to update it and check it back
in, we’ve now got misleading documentation in our
repository. So in this case, we’d want to keep a single
source of the information, the source code. The same
rules apply to most generated artifacts.
Pragmatically, some artifacts are difficult to regenerate.
For example, you may have only a single license
for a tool that generates a file needed by all the
developers, or a particular artifact may take hours to
create. In these cases, it makes sense to store the
generated artifacts in the repository. The developer
with the tool’s license can create the file, or a fast
machine somewhere can create the expensive artifact.
These can be checked in, and all other developers
can then work from these generated files.
Yukarıda yazılanların dışında, tek tek compile edilmiş tüm *.class dosyalarını (yani her bir kaynak kodu dosyasına karşılık gelen compile edilmiş bytecode dosyaları*) KY (Konfigürasyon Yönetim Aracı) ile takip etmek, özellikle check-out ve check-in işlemleri sırasında zahmetli olacaktır. Çünkü bir programcı bir kaynak kodu dosyasında (*.java) değişiklik yaptığı vakit, bu kaynak kodundan üretilen tüm compile edilmiş *.class dosyalarını da check-out etmek ve sonra kaydederken yeniden check-in etmek zorunda kalacaktır. Eğer *.class dosyalarını check-in etmeyi unutursa, başka bir programcının aynı *.class dosyasını tekrar “exclusively check-out” etmesi mümkün olmayacaktır. Eğer bir *.java dosyasında çok sayıda anonim dahili sınıflar (anonymous inner class) varsa, bu *.java dosyasına karşılık gelen çok sayıda *.class dosyasının tümünü birden check-out ve check-in etmesi gerekecektir. Ki bütün bu işlemler pratik olarak çok yorucu olacaktır.
Bir çözüm, tüm *.class dosyaları yerine sadece nihai olarak deploy edilen uygulamayı (EAR dosyasını) KY sisteminde yönetmektir. Bu yukarıda anlattığımdan daha az yorucu bir işlem olacaktır. Ancak yine de bu işlemin de faydası, sebep olduğu ek zahmeti karşılamayacaktır. Sebebini açıklayayım: Bir anda, bir dosya KY prensiplerine göre en fazla bir kişi tarafından kilitlenebilir, yani check-out edilebilir. Dolayısıyla, aynı anda iki kişi, kendi kodlarını compile edip EAR dosyasını deploy etmesi mümkün olmayacaktır. Buna bir çözüm şu olabilir, EAR dosyalarının KY sisteminde tutulduğu klasör, programcıların otomatik olarak EAR dosyasını ürettikleri yerden farklı bir klasör yapılır. Bu durumda her programcı kendi EAR dosyasını oluşturup deneyebilir. Çözümden emin olduğu vakit, EAR dosyasını KY sistemine yükler. Ancak bu programcının kendi kaynak kodlarını check-in etmesinden farklı bir işlem olacağından, programcı tarafından yapılması unutulabilir. Daha sonra bu EAR dosyası production ortamına yüklenirse, yanlış uygulama yüklenmiş olur.
Bu konuyla ilgili aslında çok senaryolar üretilebilir. Bu bahsettiğim problemlere farklı çözümler getirilebilir. Ancak bu çözümler de yine başka problemlere sebep olacaktır. Sonuçta en kısa şekilde bu sorunu çözen, yazılım geliştirmede çok kullanılan bir ilkeyi uygulamak olacaktır, diye düşünüyorum: Asla aynı şeyin iki kopyasını oluşturma (Don’t repeat yourself). Bu ilke, DRY diye de kısaltılıyor. Compile edilmiş kodlar, kaynak kodlarından otomatik olarak üretilebildiğinden, aynı modelin iki farklı görünümü gibidir. Dolayısıyla her ikisinin birden KY üzerinde tutulması, bir düplikasyondur (duplication).
Eğer compile edilmiş kodları bir şekilde KY sisteminde yönetmeye çalışırsak, karşılaştığımız problemleri çözmek için, çeşitli hackler uygulamamız gerekecek. Bu tür hackler birike birike proje yönetimini zorlaştıracaktır. Bakım maliyetlerinin yükselmesine sebep olacaktır.
Compile edilmiş uygulamanın ve kaynak kodlarının KY sisteminde tutulmasının getireceği avantajlar ise, aslında düşünüldüğü kadar çok değil. Bunun sağlayacağı birinci avantaj zamandan tasarruf etmektir. Ancak EAR dosyasını sıfırdan üretmek, toplam bir iki dakikalık bir işlem. Bu da pratik olarak bir sorun oluşturmaz.
İkinci bir avantaj, farklı ortamlarda üretilen EAR dosyalarının bozuk olabilme ihtimaline karşı bir tedbir oluşturmak. Ancak aslında biz farklı ortamlarda bile bozuk EAR dosyalarının üretilmesine engel olmak için zaten KY sistemini kullanıyoruz. Eğer bizim KY sistemimiz üzerinde çalışan otomatik bir script tüm kaynakları compile edip, çalışır durumdaki EAR uygulamasını oluşturmuyorsa, o zaman bizim KY sistemimiz zaten temelden kusurlu demektir.
Üçüncü bir avantaj, compile edilmiş uygulamadan kaynak kodlarına ve oradan dizayn ve analiz dokümanlarına kadar dosyaların aralarındaki ilişkileri yönetmek olabilir. Ancak burada da şu nokta gözden kaçıyor. Labelling mekanizmasıyla biz zaten productiona aktarılan uygulamanın hangi kaynak kodlarına ve oradan hangi dizayn ve analiz dosyalarına ilişkili olduğunu takip edebiliyoruz. Dolayısıyla, compile edilmiş kodları eklemek ek bir traceability imkanı sunmuyor. Zaten labelling mekanizması bu traceability problemini çözüyor.
* C, .Net gibi farklı ortamlarda compile edilmiş dosyaların isimleri farklıdır. Ama temel mantık hepsinde aynı. EAR yerine bu ortamlarda DLL, EXE veya farklı bir uygulama dosyası uzantısı bulunabilir.
Kayıtlar
