Analist Eğitimi - Tüm Bölümler - [535 Slides]

10,335 views

Published on

Published in: Business
4 Comments
20 Likes
Statistics
Notes
  • Mükemmel bir kaynak.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • - URUS SRP, NIK BEACUKIA PENERBITAN BARU
    - URUS SRP, NIK BEACUKAI DITOLAK.
    - URUS SRP, NIK BEACUKAI DIBLOKIR
    - URUS SRP, NIK BEACUKAI PINDAH ALAMAT,

    URUS IZIN USAHA:
    - URUS PENDIRIAN PT – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN PMA – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN CV – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIU – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIP – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS NPIK – Seluruh Indonesia
    - URUS NIK BEACUKAI – Seluruh Indonesia
    - Urus IT Plastik
    - Urus IT CAKRAM OPTIK
    - Urus IT KOSMETIK
    - Urus IT ALAS KAKI
    - Urus IT MAKANAN DAN MINUMAN
    - Urus IT MAINAN ANAK-ANAK
    - Urus IT ELEKTRONIKA
    - Urus IT OBAT TRADISIONAL DAN HERBAL
    - Urus IT PRODUK MAKANAN DAN MINUMAN
    - Urus Izin Prinsip
    -Urus SIUP.
    -Urus TDP
    -Dll

    PT. LEGALITAS SARANAIZIN INDONESIA.
    Gedung Maya Indah Lt 2 Jakarta Pusat 10450
    Telp. 021-3142566
    Fax. 021-3928113
    HP. 081385042000
    Flexi. 021-70940216
    Website: http://www.saranaijin.com
    Email legal@saranaizin.com
    Pin BB 2262D175
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • URUS NIK BEACUKAI / REGISTRASI PABEAN / SRP BEACUKAI
    Peraturan Menteri Keuangan No. 63/PMK.04/2011

    - URUS SRP, NIK BEACUKIA PENERBITAN BARU
    - URUS SRP, NIK BEACUKAI DITOLAK.
    - URUS SRP, NIK BEACUKAI DIBLOKIR
    - URUS SRP, NIK BEACUKAI PINDAH ALAMAT,

    URUS IZIN USAHA:
    - URUS PENDIRIAN PT – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN PMA – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN CV – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIU – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIP – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS NPIK – Seluruh Indonesia
    - URUS NIK BEACUKAI – Seluruh Indonesia
    - Urus IT Plastik
    - Urus IT CAKRAM OPTIK
    - Urus IT KOSMETIK
    - Urus IT ALAS KAKI
    - Urus IT MAKANAN DAN MINUMAN
    - Urus IT MAINAN ANAK-ANAK
    - Urus IT ELEKTRONIKA
    - Urus IT OBAT TRADISIONAL DAN HERBAL
    - Urus IT PRODUK MAKANAN DAN MINUMAN
    - Urus Izin Prinsip
    -Urus SIUP.
    -Urus TDP
    -Dll

    PT. LEGALITAS SARANAIZIN INDONESIA.
    Gedung Maya Indah Lt 2 Jakarta Pusat 10450
    Telp. 021-3142566
    Fax. 021-3928113
    HP. 081385042000
    Flexi. 021-70940216
    Website: http://www.saranaijin.com
    Email legal@saranaizin.com
    Pin BB 2262D175
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • analistliğe genl bir bakış sunmaktadır
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
10,335
On SlideShare
0
From Embeds
0
Number of Embeds
132
Actions
Shares
0
Downloads
713
Comments
4
Likes
20
Embeds 0
No embeds

No notes for slide

