Şelale (kademeli) modeli. Basamaklama yöntemi teriminin geçtiği sayfalara bakın

Farklı proje yönetimi metodolojilerinin olduğunu biliyor muydunuz? Her biri tüm ana çalışma döngülerini içerir:

• Gereksinim geliştirme
• Planlama
• Tasarım
• Kodlama
• Test yapmak
• Optimizasyon.

Bugün bunlardan ikisinden bahsedeceğiz. Projelerimizde aktif olarak kullandığımız ikisi. Okuyoruz, analiz ediyoruz, seçiyoruz. İşte iki metodolojinin karşılaştırması: Çevik ve Şelale.

Atik

Bu metodoloji 12 prensibe (sözde Çevik Manifesto) dayanmaktadır. Agile'ın temel pratik ilkelerine bir göz atalım:

• Müşteri, geliştirmenin herhangi bir aşamasında gereksinimlerini değiştirebilir veya ayarlayabilir.
• Ekip etkinliğinin en iyi göstergesi çalışan bir çözümdür.
• İletişimin en verimli yolu kişisel iletişimdir.
• Ürünün yeni sürümleri her yinelemeden sonra veya birkaç ayda bir (projeye bağlı olarak) yayınlanır.

2015 yılında geniş çaplı bir mesleki çalışma yapıldı. 601 bilişim projesini hedef aldı. Sonuç, Agile'ın günümüzde proje yönetimine yönelik en yaygın yaklaşım olduğunu gösterdi.

Çevik: faydalar

• Birkaç yinelemeden geçtikten sonra bile bir projeyi tamamen yeniden yapabilme yeteneği.

• Proje kısa ve şeffaf bölümlere (yinelemelere) bölünmüştür; Scrum'da bunlara sprint denir.

• Agile'ın esnekliği olası tüm riskleri minimuma indirir.

• Çevik, MVP gelişimi için idealdir.

Çevik: dezavantajları

• Proje bütçesinin hesaplanması, sürekli değişen gereksinimler nedeniyle önemli ölçüde karmaşıktır.
• Geliştirme ekibinin yalnızca yüksek nitelikli olması değil aynı zamanda müşteri odaklı da olması gerekir.
• Yeni gereksinimler sıklıkla mevcut proje mimarisiyle çelişir.
• İhtiyaçlarda sürekli ayarlamalar yapmak bazen projenin hiçbir zaman bitmeyeceği hissine yol açabilir :)

Şelale

Şelale metodolojisi tutarlı gelişim ilkesine dayanmaktadır. Kısaca proje yönetimi akış şeması şuna benzer:

1. Gereksinimlerin analizi
2. Planlama
3. Uygulama
4. Test ve optimizasyon
5. Dağıtım
6. Destek

Sonraki her adıma geçiş ancak önceki aşamanın tamamlanmasından sonra mümkündür. Aynı zamanda, proje dağıtıldıktan ve tüm hatalar giderildikten sonra yeni işlevsellik getirilmesine izin verilir.

Şelale: faydaları

• Açık ve mantıksal yönetim yapısı (çok az deneyimi olan ekipler için bile harika).
• Tutarsızlıklara ve yanlış yorumlamalara izin vermeyen harika belgeler.
• Kaynakları, zamanı ve olası riskleri kolayca takip etmenizi sağlar.
• Geliştiriciler için sabit miktarda görev.

Şelale: dezavantajları

• Şelale, gereksinimleri ayarlama yeteneği anlamına gelmez; yeterince esnek değildir.
• Waterfall, Agile'a göre daha fazla zaman ve kaynak gerektirir.
• Projenizi ancak yayınlandıktan sonra “deneyebilirsiniz”. Geliştirme sürecinde işlevselliğin değiştirilme olasılığı yoktur.
• Müşteri ve geliştirme ekibi arasındaki etkileşim minimum düzeydedir.

Ne seçeceksin?

Aşağıdaki durumlarda çevik sizin seçiminizdir:

• Deneyimli bir geliştirme ekibiniz var.
• Ürünün nihai işlevselliği hakkında kesin bir fikriniz yok.
• Projede yapılacak değişiklikler mümkün olan en kısa sürede hayata geçirilmelidir.
• Gelişimi boyunca projeye aktif olarak dahil olmak istiyorsunuz.
• Çalışan bir ürünü olabildiğince çabuk teslim etmeniz gerekiyor.
• Sen bir startupsın.

Aşağıdaki durumlarda seçiminiz Şelale'dir:

• Proje gereksinimlerinizin değişmesi pek olası değildir.
• Ürünün kalitesi, ona yatırım yapmak istediğiniz zaman ve kaynaklardan çok daha önemlidir.
• Gelişimin her aşamasından sonra ara sonuçları gözlemlemekle pek ilgilenmiyorsunuz ve projede aktif rol almak için çaba göstermiyorsunuz.

Ve son olarak istatistiklere bakalım. Agile kullanılarak teslim edilen projelerin başarılı olma ihtimalinin, Şelale metodolojisi kullanılarak yönetilen projelere göre üç kat daha fazla olduğunu gösteriyor.

Çevik ve Şelale: Sonuç

Proje yönetimi için asla sihirli bir değnek bulamazsınız. Gelişimin tüm aşamalarını mükemmel bir şekilde düzene koyabilecek ve olası tüm riskleri dengeleyebilecek bir metodoloji ancak hayalde mevcuttur. Şelalenin en büyük dezavantajı esnekliğinin olmamasıdır. Bu metodolojiyi kullanarak geliştirme süreci sırasında proje gereksinimlerini değiştiremezsiniz. Ve modern pazardaki mevcut koşullara uyum sağlama yeteneği büyük bir artı.

Ancak bu, Şelalenin kötü olduğu ve unutulması gerektiği anlamına gelmez. Küçük projeler için harikadır. Peki, Agile ve Waterfall'ı tek bir projede yetkin bir şekilde birleştirmeyi öğrenirseniz, bu yeni ufuklar açacak ve birçok ilginç fırsat sağlayacaktır.

Yazılım geliştirme metodolojisi - ideolojik ilkeler, plan, süreçler üzerinde kontrol, çalışanlara yaklaşım dahil olmak üzere işin organizasyonu. 12 türü vurgulayalım:

• Şelale geleneksel bir yaklaşımdır.
• RUP (Rasyonel Birleşik Süreç) - rasyonel.
• Çevik genel bir esnek geliştirme metodolojisidir.
• Crystal Clear, bir ekipteki geliştiricileri eşitlemeye yönelik bir yaklaşımdır.
• Spiral - spiral yöntemi.
• DSDM (Dinamik Sistem Geliştirme Modeli) dinamik bir modeldir.
• FDD (Özellik Odaklı Geliştirme), gelecekteki değişiklikleri dikkate alan bir metodolojidir.
• JAD (Ortak Uygulama Geliştirme) kullanıcı merkezli bir yaklaşımdır.
• RAD (Rapid Application Development) hızlı bir geliştirme modelidir.
• Scrum, kaçırılmış teslim tarihleri ​​ve ideolojik kriz koşullarında çalışma kavramıdır.
• XP (Ekstrem Programlama) - dinamik bir ortamda olağanüstü gelişme.
• LD (Yalın Gelişim), süreçteki tüm katılımcıların dikkatli bir şekilde ele alınmasını içeren bir yöntemdir.

