İlk bölümde, metodolojinin yinelemeli geliştirmeye oranı ve çalışma materyallerinin tasarımındaki ve genel olarak geliştirmedeki formalite derecesi gibi göstergeler gibi yazılım geliştirme metodolojilerini karşılaştırmayı seçtik. Bu bölümde, en iyi bilinen yazılım geliştirme uygulamalarını karşılaştırmak için bu metrikleri kullanıyoruz.

Bakalım nasıl olacak…

Ne yazık ki, bu tanımlaması en zor kategoridir - sonuçta, hem ilk projesini ne pahasına olursa olsun tamamlamaya çalışan bir aceminin sarsıcı fırlatma ürününü hem de uzun yıllar boyunca emilmiş oldukça olgun ve köklü metodolojileri içerir. belirli geliştirme ekiplerinin çeşitli deneyimleri ve hatta iç düzenlemelerde açıklanmıştır. Kural olarak, kendi metodolojilerini geliştirebilen insanlar, yineleme ve formalizasyon açısından kendileri değerlendirebildiklerinden, yeni başlayanlara odaklanacağız. Ne yazık ki, çoğu zaman bu, geliştirme kurallarının ya hiç olmadığı ya da geliştirilip benimsendiği, ancak uygulanmadığı anlamına gelir. Bu gibi koşullarda doğal, son derece düşük bir gelişme formalizmidir. Yani her şey açık.

Geliştirme "Nasıl çalışır"

Yinelemeli bir yaklaşıma ne dersiniz? Ne yazık ki, kural olarak, bu tür projelerde kullanılmaz. Her şeyden önce, çünkü ilk iterasyonlarda bile projeyi son derece şüpheli ve düzeni yeniden sağlamak için üst yönetimin acil müdahalesini gerektiren olarak değerlendirmeye izin verecekti. Ne de olsa, yinelemeli bir projede, programcının her şeyin onun için %90 hazır olduğu şeklindeki geleneksel yanıtı, yalnızca ilk yinelemenin tamamlanmasına kadar sürer…

Yapısal Metodolojiler

Yapısal Metodolojiler

Yapısal yöntemler, kural olarak, nesne yönelimli dillerin yaygın kullanımından önce bile geliştirilmiş bir grup metodolojidir. Hepsi şelale gelişimini içerir. Her ne kadar ortaya çıktığı gibi, şelale yaklaşımının ilk sunumu olarak sıklıkla atıfta bulunulan o makalede bile, projeye bir prototip geliştirilmesi ile başlamanın, yani en azından gerçekleştirmenin arzu edilir olduğu söylendi. iki yineleme.

Bununla birlikte, bu metodolojilerin temeli, işten işe ardışık geçiş ve bir sonraki aşamanın sonuçlarının (belgelerinin) bir sonraki aşamanın katılımcılarına aktarılmasıdır.

Ayrıca, tüm bu metodolojiler oldukça resmi bir yaklaşımı varsayar, ancak bunlarda makul miktarda belgeleme hakkında ifadeler bulunabilir. Yazılım geliştirme metodolojilerinin sadece Batı'da geliştirilmediğinin bariz olmayan örneklerinden biri, 1980'lerin başında ülkemizde yayınlanan bir kitaptan yapılan alıntıdır. analist ve programcının ne kadar iyi olduğuna dair. Ve bu, kitabın temasının, şimdi adlandırıldığı gibi, ciddi kayıplara ve hatta felaketlere yol açan sistemlerin, hataların oldukça kritik gelişimini içermesine rağmen.

Çevik Metodolojiler

Çevik metodolojiler, sadece bu metodolojilerin seçilen parametrelere göre değerlendirilmesini belirleyenleri isimlendireceğimiz on ilkeye dayanmaktadır:

• asıl olan müşteriyi memnun etmek ve ürünü en kısa sürede ona ulaştırmak;
• ürünün yeni sürümleri, aşırı durumlarda birkaç haftada bir görünmelidir - aylar;
• çoğu etkili yöntem geliştirme katılımcılarına ve aralarında bilgi aktarımı - kişisel iletişim;
• Çalışan bir program, gelişimdeki ilerlemenin en iyi göstergesidir.

Bu nedenle, bu yöntemler açıkça yinelemeli yazılım geliştirmeye ve sürecin minimum resmileştirilmesine odaklanmıştır. Ancak, ikinci noktaya ilişkin bir çekince yapmak gerekir: bu yöntemler, belirli bir proje için kabul edilebilir minimum resmileştirme düzeyine odaklanır. Esnek gruba dahil edilen metodolojilerden en az biri - Crystal - süreçleri farklı sayıda katılımcıyla ve geliştirilmekte olan yazılımın farklı kritikliğiyle gerçekleştirmek için tasarlanmış modifikasyonlara sahiptir (yazılımın kritikliği, farklı olabilecek hataların olası sonuçlarıyla belirlenir). bir hatayı feci bir hataya sabitlemek için küçük mali kayıplar). Esnek metodolojilerle daha fazla karşılaştırmanın anlamsız olmaması için, bunlardan birkaçının kısa açıklamalarını vereceğiz.

eXtreme Programlama veya XP (aşırı programlama)

Kent Beck, Ward Cunningham ve Ron Jeffries tarafından geliştirilen XP metodolojisi, günümüzde çevik metodolojilerin en iyi bilinenidir. Bazen "çevik metodolojiler" kavramının kendisi, sosyalliği, basitliği, geri bildirim ve cesaret. Bir dizi uygulama olarak tanımlanır: planlama oyunu, kısa sürümler, metaforlar, basit tasarım, kodu yeniden düzenleme, önceden test geliştirme, çift programlama, toplu kod sahipliği, 40 saatlik çalışma haftası, müşteri varlığı ve kod standartları. XP'ye olan ilgi, aşağıdan yukarıya doğru arttı - geliştiriciler ve testçilerden, sancılı süreçler, belgeler, ölçümler ve diğer formalizm tarafından eziyet edildi. Disiplini reddetmediler, ancak resmi gereklilikleri anlamsızca takip etmeye isteksizdiler ve yüksek kaliteli programların geliştirilmesine yönelik yeni hızlı ve esnek yaklaşımlar aradılar.