Analist Eğitimi - Tüm Bölümler - [535 Slides]

  1. 1. Analize Giriş<br />Bölüm 1/4<br />
  2. 2. İçerik<br />
  3. 3. Eğitmen Hakkında<br />Erol Bozkurt – erol.bozkurt@xupit.com<br />Bilişim Teknolojileri Danışmanı<br />University of Houston, Computer Science.<br />Uzmanlıklar:<br />Real Time Simülasyon Sistemleri Tasarımı ve Programcılığı,<br />Sistem Analizi, UML ve Yazılım Süreçleri Danışmanlığı.<br />
  4. 4. Eğitim Planı<br />9:30 – 12:30 (3 Ders)<br />Öğle arası (12:30 – 13:30)<br />13:30-16:30 (3 Ders)<br />İhtiyacınıza göre düzenlemeler yapılabilir.<br />
  5. 5. Tipik Katılımcı Profili<br />Nesne Tabanlı Yazılım Deneyimi Olanlar<br />Nesne Tabanlı Yaklaşımı Öğrenmek İsteyenler<br />Analistler, Tasarımcılar, Programcılar, …<br />Süreç Mühendisleri<br />Kalite Sorumluları<br />Proje Yöneticileri<br />Konu Uzmanları (Domain Expert)<br />Müşteriler <br />
  6. 6. Katılımcılar Hakkında<br />Şirketiniz ve faaliyet alanı<br />Sizin rolünüz<br />Eğitim almanızdaki nedenler<br />Eğitime yönelik beklentileriniz<br />
  7. 7. Eğitim Materyalleri<br />Eğitim Kitabı.<br />Çalışmalarımızda kullanacağımız ürünlerin demolarını ve egzersiz dokümanları içeren CD-ROM.<br />
  8. 8. Bizi Seçtiğiniz İçin Teşekkür Ederiz!<br />
  9. 9. Analize Giriş<br />Bölüm 2 / 4<br />
  10. 10. İçerik<br />
  11. 11. Analizden Ne Anlıyoruz?<br />Bir konuyu derinlemesine inceleyerek <br /><ul><li>onun iç mekanizmasını,
  12. 12. temel parçaları ve ilişkilerini,
  13. 13. işleyiş mantığını ve
  14. 14. baz aldığı varsayımları</li></ul>saptama faaliyetlerinin tümüdür.<br />Sherlock Holmes<br />
  15. 15. Analizden Ne Anlıyoruz?<br />Analiz esnasında dikkat edilebilecek öğeler<br /><ul><li>Çözümü kullanacak kişilerin özellikleri
  16. 16. Çözümü geliştiren kişilerin özellikleri
  17. 17. Çözümü kullanacak kişilerin iş süreçleri
  18. 18. Çözümü geliştirecek kişilerin yazılım geliştirme süreçleri</li></ul>Formül: Roller – İş Ürünleri – İş Adımları<br />
  19. 19. Analizden Ne Anlıyoruz<br />Farklı bir şekilde söylersek analiz çalışması insan ilişkilerinin yeniden tanımlanması ve düzenlenmesi işidir.<br />Dolayısıyla müşteriler ve tasarımcılar / programcılar arasında yer alarak tartışmaların tam merkezine düşer!<br />
  20. 20. Analist Kimdir?<br />Duyduğunu gerçek ve eksiksiz bilgi olarak algılayan,<br />Algıladıklarını onaylattığında onlara bir kesinlik kazandırdığını zanneden birisi değildir.<br />Aksine, duyduklarını sorgulayan ve söylenmeyenleri su yüzüne çıkaran,<br />Kronik sorunları dokümante etmenin ötesinde problemin çözülmesine yardımcı olan birisidir.<br />
  21. 21. Analist Kimdir?<br />Terapisttir<br />Toplantı yöneticisidir<br />Değişiklik mühendisidir<br />
  22. 22. Analist Kimdir?<br />Dokümanla ifade edilen bilgileri kolay ayrıştıran ve alakalandıran<br />Pek çok konuya yönelik yazılım geliştirmiş<br />Hataları ve nedenlerini tanımlayan<br />Gereksinimleri derleyerek geliştirilecek ürünleri tanımlayan<br />Derlediği bilgileri etkili bir kullanımı sağlayacak şekilde dokümante eden<br />Kalite ve performansa yönelik olarak ürünleri, hizmetleri ve süreçleri değerlendiren ...<br />
  23. 23. Analist Kimdir?<br />İnsanların gerçek ihtiyaçlarını saptamak için gerekli sabra ve yeteneğe sahip<br />Alternatif yaklaşımları güçlü ve zayıf yanlarına göre karşılaştırabilen<br />Yüz yüze iletişim tekniklerinde bilgili ve becerili<br />Karmaşık sorunları kavramsal olarak inceleyebilen ve seçenekleri belirleyerek, çözümler üretebilen birisidir.<br />
  24. 24. Analist Kimdir?<br />Bilgisayar donanımı, elektronik cihazlar ve yazılımlar <br />Türkçe ve kullanılan diğer dillerde dilbilgisi, imla ve kompozisyon yazma <br />Müfredat belirleme, eğitim içerik geliştirme, eğitmenlik ve eğitim değerlendirmeleri hakkında deneyim sahibi birisidir. <br />
  25. 25. Analist Kimdir?<br />Temel matematik, cebir, geometri, calculus,istatistik ve uygulanma şekilleri<br />Hizmet sağlama ilkeleri ve süreçleri (İhtiyaç belirleme, hizmet kalite standartları, müşteri memnuniyeti ölçmeyi de içerir) hakkında deneyim sahibi birisidir.<br />
  26. 26. Analist Türleri<br />
  27. 27. Analist Türleri / Farklı Tanımlar<br />İş Analisti<br />Sistem Analisti<br />Analist / Programcı<br />Veri / Veritabanı ‘Analisti’<br />
  28. 28. Alakalı Meslekler<br />Değişiklik Mühendisi<br />Süreç Mühendisi<br />İş Geliştirme Yöneticisi<br />Proje Yöneticisi<br />
  29. 29. İlgili Standartlar<br />RUP, XP, MIL-STD, IEEE vs.<br />CMMI<br />CobiT, ITIL<br />
  30. 30. Olası Bir Kariyer Planı<br />
  31. 31. İş Analisti<br />
  32. 32. İş Analisti<br />
  33. 33. Sistem Analisti<br />
  34. 34. Sistem Analisti<br />
  35. 35. Analize Giriş<br />Bölüm 3 / 4<br />
  36. 36. İçerik<br />
  37. 37. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  38. 38. KiminNeyiNe ZamanNasıl yapacağını tanımlamaktır.<br />Yeni <br />sistem<br />Değişen<br />gereksinimler<br />Süreç<br />Süreç Nedir?<br />
  39. 39. 1. Gereksinim Yönetimi(Ne?) <br />Ürünün yerine getirmesi gerekenler<br />2. Analiz(Nasıl?)<br />Sistemin parçalarının ve birbirleriyle alakalarının kavramsal seviyede belirlenmesi<br />3. Tasarım(Nasıl?)<br />Sistemin parçalarının ve birbirleriyle alakalarının bir teknolojiye has olarak (J2EE, C++) belirlenmesi<br />4. İmplementasyon(Kodlamak)<br />Sistemin kaynak kodunun geliştirilmesi<br />5. Test (Verifikasyon: Fonksiyonel Test)<br />Test verileriyle uygulamayı çalıştırmak<br />6. Bakım(Hata Düzeltme ve Geliştirme)<br />Ürünün hatalarını giderme ve yeni özellikler ekleme<br />Yazılım Süreci Aşamaları<br />
  40. 40. 1. Gereksinim Yönetimi:<br />Uygulama kullanıcının bakiyesini göstermelidir. <br />2. Analiz ve Tasarım:<br />Tasarım VadesizHesap ve VadeliHesap class’larına sahip olmalıdır.<br />3. İmplementasyon:<br />class VadesizHesap{ <br />double bakiye; <br />getBakiye{}; setBakiye{}} …<br />4. Test:<br />yatırılan $44.92 / yatırılan $32.00 / <br />çekilen $101.45 / … <br />bakiye $2938.22, testi geçti.<br />5. Bakım:<br />Hata düzeltme: Bakiye sıfır olunca ve para çekme işlemi yapılmak istenince sistem göçüyor.<br />Ek Özellik Geliştirme: Euro para birimini destekleme.<br />Süreç Örneği: Bireysel Finans<br />
  41. 41. Milestone(s)<br />Ürünün sürümleri<br />Bu fazlar kısa bir süre için örtüşebilir<br />Fazlar<br />Waterfall Yazılım Süreci<br />Gereksinim<br />Analizi<br />Tasarım<br />İmplementasyon<br />Test<br />Bakım<br />zaman<br />
  42. 42. Waterfall Neden Pratik Değildir?<br />1. Sahip olunması istenen bilgilerin hepsi hazır değildir<br />Bütün detayları işin başında görmek zordur <br />2. Gereksinimlerin implementasyon maliyetlerini sadece tahmin edebiliriz<br />Tahminin isabetliliğini anlamak için en riskli olanlarının tasarlanıp, implemente edilmeleri gerekir<br />Buradan alınan sonuçlara göre gereksinimler değişebilir <br />3. Sık sık ara sürümler çıkarmak zorunda kalırız<br />Paydaşların (müşteriler, yöneticiler) projeye güvenlerini tazelemek gerekir<br />Tasarımcılar ve programcılar geliştirdikleri sistemin istenen sistem olduğunun konfirmasyonunu beklerler (Bunun yegane yolu: kademe kademe parçaları birleştirerek (iterative ve incremental) yazılım geliştirme ve testtir)<br />4. Tipik olarak yazılım ekibinin elemanları farklı fazlarda da görev alırlar<br />
  43. 43. Spiral Süreç<br />
  44. 44. M I L E S T O N E S<br />α(prototype) X<br />β<br />X sürüm 1.0<br />1<br />2<br />3<br />1 <br />2<br />3 <br />1<br />2<br />3<br />1 <br />2<br />3 <br />2 <br />3<br />1<br />Spiral Süreç<br />zaman<br />İterasyon #<br />Gereksinim<br />Tasarım<br />Kodlama<br />Test<br />
  45. 45. Örtüşen Süreç Aşamaları: UP<br />
  46. 46. RUP’un Gelişimi<br />Rational Unified Process 5.0<br />İşlevsellik Testi<br />Performans Testi<br />Gereksinim Denet.<br />Değişiklik Denet.<br />İş Akışı<br />Veri Tabanı<br />UI<br />1998<br />Rational <br />Objectory Process 4.1<br />1996-1997<br />UML<br />Rational Yaklaşımı<br />Objectory Process 1.0-3.8<br />1987-1995<br />Ericsson Yaklaşımı<br />
  47. 47. Süreç Seçim Yaklaşımı Olarak MPP<br />Method over Tool:<br />“Herhangi bir yazılım mühendisliği ürününden ziyade yönteme odaklanmak”<br />Project over Method:<br />“Herhangi bir yazılım sürecinden ziyade projeye/ürüne odaklanmak”<br />People over All:<br />“Herşeyden çok ürünün kullanıcıları ve onu geliştirenler dahil olmak üzere paydaşlara odaklanmak”<br />
  48. 48. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  49. 49. zaman<br />Gereksinim<br />Kontrolü<br />Sistem<br />Mimarisi <br />Kullanılabilirlik <br />Resmi<br />Sürüm<br />Proje Gelişim Süreci<br />Inception<br />Elaboration<br />Construction<br />Transition<br />saptama<br />tasarlama<br />oluşturma<br />sunma<br /><ul><li>Inception: Projenin sınırlarının belirlenmesi, Verilecek hizmetin</li></ul> berraklaştırılması<br /><ul><li>Elaboration: Proje planının oluşturulması, ürün özelliklerinin</li></ul> saptanması, Baseline <br /><ul><li>Construction: Ürünün oluşturulması
  50. 50. Transition: Kullanıma sunulma</li></li></ul><li>Release<br />Release<br />Release<br />Release<br />Release<br />Release<br />Release<br />Release<br />Aşamalar ve İterasyonlar<br />Inception<br />Elaboration<br />Construction<br />Transition<br />...<br />Arch<br />Iteration<br />...<br />Dev <br />Iteration<br />Dev <br />Iteration<br />...<br />Trans<br />Iteration<br />Prelim<br />Iteration<br />...<br />Bir iterasyon planlı olarak gerçekleştirilmiş faaliyetler bütünüdür. Sonucunda başarısı ölçülebilen çalıştırılabilir bir bilgisayar programı oluşur.<br />
  51. 51. I<br />n<br />c<br />e<br />p<br />t<br />i<br />o<br />n<br />E<br />l<br />a<br />b<br />o<br />r<br />a<br />t<br />i<br />o<br />n<br />C<br />o<br />n<br />s<br />t<br />r<br />u<br />c<br />t<br />i<br />o<br />n<br />T<br />r<br />a<br />n<br />s<br />i<br />t<br />i<br />o<br />n<br />P<br />r<br />e<br />l<br />i<br />m<br />i<br />n<br />a<br />r<br />y<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />i<br />t<br />e<br />r<br />.<br />I<br />t<br />e<br />r<br />a<br />t<br />i<br />o<br />n<br />(<br />s<br />)<br />#<br />1<br />#<br />2<br />#<br />n<br />#<br />n<br />+<br />1<br />#<br />n<br />+<br />2<br />#<br />m<br />#<br />m<br />+<br />1<br />İterasyonlar ve İşler<br />Aşamalar<br />İşler<br />Gereksinim<br />Analiz<br />Tasarım<br />Uygulanma<br />Test<br />İterasyon<br />
  52. 52. İterasyonlar ve Risk<br />Proje risklerinin ortaya konması<br /><ul><li>Mimarinin revizyonu
  53. 53. Risk-bazlı iterasyonlar
  54. 54. Entegrasyon</li></ul>Inception<br />Waterfall<br />Elaboration<br /><ul><li>Kullanıma sunma
  55. 55. Müşteri memnuniyetini ölçme</li></ul>Risk<br />Construction<br /><ul><li>Senaryolarla sistemin yapısının ve davranışının oluşturulması
  56. 56. Sistem Mimarisinin oluşması
  57. 57. Temel mekanizmaların tasarlanması</li></ul>Transition<br />Preliminary<br />Iteration<br />Architect.<br />Iteration<br />Architect.<br />Iteration<br />Devel. <br />Iteration<br />Devel. <br />Iteration<br />Devel. <br />Iteration<br />Transition<br />Iteration<br />Transition<br />Iteration<br />Post-<br />deployment<br />Zaman<br />
  58. 58. Risk Azaltma Odaklı İterasyonlar<br />İterasyon N’in Planı<br /><ul><li> Maliyet
  59. 59. Zamanlama</li></ul>En önemli risklere yönelik senaryoların oluşturulması<br />İlk Proje Riskleri<br />İlk Proje Odağı<br />Iteration N’in oluşması<br /><ul><li> Maliyet ve Kalite ölçümleri</li></ul>Iterasyon N<br />Iteration N’in değerlendirilmesi<br />Yenilenen Proje Planı<br /><ul><li> Maliyet
  60. 60. Zamanlama
  61. 61. Odak/İçerik</li></ul>Giderilen Riskler<br />Diğer Riskler<br /><ul><li> Yeni öncelikler</li></li></ul><li>Use Case Odaklı İterasyonlar<br />Inception<br />Elaboration<br />Construction<br />Transition<br />İterasyon1<br />İterasyon2<br />İterasyon3<br />“Mini-Waterfall” Süreci<br />İterasyon Planı<br />Gereksinimler <br />Analiz + Tasarım<br />Uygulama<br />Test <br />Release<br />
  62. 62. İterasyon Süreci<br /><ul><li> Önceki iterasyonların sonuçları
  63. 63. Güncel Risk Raporu
  64. 64. Model, kod ve test kayıtları </li></ul>İterasyon Planı<br />Gereksinimlerin Sapt.<br />Analiz + Tasarım<br />Uygulama<br />Test<br />Release<br />Release raporu<br />Yeni Risk Raporu<br />Konfigürasyon Denet.<br />
  65. 65. Adapte Olabilen bir Süreç: UP<br />Rational Stratejik Hizmetler Biriminde baş danışman. <br />Uzmanlık alanları:<br /><ul><li> Yazılım Mühendisliği Süreçleri
  66. 66. Sistem Mühendisliği Süreçleri
  67. 67. Yazılım Proje Yönetimi
  68. 68. Liderlik</li></ul>Software Leadership: A Guide to Successful Software Development<br />Murray Cantor<br />Slaytlar 20 - 28<br />
  69. 69. Eski Müşteri/Yazılım Ekibi İlişkisi<br />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)<br />Varsayımlar<br />Gereksinimlerin, proje içeriğinin, kullanılacak teknolojinin eksiksiz ve gereken detay seviyesinde anlaşıldığını ... <br />Çok isabetli tahminlerde bulunmanın mümkün olduğunu ...<br />Detaylı bir planın yapılabileceği ve uygulanabileceği ... <br />
  70. 70. ‘Waterfall’ Yaklaşımının Sonuçları<br />Sözde Sonuçlar<br />Gerçek Sonuçlar<br /><ul><li>Detaylı toplantılar yapılıyor /Toplantı notları yazılıyor
  71. 71. Tasarım uygun gözüküyor.
  72. 72. Detaylı bir spesifikasyon hazırlanıyor.
  73. 73. Gereksinim kapsama yüzdesi(% 100) yüksek.
  74. 74. Tasarım “suçu ispatlanana kadar masum.”
  75. 75. Toplantılar ve dokümanlar karmaşık bir yazılım sisteminin gerçek risklerinin çok azına değiniyor.
  76. 76. Elle tutulur bir delil yok.
  77. 77. Yanıltıcı bir güvenlik hissi var.
  78. 78. Pek azın*(% 10) tasarımı yönlendiriyor.
  79. 79. Gereksinimlerin hepsine nüfuz etme çabası kritik noktaları gözden kaçırıyor.
  80. 80. Her zaman suçlu. Tasarım hatası ileride istemediğimiz bir zamanda ortaya çıkacak. </li></li></ul><li>Pareto Kanunu<br />80%<br />Fayda<br />20%<br />Emek<br />%20’lik emekfaydanın%80’ini sağlar.<br />
  81. 81. Hata Payını En Aza İndirmek Çok Emek İster<br />Gereksinimler karmaşıktır<br />Fonksiyon/Davranış<br />Sistem tarafı ayrıca karmaşıktır. <br />Tam anlamıyla anlamak analiz, deneyler ve neticelerin değerlendirilmesiyle mümkündür. <br />Gereksinimlerle Sistem Mimarisinin ilişkilerinin belirlenmesi gerekir.<br />Tüm bu emek bahsettiğimiz 80/20 kuralına tabiidir. <br />Eksiksiz bir bilgiye erişim en iyimser yaklaşımla ekonomik değildir. Gerçekçi olursak mümkün değildir. <br />Bilgi proje süresince eksiksizleşir.<br />
  82. 82. Paradoks<br />Yapılacak işi yönetebilmek içim yazılım taahhütlerinin olması gerekli<br />Taahhütlerin çok detaylı bir şekilde tarif edilmeleri mümkün değil<br />Çözüm:<br />Açık bir şekilde ortaklaşa çalışma, müşteriye sonuç göstererek yönetim ve programcı arasında ahenk oluşturarak çalışmak<br />İteratif yazılım geliştirme<br />Elde edilen bilgilerin kademeli olarak zaman içerisindeeksiksizleşmesi ve detay seviyelerinin artması. <br />
  83. 83. Yazılım Problemi: İki nokta arasındaki en kısa yol<br />Buradan Buraya<br />Nasıl gideceğiz?<br />Düşündüğümüz Güzergah<br />Müşteriyi Tatmin Edebilecek Alan<br /><ul><li>Katmadeğer: Kullanıcıya (kullanılabilirlik, performans, kalite)
  84. 84. Maliyet (zaman ve para)
  85. 85. Katmadeğer: Yazılım Geliştirici (kar, deneyim, satış, Pazar payı vs.)</li></ul>Projenin ilk Durumu<br /><ul><li>Mevcut ‘malzemeler’, teknolojiler
  86. 86. Elemanlar, kabiliyetleri, bilgileri
  87. 87. Kaynak eksiklikleri
  88. 88. Belirsizlikler</li></li></ul><li>İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi<br />Müşteriyi Tatmin Edebilecek Alandaki Belirsizlik<br />Planlanan Güzergah<br />Gerçek Güzergah<br />Projenin ilk Durumu<br />Planlanan İçerik<br />
  89. 89. Planla ve Takip Et: <br />Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. <br />Gerçek ve Hayal: <br />Bu durum iki farklı planın takip edilmesini gerektiriyor.<br />Planlanan Proje Bitişi<br />Planlanan Güzergah<br />Gerçek Güzergah<br />‘Waterfall’Yönetimi: “Planla ve Takip Et” <br />Müşteriyi Tatmin Edebilecek Alan<br />Projenin ilk Durumu<br />Gerçek Proje Bitişi<br />
  90. 90. İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol”<br />Gerçek Güzergah<br />Devamlı olarak :<br />Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendir<br />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? <br />Gerçek Proje Bitişi<br />Planlanan Proje Bitişi<br />Planlanan Güzergah<br />Müşteriyi Tatmin Edebilecek Alan<br />Projenin ilk Durumu<br />
  91. 91. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  92. 92. Bir iş<br />Bir rol<br />Activity <br />(Faaliyet)<br />Role (Çalışan)<br />Artifact<br />(Oluşanlar)<br />Sürecin oluşturduğu, kullandığı veya değiştirdiği bir ürün<br />Use case<br />UP’in 3 Temel Parçası <br />Use Case’leri tanımla<br />Analist<br />sorumluluğu<br />Use case paketi<br />
  93. 93. Role<br />Analistler: İş Analisti, Sistem Analisti, vs.<br />Yazılım Geliştirenler: Tasarımcı, Programcı, Kullanıcı Arayüzü Tasarımcısı, vs.<br />Yöneticiler: Proje Yöneticisi, Süreç Uzmanı, vs.<br />Diğer: Konu Uzmanları, Denetçiler (Reviewer), vs.<br />
  94. 94. Activity<br />
  95. 95. Artifact<br />
  96. 96. Unified Process Yapısı<br />
  97. 97. Discipline ve Workflow<br />Disiplin: Gereksinim Yönetimi<br />Workflow: Gereksinim Yönetimine <br />ait çalışma şekli detayları <br />
  98. 98. Workflow Details<br />
  99. 99. Daha Fazla Detay “Rol Üzerinden”<br />
  100. 100. Daha Fazla Detay“Yapılacak İş Üzerinden”<br />
  101. 101. Daha Fazla Detay“Üretilenler Üzerinden”<br />
  102. 102. Daha Fazla Detay“Bir Adım Daha İleriye: Şablonlar”<br />
  103. 103. İş Akışları Modelleri Oluşturur<br />
  104. 104. “Ürünler ve Kullanım Teknikleri”<br />
  105. 105. Özetlersek<br />
  106. 106. Sorulamayan Soruyu Bulmak<br />“Sorulamayan soruyu bulmak gerçekle hayali birbirinden ayırmamızı sağlar.”<br /> John M. Berry (A.B.D.’li Filozof)<br />UP diğer süreç tanımları gibi ‘geleneksel bir model’ değildir.<br />Varsayımları (Neden’i) açık ve belli.<br />Çalışma şekillerinin girdisi, çıktısı, kimlerin ne işine yaradığı ve kimler tarafından oluşturuldukları belli.<br />Yapılacakları dikte etmez: Ne’nin yanında Nasıl’da vardır.<br />Ne’lerin neler olacağına UP’un kullanıcısı karar verebilir.<br />Ne mevcut değilse onu ekleyebilir: UP plug-in’leri.<br />Ne’sini,Nasıl’ını ve Neden’ini (en küçük yapı taşına kadar) açıkça ortaya koyan bir sistem soyut ve anlamsız (süreç için süreç) bir kavrama dönüşmez.<br />UP’u çok ciddi bir hedef olan CMM-I için de daha çok programcı odaklıExtreme Programming için de kullanabiliriz.<br />
  107. 107. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  108. 108. SPEM“Software Process Engineering Metamodel”<br />UML gibi OMG tarafından onaylanmaktadır. Açık bir standarttır.<br />Bitmiş bir standart değildir. Ufak değişmeler (gelişmeler) söz konusu olacaktır.<br />Tamamıyla Unified Process üzerine oturur.<br />Biz, örneklerimizde, kabaca kullanacağız.<br />
  109. 109. SPEM Gösterimi“Disiplinler”<br />X<br />X<br />X<br />
  110. 110. SPEM Gösterimi“Roller”<br />
  111. 111. SPEM Gösterimi“Yapılanlar”<br />
  112. 112. SPEM Gösterimi“Üretilenler”<br />
  113. 113. SPEM Gösterimi“Roller, Yapılanlar ve Üretilenler”<br />
  114. 114. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  115. 115. Süreç Haritası<br />
  116. 116. Süreç Haritası“Çevik Süreç Tanımları”<br />
  117. 117. Süreç Haritası“CMMI”<br />
  118. 118. Süreç Haritası“Unified Process”<br />
  119. 119. UP Uyarlamaları<br />
  120. 120. Gereksinim Yönetimi“Standart UP”<br />
  121. 121. Analiz ve Tasarım “Standart UP”<br />
  122. 122. İmplementasyon “Standart UP”<br />
  123. 123. Bizim UP Sürecine Yaklaşımız<br />
  124. 124. Proje Süresince Roller<br />Bir kişi birden fazla rolü canlandırabilir.<br />Aynı kişinin canlandırdığı rollerin çıkarları bir çelişki oluşturmamalıdır.<br />Bütçe ve Eleman sayımızı gözeterek ve en verimli süreç tanımını hedefleyerek,<br />Aşağıdaki gibi bir kadroyla yola çıkarsak,<br />Ahmet Bey: Birincil görevi Sistem Analizi<br />Leyla Hanım: Birincil görevi Tasarım<br />Mehmet Bey: Birincil görevi Veritabanı Tasarımı <br />Hülya Hanım: Birincil görevi Proje Yönetimi<br />
  125. 125. Gereksinimler<br />
  126. 126. 2. Analiz ve Tasarım<br />
  127. 127. 3. İmplementasyon<br />
  128. 128. 4. Test<br />
  129. 129. Proje Yönetimi<br />
  130. 130. Süreç Mühendisliği<br />
  131. 131. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  132. 132. İdeal Proje Ekibi<br />
  133. 133. BizimProje Ekibimiz<br />
  134. 134. Ahmet = Sistem Analisti<br />
  135. 135. Ahmet = UI Tasarımcısı<br />
  136. 136. Ahmet = Testçi<br />
  137. 137. Leyla = Sistem Mimarı<br />
  138. 138. Leyla = Tasarımcı<br />
  139. 139. Leyla = Programcı<br />
  140. 140. Mehmet = Veritabanı Tasarımcısı<br />
  141. 141. Hülya = Proje Yöneticisi<br />
  142. 142. Hülya = Süreç Uzmanı<br />
  143. 143. İçerik<br />Yaygın Yazılım Süreçleri<br />İteratif Yazılım Geliştirme<br />Unified Process (UP) Yapısı<br />SPEM Gösterimi ile Yazılım Süreci Tanımlama<br />Pratik bir UP Yaklaşımı<br />Yazılım Rolleri ve Kaynak Yönetimi<br />Proje Hazırlık Çalışmaları<br />
  144. 144. Proje Hazırlık Çalışmaları“Tanımlamalar”<br />Paydaş Türleri<br />Gereksinim Türleri<br />Gereksinim Değişkenleri<br />Kısıtlama Türleri<br />Risk Türleri<br />Metrik Türleri<br />Emek Türleri<br />Bakım Türleri<br />Test Türleri<br />UML Standardına Ekleriniz, vs. vs.<br />
  145. 145. 1a. Paydaşlar“Kullanıcılar”<br />
  146. 146. 1b. Paydaşlar“Proje Ekibi Adayları”<br />
  147. 147. 1c. Paydaşlar“Proje Ekibi”<br />
  148. 148. 2a. Gereksinim Türleri<br />
  149. 149. 2b. Gereksinim Türleri<br />
  150. 150. 2c. Gereksinim DeğişkenleriÖrnek: “Statü”<br />
  151. 151. 3. Kısıtlama Türleri<br />
  152. 152. 4. Risk Türleri<br />
  153. 153. 5. Metrik Türleri<br />
  154. 154. 6. Emek Türleri<br />
  155. 155. 7. Bakım“Problem Türleri”<br />
  156. 156. 8. Test<br />
  157. 157. 9. UML Kapsamına Ekler“Size Özel Stereotype”<br />
  158. 158. İlham Kaynakları<br />Philippe Kruchten<br />Watts Humphrey<br />?<br />Murray Cantor<br />Sizin Adınız<br />Terry Quatrani<br />James Bach<br />James Rumbaugh<br />Grady Booch<br />Ivar Jacobson<br />
  159. 159. Analize Giriş<br />Bölüm 4 / 4<br />
  160. 160. Neredeyiz?<br />
  161. 161. İçerik<br />
  162. 162. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  163. 163. Proje Başarısızlığı Nedenleri<br />En yaygın nedenler:<br />Kullanıcı fikirlerinin alınmaması (% 13)<br />Eksik gereksinimler (% 12)<br />Değişen gereksinimler (% 12)<br />Dolayısıyla projelerin üçte biri gereksinimlerle ilgili nedenlerden başarısız oluyor<br />
  164. 164. Proje Başarısı Nedenleri<br />En yaygın nedenler :<br />Kullanıcı fikirlerinin alınması (% 16)<br />Üst yönetim desteği (% 14)<br />Gereksinimlerin açık olması (% 12)<br />
  165. 165. Gereksinim Hataları<br />Müşteriye taşınan hataların yaklaşık olarak üçte biri gereksinim hatalarıdır<br />Gereksinim hataları bulundukları anda giderilmezlerse ilerideki düzeltilme maliyetleri 10 ila 100 katına çıkabilir<br />İyi proje takımları hataları tespit edildikleri anda tahlil ederler<br />
  166. 166. Gereksinim Yönetimi<br />Öyleyse gereksinimleri denetlemeye ihtiyacımız var: <br />Gereksinimleri bulmak, organize etmek ve dokümante etmek için bir sistem gerekli <br />Gereksinim değişikliklerini yöneterek müşteri ve proje ekibinin anlaşmalarını sağlayabilmek için bir süreç gerekli<br />Bu kavramlara Gereksinim Yönetimi diyoruz<br />
  167. 167. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  168. 168. Gereksinim Nedir?<br />Gereksinimleri tanımlayabilmek için onları gereksinim gibi algılanabilecek diğer bilgi türlerin ayrıştırabilmemiz gerekir <br />Bir ihtiyaç (need) bir sistemi kullanan müşterinin işini yapabilmesi için gereken, sistemin sahip olmak zorunda olduğu bir özelliktir<br />
  169. 169. Gereksinim Nedir?<br />İşlev (feature) sistemin yerine getirmeyi taahhüt ettiği bir hizmettir<br />Gereksinim (requirement) sistemin karakteristik bir özelliğidir<br />Gerçekleştirme (realization) gereksinimlerin uygulanma şeklidir<br />Bir işlevden bir veya daha fazla gereksinim türetilebilir<br />
  170. 170. Detay Seviyeleri<br />Daha detaylı<br />Müşterinin probleminin tanımı<br />İhtiyaç<br />İşlev<br />Çözümün tanımı<br />Gereksinim<br />Çözümün gerçekleştirilmesi<br />Gerçekleştirme<br />
  171. 171. Gereksinim Nedir?<br />Fırsat (opportunity) yeni bir işlev, yeni bir müşteri tipi veya ürüne eklenen yeni bir özellik olabilir<br />Problem müşterinin işini yaparken karşılaştığı bir zorluktur<br />Kısıtlama (constraint) oluşturulacak sistemin uymak zorunda olduğu bazı sınırlardır<br />
  172. 172. Acaba Bu Bir Gereksinim Mi?<br />Yoksa eksik bilgiyle tasarımıma mı başladık?<br />Gerçekte ihtiyaç duyulmayan gereksinimlere ve aslında mevcut olmayan kısıtlara dikkat ediniz<br />Yoksa birisi problemden ziyade çözümü mü tanımlamaya başladı? <br />Bir gereksinim olmak için çok mu genel?<br />
  173. 173. Öncelik<br />Gereksinimin önceliği veya aciliyeti nedir? <br />Yüksek, Orta, Düşük<br />Zaruri, İstenen, Seçeneğe Tabii <br />Mutlaka olmalı, Olması arzulanan, Olsa iyi olacak olan<br />Gündelik terminolojide ‘olacak’, ‘olsa iyi olur’, ‘olmayabilir’<br />Gereksinimlerin önem nedenleri nedir?<br />Sistem Mimarisine etki,<br />Teknolojik yenilik nedeniyle bir risk,<br />Zorluk nedeniyle bir risk,<br />Vs. vs.<br />
  174. 174. Paydaş (Stakeholder)<br />Müşteriden fikri değerli yegane grupmuş gibi bahsedebiliyoruz ama projeye yönelik çelişen düşüncelere sahip pek çok grup insan olabilir (paydaş)<br />
  175. 175. Paydaş Türü Örnekleri<br />Sponsor<br />İş Analisti, Sistem analisti, Tasarımcı, Programcı, Veritabanı Analisti, vs.<br />Konu Uzmanları<br />Kullanıcı<br />Yöneticiler<br />Admin.’ler<br />Süreç Uzmanları, Kalite Sorumluları, vs.<br />3rd Party<br />
  176. 176. Paydaşların Çelişen İstekleri<br />Bu paydaşların hepsinin farklı ve birbirleriyle çelişen istekleri olabilir <br />Başarılı bir projenin sağlaması gereken en önemli şeylerden biri bu isteklerin sahipleri arasında bir mutabakat sağlamaktır <br />Mutabakat farklı çıkarlara sahip rollerin çıkarlarını olabildiğince korumalarıyla mümkündür<br />
  177. 177. Yazılım Ekibi<br />Yazılım geliştirme sürecine iştirak eden herkes gereksinim yönetimi çalışmalarından farklı şekillerde etkilenirler<br />Problem çoğu yazılımcının teknik odaklarından dolayı insan ilişkilerinde çok başarılı olmayışlarıdır <br />Öte yandan modern sistemlerin karmaşıklıkları insan ilişkisini zaruri kılmaktadır <br />
  178. 178. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  179. 179. Altı Ekip Yeteneği<br />Problem analizi<br />Müşteri ihtiyaçlarını anlama<br />Sistemi tanımlama<br />Sistem kapsamını yönetme<br />Sistem tanımının revize edilmesi<br />Doğru sistemin geliştirilmesi<br />
  180. 180. 1. Problemi analizi<br />Bu konuya ileride, daha sonra değineceğiz.<br />
  181. 181. 2. Müşteri ihtiyaçlarını anlama<br />En üst seviyedeki gereksinimler olası çözümün tanımlanmasından çıkar <br />Müşteriden bu gereksinimleri alabilmek için hangi teknikleri kullanacağımıza nasıl karar vereceğiz? <br />Tıpkı bir marangoz gibi iş için gereken alet edavatı kolayca tespit edebilmek <br />
  182. 182. 3. Sistemi tanımlama<br />Bir dizi gereksinimi nasıl organize edecek ve oluşturulacak sistemin açık bir resmini görebileceğiz? <br />Alakalı ürünler arasındaki ortak gereksinimler nasıl ilişkilendirilecekler? <br />Ürünün vizyonunun dejenere olmaması için onu detay gereksinimlerden nasıl ayrıştıracağız? <br />
  183. 183. 4. Sistem kapsamını yönetme<br />Gereksinimler nadiren statiktir. Üç yaşındaki çocukların ilgi alanı gibi her an değişirler<br />Ürünün kapsamının kontrolden çıkmasını nasıl sağlayacağız? <br />Yapılması gerekenleri geciktirirsek kapsamı nasıl kontrol edebiliriz? <br />
  184. 184. 5. Sistemin tanımının revizyonu<br />Yazılım ekibinin işini yapmaya kalkışmadan onlar için gerekli detay seviyesindeki gereksinimleri nasıl oluşturabiliriz? <br />Detaylı gereksinimler vizyondan kopmamalı ve sadece her küçük problem parçasının çözülebilir olmasını sağlamalı <br />
  185. 185. 6. Doğru sistemin geliştirilmesi<br />Tasarımın gereksinimleri yerine getirdiğini nasıl anlayacağız? <br />Tasarımın müşteri isteklerine uygunluğundan nasıl emin olacağız? <br />Gereksinim değişikliklerini nasıl kontrol altına alacağız? <br />
  186. 186. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  187. 187. Problemler ve Fırsatlar<br />Sistemlerin en önemli iki nedeni:<br />Problem çözmek; mevcut sistem müşteri ihtiyaçlarını karşılamıyor demek <br />Fırsatları değerlendirmek; yeni ürün düşünceleri, yeni işlevler, yeni pazarlar vs. <br />Biz problem çözmeye odaklanacağız <br />
  188. 188. Problem Analizi Aşamaları<br />Problem beş aşamada tahlil edilebilir:<br />Problem tanımı üzerinde anlaşmak<br />Problemin temel nedenlerini anlamak<br />Paydaş ve kullanıcıları tespit etmek <br />Sistemin sınırlarını tespit etmek<br />Çözümü sınırlandıracak olan kısıtları bulmak<br />
  189. 189. 1Problem tanımı üzerinde anlaşmak<br />Problem tanımı içeriği: <br />Problemi tarif ediniz <br />Etkilenen paydaşları belirtiniz <br />Problemin paydaşlar ve yaptıkları işler üzerindeki etkilerini belirtiniz <br />Önerilen çözümü ve sağlayacağı faydaları ifade ediniz <br />Kısaca, neden bu problemi çözmek için vaktimizi harcamalıyız? <br />
  190. 190. Problemin mevcudiyetinden emin olunca bir çözüm oluşturmamız gerekiyor: <br />Bir yol “temel neden” veya “nedensellik analizi”dir. Böylece problemin mevcudiyet nedenini anlayabiliriz <br />Bunun için ‘kılçık şeması’ (fishbone) çizebiliriz<br />Düz bir çizgi çekerek problemi yazınız<br />Sonra problem nedenlerini yazınız<br />Daha sonra problem nedenlerinin nedenlerini yazınız<br />Tekrar ediniz <br />2Probleminnedenlerinianlamak<br />
  191. 191. 2Probleminnedenlerinianlamak<br />‘Akıl haritası’ (mindmap) çizebiliriz<br />12 m. <br />Boeing Uçak A.H.<br />
  192. 192. 3Paydaşları ve kullanıcıları tespit<br />Sistemi kullanacak ve mevcudiyetinden etkilenecek kişileri tespit edin<br />Çoğu paydaş kullanıcıdır ama diğerleri değillerdir<br />
  193. 193. 4-5Sistemin sınırlarını tespit<br />En basit tanımıyla her sistem bazı girdiler alır ve bazı çıktılar üretir<br />Püf noktası bu girdi ve çıktıları kimin veya neyin üretip tükettiğidir<br />
  194. 194. 4-5Sistemin sınırlarını tespit<br />Neler sistemin kapsamındadır?<br />Paydaşların yerine kendimizi koyarsak,<br />Kullanıcıların yerine kendimizi koyarsak,<br />Yazılım ekibinin yerine kendimizi koyarsak,<br />Dış sistemler hangileridir?<br />Bağımlı olduklarımız,<br />Bizim sistemimize bağımlı olanlar<br />
  195. 195. 4-5Sistemin sınırlarını tespit<br />Sistem üzerine adı yazılı bir kutu ile gösterilir<br />Aktörler çöpten adamlardır<br />Dış sistemler ya adı üzerine yazılı bir kutu ya da daha yaygın olarak birer aktör olarak gösterilirler<br />İlişki çizgilerinin yönü veri akış yönünü gösterir<br />
  196. 196. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  197. 197. Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”<br />Gereksinimlerin bulunabilmeleri için yazılım ekibi dikkatli olmalıdır<br />Gereksinimleri açığa çıkarabilecek kavramları değerlendiriniz <br />“Bunu bir gereksinim olarak eklemek ister misiniz” diye sorunuz ve bahsedilen düşüncenin önemini saptayınız <br />Çalışmalarınıza müşteri ihtiyaçlarını tespit ederek başlayınız<br />
  198. 198. Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”<br />En üst seviyedeki bilgi türümüz olan ihtiyaçlarla problem tahliline başlayabiliriz<br />Genellikle ihtiyaçlar sistemin çözmesi beklenen temel bir problemle ifade edilirler (bu problemi nelerin ortadan kaldıracağıyla) <br />Bazı kullanıcılar işlevlere değinebilirler – ihtiyaçların nasıl yerine getirilebilecekleri <br />
  199. 199. İşlevler“Features”<br />İşlevler müşteri ihtiyaçlarının hangi ürün kabiliyetlerine karşılık geleceğini ifade ederler <br />İşlev sistemin bir ihtiyacı gidermek için sunduğu bir hizmettir<br />İşlevin faydası onun altında yatan ihtiyaçlara bakıldığında kendisini gösterir <br />Bir ihtiyaç sisteme değinmez; bunu bir işlev yapar <br />Örneğin, <br />Evden okula kayıt olabilmek istiyorum (ihtiyaç) -&gt; Sistemin internet erişimi olmalıdır (işlev)<br />
  200. 200. Hangisi Hangisi?<br />Kullanıcı görüşmesinde ihtiyaç ve işlev ayrımını hemen yapmak gerekmez <br />Daha sonra edinilen bilgilerin düzenlenmesinde yardımcı olur (brainstorming)<br />İşlev örneği arıyorsanız, yazılım ürünü reklamlarına bakınız!<br />
  201. 201. İhtiyaç ve İşlev Sayıları<br />İhtiyaçlar genellikle azdır – 10 veya daha az<br />İşlevler sistemin büyüklüğüne göre genellikle 25-100 arasında değişirler <br />Sistem kapsamı toplantıları için işlevler kullanılırlar<br />
  202. 202. İşlevler ve Gereksinimler<br />İşlevlerin (feature) detayları ortaya dökülmeye başlandığında gereksinimler (requirement) ortaya çıkmaya başlarlar<br />İşlev aşamasında geçici öncelikler verilebilir<br />İşlevleri ileride kolayca yönetebilmek için açıklamalarını yazınız <br />
  203. 203. İşlev/Gereksinim Değişkenleri (Attribute)<br />İşlevleri yönetebilmek için kullanılan tipik değişkenler:<br />Statü, {önerildi, onaylandı, reddedildi}<br />Öncelik, {yüksek, orta, düşük}<br />Emek, {yüksek, orta, düşük}<br />Risk, {yüksek, orta, düşük}<br />
  204. 204. İşlev/Gereksinim Değişkenleri (Attribute)<br />Değişebilirlik (Stability), işlevin ve ileride implementasyonunun değişme olasılığı / derecesi<br />Hedeflenen sürüm, Bu işlev hangi sürümde hazır olacak?<br />Görevli, Bu işlevle ilgili atama kime yapıldı? Aşamasına göre farklı kişiler olabilir (gereksinim, analiz vs.)<br />Neden veya Kaynak – Bu işlevin kaynağı nedir? <br />
  205. 205. İşlevler ve Gereksinimler<br />Üst seviye gereksinimler: İşlevler<br />“features”<br />Fonksiyonel gereksinimler<br />“functional requirements”<br />Fonksiyonel olmayan gereksinimler<br />“supplementary requirements”<br />
  206. 206. Gereksinim Grupları<br />
  207. 207. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  208. 208. VizyonDokümanı<br />GelenekselSRS<br />EkGereksinimler<br />Use-Case Modeli<br />Senaryo Odaklı Gereksinim Yönetimi<br />İhtiyaçlar<br />İşlevler<br />Senaryo Odaklı Yol<br />Geleneksel Yol<br />Gereksinimler<br />=<br />+<br />Geleneksel Software Requirements Specification (SRS) dokümanı Use Case Modeli ve Ek Gereksinimler Dokümanına (Supplementary Requirements) karşılık gelmektedir.<br />
  209. 209. Ek Gereksinimler<br />(Supplementary<br />Specification)<br />Proje Sözlüğü<br />(Glossary)<br />Gereksinim Ürünleri (Artifact)<br />Use Case Modeli<br />Aktörler<br />Use Case’ler<br />...<br />Use-Case Dokümanları<br />
  210. 210. İlgili Roller<br />Hazırlayan: İş Analisti, Sistem Analisti<br />Faydalanan: Tasarımcı, Kullanıcı Arayüzü Tasarımcısı, Ürün Kullanım Kılavuzu Yazarı, Veritabanı Tasarımcısı<br />Yardımcı: Müşteri, Müşteri Temsilcisi, Konu Uzmanı<br />
  211. 211. Gereksinim Ürünleri (Artifact)<br />Use Case Şemaları<br />
  212. 212. Gereksinim Ürünleri (Artifact)<br />
  213. 213. [1]Vizyon<br />Ürününüzün ilgili olduğu işi aklayan ve gerekli kabiliyetlerini ortaya koyan genel bir dokümandır <br />Ne yapmak istiyorsunuz ve o iş neden yapılmaya değer? <br />Vizyon dokümanı içeriği: <br />Giriş:<br /> ürününüzün karşılık olduğu temel ihtiyaçlara değininiz <br />
  214. 214. Vizyon<br />Konumlandırma (Positioning):<br /> hitap ettiğiniz pazarın sizin açınızdan problemli yanlarını, hedef kitlenizi ve rakiplerinizin ürünlerinin kabiliyetlerini (ne yapıp ne yapamadıkları) yazınız.<br />Paydaş Tanımları:<br /> paydaşların demografik yapısını, ürününüzü kullanmak için gereken kabiliyet seviyesini, paydaşlarınızın hedefleri ve yaşadıkları sorunları belirtiniz. Her paydaş türüne bir temsilci atayarak irtibat bilgilerini sağlayınız.<br />
  215. 215. Vizyon<br />Ürün işlevleri listesi:<br /> ürünün sağlaması gereken temel işlevleri ve bunların paydaşlara ne fayda sağlayacağını birer ikişer cümle ile yazınız <br />
  216. 216.
  217. 217. Vizyon - Amaç<br />
  218. 218. Vizyon – İş Fırsatı<br />
  219. 219. Vizyon – Problem Tanımı<br />
  220. 220. Vizyon - Paydaşlar<br />
  221. 221. Paydaş Detayları<br />
  222. 222. İşlevler<br />
  223. 223. Gereksinim Ürünleri (Artifact)<br />
  224. 224. [2]Use Case Dokümantasyonu<br />Monolog değil Dialog olmalı.<br />Aktörleri ile Use Case arasındaki etkileşimleri içermeli.<br />Müşteri ile Tasarımcılar, Veritabanı Tasarımcıları ve Arayüz Tasarımcıları arasındaki köprü olmalı.<br />
  225. 225. Use Case: Olayların Akışı<br /><ul><li>Bir tane olağan, en tipik akış: Temel Akış (“Happy Path”)
  226. 226. Birden fazla Alternatif Akış:
  227. 227. Başarılı alternatif akışlar
  228. 228. Başarısız Akışlarhata durumlarını tolere etmeye yarar</li></ul>“Happy Path”<br />
  229. 229. Senaryo Nedir?<br />Bir senaryo use case’in içerdiği akışların bir kombinasyonunun başlayıp bitişidir: Use Case Instance.<br />
  230. 230. Senaryolar<br />Use Case akışlarının bir kombinasyonudur (use case instance)<br />Bir senaryonun beklenen (başarılı) bir neticesi olabilir<br />Müşteri kitaplarını satın aldı<br />Veya başarısız bir neticesi olabilir<br />Müşterinin kredi kartı kabul edilmedi<br />
  231. 231. Senaryolar<br />Her use case’in odağı başarılı TemelAkışı’dır<br />Ancak pek çok başarılı ve başarısız Alternatif Akış olabilir<br />Alternatif senaryolar akış esnasında neler olabileceğini tespit yollarıdır. Örneğin, farklı şekillerde ödeme, bir transaction’ın bitirilememesi gibi<br />
  232. 232. Use Case Dokümanı Formatı<br />Tek-sütun formatında her paragraf aktör veya sistemin bir faaliyetini anlatır. Daha yaygın bir kullanımdır.<br />İki-sütun formatında sol sütun aktöre sağ sütun sisteme aittir ve faaliyetleri ona göre yer alırlar. Faydası dialoğun zigzag yapısını daha iyi göstermesidir.<br />
  233. 233. Use Case DokümanıGelişim Süreci<br />Bulunma<br />Tanımlanma<br />Konu Başlıkları<br />+ Kısa Tanımlar<br />Temel Akış Detaylanır<br />Tüm Akışlar Detaylanır<br />
  234. 234. Use Case Dokümanı İçeriği<br />Dokümanın mutlaka içermesi gerekenler ‘*’ işaretlenmiştir.<br />Temel Aktör*<br />Paydaşlar ve UC’le ilgileri<br />Precondition*<br />Postcondition*<br />Temel Akış*<br />Alternatif Akışlar*<br />
  235. 235. 1. Use Case Tanımı<br />İlişkili Use Case’ler<br />Ek Gereksinimler<br />İş Kuralları<br />Kullanım Yoğunluğu<br />Açık Konular<br />
  236. 236. 2. Temel Aktör<br />Bir use case için temel aktör o UC’i kendine bir fayda sağlamak için çalıştıran aktördür.<br />Dolayısıyla bu aktör UC’i için bir tetik mekanizmasıdır. <br />Temel Aktör genellikle insandır. Ancak bazen sistemler otomatik olarak dış sistemlere erişirler.<br />
  237. 237. 3. Paydaşlar ve UC ile İlgileri<br />Bu bölümde use case’in akışında bir parçası olan tüm aktörler ve kendilerine sağladıkları faydalar belirtilmelidir<br />Genellikle aktör başına bir iki cümle kafidir<br />
  238. 238. 4. Temel Akış<br />Herşeyin yolunda gittiği varsayılarak use case akışının adım adım ve aktörle sistem arasındaki dialoğu işaret edecek şekilde yazılmasıdır.<br />Bu akış iş kurallarını, üretilecek ve tüketilecek veri yapılarını ve yapılacak kontrolleri içerir.<br />Bu akış use case’in beklenen kullanım şeklini ifade eder.<br />Bütün adımlar aktör’ün perspektifiyle yazılır. Yalnızca onun gördükleri ve yaptıkları ile sistemin bu davranışlara reaksiyonlarını içerir.<br />
  239. 239. 5. Alternatif Akışlar<br />Temel akışın izlediği yolu değiştirebilecek koşulları ve bu durumlarda kullanılacak yeni akışları ifade eder <br />Bu başarısızlık durumlarını içerdiği gibi (kredi kartının reddedilmesi), farklı seçeneklerin izlediği yolları da içerir (çekle, kredi kartıyla veya paypal’le ödeme)<br />
  240. 240. 5. Alternatif Akışlar<br />Alternatif akışlar geçerli oldukları temel akış adımında yanlarına harf konarak işaretlenirler<br />Temel Akış 3. Kasiyer ürün numarasını girer<br />Alternatif Akış 3a. Geçersiz numara<br />Daha sonra da alternatif akış adımları yazılır<br />
  241. 241. 5. Alternatif Akışlar<br />Dolayısıyla alternatif akışların iki parçası olur:<br />Nedeni: Başlığı <br />Akışı: Kendine özel akışı<br />Nedeni: 3a. Geçersiz ürün numarasıAkışı: <br /> 1. Sistem bir hata mesajı vererek ürünün girilmesini engeller.<br />
  242. 242. 6. Precondition<br />Use Case’in çalışabilmesi için sistemin sahip olması gereken durumu ifade ederler <br />Bu liste temel aktörün o ana kadar yaptıklarını ve yapmadıklarını, şu andaki use case’e yönelmesine yol açan eylemleri içerebilir <br />
  243. 243. 7. Postcondition<br />Use case’in akışının tamamlanmasının sonucunda sahip olunması gereken durumları ifade eder<br />Bu da precondition gibi temel akış referanslı bir listedir. Herşey yolunda giderse use case akışı sonunda elimize ne geçecek? <br />
  244. 244. 8. Ek Gereksinimler<br />Fonksiyonel olmayan gereksinimler veya use case’e özel kısıtlamalar olabilir<br />Performans, Güvenilirlik, Kullanılabilirlik ve Tasarım Kısıtlamaları bu bölümde belirtilebilir<br />Use Case’e özel olmayan bu tür gereksinimler Ek Gereksinimler (Supplementary Specification) dokümanında yer alır<br />
  245. 245. 9. İş Kuralları<br />Use Case akışı esnasında uyulması gereken işe özel kuralları ve yapılması gereken kontrolleri gösterir.<br />Genellikle use case’e özel değil, proje genelinde bir doküman olarak oluşturulur. <br />
  246. 246. 10. Kullanım Yoğunluğu<br />Use Case’in kullanım yoğunluğunun belirtildiği bölümdür:<br />Günde 1000 defa mı?<br />Ayda 1 defa mı?<br />Use Case öncelikleri hakkında fikir verdiğinden tasarıma yardımcı olur<br />
  247. 247. 11. Açık Konular<br />Bu kısımda emin olmadığımız varsayımları, muhtemel teknoloji değişikliklerini ve bunlar gibi kesinleşmemiş konuların unutulmamalarını sağlayabiliriz. <br />Kesinleşmemiş hukuki, iş akışı ve interface konularını da burada belirtebiliriz. <br />
  248. 248. Bid on Item - Use Case Dokümanı<br />İnternette Açık Artırma<br />
  249. 249. UC Dokümanı - Tanım<br />
  250. 250. UC Dokümanı - Akış<br />
  251. 251. UC Dokümanı – Geriye Kalan<br />
  252. 252. Gereksinim Ürünleri (Artifact)<br />
  253. 253. [3]Ek Gereksinimler: FURPS+ Modeli<br />Ek Gereksinimlerin kapsamı:<br /><ul><li>Fonksiyonel (Functional)
  254. 254. Kullanılabilirlik (Usability)
  255. 255. Güvenilirlik (Reliability)
  256. 256. Performans
  257. 257. Bakım (Supportability)
  258. 258. + = geriye kalan herşey</li></li></ul><li>Fonksiyonel<br />Tüm sisteme yönelik fonksiyonel gereksinimler. <br />UC odaklı olmayan yazılım geliştirme yöntemlerini kullananlar için.<br />Fonksiyonel gereksinimlerin tamamı aslında UML yaklaşımında UC Modeliyle kapsanıyor. <br />
  259. 259. Kullanılabilirlik (Usability)<br />Kullanılabilirlik:<br />İnsan faktörü; sisteminizi kullanmak nasıl hoşnutluk verici olabilir? <br />Help; Kullanıcıya hangi help imkanı sağlanacaktır? F1? Context sensitive? Online kullanım kılavuzu?<br />Dokümantasyon; Kullanıcıları eğitmek için ne tür dokümantasyon üretilecektir? <br />
  260. 260. Güvenilirlik (Reliability)<br />Güvenilirlik ölçüm şekilleri: <br />Mean Time Between Failures (MTBF); İki sistem göçmesi arasında geçen zaman <br />Mean Time To Repair (MTTR); Sistem göçtüğünde çalışır hale getirilmesi için gereken zaman (Bu ‘bakım’ başlığı altında da olabilir)<br />Sistemin kullanılabilir durumunu koruması (Availability) ‘performans’ başlığı altında yer alır<br />
  261. 261. Performans<br />Çoğu performans kriteri gereksinime dönüşür<br />Sorgu cevaplama süresi (ortalama, maksimum)<br />Throughput (Saat veya gün başına işlenen kayıt sayısı, transactions per second (TPS))<br />Accuracy (scan veya veri giriş doğrululuğu)<br />Kaynak kullanımı (CPU, HDD kullanımı, network trafiği)<br />
  262. 262. Bakım (Supportability)<br />İçeriği:<br />Bakım prosedürünü içerir. Sorunlar için kılavuz mu sunacaksınız? <br />Sistemin bakımını yapmak ne kadar kolay? Yazılımı ve Donanımı birlikte düşününüz. <br />Internationalization; sisteminiz farklı dillerde kullanılabilecek mi?<br />Sisteminizin konfigürasyonu kolayca değiştirilebilir mi? <br />
  263. 263. “+”<br />İçeriği:<br />İmplementasyon <br />Interface<br />Operasyonel<br />Paketleme<br />Kanuni konular<br />Ve aklınıza ne gelirse! <br />
  264. 264. “+” - İmplementasyon<br />İmplementasyon üzerindeki sınırlamaları ifade eder:<br />Kaynak sınırlamaları (maliyet, zamanlama, eleman)<br />Dil ve ürünler (kullanılacak programlama ortamı)<br />Donanım (Dell)<br />Yazılım (MySQL)<br />Kullanıcı PC özellikleri (PIII 1000 MHz, 128 MB RAM, Windows ME)<br />
  265. 265. “+” - Interface<br />Interface gereksinimleri dış sistemlerle haberleşme amaçlıdır: <br />Kurumuzdaki eski sistemler<br />Bileşenlerini satan şirketler<br />Başka proje ekipleri<br />Dış kurumlar (İMKB vs.)<br />
  266. 266. “+” - Operasyonel<br />Sisteminiz kullanım halindeyken yönetilebilmelidir<br />Yöneticilere gereken kabiliyetler?<br />Kullanıcı ekleme<br />Kullanıcı erişim haklarını değiştirme<br />Kaynak kullanımını izleme (CPU, disk, network)<br />Fiziki ortamı izleme (ısı, nemlilik)<br />
  267. 267. “+” - Paketleme<br />Ürününüz nasıl paketlenecek?<br />Medya? CD-ROM? DVD?<br />Hangi dokümanlar basılacak? Hangileri elektronik ortamdan sağlanacak?<br />Kullanıcılar için help desk kimlerden oluşacak?<br />Farklı ülkelere özel çalışmalar yapılacak mı? <br />
  268. 268. “+” - Kanuni<br />Ürününüz nasıl lisanslanacak?<br />Kullanıcı başına? Şirket başına?<br />PC başına?<br />CPU başına?<br />Ürününüzün farklı versiyonları var mı? (akademik, profesyonel)<br />Ürününüzün satılamayacağı yerler var mı? (ihracat kısıtlamaları)<br />
  269. 269. FURPS + ve UML<br />
  270. 270. Gereksinim Ürünleri (Artifact)<br />
  271. 271. [4]Sözlük (Glossary)<br />Proje terimlerini içerir:<br />Terim 1, Terim 2, … Terim N<br />Kısaltmaları ve use case dokümanlarında ifade edilseler çok yer kaplayarak okunmayı zorlaştıracak veri yapısı tanımlarını içerir<br />Tanımlar dokümanda olabilir veya başka bir dokümanı refere edebilir<br />Sözlük hyperlink’ler içerebilir<br />
  272. 272. İçerik<br />Proje Başarısızlığı Nedenleri<br />Gereksinim Yönetimi Kavramları<br />Gereksinim Yönetimi Teknikleri<br />Problem Analizi Teknikleri<br />Gereksinim Türleri<br />Gereksinim Dokümanları<br />Önceliklendirme ve Takip Edilebilirlik<br />
  273. 273. Gereksinimleri Önceliklendirme<br />Tüm gereksinimler (özellikle use case modelindeki fonksiyonel gereksinimler) için öncelikler belirlemeli ve ona göre zaman planı yapmalıyız.<br />Önceliklendirme gereksinim değişkenleri kullanılarak yapılmalıdır:<br />{Tür: Zaruri, İstenen, Seçeneğe Tabii}<br />{Sistem Mimarisine Etki: Var, Yok}<br />{Emek: Zor, Orta, Kolay}<br />Vs. vs.<br />
  274. 274. Gereksinimlerin Takip Edilebilirliği<br />
  275. 275. Önceliklendirme ve Takip Edilebilirlik Kriterleri<br />
  276. 276. Önceliklendirme ve Takip Edilebilirlik Kriterleri<br />veya<br />
  277. 277. Gereksinim Yönetimi Planı 1“Vizyon Kapsamında”<br />
  278. 278. Gereksinim Yönetimi Planı 2“Vizyon Kapsamında”<br />
  279. 279. Gereksinim Yönetimi Planı 3“Vizyon Kapsamında”<br />
  280. 280. Gereksinim Yönetimi Planı 4“Vizyon Kapsamında”<br />
  281. 281. Gereksinim Yönetimi Planı<br />Configuration Management Plan<br />Requirements Management Plan<br />
  282. 282. 1. İterasyonların Belirlenmesi<br />İnternet’te Açık Artırma Sistemi<br />
  283. 283. 2. İterasyonların Belirlenmesi<br />
  284. 284. 3. İterasyonların Belirlenmesi<br />Sistem Mimarisini Etkileyen UC’ler<br />İterasyon 1<br />İterasyon 2<br />İterasyon 2<br />
  285. 285. İlham Kaynakları<br />James Bielak<br />Ellen Gottesdiener<br />Alistair Cockburn<br />?<br />Sizin Adınız<br />
  286. 286. Pratik Çalışma<br />
  287. 287. Analistler için Modelleme<br />Bölüm 1 / 6<br />
  288. 288. İçerik<br />
  289. 289. Eğitmen Hakkında<br />Erol Bozkurt <br />Bilişim Teknolojileri Danışmanı<br />University of Houston, Computer Science.<br />Uzmanlıklar:<br />Real Time Simülasyon Sistemleri Tasarımı ve Programcılığı,<br />Sistem Analizi, UML ve Yazılım Süreçleri Danışmanlığı.<br />
  290. 290. Eğitim Planı<br />9:00 – 12:30 (3 Ders)<br />Öğle arası (12:30 – 13:30)<br />13:30-18:00 (4 Ders)<br />60 dakikada bir ara: 10 dk.<br />İhtiyacınıza göre düzenlemeler yapılabilir.<br />
  291. 291. Tipik Katılımcı Profili<br />Nesne Tabanlı Yazılım Deneyimi Olanlar<br />Nesne Tabanlı Yaklaşımı Öğrenmek İsteyenler<br />Analistler, Tasarımcılar, Programcılar, …<br />Süreç Mühendisleri<br />Kalite Sorumluları<br />Proje Yöneticileri<br />Konu Uzmanları (Domain Expert)<br />Müşteriler <br />
  292. 292. Katılımcılar Hakkında<br />Şirketiniz ve faaliyet alanı<br />Sizin rolünüz<br />Eğitim almanızdaki nedenler<br />Eğitime yönelik beklentileriniz<br />
  293. 293. Eğitim Materyalleri<br />Eğitim Kitabı.<br />Çalışmalarımızda kullanacağımız ürünlerin demolarını ve egzersiz dokümanları içeren CD-ROM.<br />
  294. 294. Bizi Seçtiğiniz İçin Teşekkür Ederiz!<br />
  295. 295. Analistler için Modelleme<br />Bölüm 2 / 6<br />
  296. 296. İçerik<br />
  297. 297. İçerik<br />Nesne Tabanlı Yaklaşımın Temelleri<br />Class’lar ve Nesneler<br />
  298. 298. Nesne Tabanlı Yaklaşım:<br />Esnek bir Referans Mekanizması: Abstraction<br />Etkili bir Gizleme Mekanizması: Encapsulation<br />Sistemi Hazmedilebilir Parçalara Ayırabilmek: Modularity<br />Sistemin Parçalarının Alakalandırılabilmesi: Hierarchy<br />
  299. 299. Abstraction<br />Abstraction<br />
  300. 300. Abstraction (Soyutlama)<br />Sisteme değişik referanslara göre bakmak<br />Kullanıcı bazında geçerli hizmetleri saptamak<br />Bir kullanıcıya yönelik olmayan sistem hizmetlerini ondan gizlemek<br />
  301. 301. Encapsulation<br />
  302. 302. Encapsulation (Gizleme)<br />Kullanıcıya bir basitlik illüzyonu verebilmek<br />Kullanıcıyı gereksiz sistem detaylarıyla uğraşmaktan kurtarmak<br />Sistemin parçalarının kolayca tekrar kullanımına imkan vermek<br />
  303. 303. Modularity<br />
  304. 304. Modularity (Çok Parçalılık)<br />Tekrar kullanımı kolaylaştırmak<br />Testi ve Bakımı kolaylaştırmak<br />Bir projeye yönelik parçaların entegrasyonunu kolaylaştırmak<br />
  305. 305. Kullanıcı<br />Her abstraction<br />bir hiyerarşi <br />oluşturur.<br />Sistem<br />
  306. 306. Hierarchy (Hiyerarşi)<br />Class’ların sağladıkları fonksiyonellik bazında uzmanlaşmalarına imkan vermek<br />Genel kullanıma açık metodları belirli paketler halinde toplayabilmek<br />Sistemin yapısının takibini kolaylaştırmak<br />
  307. 307. İçerik<br />Nesne Tabanlı Yaklaşımın Temelleri<br />Class’lar ve Nesneler<br />
  308. 308. Class’lar ve Nesneler<br />ali meltem<br />özellikler/benzerlikler?<br />
  309. 309. Class’lar ve Nesneler<br />ali meltem<br />yaş cinsiyet ad soyad<br />
  310. 310. Class’lar ve Nesneler<br />iki FARKLI kişi<br />ali meltem<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />
  311. 311. Class’lar ve Nesneler<br />yaş<br />cinsiyet<br />ad<br />soyad<br />Değişkenler/<br />özellikler<br />nesne<br />ali<br />meltem<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />
  312. 312. Class’lar ve Nesneler<br />Değişkenler/<br />özellikler<br />???<br />Diğer nesneler:<br />
  313. 313. Class’lar ve Nesneler<br />isim<br />başkent<br />nüfus<br />paraBirimi<br />Değişkenler/<br />özellikler<br />Diğer nesneler:<br />Avustralya<br />İngiltere<br />İtalya<br />
  314. 314. Class’lar ve Nesneler<br />Tüm nesneler<br />Bu nesneleri birbirlerinden nasıl ayıracağız?<br />
  315. 315. Class’lar ve Nesneler<br />yaş<br />cinsiyet<br />ad<br />soyad<br />isim<br />başkent<br />nüfus<br />paraBirimi<br />Kişi<br />Ülke<br />Ortak değişkenler<br />
  316. 316. “yenibirkişi”<br />?<br />“hangideğişkenler?”<br />Class’lar ve Nesneler<br />yaş<br />cinsiyet<br />ad<br />soyad<br />Değişkenler/<br />özellikler<br />Kişi(ler)<br />ali<br />meltem<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />
  317. 317. “yenibirkişi”<br />Class’lar ve Nesneler<br />yaş<br />cinsiyet<br />ad<br />soyad<br />Değişkenler/<br />özellikler<br />Kişi(ler)<br />ali<br />meltem<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />yaş<br />cinsiyet<br />ad<br />soyad<br />
  318. 318. Class’lar ve Nesneler<br />Kişi<br />yaş<br />cinsiyet<br />ad<br />soyad<br />Nesne tabanlı terminoloji<br />class<br />(instance)variables<br />attributes<br />fields<br />
  319. 319. Class’lar ve Nesneler<br />yaş<br />cinsiyet<br />ad<br />soyad<br />Kişi<br />instances<br />ali<br />meltem<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />Nesneler<br />
  320. 320. Class’lar ve Nesneler<br />İngiltere<br />Nesneler<br />ali<br />Bir nesnenin özellikleri nelerdir?<br />isim : ingiltere<br />Başkent : Londra<br />Nüfus: 3,534,209<br />paraBirimi : Pound<br />}<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />?<br />}<br />?<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />}<br />?<br />meltem<br />
  321. 321. Class’lar ve Nesneler<br />kimliği<br />kimliği<br />İngiltere<br />Nesneler<br />ali<br />Bir nesnenin özelliklerini ne belirler?<br />isim : ingiltere<br />Başkent : Londra<br />Nüfus: 3,534,209<br />paraBirimi : Pound<br />}<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />state<br />}<br />state<br />yaş : 23<br />cinsiyet : kadın<br />ad : meltem<br />soyad : manisalı<br />}<br />state<br />kimliği<br />meltem<br />
  322. 322. Class’lar ve Nesneler<br />Nesne<br />Nesnenin sahip olduğu özellikler<br />State: Durum<br />Identity: Kimlik<br />
  323. 323. Class’lar ve Nesneler<br />Nesneler<br />Değişebilir<br />Benzersiz<br />State / Durum<br />Identity / Kimlik<br />
  324. 324. Class’lar ve Nesneler<br />{Orta Yaş}<br />{Yetişkin}<br />Benzersiz<br />Identity / Kimlik<br />yaş : 25<br />cinsiyet : erkek<br />ad : ali<br />soyad : turalı<br />yaş : 45<br />cinsiyet : erkek<br />ad : veli<br />soyad : kara<br />State / Durum aynı da olabilir farklı da<br />
  325. 325. Analistler için Modelleme<br />Bölüm 3 / 6<br />
  326. 326. İçerik<br />
  327. 327. İçerik<br />Görsel Tasarım<br />UML Modeli<br />UML Sonrasında Yazılım Dünyası<br />
  328. 328. Görsel Tasarım<br />Bir sistemin verdiği bir hizmeti<br />nasıl gerçekleştirdiğinin görsel olarak ifade edilmesidir.<br />
  329. 329. UML Süreci Yaklaşımları<br />use-case driven (kullanıcıya sağlanan fayda odaklı), <br />architecture centric (esnek, bakımı ve tekrar kullanılabilirliği kolay bir sistem mimarisi oluşturmaya elverişli), <br />iterative (kademeli olarak)<br />incremental (birbirinin üzerine inşa ederek).<br />
  330. 330. Rumbaugh Tanımı<br />Bilgi İşlem<br />“Bir Model bir Sistemin<br /> vazgeçilmez özelliklerini gösterir.”<br />Dr. James Rumbaugh<br />Sipariş<br />Ürün<br />Kargo<br />İş Akışı<br />Görsel Tasarım standartlaşmış sembolleri kullanarak tasarım yapmaktır<br />
  331. 331. Görsel tasarımın faydaları<br /><ul><li>İşAkışıBilgisiToplamak
  332. 332. İletişimiKolaylaştırmak
  333. 333. ProjeKontrolünüArtırmak
  334. 334. SistemMimarisiniOluşturmak
  335. 335. TekrarKullanabilmek</li></li></ul><li>İş Akışı Bilgisi Toplamak<br /> Use Case’ler ile yazılımın müşteri kullanımı odaklı olması sağlanıyor. <br />
  336. 336. İletişimi Kolaylaştırmak<br />Birlikteçalışmasıgerekenbuikitakımçoğuzamanfarklıkelimehazneleriyüzündenanlaşamıyor.<br />GörselTasarımdaUMLkullanımımüşterinindünyasıylasistemindünyasınıbirbirinebağlar<br />Programcılar bu gereksinimlere dayanarak sistemi oluştururlar<br />İş Analistleri sistemin gereksinimlerini belirlerler<br />
  337. 337. Proje Kontrolünü Artırmak<br />Sistemleryüzlercehattabinlerceclass’danoluşabiliyor.<br />Buclassgruplarısistemebakankişininihtiyacınagöreorganizeedilebilmeli.<br />GörselTasarımsistemefarklıyönlerdenbakabilmeyisağlar.<br />
  338. 338. Sistem Mimarisi Oluşturmak<br />GörselTasarımoluşançözümükullanılanprogramlamadilindenbağımsızhalegetirir.<br />Programlamadilibelirlenincetasarımfizikiortamataşınır.<br />
  339. 339. Tekrar Kullanabilmek<br />Farklı Sistemler<br />Tasarımınızıbileşenlerebölerekçözümünüzünparçalarınıtekrarkullanabilirsiniz.<br />Bileşenler<br />
  340. 340. UML Öncesi<br />1960 - 70<br />COBOL, FORTRAN, C<br />Yapısal analiz ve tasarım teknikleri<br />1980 – 1990 başları<br />Smalltalk, Ada, C++, Visual Basic<br />İlk NT yöntemlerin ortaya çıkması<br />1990’ların geriye kalanında<br />Java<br />UML<br />Unified Process<br />
  341. 341. Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html<br />UML Öncesi<br />
  342. 342. İçerik<br />Görsel Tasarım<br />UML Modeli<br />UML Sonrasında Yazılım Dünyası<br />
  343. 343. Modeller ve Şemalar<br />Bir model bir sistemin<br />Belli bir açıdan eksiksiz olarak<br />Ifade edilebilmesini<br />sağlar<br />State<br />Diagrams<br />State<br />Diagrams<br />Class<br />Şeması<br />Use Case<br />Diagrams<br />Use Case<br />Diagrams<br />State<br />Diagrams<br />Use Case<br />Şeması<br />State<br />Diagrams<br />Use Case<br />Diagrams<br />Object<br />Şeması<br />Use Case<br />Diagrams<br />Sequence<br />Şeması<br />Scenario<br />Diagrams<br />State<br />Diagrams<br />Scenario<br />Diagrams<br />State<br />Diagrams<br />Component<br />Şeması<br />Collaboration<br />/ Communication<br />Şeması<br />Model<br />Component<br />Diagrams<br />Scenario<br />Diagrams<br />Component<br />Diagrams<br />Scenario<br />Diagrams<br />Deployment<br />Şeması<br />Statechart<br />/ State Machine<br />Şeması<br />Activity<br />Şeması<br />
  344. 344. Modellerin Faydaları<br />Problem Çözme Mekanizması<br />Alternatif Çözümleri Görebilme<br />Sistemin Karmaşıklığını Kontrol Altına Alabilme<br />Ürünleri Daha Hızlı Oluşturabilme<br />Proje Maliyetini Düşürme<br />Hataları Azaltabilme<br />
  345. 345. Model Nedir?<br />Gerçeğinbasitleştirilmişbirifadesi,<br />SisteminveyaSürecinkavramsaldüzeydeanlaşılmasıdır<br />
  346. 346. Model Kullanımı<br />Gereksiz<br />Zaruri<br />F-15<br />Kağıttan Uçak<br />
  347. 347. Model Kullanımı<br />BilişimTakımlarıF-15’lerikağıttanuçakyaklaşımıylaoluşturabileceklerinizannedebiliyor.<br />GereksinimlerdenKodlamayageçiş<br />Dahauzunçalışmak,sistemmimarisiodaklıolmayankodyazmak<br />EsnekbirSistemMimarisiolmaması<br />Başarısızlık<br />
  348. 348. Modelin Faydası<br />Tasarladığımız çözümü anlayabilmek<br />Modeller ...<br />Tasarlamak istediğimiz çözümü düşünebilmemize,<br />Sistemin yapısını ve davranışını belirleyebilmemize, <br />Sistemi oluşturabilmemize ve <br />Yaptıklarımızı dokümante edebilmemize yarıyor.<br />Kapsamlı sistemleri modeller olmadan tasavvur etmek bile mümkün değil.<br />
  349. 349. 4 Model Kuralı<br />Modelprobleminasılçözeceğinizibelirler.<br />Hermodelfarklıdetayseviyelerindekullanılabilir.<br />Modelçözümünkullanılacağıdünyadankopmamalıdır.<br />Çözümeyöneliktekbirmodelyetersizdir<br />
  350. 350. 4 Model Kuralı<br />Modelprobleminasılçözeceğinizibelirler.<br />Oluşturacağınızmodelproblemeveçözümeyaklaşımınızıbelirler.<br />Seçilenmodelbiranlamdünyasıoluşturur<br />Heranlamdünyasısizibaşkabirçözümeyöneltir<br />
  351. 351. 4 Model Kuralı<br />Hermodelfarklıdetayseviyelerindekullanılabilir<br />Her model kullanıcısına yönelik olmalıdır.<br />Detay seviyesi modeli kimin ve ne amaçla kullandığına göre değişmelidir.<br />
  352. 352. 4 Model Kuralı<br />Modelçözümünkullanılacağıdünyadankopmamalı<br />Modelgerçekçiolmalı<br />Gerçekyerinegörebirkullanımsenaryosu,yerinegörebirsistemkısıtlamasıolabilir.Dolayısıylamodelfarklıreferanslarıbarındırabilmelidir.<br />Gerçeğibasitleştirmeli<br />Riskliunsurlarıişaretetmeli<br />
  353. 353. 4 Model Kuralı<br />Çözümeyöneliktekbirmodelyetersizdir<br />Sistemlerbirbirlerikötüolaraketkilemeyenfarklımodellerleincelenmeli.<br />Birbirlerindenbağımsızolarakoluşturulabilen,incelenebilenfakatbirbirleriylealakalıolanmodelleroluşturulmalıdır<br />Modellerinfarklıreferansları,oluşturulmanedenlerivekullanıcılarıolmalıdır.<br />
  354. 354. Kullanıcı<br />İşlevsellik<br />SistemMimarı<br />Performans<br />Sisteme4+1Bakışı<br />Logical View<br />Implementation View<br />Analiz /Tasarım<br />Kod<br />Versiyonlar<br />Use-Case View<br />Process View<br />Deployment View<br />Topoloji<br />kurulum, kullanım<br />
  355. 355. İçerik<br />Görsel Tasarım<br />UML Modeli<br />UML Sonrasında Yazılım Dünyası<br />
  356. 356. Fallingwater: <br />http://www.casas.com/architect/franklloydwright/fallingwater000.html<br />UML Sonrası<br />Frank Lloyd Wright<br />
  357. 357. UML’in Sınırları<br />Takım Üyeleri<br />Dil<br />Kullanılan<br />Süreç<br />
  358. 358. UML’in Yarattığı İş Fırsatları<br />Ken Ishiwata<br />Yetenekli bilişim elemanlarının deneyimlerini aktarabilmeleri<br />Yeni mezunların ustalarından örnek alabilmeleri<br />Problem çözümlerinin gereksinim, analiz ve tasarım faaliyetlerinin yan ürünlere dönüşmesi<br />İşverenlerin en kritik bilgilerini altyapı çalışmalarından ayırabilmeleri<br />Müteşebbislerin kendilerini daha çok yeni iş fikirlerine adayabilmeleri<br />
  359. 359. Fırsatlara örnekler<br />İnfina: İş bilgisi satma,<br />Anadolu Hayat: Altyapı değerlendirme,<br />Uml öğrenen doktor,<br />Yazılım projesine giren haritacılar,<br />Alman sigorta uygulama referans modeli,<br />Vs. vs.<br />
  360. 360. UML Kehanetleri<br />Teknolojik altyapı kullanımı kolaylaşacak<br />İşe özel nesne tabanlı yaklaşım bilgilerine erişim kolaylaşacak<br />İş mantığı bilgilerine erişim kolaylaşacak<br />Yönetsel yaklaşımların önemi artacak<br />İş mantığını gizleme artacak<br />Kod ve framework paylaşımı artacak<br />İş uzmanlarının yazılım alanına iştirakleri artacak<br />İşe özel framework pazarı kızışacak<br />Yazılım evleri uluslararası çalışmalara daha çok girmeye başlayacak<br />Az sayıda kişiden oluşan ve kısıtlı bütçe sahibi ekiplerin etkinlikleri artacak<br />Tasarımcı ve Sistem Analistlerinin popülerlikleri artacak<br />Programcıların önemleri daha çok algoritmik karmaşıklığa sahip alanlarda korunacak<br />Framework bazlı kodlama hangarları oluşmaya devam edecek<br />Yazılım elemanlarının kişisel önemleri artacak<br />
  361. 361. İlham Kaynakları<br />Max Goff<br />Eğitimimizin sonunda açık kaynak kodlu bir projeyi UML modelinize çekin ve inceleyin: <br />www.sourceforge.net<br />“Zero Dollar Bill”<br />
  362. 362. Analistler için Modelleme<br />Bölüm 4 / 6<br />
  363. 363. İçerik<br />
  364. 364. İçerik<br />UML Modeli Kavramları<br />UML Tanımını Genişletme Mekanizmaları<br />Davranış Şemaları<br />Yapısal Şemalar<br />
  365. 365. UML 2.0 Şema Türleri<br />*<br />*<br />*<br />*<br />*<br />
  366. 366. Kısaca UML<br />UML sembolik bir dildir:<br />Yazılım sistemlerinin oluşturulması esnasında ortaya çıkan iş ürünlerinin<br />Tasavvur edilebilmesine,<br />İfade edilebilmesine,<br />Oluşturabilmesine ve <br />Dokümante edilebilmelerine yarar.<br />
  367. 367. UML Modeli Oluşturma Nedenleri<br />Oluşturulacak sistemin yapısı ve davranışı hakkındaki bilgiyi paylaşmak<br />Sistem mimarisini tasavvur ve kontrol edebilmek<br />Sistemi daha iyi anlayıp çözümü basitleştirmek ve tekrar kullanılabilirliği artırmak<br />Riskleri yönetebilmek<br />
  368. 368. 4 Model Kuralı<br />Oluşturduğunuz model problemi nasıl çözeceğinizi belirler.<br />Her model farklı detay seviyelerinde bilgi verebilir.<br />En iyi modeller gerçekle bağlarını koparmayanlardır.<br />Tek bir model kesinlikle kafi değildir.<br />
  369. 369. İçerik<br />UML Modeli Kavramları<br />UML Tanımını Genişletme Mekanizmaları<br />Davranış Şemaları<br />Yapısal Şemalar<br />
  370. 370. UML Genişletme Mekanizmaları<br />UML tanımı çok geniş de olsa bazen özel durumlara uyabilmesi için ‘genişletilmesi’ (extend) gerekebilir.<br />UML tanım genişletme mekanizmaları<br /><ul><li>Yeni model sembolleri oluşturmak,
  371. 371. Yeni özellikler (property) tanımlayabilmek,
  372. 372. Yeni semantik yapılar oluşturabilmek için kullanılır.</li></ul>Genişletme mekanizmaları dörde ayrılır:<br /><ul><li>stereotype, tagged values, kısıtlar ve notlar</li></li></ul><li>Stereotype<br />Stereotype genellikle UML sembollerini yeni ortamlarda tanımlamak amacıyla kullanılır:<br />Örneğin Asansör Kontrol Sisteminin bir modelini oluştururken, bazı class’ları ve durumlarını (state) vurgulamak isteyebiliriz <br />«hardware»<br />«software»<br />Stereotype mutlaka tanımlandığı özel durum için ve hep aynı şekilde (mantıkla) kullanılmalıdır. <br />
  373. 373. Stereotype<br />«button»<br />CancelButton<br />Stereotype<br />ikon gösterimi<br />Stereotype<br />etiket gösterimi<br /><br />CancelButton<br />state<br />Stereotype kullanım şekli:<br /><ul><li>Stereotype’ı UML sembolünün adının üstüne yerleştiriniz</li></ul>Stereotype adını «» işaretleri arasına koyunuz: (Örneğin, «node»)<br /><ul><li>Yeni ikonu (resmini) tanımlayınız </li></li></ul><li>Stereotype“UML Tanımıyla Gelenler”<br />Tanımlı Stereotype’lar:<br />UML tanımı içinde mevcut, anlamı kesin olarak belirlenmiş ve işarete karşılık gelen bir ikonu olan işaretlerdir.<br />&lt;&lt;Stereotype Adı&gt;&gt;<br />Tanımla Gelenler:<br />Boundary, Entity, Control<br />Aktör, vs.<br />
  374. 374. Size Ait İşaretler“UML in Color”<br />Peter Coad (TogetherSoft) entity<br />class’larının da kendi aralarında<br />gruplara ayrılması gerektiğini <br />söyler:<br />&lt;&lt;Thing&gt;&gt; <br />&lt;&lt;Description&gt;&gt; <br />&lt;&lt;Role&gt;&gt; <br />&lt;&lt;Moment-Interval&gt;&gt;<br />
  375. 375. Tagged Values<br />Tagged values<br />UML sembollerine ek özellikler atarken kullanılır<br />Mevcut UML sembol ve stereotype’larına eklenebilir<br />Bir isim-değer (özellik-değer, tag-value) ikilisi olarak kullanılır. <br />Genellikle aşağıdaki konularda kullanılır<br /><ul><li>Kod üretimi
  376. 376. Versiyon kontrolü
  377. 377. Konfigürasyon yönetimi
  378. 378. Sahiplik (telif hakkı kanıtı)
  379. 379. vs. vs.</li></li></ul><li>Tagged Values<br />tagged value<br />{yazan = “Ali”, <br />Versiyon = 2.5}<br />Eleman<br />isim<br />adres<br />Tagged value {} parantezi içine yazılan çok kısa bir nottur:<br /><ul><li>{tag adı, ayraç (=), bir değer}’den oluşur.</li></li></ul><li>Kısıtlamalar<br />UML’in semantik yapısına yeni kurallar ekleyerek veya mevcut kuralları değiştirerek onu genişletirler<br />Her zaman uyulması gereken kuralları tanımlarlar<br />Kısıtlamalar tıpkı birer not gibi yazılabildiği, kullanılan UML ürününün api’ı ve/veya özel menü sistemleri aracılığıyla da yazılabilirler<br />
  380. 380. Tagged Values ve Kısıtlamalar<br />Gösterimleri aynıdır. UML ürünleri kullanıldığında NOT sembolünün içine yazılırlar. Pek çok farklı yerde belirtilebildiklerinden yaygın bir kullanımı yoktur.<br />{Tagged Value / Constraint}<br />{Vermek istediğiniz ek bilgi}<br />{Vurgulamak istediğiniz kısıtlama}<br />
  381. 381. Notlar<br />Abstraction-occurrence pattern<br />1..*<br />Title<br />Copy<br />Oluşturulan modellere eklenen daha detaylı açıklamalardır<br /><ul><li>Örneğin, verilen bir tasarım kararının gerekçesini vurgulamak amacıyla kullanılabilir. </li></ul>Not ikonu içine yazılan yazılardır<br />
  382. 382. UML Metamodel<br />Metamodel olası modellerin kullanacağı yapısal ve semantik özelliklerin tanımlandığı bir modeldir<br />UML modeli, ait olduğu metamodelin bir uygulanış şeklidir<br />UML metamodeli<br />UML sembollerini tanımlar<br />Tanımlamalar için UML sembollerinin bir alt kümesini kullanır <br />Aralarında ilişkiler kurulan paketlerle düzenlenir<br />
  383. 383. <ul><li>UML metamodeli aşağıdaki konulara yanıtlar bulunarak oluşturulur:
  384. 384. Syntax Yapısı (Abstract Syntax): Class Şemaları kullanılarak tanımlanır
  385. 385. Net olarak tanımlanmış kurallar: Model öğelerinin uyması gereken kurallar (sınırlamalar) tanımlanır
  386. 386. Örneğin, bir class’ın birden fazla adı olamaz
  387. 387. Semantik Yapı: Model öğelerinin ilşkilendirilme biçimleri gündelik dille tanımlanır</li></ul>UML Metamodel<br />
  388. 388. UML Profilleri<br />UML Profilleri özel konulara yönelik UML modelleri geliştirebilmemizi sağlarla<br /><ul><li>Örneğin, süreç mühendisliği, gerçek zamanlı sistemler, web uygulamaları vs. vs.</li></ul>Bir profil ‘paketinde’ bir veya daha çok genişletme mekanizması ürünleri bulunur (stereotype, tagged value, kısıtlamalar) <br />Bunlar UML model öğelerine uygulanarak kullanılırlar<br />
  389. 389. UML Profilleri<br />Bir UML profilinde aşağıdaki çalışmalardan gerekenler yapılır: <br /><ul><li>UML metamodelinin ilgili bir bölümü seçilir
  390. 390. Stereotype’lar ve/veya tagged value çiftleri tanımlanır
  391. 391. Mevcut kurallara yeni ekler tanımlanır
  392. 392. Yeni bir semantik yapı tanımlanır </li></li></ul><li>Profil Örneği<br />Temel GUI bileşenlerine yönelik bir profil tanımlarsak, <br />GUI yapımız aşağıdaki öğelere sahip olacaktır:<br /><ul><li>Formlar
  393. 393. Butonlar</li></ul>Kısıtlamalar: <br />Bir form bir ‘dialog box’ı çalıştırabilir<br />Formlar ve Dialog Box’ların butonları olabilir<br />
  394. 394. GUI Profili<br />GUI Profili<br />Class<br />Association<br />&lt;&lt;stereotype&gt;&gt;<br />Form<br />&lt;&lt;stereotype&gt;&gt;<br />Button<br />&lt;&lt;stereotype&gt;&gt;<br />Contains<br />&lt;&lt;stereotype&gt;&gt;<br />Invokes<br />&lt;&lt;stereotype&gt;&gt;<br />DialogBox<br />Class ve Association UML metamodelinden <br />gelmektedir<br />
  395. 395. GUI Profili Uygulaması<br />&lt;&lt;Form&gt;&gt;<br />MainView<br />1<br />1<br />&lt;&lt;Invokes&gt;&gt;<br />&lt;&lt;DialogBox&gt;&gt;<br />OpenDialogBox<br />1<br />1<br />&lt;&lt;Contains&gt;&gt;<br />&lt;&lt;Contains&gt;&gt;<br />1<br />1<br />&lt;&lt;Button&gt;&gt;<br />OkButton<br />&lt;&lt;Button&gt;&gt;<br />CancelButton<br />
  396. 396. İçerik<br />UML Modeli Kavramları<br />UML Tanımını Genişletme Mekanizmaları<br />Davranış Şemaları<br />Yapısal Şemalar<br />
  397. 397. UML 2.0 Şemaları<br />
  398. 398. Davranış Şemaları<br />use case şeması*<br />activity şeması*<br />Etkileşim Şemaları<br />sequence şeması<br />collaboration / communication şeması<br />interaction overview<br />timing şeması<br />statechart / state machine şeması*<br />
  399. 399. Use Case Şeması<br />Temel Kavramlar<br />Şema İçeriği<br />Şemayla Aktarılan Bilgiler<br />Tasarım Teknikleri<br />Forward ve Reverse Engineering<br />
  400. 400. Temel Kavramlar<br />Her tasarlanan sistem bir insanla veya başka bir sistemle etkileşir<br />Sistemin kullanıcıları onun tahmin edilebilir bir şekilde çalışmasını beklerler<br />Use Case sistemin kullanıcılarına sunacağı bir hizmetin senaryo şeklindeki anlatımıdır.<br /> Bu yüzden bir fiil ismine sahiptir: Yap, Et gibi adlandırılır. Örneğin, “Para Çek”, “Havale Yap”.<br />Aktör sistemin sunduğu hizmetleri kullanan bir kişi veya başka bir sistemdir.<br />Aktörler mutlaka tasarlanan sistemin dışında olmalıdırlar.<br />
  401. 401. Use Case’lerin 3 Temel İşlevi<br />Sistemin Sınırlarını Çizmek: Tasarlanan sistemin dışarıdan nasıl görüleceğini programcılara da yol gösterebilecek şekilde belirlemek<br />Sistemin Bütünlüğünü Görebilmek: Sunulan hizmetlerin sistem içinde nasıl gerçekleştirileceğini görebilmek<br />Test için Referans Oluşturmak: Sistem oluştukça eklenen yeni unsurları kaldırıp kaldıramayacağını anlamak<br />
  402. 402. ‘Sihirli’ Use Case Sayısı Nedir?<br />Functional Decomposition!<br />
  403. 403. İlgili Roller<br />Şemayı Hazırlayanlar:<br />İş Analisti<br />Sistem Analisti<br />Şemayı Kullananlar:<br />Müşteri<br />Proje Yöneticisi<br />Tasarımcı<br />Veri Tabanı Analisti<br />Kullanıcı Arayüzü Tasarımcısı<br />Testçi<br />Kullanım Kılavuzu Hazırlayanlar<br />
  404. 404. Use Case Şeması Sembolleri - 1<br />
  405. 405. Use Case Şeması Sembolleri - 2<br />
  406. 406. Use Case Şeması Sembolleri - 3<br />
  407. 407. Şema Örneği 1<br />
  408. 408. Use Case Bulma Teknikleri 1<br />
  409. 409. Use Case Bulma Teknikleri 2<br />Event Table Çalışması:<br />
  410. 410.
  411. 411. Use Case Bulma Teknikleri 3<br />Aktörler Adaylarını Bulun<br />Event Table Çalışmasını Yapın<br />Aktör ve Use Case’leri Belirleyin<br />Aktörleri Çizin ve İlişkilerini Düşünün<br />Use Case’leri Çizin ve Aktörlere Bağlayın<br />Use Case’ler Arasındaki İlişkileri Belirleyin<br />
  412. 412. Aktör Bulma Soruları<br />Sistemin gereksinimleri kimleri ilgilendiriyor?<br />Sistem organizasyonun hangi biriminde kullanılacak?<br />Sistemden kimler faydalanacak?<br />Sisteme veri sağlayacak, sistemden bilgi alacak ve sistem kayıtlarını değiştirecek olanlar kim?<br />Sistemin bakımını kim yapacak?<br />Sistemin hizmetlerinden yararlanacağı başka sistemler var mı?<br />Sistemin hizmetlerini sunacağı başka sistemler var mı?<br />Sistemin kullanımında birden fazla rolü oynayan kişiler var mı?<br />Sistemin kullanımında aynı rolü oynayan birden çok kişi var mı?<br />
  413. 413. Use Case Bulma Soruları<br />Aktörlerin yerine getirecekleri görevler nelerdir?<br />Aktörlerden herhangi birisi sistem kayıtlarını oluşturma, kaydetme, değiştirme, silme ve okuma amaçlı olarak kullanacak mı?<br />Hangi use case’ler yukarıdaki kaydetme, değiştirme, silme ve okuma işlemlerine yol açacak?<br />Herhangi bir aktörün sistemi sistem dışındaki ani değişikliklerden haberdar etmesi gerekli mi?<br />Herhangi bir aktörün sistem içinde olanlardan haberdar edilmesi gerekiyor mu?<br />Hangi use case’ler sistemin bakımı için kullanılacak?<br />Sistemin vereceği tüm hizmetler (fonksiyonel gereksinimler) bulunan use case’ler ile yansıtılabiliyor mu?<br />
  414. 414. Use Case ŞemasıEgzersiz # 1<br />Lütfen şemadan anladıklarınızı bir paragrafta özetleyiniz (10 dk.)<br />
  415. 415. Use Case ŞemasıEgzersiz # 2<br />Aşağıdaki tanıma uygun use case şemasını çiziniz (15 dk.).<br />“Sadece üyelerin bir satın alma yapabileceği bir cd satış portali oluşturmanızgerekmektedir. Bu portali ziyaret edenler üye olmadıkları takdirde portal kataloğuna erişemeyeceklerdir. <br />Üye olma işlemi sırasında başvuru yapanların:<br />isim ve soyadları,<br />e-mail adresleri<br />favori müzisyenleri (3 isim)<br />favori cd’leri (3 isim)<br />arayıp bulamadıkları cd’ler (3 isim)<br />bilgileri toplanacaktır. <br />Üyelerden ayrıca bir şifre tanımlamaları istenecek ve e-mail adresleri kullanıcı adları olarak kullanılacaktır. <br />Web sitesinde şirket kataloğuna bakarak cd satın alabilmenin dışında, üyeler birbirleri arasında cd değiş tokuşu yapabileceklerdir.<br />Sistem üyelerin hangi cd’leri alıp sattıklarına, hangi cd’leri arayıp bulamadıklarına bakarak, cd önerilerinde bulunacaktır.“<br />
  416. 416. Activity Şeması<br />Temel Kavramlar<br />Şema İçeriği<br />Şemayla Aktarılan Bilgiler<br />Tasarım Teknikleri<br />Forward ve Reverse Engineering<br />
  417. 417. Temel Kavramlar<br />Sistem akışı içinde önce ne sonra ne olduğunu koşullarını işaret ederek gösterebiliriz.<br />Use Case akışını çizebiliriz.<br />Sistem genelinin işleyişini çizebiliriz.<br />Bir hizmete yönelik işlemleri toplu halde inceleyebiliriz (UC Map).<br />Tek bir işlemin nasıl gerçekleştirildiğini inceleyebiliriz.<br />
  418. 418. İlgili Roller<br />Şemayı Hazırlayanlar:<br />İş Analisti<br />Sistem Analisti<br />Tasarımcı<br />Programcı<br />Şemayı Kullananlar:<br />Müşteri<br />Proje Yöneticisi<br />Tasarımcı<br />Programcı<br />Veri Tabanı Analisti<br />Kullanıcı Arayüzü Tasarımcısı<br />
  419. 419. Activity Şeması Sembolleri 1<br />
  420. 420. Activity Şeması Sembolleri 2<br />
  421. 421. Activity Şeması Sembolleri 3<br />
  422. 422. Activity Şeması Sembolleri 4<br />Sembol<br />Tanımı<br />Syntax<br /> Object<br />‘Elle tutulabilir’ nesnelerdir. <br />OrderItem<br />ObjectFlow<br /> Object’i girdi ve çıktı olarak faaliyet <br /> ve komutlara bağlamaya yarar. <br />
  423. 423. Şema Örnekleri 1<br />
  424. 424. Activity Şeması Örnekleri 2<br />
  425. 425. Activity Şeması Örnekleri 3<br />
  426. 426. Activity Şeması Örnekleri 4<br />
  427. 427. Activity ŞemasıEgzersiz<br />Aşağıdaki bilgileri alternatifleri ve beklenmeyen durumları da ekleyerek activity şemasıyla anlatınız (15 dk.)<br />Yemek Tarifi: Arap Usulü Ispanak<br />Soğanları kızgın yağda 5 dk. kavurunuz,<br />İsterseniz, sarmısak ve kimyon ekleyerek 1 dk. daha kızartınız.<br />Ispanakları tavaya yavaş yavaş ekleyiniz. Eklenen ıspanakların yapraklarını iyi yumuşayıncaya kadar karıştırınız. Taze ıspanak büyük ölçüde pişirilirken ufalacağından, ıspakların hepsi tavaya sığacaktır. <br />Daha önce yumuşamaları için gece boyunca suda beklettiğiniz nohutların suyunu süzünüz ve tavaya ekleyiniz.<br />Karışıma tereyağı ve baharat (tuz, biber ve kırmızı biber) ekleyiniz.<br />Karışım köpürmeye başlayana dek ısıtmaya devam ediniz.<br />Karışımı kendi suyu içinde hafif nemli olarak sununuz.<br />
  428. 428. Statechart Şeması<br />Temel Kavramlar<br />Şema İçeriği<br />Şemayla Aktarılan Bilgiler<br />Tasarım Teknikleri<br />Forward ve Reverse Engineering<br />
  429. 429. Temel Kavramlar 1<br />
  430. 430. Temel Kavramlar 2<br />
  431. 431. Temel Kavramlar 3<br />Action ve Output:<br />
  432. 432. Temel Kavramlar 4<br />Event ve State Machine örtüşmesi:<br />
  433. 433. Temel Kavramlar 5<br />Bir faaliyet sona erene ve state geçerliliğini yitirene dek eş zamanlı<br />olarak sürekli çalışır: <br />
  434. 434. Temel Kavramlar 6<br />Duruma (guard condition) göre çalıştırılan komutlar:<br />
  435. 435. Temel Kavramlar 7<br />Hiyerarşik State Machine’ler:<br />
  436. 436. İlgili Roller<br />Şemayı Hazırlayanlar:<br />Sistem Analisti<br />Tasarımcı<br />Programcı<br />Şemayı Kullananlar:<br />Sistem Analisti<br />Tasarımcı<br />Programcı<br />
  437. 437. State Machine ŞemasıEgzersizi<br />Kredi Kartı borcunu zamanında ödemeyenlere tutarın % 5.5’i oranında ceza verilmektedir. Borcunu son ödeme tarihinden bir ay sonra hala ödemeyenlerin kartlarına el konulmaktadır. Diğer durumlarda kart kullanımı normal şekliyle sürmektedir.<br />Kredi Kartı aylık ödeme tutarı 1,000 YTL ve üzerinde olanların kart limitleri iki katına çıkarılmaktadır. 1000 YTL ve üzeri ödeme yapanlara toplam harcamalarının % 2’si oranında hediye çeki gönderilmektedir. <br />
  438. 438. İçerik<br />UML Modeli Kavramları<br />UML Tanımını Genişletme Mekanizmaları<br />Davranış Şemaları<br />Yapısal Şemalar<br />
  439. 439. UML 2.0 Şemaları<br />
  440. 440. Yapısal Şemalar<br />class şeması*<br />package şeması*<br />composite structure şeması<br />object şeması<br />component şeması<br />deployment şeması<br />
  441. 441. Class Şeması<br />Temel Kavramlar<br />Şema İçeriği<br />Şemayla Aktarılan Bilgiler<br />Tasarım Teknikleri<br />Forward ve Reverse Engineering<br />
  442. 442. Temel Kavramlar<br />Class kendisinden üretilecek nesneler için ortak değişken ve metodları içeren bir şablondur.<br />Bu şablondan üretilecek her nesne sadece şablonunda belirtilen değişken tipine uygun veri yapılarını taşıyabilir.<br />Her nesne şablonunda tanımlanmış metodlar aracılığıyla kullanılabilir.<br />
  443. 443. Temel Kavramlar<br />Değişkinler:<br />Bir tip – değer ikilisidir.<br />Class’lar değişken tipini belirler.<br />Nesneler değişken değerini belirler.<br />Değişkenler bir ilkel veri veya bir class tipinde olabilirler.<br />İlkel veri tipi kullanılan yazılım ortamına bağlı olarak değişen integer veya string gibi mevcut veri tipleridir.<br />
  444. 444. Temel Kavramlar<br />Metodlar:<br />Class’ın tüm nesnelerinin canlandırabileceği davranışlardır.<br />Metodlar önce birer sorumluluk olarak ortaya çıkıp daha sonra fonksiyonlara dönüşürler.<br />Fonksiyona dönüştüklerinde parametreleri ve return tipleri tanımlanmış olmalıdır.<br />
  445. 445. Temel Kavramlar<br />Değişkinler ‘private’<br />Metodlar ‘public’<br />Hepsi küçük harfle başlar ve kelimeler bitişik yazılır.<br />
  446. 446. Temel Kavramlar<br />Her eleman bulunduğu yere erişim haklarını ifade eden bir görünürlüğe sahiptir (visibility).<br />‘public’ elemanlar Class dışından görülebilir ve erişilebilirler. Sembolleri: ‘+’<br />‘protected’ elemanlar sadece Class’la generalization ilişkisine sahip Class’larca görülebilir ve erişilebilirler. Sembolleri: ‘#’<br />‘private’ elemanlar ait olduğu Class dışında görülemez ve erişilemezler. Sembolleri: ‘-’<br />
  447. 447. Temel Kavramlar<br />Encapsulation:<br />Değişkenlerin ‘private’ olma nedenidir.<br />
  448. 448. Temel Kavramlar<br />Generalization:<br />Farklı ‘abstraction’ seviyeleri arasında ırsiyet ilişkileri kurmak için kullanılır.<br />
  449. 449. Temel Kavramlar<br />Polymorphism: implementasyonun detaylarını gizleyerek kolay kullanımı sağlar.<br />Aynı isme sahip fakat farklı çalışan fonksiyonları ifade eder.<br />
  450. 450. Temel Kavramlar<br />Inheritance: oluşmuş class’ların özelliklerinin kademeli olarak zenginleştirilebilmesine olanak verir. <br />Class’ları özel durumlara istinaden ayırarak farklı ‘abstraction’ seviyeleri oluşturulmasını sağlar.<br />Böylece katmanlı bir sistem mimarisine imkan vererek tekrar kullanımı kolaylaştırır.<br />
  451. 451. Temel Kavramlar<br />Abstract Class:<br />Kendisinden nesne üretilmeyen, hiyerarşik yapının en üstünde yer alan ve kendinden özelleştirilmiş class’lar vasıtasıyla değişkenlerini sistemin kullanımına sunan class’lardır.<br />
  452. 452. Class Şeması Sembolleri 1<br />
  453. 453. Class Şeması Sembolleri 2<br />
  454. 454. İlgili Roller<br />Şemayı Hazırlayanlar:<br />Tasarımcı<br />Programcı<br />Şemayı Kullananlar:<br />Tasarımcı<br />Programcı<br />
  455. 455. Class Şeması Örneği<br />
  456. 456. Class ŞemasıEgzersiz # 1<br />
  457. 457. Class ŞemasıEgzersiz # 2<br />“Dinozorlar Paleozoik, Mesozoik ve Senozoik zaman dilimlerinde görülmüşlerdir. Paleozoik’in sonlarına doğru memelileri andıran ilginç bir örnek Dimetrodon’dur. Dimetrodon’un sırtında yelken gibi büyük bir çıkıntı vardı. Dimetrodon yürürken dört ayağını birden kullanıyordu ve etçildi.<br />Uçan dinozorlara (Pterosor) örnek olarak Pteranodon’u verebiliriz. Diğerlerinin aksine Pteranodon’un kuyruğu yoktu ve çok geniş kanatları vardı (8 m.). Yine ilginç bir özelliği diğerlerinin aksine dişlerinin olmamasıydı. Uçan dinozorlar etçillerdi.<br />Etçil dinozorların en ünlüsü Tiranosorus’dur. Etçil dinazorların en önemli özelliklerinden birisi genellikle ön ayaklarının çok küçük ve kullanışsız olmasıdır. Bu tür etçil dinozorlar arka ayakları üzerinde yürür ve ön ayaklarını hareket amacıyla kullanmazlar.<br />Otçul dinozorların en uzunları Diplodokus ve Brontosorus etçil dinazorların aksine dört dev ayağa sahiptiler ve hepsini kullanarak gayet hızlı yürüyebildikleri düşünülmektedir. ”<br />
  458. 458. Package (Paket) Şeması<br />Temel Kavramlar<br />Şema İçeriği<br />Şemayla Aktarılan Bilgiler<br />Tasarım Teknikleri<br />Forward ve Reverse Engineering<br />
  459. 459. Temel Kavramlar<br />Paket, Subsystem ve Model <br />Model içindeki elemanları belli bir referansa göre gruplamaya yararlar. <br />Her grubun elemanları arasında farklı bir semantik ilişki vardır. Farklı bir nedenden dolayı bir araya gelmişlerdir.<br />Subsystem (Modül) ve Model aslında birer pakettir.<br />
  460. 460. Temel Kavramlar<br />Paket UML modeli elemanlarından oluşan bir gruptur.<br />
  461. 461. Paket Şeması Sembolleri<br />
  462. 462. İlgili Roller<br />Şemayı Hazırlayanlar:<br />Herkes<br />Şemayı Kullananlar:<br />Herkes<br />
  463. 463. Paket Şeması Örnekleri<br />Müşteri<br />Sipariş<br />Yer<br />CD<br />Sipariş<br />Stok<br />Satış<br />Depo<br />
  464. 464. Şema Eksiksizliği Kontrolleri 1<br />UML Şeması hazırlamak serbest resim çalışmasına dönüşmemelidir.<br />Şemanın hazırlanma amacı asla mevcudiyeti olmamalıdır.<br />Şemayı hazırlayan ya düşünüyordur, ya sistemi geliştiriyordur, ya birisine doküman hazırlıyordur ya da bir sistemin yapısını inceliyordur.<br />Şemaların belli hazırlayıcıları ve kullanıcıları vardır.<br />
  465. 465. Şema Eksiksizliği Kontrolleri 2<br />Bir UML şeması çizmeye karar verdiğimizde belli bir amacımız ve açıkça ifade edilebilen sorularımız olmalıdır.<br />Sorularımız yanıt bulduğunda eğer şirketimiz içinde gereken dokümantasyon seviyesine de uyuyorsak çizim çalışması biter.<br />Her şemanın aynı konuda olsalar bile farklı yararlılık dereceleri vardır. Bazı şemalar zamana karşı koyar bazılarıysa giderek gözden düşer.<br />
  466. 466. Analistler için Modelleme<br />Bölüm 5 / 6<br />
  467. 467. İçerik<br />
  468. 468. İçerik<br />Modüllerin Yapısı<br />Modül Tanımlama Teknikleri<br />Modül Gerçekleştirme Teknikleri<br />Modellerin Yapısı<br />Modellerin İlişkileri<br />
  469. 469. Modül (Subsystem) Özellikleri<br />Bir modülün iki özelliği vardır:<br />Dış görünümü: modülün sağladığı hizmetleri gösterir. <br />İç görünümü: modülün verdiği hizmetleri destekleyen altyapıyı gösterir. <br />Bu iki görünüm arasında bire bir bir ilişki vardır.<br />
  470. 470. Modül Özellikleri<br />Tanım elemanları<br />Gerçekleştirme elemanları<br />Bir modül bir sistemin hem tanımlanma hem de gerçekleştirilme aşaması çalışmalarını içerir.<br />
  471. 471. Modülün Gerçekleştirilmesi<br />Tanım elemanları<br />Gerçekleştirme elemanları<br />?<br />Gerçekleştirme elemanları subsytem’in içeriğini gösterir. <br />Modül gerçekleştirilmesi genellikle class’lar ve ilişkilerini içerir.<br />
  472. 472. Modül Tanımlanması<br />Tanım elemanları<br />Gerçekleştirme elemanları<br />?<br />Modül tanımı modülün dışarıdan nasıl görüldüğü belirtir<br />
  473. 473. İçerik<br />Modüllerin Yapısı<br />Modül Tanımlama Teknikleri<br />Modül Gerçekleştirme Teknikleri<br />Modellerin Yapısı<br />Modellerin İlişkileri<br />
  474. 474. Modül Tanımlanması<br />Modül tanımı<br />Modülün verdiği hizmetleri tanımlar<br />Sistemin kullanıcılarına yaşatacağı deneyimi tanımlar <br />Modülün iç yapısını gözler önüne dökmez <br />Modülün interface’lerini tanımlar<br />
  475. 475. Tanımlama Teknikleri<br />Use Case yaklaşımı<br />State Machine yaklaşımı<br />Mantıksal Class yaklaşımı<br />Metod Yaklaşımı<br />… ve bunların kombinasyonları <br />
  476. 476. Gerçekleştirme elemanları<br />Tanım elemanları<br />Modülü sunduğu hizmetlerle alakalandırabilmek için<br />Spesifikasyonun teknik olmayan insanlara aktarılabilmesi için<br />1. Use Case Yaklaşımı<br />
  477. 477. 1. Use Case Yaklaşımı<br />Realization elements<br />Change Digit Analysis Information<br />Operator<br />Initiate Call<br />Trunk<br />Receive Digit and Connect<br />Hook Signal and Disconnect<br />Subscription<br />Çağrı Kontrol<br />Tanım elamanları<br />
  478. 478. Stopped<br />Running<br />Maintenance<br />Exhausted<br />Error<br />2. State Machine Yaklaşımı<br />Çağrı Kontrol<br />Tanım elemanları<br />Duruma göre davranışı değişen modüller için (Simülasyon vs.)<br />Modülün yaşadığı durumlar ve bu durumlar arasındaki geçişlere odaklanır<br />
  479. 479. Number Dictionary<br />Analyzer<br />Network Manager<br />3. Mantıksal Class Yaklaşımı<br />Çağrı Kontrol<br />Tanım elemanları<br />Modülün kullanımı nesnelerin manipülasyonu olarak görülüyorsa<br />Gereksinimler belli bir standarda uyum zorunluluğundan kaynaklanıyorsa<br />
  480. 480. initiateConnection (…)<br />dialledDigit (…)<br />throughConnect (…)<br />bAnswer (…)<br />bOnHook (…)<br />aOnHook (…)<br />4. Metod Yaklaşımı<br />Çağrı Kontrol<br />Metodlar<br />Basit (atomic) hizmetler veren modüller için<br />Metodlar birbirlerinden bağımsız olarak çağrılıyorlarsa<br />
  481. 481. Tekniklerin Kombinasyonları<br />Initiate Call<br />Trunk<br />Receive Digit and Connect<br />Hook Signal and Disconnect<br />Subscription<br />Çağrı Kontrol<br />Specification elements<br />Metodlar<br />changeDigitAnalysisInformation (...)<br />Tanım elemanları<br />
  482. 482. Operations<br />Gerçekleştirme elemanları<br />Metodlar<br />Tanım elemanları<br />Eksiksiz Modül Notasyonu<br />Üç tanımlı parçadan oluşur<br />Bu parçalar isteğe bağlı olarak kullanılmayabilir <br />
  483. 483. İçerik<br />Modüllerin Yapısı<br />Modül Tanımlama Teknikleri<br />Modül Gerçekleştirme Teknikleri<br />Modellerin Yapısı<br />Modellerin İlişkileri<br />
  484. 484. Tanım (Specification) – Gerçekleştirme (Realization)<br />Tanım ve gerçekleştirme birbirleriyle uyumlu olmalıdır <br />Tanım ile gerçekleştirme arasındaki ilişki (mapping) şu şekilde ifade edilebilir:<br /> gerçekleştirme (realization) ilişkisi<br /> birliktelik (collaboration)<br />
  485. 485. «realize»<br />Metodlar<br />Gerçekleştirme elemanları<br />operation1( ) : Type1<br />operation1( )<br />operation2( ) : Type2<br />operation3( ) : Type3<br />operation4( ) : Type4<br />operation5( ) : Type5<br />Gerçekleştirme İlişkisi<br />Gerçekleştirme (Realization) özellikle tek seviyeli ilişkileri göstermekte faydalı<br />
  486. 486. Gerçekleştirme İlişkisi<br />«realize»<br />Trafik Kontrol<br />Gerçekleştirme elemanları<br />Metodlar<br />changeDigitAnalysisInformation ( )<br />Tanım elemanları<br />Initiate Call<br />changeDigitAnalysisInformation ( )<br />:<br />:<br />Trunk<br />Receive Digit and Connect<br />Hook Signal and Disconnect<br />Subscription<br />
  487. 487. Collaboration<br />Collaboration (Birliktelik): Belli bir hedefe yönelik olarak nesne etkileşimlerinin resmedilmesidir. Bu bir UC senaryosu veya class ilişkileri incelemesi olabilir.<br />Interaction (Etkileşim):Bir birliktelik içindeki nesnelerin arasındaki haberleşmelerdir. <br />
  488. 488. Collaboration<br />Sequence Şeması<br />Collaboration Şeması<br />2: dialledDigit<br /> :Trunk<br /> :Subscription<br /> :Traffic Control<br /> :Traffic Control<br />markBusy<br />dialledDigit<br />4: throughConnect<br />dialledDigit<br /> :Trunk<br />throughConnect<br />markBusy<br /> :Subscription<br />bAnswer<br />1: markBusy<br />Bir ‘collaboration’ bir iş yerine getirilirken gereken rolleri tanımlar<br />Bu roller birbirleriyle etkileşen nesneler aracılığıyla canlandırılır <br />3: dialledDigit<br />6: bAnswer<br />5: markBusy<br />
  489. 489. Collaboration Sembolleri<br />
  490. 490. Collaboration Notasyonu<br />Collaboration<br />Rol adı<br />Rol adı<br />Rol<br />Rol adı<br />Rol adı<br />Class<br />Bir birliktelik (collaboration) ve katılımcıları <br />
  491. 491. Tanım elemanları<br />Gerçekleştirme elemanları<br />Initiate Call<br />Network<br />Interface<br />Receive Digit and Connect<br />Coordinator<br />Analysis<br />Database<br />Hook Signal and Disconnect<br />Collaboration<br />Collaboration genellikle daha karmaşık durumlarda faydalıdır<br />
  492. 492. Collaboration Çeşitleri<br />Rol modeli bir özel durumu ifade ederken Class modeli daha<br />genele yönelik. Dolayısıyla her Class modeline karşılık birden<br />fazla Rol modeli olacaktır.<br />
  493. 493. Use Case Realization<br />Collaboration Şeması: “Sipariş Alınması”<br />
  494. 494. Use Case Realization (UCR) <br />
  495. 495. Use Case Realization (UCR)<br />
  496. 496. Use Case Realization (UCR) <br />
  497. 497. Use Case Realization (UCR)<br />
  498. 498. Model Bağımlılıkları<br />Üniversite Kayıt Sistemi<br />
  499. 499. Modüller Ne Zaman Gerekli?<br />Büyük bir sistemin hangi parçalardan oluştuğunu ve bu parçaların bağımlılıklarını göstermek gerektiğinde (Sistem Mimarisi)<br />Dağıtık (distributed) yazılım geliştirme yapılıyorsa <br />Bir grup modülün nasıl büyük bir sisteme dönüştürülebileceğini gözlemleyebilmek için (Sistem Mimarisi)<br />Bileşen bazlı yazılım geliştirme yapabilmek için <br />
  500. 500. Modül Oluşturma Teknikleri<br />Büyük bir sistemin her kendine haslık gösteren parçasını bir modülle ifade edin<br />Tanımlama (specification) tekniğini sistem ve modülün özelliklerine göre belirleyin<br />Her modülü ayrı ayrı ve tanımlama elemanlarını (gereksinim) kullanarak gerçekleştirin (realize)<br />
  501. 501. İçerik<br />Modüllerin Yapısı<br />Modül Tanımlama Teknikleri<br />Modül Gerçekleştirme Teknikleri<br />Modellerin Yapısı<br />Modellerin İlişkileri<br />
  502. 502. Model<br />Bir model sisteme belli nedenden dolayı farklı bir bakış şeklidir. Oluşturulma amacına uygun şekilde dokümantasyona ve detay seviyesine sahiptir. <br />
  503. 503. Model<br />Use Case Modeli<br />Tasarım Modeli<br />
  504. 504. Model Sembolleri<br />Sistemi belli muhataplara onlara özel detay seviyesiyle sistemin ilgili yönlerinin gösterilmesidir.<br />İsim<br />Modeller arasındaki bağımlılık aynı konuların farklı bakış açıları altındaki ürünlerini temsil eder.<br />İşaret tek veya çift yönlü olabilir.<br />«trace»<br />Sembol<br />Tanım<br />Syntax<br />Model<br />Trace<br />
  505. 505. Trace<br />Analiz<br />Tasarım<br />«trace»<br />
  506. 506. Model / Şema<br />Şemalar modeli dokümante eder<br />Use Case Modeli<br />Tasarım Modeli<br />
  507. 507. Model Ne Zaman Gerekli?<br />Farklı paydaşlara sisteme kendi ihtiyaçlarına göre bakabilmelerini sağlamak için <br />Sistemi gerektiğinde sadece tek bir yönden inceleyebilmek <br />Yazılım geliştirme sürecinde farklı aşamalarda üretilenleri dokümante edebilmek <br />
  508. 508. Model Oluşturma Teknikleri<br />Her modelin amacını tanımlayınız <br />Her model amacına uygun şekilde sistemin eksiksiz bir resmini çizmelidir <br

×