Bu İngilizce isimlerin arkasında neyin saklı olduğunu bulmaya çalışalım.

Şelale

Şelale modeli klasik yazılım geliştirme anlayışına aittir. Tüm süreç katı ve doğrusaldır, her aşama için net hedefler vardır, bir öncekinin tamamlanmasıyla yeni bir aşama başlar, geri dönüş yoktur. Şelale metodolojisinin avantajları, merkezi olmayan yönetim ve yürütmenin zamanlaması ve kalitesi üzerinde sıkı kontroldür.

Uygulamada Waterfall, dinamik değişiklikleri göz ardı ettiği için çoğu zaman beklentileri karşılayamıyor. Bu nedenle, testten sonra süreci geri almak ve geliştirme aşamasında dikkate alınmayan işlevleri eklemek çok zordur. Şelale aynı zamanda etkisizdir çünkü bir proje çerçevesinde çalışanlar için geçici kesinti anlamına gelir. Testler yalnızca geliştirmenin sonunda gerçekleştirilir, ancak bu aşamada bulunan sorunların düzeltilmesi pahalıdır.

RUP

RUP, Şelalenin sahip olduğu sorunları çözen yinelemeli bir yaklaşımdır. RUP'un iyi yanı:

• Değişen gereksinimleri karşılar. Proje yöneticisi ne kadar iyi olursa olsun başlangıçta her şeyi hesaba katmak mümkün değildir.
• İşlevlerin entegrasyonu kademeli olarak gerçekleşir, yani her "detay" bir geliştirme, test etme ve projeye uygulama döngüsünden geçer. Sonuç olarak riskler ve üretim maliyetleri azalır.
• Erken ürün sürümü. Yazılım, pazarda bir yer edinmek ve rakiplere direnmek için azaltılmış işlevsellikle ortaya çıkıyor ve ardından "et" ile büyümüş hale geliyor.
• Yeniden kullanın. İşlevselliği artırırken geliştirme süresini kısaltacak standart çözümleri belirlemek daha kolaydır.
• Sürekli öğrenme. Sık yinelemeler nedeniyle, geliştiricilerin kod revizyonları arasında uzun duraklamaları olmaz, dolayısıyla profesyonel gelişim sorunsuz ve sorunsuz bir şekilde gerçekleşir.
• Ürünün sürekli iyileştirilmesi. Yinelemeler, projeyi yalnızca plana ve teknik spesifikasyonlara uygunluk açısından değerlendirmenizi değil, aynı zamanda ürünün verimliliğini ve kalitesini artırmanın yollarını bulmanızı da sağlar.

Atik

Çevik, çok sayıda yinelemeyi içeren esnek bir yazılım geliştirme yöntemidir. Çevik Manifesto belgesinde çevik yaklaşımın 4 fikri ve 12 ilkesi anlatılmaktadır; yalnızca iki noktada kısaca açıklanabilir:

• Gayri resmi ilişkiler belgelenmiş olanlardan daha önemlidir. Yani planlara, sözleşmelere ve teknik şartnamelere yansıyan, çalışanlar arasındaki, müşteri ile yüklenici arasındaki sözlü anlaşmalar çok önemlidir. Başka bir deyişle müşteri her zaman haklıdır.
• Çalışan bir ürün, ilerlemenin ana değerlendirmesidir. Önemli olan araçlar, çözümler, performans veya zarafet değil, planlanan tüm yeteneklerin gerçekleştirilmesidir.

Eksikliklerine rağmen Agile, yazılım geliştirme için temel bir kavram haline gelmiştir ve aşağıda tartışılacak olan diğer metodolojilere de yansımaktadır.

Kristal berraklığı

6−10 çalışandan oluşan küçük ekipler için oluşturulmuş bir metodoloji. Aynı zamanda çevik gelişimin ilkelerini de destekler ancak biraz daha spesifiktir. Adın içerdiği ana fikir, her ekibin farklı bilgi düzeylerine, farklı becerilere ve deneyime sahip bir grup insandan oluşmasıdır.

Bu nedenle yazılım geliştirmede evrensel bir yaklaşım yoktur; grup içi iletişim sürecinde belirlenmelidir. Burada roller, araçlar ve standartlar da atanır. Daha sonra grup bir birim olarak ele alınır ve hiyerarşi müşteriye ulaşana kadar aynı sorunlar daha üst düzeyde çözümlenir.

Sarmal

Spiral yaşam döngüsü modeli, proje risklerinin erken tanımlanmasına ve azaltılmasına odaklanan karmaşık bir yazılım yaşam döngüsü organizasyonudur. Kalkınma küçük ölçekte başlar, yerel sorunlar çözülür, riskler ve bunları azaltma yolları değerlendirilir. Bir sonraki adım, spiralin bir sonraki dönüşü olan daha karmaşık görevleri kapsar.

Yaklaşımın avantajı gelişme hızını arttırmak değil, risk düzeyini azaltmaktır. Spiral yöntemin başarısı dikkatli, dikkatli ve yetkin yönetime bağlıdır ve projenin büyüklüğü çok önemli değildir.

DSDM

Dinamik sistem geliştirme modeli, 1990'ların ortasında İngiltere'de geliştirildi ve hızlı uygulama geliştirmenin (RAD) evrimsel bir gelişimidir. Ana fikir standarttır: Başlangıçta planlama yaparken gelişimin tüm inceliklerini anlamak imkansızdır, bu nedenle tüm süreç bir araştırma çalışmasıdır.

DSDM'nin ayrıca her biri stratejik kararlar almaya yetkili bir kişiye sahip olan ekiplerden oluşan bir bölümü vardır. İlgili tüm taraflar sürece katılabilir: kullanıcılar, geliştiriciler, müşteriler, yöneticiler. Test tüm yaşam döngüsü boyunca gerçekleştirilir.

FDD

FDD, yaratıcılığı ve yeniliği teşvik ederken ölçeklenebilirliği ve tekrarlanabilirliği sağlayan bir süreçtir. İşte temel ilkeler:

• Her büyük projenin gelişimi sistematik olmalıdır.
• Süreçler basit ve iyi geliştirilmiş olmalıdır.
• Sürecin değeri ve mantığı her ekip üyesi için açık olmalıdır.
• Kısa, tekrarlanan geliştirme döngüleri tercih edilir. Bu, hata sayısını azaltır ve işlevselliği hızlı bir şekilde artırmanıza olanak tanır.

