YAZILIM PROJE YÖNETİMİ. Yrd.Doç.Dr.Hacer KARACAN

Transkript

1 YAZILIM PROJE YÖNETİMİ Yrd.Doç.Dr.Hacer KARACAN

2 İçerik Yazılım süreç modelleri (yöntembilimleri) ile ilgili tanımlar Yazılım süreç modeli tanıtımı Çeşitli süreç modelleri Tanımları Kullanım alanları

3 Yüksek kalitede yazılım ürünleri geliştirme için yol haritası yazılım süreci Yazılım süreçleri yazılım mühendisleri ve yöneticilerinin yazılım ürünü geliştirirken ihtiyaçlarını karşılamak için adapte olurlar kolaylıkla kontrolden çıkabilecek aktivitelerin yönetilebilmesi ve gerçekleştirilebilmesi için çerçeve sağlar

4 Süreç (process) nedir? Süreç olguların ya da olayların, belli bir taslağa uygun ve belli bir sonuca varacak biçimde düzenlenmesi, sıralanması. Bir şeyin yapılış, üretiliş biçimini oluşturan sürekli işlemler, eylemler dizisi. Aralarında birlik olan veya belli bir düzen veya zaman içinde tekrarlanan, ilerleyen, gelişen olay ve hareketler dizisi, proses

5 Yazılım süreci nedir? Bir yazılım ürününü üretmeyi sağlayan birbiriyle tutarlı aktivite grubudur Aktivite spektrumu (bandı) Yazılımı baştan geliştirme Piyasada satılan hazır yazılımları yapılandırma ya da tümleştirme

6 Yazılım süreci nedir? Ne yapılmak istendiğini tüm uygulama detaylarına girmeden tanımlar Yazılım süreci bizim yazılım üretme yolumuzdur. * *Kaynak: Object-Oriented and Classical SWE, 7thEdition, Stephen R. Schach, p71.

7 Temel aktiviteler (evreler\fazlar) Yazılım geliştirme süreci için pek çok aktivite vardır. Ama tüm süreçleri için ortak olanlar: Yazılım Belirtimi (Software specification \ Req. Engineering) Yazılım Tasarım ve Gerçekleştirimi (Software design and implementation) Yazılım geçerleme (onaylama) (Software validation) Yazılım gelişimi (Software evolution)

8 Yazılım Belirtimi (Software specification \ Req. Engineering) Ne gibi hizmetler gerekli? Sistemin çalışması ve geliştirilmesi için ne gibi kısıtlamalar var? Süreç fazları: Yapılabilirlik çalışması (Feasibility study) günümüz teknolojisi ile karşılanabilecek mi? Gereksinim ortaya çıkarma ve çözümleme (Requirements elicitation and analysis) var olan sistemden sistem gereksinimlerini çıkarma. Sistem modellerini geliştirme. Gereksinim belirtimi (Requirements specification) Sistem ve kullanıcı isterlerini belgeleme Gereksinim geçerleme (Requirements validation) tamlık (completeness) ve tutarlılığı (consistency) kontrol etme

9 Yazılım Tasarım ve Gerçekleştirimi (Software design and implementation) Sistem belirtimini çalıştırılabilir sisteme çevirme süreci Yazılım Tasarımı Belirtimi gerçekleştirecek yazılım yapısını tasarlama Gerçekleştirim Bu yapıyı çalıştırılabilir programa çevirme Tasarım ve gerçekleştirim aktiviteleri birbirleriyle yakın ilişkilidir ve sırayla da gerçekleştirilebilir.

10 Yazılım Geçerleme (Software validation) Gerçekleme (verification) ve geçerleme (validation), sistemin belirtimlerine uyduğunu ve sistem müşterisinin gereksinimlerini karşıladığını göstermek içindir. Kontrol etme (checking) süreci Gözden geçirme (review) süreci Sistemi test etme (system testing) Sistem testi; sistem tarafından işlenecek gerçek verinin belirtiminden çıkarılarak oluşturulmuş test durumları ile sistemin çalıştırılmasını içerir.

11 Yazılım gelişimi (Software evolution) Yazılım doğası gereği esnek ve değişebilirdir. İşle ilgili şartların değiştikçe gereksinimler de değiştiği için işi destekleyen yazılımın da gelişmesi ve değişmesi gerekmektedir.

