005 Alternatif Yazilim Surecleri [99 Slides]
•Download as PPT, PDF•
2 likes•1,860 views
Unified Process ve UML ile Yazılım Geliştirme - 5 - Alternatif Yazılım Geliştirme Süreçleri
Recommended
More Related Content
What's hot
What's hot (19)
Similar to 005 Alternatif Yazilim Surecleri [99 Slides]
Similar to 005 Alternatif Yazilim Surecleri [99 Slides] (20)
005 Alternatif Yazilim Surecleri [99 Slides]
- 1. UML/UP ile Yazılım Geliştirme Bölüm 5/7
- 2. İçerik • UML’in Sizin için Anlamı • UML Şemaları, Semboller ve Semantik İlişkileri • Şema ve Model Bazlı UML Çalışmaları Arasındaki Farklar • Alternatif Yazılım Geliştirme Süreçlerinde UML'in Yeri • UML ile Gereksinim Yönetimi • UML ile Nesne Yönelimli Tasarım
- 3. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 4. Süreç Nedir? • Kimin Neyi Ne Zaman Nasıl yapacağını tanımlamaktır. Değişen Yeni Süreç gereksinimler sistem
- 5. Yazılım Süreci Aşamaları 1. Gereksinim Yönetimi (Ne?) Ürünün yerine getirmesi gerekenler 2. Analiz (Nasıl?) Sistemin parçalarının ve birbirleriyle alakalarının kavramsal seviyede belirlenmesi 3. Tasarım (Nasıl?) Sistemin parçalarının ve birbirleriyle alakalarının bir teknolojiye has olarak (J2EE, C+ +) belirlenmesi 4. İmplementasyon (Kodlamak) Sistemin kaynak kodunun geliştirilmesi 5. Test (Verifikasyon: Fonksiyonel Test) Test verileriyle uygulamayı çalıştırmak 6. Bakım (Hata Düzeltme ve Geliştirme) Ürünün hatalarını giderme ve yeni özellikler ekleme
- 6. Süreç Örneği: Bireysel Finans 1. Gereksinim Yönetimi: Uygulama kullanıcının bakiyesini göstermelidir. 2. Analiz ve Tasarım: Tasarım VadesizHesap ve VadeliHesap class’larına sahip olmalıdır. 3. İmplementasyon: class VadesizHesap{ double bakiye; getBakiye{}; setBakiye{}} … 4. Test: yatırılan $44.92 / yatırılan $32.00 / çekilen $101.45 / … bakiye $2938.22, testi geçti. 5. Bakım: Hata düzeltme: Bakiye sıfır olunca ve para çekme işlemi yapılmak istenince sistem göçüyor. Ek Özellik Geliştirme: Euro para birimini destekleme.
- 7. Waterfall Yazılım Süreci Milestone(s) Ürünün sürümleri Gereksinim Bu fazlar kısa bir süre Analizi için örtüşebilir Tasarım İmplementasyon Fazlar Test Bakım zaman
- 8. Waterfall Neden Pratik Değildir? 1. Sahip olunması istenen bilgilerin hepsi hazır değildir Bütün detayları işin başında görmek zordur 2. Gereksinimlerin implementasyon maliyetlerini sadece tahmin edebiliriz Tahminin isabetliliğini anlamak için en riskli olanlarının tasarlanıp, implemente edilmeleri gerekir Buradan alınan sonuçlara göre gereksinimler değişebilir 3. Sık sık ara sürümler çıkarmak zorunda kalırız Paydaşların (müşteriler, yöneticiler) projeye güvenlerini tazelemek gerekir 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) 4. Tipik olarak yazılım ekibinin elemanları farklı fazlarda da görev alırlar
- 9. Spiral Süreç
- 10. Spiral Süreç M I L E S T O N E S zaman α β (prototype) X X sürüm 1.0 İterasyon # 1 2 3 Gereksinim 1 2 3 Tasarım 1 2 3 Kodlama 1 2 3 Test 1 2 3
- 11. Örtüşen Süreç Aşamaları: UP
- 12. RUP’un Gelişimi Rational Unified Process 5.0 1998 İşlevsellik Testi Performans Testi Gereksinim Denet. Değişiklik Denet. İş Akışı Rational Objectory Process 4.1 Veri Tabanı 1996-1997 UI Rational Yaklaşımı UML Objectory Process 1.0-3.8 1987-1995 Ericsson Yaklaşımı
- 13. Süreç Seçim Yaklaşımı Olarak MPP • Method over Tool: “Herhangi bir yazılım mühendisliği ürününden ziyade yönteme odaklanmak” • Project over Method: “Herhangi bir yazılım sürecinden ziyade projeye/ürüne odaklanmak” • People over All: “Herşeyden çok ürünün kullanıcıları ve onu geliştirenler dahil olmak üzere paydaşlara odaklanmak”
- 14. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 15. Proje Gelişim Süreci Inception Elaboration Construction Transition saptama tasarlama oluşturma sunma Gereksinim Sistem Kullanılabilirlik Resmi Kontrolü Mimarisi Sürüm zaman •Inception: Projenin sınırlarının belirlenmesi, Verilecek hizmetin berraklaştırılması •Elaboration: Proje planının oluşturulması, ürün özelliklerinin saptanması, Baseline •Construction: Ürünün oluşturulması •Transition: Kullanıma sunulma
- 16. Aşamalar ve İterasyonlar Inception Elaboration Construction Transition Prelim ... Arch ... Dev Dev ... Trans ... Iteration Iteration Iteration Iteration Iteration Release Release Release Release Release Release Release Release 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.
- 17. İterasyonlar ve İşler Aşamalar İşler Inception Elaboration Construction Transition Gereksinim Analiz Tasarım Uygulanma Test P r e lim in a ry ite r. ite r. ite r. ite r. ite r. ite r. ite r. Ite ra tio n (s ) #1 #2 #n #n+1 # n +2 #m #m +1 İterasyon
- 18. İterasyonlar ve Risk Proje risklerinin ortaya •Mimarinin revizyonu konması •Risk-bazlı iterasyonlar •Entegrasyon Inception Waterfall Elaboration •Kullanıma sunma •Müşteri memnuniyetini ölçme Construction •Senaryolarla sistemin yapısının ve davranışının oluşturulması Transition •Sistem Mimarisinin oluşması •Temel mekanizmaların tasarlanması Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Post- Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration deployment
- 19. Risk Azaltma Odaklı İterasyonlar İterasyon N’in Planı En önemli risklere • Maliyet yönelik senaryoların • Zamanlama İlk Proje Riskleri oluşturulması İlk Proje Odağı Iteration N’in oluşması • Maliyet ve Kalite ölçümleri Iterasyon N Iteration N’in değerlendirilmesi Yenilenen Proje Planı • Maliyet • Zamanlama • Odak/İçerik Giderilen Riskler Diğer Riskler • Yeni öncelikler
- 20. Use Case Odaklı İterasyonlar Inception Elaboration Construction Transition İterasyon1 İterasyon2 İterasyon3 “Mini-Waterfall” Süreci İterasyon Planı Gereksinimler Analiz + Tasarım Uygulama Test Release
- 21. İterasyon Süreci • Önceki iterasyonların sonuçları • Güncel Risk Raporu • Model, kod ve test kayıtları İterasyon Planı Gereksinimlerin Sapt. Analiz + Tasarım Uygulama Test Release Release raporu Yeni Risk Raporu Konfigürasyon Denet.
- 22. Adapte Olabilen bir Süreç: UP Rational Stratejik Hizmetler Biriminde baş danışman. Uzmanlık alanları: • Yazılım Mühendisliği Süreçleri • Sistem Mühendisliği Süreçleri • Yazılım Proje Yönetimi • Liderlik Murray Cantor Software Leadership: A Guide to Successful Software Development Slaytlar 20 - 28
- 23. Eski Müşteri/Yazılım Ekibi İlişkisi • Gereksinimleri ‘bitir’ kaynak değerlendirmesi yap proje planı yaz taahhüt ver planı uygula proje başarısızlığını gör suçluyu ara sonunda kabul edilebilecek bir çözüm sun (belki) • Varsayımlar – Gereksinimlerin, proje içeriğinin, kullanılacak teknolojinin eksiksiz ve gereken detay seviyesinde anlaşıldığını ... – Çok isabetli tahminlerde bulunmanın mümkün olduğunu ... – Detaylı bir planın yapılabileceği ve uygulanabileceği ...
- 24. ‘Waterfall’ Yaklaşımının Sonuçları Sözde Sonuçlar Gerçek Sonuçlar Detaylı toplantılar yapılıyor /Toplantı ⇒ Toplantılar ve dokümanlar notları yazılıyor karmaşık bir yazılım sisteminin gerçek risklerinin çok azına değiniyor. ⇒ Elle tutulur bir delil yok. Tasarım uygun gözüküyor. ⇒ Yanıltıcı bir güvenlik hissi var. Detaylı bir spesifikasyon hazırlanıyor. Gereksinim kapsama yüzdesi ⇒ Pek azı n*(% 10) tasarımı (% 100) yüksek. yönlendiriyor. ⇒ Gereksinimlerin hepsine nüfuz • Tasarım “suçu ispatlanana kadar etme çabası kritik noktaları gözden kaçırıyor. masum.” ⇒ Her zaman suçlu. Tasarım hatası ileride istemediğimiz bir zamanda ortaya çıkacak.
- 25. Pareto Kanunu %20’lik emek faydanın %80’ini sağlar. 80% Fayda 20% Emek
- 26. Hata Payını En Aza İndirmek Çok Emek İster • Gereksinimler karmaşıktır – Fonksiyon/Davranış – Sistem tarafı ayrıca karmaşıktır. • Tam anlamıyla anlamak analiz, deneyler ve neticelerin değerlendirilmesiyle mümkündür. • Gereksinimlerle Sistem Mimarisinin ilişkilerinin belirlenmesi gerekir. • Tüm bu emek bahsettiğimiz 80/20 kuralına tabiidir. – Eksiksiz bir bilgiye erişim en iyimser yaklaşımla ekonomik değildir. Gerçekçi olursak mümkün değildir. – Bilgi proje süresince eksiksizleşir.
- 27. Paradoks Yapılacak işi yönetebilmek içim yazılım taahhütlerinin olması gerekli Taahhütlerin çok detaylı bir şekilde tarif edilmeleri mümkün değil Çözüm: – Açık bir şekilde ortaklaşa çalışma, müşteriye sonuç göstererek yönetim ve programcı arasında ahenk oluşturarak çalışmak – İteratif yazılım geliştirme – Elde edilen bilgilerin kademeli olarak zaman içerisinde eksiksizleşmesi ve detay seviyelerinin artması.
- 28. Yazılım Problemi: İki nokta arasındaki en kısa yol Buradan Buraya Nasıl gideceğiz? Düşündüğümüz Güzergah Projenin ilk Durumu Müşteriyi Tatmin Edebilecek Alan Mevcut ‘malzemeler’, teknolojiler Katmadeğer: Kullanıcıya (kullanılabilirlik, performans, kalite) Elemanlar, kabiliyetleri, bilgileri Maliyet (zaman ve para) Kaynak eksiklikleri Katmadeğer: Yazılım Geliştirici (kar, deneyim, Belirsizlikler satış, Pazar payı vs.)
- 29. İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi Müşteriyi Tatmin Edebilecek Alandaki Belirsizlik Planlanan Güzergah Gerçek Güzergah Projenin ilk Durumu Planlanan İçerik
- 30. ‘Waterfall’ Yönetimi: “Planla ve Takip Et” Planla ve Takip Et: Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor. Planlanan Proje Bitişi Planlanan Güzergah Gerçek Güzergah Müşteriyi Tatmin Projenin ilk Durumu Edebilecek Alan Gerçek Proje Bitişi
- 31. İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol” Devamlı olarak : Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendir Manevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız? Planlanan Proje Gerçek Proje Bitişi Bitişi Planlanan Güzergah Gerçek Güzergah Müşteriyi Tatmin Projenin ilk Durumu Edebilecek Alan
- 32. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 33. UP’in 3 Temel Parçası Bir iş Bir rol Activity (Faaliyet) Role (Çalışan) Use Case’leri tanımla Analist sorumluluğu Artifact (Oluşanlar) Sürecin oluşturduğu, kullandığı veya değiştirdiği bir ürün Use case Use case paketi
- 34. Role • Analistler: İş Analisti, Sistem Analisti, vs. • Yazılım Geliştirenler: Tasarımcı, Programcı, Kullanıcı Arayüzü Tasarımcısı, vs. • Yöneticiler: Proje Yöneticisi, Süreç Uzmanı, vs. • Diğer: Konu Uzmanları, Denetçiler (Reviewer), vs.
- 35. Activity
- 36. Artifact
- 38. Discipline ve Workflow Disiplin: Gereksinim Yönetimi Workflow: Gereksinim Yönetimine ait çalışma şekli detayları
- 39. Workflow Details
- 40. Daha Fazla Detay “Rol Üzerinden”
- 41. Daha Fazla Detay “Yapılacak İş Üzerinden”
- 42. Daha Fazla Detay “Üretilenler Üzerinden”
- 43. Daha Fazla Detay “Bir Adım Daha İleriye: Şablonlar”
- 44. İş Akışları Modelleri Oluşturur
- 45. “Ürünler ve Kullanım Teknikleri”
- 46. Özetlersek
- 47. Sorulamayan Soruyu Bulmak “Sorulamayan soruyu bulmak gerçekle hayali birbirinden ayırmamızı sağlar.” John M. Berry (A.B.D.’li Filozof) • UP diğer süreç tanımları gibi ‘geleneksel bir model’ değildir. – Varsayımları (Neden’i) açık ve belli. – Çalışma şekillerinin girdisi, çıktısı, kimlerin ne işine yaradığı ve kimler tarafından oluşturuldukları belli. • Yapılacakları dikte etmez: Ne’nin yanında Nasıl’da vardır. • Ne’lerin neler olacağına UP’un kullanıcısı karar verebilir. • Ne mevcut değilse onu ekleyebilir: UP plug-in’leri. • 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. • UP’u çok ciddi bir hedef olan CMM-I için de daha çok programcı odaklı Extreme Programming için de kullanabiliriz.
- 48. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 49. SPEM “Software Process Engineering Metamodel” • UML gibi OMG tarafından onaylanmaktadır. Açık bir standarttır. • Bitmiş bir standart değildir. Ufak değişmeler (gelişmeler) söz konusu olacaktır. • Tamamıyla Unified Process üzerine oturur. • Biz, örneklerimizde, kabaca kullanacağız.
- 50. SPEM Gösterimi “Disiplinler” X X X
- 51. SPEM Gösterimi “Roller”
- 52. SPEM Gösterimi “Yapılanlar”
- 54. SPEM Gösterimi “Roller, Yapılanlar ve Üretilenler”
- 55. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 56. Süreç Haritası
- 57. Süreç Haritası “Çevik Süreç Tanımları”
- 58. Süreç Haritası “CMMI”
- 60. UP Uyarlamaları
- 61. Gereksinim Yönetimi “Standart UP”
- 62. Analiz ve Tasarım “Standart UP”
- 63. İmplementasyon “Standart UP”
- 64. Bizim UP Sürecine Yaklaşımız
- 65. Proje Süresince Roller • Bir kişi birden fazla rolü canlandırabilir. • Aynı kişinin canlandırdığı rollerin çıkarları bir çelişki oluşturmamalıdır. • Bütçe ve Eleman sayımızı gözeterek ve en verimli süreç tanımını hedefleyerek, • Aşağıdaki gibi bir kadroyla yola çıkarsak, – Ahmet Bey: Birincil görevi Sistem Analizi – Leyla Hanım: Birincil görevi Tasarım – Mehmet Bey: Birincil görevi Veritabanı Tasarımı – Hülya Hanım: Birincil görevi Proje Yönetimi
- 66. 1. Gereksinimler
- 67. 2. Analiz ve Tasarım
- 69. 4. Test
- 70. Proje Yönetimi
- 72. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 75. Ahmet = Sistem Analisti
- 76. Ahmet = UI Tasarımcısı
- 77. Ahmet = Testçi
- 78. Leyla = Sistem Mimarı
- 81. Mehmet = Veritabanı Tasarımcısı
- 82. Hülya = Proje Yöneticisi
- 83. Hülya = Süreç Uzmanı
- 84. İçerik • Yaygın Yazılım Süreçleri • İteratif Yazılım Geliştirme • Unified Process (UP) Yapısı • SPEM Gösterimi ile Yazılım Süreci Tanımlama • Pratik bir UP Yaklaşımı • Yazılım Rolleri ve Kaynak Yönetimi • Proje Hazırlık Çalışmaları
- 85. Proje Hazırlık Çalışmaları “Tanımlamalar” • Paydaş Türleri • Gereksinim Türleri • Gereksinim Değişkenleri • Kısıtlama Türleri • Risk Türleri • Metrik Türleri • Emek Türleri • Bakım Türleri • Test Türleri • UML Standardına Ekleriniz, vs. vs.
- 87. 1b. Paydaşlar “Proje Ekibi Adayları”
- 91. 2c. Gereksinim Değişkenleri Örnek: “Statü”
- 93. 4. Risk Türleri
- 95. 6. Emek Türleri
- 97. 8. Test
- 98. 9. UML Kapsamına Ekler “Size Özel Stereotype”
- 99. İlham Kaynakları Philippe Kruchten James Bach Watts Humphrey Murray Cantor Terry Quatrani James Rumbaugh Grady Booch Ivar Jacobson
Editor's Notes
- Süreç en basit tanımıyla kimin neyi ne zaman ve nasıl yapacağının tanımlanmasıdır. Bunun biraz ötesine geçtiğimizde ise tanımlı kimlikler (roller), bir iş yapma sırası ve iş ilişkileri tanımı, yapılması istenen işlerin yapılış adımlarının ve bu işler sırasında (sonunda) üretilecek öğelerin tanımlarını (ve şablonlarını) oluşturmamız gerekir. Diğer bir süreç tanımı ise, değişen gereksinimlerimizi sürecimize uyguladığımızda bunun sonucunda ihtiyaç duyduğumuz çözümün geliştirileceğidir. Buna bir de ters taraftan bakarsak, sürecimiz her yeni projeyle ateşle bir kez daha sınanarak, kendini geliştirecek ve daha fazla sayıda (ve farklı özellikte) duruma (yani projelere) uygulanabilir hale gelecektir. Öyle ki bir müddet sonra şirketimizin/kurumumuzun en önemli değerlerinden birisi olacaktır.
- Hangi Yazılım Süreç Tanımı’nı kullanırsanırsak kullanalım, proje süresinde ortaya çıkacak faaliyet türleri değişmez. Gerçi süreç yaklaşımınıza göre bu süreçler arasında daha çok ayrılık veya daha çok birlik olabilir ama bu faaliyetleri disiplinler çerçevesinde aynı şekilde gruplayabiliriz: 1) Gereksinim Yönetimi: Geliştireceğimiz sistem neler yapacak? Müşterilerinizden sisteme yönelik taleplerini (need, enhancement request, bug fix) toparladıktan sonra, bu taleplerden onayladıklarınız sistemin gereksinimleri olmaktadır. 2) Analiz: Geliştireceğiniz yazılım kavramsal olarak problemi nasıl çözecek? Herhangi bir teknolojiden bağımsız problem çözümü olarak ne geliştireceğiz? UML/UP sürecinde özellikle önemli bir aşamadır. Geleneksel olarak analiz olarak adlandırılan çalışmaların ötesine geçip domain modeli (analiz class’larını bulmak) oluşturmak ve nesne etkileşimlerini incelemek hedeflidir. 3) Tasarım: Çözümümüz seçtiğimiz bir teknolojiye nasıl uygulanacak? Hedeflediğiniz teknolojiyi kullanarak çözümü gerçekleştirecek sistem mimarisini tasarladığınız aşamadır. 4) İmplementasyon: Geliştirdiğimiz sistemin çalıştırılabilir bir uygulamaya dönüştüğü ve alınan tasarım kararları dahilinde kodlamanın yapıldığı aşamadır. 5) Test (Functional Test / Acceptance Test): Yazılımın müşteri isteklerini karşıladığının onayının veri kullanımı, akış ve iş mantığı gibi konuların incelenmesiyle verildiği aşamadır. 6) Bakım: Ürünün yaşam döngüsü içerisinde gözden kaçan hatalarının giderildiği ve yeni özellikler edinerek yaşamını uzattığı aşamadır.
- Eğer bahsettiğimiz yazılım süreç disiplinlerini bir örneğe uygulamak istersek, Proje Konusu: Bireysel Finans 1) Gereksinim Yönetimi Yeni bir gereksinim ortaya çıkar: “Kullanıcının bakiyesi gösterilmelidir” Bu gereksinim genellikle para çekme işlemiyle birlikte ortaya çıktığından, onun akışına yeni bir detay olarak eklenir. Örneğin, ‘Para Çek’ kullanım senaryosunun dokümanında akışlardan birine eklenen satırlar gibi. 2) Analiz ve Tasarım Yeni gereksinimi karşılayabilmek için yeni class’lara ihtiyaç duyuldu: VadesizHesap ve VadeliHesap. Bu class’lar daha sonra farklı akışlar için de kullanılabilecektir. Class’ların sorumlulukları bu yeni ortaya çıkan ihtiyaçlara karşılık verebilmek için zaman içerisinde genişleyecektir. 3) İmplementasyon Hedeflenen bir programlama dili kullanılarak, istenilen servisler gerçekleştirilecektir. 4) Test Akış, iş mantığı ve bunların implementasyonu veri setleri kullanılarak kontrol edilecektir. Burada kasdedilen programcının yaptığı testlerden ziyade, genellikle sistem analistlerinin müşteri temsilcileriyle birlikte yürüttüğü ürün kabul testleridir. 5) Bakım Bu aşama süreç döngüsü başa döner. Yeni bir gereksinim ortaya çıkar. Bu gereksinim yine mevcut bir sisteme yönelik olduğundan ya bir hata düzeltme (bug fix) ya da ek özellik geliştirme (enhancement request) isteğine istinaden ortaya çıkmıştır.
- Alternatif Yazılım Süreçleri: Waterfall Yazılım Sürecini oluşturan disiplinlerin sırayla birbirini takip ettiği bir yaklaşımdır. Temel eksikliği ‘tamamen bitmişlik’ varsayımları ve zaman ekseninde çalışma türünü tekrar etmemesidir (bir kontrol, sağlama, eksiklik giderme imkanı vermemesidir).
- Alternatif Yazılım Süreçleri: Waterfall Waterfall yaklaşımının en önemli özelliği az önce değindiğimiz süreçleri oluşturan disiplinlerdeki çalışmaların birbirini sırayla takip etmeleri ve bir çalışma türünden ötekine geçerken öncekinin eksiksiz olarak yapıldığının (bittiğinin) kabul edilmesidir. Bu yaklaşım altında (katı bir şekilde tarihlerine bağlı kalınmaya çalışılan proje planları yüzünden) çoğu kez kağıt üzerinde bitmiş gözüken çalışmaların bitmediklerini ve bitmiş farzedilerek ileride büyük sorunlara yol açtıklarını görürüz. Bu yaklaşıma karşı çıkanlar bu tür detaylı gereksinimlerin ve proje planlarının işin başında oluşturulabileceği iddiasının yazılım geliştirme işinin doğasına aykırı olduğunu iddia ederler.
- Alternatif Yazılım Süreçleri: Spiral Bu yaklaşımın ilginçliği hem waterfall yaklaşıma hem de birazdan göreceğimiz iteratif yaklaşıma uygulanabileceğidir. Yazılımın kademe kademe oluşturulabileceği düşüncesini ortaya çıkaran ve gelişmesine imkan tanıyan bir yaklaşımdır. Salyangoz yapısını bozarak süreci düz bir çizgiye dönüştürün waterfall süreç yapısı ortaya çıkar.
- Alternatif Yazılım Süreçleri: Spiral Spiral sürecin salyangoz yapısında disiplinleri (çalışma türlerini: Gereksinim Yönetimi, Analiz, Tasarım, vs.) daha net bir şekilde belirleyin ve zaman eksenindeki kontrolünüzü artırın (Salyangoz içinde proje gelişimi süresince pek çok döngü tamamlayın), elinize İteratif Yazılım Süreci yapısı geçer. Pek çok farklı durumda gördüğümüz gibi bir probleme yönelik geliştirdiğimiz yeni (ve radikal) yöntem aslında eski çalışma şeklimize çok benzemekte ama bakış açımızda bir farklılık olmaktadır. Örneğin, Lotfi Zadeh’nin Fuzzy Logic teorilerini geleneksel mantık üzerine nasıl oturttuğunu hatırlayabilirsiniz.
- Spiral yaklaşımı, iterasyon ve faz kavramlarının altına yerleştirerek en kabul gören İteratif Yazılım Süreç tanımı haline gelen Rational Unified Process (RUP) ya da günümüzdeki daha yaygın adıyla, Unified Process’dir (UP). Unified Process yapısının en önemli özelliklerinden birisi ‘Sihirli Çalışma Bitiş Tarihlerini’ ortadan kaldırmasıdır. Yazılım süreci içindeki disiplinlere ait çalışmalar birbirlerini hem takip ederler hem de birbirleriyle örtüşürler. Dolayısıyla bu yapının ardında şu anlayış yatmaktadır: Yazılım mühendisliği çalışmaları iş yoğunluğu olarak ayrı zaman dilimlerine ayrılabilirler ve çalışmaların büyük bir bölümü bu zaman içinde gerçekleştirilebilir. Bununla birlikte, çalışmaların sonuna bir nokta koymak bu kadar kolay değildir. Yazılım mühendisliği çalışmalarının mahiyetinden dolayı imkansız ve gereksizdir.
- UML’in gelişimindeki en önemli üç kişiyi UP’in gelişiminde de görüyoruz. Zaten bu yüzden UP’in omurgası olan UML’in üzerine inşaa edildiğini anlayabilirsiniz. Dolayısıyla UP üzerinde bir hakimiyet oluşturmadan kullanılan UML yaklaşımı farkında olmadan yapılan bir UP uyarlaması olmasının da ötesinde eksiklikleri olan bir UP uyarlamasıdır. UML’den bile daha çevik bir yazılım süreci kullanmak istiyor olabilirsiniz, ancak UP genel yapısı üzerinde bir hakimiyetiniz yoksa kararlarınızın isabetliliği her zaman tartışmaya açıktır.
- Hangi süreci kullanırsak kullanalım, süreç mühendislerinin deneyimleri onları aşağıdaki ‘ altın sözlere’ yöneltmiştir: Farklı bir şekilde yaklaşıldığında hepsinin tersi de doğru olmakla birlikte, özdeyişlerin tersinin de doğru olması onların gerçekten birer özdeyiş olduklarını teyit eden en önemli özellikleri değil midir? Method over Tool: Yöntemi ve onun öğelerini yazılım süreç çalışmamızın odağı haline getirmeliyiz. Bu süreçte kullanacağımız ürünlere ikincil bir önem vermeliyiz. Seçtiğimiz ürünlere bağımlı hale gelmemeliyiz. Project over Method: Proje (yani geliştireceğiniz ürün) kullandığınız yazılım süreçi yaklaşımlarından ve problem çözme tekniklerinden daha önemlidir. Kendimizi sonu gelmeyen ‘süreç için süreç’ yaklaşımına kaptırmamalıyız. Yöntem beklenen faydayı sağladığında diğer aşamaya geçmemiz gerekir. People over All: Projeyi geliştirenler ve kullanıcıları başta gelmek üzere tüm paydaşların (projenin sorumluluğunu paylaşan herkesin) katkılarından devamlı ve düzenli olarak yararlanınız. İteratif yazılım geliştirme yönteminin ortaya çıkış nedenlerinden bir tanesi de zaten budur: Kullanıcılarla düzenli olarak görüşerek, elle tutulur bir öğe (executable(s), modeller, dokümanlar) üzerinden geçmek.
- İterasyon kavramını incelerken bunu UP referanslı olarak yapacağız. Bu şekilde konunun çok daha anlaşılır ve kolay uygulanabilir hale geldiğine dikkat ediniz. UP iterasyonların üstünde dört ana aşamaya (phase) ayrılır. Bu aşamalar zaman içerisinde birbirlerini takip ederler. Her birinin bitişi üretilenler ve proje sürecindeki yerimiz açısından büyük önem teşkil eder. Sırasıyla bu aşamalara bakacak olursak, Inception (Saptama): Projenin kapsamı, sınırları ve sağlanacak çözümün gereksinimleri artık kesinleşmiştir. Bitiş sinyalini Gereksinim Yönetimi çalışmalarının odağını yitirmesi gösterir. Bunun manası Vizyon, Use Case Modeli (ve UC Dokümanları), Ek Gereksinim Dokümanları üzerinde % 80 kontrolümüz vardır. Elaboration (Tasarlama): Proje planı detaylanmaya başlamıştır ve artık iyice oturmuştur. Önceki aşamada tarif edilen çözüme karşılık gelen sistem mimarisi tasarlanmıştır. Bitiş sinyalini Analiz ve Tasarım çalışmalarının odaklarını yitirmesi gösterir. Bunun manası projeye özel kapsamda Analiz Modeli ve Tasarım Modellerinin oluşturulmuş olmalarıdır. Construction (Oluşturma): Artık egemen çalışma şekli kodlama haline gelmiştir. Hala ufak gereksinim değişiklikleri ve tasarıma çeşitli rötuşların yapılması mümkündür. Ancak bu çalışmaların kritik etkileri artık ortadan kalkmıştır. Bitiş sinyalini Programlama (İmplementasyon) çalışmalarının odaklarını yitirmesi (Post-Mass Production) gösterir. Bunun manası yazılımın büyük ölçüde çalışır (programcı testlerini geçmiş) kodunun geliştirilmiş olmasıdır. Transition (Sunma): Geliştirilen yazılım kademe kademe müşteri ortamına çekilmeye başlanmıştır. Artık gelen değişiklik isteklerinin önemi minimaldir. Bitiş sinyali bakım ve gelecek sürüme yönelik müşteri isteklerinin toplanmaya başlamasıyla kendini belli eder. Bunun manası müşteri ortamında etkin bir biçimde kullanılan yazılım sürümünün ortaya çıkmış olmasıdır.
- Değindiğimiz iterasyonlar üstü olan dört temel UP aşamasının altında ise pek çok sayıda iterasyon (daha kısa süre alan aşamalar) görürüz. Burada sadece tek bir disiplin kapsamında çalışmaları parçalara bölmenin bir iterasyon oluşturmayacağıdır . İterasyon sonucunda mutlaka çalıştırılabilir (proje başların daha çok dummy, prototip) bir yazılımın oluşturulması gerektiğidir. A.B.D. Savunma Bakanlığının güzel bir iterasyon (evolutionary strategy) tanımını aşağıda bulabilirsiniz: "The evolutionary strategy differs from the incremental in acknowledging that user needs are not fully understood, and all requirements cannot be defined up front, they are refined in each successive build." Software Development and Documentation, MIL-STD-498, U.S. Department of Defense, December 1994.
- İterasyon farklı iş yoğunlukları (zaman, emek) altında mutlaka çok sayıda çalışma şeklini içeren ve bu çalışmaların sona erdiği aşamada ortaya çalıştırılabilir bir yazılım parçası çıkaran faaliyetlere verilen bir addır. İterasyonlar için verilecek formüle edilmiş bir zaman uzunluğu olmamakla birlikte (çünkü bu proje mahiyetine göre değişecektir), genellikle 4-8 haftalık süreler telaffuz edilir. Eğer proje kısa sürede yapılan bir projeyle bu zamanlama ona göre ayarlanır. Hatırlarsanız, projenin ana aşamaları ve sonuçlarında neler olması gerektiği bellidir (Inception, Elaboration, Construction, Transition). Yine Gereksinim Çalışmalarının ilk aşamalarında ortaya çıkacak Use Case Şemalarındaki use case’lerin önceliklerine göre iterasyon kapsamlarını ve iterasyon sayılarını belirlemek de mümkündür. Bu kolaylıkların hepsini İteratif bir yazılım süreci olan UP aracılığıyla elde ediyoruz.
- Inception: Proje risklerinin ortaya konması Elaboration: Senaryolarla sistemin yapısının ve davranışının oluşturulması Sistem Mimarisinin oluşması Temel mekanizmaların tasarlanması Construction: Mimarinin Revizyonu Risk-bazlı iterasyonlar Entegrasyon Transition: Kullanıma sunma Müşteri memnuniyetini ölçme
- İteratif yaklaşıma diğer bir bakış şekli de onu ‘Risk Azaltma Odaklı’ olarak tanımlamaktır. Gerçekten de kademeli olarak (aynı tür çalışmaları tekrarlayarak) ve işe en zor (en önemli) kısmından başlayarak yazılım geliştirmeyi desteklediğinden dolayı geçirdiğimiz her iterasyon omuzlarımızdaki yükü hafifletir ve her yeni iterasyon bir öncekinden daha kolay olur.
- İterasyonlar da aslında özünde birer waterfall süreci uygulamasıdır. Farkı bizi bu waterfall sürecinin kontrolü altına girmekten koruyarak, süreci bizim kontrolümüz altına sokmasıdır. Bunu yapabilmemizin yegane nedeniyse iterasyon kapsamındaki waterfall süreçlerinin çok kısa tutulmalarıdır.
- İterasyon Planı: • İterasyon’a başlanmadan amaçlarının belirlenmesi: • Önceki iterasyonların sonuçları • Güncel Risk Raporu • İterasyona yönelik Başarı Kriterlerinin belirlenmesi • Proje planına iterasyon planlarının eklenmesi • Performans ölçümü için yapılacak işlerin kademelendirilmesi • İterasyon detaylarının eklenmesi Gereksinimlerin Saptanması: • İterasyonla gerçekleşecek use case’lerin seçilmesi • Nesne modelinin bulunan class ve ilişkilerine göre yenilenmesi • İterasyona yönelik test planının yapılması Analiz ve Tasarım: • İterayonda oluşacak veya yenilecek class’ların saptanması • Nesne modelinin yeni bulunan class ve ilişkilerine göre güncellenmesi • Sistem Mimarisi dokümanının güncellenmesi • Test işlemlerinin başlatılması Uygulama: • Nesne modelinden kod üretilmesi • Fonksiyonların kodlarının yazılması • Test senaryolarının tasarlanması • Birim bazında ve genel entegrasyon testleri Test: • Oluşan kodun sisteme entegrasyonu ve yeni sistemin testi • Test sonuçlarının kaydı ve değerlendirilmeleri • Başarı kriterlerine göre test sonuçlarının değerlendirilmesi • İterasyon değerlendirilmesinin yapılması Release: • Kod ve Model Senkronizasyonu • İterasyon bazlı konfigürasyon denetimi
- Waterfall sürecinin sahip olduğu sorunlara spiral yaklaşımdan da yararlanarak verilen yanıt Rational Software şirketinin geliştirdiği Unified Process Süreç Tanımı aracılığıyla olmuştur. Şimdi bunun gelişimi ve mantığı hakkında biraz bilgi vereceğiz. Slayt 20 – 28 arasında ünlü yazılım stratejisti Murray Cantor’ın “Software Leadership” adlı kitabını refere edeceğiz ve onun engin deneyimlerinden yararlanacağız.
- Eski müşteri – yazılım ekibi ilişkilerinde pek çok kez kazanan, kaybeden, yenen ve yenilen gibi terimler kullanabilirdik. Daha da ilginci bu iki grup (ve yazılım ekibi içerisindeki pek çok diğer grup) arasındaki sürtüşmeler grupları birbirinden ayıran kültürel öğelere dönüşerek, hatalı çalışma şekillerinin yanıltıcı bir yazılım süreç tanımına dönüştüğünü saptayabilirdik. MPP süreç tanımının son P’sini hatırlarsanız ( P eople over All), bu UP’in en önemli hedeflerinden birisi olarak süreç tanımının merkezine oturmuştur. Hedeflenen birbiriyle yoruma açık olmayan, etkili bir şekilde haberleşebilen, birbirlerinden öğrenebilen ve birbirlerine yardımcı olan, zaman içerisinde bir kurum kültürü oluşturarak kaliteyi (kaliteli çalışma ortamı, kaliteli yazılım, vs.) bir yaşam tarzı haline getiren açık bir toplum hedeflenmektedir. Dolayısıyla UP’e yaklaşmaya karar verdiğinizde sahip olmanız gereken bir olgunluk seviyesi vardır: Hataları görünce kabullenebilmek.
- Geleneksel waterfall yaklaşımında kullanılan bir yaklaşımın kilometre taşı tabir edilen bazı iş ürünlerinin ortaya çıkması olduğunu görürüz. Deneyimlerimiz bu tür iş ürünlerinin ortaya çıkmasının kafi başarı olarak kabul edildiğini ve bunun yanıltıcı bir başarı hissi olduğunu gösteriyor. Yine geleneksel yaklaşımlar altında çalışmaya alışmış proje yöneticileri iteratif yazılım geliştirme yaklaşımının programcılara eksiksiz bir gereksinim dokümanı verilmeden onları programlamaya ittiğini söyleyerek itiraz etmek eğilimindedirler. İteratif yaklaşımın ilk ortaya atıldığı günlerde, günümüzdeki başarısını tekrar tekrar kanıtlamış iteratif formüle (UP içindeki tanımı ve kullanımına) sahip olmadığınızda, geçerli olabilecek bir iddia.
- Üniversitedeki istatistik derslerinden hatırlayabileceğiniz Pareto Kanunu kısaca: Emek ile Fayda arasında devamlı olarak doğru orantılı bir ilişki kuramayacağımızı söyler. Bu kanuna göre % 20 emek harcayarak, hedeflediğiniz faydanın % 80’ine ulaşırsınız. Faydanın % 80’i üzerine geçmeye çalıştıkça harcadığınız emek çok daha fazla oranda artar: Bir Türkçe deyimle, astarı yüzünden pahalıya gelir.
- Pareto Kanununu yazılım geliştirmeye uygularsak önümüze gene aynı netice çıkar: Hata payını en aza indirmek çok emek ister! Dolayısıyla odağımız en azdan ziyade çok aza, tolere edilebilen miktara kaymalıdır. Eksik kalan kısımların zaman içerisinde (farklı çalışma türlerinin yoğunlukta oldukları esnalarda) giderilmesine çalışılmalıdır.
- Çalışmalarımıza kontrolümüz altına aldığımız zaman eksinini bir zemin olarak aldığımızda (UP’in Faz ve İterasyon yapısı) önümüzdeki paradoksa bir çözüm geliştirebiliriz.
- Detaylı olarak oluşturulmuş planların uygulanabilirlikleri sıfıra yakındır. Bunun en büyük nedeni işin başında bilinmeyenlerin sayısının çok fazla olmasıdır: ‘ Gerçek’ müşteri isteklerinin ortaya çıkarılması, Yaratıcılığın ve Çözüm oluşturmanın mahiyetinden dolayı sahip olduğu zorluklar, Takım elemanları arasındaki iletişim ve uyum problemleri, vs. vs.
- Her iterasyonla, müşterinin bizi gerçek ihtiyaçlarına yönlendirmesine izin veririz. Bu yöntem eksiksiz olarak gereksinimleri bulduğumuz yanılgısını ve inzivaya çekilerek anladığımız zannettiğimiz (ve gerçekte varolmayabilecek) problem ve çözümüne yönelik çalışmalara dalmamızı engeller. Sonuçta, iterasyon kendi çıkarlarımızı ve müşteri memnuniyetini aynı oranda korumamızı sağlayabilecek bir Manevra Mekanizmasıdır.
- Kuşkusuz waterfall yaklaşım altında da bir şekilde (bütçe ve zamanını aşarak) projeler müşteriyi tatmin eder hale gelmektedir. Bu negatif etkilerin en büyük nedeni “Detaylı Olarak Herşeyi Planla ve Takip Et” yaklaşımından kaynaklanmaktadır. Planlanmış içerik gerçek ihtiyaçlara karşılık gelmebilir. Eldeki gereksinimlere göre yapılan testlerin başarısı müşterinin ihtiyaçlarını karşılayacak bir çözümün geliştirildiği anlamına gelmeyebilir.
- Kulağa biraz felsefi gelmekle birlikte, izlenecek yol proje süresince tanımlanır. Bu yüzden iteratif yaklaşım altında liderlik ve insiyatif almak çok önemli özelliklerdir. Proje gelişimi süresince gerekli yerlerde manevralar yapmak ve gerçek hedefi ortaya çıkarmak gerekir.
- Unified Process’in anlaşılabilmesi ve uyarlanabilmesini sağlayan mekanizma tektir ve aynıdır. UP süreç tanımı materyali veya sizlerin kendi hedeflerinize yönelik oluşturacağınız UP Uyarlamaları (XP Odaklılardan CMMI Odaklılara dek) hep bu üçlü yapıya sahip olmak zorundadır . Bu üç tanım grubunu belirlemeden yapacağınız her UP uyarlama ve kullanma çabası işinizi kolaylaştırmayabileceği gibi en önemli katkısı angarya miktarını artırmak ve proje başarısını güçleştirmektir. Bu tanım grupları, Roller (Role), Yapılanlar (Activity) ve Üretilenler’dir (Artifact).
- Bu üçlü yapının detaylarına girecek olursak, [1] Rol (Role): Proje süresince etkileşim içinde olacak, proje sorumluluğunu paylaşacak ve projeden şu veya bu şekilde etkilenecek herkes. Bizi özel olarak ilgilendirenler ise yazılım ekibi içerisinde olanlar. Bazen “Burada herkes her işi yapar” iddiasıyla karşılaşabilirsiniz. Gerçekte böyle bir yaklaşım olsa dahi herkesin canlandırdığı farklı roller, farklı başarı seviyeleri, çelişen veya birbirini destekleyen rol grupları mutlaka vardır.
- [2] Yapılanlar (Activity): Tanımladığınız bir rolü ele aldığınızda proje süreci içerisinde yaptığı çalışmaların neler olacağının bir listesi ve bu çalışmaların açıklamalarıdır. Bu sayede bir rolün işini yaparken hangi aşamaları yaşadığını dolayısıyla çalışmalarının hangi aşamada olduğuyla ilgili daha detaylı bir bilgi edinme imkanına sahip oluruz.
- Bu üçlü yapının son öğesi ise, [3] Üretilenler (Artifact): Tanımladığınız rollerin bir hedefe yönelik olarak yaptıkları çalışmalar neticesinde üretilen veya üretilmesine katkıda bulunulan iş ürünleridir. Bu iş ürünleri arasında proje süreci aşamaları ve disiplinler bazında bir ilişki yapısı mevcuttur.
- Değindiğimiz üçlü yapıyı hatırlayarak, UP yapısını özetlersek, Kademe 1: Süreç Tanımı çeşitli Disiplinlere bölünmüştür: İş Modeli, Gereksinimler, Analiz ve Tasarım vs. Kademe 2: Her Disiplin altında işlerin nasıl yapılacağını anlatan bir İş Akışı (Workflow) vardır. Kademe 3: Her İş Akışı altında bu akışın çeşitli detay bilgilerine sahip İş Akışı Detayları vardır. Kademe 4: İş Akışı Detayları altında yapılacak işle ilgili açıklamalar, şablonlar vs. bulunur. Kademe 5: Şablonlar UP’in son kademesini oluşturmaktadır.
- [1] Unified Process Yapısı: Disiplinler ve İş Akışları UP’de tanımlı disiplinler (çalışma türleri, uzmanlık alanları) şunlardır: İş Modeli Gereksinimler Analiz ve Tasarım İmplementasyon (Kodlama) Test Uygulama (Deployment) Konfigürasyon ve Değişiklik Yönetimi Proje Yönetimi Çalışma Ortamı Yönetimi (Environment) Bu Disiplinlerin hepsinin altında kendisine özel (ve kuruma/projeye göre uyarlanan) bir iş akışı vardır. Bu İş Akışları önce ve sonralık ile koşul ilişkileri kurulmuş adımlardır. Birer Activity Şemasıyla resmedilmişlerdir.
- [2] Unified Process Yapısı: İş Akışı Detayları İş Akışı Adımlarına karşılık gelen detay bilgileri, dikkatlerimizi ilk olarak değindiğimiz üçlü yapıya (Rol-Yapılan-Üretilen) çeker: Geçerli Rol: Bu aşamada işi yapacak roller hangileridir? Yardımcı Roller (Kırmızı olanlar): İşin yapılmasına yardımcı olacak roller hangileridir? Yapılması Gereken İşler: Hedeflenen çalışmanın sonucuna ulaştırılabilmesi için gereken alt çalışmalar nelerdir? Üretilenler: Yapılan çalışmalar neticesinde ortaya çıkan iş ürünleri nelerdir?
- Daha fazla detaya ulaşmanın da aynı mantık üzerinden üç yolu vardır: Rol, Yapılacak ve Üretilecek yolları. [3a] Unified Process Yapısı: Rol Üzerinden Daha Fazla İş Akışı Detayı Role odaklandığımızda o rolün tüm yazılım proje süreci boyunca yapabileceklerine ve üreteceklerine odaklanabiliriz. Dolayısıyla bu bakış açısı özellikle süreç uyarlaması yapacağımız zaman neleri isteyip neleri istemediğimizi belirlemek için kolaylık sağlayan bir bakış şeklidir.
- [3b] Unified Process Yapısı: Yapılacaklar Üzerinden Daha Fazla İş Akışı Detayı Bu bakış açısı bilfiil tanımlı işi yapanların çok başvuracağı bir yoldur. Böylece işlerini yaparken neler yapmaları ve nelere dikkat etmeleri gerektiğini öğrenmek veya hatırlamak amacıyla kullanılabilinir.
- [3c] Unified Process Yapısı:Üretilenler Üzerinden Daha Fazla İş Akışı Detayı Bu bakış açısı yine bilfiil tanımlı işi yapanların çok başvuracağı bir yoldur. Böylece işlerini yaparken neler yapmaları ve nelere dikkat etmeleri gerektiğini oluşturacak iş ürünleri bazında öğrenmek veya hatırlamak amacıyla kullanılabilinir.
- [4] Unified Process Yapısı:Üretilenler Üzerinden Daha Fazla İş Akışı Detayı UP’in en alt kademesinde ise artık yapacağımız çalışmalrda kullanabileceğimiz şablonlara rastlarız. Bu şablonlar proje ve kurum özelliklerimize uyarlanmış olmalıdırlar. Bu bakış da yine bilfiil tanımlı işi yapanların çok başvuracağı bir yoldur.
- Bu ünitede ilk olarak yaptığımız süreç tanımını hatırlarsak, yeni gereksinimler sürecimize tabii tutulduğunda ihtiyaçlarımıza cevap veren yeni sistem ortaya çıkar. Bu tanımı biraz genişletirsek, UP içindeki Disiplinlerin altındaki İş Akışlarını uygulanırken tüm iş ürünlerimiz (Model, Doküman, vs.) ve kademe kademe geliştirdiğimiz yazılım ortaya çıkar.
- Yaptığımız süreç tanımını eksiksizleştirmek için ekleyebileceğimiz son bölüm ise kullanacağımız Yazılım Mühendisliği Ürünlerini ve kullanımlarını tanımlamaktır. UP’in içinde, doğal olarak, bunun sadece IBM Rational ürünleriyle nasıl yapılabileceği anlatılmaktadır. Bununla birlikte UP’in diğer ürünlerle kullanımı da (eş değer kabiliyetlere sahip olanlarla) aşağı yukarı aynı şekildedir. UP’in eksiksiz bir biçimde uygulanabildiği diğer bir ürüne örnek olarak, Sparx Systems’ın Enterprise Architect ürününü (Avustralya) verebiliriz. Bu ürün UML ürünü kategorisinde IBM Rational XDE, SM, SA ve Rose eşdeğeridir.
- Rol – Yapılan – Üretilen - Ürün Unified Process’i (ve en temel parçası olan UML’i) ne amaçla kullanırsak kullanalım, süreç tanımının üç ayaklı yapısına (roller, yapılanlar, üretilenler) hakim olmak ve onlar aracılığıyla çalışmak zorundayız.
- SPEM herhangi bir şirketin kendine özel süreç sembollerini kullanmaktan bizleri kurtarmaktadır. Tüm Unified Process kavramlarını içeren sembolleri ile dilediğiniz UML ürününü kullanarak yazılım süreç yapınızı tanımlayabilmenizi sağlar.
- Birebir spem gösterimine uyma kaygımız olmadığından, biraz özgür bir yaklaşımla, [1] SPEM Gösterimi: Disiplinler Bir hiyerarşik yapı oluşturmalıyız. Örneğin: Süreç > Fazlar > Disiplinler > {Yapılanlar / Roller / Üretilenler} (Bu bizim kullanacağımız yaklaşım olacak). Diğer muhtemel hiyerarşik yapılar: Yapılanlar > Disiplinler, Roller > Disiplinler, Üretilenler > Disiplinler
- [2] SPEM Gösterimi: Roller Her Faz > Disiplin > Roller yapısı altına sadece alakalı olan rolleri yerleştireceğiz.
- [3] SPEM Gösterimi: Yapılanlar Her Faz > Disiplin > Yapılanlar altına o disiplin çalışmaları gerçeleşirken yapılması gereken faaliyetleri yerleştireceğiz.
- [4] SPEM Gösterimi: Üretilenler Her Faz > Disiplin > Üretilenler yapısı altına sadece alakalı olan dokümanları, model öğelerini ve model türlerini yerleştireceğiz.
- [5] SPEM Gösterimi: Hepsini Birleştirirsek Her sıkı rol ilişkisini veya bir disiplinden diğerine geçişi göstermeye çalıştığımızda, eğer eksiksiz bir resmini çizmek istersek, şemamıza roller, yapılanlar ve üretilenleri bir arada koymalıyız.
- Unified Process süreç tanımı ile elimize geçen imkanları daha iyi anlayabilmemiz için bir süreç haritası inceleyelim, Haritamızın iki ekseni var. Dikey eksende yukarıya ilerledikçe Waterfall yaklaşım eğilimi artmakta, aşağıya ilerledikçeyse İteratif yaklaşım. Yatay eksen boyuncaysa, sola doğru lerledikçe daha çevik, sağa doğru ilerledikçeyse daha disiplinli ve daha çok doküman üreten süreç tanımlarına yaklaşıyoruz.
- Süreç haritamızda ‘Güney Batı’ çevik süreçler demektir: Extreme Programming ve benzerleri bu bölgede yer alırlar.
- Süreç haritamızda daha disiplinli ve çok doküman kullanımına dayalı süreç tanımları ‘ Doğu’da yer alırlar: CMM waterfall eğiliminden dolayı ‘Kuzey Doğu’da, CMMI ise iteratif eğiliminden dolayı ‘Güney Doğu’da yer alır.
- İyi haber tüm bu eğilimleri Unified Process’in dekteklemesidir. Bu yüzden UP diğer süreç Modelleri gibi bir yönde eğilimden ziyade eğilimlerinizden bağımsız olarak faydalanabileceğiniz engin bir ‘alet kutusudur.’
- UP eğilim ve kendi özel ihtiyaçlarınıza uyarlanarak karşılık verir. Rational United Process en alttaki kaynak olmak üzere, konuya uzman bir süreç danışmanıyla yapacağınız çalışmalar neticesinde, size özel bir süreç tanımı ortaya çıkar: {Şirket Adı} Unified Process. Bunun üzerine ise her projenin kendi istiyaçlarına göre kendi UP’nizin bir alt kümesini kullandığınız çalışmalar yer alırlar.
- [1] Standart UP Yaklaşımı: Gereksinim Yönetimi Sistem Analisti Yaptıkları: Müşteri İsteklerini derle Vizyon Dokümanını hazırla Projeye has kelime haznesini oluştur Aktör ve Kullanım Senaryolarını bul Use Case Modelini oluştur Use Case Dokümanlarını hazırla Ek Gereksinimler Dokümanını hazırla Gereksinim Yönetimi Planını hazırla Ürettikleri: Müşteri İstekleri Dokümanı Vizyon Use Case Modeli Gereksinim Yönetimi Planı Sözlük Ekran Kullanım Senaryoları (Kullanıcı Etkileşimi Modeli > Storyboard(s)) Kullanıcı Arayüzü Tasarımcısı Yaptıkları: Kullanıcı Arayüzlerini tasarla Kullanıcı Arayüzü prototipini oluştur Ürettikleri: Ekran Akış Şemaları Kullanıcı Arayüzü Prototipi
- [2] Standart UP Yaklaşımı: Analiz ve Tasarım Sistem Mimarı Yaptıkları: Kullanım Senaryolarını önceliklendir Sistem Mimarisi Analizi yap Tasarım teknikleri belirle Tasarım paketlerini belirle Sistem Mimarisi Proof-of-Concept hazırla Model yapılarını belirle (Analiz, Tasarım, Deployment ve İmplementasyon için) Ürettikleri: Analiz Modeli yapısı Tasarım Modeli yapısı Deployment Modeli yapısı İmplementasyon Modeli yapısı Sistem Mimarisi Dokümanı (UML modelinden otomatik olarak üretilir) Tasarımcı Yaptıkları: Use Case Analizi yap Use Case Tasarımı yap Modül Tasarımı yap Ürettikleri: Use Case Realization içeriği (Analiz ve Tasarım)
- [3] Standart UP Yaklaşımı: İmplementasyon Programcı Yaptıkları: Tasarım paketi içerikleri için kod yaz Programcı testlerini hazırla Programcı testlerini gerçekleştir Ürettikleri: Kod Test sonuçları
- UP Sürecini kabaca özetleyecek olursak, Sistem Analisti Use Case Modeli ve Ek Gereksinimler Dokümanını hazırlar ve Tasarımcı’ya, Veritabanı Tasarımcı’sına ve Kullanıcı Arayüzü Tasarımcısı’na sunar. 2. Tasarımcı [ Paralel Çalışma ] Analiz Modeli ve Tasarım Modelini hazırlar ve Programcıları yönlendirir. 3. Veritabanı Tasarımcısı [ Paralel Çalışma ] Veritabanı Modelini hazırlar. 4. Kullanıcı Arayüzü Tasarımcısı [ Paralel Çalışma ] Kullanıcı Etkileşim Modelini hazırlar.
- [1] UP Uyarlaması Çalışması: Gereksinimler Ahmet Bey birincil görevi olan Sistem Analisti rolünü canladırıcak. Bu rol altında yapacağı çalışmalar sırasıyla, Aktör ve Kullanım Senaryolarının bulunması Use Case Modelinin oluşturulması Use Case Dokümanlarının hazırlanması Ek Gereksinim Dokümanının hazırlanması
- [2] UP Uyarlaması Çalışması: Analiz ve Tasarım Ahmet Bey akışları hazırlayan kişi olduğundan kolaylıkla Ekran Akış Şemaları ve Storyboard’ları (Nesneler yerine ekranların kullanıldığı Sequence Şemaları) hazırlayabilir. Bu aşamadaki paralel çalışmalardan birini ise Mehmet Bey Veritabanı Analisti rolünü canlandırarak yapmaktadır. Öte yandan Analiz ve Tasarım aşamasındaki en önemli çalışmalar Leyla Hanım tarafından, iki rol altında gerçekleştirilmektedir: Tasarımcı ve Sistem Mimarı. Tasarımcı olarak Use Case Analizi, Use Case Tasarımı ve Etkileşimli Ekran Akışlarını (Storyboard) hazırlamaktadır. Sistem Mimarı olaraksa Analiz, Tasarım, Deployment ve İmplementasyon Modellerinin yapılarını belirlemektedir.
- [3] UP Uyarlaması Çalışması: İmplementasyon Değindiğimiz çalışmalarına ek olarak Leyla Hanım Tasarım Paketlerinin içeriklerinin kodlanması ve ortaya çıkan bileşenlerin test scriptlerinin oluşturulup, programcı testlerine (Unit Test) tabii tutulmasında görev alabilir.
- [4] UP Uyarlaması Çalışması: Fonksiyonel Test Bu aşamada asıl görevi sistem analizi olan Ahmet Bey’i tekrar görürüz. Ahmet Bey fonksiyonel test scriptlerinin hazırlanmasında (Use Case Dokümanları üzerinden), testlerin gerçekleştirilip, ilgili raporların hazırlanmasında görevlendirilebilir.
- [5] UP Uyarlaması Çalışması: Proje Yönetimi Hülya Hanım birincil görevi olan proje yöneticiliği kapsamında farklı gruplara ait çalışmalar yapar: Geliştirme Planlama Yazılım Geliştirme Planının hazırlanması İterasyonlar ve Fazların (Inception, Elaboration, Construction, Transition) kapsamlarının belirlenmesi İterasyon Planlama İterasyon Planlarının hazırlanması İterasyon Sonuçlarının değerlendirilmesi Diğer Planlama Faaliyetleri Ölçme ve Değerlendirme (Metrik) Planının hazırlanması Risk Yönetimi Planının hazırlanması Kalite Güvence Planının hazırlanması
- [6] UP Uyarlaması Çalışması: Süreç Mühendisliği Hülya Hanım birincil işi olan proje yönetiminin yanına kaynak sıkıntısı yüzünden süreç mühendisliğini ekleyebilir. Ancak (çıkar çatışmasından ziyade) rollerin iş yükleri yüzünden, proje başarısını kötü olarak etkilememek için bu rollerin farklı kişilerce canlandırılmaları tavsiye edilir. Süreç Mühendisi olarak Hülya Hanım yazılım süreç tanımını proje ihtiyaçlarına göre uyarlar, projenin ihtiyaç duyacağı şablon ve kılavuzları hazırlar.
- Edindiğimiz bilgiler ışığında ihtiyaç duyduğumuz yazılım ekibi personelini tanımlamak istersek, ideal bir kadro aşağıdaki rollere sahip olmalıdır: Toplam Sayı: 6 + N Bir Proje Yöneticisi Bir Tasarımcı (Sistem Mimarı olarak da görev alabilir) Bir Veritabanı Analisti Bir Sistem Analisti (Fonksiyonel Testçi olarak da görev alabilir) Bir Kullanıcı Arayüzü Tasarımcısı Bir Süreç Mühendisi Gerekli sayıda Programcı
- Eğer kaynak ve finansman sıkıntımız varsa (bazı kurallara uymak şartıyla) bu sayıyı aşağıya çekebiliriz: Toplam Sayı: 4 + N Bir Proje Yöneticisi [Süreç Mühendisi] Bir Tasarımcı (Sistem Mimarı olarak da görev alabilir) Bir Veritabanı Analisti Bir Sistem Analisti [Fonksiyonel Testçi, Kullanıcı Arayüzü Tasarımcısı] Gerekli sayıda Programcı (Bir tanesi Kullanıcı Arayüzü Tasarımcısı olarak da çalışmak üzere)
- [1] Yazılım Ekibi: Minimum Konfigürasyon Ahmet Bey, Sistem Analisti rolü altında sırasıyla, Vizyon Dokümanını, Use Case Modelini, Use Case Dokümanlarını ve Ek Gereksinimler Dokümanını üretir.
- [2] Yazılım Ekibi: Minimum Konfigürasyon Ahmet Bey, Kullanıcı Arayüzü Tasarımcısı rolü altında sırasıyla, Kullanıcı Etkileşimi Modelini (Etkileşimli Ekran Akışlarını da –storyboard- içerir) üretir. Programcılık gereken kısımda görevi ilgili bir role aktarmalıdır. Bu yeni rol (Kullanıcı Arayüzü Tasarımcısı veya Programcı adı altında) Kullanıcı Arayüzü Prototiplerini üretir.
- [3] Yazılım Ekibi: Minimum Konfigürasyon Ahmet Bey, Fonksiyonel Testçi rolü altında sırasıyla, Test Scriptlerini ve Test Suitlerini (test scripti grupları) hazırlar. Testleri gerçekleştirir ve Test Log’larını hazırlar.
- [4] Yazılım Ekibi: Minimum Konfigürasyon Leyla Hanım, Sistem Mimarı rolü altında sırasıyla, Analiz Modeli yapısını, Tasarım Modeli yapısını, Deployment Modeli yapısını ve İmplementation Modeli yapısını belirler.
- [5] Yazılım Ekibi: Minimum Konfigürasyon Leyla Hanım, Tasarımcı rolü altında sırasıyla, Analiz Use Case Gerçekleştirmelerini, Analiz Paketlerini, Tasarım Use Case Gerçekleştirmelerini, Tasarım Paketleri oluşturur.
- [6] Yazılım Ekibi: Minimum Konfigürasyon Leyla Hanım, Programcı rolü altında (diğer programcılarla birlikte) sırasıyla, Tasarım Paketleri içeriğini kodlar.
- [7] Yazılım Ekibi: Minimum Konfigürasyon Mehmet Bey yegane rolü olan Veritabanı Tasarımcısı altında (Sistem Analistinin çalışmalarını takiben, Tasarımcı ve Kullanıcı Arayüzü Tasarımcısının çalışmalarına paralel olarak) Veritabanı Modeli oluşturur.
- [8] Yazılım Ekibi: Minimum Konfigürasyon Hülya Hanım birincil görevi olan Proje Yöneticisi rolü altında (Eğer Sistem Analisti üstlenmiyorsa) Gereksinim Yönetimi Planını hazırlar. Hatırlarsanız sistem analisti rolü tanımlı değilse Vizyonu da Proje Yöneticisinin yazabildiğini söylemiştik. Bu durumda Gereksinim Yönetimi Planı içeriği daha basit bir şekilde Vizyon’un bir parçası haline gelebilir. Yazılım Geliştirme Planını hazırlar, İterasyon Planlarını hazırlar, Risk Yönetimi Planını hazırlar, Ölçme ve Değerlendirme (Measurement Plan) Planını hazırlar.
- [9] Yazılım Ekibi: Minimum Konfigürasyon Hülya Hanım iş yükü nedeniyle aslında bir başkasının yapması gereken, Süreç Mühendisi rolü altında Şirket – Proje özelliklerine göre Süreç Uyarlaması yapabilmek için Şirket Durum Değerlendirmesi dokümanını hazırlar, Projeye has doküman şablonlarını hazırlar, Projeye has kılavuzları hazırlar.
- Proje başında bazı tanımlamaların yapılmaları ileride bize düzenlilik, anlaşılırlık, takip edilebilirlik ve yönetilebilirlik sağlayacaktır. İlerideki slaytlarda göstereceğimiz tanımlamalar eksiksiz olmamakla birlikte olası tanım çeşitleri hakkında genel bir fikir vermektedir. Burada konuyu daha kolay açıklayabilmek için Sparx Systems – Enterprise Architect ürününe entegre menü sistemleri kullanılmıştır. Eğer başka UML ürünleri kullanıyorsanız, aynı tanımlamalar çeşitli dokümanlarda yer alacaklardır.
- [1] Proje Tanımlamaları: Paydaşlar – Müşteriler Müşteriler Kullanıcılar, Sponsorlar ve yazılım ekibi içinde yer almayan diğer gruplar arasından seçilirler. Her tanımladığınız türün adı soyadı ve erişim bilgilerinin istendiğine dikkat ediniz.
- [2] Proje Tanımlamaları: Kaynaklar şirketiniz genelinde tanımlanmış yöneticilerin seçerek projelerine dahil ettiği eleman listenizdir.
- [3] Proje Tanımlamaları: Kaynaklarınızdan projenize elemanları seçtikten sonra onların canlandırabileceği rol tanımlarınız olmalıdır.
- [4] Proje Tanımlamaları: Projenizde değişikliği yönetmek ve proje kapsamını etkili bir şekilde belirleyerek, sınırlandırabilmek için gereksinim türleri tanımlamalısınız. Bu türler arasında hiyerarşik bir (detay seviyesi) yapısı olmalıdır.
- [5] Proje Tanımlamaları: Genellikle gereksinim türleri doküman başına belirlenir. Örneğin, Use Case Dokümanları için UC Gereksinimi (UC1, UC2), Ek Gereksinimler Dokümanı için EK Gereksinimler (EK1, EK2, vs.) gibi. Yukarıda görüldüğü gibi ihtiyaç duyulan detay seviyesinde gereksinim tanımlamak da mümkündür.
- [6] Proje Tanımlamaları: Gereksinimlerin, örneğin değişiklerin yönetilmesi amaçlı olarak, kullanılabilmesi için çeşitli değişkenlerinin tanımlanmış olması gerekir.
- [7] Proje Tanımlamaları: Ek Gereksinimler Dokümanının (Supplementary Requirements) bir parçası olan kısıtlamalar ayrı bir işaretleme sistemiyle daha da kontrollü bir şekilde takip edilebilirler.
- [8] Proje Tanımlamaları: Projenizle ilgili olarak ortaya çıkabilecek istenmeyen olayları öngörebilmek için riskleri tanımlamanız gerekir.
- [9] Proje Tanımlamaları: Projenizin gelişimini en etkili şekilde izleyebilmeniz için Ölçme ve Değerlendirme Öğelerini (Metrik) tanımlamanız gerekir.
- [10] Proje Tanımlamaları: Proje gereksinimlerini önceliklendirirken kullanacağız önemli değişkenlerden bir tanesi de onlara yönelik ne kadar emek harcayacağınızdır.
- [11] Proje Tanımlamaları: Bakım ve Test Süreçlerinde problem alanınızı daha kolay daraltmanızı sağlamak için problem türleri tanımlayınız.
- [12] Proje Tanımlamaları: Test süreçlerinizi daha kolay yönetebilmek için Test Türleri tanımlayınız. Bu türleri daha sonra test modelinizde kullanacaksınız.
- [13] Proje Tanımlamaları: Eğer proje ihtiyaçları UML standardıyla tamamen karşılanamıyorsa (Örneğin nesne tabanlı olmayan teknolojilerde kullanılıyorsa: RPG, C vs.) kendi işaretlerinizi (stereotype) belirleyiniz.
- İlham Kaynakları James Bach: http://www.satisfice.com/articles/cmm.htm Murray Cantor: http://www-306.ibm.com/software/rational/bios/cantor.html Watts Humphrey: http://www.sei.cmu.edu/tsp/watts-bio.html Philippe Kruchten: http://philippe.kruchten.com/ Terry Quatrani: http://www-306.ibm.com/software/rational/bios/quatrani.html James Rumbaugh: http://www-306.ibm.com/software/rational/bios/rumbaugh.html Grady Booch: http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=317 Ivar Jacobson: http://www.ivarjacobson.com/html/index.html