FDD, süreçlerin her biri için harcanması gereken süreyi düzenler. Döngüdeki organizasyonel faaliyetler %23-25'ten fazla olmamalıdır, zamanın %75-77'si ise işlevlerin doğrudan geliştirilmesi, birleştirilmesi ve test edilmesine harcanmalıdır.

JAD

JAD, son kullanıcı geliştirme katılımını en üst düzeye çıkarmayı amaçlayan bir metodolojidir. Bu, toplantılar ve ortak seminerler aracılığıyla gerçekleşir. JAD, 1970'lerde IBM çalışanları tarafından icat edildi ve genel olarak iş hedefleniyor. Ancak zamanla bu kavram yazılım geliştirmede başarıyla uygulanmaya başlandı.

Şelale yaklaşımından farklı olarak JAD, geliştirme süresinin azalmasına, daha fazla müşteri memnuniyetine ve pazar araştırma maliyetlerinden tasarruf sağlar. Öte yandan, bu, geniş bir müşteri örneğini ve geliştiricilerin teknik spesifikasyonların katı gereklilikleri ile değil, sürekli değişen görüşlerle çalışması ihtiyacını gerektirir.

RAD

RAD, hıza ve geliştirme kolaylığına öncelik veren bir metodolojidir. Ana koşullardan biri hızlı gelişen bir dilin kullanılmasıdır. Bu, bir programcının sorunları üçüncü nesil temsilcilerden (C / C ++, Pascal veya Fortran) olduğundan daha hızlı çözebildiği soyut bir programlama dilinin adıdır. İşte konseptin birkaç noktası daha:

• Gereksinimleri toplamak için odak gruplarını kullanma.
• Tasarımların prototiplenmesi ve kullanıcı testleri.
• Yazılım bileşenlerinin yeniden kullanılması.
• Ürünün bir sonraki sürümü için yeniden tasarım veya tasarım içermeyen bir plan kullanılması.
• Taraflardan birinin talebi üzerine gayri resmi toplantılar düzenlemek.

RAD, hızlı geliştirme diline ek olarak çok çeşitli araçların kullanımını içerir: gereksinim toplama sistemleri, geliştirme ortamları, çerçeveler, grup iletişimi programları, test yazılımı.

Scrum

Scrum, amacı daha önce daha zor metodolojik süreçler nedeniyle felç olmuş ekiplerde üretkenliği artırmak olan esnek bir proje yönetimi yöntemidir. Konsept “sprint”lere dayanmaktadır. Bir sprint, zaman açısından kesinlikle sınırlı olan (genellikle 2−4 hafta) kısa bir yinelemedir. Şu anda toplantıların süresi en aza indirilir, ancak sıklıkları artar (bunlara "scrum" denir).

Bu, yürütme kontrolünü daha esnek hale getirir ve geliştiricilerin ortaya çıkan sorunlara daha hızlı yanıt vermelerine olanak tanır. Geleneksel planlama arka planda kayboluyor ve onun yerini sprint günlüğü alıyor.

XP

Ekstrem programlama, sürekli değişen gereksinimler karşısında gelişme yeteneğidir. İşte bazı işaretler:

• Planlama oyunu. Projenin başlangıcında sadece kaba bir plan vardır, her yinelemeden sonra netliği artar.
• Yüksek yayın sıklığı. Ürünün yeni sürümünde önceki sürüme göre küçük değişiklikler var ancak yayınlanma süresi minimum düzeyde.
• Müşteriyle iletişime geçin. Nihai hedef kitlenin gereksinimlerini karşılamak için yorum ve önerilere hızlı yanıt verilmesi gerekmektedir.
• Yeniden düzenleme. İşlevselliği azaltmadan kod kalitesini artırma.
• Kod yürütme standardı. Ya genel kurallar uygulanır ya da tasarımdaki anlaşmazlıklar tartışmaya ve eleştiriye konu olmaz.
• Kolektif sorumluluk. Her ekip üyesi kendi çalışma alanını gerçekleştirse de bir bütün olarak ekibin tamamı koddan sorumludur.

LD

Yalın yazılım geliştirme, geliştiricilerin yüksek ahlaki ve işlevsel durumunu korumayı içeren esnek metodolojinin bir başka dalıdır. Bu şu şekilde ifade edilir:

• Başarılı çalışmalar için çalışanları ödüllendirmek.
• Mevcut görevleri yalnızca gerektiğinde veya müşterinin isteği üzerine değiştirmek.
• Planın sıkı bir şekilde uygulanması: Aşırı olan her şey zaman ve kaynak israfı olarak kabul edilir.
• “Büyük düşün, az yap, çabuk hata yap, hızlı öğren” genel konseptinin tanıtılması.

Kısa bir özetle metodolojilerin tüm avantaj ve dezavantajlarını ortaya koymak ve etkili uygulama alanlarını göstermek zordur. Bugün en alakalı kavramlar hakkında ayrı ayrı konuşacağız. Tam olarak hangileri? Dileklerinizi yorumlara bırakın.

Ana makale: Şelale Modeli

Şelale yaşam döngüsü modeli şelale Modeli) 1970 yılında Winston Royce tarafından önerildi. Projenin tüm aşamalarının kesin olarak sabit bir sırayla sıralı olarak uygulanmasını sağlar. Bir sonraki aşamaya geçiş, bir önceki aşamadaki işin tamamen tamamlanması anlamına gelir. Gereksinimlerin oluşturulması aşamasında belirlenen gereksinimler, teknik şartname şeklinde sıkı bir şekilde belgelenir ve projenin tüm gelişimi boyunca kayıt altına alınır. Her aşama, geliştirmenin başka bir geliştirme ekibi tarafından sürdürülmesine izin vermeye yetecek eksiksiz bir belge setinin yayınlanmasıyla sonuçlanır.

Şelale modeline göre proje aşamaları:

1. Gereksinimlerin oluşturulması;

2. Tasarım;

3. Uygulama;

4. Test etme;

5. Uygulama;

6. Çalıştırma ve bakım.

Avantajları:

· Her aşamada dokümantasyonu tamamlayın ve üzerinde anlaşmaya varın;

· Projenin zamanlamasını ve maliyetini belirlemek kolaydır.

Kusurlar:

