Yazılım Geliştirme Süreçleri ve Çevik Yöntemler

Transkript

1 Yazılım Geliştirme Süreçleri ve Çevik Yöntemler Dr. Tolga Ovatman İstanbul Teknik Üniversitesi Bilgisayar ve Bilişim Fakültesi Maslak 20 Mart

2 İçerik Giriş Yazılım Geliştirme Sürecinde Klasik Yaklaşımlar Şelale(Waterfall) Yaklaşımı Artırımlı(Incremental) Yaklaşımlar Spiral Yaklaşım RAD (Rapid Application Development) Çevik Yazılım Geliştirme Süreçleri Extreme Programming Scrum Scrum-ban Sonuç 2

3 Yazılım Geliştirme Yazılım geliştirmek, mühendislik disiplinleri içinde en fazla bireysel etkinlik içeren disiplinlerden biri. Disiplin geliştiği zamanlarda donanım kapasitesinin sınırlı olması nedeniyle daha küçük çaplı ve basit sistemler geliştiriliyordu. Yazılım projeleri yönetimi artık çok daha fazla paydaşın rol oynadığı çok boyutlu problemler haline geldi.

4 YGS Metodolojisi İhtiyacı 2000li yıllarda yazılım endüstrisinin durumu hakkında birçok araştırma yapıldı. The OASIG Study (1995) : Her 10 projeden 7si bir yönden başarısız bulunuyor The Chaos Report (1995): Projelerin %31.1'i tamamlanmadan iptal ediliyor. %52.7'si tahmin edilenin 2 katına maloluyor. The KPMG Canada Survey (1997): İncelenen projelerin %61'i başarısızlıkla sonuçlandı. The Conference Board Survey (2001): Projelerin %40 tamamlandıktan bir yıl sonra işlevini yitiriyor.

5 Yazılım Geliştirme Süreci Parçaları Yazılım geliştirme projeleri aşağıdaki süreçleri içerir Planlama (Analiz-Tasarım) Geliştirme (Kodlama-Test) Montaj ve bakım

6 Yazılım Geliştirme Süreci Riskleri

7 Yazılım Geliştirme Süreci Taksonomisi Model: A praiseworthy example to be copied, with or without modifications. Yazılım yaşam döngüsü modelleri, geçmişten günümüze üç farklı bakış açısından oluşturulmuştur. Programlama bakış açısı: Yazılım geliştirme, fikirlerin doğrudan bir yansımasını üretmektir. Ardışıl işlem bakış açısı: Yazılım geliştirme, problem çözümlemeden çalışabilen koda uzanan bir dönüşüm sürecidir. Keşif çalışmasıbakış açısı: Yazılım geliştirme, problem uzayını keşfetme çabasıdır.

8 Şelale(Waterfall) Yaklaşımı Proje ardışıl fazlara bölünmüştür. Güçlü bir planlama safhası gerekir. Belgeleme ve kontrol çok önemli.

9 Şelale(Waterfall) Yaklaşımı Güçlü yanları: Az tecrübeli proje çalışanları için idealdir. Kalite kontrolü daha rahat biçimde gerçekleştirilebilir. Proje gelişimi daha ölçülebilirdir. Süre kaygısının fazla olmadığı, isterlerin daha açık olduğu büyük projeler için daha uygundur.

10 Şelale(Waterfall) Yaklaşımı Zayıf yanları: Esnek değildir ve maliyeti yüksektir. Proje safhalarına geri dönüş yapılmaz. Öngörünün önemi çok büyüktür. İsterlerin erken ve bir kez belirlenmesini gerektirir. Sistem testlerine kadar problemlerle ilgilenilmez. Belgeleme yükü çok ağırdır. Kullanıcı-geliştirici arası çok açıktır. İsterlerin sabit olmadığı değişime çok açık projelerde kullanılması tavsiye edilmez

11 Artırımlı(Incremental) Yaklaşımlar Yazılımın minimal bir örneği hazırlanır. Her iterasyonda küçük bir şelale ile yazılıma yeni işlevler eklenir. Proje öncesi tüm yazılıma dair isterler hazırlanır.

12 Artırımlı(Incremental) Yaklaşımlar Güçlü yanları: Önceki iterasyonlarda edinilen bilgiler,sonraki iterasyonlarda kullanılabilir. Kilit noktalarda yapılan gözden geçirmelerle orta dereceli bir kontrol sağlanır. Paydaşlara projenin gidişhatıyla ilgili bilgi verme olanağı sağlar. Entegrasyona dayalı ve mimari riskleri az da olsa hafifletir. Artırımlı yöntemler, isterlerin iyi anlaşılmadığı büyük projeler için daha uygundur.

