Erol Bozkurt i-con erolbozkurt@i-con.com.tr UML ve İş Analizi Erol Bozkurt i-con erolbozkurt@i-con.com.tr

İçerik Karanlıkta ... Tabandan Gelen bir Çözüm Projeyle Birlikte ‘Büyümek’ Sözün Özü

Başlamadan UML’in yazılım mühendisliği projelerine etkisini gerçekten anlayabilmek için nelere etkisi olduğunu anlamak gerekir. Kısaca ifade etmek gerekirse etkisi geliştirilecek ürünün niteliklerinin çok ötesindedir.

Çözümlerin Sınırları Melvin E. Conway “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.” Melvin E. Conway www.melconway.com/research/committees.html

Aynı / Ayrı Dünyalar Biz Ayrı Dünyaların İnsanlarıyız ;o) Biz Ayrılamayız ;o) http://en.wikipedia.org/wiki/Many-worlds_interpretation

Takım: Aynı Dünya Nasıl? "Bir takım sahışların birbirlerini tamamlayıcı özelliklerinin ortak bir amaca yöneltildiği, performans ve kalite kriterlerinden hep birlikte sorumlu oldukları bir insan topluluğudur." Nasıl?

Ayrı Dünyalar Olmayan Tablonun Analizi Mutlu sonlara düşkün bir analist Beyanatı kesin olarak algılayan veritabanı tasarımcısı Söyleneni yapan programcı Söylenmesi gerekeni bulmaya çalışan programcı (OTA v 2.0) Kibarca başımdan git demek isteyen müşteri (OTA v 2.0)

‘Aydınlama’ Döngüsü Otorite Mantık Zaruriyet Fayda İnsiyatif “Kendimizin Yeni Versiyonu!” Mel Conway Aydınlanma (Fikir) Aktarma (Dil) (Süreç) Kültür Süreç Memurluğu Dogma Otorite Mantık Zaruriyet Fayda İnsiyatif Edilgenlik Döngüye herhangi bir yerinden girmiş olabilirsiniz!

Dünyalar Arasında Yolculuk Hayal “inbetween” Gerçek

Anahtar olarak Risk Eğer şirketin risk duyarlılığı olgunlaşmışsa, riskler açıkca ve kimlik gizlemeksizin yönetime aktarılırlar. Yaklaşım olarak risk ve risk yönetimi gündelik işlerin bir parçası olarak görülür. Ayrıca, düzenli toplantılarla risk saptama çalışmalarının önemi vurgulanır ve katılımcılara bir riskin varlığını hisseder hissetmez bunu bildirmeleri önerilir. SEI Dokümanları

Riske Duyarlı Topluluklar Eskiden riskli konular biraz radikal bir şekilde bertaraf edilirdi. Jean d'Arc son duasını ederken görülüyor. Anahtara Erişim İhtimali Topluluğa Göre Değişir!

İçerik Karanlıkta ... Tabandan Gelen bir Çözüm Projeyle Birlikte ‘Büyümek’ Sözün Özü

İş Analizi Ortaklaşa Arayıştır Geliştirme Araştırma Programcı Analist

Gereksinim Yönetimi Analistin geliştirilecek yazılımın kapsamını, detaylı olarak çözümün yapısını derleme, bulma ve organize etmek için kullandığı tekniklerin tamamına Gereksinim Yönetimi diyoruz. UML sürecinde bu çeşitli şemalar ve dokümanlar demek oluyor.

Algının Üç Seviyesi Kara Kutu  Sistem / Alt Sistem Girdi, Çıktı (Siyahlarla beyazlar ...) Kalıplar (Süreçler)  Akışlar, SM/Nesne/Veri Grubu Girdi, Çıktı üzerinde İnce Ayar (Denek ...) Varsayımlar  Fayda (Use Case) Neden, Geçerlilik, Ufuk Kaynaşımı* * Birden fazla bakış açısına nüfuz edebilmek - Heidegger

İş Ürünleri Bu üçlü yapının son öğesi ise, [3] Üretilenler (Artifact): Tanımladığınız rollerin bir hedefe yönelik olarak yaptıkları çalışmalar neticesinde üretilen veya üretilmesine katkıda bulunulan iş ürünleridir. Bu iş ürünleri arasında proje süreci aşamaları ve disiplinler bazında bir ilişki yapısı mevcuttur.