Şelale modelinde bir proje aşamasından diğerine geçiş, önceki aşamanın sonucunun (çıktısının) tamamen doğru olduğunu varsayar. Bununla birlikte, herhangi bir gereksinimin yanlış olması veya yanlış yorumlanması, projenin erken aşamasına "geri dönmenin" gerekli olduğu gerçeğine yol açar ve gerekli yeniden çalışma, yalnızca proje ekibini programın dışına çıkarmakla kalmaz, aynı zamanda çoğu zaman niteliksel bir projeye de yol açar. maliyetlerde artış ve muhtemelen projenin başlangıçta amaçlandığı biçimde sonlandırılması. Modern uzmanlara göre, şelale modelinin yazarlarının temel yanılgısı, projenin tüm süreci bir kez geçirdiği, tasarlanan mimarinin iyi ve kullanımı kolay olduğu, uygulama tasarımının makul olduğu ve uygulamadaki hataların önemli olduğu varsayımıdır. test yoluyla kolaylıkla ortadan kaldırılabilir. Bu model, tüm hataların uygulamada yoğunlaşacağını ve bu nedenle bileşenlerin ve sistemin test edilmesi sırasında bunların ortadan kaldırılmasının eşit şekilde gerçekleştiğini varsayar. Bu nedenle şelale modeli büyük projeler için pek gerçekçi değildir ve yalnızca küçük sistemler oluşturmak için etkin bir şekilde kullanılabilir.

Yinelemeli model

Sıralı modele bir alternatif, yinelemeli ve artımlı geliştirme modeli olarak adlandırılan modeldir. yinelemeli ve artımlı geliştirme, IID), 70'lerde T. Gilb'den de alındı. İsim evrimsel model. Bu modele aynı zamanda denir yinelemeli model Ve artımlı model .

IID modeli, proje yaşam döngüsünü, bir bütün olarak projeyle karşılaştırıldığında daha küçük işlevsellik parçalarının oluşturulmasına uygulanan tüm geliştirme süreçlerini içeren, her biri bir "mini projeye" benzeyen bir yineleme dizisine bölmeyi içerir. Her birinin amacı yinelemeler- tüm önceki ve mevcut yinelemelerin entegre içeriğiyle tanımlanan işlevsellik de dahil olmak üzere, yazılım sisteminin çalışan bir sürümünün elde edilmesi. Son yinelemenin sonucu, ürünün gerekli tüm işlevlerini içerir. Böylece, her yinelemenin tamamlanmasıyla birlikte ürün bir artış alır - artış- sonuç olarak gelişen yeteneklerine evrimsel olarak. Bu durumda yineleme, artımlılık ve evrim, aynı anlamın farklı kelimelerle, biraz farklı bakış açılarından ifadesidir.

T. Gilb'in belirttiği gibi, “Evrim, istikrarlı bir görünüm yaratmak için tasarlanmış bir tekniktir. Karmaşık bir sistemi başarılı bir şekilde oluşturma şansı, bir dizi küçük adımla uygulandığında ve her adımın açıkça tanımlanmış bir başarıyı içermesinin yanı sıra başarısızlık durumunda önceki başarılı aşamaya "geri dönme" olasılığını da içeriyorsa en yüksek olacaktır. . Geliştirici, bir sistemi oluşturmaya yönelik tüm kaynakları hayata geçirmeden önce gerçek dünyadan geri bildirim sinyalleri alma ve projedeki olası hataları düzeltme fırsatına sahip oluyor."

IID yaklaşımının, aslında avantajların tersi olan olumsuz yanları da vardır. İlk olarak, projenin yetenekleri ve sınırlamalarına ilişkin bütünsel bir anlayış çok uzun zamandır eksikti. İkinci olarak, yineleme yaparken daha önce yapılan işlerin bir kısmını atmanız gerekir. Üçüncüsü, uzmanların iş yaparken vicdanlılığı hala azalıyor ki bu psikolojik olarak açıklanabilir, çünkü sürekli olarak "her şey daha sonra yeniden yapılabilir ve geliştirilebilir" hissinin hakimiyetindedirler.

Yinelemeli yaklaşımın çeşitli çeşitleri çoğu modern geliştirme metodolojisinde (RUP, MSF, XP) uygulanmaktadır.

Spiral modeli

Spiral modeli(İngilizce) spiral modeli) 1980'lerin ortasında Barry Boehm tarafından geliştirildi. Klasik Deming döngüsü PDCA'ya (planla-yap-kontrol et-harekete geç) dayanmaktadır. Bu modeli kullanırken, yazılım prototipleme yöntemi kullanılarak birkaç yinelemede (spiral dönüşler) oluşturulur.

Her yineleme, projenin hedeflerinin ve özelliklerinin açıklandığı, elde edilen sonuçların kalitesinin değerlendirildiği ve bir sonraki yinelemenin çalışmasının planlandığı yazılımın bir parçasının veya versiyonunun oluşturulmasına karşılık gelir.

Her yinelemede aşağıdakiler değerlendirilir:

· proje son tarihlerini ve maliyetlerini aşma riski;

· başka bir yineleme gerçekleştirme ihtiyacı;

· sistem gereksinimlerinin anlaşılmasının tamlık ve doğruluk derecesi;

· Projeyi sonlandırmanın fizibilitesi.

Spiral modelin evrimsel modele (IID modeli) bir alternatif değil, özel olarak geliştirilmiş bir versiyon olduğunun anlaşılması önemlidir. Ne yazık ki, sarmal model sıklıkla ya yanlışlıkla genel olarak evrimsel modelle eşanlamlı olarak kullanılıyor ya da (daha az hatalı olmamak üzere) IID ile birlikte tamamen bağımsız bir model olarak anılıyor.

Spiral modelin ayırt edici özelliği, yaşam döngüsünün ve kontrol noktalarının organizasyonunu etkileyen risklere verilen özel önemdir. Boehm en yaygın (önceliğe göre) 10 riski formüle ediyor:

1. Uzman eksikliği.

2. Gerçekçi olmayan son tarihler ve bütçe.

3. Uygunsuz işlevselliğin uygulanması.

4. Yanlış kullanıcı arayüzü tasarlamak.

5. Mükemmeliyetçilik, gereksiz optimizasyon ve detayların bilenmesi.

6. Sürekli bir değişim akışı.

7. Sistem ortamını tanımlayan veya entegrasyona dahil olan dış bileşenler hakkında bilgi eksikliği.

8. Dış (projeyle ilgili olarak) kaynaklar tarafından gerçekleştirilen işin dezavantajları.

9. Ortaya çıkan sistemin yetersiz performansı.

10. Farklı alanlardaki uzmanların niteliklerindeki boşluk.

Günümüzün spiral modeli aşağıdaki genel kontrol noktalarını tanımlar:

1. Operasyon Konsepti (COO) - sistemin konsepti (kullanımı);

2. Yaşam Döngüsü Hedefleri (LCO) - yaşam döngüsünün hedefleri ve içeriği;

3. Yaşam Döngüsü Mimarisi (LCA) - yaşam döngüsü mimarisi; burada hedef yazılım sisteminin kavramsal mimarisinin hazır olduğundan bahsetmek mümkün;