13 Artırımlı(Incremental) Yaklaşımlar Zayıf yanları: İterasyonlar arası geçiş yaparken genelde sistem geneline yönelik kaygılar göz ardı edilir. Bazı modüller diğerlerinden çok daha erken biteceği için arayüzler iyi tanımlanmalıdır. Projeyi iyi gidiyor göstermek için zor problemler geç aşamalara itilir. Kısa sürecek küçük projelerde, entegrasyon riski olmayan veriye dayalı sistemler için kullanılması önerilmez.

14 Spiral Yaklaşım

15 Spiral Yaklaşım Risk yönetimine odaklanmış bir yaklaşımdır. Planlamadan kodlamaya kadar yazılım her parçasının her düzey gelişimi için aynı 4 aşamalı döngüden geçilerek geliştirme sağlanır: İterasyon için amaç, alternatif ve kısıtları belirle Alternatifleri değerlendir, riskleri belirle İterasyon çıktılarını üret Sıradaki iterasyonu planla Her döngüye paydaş amaçlarının belirlenmesi ile başlanıp, gözden geçirme ve devam kararı ile sonlandırılır.

16 Spiral Yaklaşım Güçlü yanları: Riskten kaçınmayı güçlendirir Risklere göre iterasyona uygun olacak metodolojiyi seçme olanağı sunar. Proje yöneticisinin daha deneyimli olduğu durumlarda, riskin yüksek olduğu reaktif sistemlerde tercih edilebilir.

17 Spiral Yaklaşım Zayıf yanları: İterasyona uygun geliştirme metodolojisini seçmek deneyim gerektirir. Döngüler arası geçişler kesin kurallara bağlanmış değildir. Bu yüzden iş yükü çığ gibi büyüyebilir. Döngülerin ilerleyişinde kesin zaman sınırı olmayabilir, bu nedenle bütçe veya zaman aşımı riskleri mevcuttur. Fonksiyonelliğin önemli olduğu, kaynak yönetiminin öncelikli olduğu projelerde kullanılması önerilmez.

18 RAD(Rapid Application Development) Yazılım geliştirme sürecini hızlandırma ana amaçtır. Müşteri tatmini ön plandadır ve süreçte müşteri ile interaskiyon güçlendirilmiştir. İterasyonlar için kesin teslim süreleri belirlenir ve işlerin yetişmemesi durumunda süreyle oynamak yerine, gerçekleştirilecek isterler gözden geçirilir.

19 RAD(Rapid Application Development) Güçlü yanları: İşlevsel bir versiyon çıkarma tarihi önceki metodolojilere göre daha erkendir. RAD ile sistem geliştirme maliyeti de düşer Paydaşları daha rahat içine alan bir yaklaşıma sahiptir. Kullanıcı isteklerine karşı daha esnektir. İsterlere uygunluk daha yüksek oranda sağlanır. Küçük-orta ölçekli projelerde, son kullanıcıya yönelik işlevlerin daha yüksek oranda olduğu projelerde tercih edilir.

20 RAD(Rapid Application Development) Zayıf yanları: Çok hızlanmak kalite düşüklüğüne yol açabilir. Gerekli olandan fazla ister toplanabilir. Sistem içi tutarsız tasarımlar ortaya çıkabilir. Kullanıcılar sürece dahil olmakta zorluk yaşayabilir. Çok büyük, çok karmaşık, sıkı dökümantasyonun istendiği projelerde; kullanıcı değerlendirmesinin mümkün/uygun olmadığı durumlarda kullanılması önerilmez.

21 Çevik Yazılım Geliştirme Süreçleri Method: A process by which a task is completed; a way of doing something. Methodology: A collection of methods, practices, procedures and rules used by those who work in some field.

22 Çevik Yazılım Geliştirme Süreçleri Şubat 2001'de Kent Beck önderliğindeki 17 kişilik bir topluluk tarafından bir manifesto önerildi: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

23 Extreme Programming Kent Beck tarafından öncülüğü yapılmıştır. Bir takım temel değerler, ilkeler ve uygulamalar bütününü önerir.

24 Extreme Programming Öne çıkarılan değerler İletişim Basitlik Geri bildirim Cesaret

25 Extreme Programming Kabul edilen ilkeler: Hızlı geri bildirim: Sistemden testlerle, kullanıcıdan katılımla, takımdan plan oyunlarıyla. Sadeliği benimsemek: En iyi kod işimi gören koddur. Probleme yönelik çözümler azar azar gerçekleştirilmelidir. Değişimi kabullenmek: Değişime karşı koymak yerine, değişimin her zaman olacağını kabullenip onunla yaşamaya alışmak