XP'yi kullanırken, dikkatli ön yazılım tasarımı, bir yandan müşterinin ekipte sürekli varlığı, herhangi bir soruyu yanıtlamaya ve herhangi bir prototipi değerlendirmeye hazır olması ve diğer yandan düzenli kod revizyonları (sözde) ile değiştirilir. yeniden düzenleme). İyice yorumlanmış kod, tasarım belgelerinin temeli olarak kabul edilir. Metodolojide teste çok dikkat edilir. Kural olarak, her yeni yöntem için önce bir test yazılır ve ardından test başarılı bir şekilde çalışmaya başlayana kadar asıl yöntem kodu geliştirilir. Bu testler, herhangi bir kod değişikliğinden sonra otomatik olarak yürütülen paketlerde saklanır.

Eşli programlama ve 40 saatlik çalışma haftası belki de XP'nin en iyi bilinen özellikleri olsa da, bunlar doğası gereği hala yardımcıdır ve yüksek geliştirici üretkenliğine ve geliştirme hatalarının azalmasına katkıda bulunur.

Kristal berraklığı

Crystal, katılımcı sayısına ve görevlerin kritikliğine bağlı olarak, geliştirme sürecinin gerekli resmileştirme derecesini belirleyen bir metodoloji ailesidir.

Crystal Clear metodolojisi, performans açısından XP'den daha düşüktür, ancak kullanımı mümkün olduğunca kolaydır. İnsan alışkanlıklarına odaklandığı için uygulanması minimum çaba gerektirir. Bu metodolojinin, başka bir metodolojinin amaçlı bir şekilde uygulanmasıyla meşgul olmamaları durumunda, yeterince nitelikli ekiplerde kurulan doğal yazılım geliştirme sırasını tanımladığına inanılmaktadır.

Crystal Clear'ın Temel Özellikleri:

• yinelemeli artımlı geliştirme;
• otomatik regresyon testi;
• kullanıcılar projeye aktif katılımda bulunur;
• belgelerin bileşimi proje katılımcıları tarafından belirlenir;
• kural olarak, kod sürüm kontrol araçları kullanılır.

Crystal Clear'a ek olarak, Crystal ailesinde daha büyük veya daha kritik projeler için tasarlanmış birkaç başka metodoloji vardır. Değişiklik ve sürüm kontrolü gibi dokümantasyon ve destekleyici prosedürler için biraz daha katı gereksinimlerde farklılık gösterirler.

Özellik Odaklı Geliştirme

Özellik Odaklı Geliştirme (FDD), RUP kullanım durumu kavramına oldukça yakın olan bir sistem özelliği veya özelliği açısından çalışır. Belki de en önemli fark, ek bir kısıtlamadır: "her işlev, uygulamaya en fazla iki hafta içinde izin vermelidir." Yani, kullanım durumu yeterince küçükse, bir işlev olarak kabul edilebilir ve büyükse, nispeten bağımsız birkaç işleve bölünmelidir.

FDD, son ikisi her özellik için tekrarlanmak üzere beş süreç içerir:

• ortak bir modelin geliştirilmesi;
• gerekli sistem fonksiyonlarının bir listesini derlemek;
• her fonksiyon üzerinde planlama çalışması;
• fonksiyon tasarımı;
• fonksiyon yapısı.

Proje üzerindeki çalışma, sık sık yapılanmaları içerir ve her biri belirli bir dizi özellik kullanılarak uygulanan yinelemelere bölünmüştür.

FDD'deki geliştiriciler "sınıf ustaları" ve "baş programcılar" olarak ikiye ayrılır. Ana programcılar, bir sonraki mülk üzerinde çalışmak üzere ilgili sınıfların sahiplerini içerir. Karşılaştırma için: XP'de sınıflardan veya yöntemlerden kişisel olarak sorumlu değildir.

Ortak özellikler

Esnek metodolojilerin listesi şu anda oldukça geniştir. Bununla birlikte, tarif ettiğimiz metodolojiler tüm ailenin çok eksiksiz bir resmini verir.

Hemen hemen tüm çevik metodolojiler, bir sonraki sürümün yayınlanmasıyla ilgili yalnızca sınırlı miktarda çalışmanın ayrıntılı olarak planlandığı yinelemeli bir yaklaşım kullanır.

Hemen hemen tüm çevik metodolojiler, geliştirmeye yönelik en resmi olmayan yaklaşıma odaklanır. Sorun normal bir konuşma sırasında çözülebiliyorsa, bunu yapmak daha iyidir. Ve çizmek için karar kağıt şeklinde veya elektronik belge sadece onsuz yapmak imkansız olduğunda gereklidir.

Çevik Metodolojiler

GOST'ler

GOST'ler, bir sonraki bölümde açıklanan CMM gereksinimleri gibi metodolojiler değildir. Kural olarak, yazılım geliştirme süreçlerini kendileri tanımlamazlar, sadece formüle ederler. belirli gereksinimler farklı metodolojilerin bir dereceye kadar karşılık geldiği süreçlere. Metodolojileri karşılaştırdığımız aynı kriterlere göre gereksinimleri karşılaştırmak, GOST'a göre geliştirmeniz gerekiyorsa hangi metodolojileri kullanmanız gerektiğine hemen karar vermenize yardımcı olacaktır.

Şu anda, 19. ve 34. serilerin eski GOST'leri ve daha fazlası Rusya'da yürürlükte yeni GOST R ISO IEC 122207. 19. ve 34. serinin GOST'leri, kesinlikle yazılım geliştirmeye yönelik kademeli yaklaşıma odaklanmıştır. Bu GOST'lere göre geliştirme, her biri kesin olarak tanımlanmış işin performansını içeren ve yeterince serbest bırakılmasıyla sona eren aşamalar halinde gerçekleştirilir. Büyük bir sayı son derece resmi ve kapsamlı belgeler. Bu nedenle, bu standartlara derhal sıkı sıkıya bağlı kalmak, sadece şelale yaklaşımına yol açmakla kalmaz, aynı zamanda çok yüksek derece kalkınmanın resmileştirilmesi.

GOST gereksinimleri