4. İlk Operasyonel Yetenek (IOC) - oluşturulan ürünün deneme işlemine uygun ilk versiyonu;

5. Nihai Operasyonel Yetenek (FOC) – gerçek operasyon için konuşlandırılmış (kurulu ve yapılandırılmış) bitmiş bir ürün.

Yazılım yaşam döngüsünün temel ilkelerini, müşterinin oluşturulan ürüne yönelik gereksinimlerini iyi anlamak ve aynı zamanda finansal yeteneklerini de dikkate almak gerekir. Birkaç yaşam döngüsü modeli (kademeli model, spiral model, hızlı) vardır. prototipleme vb.) Belirli bir yaşam döngüsü modelinin seçimi esas olarak projenin içeriğine ve hedeflerine ve ayrıca finansman miktarına bağlıdır.

Genellikle Agile adı verilen esnek geliştirme metodolojilerini bünyesinde barındıran spiral modeli tercih ediyoruz. Ancak bazen küçük veya karmaşık olmayan projeleri tamamlamak için şelale modelini (Şelale modeli olarak da bilinir) ve türevlerini kullanırız. Bu yazımızda klasik bir yazılım yaşam döngüsü türü olan şelale modelini anlatacağız.

Bu modele göre proje, tam eylem sırasına uygun olarak adım adım uygulanır: gereksinimlerin toplanması ve incelenmesi, yazılım tasarımı ve geliştirilmesi, test edilmesi ve teknik destek. Şelale modeli oldukça esnektir ve bazı aşamalar çakışabilir.

Yaşam döngüsünün her aşamasına tek tek bakalım:

1. Gereksinim analizi

Bu aşamada gelecekteki yazılımlar için tüm gereksinimlerin belgelenmesi önemlidir. Projenin detaylarının ilgili tüm taraflarla tartışılmasına yeterli zaman ayrılması gerekmektedir. Gelen tüm veriler analiz edilmeli ve sistematize edilmelidir. Müşteri tarafında ortaya çıkabilecek tüm teknik sınırlamaların dikkate alınması da önemlidir. Bu aşamanın sonucu, tüm müşteri gereksinimlerini karşılayan ayrıntılı bir spesifikasyonun oluşturulması olmalıdır. Geliştirme sürecini zorlaştırabilecek diğer faktörlere de dikkat etmelisiniz. Bunlar, müşteri tarafından belirlenen son teslim tarihlerinin yanı sıra bütçe kısıtlamalarını da içerir.

Lütfen unutmayın: Proje hakkında ne kadar çok bilgi toplarsanız, hataları düzeltmek, projeyi sonuçlandırmak, bütçeyi revize etmek, diğer konuları tartışmak ve çözmek için o kadar az zaman harcarsınız.

Proje vizyonu

Önemli bir görev, ayrıntılı bir proje vizyon belgesi (veya resmi) Projenin kısa bir açıklamasını, iş hedeflerini, proje başarı kriterlerini, iş risk faktörlerini ve ürünün son kullanıcısının açıklamasını içerir.

Bitmiş belge, belirtilen tüm gerekliliklerin dikkate alındığından emin olmak ve ayrıca projenin yayınlanmasından sonra ortaya çıkabilecek riskler konusunda onu bilgilendirmek için müşterinin onayına sunulmalıdır.

Gereksinimlerin toplanması

Tüm önemli sorunlar çözüldükten sonra, tüm paydaşlarla daha fazla tartışma ve etkileşimli çalıştay düzenlenmesi tavsiye edilir. Bu, daha sonra uygulama arayüzünde değişikliklere veya kod kalıplarının yeniden yazılması ihtiyacına neden olabilecek açık olmayan noktaların belirlenmesine yardımcı olacaktır. Bu aşama aynı zamanda anketlerin doldurulmasını, vakaların gözden geçirilmesini, beyin fırtınası yapılmasını vb. de içerebilir.

Pek çok proje, geliştirme aşamasında ortaya çıkan ek gereksinimler nedeniyle duraklıyor. Bu nedenle başlangıçtaki iş hedeflerini ve gelecekteki uygulamanın ana fikrini anlamak çok önemlidir.

2. Yazılım tasarımı

Yazılım yaşam döngüsünün bir sonraki aşaması, projenin kapsamını ve sınırlarını açıklayan bir belgenin oluşturulmasıdır. Bu belge, gelecekteki uygulamanın arayüzünün modellerini veya taslaklarını ve ayrıca yazılım gereksinimlerinin ayrıntılı bir spesifikasyonunu içerir. Bazı durumlarda projenin vizyon belgesi (imajı) ile projenin kapsamı ve sınırlarına ilişkin belgenin “Projenin görüntüsü ve sınırları hakkında” tek bir belge olarak sunulabileceğini belirtmek gerekir.

Proje kapsamı ve sınırları

Projenin kapsamını ve sınırlarını açıklayan belge, oluşturulan yazılımın ana işlevlerini listelemelidir. Proje vizyon belgesi esas alınarak ve elbette belirlenen zaman dilimi ve oluşturulan bütçe dikkate alınarak belirlenir.
Ayrıca bu belge, proje vizyon belgesine ve toplanan gereksinimlere dayalı olarak oluşturulan maketleri veya eskizleri içerir.
Kullanıcı arayüzünün bir taslağını elle çizebilir veya bunun için maket programları kullanabilir ve ardından müşteriyle üzerinde anlaşabilirsiniz. Aşağıda pratikte kullandığımız maketler oluşturmaya yönelik yararlı programların bir listesi bulunmaktadır:

Projenin tartışılması sırasında müşteri, projenin uygulanmasına ilişkin giderek daha fazla yeni fikre sahip olabilir. Bu nedenle, projesi ve gereksinimleri hakkında düşünmesi için ona zaman tanınması ve ardından hiçbir şeyin gözden kaçmaması için yeniden toplanıp projenin ayrıntılarını tartışması önerilir.
Bu aşamada ürünün satış sonrası hizmeti sorunu da ortaya çıkıyor. Test aşamasının tamamlanmasından ve ürünün daha sonra piyasaya sürülmesinden sonra teknik desteğin nasıl sağlanacağı konusunda müşteriye bilgi vermelisiniz.
Sözleşme imzalanmadan önce proje vizyon belgesi ve proje kapsam belgesinin oluşturulması gerektiğini lütfen unutmayın.

Yazılım Gereksinimleri Belirtimi