12 Yazılım Süreç Modelleri Süreç belirli bir amaç için gerçekleştirilen bir grup aktivite (örn. Gereksinim, yönetim, teslimat) Aktivite belirli bir amacı gerçekleştirmek için bir takıma ya da proje çalışanına atanan bir görev Örn. Gereksinim sürecinde 3 aktivite Yazılım gereksinimleri tanımla ve geliştir Arayüz gereksinimlerini tanımla Yazılım gereksinimlerini önceliklendir ve tümleştir.

13 Yazılım Süreç Modelleri Yazılım süreç modeli, sürecin soyut gösterimidir. Sürecin tanımını farklı bir bakış açısından sunar. Yazılım yaşam döngüsü modeli (Software lifecycle model) Yazılım süreç modeli için kullanılan başka bir isimlendirmedir.

14 Yazılım Süreç Modelleri neden önemlidir? Endüstri kaliteye önem vermektedir. (örn. performans, üretkenlik) Deneyimler göstermektedir ki süreçlerin ürünlerin kalitesine kayda değer etkisi vardır. Ürünlerin istenen kalitede olmasını süreçleri kontrol ederek daha iyi sağlayabiliriz. yönetici ve geliştiricilerin, yazılım geliştirme sürecinin karışıklığı ile baş etmelerini sağlarlar.

15 Yazılım Süreç Modelleri Ürün gereksinimleri SÜREÇ Ürün Kara kutu olarak süreç (hatalı bakış açısı)

16 Yazılım Süreç Modelleri Resmi olmayan (informal) gereksinimler SÜREÇ Ürün Resmi olmayan (informal) gereksinimler ve kara kutu süreci

17 Yazılım Süreç Modelleri Resmi olmayan (informal) gereksinimler SÜREÇ Ürün Geribildirim (feedback) Şeffaf Süreç

18 Özetle... Yazılım Süreç Modelleri Kontrol Tutarlılık Düzen sağlar Karmaşıklığı azaltıp kaosu önler

19 Yazılım yaşam döngüsü

20 Kullanıcı isterleri Her proje mutlaka kullanıcının ortaya koyduğu gereksinimleri karşılamak üzere gerçekleştirilir.

21 İnceleme ve Planlama Her projeye başlamadan önce, kullanıcı isteklerinin karşılanabilmesi için Yapılabilirlik (feasibility ) araştırması yapılır. Her problemin çözümü bilgisayar otomasyonu olmayabilir!

22 Sistem Çözümlemesi Çözümleme yapmak için çeşitli yöntemlerle kullanıcı ortamı modellenir, geliştirme ve davranış modelleri oluşturulur.

23 Sistem Tasarımı (Design) Çözümleme sonucu ortaya çıkan işlev ve isterlerin bir kısmının yazılım ve donanım öğelerine bir kısmının da kullanıcılara paylaştırılmasını içeren aşamadır.

24 Sistemin Gerçekleştirimi (Implementation) Genelde iki ayrı koldan yapılır. Yazılım Donanım

25 Sistem Tümleştirme (Integration) Geliştirilen yazılım öğeleri, geliştirilen veya hazır alınan donanım öğeleri ile tümleştirilir.

26 Sistem Testi Mutlaka sistemin asıl kullanılacağı ortamda yapılan geçerleme (validation) ve gerçekleme (verification) dir.

27 Teslim Bu süreç içerisinde İşletmen eğitimi Donanım bakım eğitimi Yazılım bakım eğitimi İlk kullanım sırasında ortaya çıkan hataların giderilmesi gerçekleştirilir.

28 Bakım (Maintenance) İyileştirici ve düzeltici etkinlikler yer alır. Sistem yaşam çevrimi boyunca devam eder

29 Genel Yazılım Süreç Modelleri (Sadece yazılım geliştirmek için) Kodla ve Düzelt (Code and Fix) Çağlayan Modeli (Waterfall Model) V Modeli (V-shaped Model) Evrimsel Geliştirme (Evolutionary Development) Prototipleme (Prototyping) Spiral Model Formal Sistem Geliştirme (Formal System Development) Matematiksel sistem modeli formal (kurallara uygun) olarak gerçekleştirilir. Yeniden kullanıma yönelik geliştirme (Re-use based development) Sistem var olan bileşenlerden toparlanır Artımlı Geliştirme (Incremental Development) Birleşik Süreç (Unified Process) Uç Programlama (Extreme Programming)

30 Kodla ve Düzelt (Code and Fix) Analiz (Çözümleme) Kod Kod Düzeltme