Süreç Yapısı Değindiğimiz üçlü yapıyı hatırlayarak, UP yapısını özetlersek, Kademe 1: Süreç Tanımı çeşitli Disiplinlere bölünmüştür: İş Modeli, Gereksinimler, Analiz ve Tasarım vs. Kademe 2: Her Disiplin altında işlerin nasıl yapılacağını anlatan bir İş Akışı (Workflow) vardır. Kademe 3: Her İş Akışı altında bu akışın çeşitli detay bilgilerine sahip İş Akışı Detayları vardır. Kademe 4: İş Akışı Detayları altında yapılacak işle ilgili açıklamalar, şablonlar vs. bulunur. Kademe 5: Şablonlar UP’in son kademesini oluşturmaktadır.

Müşterinin probleminin tanımı Çözümün gerçekleştirilmesi Gereksinim Türleri İhtiyaç İşlev Gereksinim Gerçekleştirme Müşterinin probleminin tanımı Çözümün tanımı Daha detaylı Çözümün gerçekleştirilmesi

Anlaşma Müşteriyle sağlanan proje kapsam anlaşması proje vizyonudur. Paydaşlar Temel işlevler (feature list) Kısıtlamalar Kullanılacak standartlar vs.

Gereksinim Dokümanları Proje Vizyonu Detaylı Gereksinim Dokümanları Fonksiyonel Olan Gereksinimler Fonksiyonel Ol-ma-yan Gereksinimler Diğer İş Kuralları Risk Listesi Sözlük

Gereksinim Ürünleri (Artifact)

Kabaca Şemaların Kullanımı Activity Şeması (Genel İş Akışı) State Machine Şeması (Duruma Göre Davranış) Class Şeması (Domain Model) Vizyon Dokümanı (Paydaşlar, İşlevler) Use Case Şeması (Faydalar, Aktörler) Activity Şeması / UC Dokümanı (Detaylı Akışlar, Veri Yapısı, İş Kuralları, Kontroller)

Activity Şeması

State Machine Şeması

Class Şeması

Use Case Şeması

Analizin Sihirli Kelimeleri Risk Giderme Odaklılık Müşteri Memnuniyeti Odaklılık Ortaklaşa ve Zaman İçerisinde Eksiksizleşerek Başarı ve Başarısızlıkları Paylaşarak Manevra Kabiliyetimizi Koruyarak

İçerik Karanlıkta ... Tabandan Gelen bir Çözüm Projeyle Birlikte ‘Büyümek’ Sözün Özü

Proje Yönetimine Etkiler Proje Yönetimi bilinenlere bağlı bir yönetim şeklidir, oysa Risk Yönetimi bilinmeyenlerin nasıl yönetileceğiyle ilgilidir. Risk = Tehdit = Tuhaflık = Gerçekdışılık Kara Delik

Proje Yönetiminin Sihirli Kelimeleri Risk Giderme Odaklılık Müşteri Memnuniyeti Odaklılık Ortaklaşa ve Zaman İçerisinde Eksiksizleşerek Başarı ve Başarısızlıkları Paylaşarak Manevra Kabiliyetimizi Koruyarak ! Herkesin Sihirli Kelimeleri Aynı !

Eski Müşteri/Yazılım Ekibi İlişkisi Gereksinimleri ‘bitir’  kaynak değerlendirmesi yap proje planı yaz  taahhüt ver  planı uygula proje başarısızlığını gör  suçluyu ara  sonunda kabul edilebilecek bir çözüm sun (belki) Varsayımlar Gereksinimlerin, proje içeriğinin, kullanılacak teknolojinin eksiksiz ve gereken detay seviyesinde anlaşıldığını ... Çok isabetli tahminlerde bulunmanın mümkün olduğunu ... Detaylı bir planın yapılabileceği ve uygulanabileceği ... Eski müşteri – yazılım ekibi ilişkilerinde pek çok kez kazanan, kaybeden, yenen ve yenilen gibi terimler kullanabilirdik. Daha da ilginci bu iki grup (ve yazılım ekibi içerisindeki pek çok diğer grup) arasındaki sürtüşmeler grupları birbirinden ayıran kültürel öğelere dönüşerek, hatalı çalışma şekillerinin yanıltıcı bir yazılım süreç tanımına dönüştüğünü saptayabilirdik. MPP süreç tanımının son P’sini hatırlarsanız (People over All), bu UP’in en önemli hedeflerinden birisi olarak süreç tanımının merkezine oturmuştur. Hedeflenen birbiriyle yoruma açık olmayan, etkili bir şekilde haberleşebilen, birbirlerinden öğrenebilen ve birbirlerine yardımcı olan, zaman içerisinde bir kurum kültürü oluşturarak kaliteyi (kaliteli çalışma ortamı, kaliteli yazılım, vs.) bir yaşam tarzı haline getiren açık bir toplum hedeflenmektedir. Dolayısıyla UP’e yaklaşmaya karar verdiğinizde sahip olmanız gereken bir olgunluk seviyesi vardır: Hataları görünce kabullenebilmek.