Bir yazılım gereksinimleri spesifikasyonu (SRS), oluşturulmakta olan yazılımın karşılaması gereken gereksinimleri açıklar. Mantıksal, tutarlı, erişilebilir ve eksiksiz olmalıdır. Gereksinimler, örneğin geleneksel zorunluluk ifadeleri (örneğin, "Personel Yöneticisi sistemi aşağıdaki tarayıcıları desteklemelidir: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+") gibi farklı biçimlerde ifade edilebilir veya kullanıcı hikayeleri biçiminde (örneğin, "yönetici olduğum için tüm çalışanların kişisel bilgilerine erişmem gerekiyor").
Çok sayıda spesifikasyon şablonu vardır. Belirli bir şablonun seçimi projenin özelliklerine bağlıdır. Çoğu durumda spesifikasyon, ürünün bir tanımını, kullanıcı sınıflarını, geliştirilmekte olan yazılım için işlevsel ve işlevsel olmayan gereksinimleri içerir. Bazen şablon aynı zamanda bir prototip de içerir. Önemli olan, spesifikasyonun geliştiriciler için açık, kısa ve kullanışlı olmasını sağlamaktır.

Bir prototip oluşturmak için aşağıdakileri anlamanız gerekir:

• gerekli çıktı verilerini oluşturmak için gelen verileri almak ve işlemek için bir yöntem;
• Çıktının sunulması gereken form.

Maketler (veya prototipler), onları renkli şablonlara dönüştüren UI/UX tasarımcılarına teslim edilir.

3. Yazılım geliştirme

Yazılım geliştirmenin, özünde gelecekteki uygulamanın temeli olan etkileşimli bir prototipin oluşturulmasını da içerebileceği unutulmamalıdır. Böyle bir prototip sistemin mimarisini bir bütün olarak tanımlamaya yardımcı olur. Bu aşamada müşteriye son ürünün nasıl çalışacağına dair genel bir fikir vermek için küçük kodlar yazılır: örneğin düğmeler ve basit formlar için kodlar. Bu nedenle yazılım geliştirme aşamasına prototip oluşturmayı da dahil ettik.

İnteraktif prototip ve uygulama tasarımı hazır olup müşteri tarafından onaylandıktan sonra, uygulama standartlarının (adlandırma kuralları, kodu belgeleme yöntemi, son kullanıcıya yönelik talimatlar vb.) geliştirilmesine başlanır. Bundan sonra yaşam döngüsünün bir sonraki aşaması olan yazılım geliştirmeye güvenle geçebilirsiniz. Yazılım geliştirme küçük parçalara veya birimlere bölünebilir ve her birim, işlevselliğini doğrulamak için geliştiriciler tarafından geliştirilir ve test edilir (birim testi).

4. Yazılım testi

Geliştirme aşaması tamamlandıktan sonra ürünün, belirtilen gereksinimleri karşıladığından emin olmak için sıkı testlerden geçmesi gerekir. Kabul testi, müşterinin ürünü piyasaya sürüldükten sonra kullanacakları şekilde yerel olarak kullanmaya çalışmasını gerektirir. Büyük hatalar düzeltildikten sonra yazılım uygulanabilir. Küçük hataları düzeltmek için, yazılım bakımı aşamasında herhangi bir kusurun düzeltilmesine olanak sağlayacak basit bir takip sistemi kullanılabilir.

5. Yazılım teknik desteği

Ürün müşterinin sunucusunda test edilip dağıtıldıktan sonra, yazılım geliştirme yaşam döngüsünün bir sonraki aşaması başlar; buna yazılım bakımı veya teknik destek adı verilir. Genel olarak bakım, bu aşamada keşfedilen küçük hataların düzeltilmesini içerir.
Ancak önceki adımlarda gösterdiğiniz tüm çabalara rağmen oluşturulan yazılımda bazı değişiklikler yapmak zorunda kalmanız olasıdır. Müşteri, geliştirilen ürünün işlevselliğinde değişiklik yapmaya karar verebilir. Bu nedenle, üründe gerekli değişiklikleri yapabilmek için yeni gereksinimleri müşteriyle toplamanız, tanımlamanız ve tartışmanız gerekecektir. Bu durumda yeni bir şelale projesi ile çalışmanız gerekecek ve yukarıda anlatılan tüm adımların baştan tekrarlanması gerekecektir.

Çözüm

Kaliteli yazılım oluşturmak için gerekli olan temel geliştirme aşamalarına baktık. Projenizin başarılı olabilmesi için, gelecekteki uygulamaya yönelik tüm gereksinimleri doğrudan müşteriyle tartışmanız ve ayrıca geliştirmenin her aşamasında yapılması gereken tüm çalışmaları ayrıntılı olarak belgelendirmeniz gerekir.

Kademeli model, askeri işlerde, uzay geliştirmede ve tıpta kullanılan yaşam destek sistemleri oluşturulurken, örneğin uçuş kontrolü, hava yastığı sistemleri vb. için yazılımın geliştirilmesinde mutlaka kullanılır. Küçük ve karmaşık olmayan projeler geliştirirken de kullanılabilir. Ancak başlangıç ​​aşamalarından birinde bir hata yapılırsa, bunun ancak geliştirme veya test aşamasında fark edilmesi ihtimali vardır. Bu nedenle bu modelin ancak tüm gereksinimlerin çok net olması ve zamanla değişmeyecek olması durumunda kullanılması önerilir.

Bu makale XB Yazılım'daki deneyimli iş analistlerinin rehberliğinde hazırlanmıştır.

Aşağıdaki iki sekme aşağıdaki içeriği değiştirir.

Yazılım ürünü geliştirme, pek çok değerli metodolojiyi, diğer bir deyişle yerleşik en iyi uygulamaları bilir. Seçim projenin özelliklerine, bütçeleme sistemine, öznel tercihlere ve hatta yöneticinin mizacına bağlıdır. Makale Edison'da düzenli olarak karşılaştığımız metodolojileri anlatıyor.

1. “Şelale Modeli” (kademeli model veya “şelale”)

En eskilerinden biri, her birinin bir sonraki başlamadan önce tamamen tamamlanması gereken aşamaların sıralı geçişini içerir. Şelale modeli bir projeyi yönetmeyi kolaylaştırır. Sağlamlığı sayesinde geliştirme hızlı ilerler, maliyet ve son tarih önceden belirlenir. Ancak bu iki ucu keskin bir kılıçtır. Şelale modeli yalnızca açıkça ve önceden tanımlanmış gereksinimlere ve bunları uygulama yollarına sahip projelerde mükemmel sonuçlar verecektir. Geri adım atmanın bir yolu yoktur; test ancak geliştirme tamamlandıktan veya neredeyse tamamlanmak üzereyken başlar. Bu modele göre haklı bir seçim olmadan geliştirilen ürünler, sıkı eylem dizisinden dolayı ancak sonunda bilinen eksikliklere sahip olabilir (gereksinimler listesi herhangi bir zamanda değiştirilemez). Değişiklik yapmanın maliyeti yüksektir çünkü başlatmak için tüm projenin tamamlanmasını beklemek gerekir. Bununla birlikte, sabit maliyet çoğu zaman yaklaşımın dezavantajlarından daha ağır basmaktadır. Oluşturma sürecinde ortaya çıkan eksikliklerin düzeltilmesi mümkündür ve deneyimlerimize göre, sözleşmeye küçük bir teknik şartname içeren bir ila üç ek anlaşma yapılması gerekmektedir.