31 Kodla ve Düzelt - Avantajları Tüm gereken yeterli olacak kadar gayrettir. Tüm adımlardaki gayret direk olarak ürüne katkı sağladığından çoğu müşteri ödeme yapmaktan mutlu olur. Eğer ürün onu yapanlar tarafından kullanılacaksa avantajlıdır.

32 Kodla ve Düzelt - Dezavantajları Kodlamaya başlamadan önce değişiklik tahmin edilmediğinden, birbirini izleyen değişikliklerden sonra kod karmakarışık bir hale gelir ve daha sonraki düzeltmeleri yapmak daha da zorlaşır. Geliştirilen sistemin boyutunun artması, yapısal olmayan bir şekilde karmaşıklığının yönetilmesini zorlaştırır. Müşterinin sürece dahil edilmemesi kullanıcı ihtiyaçlarına uygun olmamasına yol açar. Bireysel geliştiriciler için uygundur, takımlar için değil.

33 Temel Çağlayan Modeli (Royce, 1970) Yazılım Gereksinimi Tasarım Gerçekleştirim Test İşlem ve Bakım

34 Temel Çağlayan Modeli Sonraki faz bir önceki faz tamamlanmadan başlayamaz. Her fazın sonucu bir ya da birden fazla onaylanan (imzalanan) belgedir. Gerektiğinde geliştirme aktivitelerinde iterasyonlar (tekrarlamalar) olabilir.

35 Çağlayan Modeli - Avantajları Müşteriler ve son kullanıcılar tarafından da iyi bilenen anlaşılabilen adımlardan oluşur. İterasyonlar (tekrarlamalar) bir sonraki ve bir önceki adımlarla gerçekleşir, daha uzak adımlarla olması nadirdir. Değişiklik süreci yönetilebilir birimlere bölünmüştür. Gereksinim adımı tamamlandıktan sonra sağlam bir temel oluşur Erken işin miktarını arttırır.

36 Çağlayan Modeli - Avantajları Proje yöneticileri için işin dağılımını yapma açısından kolaydır. Aşamaları iyi anlaşılabilir. Gereksinimleri iyi anlaşılabilen projelerde iyi çalışır. Kalite gereksinimlerinin bütçe ve zaman kısıtlamasında göre çok daha önemli olduğu projelerde iyi çalışır.

37 Çağlayan Modeli Problemleri Problem - 1 Test aşaması geliştirme sürecinin en sonunda yapılır. Hatalar önemli yeniden tasarım gerekliliğini oluşturur. Çözüm 1. Çözümleme aşamasının önüne bir ön-tasarım aşaması eklenir böylece programlama kısıtlamaları önceden anlaşılabilir. 2. Her aşamanın sonunda genişletilmiş belgelendirme yapılır Neden? Erken aşamalarda tasarım= belgelendirme Etkili yeniden tasarıma izin verir Proje ile ortak anlayış

38 Çağlayan Modeli Problemleri Problem 2 Eğer ürün tamamıyla orijinal ise, sistemi yapmadan önce biraz deneysel testlerin yapılması gereklidir Çözüm Bazı anahtar hipotezleri sınamak için prototip yap (Royce un da dediği gibi iki defa yap)

39 Prototip yaptıktan sonra Yazılım Gereksinimi Tasarım Tasarım Gerçekleştirim Gerçekleştirim Test Test İşlem ve Bakım İşlem

40 Çağlayan Modeli Problemleri Problem 3 Önceden anlaşma sağlansa bile yazılımın ne yapacağı konusu yoruma açıktır. Kullanıcılar kaliteyi en sondan önce anlayamazlar Çözüm: Teslim etmeden önce sürece müşteriyi de dahil et. - Gözden geçirmeler

41 Çağlayan Modeli - Diğer dezavantajları Bitirme kriteri olarak belgelendirmeye önem verilmektedir Bazı alanlar için mümkünken (derleyiciler, işletim sistemleri, vb.) etkileşimli son kullanıcı uygulamaları gibi alanlar için zordur. Sistem geliştirilmesi süresince de gereksinimler sıklıkla değişir. Çağlayan modeli gereksinimlerin çok iyi anlaşılabildiği durumlarda kullanılmalıdır. İki ya da daha önceki fazlara gitmek çok maliyetlidir bu durumda da gerektiğinde tüm fazı yeniden gerçekleştirmek çok büyük bir iştir. Bir faz tamamlanmadan diğerine geçilememesi riski arttırır.