GOST 12207, 19. ve 34. serilerin standartlarının aksine, yazılım geliştirmeyi projenin başından sonuna kadar çalışabilen bir dizi ana ve yardımcı süreç olarak tanımlar. modeli yaşam döngüsü Projenin özelliklerine göre seçilebilir. Bu nedenle, bu GOST, yinelemeli bir yaklaşımın kullanımını açıkça yasaklamaz, ancak kullanımını açıkça önermez. GOST 12207, geliştirme sürecinin formalitesi gereksinimleri açısından da daha esnektir. Yalnızca tüm süreçlerin ana sonuçlarını belgeleme ihtiyacının göstergelerini içerir, ancak içerikleriyle ilgili gerekli belgelerin ve talimatların listelerini içermez.

Böylece GOST 12207, yinelemeli ve daha az resmi yazılım geliştirmeye izin verir.

Geliştirme süreci olgunluk modelleri (CMM, CMMI)

Ulusal ve uluslararası standartlara ek olarak, geliştirme sürecinin belgelendirilmesine yönelik çeşitli yaklaşımlar vardır. Rusya'daki en ünlüleri, görünüşe göre, CMM ve CMMI'dir.

CMM (Yetenek Olgunluk Modeli), belirli bir şirketteki geliştirme sürecinin olgunluk düzeyini değerlendirmek için tasarlanmış, yazılım geliştirme süreçlerinin bir olgunluk modelidir. Bu modele göre, beş geliştirme süreci olgunluğu seviyesi vardır. İlk seviye, geliştiricilerin her projeye bir başarı olarak gittiği “nasıl gidiyor” gelişimine karşılık gelir. İkincisi, projenin olumlu bir sonucuna güvenmek için yeterli güvenle mümkün olduğunda, az çok iyi kurulmuş süreçlere karşılık gelir. Üçüncüsü, geliştirmede kullanılan gelişmiş ve iyi tanımlanmış süreçlerin varlığına karşılık gelir ve dördüncüsü, hedefleri belirlemek ve başarılarını izlemek için yönetim sürecinde metriklerin aktif kullanımına karşılık gelir. Son olarak, beşinci seviye, şirketin süreci gerektiği gibi optimize etme yeteneğini ifade eder.

CMM ve CMMI gereksinimleri

CMM'nin ortaya çıkışından sonra, özel olgunluk modelleri geliştirilmeye başlandı. bilgi sistemi, tedarikçileri ve diğerlerini seçme süreci için. Bunlara dayalı olarak entegre bir CMMI modeli (Capability Maturity Model Integration) geliştirildi. Ek olarak, CMMI'de, o zamana kadar ortaya çıkan CMM'nin eksikliklerinin üstesinden gelmek için bir girişimde bulunuldu - belirli belgelerin varlığının iyi kurulmuş bir belgeden çok daha değerli olduğu durumlarda, süreçlerin resmi tanımlarının rolünün abartılması, ancak tarif edilen süreç değil. Bununla birlikte, CMMI aynı zamanda oldukça resmi bir süreç kullanmaya da odaklanmıştır.

Bu nedenle, CMM ve CMMI modellerinin temeli, geliştirme sürecinin resmileştirilmesidir. Geliştiricilere, düzenlemelerde ve talimatlarda ayrıntılı olarak açıklanan ve uygun kontrol ve raporlama için büyük miktarda proje belgesinin geliştirilmesini gerektirmeyen ancak gerektirmeyen bir sürecin uygulanmasına yöneliktirler.

CMM ve CMMI'nin yinelemeli gelişimle ilişkisi daha dolaylıdır. Resmi olarak, hiçbiri bir şelaleye veya yinelemeli yaklaşıma bağlı kalmak için özel gereksinimler ortaya koymadı. Ancak bazı uzmanlara göre, CMM şelale yaklaşımıyla daha uyumluyken, CMMI yinelemeli bir yaklaşıma da izin veriyor.

RUP

Elbette, RUP yinelemeli bir metodolojidir. Resmi olarak tüm aşamaların zorunlu olarak yürütülmesi veya bazı minimum yineleme sayısı RUP'nin hiçbir yerinde belirtilmese de, tüm yaklaşım bunların oldukça fazla olduğu gerçeğine odaklanmıştır. Sınırlı miktar yinelemeler, RUP'tan tam olarak yararlanmanıza izin vermez. Aynı zamanda, RUP, gerçekten yalnızca birkaç yineleme içeren neredeyse basamaklı projelerde de kullanılabilir: biri Oluşturma aşamasında, diğeri Aktarma aşamasında. Bu arada, şelale projelerinde gerçekten kullanılan yineleme sayısıdır. Sonuçta sistemin test edilmesi ve denenmesi, analiz, tasarım ve geliştirme ile ilgili belirli eylemleri içerebilecek düzeltmelerin yapılmasını içerir, yani aslında geliştirmenin tüm aşamalarından bir geçiş daha.

RUP Metodolojisi

Metodolojinin formalitesi ile ilgili olarak, RUP kullanıcıya çok geniş bir olasılık yelpazesi sunar. Tüm işleri ve görevleri yerine getirirseniz, tüm eserleri ve resmi olarak yeterince (resmi bir gözden geçirenle, elektronik veya elektronik olarak tam bir inceleme hazırlayarak) oluşturun. kağıt belge vb.) tüm incelemeleri yapmak için, RUP çok resmi, hantal bir metodoloji olabilir. Aynı zamanda, RUP, yalnızca bu yapıtları geliştirmenize ve yalnızca belirli bir projede gerekli olan işleri ve görevleri gerçekleştirmenize olanak tanır. Ve seçilen eserler keyfi bir formalite derecesi ile yürütülebilir ve gözden geçirilebilir. Her belgenin ayrıntılı bir şekilde incelenmesini ve dikkatli bir şekilde yürütülmesini, eşit derecede dikkatli bir şekilde yürütülen ve resmileştirilmiş bir incelemenin sağlanmasını ve hatta eski uygulamaya göre, bu tür her bir incelemenin işletmenin bilimsel ve teknik konseyinde onaylanmasını istemek mümkündür. Veya kendinizi bir e-postayla veya kağıt üzerinde bir çizimle sınırlayabilirsiniz. Ek olarak, her zaman bir olasılık daha vardır: kafanızda bir belge oluşturmak, yani ilgili konuyu düşünmek ve yapıcı bir karar vermek. Ve bu karar sadece sizi ilgilendiriyorsa, kendinizi örneğin program kodundaki bir yorumla sınırlayın.

Bu nedenle RUP, çok geniş bir yelpazeye sahip yinelemeli bir metodolojidir. Muhtemel çözümler geliştirme sürecinin resmileştirilmesi açısından.

