Artan Yaklaşım adımların belirli sayıda kullanır ve geliştirme ilerlemesi doğrusal yolundaki baştan sona gider.
Artımlı geliştirme, tasarım, uygulama, test / doğrulama, bakımdan adımlarla yapılır. Bunlar alt adımlara ayrılabilir, ancak artımlı modellerin çoğu aynı modeli izler. Şelale Modeli geleneksel artan gelişme yaklaşımdır.
İteratif Yaklaşım adımların belirlenmiş numarası vardır, daha doğrusu geliştirme döngüleri yapılır.
Yinelemeli gelişim, bireysel özelliklerin ilerlemesini izlemekle daha az ilgilidir. Bunun yerine, önce çalışan bir prototip oluşturmaya ve Artırma Geliştirme adımlarının her döngü için yapıldığı geliştirme döngülerinde özellikler eklemeye odaklanır. Çevik Modelleme tipik bir yinelemeli yaklaşımdır.
Artımlı model ilk olarak fabrikalarda kullanılan geleneksel montaj hattı modelini takip etmek için geliştirilmiştir. Ne yazık ki, yazılım tasarımı ve geliştirilmesinin fiziksel mal üretimi ile çok az ortak noktası vardır. Kod, geliştirmenin bitmiş ürünü değil, plan. İyi tasarım seçimleri geliştirme sürecinde sıklıkla 'keşfedilir'. Geliştiricileri uygun bağlam olmadan bir dizi varsayımlara kilitlemek, en iyi durumda kötü tasarımlara veya en kötüsündeki gelişimin tamamen raydan çıkmasına neden olabilir.
Yinelemeli yaklaşım artık yaygın bir uygulama haline geliyor çünkü yazılım geliştirmedeki doğal ilerleme yoluna daha iyi uyuyor. Varsayımlara dayalı 'mükemmel tasarımı' kovalamak için çok fazla zaman / çaba harcamak yerine, yinelemeli yaklaşım, tamamen başlamak için 'yeterince iyi' bir şey yaratmak ve kullanıcının ihtiyaçlarına uyacak şekilde gelişmektir.
tl; dr - Artımlı Model altında bir deneme yazıyorsanız, o anda bir cümleyi bitirmek için baştan mükemmel bir şekilde yazmaya çalışacaksınız. Yinelemeli Model altında yazdıysanız, hızlı bir kaba taslak patlatır ve bir dizi revizyon aşamasıyla geliştirmeye çalışırsınız.
Güncelleme:
'Artımlı Yaklaşım' tanımımı daha pratik bir örneğe uyacak şekilde değiştirdim.
Eğer herhangi bir sözleşme ile uğraşmak zorunda kalsanız, Artan Yaklaşım çoğu sözleşmenin (özellikle ordu için) nasıl yapıldığını gösterir. Tipik 'Şelale Modeli'nin birçok ince varyasyonuna rağmen, çoğu / hepsi pratikte aynı şekilde uygulanır.
Adımlar aşağıdaki gibidir:
- Sözleşme ödülü
- Ön Tasarım İncelemesi
- Kritik Tasarım İncelemesi
- Şartname Dondur
- gelişme
- Fielding / Entegrasyon
- Doğrulama
- Güvenilirlik Testi
PDR ve CDR, spesifikasyonun oluşturulduğu ve revize edildiği yerdir. Spec tamamlandıktan sonra, gereken kapsam sünme önlemek için dondurulmuş. Yazılım, önceden var olan bir sistemi genişletmek için kullanılırsa tümleştirme gerçekleşir. Doğrulama, uygulamanın spesifikasyonla eşleşip eşleşmediğini kontrol etmek içindir. Güvenilirlik, uygulamanın uzun vadede güvenilir olacağını kanıtlayan bir testtir, bu, sistemin belirli bir çalışma süresini (3 ay boyunca% 99 çalışma süresi) sürdürmesi gereken bir SLA (Hizmet Düzeyi Sözleşmesi) gibi belirtilebilir. ).
Bu model, kağıt üzerinde belirtilmesi kolay ancak üretimi zor olan sistemler için harika çalışır. Yazılımın kağıt üzerinde kayda değer herhangi bir ayrıntı derecesine (UML'den) belirtilmesi çok zordur. Yönetim / sözleşme sorumlu Çoğu 'işletme türleri' gerçekleştirmek için başarısız - bu yazılım geliştirme konusunda - Kod kendisi olduğunu Spec. Kağıt özellikleri genellikle kodun kendisi kadar yazmak için daha fazla veya daha fazla zaman / çaba gerektirir ve genellikle pratikte eksik / daha düşük olduğunu kanıtlarlar.
Artımlı yaklaşımlar, kodun kendisini şartname olarak ele alarak boşa harcanan zamanı / kaynakları dener. Kağıt spesifikasyonunu birden fazla revizyon adımında çalıştırmak yerine, kodun kendisi birden fazla revizyon döngüsünden geçer.