Çevik yöntemler kullanarak proje geliştirme yeni bir şey değil. Bu yazıda, sistemin mimari tasarımının Çevik geliştirmeye nasıl uyduğunu tartışacağız.
Çevik yöntemler kullanarak proje geliştirme yeni bir şey değil. Ancak, çevik projelerde bir sistemin mimarisini tasarlamaya gerek olmadığı fikrini ilişkilendirmek çok yaygındır. Geri kalan soru şudur: Sistemin mimari tasarımı Çevik geliştirmeye nasıl uyar?
Pek çoğu, çevik bir geliştirme senaryosunda, mimariyi düşünmeyi bırakmanın yararlı olmadığını, böylece mimarinin zaman içinde kaçınılmaz olarak değişeceğini tartışacaktır. Bu ifadenin ikinci kısmına katılıyoruz, proje sırasında mimari değişecek ve proje süresi ne kadar uzun olursa, başlangıçta tanımlanan mimaride değişiklik olasılığı o kadar yüksek olur.
Mimari planlamaya karşı algının ve bu faaliyetin bürokratik bir şey ve hatta çoğu zaman proje ilerlemesinde bir darboğaz olarak anlaşılmasının çoğu, kökenlerini, tahmine dayalı yazılım geliştirme yöntemlerini kullanan yazılım geliştirme deneyimlerinden almaktadır .
Aşağıdaki bölüm, öngörücü ve uyarlanabilir yöntemler arasında bir karşılaştırma sağlar.
Öngörücü / Uyarlanabilir Yöntemler Arasındaki Özellikler ve Ayrımlar
Tahmin Yöntemleri
Geleneksel yazılım geliştirme hakkında her konuştuğumuzda, genellikle tahmine dayalı yazılım geliştirme sürecinden bahsediyoruz. Bu yöntemlerden en yaygın olanı ünlü şelaledir.
Bu tür bir süreçte, açıkça tanımlanmış aşamalar vardır:
Gereksinim - Tüm sistem gereksinimlerini anlama. Gerçekleştirmesi gereken işlevler, hacimsel (statik ve dinamik), entegrasyonlar ve diğer işlevsel veya işlevsel olmayan ihtiyaçlar.
Proje - Bu aşamada sistem tasarımı gerçekleşir. Sistemin dış dünya ile nasıl etkileşime gireceği, veri modelinin ne olacağı, kullanılacak teknolojiler, sınıfları/programları, ilişkileri ve etkileşimleri burada tanımlanır. Bu aşamada sistem mimarisi tanımlanır.
Uygulama - Burada tasarım aşamasında tanımlanan sistemin gerçekleşmesi gerçekleşir. Temel olarak proje kodlanır ve birim test edilir.
Doğrulama - Sistem entegre bir şekilde test edilir ve kullanıcı tarafından onaylanır.
Bakım - Sistem test edildikten, onaylandıktan ve üretime kurulduktan sonra bakım aşamasına girer.
Tahmine dayalı yöntem süreç akışı
Görüldüğü gibi kestirimci yöntemlerde sistem çözümü sürecin hemen başında verilmektedir. Her sistem projesi, başlangıcında algılanan ihtiyaçların bilgisine göre yapılır.
Ayrıca, mimari, bu aşamada verilen mimari kararları doğrulamak için genellikle uygulamalı testler olmaksızın tüm sistem gereksinimlerini önceden karşılayacak şekilde tasarlanmıştır. Seçilen teknolojiler arasındaki uyumsuzluklar ve/veya gereksinimleri karşılayamama gibi tasarım aşamasıyla ilgili sorunların uygulama aşamasında ortaya çıkması nadir değildir.
Bu olduğunda, bir önceki aşamaya geri dönmek ve projeyi değiştirmek gerekir. Proje bir bütün olarak sistem için tasarlandığından, değiştirilmesi genellikle yüksek çaba gerektiren bir iştir (örneğin, tasarım hatasını düzeltmek için tüm belgeleri değiştirmek), sistemin geliştirilmesinde zaman ve maliyet açısından bir etkiye neden olur.
Bu tür bir yöntemle ilgili diğer bir sorun, geliştirme sırasında sistem gereksinimlerinin gözden geçirilmemesidir. Geliştirme döngüsü ne kadar uzun olursa, sistem nihayet üretime geçtiğinde, inşaatına yol açan iş ihtiyaçlarının önemli ölçüde değişme şansı o kadar artar.
Aşağıdaki Şekil bunu örneklemektedir. Zaman, projenin başlarında bir hedefi (algılanan ihtiyaçları) hedefler. Ancak bu ihtiyaçlar zamanla değişir ve sistem sonunda üretime geçtiğinde hedefi kaçırır:
Tahmine dayalı yöntem mimarisi
Uyarlanabilir Yöntemler
"Ürün geliştirme ekipleri, hem mühendislerin hem de yöneticilerin uyum sağlamakta zorlandığı sessiz bir devrimle karşı karşıya. İlaç, yazılım, otomobil, entegre devreler gibi endüstriden sonra endüstride, sürekli yenilik için müşteri talepleri ve düşen deneme maliyeti, büyük bir geçişin sinyallerini veriyor. beklentiden uyarlanabilir gelişim tarzlarına."
Yukarıdaki alıntı, 2009 yılında Agile Project Management kitabında yayınlanan Jim Highsmith'e aittir. Onu tanımayanlar için Jim Highsmith, Çevik Manifesto'nun imzacılarından biridir ve 1999'da ASD - Uyarlanabilir Yazılım Geliştirme'yi öneren kişidir. karmaşık sistemler.
Buradaki uyarlanabilir terimi, sistemin çevresindeki değişikliklere uyarlanacağını açıklamak için kullanılır. Yani: Çevik manifestoda belirtildiği gibi "Bir planı takip etmek yerine değişime yanıt verin".
Çevik geliştirmenin birkaç yöntemi vardır. Bu yöntemler, bir sistemin/ürünün gelişimini küçük artışlar/yinelemelere böler. Bu mola, uygulamadan önce gereken planlama ve tasarım miktarını azaltmanıza olanak tanır. Sanki zaman içinde birkaç şelale döngüsü yaşamışız gibi.
Şelale sıralı akışı
Her döngünün sonunda paydaşlara fonksiyonel bir ürün sunulur. Bu, neyin inşa edildiğinin değerlendirilmesine ve her döngüde sistemin amaçlarının / gereksinimlerinin değiştirilmesi / uyarlanması ihtiyacının doğrulanmasına olanak tanır.
Her yineleme, planlama, analiz, tasarım, kodlama, birim ve kabul testlerini ele alacak çapraz işlevli bir ekip içerir. Amaç, her yinelemenin sonunda üretime bırakılabilen bir ürüne sahip olmaktır. En kısa sürede üretimde test edilen ürün ile tasarımındaki veya yapımına yönelik iş yerlerindeki kusurlar en kısa sürede keşfedilir. Bu bize sistemi / ürünü adapte etme ve rotasını / yönünü düzeltme şansı verir.
Aşağıdaki şekil tam olarak bunu örneklemektedir. Her sürümde / yinelemede (gri daire), üretime sunulan ürün, sistemin karşılaması gereken ihtiyaçların algısı değiştirilir, sistemin planlaması yeniden yapılır, yeni hedefe ulaşmak için rotası düzeltilir (sonradan algılanan ihtiyaç). önceki artışın yayınlanması).
Uyarlanabilir yöntem mimarisi
Çevik mimari
SAFe'de bulunan Çevik Mimari tanımını alarak :
"Çevik Mimari, esasen bir sistemin tasarımını ve evrimsel mimarisini aktif olarak destekleyen bir dizi değer, uygulama ve iş birliğidir. Bu yaklaşım, DevOps zihniyetini benimser ve bir sistemin mimarisinin zaman içinde sürekli olarak gelişmesine izin verirken aynı zamanda destekler. Günümüz kullanıcılarının ihtiyaçlarını karşılar.Başla-dur-başla doğası ve faz kapısı ve Büyük Ön Tasarım (BUFD) süreçlerinde bulunan büyük ölçekli yeniden tasarımla ilişkili ek yükleri ve gecikmeleri önler.
Çevik mimari, işbirliği, yeni ortaya çıkan tasarım, amaçlı mimari ve tasarım basitliği aracılığıyla Çevik geliştirme uygulamalarını destekler. Çevik geliştirme uygulamalarının yanı sıra, Çevik mimari ayrıca test edilebilirlik, uygulama ve yayın için tasarım sağlar. etki alanı ve merkezi olmayan yenilik. "
Bu tanımdan, Gelişen Tasarım ve Kasıtlı Mimari dahil olmak üzere çok önemli iki terim ortaya çıkıyor.
Acil tasarım , geliştirme döngüsündeki bir sonraki artışı uygulamaya ve doğrulamaya yetecek kadar mimariyi analiz etme ve genişletme sürecidir.
Kasıtlı Mimari , büyük resmi görmekle ilgilidir. Büyük şirketlerin, büyük ölçekli mimari girişimlerle yeni iş zorluklarına aynı anda yanıt vermesi gerekiyor. Büyük ölçekte, iş hedefini karşılamak için birden fazla ekip, ürün ve sistemin dahil olacağını anlayabiliriz. Bu durumda Acil Tasarım tek bir takımda sınırlandırıldığı için yeterli değildir. Kasıtlı mimari olmadan, işlevsel olmayan sistem gereksinimlerinin yerine getirilmesini entegre etme, doğrulama ve sürdürme zorluğu, düşük yeniden kullanım, çözüm fazlalığı vb. gibi birçok sorunla karşılaşabiliriz.
Kasıtlı mimari, ekiplere ortak bir hedef / ulaşılacak hedef sunacak, çabaların hizalanmasına ve bağımsız ekiplerin çalışmalarının paralelleştirilmesine izin verecektir. Başka bir deyişle, takımların çalışmaları arasındaki yol gösterici, yapıştırıcı olacaktır.
Çevik Mimari, bu iki gücü dengelemekle ilgilidir. Gelişmekte olan tasarıma çok fazla vurgu yapılırsa, entegre edilmesi zor bileşenler, düşük yazılım kalitesi ve yukarıda ele alınan diğer tüm noktalarla karşılaşacağız. Tersi bir yol izlerseniz, yani gelecekteki mimari bileşenlerin ayrıntı düzeyini abartmaya başlarsak, bu bir darboğaz haline gelebilir ve ekip geliştirme hızınızı büyük ölçüde yavaşlatabilir.
Derinlere inen Agile Architecture, bir sistemin yapısal bileşenlerini ve standartlarını, inşası sırasında algılanan ihtiyaçlardaki (fonksiyonel ve fonksiyonel olmayan gereksinimler) değişikliklere cevap verebilecek şekilde tasarlamak/seçmekle ilgilidir.
Bunu başarmak için büyük bir ön tasarımdan kaçının, ancak son durumunuzun net bir görünümünü belirtin. İstenen son durum zamanla değişecektir ama sorun değil. İkincisi, sisteminizi mümkün olan en kısa sürede deneyin. Her sürümün üretime hazır bir sistem sunduğundan emin olun.Sisteminizin gerçekten değer sağlayıp sağlamadığını test etmenize ve kontrol etmenize olanak tanır ve herhangi bir arızayı (gereksinimlerde veya tasarımda) mümkün olan en kısa sürede belirleyebilir ve gerekli olanı yapabilirsiniz. değişir.
Çözüm
Çevik Mimari, uyarlanabilir yazılım geliştirme yöntemlerinde mimari tasarlamanın yoludur. BUDF - Bid Up Front Design'dan kaçınarak mimarinin her sistem artışıyla gelişmesine izin verir.
Referanslar
Highsmith Jim Robert (2009-07-09T22: 58: 59). Çevik Proje Yönetimi (Çevik Yazılım Geliştirme Serisi). Pearson Eğitimi. Kindle Sürümü.
"
Link:
https://dzone.com/articles/agile-architecture-what-is-it
Hiç yorum yok:
Yorum Gönder