Yazının ikinci bölümünü özetleyelim. RUP, diğer metodolojilerin çoğundan farklı olarak, projelerin ve gelişen organizasyonun özelliklerine bağlı olarak, geliştirme sürecinin resmileştirme ve yineleme derecesini geniş bir aralıkta seçmenize olanak tanır.

Ve bunun neden bu kadar önemli olduğunu - bir sonraki bölümde tartışacağız.

1. Cascade (İngiliz şelalesi) - standart geliştirme modeli

Kademeli geliştirme modeli - tüm geliştirme aşamalarının sırayla gerçekleştirildiği bir model - bir sonraki aşama, bir önceki aşama tamamlandıktan sonra başlar.

Bu model, yazılım geliştirme sürecinde aşağıdaki adımları içerir:

Her şeyden önce, belirlenir teknik özellikler gelecekteki program, sonuç olarak, bir yazılım gereksinimleri listesi onaylanır. Ardından, programcılar için bir plan ve gereksinimlerin uygulanması için bir yol tanımlayan belgelerin oluşturulduğu tasarıma geçiş gelir.

Tasarım tamamlandıktan sonra programcılar projeyi uygular (inşa eder). Uygulama aşamasında, tüm proje bileşenleri entegre edilir. Ancak bu aşamaların tam olarak tamamlanmasından sonra, bitmiş ürün test edilir ve hata ayıklanır. Ayrıca, yazılım ürünü uygulanabilir ve uygulamadan sonra destek sağlar - yeni işlevler sunar ve hataları ortadan kaldırır.

Şelale geliştirmenin ana avantajları:

2. Çevik yazılım geliştirme metodolojisi

Bir dizi geliştirme metodolojisi yazılım müşteri temsilcilerinin ve geliştiricilerin ortak çalışmasını sağlayan . Çevik geliştirme yöntemi, yinelemeli bir yaklaşıma, gereksinimlerin dinamik oluşumuna ve bunların kısa aşamalarda uygulanmasına dayanmaktadır.

Bir yineleme döngüsü de dahil olmak üzere bu tür her aşamanın sonucu, minyatür bir yazılım projesidir.

Birkaç çevik geliştirme yöntemi vardır, en ünlüsü Scrum, Extreme Programming, DSDM'dir.

Çevik geliştirmenin başlıca avantajları:

		risk minimizasyonu; yazılım ürününün işlevselliğinde kademeli artış; az miktarda yazılı belge; programın temel sürümünün mümkün olan en kısa sürede piyasaya sürülmesi.
Dezavantajları da vardır:
		proje bütçesini doğru bir şekilde belirleyememe; proje hazırlığının kesin zamanlamasını belirlemenin imkansızlığı; devlet ve bütçe kuruluşları için uygun değildir; müşterinin sorumlu temsilcilerinden motivasyon gerektirir.

Çevik Yazılım Geliştirme Manifestosu Doğrudan geliştirerek ve başkalarına yardım ederek yazılım geliştirmenin daha iyi yollarını sürekli keşfediyoruz. Yapılan çalışmalar sayesinde şunu fark edebildik: İnsanlar ve etkileşim süreçlerden ve araçlardan daha önemli Çalışan ürün kapsamlı dokümantasyondan daha önemli müşteri ile işbirliği sözleşmenin şartlarını müzakere etmekten daha önemli Değişime hazır olmak daha önemli orijinal planı takip ederek Yani sağda olanın önemini inkar etmeden, solda olanı daha çok takdir ediyoruz.

Çevik geliştirme ilkeleri:

Gerekli yazılımların hızlı ve kesintisiz teslimi sayesinde müşteri memnuniyeti; geliştirmenin sonunda bile gereksinimlerdeki değişiklikleri memnuniyetle karşılar (bu, ortaya çıkan ürünün rekabet gücünü artırabilir); çalışan yazılımın sık sık teslimi (her ay veya hafta veya daha sık); proje boyunca müşteri ve geliştiriciler arasında yakın, günlük iletişim; proje gerekli çalışma koşulları, destek ve güvene sahip motive olmuş kişiler tarafından yürütülür; önerilen bilgi aktarma yöntemi kişisel bir görüşmedir (yüz yüze); çalışan yazılım, ilerlemenin en iyi ölçüsüdür; sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir tempoyu sürdürebilmelidir; teknik mükemmelliği ve kullanıcı dostu tasarımı geliştirmeye sürekli odaklanma; basitlik - gereksiz iş yapmama sanatı; en iyi teknik gereksinimler, tasarım ve mimari kendi kendini organize eden bir ekipten gelir; değişen koşullara sürekli uyum.

Yazılım geliştirme modelleri Şelale Cascade modeli Spiral Aşırı Programlama UI Prototipleme Artımlı W Modeli Testi Birleştirilmiş Yazılım Geliştirme Süreci (USDP) MSF Metodolojisi

Şelale modeli Gereksinim analizi Ürün spesifikasyonunu yazın Tasarım Ürün mimarisini yazın Uygulama Kaynak kodu geliştirin Kaynak kodunun ayrı kısımlarını entegre edin Hataları test edin ve düzeltin

Extreme Programming Başlangıç ​​Gereksinimleri Analizi Tasarım Entegrasyon Uygulama Testi Yeni Gereksinimleri Gözden Geçirme/Onaylama/Değiştirme Geliştirme Planını Sürüm Ürünü

UI Prototipleme Ürün sürümü Değişikliklerle birlikte yazılımın geliştirilmesi Gereksinimlerin ve özelliklerin netleştirilmesi Prototipin değiştirilmesi ve bazı işlevlerin iyileştirilmesi Temel işlevsellik Arayüz prototipi Ön belirtim

Artımlı Geliştirme Yineleme 1 Yineleme 2 …. Gereksinim Analizi Tasarım Uygulama Bileşen Testi Entegrasyon Tüm Yinelemenin Test Edilmesi N

Birleşik Yazılım Geliştirme Süreci (USDP) Ø Kullanım durumu modeli, uygulamanın kullanılacağı durumları açıklar. Ø Analitik model, uygulama için temel sınıfları tanımlar. Ø Tasarım modeli, sınıflar ve seçilen nesneler arasındaki bağlantıları ve ilişkileri tanımlar. Ø Dağıtım modeli, yazılımın bilgisayarlar arasında dağıtımını tanımlar. Ø Uygulama modeli açıklar iç organizasyon program kodu. Ø Test modeli, test bileşenleri, test prosedürleri ve farklı test durumlarından oluşur.