42 V Modeli Proje ve gereksinim planlaması Ürün gereksinimleri ve belirtim çözümlemesi Mimari ve yüksek seviye tasarım Detaylı tasarım Kodlama Birim testi Tümleştirme ve test Sistem ve kabul edilme testleri Üretim, işletim ve sürdürülebilirlik

43 V Modeli

44 V Modeli - Avantajları Verification ve validation planları erken aşamalarda vurgulanır Verification ve validation sadece son üründe değil tüm teslim edilebilir ürünlerde uygulanır. Proje yönetimi tarafında takibi kolaydır Kullanımı kolaydır

45 V Modeli - Dezavanatjları Aynı zamanda gerçekleştirilebilecek olaylara kolay imkan tanımaz Fazlar arasında tekrarlamaları kullanmaz Risk çözümleme ile ilgili aktiviteleri içermez

46 Yazılım da diğer sistemler gibi zamanla evrimleşir Geliştirme devam ettikçe iş ve ürün gereksinimleri de değişkenlik gösterebilir Son ürüne ulaşma düz bir çizgi ile ifade edilemez

47 Evrimsel Geliştirme (Evolutionary Development) Anahat gereksinimleri ile başlangıç sistemi geliştirilir. Müşteri geribildirimi ile sitem pek çok versiyonla yavaş yavaş geliştirilir. Belirtim (specification), geliştirme ve geçerleme (validation) aktivitleri koşut zamanlı yürütülür.

48 Evrimsel Geliştirme Koşutzamanlı Aktiviteler Belirtim Başlangıç versiyonu Ana hat Tanımı Geliştirme Ara versiyonlar Geçerleme Son versiyon

49 Evrimsel Geliştirme (Modeli) İki çeşit evrimsel geliştirme vardır: Keşifçi geliştirme (exploratory development) Hedef: Müşterinin gereksinimlerini incelemek için müşteri ile çalışıp son sistemi teslim etmek İyi anlaşılan gereksinimlerle başlanmalıdır Ne istediğimi sana söyleyemem ama onu gördüğümde bilirim Atılacak prototipleme (throw-away prototyping) Hedef: Sistem gereksinimlerini anlamak Tam anlaşılmamış gereksinimlerle başlar

50 Karşılaştırma Çağlayan modeli Evrimsel geliştirme zaman

51 Evrimsel Geliştirme - Avantajları Kullanıcıların kendi gereksinimlerini daha iyi anlamalarını sağlar Sürekli değerlendirme erken aşamalardaki geliştirme risklerini azaltır Hatalar azalır

52 Evrimsel Geliştirme - Problemler Sürecin görünürlüğü azdır (düzenli teslim edilebilir ürün yoktur) Sistemler sıklıkla iyi yapılandırılmaz (sürekli değişiklik yazılımın yapısına zarar verir) Bakımı zordur Yazılım gereksinimini yenilemek gerekebilir

53 Evrimsel Geliştirme - Uygulanabilirliği Küçük ve orta boyutlu etkileşimli sistemler ( LOC dan daha az olan) Büyük bir sistemin parçaları (örn. Kullanıcı arayüzleri) Kısa süreli kullanılacak sistemler

54 Prototipleme Gereksinim tanımlama fazında hızlıca yapılan kısmi gerçekleştirme Gereksinimler netleştikçe prototipi düzelt Müşteri memnun olana kadar düzeltmelere devam et

55 Prototipleme Communicat ion İletişim Hızlı plan Qu ick p lan Mo d e lin g Modelleme Qu ick d e sig n Hızlı tasarım Deployment Kurulum, De live ry teslimat ve & Fe e dback geribildirim Const ruct ion Prototip of prot yapımı ot ype

56 Prototipleme - Avantajları Kullanıcı sistem gereksinimlerini görebilir Karmaşa ve yanlış anlaşılmaları engeller Yeni ve beklenmeyen gereksinimler netleştirilebilir Risk kontrolü sağlanır

57 Prototipleme - Dezavantajları Belgelendirmesi olmayan hızlı ve kirli (quick and dirty) prototipler Prototip hedefleri net değilse kod hackleme ya da jenga başlar Düzeltme aşaması atlanırsa, düşük performansa yol açar Müşteri prototipten de son ürün gibi görünüm ve etki bekler.

58 Yazılım sürecinde Spiral model Hedefler, alternatifler ve kısıtlamalar belirlenir Alternatifler değerlendirilir, riskler belirlenip çözülür Aşamanın ürünü geliştirilir Sonraki faz planlanır