‘Waterfall’ Yaklaşımının Sonuçları Sözde Sonuçlar Gerçek Sonuçlar Detaylı toplantılar yapılıyor /Toplantı notları yazılıyor Tasarım uygun gözüküyor. Detaylı bir spesifikasyon hazırlanıyor. Gereksinim kapsama yüzdesi (% 100) yüksek. Tasarım “suçu ispatlanana kadar masum.” Toplantılar ve dokümanlar karmaşık bir yazılım sisteminin gerçek risklerinin çok azına değiniyor. Elle tutulur bir delil yok. Yanıltıcı bir güvenlik hissi var. Pek azı n*(% 10) tasarımı yönlendiriyor. Gereksinimlerin hepsine nüfuz etme çabası kritik noktaları gözden kaçırıyor. Her zaman suçlu. Tasarım hatası ileride istemediğimiz bir zamanda ortaya çıkacak. Geleneksel waterfall yaklaşımında kullanılan bir yaklaşımın kilometre taşı tabir edilen bazı iş ürünlerinin ortaya çıkması olduğunu görürüz. Deneyimlerimiz bu tür iş ürünlerinin ortaya çıkmasının kafi başarı olarak kabul edildiğini ve bunun yanıltıcı bir başarı hissi olduğunu gösteriyor. Yine geleneksel yaklaşımlar altında çalışmaya alışmış proje yöneticileri iteratif yazılım geliştirme yaklaşımının programcılara eksiksiz bir gereksinim dokümanı verilmeden onları programlamaya ittiğini söyleyerek itiraz etmek eğilimindedirler. İteratif yaklaşımın ilk ortaya atıldığı günlerde, günümüzdeki başarısını tekrar tekrar kanıtlamış iteratif formüle (UP içindeki tanımı ve kullanımına) sahip olmadığınızda, geçerli olabilecek bir iddia.

Pareto Kanunu 80% 20% %20’lik emek faydanın %80’ini sağlar. Fayda Emek Üniversitedeki istatistik derslerinden hatırlayabileceğiniz Pareto Kanunu kısaca: Emek ile Fayda arasında devamlı olarak doğru orantılı bir ilişki kuramayacağımızı söyler. Bu kanuna göre % 20 emek harcayarak, hedeflediğiniz faydanın % 80’ine ulaşırsınız. Faydanın % 80’i üzerine geçmeye çalıştıkça harcadığınız emek çok daha fazla oranda artar: Bir Türkçe deyimle, astarı yüzünden pahalıya gelir.

Yazılım Problemi: İki nokta arasındaki en kısa yol Buradan Buraya Nasıl gideceğiz? Düşündüğümüz Güzergah Detaylı olarak oluşturulmuş planların uygulanabilirlikleri sıfıra yakındır. Bunun en büyük nedeni işin başında bilinmeyenlerin sayısının çok fazla olmasıdır: ‘Gerçek’ müşteri isteklerinin ortaya çıkarılması, Yaratıcılığın ve Çözüm oluşturmanın mahiyetinden dolayı sahip olduğu zorluklar, Takım elemanları arasındaki iletişim ve uyum problemleri, vs. vs. Projenin ilk Durumu Mevcut ‘malzemeler’, teknolojiler Elemanlar, kabiliyetleri, bilgileri Kaynak eksiklikleri Belirsizlikler Müşteriyi Tatmin Edebilecek Alan Katmadeğer: Kullanıcıya (kullanılabilirlik, performans, kalite) Maliyet (zaman ve para) Katmadeğer: Yazılım Geliştirici (kar, deneyim, satış, Pazar payı vs.)

İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi Müşteriyi Tatmin Edebilecek Alandaki Belirsizlik Planlanan Güzergah Her iterasyonla, müşterinin bizi gerçek ihtiyaçlarına yönlendirmesine izin veririz. Bu yöntem eksiksiz olarak gereksinimleri bulduğumuz yanılgısını ve inzivaya çekilerek anladığımız zannettiğimiz (ve gerçekte varolmayabilecek) problem ve çözümüne yönelik çalışmalara dalmamızı engeller. Sonuçta, iterasyon kendi çıkarlarımızı ve müşteri memnuniyetini aynı oranda korumamızı sağlayabilecek bir Manevra Mekanizmasıdır. Gerçek Güzergah Projenin ilk Durumu Planlanan İçerik