Birleşik Yazılım Geliştirme Süreci (USDP) Gereksinimlerini Toplayan Iter 1…. Yineleme N Tasarlama Yineleme 1…. Iter N Iter 1'in Uygulanması…. Yineleme N Tasarlama Yineleme 1…. Yineleme N Testi Yineleme 1…. iter N

Tipik yazılım ürünü mimarisi bileşenleri ve tipik yazılım gereksinimleri Ø Ø Ø Program organizasyonu Temel sistem sınıfları Veri organizasyonu İş kuralları Kullanıcı arayüzü Kaynak yönetimi Güvenlik Performans Ölçeklenebilirlik Diğer sistemlerle etkileşim (entegrasyon) Uluslararasılaştırma, yerelleştirme Giriş-çıkış verileri Hata işleme

Tipik Yazılım Ürün Mimarisi Bileşenleri ve Tipik Yazılım Gereksinimleri Hata toleransı, hataları tespit ederek, kurtararak ve sistem için kötü sonuçları izole ederek sistem güvenilirliğini artıran bir dizi sistem özelliğidir. Hata toleransını sağlamak için herhangi bir gerçek sistem tasarlarken, bir sistem arızasına yol açabilecek tüm olası durumları tahmin etmek ve arızaları ele almak için mekanizmalar geliştirmek gerekir. Güvenilirlik, bir sistemin çeşitli arızalara ve arızalara dayanma yeteneğidir. Başarısızlık, bir hata sonucu sistemin tamamen çalışamaz duruma geçmesidir. Arıza, sistemin arızalanmasına yol açmayan sistemin çalışmasındaki bir hatadır. Belirli bir süre için ne kadar az arıza ve arıza olursa, sistem o kadar güvenilir kabul edilir.

Bir yazılım ürünü mimarisinin tipik bileşenleri ve tipik yazılım gereksinimleri Güvenilirlik eğrisi N t 1 t Uzaklaştıkça, bir hatayı bulmak o kadar zor olacaktır. Sistem ne kadar karmaşıksa, arıza ve arıza olasılığı da o kadar yüksek olur.

Yazılım ürünü mimarisinin tipik bileşenleri ve tipik yazılım gereksinimleri Ø Geliştirilen mimariyi uygulama olanakları. Ø Aşırı işlevsellik. Ø Hazır yazılım bileşenlerini satın almaya karar vermek. Ø Stratejiyi değiştirin.

Mimarinin kalitesi hakkında bir sonuca varmanızı sağlayan bir kontrol listesi: Ø Programın genel organizasyonu açıkça tanımlanmış mı; Ø Ø Ø Spesifikasyonun mimariye ve mantığına genel bir bakış içerip içermediği. Programın ana bileşenleri yeterince tanımlanmış mı, sorumluluk alanları ve diğer bileşenlerle etkileşimi. Gereksinim belirtiminde belirtilen tüm işlevlerin makul sayıda sistem bileşeni tarafından uygulanıp uygulanmadığı. Tanımlanmış ve gerekçelendirilmiş en önemli sınıflardır. Veritabanının organizasyonunun bir açıklamasının verilip verilmediği. Tüm iş kuralları tanımlanmış mı? Sistem üzerindeki etkileri açıklanmış mı?

Mimarinin kalitesi hakkında bir sonuca varmanızı sağlayan bir kontrol listesi: Ø Kullanıcı arayüzü tasarım stratejisi açıklanıyor mu? Ø Yapıldı mı Kullanıcı arayüzü modüler, böylece değişiklikleri sistemin geri kalanını etkilemez. ØVeri giriş/çıkış stratejisinin açıklamasının yapılıp yapılmadığı. Ø Bu mimari kullanılarak uygulanacak sistemin performans analizinin yapılıp yapılmadığı. Ø Tasarlanan sistemin güvenilirlik analizinin yapılıp yapılmadığı. Ø Sistemin ölçeklenebilirlik ve genişletilebilirlik konularının analizinin yapılıp yapılmadığı.

Yazılım yeniden düzenleme Yeniden düzenleme, yazılımı yeni bir yazılıma uyarlamayı içerir. donanım ve yeni işletim sistemlerine, yeni geliştirme araçlarına, yeni gereksinimlere ve yazılım mimarisine ve işlevselliğine. Bu, yazılımın iç yapısında değişiklik yapılmadan yapılan bir değişikliktir. dış davranış yazılım değişikliği sağlamak için tasarlanmıştır. Yeniden düzenleme için makul nedenler: Kod tekrar ediyor; yöntem uygulaması çok büyük; döngülerin çok fazla iç içe geçmesi veya döngünün kendisi çok büyük; sınıfın bağlantısı zayıf (sınıfın özellikleri ve yöntemleri yalnızca 1 nesneyi tanımlamalıdır); bir sınıf arabirimi tutarlı bir soyutlama oluşturmaz; yöntem çok fazla parametre alıyor. Parametre sayısını makul bir minimumda tutmaya çalışmalısınız; sınıfın bireysel bölümleri, sınıfın diğer bölümlerinden bağımsız olarak değişir;

Programı değiştirirken yazılımın yeniden düzenlenmesi, birkaç sınıfın paralel olarak değiştirilmesini gerektirir. Böyle bir durum ortaya çıkarsa, gelecekte olası değişiklik yerlerini en aza indirmek için sınıfları yeniden düzenlemek gerekir; birkaç miras hiyerarşisini paralel olarak değiştirmek zorunda; birkaç vaka bloğunu değiştirmeniz gerekir. Programı, case bloğunun uygulamasını yapacak şekilde değiştirmek ve programda gerekli sayıda çağırmak gerekir; birlikte kullanılan ilgili veri üyeleri sınıflar halinde organize edilmez. Aynı veri öğeleri kümesini tekrar tekrar kullanıyorsanız, bu verileri birleştirmeyi ve bunlar üzerinde gerçekleştirilen işlemleri ayrı bir sınıfa yerleştirmeyi düşünmeniz önerilir;