59 Spiral geliştirme Süreç arka arkaya devam eden sıralı aktiviteler şeklinde gösterilmek yerine spiral şekilde gösterilir. Spiral üzerindeki her bir halka bir fazı gösterir Belirtim, tasarım gibi kesin fazlar yoktur spiral deki halkalar neye ihtiyaç varsa onu gerçekleştirmek için seçilir. Süreç boyunca risklerin değerlendirilmesi ve çözümü açık olarak yapılır

60 Spiral model Hedef belirleme Fazlar için özel hedefler belirlenir Risk değerlendirme ve azaltma Riskler değerlendirilir ve ana riskleri azaltmak için aktiviteler gerçekleştirilir. Geliştirme ve geçerleme Sistem için genel geliştirme modellerinden biri seçilir Planlama Proje gözden geçirilir ve sonraki faz için plan yapılır.

61 Spiral model - Avantajları Kullanıcılar sistemi erken görebilirler Geliştirmeyi küçük parçalara böler. En riskli kısımlar önce gerçekleştirilir. Pek çok yazılım modelini içinde bulundurur. Riske duyarlı yaklaşımı potansiyel zorlukları engeller Seçeneklere erken dikkate odaklanır Hataları erken gidermeye odaklanır Yazılım-donanım sistemi geliştirme için bir çerçeve sağlar

62 Spiral Model - Problemler Küçük ve düşük riskli projeler için pahalı bir yöntemdir Komplekstir (karmaşık) Spiral sonsuza gidebilir Ara adımların fazlalılığı nedeniyle çok fazla dokümantasyon gerektirir. Büyük ölçekte projeler Kontrat tabanlı yazılıma uymaz Yazılımın içten geliştirileceğini varsayar Kontrat tabanlı yazılımlar adım adım anlaşma esnekliğini sağlamaz Öznel risk değerlendirme deneyimine dayanır Yüksek riskli öğelere yoğunlaşmak, yüksek riskli öğelerin doğru belirlenmesini gerektirir.

63 Formal Sistem Geliştirme (Formal System Development) Cleanroom yazılım geliştirme Matematiksel belirtimin farklı gösterim şekilleri ile çalıştırılabilir programa dönüştürülmesine dayalıdır. Formal belirtim, tasarım ve geçerleme kullanarak yazılımda doğruluğun geliştirilmesini vurgular. Yazılım artımlarla geliştirilir. Sürekli tümleştirme vardır ve fonksiyonellik tümleştirilen yazılım artımları ile artar. Felsefesi pahalı hata ayıklama işlemini engellemek için kodu ilk yazarken doğru yazmak ve test aşamasından doğruluğunu sağlamak Formal yöntemler Z dili

64 Formal Sistem Geliştirme Problemleri Teknikleri uygulayabilmek için eğitim ve özel beceriler gerekmektedir Kullanıcı arayüzü gibi sistemin bazı kısımlarını formal olarak belirtmek zordur Uygulanabilirliği Sistem kullanıma konmadan emniyet ve güvenlik durumlarını sağlanması gereken kritik sistemler

65 Yeniden kullanıma yönelik geliştirme (Re-use based development) Bileşene dayalı yazılım mühendisliği Sistemlerin var olan bileşen ya da ticari sistemlerin tümleştirildiği sistematik yeniden kullanıma dayalıdır. Süreç adımları Bileşen analizi Gereksinim değişikliği Yeniden kullanım ile sistem tasarımı Geliştirme ve tümleştirme Bu yaklaşımın önemi artmaktadır ama halen kullanımı limitlidir.

66 Yeniden kullanıma yönelik geliştirme Gereksinim belirtimi Bileşen çözümleme Gereksinim düzeltimi Yeniden kullanımla sistem tasarımı Geliştirme ve tümleştirme Sistem geçerleme

67 Süreç tekrarı Tüm büyük sistemler için değişim kaçınılmazdır. Son artıma (increment) kadar tam sistem belirtimi yapmak mümkün değilse ne olacak? Süreç tekrarı için iki süreç modeli Spiral geliştirme Artımlı geliştirme (incremental development)

68 Artımlı Geliştirme (Incremental Development) Sistemi tek bir parça olarak en sonda teslim etmektense, sistem, her biri sistemin ayrı bir istenen işlevini yerine getirecek artımlara (increments) bölünür Kullanıcı gereksinimleri önceliklendirilir, ve yüksek öncelikli gereksinimler ilk artımlar arasında gerçekleştirilir. Bir artımın geliştirilmesine geçilince diğer artımlar için gereksinim gelişimi devam etse bile o artım için olan gereksinimler dondurulur.