Şelale modelini kullanarak sadece teknik şartnamelerin geliştirilmesi dahil pek çok projeyi sıfırdan oluşturduk. Habré'de hakkında yazılan projeler: orta - X-ışını mikrotomografisi, küçük - AWS'de Windows hizmetinin otomatik güncellenmesi.

Şelale metodolojisi ne zaman kullanılmalı?

• Yalnızca gereksinimler bilindiği, anlaşıldığı ve kaydedildiği zaman. Çelişkili gereksinimler yoktur.
• Gerekli niteliklere sahip programcıların bulunmasında herhangi bir sorun yoktur.
• Nispeten küçük projelerde.

2. "V-Modeli"

Kademeli modelden “adım adım” yapısını devraldı. V şeklindeki model, kesintisiz çalışmanın özellikle önemli olduğu sistemlere uygulanabilir. Örneğin kliniklerde hastaların izlenmesine yönelik uygulama programları, araçlardaki acil durum hava yastıklarının kontrol mekanizmalarına yönelik entegre yazılımlar vb. Modelin özel bir özelliği, halihazırda tasarımın ilk aşamalarında olan bir ürünün kapsamlı bir şekilde kontrol edilmesini ve test edilmesini amaçlamasıdır. Test aşaması ilgili geliştirme aşamasıyla eş zamanlı olarak gerçekleştirilir, örneğin birim testler kodlama sırasında yazılır.

V-metodolojisine dayanan çalışmalarımızın bir örneği, Avrupalı ​​bir mobil operatör için seyahat sırasında dolaşım maliyetlerinden tasarruf sağlayan bir mobil uygulamadır. Proje açık bir spesifikasyona göre gerçekleştirilir, ancak önemli bir test aşamasını içerir: arayüz kolaylığı, işlevsellik, yük ve farklı üreticilerin çeşitli bileşenlerinin birlikte istikrarlı bir şekilde çalıştığını doğrulaması gereken entegrasyon dahil, para ve kredi hırsızlığı imkansız.

V modeli ne zaman kullanılmalı?

• Bir ürünün kapsamlı bir şekilde test edilmesi gerekiyorsa, V modeli kendi doğasında olan fikri haklı çıkaracaktır: doğrulama ve doğrulama.
• Gereksinimlerin açıkça tanımlandığı ve sabitlendiği küçük ve orta ölçekli projeler için.
• Gerekli niteliklere sahip mühendislerin, özellikle de test uzmanlarının bulunması durumunda.

3. "Artımlı Model" (artımlı model)

Artımlı modelde, tüm sistem gereksinimleri farklı montajlara bölünmüştür. Terminoloji genellikle yazılımın adım adım montajını tanımlamak için kullanılır. Çeşitli gelişim döngüleri gerçekleşir ve bunlar birlikte çoklu şelale yaşam döngüsünü oluşturur. Döngü daha küçük, kolayca oluşturulan modüllere bölünmüştür. Her modül gereksinimlerin tanımlanması, tasarlanması, kodlanması, uygulanması ve test edilmesi aşamalarından geçer. Artımlı modele göre geliştirme prosedürü, ilk büyük aşamada temel işlevlere sahip bir ürünün piyasaya sürülmesini ve ardından "artırımlar" adı verilen yeni işlevlerin sırayla eklenmesini içerir. Süreç, sistemin tamamı oluşturulana kadar devam eder.

Bireysel değişiklik taleplerinin net olduğu ve kolayca resmileştirilip uygulanabildiği yerlerde artımlı modeller kullanılır. Projelerimizde bunu DefView okuyucusunu ve ardından Vivaldi elektronik kütüphaneler ağını oluşturmak için kullandık.

Örnek olarak, bir artışın özünü açıklayacağız. Vivaldi elektronik kütüphaneleri ağı DefView'ın yerini aldı. DefView bir belge sunucusuna bağlı ve artık birçok belge sunucusuna bağlanabiliyor. İçeriğini belirli bir hedef kitleye yayınlamak isteyen bir kurumun sitesine, belgelere doğrudan erişen ve bunları gerekli formata dönüştüren bir depolama sunucusu kurulur. Mimarinin kök unsuru ortaya çıktı: çeşitli kurumlarda kurulu tüm depolama sunucuları için birleşik bir arama motoru görevi gören merkezi Vivaldi sunucusu.

Artımlı model ne zaman kullanılmalı?

• Sistem için temel gereksinimler açıkça tanımlandığında ve anlaşıldığında. Aynı zamanda bazı ayrıntılar zaman içinde iyileştirilebilir.
• Ürünün pazara erken sunulması gerekmektedir.
• Birkaç riskli özellik veya hedef vardır.

4. “RAD Modeli” (hızlı uygulama geliştirme modeli veya hızlı uygulama geliştirme)

RAD modeli bir tür artımlı modeldir. RAD modelinde bileşenler veya işlevler, birkaç mini proje gibi, çok sayıda yüksek vasıflı ekip tarafından paralel olarak geliştirilir. Bir döngünün zaman çerçevesi kesinlikle sınırlıdır. Oluşturulan modüller daha sonra çalışan tek bir prototipe entegre edilir. Sinerji, geri bildirim almak ve değişiklik yapmak için müşteriye çalışan bir şeyi incelenmek üzere çok hızlı bir şekilde sunmanıza olanak tanır.

Hızlı uygulama geliştirme modeli aşağıdaki aşamaları içerir:

• İş modelleme: farklı departmanlar arasındaki bilgi akışlarının bir listesini tanımlamak.
• Veri modelleme: Önceki aşamada toplanan bilgiler, bilginin dolaşımı için gerekli olan nesneleri ve diğer varlıkları belirlemek için kullanılır.
• Süreç modelleme: Bilgi akışları, geliştirme hedeflerine ulaşmak için nesneleri birbirine bağlar.
• Uygulamayı oluşturun: CAD modellerini koda dönüştürmek için otomatik montaj araçlarını kullanır.
• Test: Yeni bileşenler ve arayüzler test edilir.

RAD modeli ne zaman kullanılır?

Yalnızca yüksek vasıflı ve son derece uzman mimarlarla kullanılabilir. Proje bütçesi, hazır otomatik montaj araçlarının maliyetiyle birlikte bu uzmanlara ödenecek kadar büyük. RAD modeli, hedef işin kendinden emin bilgisiyle ve sistemin 2-3 ay içinde acil üretim ihtiyacı ile seçilebilir.

5. “Çevik Model” (esnek geliştirme metodolojisi)