26 Extreme Programming Önerilen Uygulamalar: Kodlama: Proje kodu her üyeye açık, eşli kodlama tercih ediliyor. (Collective ownership-pair programming) Test: Her kodun mutlaka bir birim testi olmalı, test güdümlü kodlama öneriliyor. (Continous integration) Kullanıcı etkileşimi: Geliştiriciler mutlaka kullanıcılıları dinlemeli, kullanıcılar sürece dahil olmalı. (on-site customer) Tasarım: Yeterli karmaşıklıklar için terih edilmeli, basit ve fonksiyonel olmalı.(user stories)

27 Scrum Yönteme adını koyanlar Jeff Sutherland ve Ken Schwaber, fakat kökenleri Hirotaka Takeuchi and Ikujiro Nonaka'nın rugby yaklaşımına dayanıyor. Temel ilke: The whole process is performed by one cross-functional team across multiple overlapping phases, where the team 'tries to go the distance as a unit, passing the ball back and forth'

28 Scrum Scrumdaki roller Scrum Master Ürün sahibi Takım Sprint: Scrum'ın geliştirme çerçevelerine verilen isim. Her sprint öncesi bir planlama toplantısı, sonrasında ise bir gözden geçirme toplantısı yapılır.

29 Scrum Toplantılar: Günlük scrum toplantısı: En fazla 15 dakika süren, yeri belli toplantılar. Scrumlar scrumı: Her takımdan bir kişinin katıldığı günlük toplantılar. Sprint planlama toplantısı: Sprint backlogları tanımlanır. Tahmin oyunları oynanır. Sprint gözden geçirme toplantısı: Tamamlanan işlerin paydaşlara sunumu yapılır. Sprint retrospektif: Geçen sprintte iyi gidenler ve geliştirilebilecekler konuşulur.

30 Scrum Backloglar: Ürün backlogu Sprint backlogu Backlog erime grafiği

31 Scrum-ban Gerçek Kanban li yıllarda Toyota tarafından önerilmiştir. Günümüzde Scrum-ban şeklinde de anılan varyantları bulunur. Kanban kartları ile üretim-sevk ve satış arası tedarik zinciri JIT prensipleriyle desteklenmektedir. Scrum-ban çok dinamik değişen kullanıcı isteklerine ve ağır bakım isteyen yazılım ürünlerinde kullanılır. Scrum-ban'da sprintler hariç Scrum uygulamaları korunur. Sprintler yerine her programcı her an farklı bir ister üzerine çalışır. İster durumları büyük bir beyaz-tahta üzerinde post-it'lerle temsil edilir.

32 Proje Yönlendirmede Öne Çıkanlar Proje ilerlerken başarılı yönlendirmeler yapmak için aşağıdaki örüntüler öne çıkmaktadır: Kapsam Yönetimi: Spesifikasyonlar da proje ile birlikte evrilir Yönetim esnekliği: Esnekten katıya kayan süreçler kullanılmalıdır. Dürüstlük: Projedeki ilerleme sık kontrol edilir. Kalite kontrol: Testler sürece yayılmalıdır

33 Sonuç

34 Geçmiş ve Günümüz Yazılım projelerinin yönetimi kendine özgü zorlukları olan bir alan. Yazılım projeleri zaman içinde geliştikçe önce daha büyük ve sert proje yönetim çözümleri önerildi Gün geçtikçe çözümlerin daha esnek ve daha az kural tabanlı hale geldiğini görebiliyoruz.

35 Gelecek Projelerde kod yazma zamanının gittikçe geriye çekilmesi bekleniyor. Otomatik kod üreten yazılım fabrikaları konusundaki gelişmeler de bu süreci hızlandırabilir.

36 Teşekkürler Sorularınız ve Yorumlarınız...

37 Kaynaklar - Process Models in Software Engineering, Walt Scacchi, Institute for Software Research, University of California, Irvine February Successful Software Management Style: Steering and Balance, Walker Royce, IBM Software Group - Embracing Change with Extreme Programming, Kent Beck, IEEE Software Iterative and Incremental Development: A Brief History, Craig Larman, Victor R. Basili, IEEE Computer, 2003

38 Şelale(Waterfall) Yaklaşımı Ne dediler? He was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. --Winston Royce, The danger in the waterfall approach is that the project moves from being grand to being grandiose, and exceeds our human intellectual capabilities for management and control. --Harlan Mills,1976 The waterfall model was adopted because software development was guided by DoD standards...in reality, software development is a complex, continuous, iterative, and repetitive process. The waterfall model does not reflect this complexity. --Carolyn Wong, 1980

39 Şelale(Waterfall) Yaklaşımı Ne dediler? Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. --Frederick Brooks, In the decade since the waterfall model was developed, our discipline has come to recognize that development requires iteration between the designers and users. --DoD report,1987

40 Şelale(Waterfall) Yaklaşımı Ne dediler? There are two approaches, evolutionary and single step waterfall, to full capability. An evolutionary approach is preferred.... [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development. --DoD report, 2000