69 Artımlı Geliştirme Ana hat gereksinimler tanımlama Gereksinimler artımlara atanma Sistem mimarisi tasarlama Sistem artımları geliştirme Artım geçerleme Artım tümleştirme Sistem geçerleme Son sistem Tamamlanmamış sistem

70 Artımlı Geliştirme Aslında çağlayan modelinin örtüşen şekilde uygulanmasıdır

71 Artımlı Geliştirme - Avantajları Sistem için gerekli olan gereksinimler müşterilerle belirlenir Gereksinimlerin önemine göre teslim edilecek artımlar belirlenir Öncelikle en önemli gereksinimleri karşılayan çekirdek bir sitem geliştirilir. Erken artımlar prototip gibi davranarak, gereksinimlerin daha iyi anlaşılmasını sağlar Tüm projenin başarısız olma riskini azaltır En önemli sistem özellikleri daha fazla sınanma (test edilme) imkanı bulmuş olur. Divide and Conquer (Böl ve Yönet) yaklaşımıdır

72 Artımlı Geliştirme Çağlayan modeli ve evrimsel geliştirme arası bir model:

73 Artımlı Geliştirme - Dezavantajları Artımları tanımlamak için tüm sistemin tanımlanmasına ihtiyaç vardır Gereksinimleri doğru boyuttaki artımlara atamak bazen zor olabilir. Deneyimli personel gerektirir Artımların kendi içlerinde tekrarlamalara izin vermez

74 Alternatif Yaklaşımlar Ticari olarak etkinlikleri kanıtlanmış yazılım iyi pratiklerinde: Yazılımın tekrarlı geliştirilmesi Gereksinimlerin yönetimi Bileşene dayalı mimari kullanımı Yazılımı görsel olarak modelleme Yazılım kalitesini doğrulama Yazılıma yapılan değişiklerin kontrolü vurgulanmaktadır.

75 Birleşik Süreç (Unified Process) Nesneye dayalı yazılım geliştirmek için var olan yöntemlerin deneyimler sonucu kabul gören en iyi özellikleri bir araya getirilerek tümleştirilmiş yazılım geliştirme süreci (The Unified Process - UP) oluşturulmuştur. 75

76 UP: Yinelemeli ve evrimsel yazılım geliştirme Her yineleme (iterasyon) adımında bütün bir yazılım projesi varmış gibi davranılır. Gerekli tüm aşamalardan geçilerek sınanmış, çalışır bir ürün elde edilir. 76

77 Yinelemeli Sürecin Yararları 77

78 UP'nin Kullanılmasına Yönelik Öneriler 2-6 haftalık sabit süreli iterasyonlar uygulanmalı Deneyemlere göre bir iterasyonun süresinin 3 ya da 4 hafta olarak seçilmesi iyi sonuçlar vermektedir. İterasyon 2 haftadan kısa olursa bu sürede bir ürün çıkarmak mümkün olmaz. Altı haftadan daha uzun süreli iterasyonlarda ise erken geri besleme alma olanağı ortadan kalkar ve çok fazla sayıda istek ile uğraşmak gerekir. Yüksek risk taşıyan kısımlar ilk iterasyonlarda gerçeklenmeli Daha önce de açıklandığı gibi ortaya çıkabilecek problemleri mümkün olduğu kadar erken fark edip bunlara karşı önlem alabilmek için zorlu görünen istekler önce ele alınmalı. Temel oluşturan yapılar (çekirdek) önce gerçeklenmeli Yüksek riskli kısımlardan başka önce ele alınması gereken modüller sistemin temelini (iskeletini) oluşturan yapılardır. 78

79 UP'nin Kullanılmasına Yönelik Öneriler Sürekli kullanıcılardan geri besleme alınmalı, isteklere uyulmaya dikkat edilmeli Her iterasyondan sonra ürün tam olarak sınanmalı Her iterasyonda bir ürün oluşturulduğu unutulmamalı ve bu ürün tam olarak sınanmalıdır. Aksi durumda hatalar geç fark edilir ve bunları düzeltme maliyeti yüksek olur. Kullanım senaryoları yöntemi (use case) uygulanmalı Görsel modelleme (UML) kullanılmalı UML tasarımların ifade edilmesini ve takım elemanları arasında iletişimi kolaylaştırır. Bir iterasyonda elde edilen deneyim diğer iterasyonda kullanılmalı 79