“Çevik” geliştirme metodolojisinde müşteri her yinelemeden sonra sonucu gözlemleyebilir ve bunun kendisini tatmin edip etmediğini anlayabilir. Bu esnek modelin faydalarından biridir. Dezavantajları arasında, sonuçların spesifik formülasyonlarının bulunmaması nedeniyle, geliştirme için gereken işçilik maliyetlerini ve maliyetleri tahmin etmenin zor olması yer almaktadır. Ekstrem Programlama (XP), çevik modelin pratikte en bilinen uygulamalarından biridir.

Bu tür, kısa günlük toplantılara - "Scrum" ve "Sprint" adı verilen düzenli olarak yinelenen toplantılara (haftada bir, iki haftada bir veya ayda bir) dayanmaktadır. Günlük toplantılarda ekip üyeleri şunları tartışır:

• son Scrum'dan bu yana yapılan çalışmalara ilişkin rapor;
• çalışanın bir sonraki toplantıdan önce tamamlaması gereken görevlerin listesi;
• çalışma sırasında karşılaşılan zorluklar.

Metodoloji büyük projelere veya uzun yaşam döngüsünü hedefleyen, sürekli olarak piyasa koşullarına uyum sağlayan projelere uygundur. Buna göre gereksinimler uygulama sürecinde değişmektedir. Haftalık, hatta günlük olarak yeni fikirler üretme, ortaya çıkarma ve deneme eğiliminde olan yaratıcı insanlar sınıfını hatırlamakta fayda var. Çevik gelişim, bu psikotipteki yöneticiler için en uygunudur. Agile'ı kullanarak şirketin dahili girişimlerini geliştiriyoruz. Müşteri projelerine bir örnek, toplu tıbbi muayenelerin birkaç dakika içinde gerçekleştirilmesi için oluşturulan Elektronik Tıbbi Muayene Sistemidir. Bu incelemenin ikinci paragrafında Amerikalı ortaklarımız Agile'da başarının temeli olan çok önemli bir şeyi anlattılar.

Çevik ne zaman kullanılmalı?

• Dinamik bir işletmede kullanıcı ihtiyaçları sürekli değiştiğinde.
• Sık artışlar nedeniyle çevik değişiklikler daha düşük maliyetle uygulanır.
• Şelale modelinin aksine çevik model, bir projeyi hayata geçirmek için sadece küçük bir planlama gerektirir.

6. “Yinelemeli Model” (yinelemeli veya yinelemeli model)

Yinelemeli bir yaşam döngüsü modeli, başlangıçta tam bir gereksinim spesifikasyonu gerektirmez. Bunun yerine oluşturma, daha sonraki gereksinimleri tanımlamanın temelini oluşturan bir işlevsellik parçasının uygulanmasıyla başlar. Bu işlem tekrarlanır. Sürüm mükemmel olmayabilir, asıl önemli olan işe yaramasıdır. Nihai hedefi anlayarak, her adımın etkili ve her versiyonun uygulanabilir olması için çabalıyoruz.

Diyagram Mona Lisa'nın yinelemeli "gelişimini" göstermektedir. Gördüğünüz gibi, ilk yinelemede sadece Mona Lisa'nın bir taslağı var, ikinci yinelemede renkler ortaya çıkıyor ve üçüncü yinelemede detaylar, doygunluk ekleniyor ve süreç tamamlanıyor. Artımlı modelde ürünün işlevselliği parça parça inşa edilir, ürün parçalardan oluşur. Yinelemeli modelin aksine, her parça tam bir öğeyi temsil eder.

Yinelemeli gelişimin bir örneği ses tanımadır. Bilimsel aparatın ilk araştırması ve hazırlanması uzun zaman önce önce düşüncelerde, sonra kağıt üzerinde başladı. Her yeni yinelemede tanıma kalitesi arttı. Ancak henüz tam anlamıyla tanınma sağlanamadığı için sorun da tam olarak çözülmüş değil.

Yinelemeli bir modeli kullanmak ne zaman en uygunudur?

• Nihai sistemin gereksinimleri önceden açıkça tanımlanmış ve anlaşılmıştır.
• Proje büyük ya da çok büyük.
• Ana hedef tanımlanmalıdır ancak uygulama ayrıntıları zaman içinde gelişebilir.

7. "Spiral Model" (spiral model)

“Sarmal model” artımlı modele benzer ancak risk analizine vurgu yapar. Başarısızlığın şirketin faaliyetleriyle bağdaşmadığı durumlarda, yeni ürün gruplarının piyasaya sürülmesi bağlamında, bilimsel araştırma ve pratik testlerin gerekli olduğu durumlarda kritik iş sorunlarını çözmek için iyi çalışır.

Spiral model her dönüş için 4 aşamadan oluşur:

1. planlama;
2. risk analizi;
3. tasarım;
4. sonucun değerlendirilmesi ve kalitenin tatmin edici olması durumunda yeni bir aşamaya geçiş.

Bu model küçük projeler için uygun değildir; örneğin bir banka için belge akış sisteminin geliştirilmesi gibi karmaşık ve pahalı projeler için, her bir sonraki adımın, sonuçların değerlendirilmesi için programlamadan daha fazla analiz gerektirdiği durumlarda mantıklıdır. Sibirya SO UES'in ODU'su için bir EDMS geliştirme projesinde, elektronik arşiv bölümlerinin kodlanmasının değiştirilmesine ilişkin iki toplantı, bir programcının iki klasörü birleştirmesinden 10 kat daha fazla zaman alıyor. Katıldığımız hükümet projeleri, ulusal ölçekte karşılığını verdiği için her zaman işe yaramaz olmayan pahalı bir konseptin uzman topluluk tarafından hazırlanmasıyla başladı.

Özetleyelim

Slayt, en yaygın iki metodoloji arasındaki farkları göstermektedir.

Modern uygulamada yazılım geliştirme modelleri çok değişkenlidir. Tüm projeler, başlangıç ​​koşulları ve ödeme modelleri için tek bir doğru model yoktur. Hepimizin çok sevdiği Agile bile bazı müşterilerin hazırlıksızlığı veya esnek finansmanın imkansızlığı nedeniyle her yerde uygulanamıyor. Metodolojiler araçlar açısından kısmen örtüşmekte ve kısmen de birbirine benzemektedir. Diğer bazı kavramlar yalnızca kendi derleyicilerini tanıtmak için kullanıldı ve uygulamaya yeni bir şey getirmedi.

Geliştirme teknolojileri hakkında:
Bir kez daha yedi ana geliştirme metodolojisinden bahsedeceğim.
Ölçeklendirme sistemlerinde 10 temel hata.
Hayatı Kolaylaştıran 8 Kalkınma Planlama İlkesi.
Özel yazılım geliştirmede 5 ana risk.

Ankete yalnızca kayıtlı kullanıcılar katılabilir. , Lütfen.