Bir yazılım yeniden düzenleme yöntemi, kendi sınıfından başka bir sınıfın daha fazla öğesini kullanır. Bu, yöntemin başka bir sınıfa taşınması ve eski sınıftan çağrılması gerektiği anlamına gelir; temel veri türü aşırı yüklendi. Gerçek dünyanın özünü tanımlamak için, herhangi bir sınıfı aşırı yüklemektense herhangi bir sınıfı kullanmak daha iyidir. mevcut tip veri; sınıf çok sınırlı işlevselliğe sahiptir. İşlevselliğini başka bir sınıfa aktararak bu sınıftan kurtulmak daha iyidir; "başıboş" veriler, yöntemler zinciri boyunca iletilir. Bir metoda sadece başka bir metoda iletilmek üzere iletilen verilere başıboş veriler denir. Bu gibi durumlar ortaya çıktığında, onlardan kurtulmak için sınıfların mimarisini ve yöntemlerini değiştirmeye çalışın.

Medya nesnesini yeniden düzenlemek hiçbir şey yapmaz. Bir sınıfın rolü, yöntem çağrılarını diğer sınıflara yeniden yönlendirmekse, bu proxy'yi ortadan kaldırmak ve diğer sınıflara doğrudan çağrı yapmak en iyisidir; bir sınıf başka bir sınıf hakkında çok şey biliyor. Bu durumda, mirasçının ebeveyni hakkında minimum bilgiye sahip olmasını sağlamak için kapsüllemeyi daha katı hale getirmek gerekir; yöntemin talihsiz bir adı var; veri üyeleri herkese açıktır. Bu, arayüz ve uygulama arasındaki çizgiyi bulanıklaştırır, kaçınılmaz olarak kapsüllemeyi bozar ve program esnekliğini sınırlar; yorum yaz kaynak kodu;

Bir yazılım yeniden düzenleme alt sınıfı, atalarının yöntemlerinin yalnızca küçük bir bölümünü kullanır. Bu durum, herhangi bir yeni varlığı tanımlamak için değil, yalnızca temel sınıftan birkaç yöntemi devralmak için yeni bir sınıf oluşturulduğunda ortaya çıkar. Bundan kaçınmak için, temel sınıfı, yeni sınıfa yalnızca ihtiyaç duyduğu yöntemlere erişim sağlayacak şekilde dönüştürmek gerekir; kod global değişkenler içerir. Yalnızca tüm program tarafından gerçekten kullanılan değişkenler global olmalıdır. Diğer tüm değişkenler ya yerel olmalı ya da bir nesnenin özellikleri haline gelmelidir; program bir gün ihtiyaç duyulabilecek kodu içerir. Bir sistem geliştirirken, gelecekte kaynak kodun eklenebileceği yerlerin sağlanması tavsiye edilir.

Bu nedenle, EIS yazılımının geliştirilmesine yönelik yapısal yaklaşımın özü, otomatikleştirilmiş işlevlere ayrıştırılmasında (bölümlenmesinde) yatmaktadır: sistem, sırayla alt işlevlere, bunlar görevlere vb. özel prosedürlere kadar. Aynı zamanda sistem, tüm bileşen bileşenlerinin birbirine bağlı olduğu bütünsel bir görüşü korur. Bireysel görevlerden tüm sisteme kadar “aşağıdan yukarıya” bir sistem geliştirirken bütünlük kaybolur, bireysel bileşenlerin bilgi etkileşimini tanımlarken sorunlar ortaya çıkar.

Yapısal yaklaşımın en yaygın yöntemlerinin tümü bir dizi temele dayanmaktadır. Genel İlkeler:

1. "Böl ve yönet" ilkesi;

2. Hiyerarşik sıralama ilkesi - her düzeyde yeni ayrıntıların eklenmesiyle sistemin kurucu parçalarını hiyerarşik ağaç yapılarında düzenleme ilkesi.

İki kişilik seçim temel prensipler ilkelerin geri kalanının ikincil olduğu anlamına gelmez, çünkü bunlardan herhangi birinin göz ardı edilmesi, öngörülemeyen sonuçlara yol açabilir (tüm projenin başarısızlığı dahil”). Bu ilkelerin başlıcaları şunlardır:

1. Soyutlama ilkesi - sistemin temel yönlerinin vurgulanması ve gereksiz olandan dikkatin dağılması.

2. Sistem öğelerinin tutarlılığı, geçerliliği ve tutarlılığı ilkesi.

3. Yapılandırma ilkesi veri - veri yapılandırılmalı ve hiyerarşik olarak organize edilmelidir.

Yapısal yaklaşımda, sistemin işlevsel yapısını ve veriler arasındaki ilişkileri tanımlayan temel olarak iki grup araç vardır. Her araç grubu, belirli model türlerine (şemalara) karşılık gelir, aralarında en yaygın olanları şunlardır:

· DFD (Veri Akış Şemaları) - veri akışlarının diyagramları;

SADT (Yapısal Analiz ve Tasarım Tekniği - yapısal analiz ve tasarım metodolojisi) - modeller ve ilgili işlevsel diyagramlar: gösterimler IDEF0 (sistemlerin işlevsel modellemesi), IDEF1x (veritabanlarının kavramsal modellemesi), IDEF3x (bir nesnenin kalitesini değerlendirmek için bina sistemleri akış süreçlerinin grafiksel açıklaması, süreçlerin etkileşimi ve bu süreçler tarafından değiştirilen nesneler);

· ERD (Varlık - İlişki Diyagramları) - "varlık-ilişki" diyagramları.

Yapısal yaklaşımın hemen hemen tüm yöntemlerinde (yapısal analiz), yazılım gereksinimlerinin oluşturulması aşamasında iki grup modelleme aracı kullanılır:

1. Sistemin gerçekleştirmesi gereken işlevleri ve bu işlevler arasındaki ilişkileri gösteren diyagramlar - DFD veya SADT (IDEF0).

2. Diyagramları modelleme verileri ve ilişkileri (ERD).

Listelenen diyagramların özel biçimi ve yapılarının yorumlanması, yazılım yaşam döngüsünün aşamasına bağlıdır.