80 Çevik Modeller Çevik yöntemler heavyweight olarak da adlandırılan yavaş ve bürokratik yöntemlere tepki olarak geliştirilmiştir. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kaynak: (Agile Alliance,

81 Çevik Manifesto - Prensipler En önemli önceliğimiz müşteriyi değerli yazılımı erken zamanda ve sürekli bir şekilde sunarak memnun etmektir. Geliştirme sürecinde son zamanlarda da gelse değişen gereksinimler hoş karşılanmalıdır. Çevik süreçler değişimi müşterinin rekabetçi avantajı için kullanırlar Çalışan yazılım bir iki haftadan bir iki aya kadar, mümkün olan en kısa sürelerde sunulmalıdır. Geliştiriciler ve iş insanları proje boyunca beraber çalışmalıdırlar.

82 Çevik Manifesto - Prensipler Projeleri motivasyonu yüksek bireylerin çevresinde geliştirilmelidir. Onlara ihtiyaçları olan destek ve ortamı sağlayın ve işi yapabileceklerine güvenin. Bilginin takımlar içerisinde ya da takımlar arasında en iyi paylaşılması ve anlaşılmasının yolu yüz yüze iletişimdir. İlerlemenin en iyi göstergesi çalışan yazılımdır Çevik süreçler sürüdürülebilir geliştrime sağlar.sponsorlar, geliştiriciler ve kullanıcılar sabit hızlarını sonsuz şekilde koruyabilirler

83 Çevik Manifesto - Prensipler Teknik mükemmellik ve iyi tasarıma verilen sürekli önem çevikliği arttırır. Basitlik önemlidir. (Yapılmaması gereken tüm işleri önlemek) En iyi mimari, gereksinimler, ve tasarımlar kendi kendilerine organize olabilen takımlardan çıkar Düzenli aralıklarla, takımlar nasıl daha etkili olacaklarına bakar, davranışlarını düzenler ve ona göre hareket eder.

84 Uç Programlama (Extreme Programming) Çevik yöntem Tüm gereksinimler senaryolar şeklinde oluşturulur. Daha sonra senaryolar işlere bölünür. Yazılımcılar çiftler halinde çalışır ve her iş için test de geliştirir. İşleri sonra tümleştirir Sistemin müşterisi de geliştirici takımın devamlı bir parçasıdır

85 Uç Programlama (XP)

86 Uç Programlama Bazı özellikleri Takımın bilgisayarları kübiklerle bölünmüş büyük bir odanın ortasında yer alır Bir müşteri temsilcisi geliştirici takımlarla devamlı beraber çalışır Hiç kimse aynı iş için peşpeşe iki haftadan fazla çalışamaz Takım içerisinde özelleşme yoktur. Herkes belirtim, tasarım, kodlama ve test aşamalarında görev yapar. Parçalar geliştirilmeden önce ayrı büyük bir tasarım aşaması yoktur. Onun yerine parçalar geliştirilirken tasarım da değiştirilir Küçük ve orta ölçekli projelerde kullanılırlar Kullanıcın gereksinimleri belirsiz ya da değişkense kullanışlıdırlar.

87 Diğer çevik modeller Adaptive Software Development (ASD) Dinamik Sistem Geliştirme Yöntemi SCRUM CRYSTAL Feature-driven development (Özelliğe yönelik geliştirme)

88 Yazılım Süreç Modeli Seçimi Yazılım süreç modelleri birbirinden tümüyle ayrı değildir ve çoğu zaman aslında beraber kullanılırlar Hangi modelin ve model içerisindeki hangi adımların gerçekleştirileceğini seçmekle görevli olan kişiye süreç mimarı denir. Her modelin güçlü ve zayıf yanlarını değerlendirdikten sonra süreç mimarı proje için en iyi modeli seçmelidir.

89 Yazılım Süreç Modeli Seçimi Süreç modeli seçiminde yararlı olabilecek bazı kriterler Modelin oluşabilecek riskleri tolere edebilme kapasitesi Geliştirici kurumun son kullanıcılara erişim imkanı Bilinen gereksinimlerin ne kadar iyi tanımlanabildiği Erken işlevlerin önemi Problemin karmaşıklığı ve çözüm için olası adaylar Gereksinim değişikliğinin tahmin edilen sıklığı ve oranı Kurumun yönetimsel kapasitesi

90 Tartışma İdeal süreç modeli var mıdır?

91 Tartışma Kurumun yapısına Projenin büyüklüğüne Projenin karmaşıklığına Kontratın tipine. dayalıdır.

92 Yazılım Süreçleri IEEE/EIA nedir? Bilgi Teknolojileri-Yazılım Yaşam Döngüsü Süreçleri için Standard Bir yazılım sisteminin tüm yaşam döngüsünü kapsayan süreçler kümesini tanımlar Kavramsal fikrin ortaya çıkışından Yazılımın emekli oluşuna kadar Yazılım süreç modelleri için ortak bir çerçeve sağlar

93 Yazılım Süreçleri IEEE/EIA nedir? Bir organizasyon kendi iç kullanımı için ya da birden çok organizasyon kontrata bağlı çalışmak için kendine adapte edebilir Projeye göre uydurulabilir Genel, büyük ve karmaşık projeler için yazılmıştır İhtiyaç, büyüklük, karmaşıklık, maliyet, zaman ve performansa uydurulabilecek şekilde tasarlanmıştır. Uygulamalar için bir kılavuzdur

94 12207 ne değildir? Yazılım geliştirme için bir reçete değildir Yönetim ya da mühendisliğin yerine geçmez Ürün ya da ölçme standardı da değildir

95 Kullanımı Birincil yaşam döngüsü süreçleri: Acquire, supply, develop, operate, and maintain software Yazılım kazanma, tedarik, geliştirme, işletim ve sürdürme Destekleyici yaşam döngüsü süreçleri: Yukarıdaki fonksiyonları, kalite güvencesi, konfigürasyon yönetimi, ortak gözden geçirme, denetleme, geçerleme, doğrulama, problem çözme ve belgelendirme ile destekler. Kurumsal yaşam döngüsü süreçleri: Organizasyonun süreçleri ve personelini yönetmesini ve geliştirmesini sağlar Yazılım ürün yaşam döngüsünde yer alan müşteri, sağlayıcı ve tüm iştirakçiler arasında anlaşmayı artırır

96 Yaşam döngüsünü bölümlendirme Modularity (modülerlik) Strongly cohesive (güçlü bağlı): süreç içindeki işler (task) fonksiyonel olarak birbirine bağlı olmalı Loosely coupled (zayıf birleşme) Süreçler arasındaki bağlar en az olmalı Association rules (İlişkilendirme kuralları) Bir fonksiyon birden fazla süreç tarafından kulanılıyorsa, o durumda fonksiyon kendi başına bir süreç haline gelir Eğer süreç A sadece ve sadece süreç B tarafından çağrılıyorsa, süreç A B ye aittir Sorumluluk Bir süreç yazılım yaşam döngüsündeki bir organizasyon ya da bir tarafın sorumluluğuna verilir Parçaları farklı organizasyonların sorumluluğunda olan fonksiyonlar süreç olamaz

97 IEEE/EIA Yaşam Döngüsü (Yazılım Süreçleri)

98 Uygulama Bir BS organizasyonunda proje yöneticisi olarak görevlendirildiniz. İşiniz daha önce geliştirdiklerinize benzer bir sistem geliştirmek olan sözleşmeli bir projeyi yönetmek. Yalnız bu defaki proje daha öncekilere göre daha büyük ve daha karmaşık. Gereksinimler müşteri tarafından baştan sona belgelendirilmiş. Hangi süreç modelini kullanırsınız? Neden?

99 Uygulama Bir BS organizasyonunda proje yöneticisi olarak görevlendirildiniz. İşiniz daha önce geliştirdiklerinize benzer bir sistem geliştirmek olan sözleşmeli bir projeyi yönetmek. Yalnız bu defaki proje daha öncekilere göre daha büyük ve daha karmaşık. Gereksinimler müşteri tarafından baştan sona belgelendirilmiş.

100 Referanslar Buzluca, F. (2010) Yazılım Modelleme ve Tasarımı ders notları ( Demirörs, O. (2003) IS 507 Lecture Notes Kalıpsiz, O., Buharalı, A., Biricik, G. (2005). Bilgisayar Bilimlerinde Sistem Analizi ve Tasarımı Nesneye Yönelik Modelleme. İstanbul: Papatya Yayıncılık Sarıdoğan, E. (2004) Yazılım Mühendisliği, İstanbul: Papatya Yayıncılık Sevgi, C. (2007). CTIS 359 Lecture Notes. Durdu, P. (2009). BIL 320 Lecture Notes.