‘Waterfall’ Yönetimi: “Planla ve Takip Et” Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor. Planlanan Proje Bitişi Planlanan Güzergah Kuşkusuz waterfall yaklaşım altında da bir şekilde (bütçe ve zamanını aşarak) projeler müşteriyi tatmin eder hale gelmektedir. Bu negatif etkilerin en büyük nedeni “Detaylı Olarak Herşeyi Planla ve Takip Et” yaklaşımından kaynaklanmaktadır. Planlanmış içerik gerçek ihtiyaçlara karşılık gelmebilir. Eldeki gereksinimlere göre yapılan testlerin başarısı müşterinin ihtiyaçlarını karşılayacak bir çözümün geliştirildiği anlamına gelmeyebilir. Gerçek Güzergah Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu Gerçek Proje Bitişi

İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol” Devamlı olarak : Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendir Manevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız? Planlanan Proje Bitişi Gerçek Proje Bitişi Planlanan Güzergah Kulağa biraz felsefi gelmekle birlikte, izlenecek yol proje süresince tanımlanır. Bu yüzden iteratif yaklaşım altında liderlik ve insiyatif almak çok önemli özelliklerdir. Proje gelişimi süresince gerekli yerlerde manevralar yapmak ve gerçek hedefi ortaya çıkarmak gerekir. Gerçek Güzergah Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu

1. İterasyonların Belirlenmesi İnternet’te Açık Artırma Sistemi [1] İterasyonların Belirlenmesi İşlediğimiz konular dahilinde örneğimizi parçalara ayırmaya çalışacağız. Burada gereksinimler ve değişkenlerine tekrar değinmeyeceğiz. İncelediğimiz sistem: Kullanıcı’ların sisteme bağlanarak hesap açtıklarında Alıcı ve Satıcı olabildikleri bir internet’te açık artırma sistemidir. Olayların akışı özetle, Satıcıların sisteme bağlanarak bir Müzayede tanımlamaları ve bir seans açmalarıyla başlar. Daha sonra Alıcılar katalokta bu ürünü gördüklerinde ona yönelik tekliflerde bulunurlar. Belli zaman sonra müzayede otomatik olarak (daha önce Satıcı bitirmemişse) bitirilir. Bunun sonucunda hem Alıcı hem de Satıcı birer ikaz mesajı alırlar. Ödemeler dış bir sistem tarafından tahsil edilir.

2. İterasyonların Belirlenmesi Tüm sistem kapsamında (bütün use case’ler için) birer kaba doküman (outline) hazırlanır. Bu dokümanlarda sadece use case tanımı, temel ve alternatif akışların isimleri ile ilgili oldukları diğer use case’lerin isimleri yer almalıdır. Bu bilgiler ışında ve use case değişkenlerinin değerlerine bakılarak, bir önceliklendirme yapılmaya başlanır.

3. İterasyonların Belirlenmesi Sistem Mimarisini Etkileyen UC’ler İterasyon 2 [3] İterasyonların Belirlenmesi Önceliklendirme sonucunda iterasyon kapsamında use case’ler gruplara bölünür. İlk iterasyon kapsamları daha riskli, daha zor ve altyapıyla daha ilgi olmak üzere, her eklenen iterasyonda bu kapsam kolaylaştırılır. Elde edilen kilometre taşlarına göre iterasyonlar UP Fazları (Inception, Eleboration, Construction, Transition) altına yerleştirilir. İterasyon kapsamındaki her use case’in aynı zorlukta olması gerekmez. Her iterasyon kapsamında bir ‘hikaye bütünlüğü’ sağlayabilmek için eşdeğer zorluktaki ‘esas’ iterasyon kapsamına daha az zorlukta olan diğer use case’ler eklenebilir.

İçerik Karanlıkta ... Tabandan Gelen bir Çözüm Projeyle Birlikte ‘Büyümek’ Sözün Özü

MPP Made in Turkey Method Over Tool Project Over Method People Over Project Made in Turkey

Marangozun Kutusu Varsayım: Ürün < Süreç < Proje < İnsan Dil : UML Süreç: UP, CMMI, XP, Scrum ... Marangoz kutusunun en vazgeçilmez öğesi Marangozun kendisidir!

Teşekkürler!