Yazılım gereksinimlerinin oluşturulması aşamasında, SADT modelleri ve DFD, “OLDUĞU GİBİ” modeli ve “TO-BE” modelini oluşturmak için kullanılır, böylece kuruluşun iş süreçlerinin mevcut ve önerilen yapısını ve bunlar arasındaki etkileşimi yansıtır. (Aslen yazılım tasarımı için tasarlanmadıklarından, genellikle yalnızca bu aşamayla sınırlı olan SADT modellerini kullanarak). ERD yardımıyla, veri tabanının (DBMS) uygulama aracı ne olursa olsun, organizasyonda kullanılan verilerin kavramsal düzeyde tanımlanması gerçekleştirilir.

Dipnot: Yazılım geliştirmeye esnek bir yaklaşım, esnek geliştirmenin temel ilkeleri göz önünde bulundurulur. Bir dereceye kadar esnek yazılım geliştirme ilkelerine karşılık gelen tekniklerin bir listesi sağlanır. Çevik gelişimin temel değerleri ve ilkeleri analiz edilir.

Bu ders için sunumu indirebilirsiniz.

Dersin amacı:

Çevik yazılım geliştirmenin amacını ve temel ilkelerini anlayın.

giriiş

Çevik yazılım geliştirme metodolojisi yinelemeli bir yaklaşımın kullanımına odaklanmıştır. yazılım belirli bir dizi gereksinimin uygulanması da dahil olmak üzere, küçük adımlarla kademeli olarak oluşturulur. Gereksinimlerin değişebileceği varsayılmaktadır. Çevik metodolojileri kullanan ekipler, bir yazılım ürünü oluşturma sürecinde çeşitli görevleri yerine getiren çok yönlü geliştiricilerden oluşur.

Çevik metodolojiler kullanılırken, geliştirme adı verilen bir dizi kısa döngüye indirgenerek risk minimizasyonu gerçekleştirilir. yinelemeler, 2-3 hafta sürer. Yineleme, içinde gerçekleştirilmek üzere zamanlanmış bir dizi görevdir. belirli bir süre zaman. Her yinelemede, en öncelikli olanın (bu yineleme için) olduğu yazılım sisteminin uygulanabilir bir sürümü oluşturulur. müşteri gereksinimleri. Her yineleme, uygulanabilir yazılım oluşturmak için gerekli tüm görevleri gerçekleştirir: planlama, gereksinim analizi, tasarım, kodlama, test etme ve belgeler. Tek bir yineleme genellikle serbest bırakmak için yeterli olmasa da Yeni sürümürün, mevcut olduğu anlaşılmaktadır yazılım her yinelemenin sonunda yayınlanmaya hazır. Her yinelemenin sonunda ekip, yazılım ürünü için gereksinimleri yeniden önceliklendirir ve muhtemelen sistem geliştirmede ayarlamalar yapar.

Çevik gelişimin ilkeleri ve anlamı

Çevik geliştirme metodolojisi için, ekiplerin yüksek performans elde etmesine izin veren temel varsayımlar açıklandı:

• insanlar ve etkileşimleri;
• çalışan yazılımın teslimi;
• müşteri ile işbirliği;
• değişime tepki.

İnsanlar ve etkileşim.İnsanlar en önemli bileşen başarı. Bireysel ekip üyeleri ve iyi iletişim, yüksek performanslı ekipler için çok önemlidir. İletişimi kolaylaştırmak için çevik uygulamalar, iş sonuçlarının sık sık tartışılmasını ve kararlarda yapılan değişiklikleri içerir. Tartışmalar günlük olarak birkaç dakika süreyle ve her yinelemenin sonunda, çalışmanın sonuçlarının bir analizi ve geriye dönük bir inceleme ile yapılabilir. Toplantılar sırasında etkili iletişim için ekip üyeleri aşağıdakilere uymalıdır: anahtar kurallar davranışlar:

• her ekip üyesinin görüşüne saygı;
• herhangi bir iletişimde dürüst olun;
• tüm verilerin, eylemlerin ve kararların şeffaflığı;
• her katılımcının takımı destekleyeceğine dair güven;
• takıma ve hedeflerine bağlılık.

Çevik metodolojilerde yüksek performanslı ekipler oluşturmak için etkili bir ekip ve iyi iletişimin yanı sıra mükemmel yazılım araçlarına ihtiyaç vardır.

Çalışan yazılım, kapsamlı dokümantasyondan daha önemlidir. Tüm çevik metodolojiler, müşteriye önceden belirlenmiş aralıklarla çalışan küçük yazılım parçaları sunma ihtiyacını vurgular. Yazılım, kural olarak, sistem düzeyinde test olan birim testi düzeyini geçmelidir. Dokümantasyon miktarı minimumda tutulmalıdır. Tasarım sürecinde ekip, kararın gerekçesini ve yapının tanımını içeren kısa bir belgeyi güncel tutmalıdır.

Müşteri ile işbirliği, sözleşme kapsamındaki resmi anlaşmalardan daha önemlidir. Projenin başarıyla tamamlanabilmesi için müşteri ile düzenli ve sık iletişim gereklidir. Müşteri, yazılım üzerinde alınan kararların tartışılmasına düzenli olarak katılmalı, isteklerini ve yorumlarını ifade etmelidir. Müşteriyi yazılım geliştirme sürecine dahil etmek, kaliteli bir ürün yaratmak için gereklidir.

Değişime hızlı yanıt vermek, bir planı takip etmekten daha önemlidir. Değişime yanıt verme yeteneği, bir yazılım projesinin başarısını büyük ölçüde belirler. Bir yazılım ürünü oluşturma sürecinde genellikle değişirler. müşteri gereksinimleri. Müşteriler, genellikle işe yaradığını görene kadar tam olarak ne istediklerini bilmiyorlar. yazılım. Çevik metodolojiler, bir yazılım ürünü oluşturma sürecinde müşterilerden geri bildirim arar. Değişime duyarlılık, müşteri memnuniyeti ve iş değeri sağlayan bir ürün yaratmak için esastır.

Çevik gelişimin ilkeleri 12 ilke tarafından desteklenir. Çevik spesifik metodolojiler, bu ilkelere az çok uyan süreçleri ve kuralları tanımlar. Yazılım ürünleri oluşturmaya yönelik esnek metodolojiler aşağıdaki ilkelere dayanmaktadır:

1. En yüksek öncelik, müteakip yazılımlarla kısa sürede faydalı yazılımların teslimi yoluyla müşterinin isteklerini karşılamaktır. sürekli güncelleme. Çevik uygulamalar, hızlı ilk sürüm ve sık güncellemeleri içerir. Ekibin amacı, projeye başladıktan sonraki birkaç hafta içinde çalışan bir sürüm sunmaktır. Daha öte yazılım sistemleri kademeli olarak genişleyen işlevsellik ile birkaç haftada bir gönderilmelidir. Müşteri başlayabilir ticari operasyon sistem, yeterince işlevsel olduğunu düşünüyorsa. Ayrıca, müşteri basitçe okuyabilir şimdiki versiyonu yazılım, geri bildiriminizi yorumlarla sağlayın.
2. Geliştirmede geç olsa bile değişen gereksinimleri göz ardı etmeyin. Çevik süreçler, değişikliklerin sağlanması için uyum sağlanmasına izin verir. rekabet avantajı müşteri. Çevik metodolojileri kullanan ekipler, değişikliklerin bir bütün olarak sistem üzerindeki minimum etkisi ile program yapısını yüksek kalitede yapmaya çalışır.
3. Yazılımın yeni çalışan sürümlerini, bir haftadan iki aya kadar aralıklarla, daha kısa teslim tarihleri ​​tercihiyle sık sık teslim edin. Aynı zamanda amaç, minimum eşlik eden belgelerle, kullanıcının ihtiyaçlarını karşılayan bir program sunmaktır.
4. Müşteriler ve geliştiriciler proje boyunca birlikte çalışmalıdır. Başarılı bir proje için müşterilerin, geliştiricilerin ve tüm paydaşların, yazılım ürününü amaçlı olarak geliştirmek için sık sık ve birçok şekilde iletişim kurması gerektiğine inanılmaktadır.
5. Projeler motive olmuş insanlar tarafından uygulanmalıdır. Proje ekibine sağlıklı bir çalışma ortamı sağlayın, ihtiyaç duydukları desteği sağlayın ve ekip üyelerinin işi yapacaklarına güvenin.
6. Geliştirme ekibine bilgi aktarmanın ve ekip içinde fikir alışverişinde bulunmanın en etkili ve verimli yöntemi yüz yüze görüşmedir. Çevik projelerde, ana iletişim modu basit insan etkileşimidir. Yazılı dokümanlar, yazılım geliştikçe ve sadece gerektiğinde aşamalı olarak oluşturulur ve güncellenir.
7. Çalışan bir program, proje ilerlemesinin ana göstergesidir. Çevik bir projenin tamamlanma yaklaşımı, ne kadar mevcut olduğuna göre değerlendirilir. şu an program müşterinin gereksinimlerini karşılar.
8. Çevik süreçler uzun vadeli gelişimi teşvik eder. Müşteriler, geliştiriciler ve kullanıcılar, süresiz olarak sabit bir hızı sürdürebilmelidir.
9. Mühendislik mükemmelliğine ve kaliteli tasarıma aralıksız odaklanma, çevik teknolojilerin getirilerini artırır. Çevik ekip üyeleri, düzenli olarak yeniden düzenleme yaparak kaliteli kod oluşturmaya çalışır.
10. Sadelik, daha azını yaparak daha fazlasını elde etme sanatıdır. Ekip üyeleri, mevcut görevleri mümkün olduğunca basit ve verimli bir şekilde çözer. Gelecekte bir sorun olursa, kalite kodunda büyük bir ücret ödemeden değişiklik yapmak mümkündür.
11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden gelir. Esnek ekiplerde görevler bireysel üyelere değil, bir bütün olarak ekibe atanır. Ekip, müşterinin gereksinimlerinin en iyi nasıl uygulanacağına kendisi karar verir. Ekip üyeleri, projenin tüm yönleri üzerinde işbirliği içinde çalışır. Her katılımcının ortak amaca katkıda bulunmasına izin verilir. Hiçbir ekip üyesi mimariden, gereksinimlerden veya testlerden tek başına sorumlu değildir.
12. Ekip düzenli olarak nasıl daha da etkili olabileceğini düşünmeli ve ardından davranışlarını buna göre ayarlamalı ve ince ayar yapmalıdır. Çevik bir ekip, organizasyonunu, kurallarını, anlaşmalarını ve ilişkilerini sürekli olarak ayarlar.

Yukarıdaki ilkeler, bir dereceye kadar, bir dizi yazılım geliştirme metodolojisine karşılık gelir:

Çevik Modelleme	yazılım geliştirme projelerinde modelleme ve dokümantasyonu hızlı ve kolay bir şekilde gerçekleştirmenizi sağlayan bir dizi kavram, ilke ve teknik (pratik);
Çevik Birleşik Süreç (AUP)	iş uygulamaları için yazılım oluşturmaya yönelik basit ve anlaşılır bir yaklaşımı (modeli) açıklayan IBM RationalUnifiedProcess(RUP) ürününün basitleştirilmiş bir sürümü;
OpenUP	yinelemeli-artımlı bir yazılım geliştirme yöntemidir. Hafif ve esnek bir RUP seçeneği olarak konumlandırılan;
Çevik Veri Yöntemi	farklı işlevler arası ekiplerin işbirliği yoluyla gereksinimlerin ve çözümlerin elde edildiği bir grup yinelemeli yazılım geliştirme yöntemi;
DSDM	hızlı uygulama geliştirme (RapidApplicationDevelopment, RAD) kavramına dayalı dinamik sistemler geliştirmeye yönelik bir metodoloji. Sürece devam eden kullanıcı/tüketici katılımını vurgulayan yinelemeli ve artımlı bir yaklaşımı temsil eder;
Aşırı programlama (XP)	aşırı programlama;
Uyarlanabilir yazılım geliştirme (ADD)	uyarlanabilir yazılım geliştirme;
Özellik odaklı geliştirme (FDD)	kademeli olarak işlevsellik eklenmesine odaklanan geliştirme;
Gerçekleşmek	web uygulamaları için kullanılan işlevsel özellikleri olmayan yinelemeli bir yaklaşım;
MSFfogAgileYazılım Geliştirme	Microsoft'tan çevik yazılım geliştirme metodolojisi;
Scrum	geliştirme sürecini yönetmek için kurallar belirler ve gereksinimleri ayarlayarak veya taktik değişiklikler yaparak mevcut kodlama uygulamalarını kullanmanıza olanak tanır [