Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

Erol Bozkurt UML ve İş Analizi.

Benzer bir sunumlar


... konulu sunumlar: "Erol Bozkurt UML ve İş Analizi."— Sunum transkripti:

1 Erol Bozkurt UML ve İş Analizi

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

3 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.

4 Çözümlerin Sınırları “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.” “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

5 Aynı / Ayrı Dünyalar Biz Ayrı Dünyaların İnsanlarıyız ;o) Biz Ayrılamayız ;o)

6 Takım: Aynı Dünya "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." "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."

7 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)

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

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

10 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ı

11 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!

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

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

14 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. 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.

15 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

16 İş Ürünleri

17 Süreç Yapısı

18 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

19 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.

20 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

21 Gereksinim Ürünleri (Artifact)

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

23 Activity Şeması

24 State Machine Şeması

25 Class Şeması

26 Use Case Şeması

27 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

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

29 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. Kara Delik Risk = Tehdit = Tuhaflık = Gerçekdışılık

30 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ı !

31 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...

32 ‘Waterfall’ Yaklaşımının 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. Sözde SonuçlarGerçek Sonuçlar

33 Pareto Kanunu Fayda Emek 20% 80% %20’lik emek faydanın %80’ini sağlar.

34 Yazılım Problemi: İki nokta arasındaki en kısa yol Buradan Buraya Nasıl gideceğiz? Buradan Buraya Nasıl gideceğiz? Düşündüğümüz Güzergah Projenin ilk Durumu  Mevcut ‘malzemeler’, teknolojiler  Elemanlar, kabiliyetleri, bilgileri  Kaynak eksiklikleri  Belirsizlikler 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.) 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.)

35 Gerçek Güzergah İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi Müşteriyi Tatmin Edebilecek Alandaki Belirsizlik Planlanan İçerik Planlanan Güzergah Projenin ilk Durumu

36 Planlanan Güzergah Gerçek Güzergah ‘Waterfall’ Yönetimi: “Planla ve Takip Et” Planlanan Proje Bitişi Gerçek Proje Bitişi Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu 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. 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.

37 Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu Planlanan Güzergah İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol” Planlanan Proje Bitişi Gerçek Güzergah Gerçek Proje Bitişi 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? 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?

38 1. İterasyonların Belirlenmesi İnternet’te Açık Artırma Sistemi

39 2. İterasyonların Belirlenmesi

40 3. İterasyonların Belirlenmesi Sistem Mimarisini Etkileyen UC’ler İterasyon 1 İterasyon 2

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

42 MPP Method Over Tool Project Over Method People Over Project

43 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! Marangoz kutusunun en vazgeçilmez öğesi Marangozun kendisidir!

44 Teşekkürler!

45


"Erol Bozkurt UML ve İş Analizi." indir ppt

Benzer bir sunumlar


Google Reklamları