İş Akışı Spesifikasyonu
Çözümün desteklemesi gereken adımların, karar noktalarının, istisnaların ve devretmelerin tam sırası — keşif sırasında oluşturulan Current-State Workflow Model’e dayanır; yeniden kurgulanmış ideal bir süreç değildir.
Çözüm Tasarımı · 03. Adım · Çalışma Biçimimiz
Spesifikasyon tahmin değildir.
Strateji ve Mimari, bir sistemin nasıl yapılandırılacağını belirler. Çözüm Tasarımı ise tam olarak neyin inşa edileceğini tanımlar — bir mühendislik yönünü ekibin gerçekten oluşturabileceği hâle getiren belirli iş akışları, arayüzler, veri sözleşmeleri ve hata davranışları.
Bu aşama uygulamayla başlamaz. Üretim kodundan tek bir satır yazılmadan önce kanıtlarla test edilmiş bir spesifikasyonla başlar.
Bu soru değil
"Ne inşa etmeliyiz?"
Bunun yerine şu soru
"Bu spesifik tasarım, gerçek koşullar altında gerçekten beklediğimiz gibi davranıyor mu — ve bunu inşa etmek için mühendislik çabasını taahhüt etmeden önce kanıtlayabiliyor muyuz?"
Tasarım · Prototip · Test · Ölçüm · Spesifikasyon
Neden Tasarım, Mimarinin Ardından Gelir
Bir yapı henüz bir sistem değildir.
Önceki aşamanın referans mimarisi katmanları, teknoloji tercihlerini ve yatay endişeleri tanımlar. Ancak bir isteğin belirsiz olduğu durumda belirli bir iş akışının nasıl davranacağını ya da bir entegrasyon hatalı veri döndürdüğünde ne olacağını henüz belirtmez. Çözüm Tasarımı bu boşluğu kapatır — aksi takdirde "mimari" bir diyagram olarak kalır, gerçek bir sistem olmaz.
Referans Mimari → Çözüm Spesifikasyonu
Neden Tasarım Titizliği Önemlidir
Bir hatanın maliyeti geçtiği her aşamada artar.
Barry Boehm'un yazılım mühendisliği ekonomisi üzerine araştırmaları — ilk olarak 1976'da yayımlandı ve 1981'deki Software Engineering Economics kitabında genişletildi — bir kusurun düzeltilme maliyetinin, ne kadar geç keşfedilirse o kadar önemli ölçüde arttığını gösterdi.
~1×
Tasarım aşamasında yakalanan bir hatayı düzeltme maliyeti.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Aynı hatayı üretim sonrası düzeltme maliyeti (proje ölçeğine bağlı olarak).
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Bu bulgu son yıllarda yeniden ele alındı. Boehm ve Basili'nin 2001'deki incelemesi, güçlü test uygulamaları ve sürekli teslimata sahip, küçük ve hızlı yinelemeli ekiplerde eğrinin anlamlı biçimde daha düz olduğunu gösterdi. Çarpan evrensel değildir ve biz de öyle kabul etmiyoruz.
Ama bulgunun yönü değişmedi: bir tasarım hatasını inşa edilmeden önce yakalamak, inşa edildikten sonra yakalamaktan daha ucuzdur. Bu yüzden OpenQCore, prototipleme ve testleri tasarımın bir parçası olarak görüyor — yapım başladıktan sonra yapılan bir aşama olarak değil.
Mimariden Spesifikasyona
Katmanları, bir ekibin üzerine inşa edebileceği kararlara dönüştürmek.
Önceki aşamadaki her mimari karar somut spesifikasyonlara dönüştürülür.
Arayüz Spesifikasyonu
Her kullanıcı, sistem veya ajanın gerçekten gördüğü, gönderdiği ve aldığı şeyler — ekranlar, konuşma akışları, API sözleşmeleri ve her adımda önemli olan alanlar.
Veri Sözleşmesi Spesifikasyonu
Bileşenler arasında aktarılan verinin kesin yapısı, doğrulama kuralları, versiyonlama yaklaşımı ve sahipliği.
Davranışsal Spesifikasyon
Sistemin normal koşullarda, uç vakalarda ve hata durumlarında ne yaptığı — ve açıkça ne yapmadığı.
Çıktı
Çözüm Spesifikasyonu (Taslak)
İş Akışı ve Etkileşim Tasarımı
İşi tasarlayın, sadece arayüzü değil.
Arkasında sorun olan bir iş akışının üstüne konan konuşma arayüzü problemi çözmez; sadece örter ve alttaki kısıtlama er ya da geç başka bir yerde yeniden ortaya çıkar.
Çözüm Tasarımı, keşif sırasında toplanan iş akışı kanıtlarından başlar ve arayüz sorusundan önce yapısal bir soru sorar: Bu süreçte hangi adımlar otomatikleştirilmeli, hangileri insan kontrolünde kalmalı ve sorumluluk tam olarak nerede devrediliyor? Bunu açıkça haritalandırıyoruz; böylece insan müdahalesi gerektiren noktalar teknolojinin rasgele yeteneklerinin sonucu değil, kasıtlı tasarım kararları olur.
İnsan Müdahalesi Noktaları
Tasarımsal olarak insan incelemesi, değerlendirmesi veya onayı gereken açık kontrol noktaları — ihmalin sonucu değil.
Otomasyon Sınırları
Bir sistemin insan onayı olmadan karar verebileceği veya yürütebileceği işler için kesin tanımlı sınırlar.
İstisna Yolları
Normal işleyişin dışında kalan durumlar için tasarlanmış yönlendirmeler — sessiz başarısızlıklar veya varsayılan geri dönüşler değil.
Prototipleme ve Deneysel Çalışmalar
Tasarımı bitmiş bir cevap olarak değil, test edilebilir bir hipotez olarak ele alın.
OpenQCore, erken aşama tasarımı tasarım biliminin bilgi sistemleri eserine yaklaştığı şekilde ele alır: yalnızca estetiği için övülecek bir nesne değil, gerçek bir probleme karşı değerlendirilebilmek için özellikle inşa edilmiş bir şey. Hevner ve diğerlerinin etkili çalışması 'Design Science in Information Systems Research' (MIS Quarterly, 2004) tarafından resmileştirilen bu yaklaşım, eseri ve onun değerlendirmesini ayrılmaz kabul eder. Keşifte kullandığımız hipotez odaklı akıl yürütmeyi tasarım düzeyinde de uygularız.
01
Tasarım
Belirli, yanlışlanabilir bir tasarım kararı — belirsiz bir yönlendirme değil.
02
Prototip
Kararı test etmek için yeterli düzeyde çalışan bir temsil — mutlaka üretim kalitesinde olması gerekmez.
03
Temsili Verilerle Test
Gerçek veya gerçeğe uygun temsili girdiler; başarıyı kolaylaştırmak için seçilmiş idealize örnekler değil.
04
Temele Karşı Ölçüm
Keşif sırasında belirlenen referans temel ve başarı kriterlerine göre yapılan karşılaştırma — kaliteyle ilgili öznel bir izlenim değil.
05
İyileştir veya Reddet
Tasarım, testin gösterdiklerine göre korunur, değiştirilir veya vazgeçilir — harcanan emek miktarına göre değil.
Bir prototipin amacı tasarımın teoride işe yaradığını göstermek değil; bitmiş sistemin gerçek koşullarında gerçekten güvenilir şekilde çalışıp çalışmadığını belirlemektir.
Veri ve Arayüz Spesifikasyonu
Buradaki hassasiyet ileride belirsizlikleri önler.
Entegrasyon hataları nadiren tek bir bariz yanlış karardan çıkar. Çoğu kez belirsizlikten kaynaklanır — her zaman mevcut olduğu varsayılan bir alan, kimsenin yazmadığı bir hata durumu, planlanmamış bir sürüm uyuşmazlığı gibi.
Şema TanımlarıDoğrulama KurallarıHata ve İstisna YönetimiSürümlendirme Stratejisiİstek Hızı ve Yük SınırlarıKimlik Doğrulama ve Yetkilendirme SözleşmeleriIdempotentlik Gereksinimleri
Bu kasıtlı olarak gösterişsiz bir iştir. Ancak demo'da iyi görünen bir sistemin üretimde, altı entegrasyon ve on sekiz ay sonra da iyi çalışıp çalışmayacağını belirleyen iş de budur.
Sadece Başarıyı Değil, Hataları da Hesaba Katan Tasarım
Her demo başarılıdır. Her sistem ise değil.
Çoğu tasarım hatası ideal akışın başarısızlığından kaynaklanmaz; bir şey ters gittiğinde ortaya çıkan süreçlerin başarısızlığından doğar — üst sistem zaman aşımına uğrar, bir belge düzgün çıkmaz, model belirsiz kalır, kullanıcı beklenmedik bir şey yapar. OpenQCore bu durumları üretimde keşfetmek yerine kasıtlı olarak tasarlar.
Belirsizlik Yönetimi
Çıktıya olan güven düşük olduğunda sistemin nasıl davrandığı — bunu bildirip bildirmeyeceği ve nasıl bildireceği de dahil.
Kademeli Bozulma
Bir bağımlılık başarısız olduğunda tam sistem kesintisi yerine hangi işlevlerin kullanılmaya devam edeceği.
Eskalasyon Tasarımı
Bir vakayı insana devretme koşulları ve bu devrin beraberinde taşıdığı bağlamın ne olduğu.
Kötü Niyetli ve Uç Durum Davranışı
Sistem hatalı biçimlendirilmiş girdiler, beklenmedik sıralamalar veya suistimal girişimleriyle karşılaştığında nasıl davranır — sadece düzgün biçimli isteklerle sınırlı değil.
Hiç 'bu başarısız olursa ne olur?' diye sorulmamış bir sistem aslında tasarlanmamıştır; sadece gösterilmiştir.
İnşa Öncesi Tanımlanan Doğrulama Kriterleri
Kabul kriterleri koddan sonra değil, önce belirlenir.
Keşif aşamasında belirlenen — başarının uygulanmadan önce tanımlanması gerektiği — ilkesine uygun olarak, Çözüm Tasarımı üretime başlanmadan önce açık, yazılı kabul kriterleri ve bir test planı oluşturur.
Fonksiyonel Kabul Kriterleri
Çözümün doğru olarak yapması gerekenler, test edilebilir terimlerle tanımlanır.
Fonksiyonel Olmayan Kabul Kriterleri
ISO/IEC 25010 yazılım ürün kalite modeline göre düzenlenen; performans verimliliği, güvenilirlik, kullanılabilirlik, güvenlik ve bakım kolaylığı gibi kabul görmüş yazılım kalite özellikleriyle uyumlu olarak, genel temenniler yerine ölçülebilir hedefler şeklinde belirlenir.
Test Planı
Çözümün üretim için inşa edilmeye hazır sayılmadan önce değerlendirileceği özel senaryolar, veri setleri ve koşullar.
Tasarım İnceleme Geçidi
Tasarım bir kararla sonlanır — otomatik bir onay değil.
Bu uygulamanın örneği vardır: Michael Fagan'ın 1976'da IBM'de tanıttığı resmi tasarım ve kod inceleme yöntemi, yapılandırılmış, kriter bazlı incelemenin gayri resmi onaya kıyasla kusurları daha erken ve daha güvenilir şekilde yakaladığını gösterdi. OpenQCore aynı ilkeleri çözüm tasarımına uygular.
Geliştirmeye Geç
Şartname yeterince kesin, prototip değerlendirme kriterlerini karşıladı ve geliştirme başlayabilir.
Tasarımı Yinele
Ana yön doğru, ancak testlerin ortaya koyduklarına göre bazı bileşenlerin revize edilmesi gerekiyor.
Mimariye Geri Dön
Tasarım çalışması, mimarinin hesaba katmadığı bir kısıtı ortaya çıkardı — doğru yaklaşım yapıyı yeniden düzenlemek; sorunu etrafından tasarım yaparak geçiştirmek değil.
Riski Üstlere Taşı
Tasarım çalışması teknik, operasyonel, güvenlik veya etik bir risk ortaya çıkardı; ilerlemeden önce tasarım ekibinin yetkisinin üstünde bir karar gerektiriyor.
Her zaman "evet" diyen bir tasarım geçidi gerçek bir geçit değildir.
Çözüm Tasarımının Çıktıları
Ekibin Gerçekten İnşa Edebileceği Şartnameler.
İş kapsamına bağlı olarak bu aşama şunları üretir:
Çözüm Spesifikasyon Belgesi
Tekrar niyet çıkarımı gerektirmeyecek kadar ayrıntılı iş akışları, arayüzler, veri sözleşmeleri ve davranış tanımları.
Etkileşim ve İş Akışı Diyagramları
Süreç akışının görsel gösterimleri; insan müdahalesinin gerektiği noktalar açıkça gösterilir.
API ve Veri Sözleşmeleri
Bileşenler arasındaki her arayüz için şemalar, doğrulama kuralları ve sürümleme stratejisi.
Prototip Değerlendirme Raporu
Nelerin test edildiği, hangi temel/ölçütlere göre değerlendirildiği ve sonuçların neleri destekleyip neleri elediği.
Hata Modu Analizi
Her bir arıza koşulu ve buna karşı tasarlanmış sistem tepkisinin belgelendirilmesi.
Kabul Kriterleri ve Test Planı
Çözümün dağıtımdan önce sağlaması gereken, belirli ve ölçülebilir şartlar.
Tasarım'dan Geliştirme ve Entegrasyona
Spesifikasyon Henüz Yazılım Değildir.
Çözüm Tasarımı, test edilmiş ve doğrulanmış bir spesifikasyon üretir — tamamlanmış bir sistem değil. Bir sonraki aşama, bu spesifikasyonu çalışır durumda, birlikte çalışacağı sistemlerle entegre edilmiş yazılıma dönüştürür.
Çözüm Spesifikasyonu → Prototip Değerlendirmesi → Kabul Kriterleri → Geliştirme ve Entegrasyon
Adım 04
Geliştirme ve Entegrasyon
Tanımlanmış çözümü, belirlenmiş kabul kriterlerine göre oluşturun — varsayımlara dayanarak değil.
Araştırma ve Metodolojik Kaynaklar
Boehm, B. — Software Engineering Economics (1981); Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
Yukarıda atıf yapılan değişim maliyeti bulgularının kaynağı; küçük, hızlı yinelemeli ekipler için daha düz bir eğri gösteren sonraki revizyonu de içerir.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in Information Systems Research," MIS Quarterly (2004)
Bilgi sistemleri artefaktını ve değerlendirmesini ayrılmaz olarak ele alan temel çerçeve — yukarıda bahsedilen prototip-test-iyileştirme döngüsünün temelidir.
Fagan, M. — "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal (1976)
Kriterlere dayalı yapılandırılmış tasarım incelemesinin resmi bir mühendislik uygulaması olarak kökeni; yukarıdaki Tasarım İnceleme Kapısı'nda atıfta bulunulmuştur.
ISO/IEC 25010:2011 — Sistem ve Yazılım Kalite Gereksinimleri ve Değerlendirmesi (SQuaRE) — Sistem ve Yazılım Kalite Modelleri
Yukarıdaki kabul kriterlerinde bahsedilen fonksiyonel olmayan kalite özelliklerinin kaynağı.