RAD Nedir? Hızlı Uygulama Geliştirme

Merhaba, bu yazımda RAD Nedir? Hızlı Uygulama Geliştirme yani Rapid application development nedir ona bakacağız. RAD bazen RAB olarak da anılabilmektedir. RAB ise Rapid Application Building anlamına geliyor. Hadi gelin rad nedir? bir bakalım.

RAD Nedir? Hızlı Uygulama Geliştirme

RAD Nedir?

Hızlı uygulama building (RAB) olarak da adlandırılan hızlı uygulama geliştirme (RAD), hem uyarlanabilir yazılım geliştirme yaklaşımları için genel bir terim hem de James Martin’in hızlı geliştirme yönteminin adıdır. Genel olarak, yazılım geliştirmeye yönelik RAD yaklaşımları, planlamaya daha az ve uyarlanabilir bir sürece daha fazla önem verir. Prototipler genellikle tasarım spesifikasyonlarına ek olarak ve hatta bazen onların yerine kullanılır.

RAD, kullanıcı arabirimi gereksinimleri tarafından yönlendirilen yazılım geliştirmek için (bunlarla sınırlı olmamakla birlikte) özellikle uygundur. Grafiksel kullanıcı arabirimi oluşturucularına genellikle hızlı uygulama geliştirme araçları denir. Hızlı gelişmeye yönelik diğer yaklaşımlar, uyarlanabilir, çevik, sarmal ve birleşik modelleri içerir.

RAD Tarihi 

Hızlı uygulama geliştirme, 1970’lerde ve 1980’lerde geliştirilen, Yapılandırılmış Sistemler Analizi ve Tasarım Yöntemi (SSADM – Structured Systems Analysis and Design Method) gibi plan odaklı şelale süreçlerine bir yanıttı. Bu yöntemlerle ilgili sorunlardan biri, köprüler ve binalar gibi şeyleri tasarlamak ve inşa etmek için kullanılan geleneksel bir mühendislik modeline dayanmalarıdır. Yazılım, doğası gereği farklı bir yapıt türüdür. Yazılım, bir sorunu çözmek için kullanılan tüm süreci kökten değiştirebilir.

Sonuç olarak, geliştirme sürecinin kendisinden edinilen bilgi, çözümün gereksinimlerine ve tasarımına geri dönebilir. Plana dayalı yaklaşımlar, gereksinimleri, çözümü ve bunu uygulama planını katı bir şekilde tanımlamaya çalışır ve değişiklikleri caydıran bir sürece sahiptir. RAD yaklaşımları ise yazılım geliştirmenin bilgi yoğun bir süreç olduğunu kabul eder ve çözümü geliştirmek veya uyarlamak için proje sırasında kazanılan bilgilerden yararlanmaya yardımcı olan esnek süreçler sağlar.

Bu tür ilk RAD alternatifi Barry Boehm tarafından geliştirildi ve spiral model olarak biliniyordu. Boehm ve sonraki diğer RAD yaklaşımları, titiz tasarım spesifikasyonlarının yanı sıra veya bunun yerine prototiplerin geliştirilmesini vurguladı. Prototiplerin geleneksel spesifikasyonlara göre çeşitli avantajları vardı:

• Risk azaltma. Bir prototip, sistemin en zor potansiyel parçalarından bazılarını yaşam döngüsünün başlarında test edebilir. Bu, bir tasarımın fizibilitesi hakkında değerli bilgiler sağlayabilir ve ekibin uygulanması çok karmaşık veya zaman alıcı olduğu ortaya çıkan çözümleri takip etmesini engelleyebilir. Sorunları daha sonra değil, yaşam döngüsünün başlarında bulmanın bu faydası, RAD yaklaşımının önemli bir faydasıydı. Bir sorun ne kadar erken bulunursa, çözülmesi o kadar ucuz olur.
• Kullanıcılar, spesifikasyonları oluşturmaktan çok kullanmakta ve tepki vermekte daha iyidirler. Şelale modelinde, bir kullanıcının bir dizi gereksinimi onaylaması yaygındı, ancak daha sonra uygulanan bir sistemle sunulduğunda, belirli bir tasarımın bazı kritik özelliklerden yoksun olduğunu veya çok karmaşık olduğunu aniden fark etti. Genelde çoğu kullanıcı, sistemin ne olması gerektiğini soyut olarak tanımlamak yerine, çalışan sistemin bir prototipini deneyimleyebildiklerinde çok daha faydalı geri bildirimde bulunur.
• Prototipler kullanılabilir ve tamamlanmış ürüne dönüşebilir. Bazı RAD yöntemlerinde kullanılan bir yaklaşım, sistemi, tamamlanmış sistem için minimum işlevsellikten orta derecede yararlıya doğru gelişen bir dizi prototip olarak oluşturmaktı. Bunun yukarıdaki iki avantajın yanı sıra avantajı, kullanıcıların yararlı iş işlevselliğini süreçte çok daha erken elde edebilmeleriydi.

Barry Boehm ve diğerlerinin fikirlerinden yola çıkan James Martin, 1980’lerde IBM’de hızlı uygulama geliştirme yaklaşımını geliştirdi ve son olarak 1991’de Rapid Application Development adlı bir kitap yayınlayarak bunu resmileştirdi. Bu, BT uzmanları arasında bile RAD terimi üzerinde bir miktar kafa karışıklığına neden oldu. Şelale modeline genel bir alternatif olarak RAD ile Martin tarafından oluşturulan özel yöntem olarak RAD arasında ayrım yapmak önemlidir. Martin yöntemi, bilgi yoğun ve kullanıcı arayüzü yoğun iş sistemlerine göre uyarlanmıştır.

Bu fikirler, RAD Metodolojisini gerçek anlamda sürerken ve rafine ederken bir RAD proje yöneticisinin yolculuğunu izleyen Inside RAD adlı konuyla ilgili ufuk açıcı kitabı birlikte yazan James Kerr ve Richard Hunter gibi RAD öncüleri tarafından daha da geliştirildi ve geliştirildi. -gerçek bir RAD projesinde zaman. Bu uygulayıcılar ve onlar gibi olanlar, geleneksel sistem proje yaşam döngüsü yaklaşımlarına bir alternatif olarak RAD’nin popülerlik kazanmasına yardımcı oldu.

James Martin RAD yöntemi

James Martin’in RAD’ye yaklaşımı, süreci dört farklı aşamaya böler:

• Gereksinim Planlama Aşaması – Sistem Geliştirme Yaşam Döngüsünün (SDLC – Systems Development Life Cycle) sistem planlama ve sistem analizi aşamalarının unsurlarını birleştirir. Kullanıcılar, yöneticiler ve BT personeli, iş ihtiyaçları, proje kapsamı, kısıtlamalar ve sistem gereksinimleri üzerinde tartışır ve anlaşırlar. Ekip, kilit konular üzerinde anlaşmaya vardığında ve devam etmek için yönetim yetkisini aldığında sona erer.
• Kullanıcı Tasarımı Aşaması – bu aşamada, kullanıcılar sistem analistleriyle etkileşime girer ve tüm sistem süreçlerini, girdilerini ve çıktılarını temsil eden modeller ve prototipler geliştirir. RAD grupları veya alt grupları, kullanıcı ihtiyaçlarını çalışan modellere dönüştürmek için tipik olarak Ortak Uygulama Tasarımı (JAD – Joint Application Design ) teknikleri ve CASE Araçları’nın bir kombinasyonunu kullanır. Kullanıcı tasarımı, kullanıcıların ihtiyaçlarını karşılayan sistemin çalışan bir modelini anlamalarını, değiştirmelerini ve nihayetinde onaylamalarını sağlayan sürekli etkileşimli bir süreçtir.
• İnşaa Etme Aşaması – SDLC’ye benzer program ve uygulama geliştirme görevine odaklanır. Ancak RAD’de kullanıcılar katılmaya devam eder ve gerçek ekranlar veya raporlar geliştirildikçe değişiklik veya iyileştirmeler önermeye devam edebilir. Görevleri programlama ve uygulama geliştirme, kodlama, birim entegrasyonu ve sistem testidir.
• Geçiş Aşaması – veri dönüştürme, test etme, yeni sisteme geçiş ve kullanıcı eğitimi dahil olmak üzere SDLC uygulama aşamasındaki son görevlere benzer. Geleneksel yöntemlerle karşılaştırıldığında, tüm süreç sıkıştırılır. Sonuç olarak, yeni sistem çok daha kısa sürede kurulur, teslim edilir ve işletime alınır.

RAD Avantajları

Modern Bilgi Teknolojisi ( IT ) ortamlarında, birçok sistem artık bir dereceye kadar Hızlı Uygulama Geliştirme kullanılarak inşa edilmektedir (James Martin yaklaşımı olması gerekmez). RAD geliştirme için Martin’in yöntemine ek olarak, Çevik Yöntemler ve Rational Unified Process sıklıkla kullanılır.

RAD’nin iddia edilen avantajları şunları içerir:

• Daha iyi kalite. Kullanıcıların gelişen prototiplerle etkileşime girmesini sağlayarak, bir RAD projesinden elde edilen iş işlevselliği, genellikle bir şelale modeliyle elde edilenden çok daha yüksek olabilir. Yazılım daha kullanışlı olabilir ve geliştiricileri ilgilendiren teknik sorunlardan ziyade son kullanıcılar için kritik olan iş sorunlarına odaklanma şansı daha yüksektir. Ancak bu, güvenlik ve taşınabilirlik dahil, genellikle işlevsel olmayan gereksinimler (AKA kısıtlamaları veya kalite özellikleri) olarak bilinen diğer kategorileri hariç tutar.
• Risk kontrolü. RAD ile ilgili literatürün çoğu hız ve kullanıcı katılımına odaklansa da, RAD’nin doğru bir şekilde yapılması kritik bir özelliği risk azaltmadır. Boehm’in başlangıçta spiral modeli riske dayalı bir yaklaşım olarak nitelendirdiğini hatırlamakta fayda var. Bir RAD yaklaşımı, temel risk faktörlerine erkenden odaklanabilir ve sürecin ilk bölümünde toplanan ampirik kanıtlara dayanarak bunlara uyum sağlayabilir. Örneğin, sistemin en karmaşık parçalarından bazılarını prototiplemenin karmaşıklığı.
• Zamanında ve bütçe dahilinde tamamlanan daha fazla proje. Artımlı birimlerin geliştirilmesine odaklanılarak, büyük şelale projelerinin peşini bırakmayan yıkıcı başarısızlık şansı azalır. Şelale modelinde, tüm sistemin radikal bir şekilde yeniden düşünülmesini gerektiren altı ay veya daha fazla analiz ve geliştirmeden sonra bir sonuca varmak yaygındı. RAD ile bu tür bilgiler keşfedilebilir ve süreçte daha erken harekete geçilebilir.

RAD Dezavantajları

RAD’nin iddia edilen dezavantajları şunları içerir:

• Yeni bir yaklaşımın riski. Çoğu BT mağazası için RAD, deneyimli profesyonellerin çalışma biçimlerini yeniden düşünmelerini gerektiren yeni bir yaklaşımdı. İnsanlar neredeyse her zaman değişime karşı isteksizdir ve yeni araçlar veya yöntemlerle üstlenilen herhangi bir projenin, yalnızca ekibin öğrenme gereksinimi nedeniyle ilk seferde başarısız olma olasılığı daha yüksektir.
• Normal çalışmada genellikle son kullanıcı tarafından görülmeyen, işlevsel olmayan gereksinimlere vurgu yapılmaması.
• Kıt kaynakların zamanını gerektirir. Neredeyse tüm RAD yaklaşımlarının ortak noktası, kullanıcılar ve geliştiriciler arasında tüm yaşam döngüsü boyunca çok daha fazla etkileşim olmasıdır. Şelale modelinde, kullanıcılar gereksinimleri tanımlayacak ve ardından geliştiriciler sistemi oluştururken çoğunlukla ortadan kalkacaktır. RAD’de kullanıcılar baştan ve neredeyse tüm projeye dahil olurlar. Bu, işletmenin uygulama alanı uzmanlarının zamanına yatırım yapmaya istekli olmasını gerektirir. Paradoks şudur ki, uzman ne kadar iyi olursa, kendi alanlarına o kadar aşina olurlar, işi fiilen yürütmek için o kadar çok ihtiyaç duyarlar ve denetçilerini zamanlarını ayırmaya ikna etmek zor olabilir. Bu tür taahhütler olmadan RAD projeleri başarılı olmayacaktır.
• Daha az kontrol. RAD’nin avantajlarından biri, esnek ve uyarlanabilir bir süreç sağlamasıdır. İdeal olan, hem sorunlara hem de fırsatlara hızla uyum sağlayabilmektir. Esneklik ve kontrol arasında kaçınılmaz bir değiş tokuş vardır, birinin daha fazla olması diğerinin daha az olması anlamına gelir. Bir proje (örneğin, hayati önem taşıyan yazılım) değerleri çeviklikten daha fazlasını kontrol ediyorsa RAD uygun değildir.
• Kötü tasarım. Prototiplere odaklanma, bazı durumlarda geliştiricilerin sürekli olarak ayrı bileşenlerde küçük değişiklikler yaptığı ve daha iyi bir genel tasarımla sonuçlanabilecek sistem mimarisi sorunlarını göz ardı ettiği bir “hack ve test” metodolojisiyle sonuçlanan çok ileri götürülebilir. Bu, özellikle Martin’inki gibi sistemin kullanıcı arayüzüne çok fazla odaklanan metodolojiler için bir sorun olabilir.
• Ölçeklenebilirlik eksikliği. RAD tipik olarak küçük ve orta ölçekli proje ekiplerine odaklanır. Yukarıda belirtilen diğer sorunlar (daha az tasarım ve kontrol), çok büyük ölçekli sistemler için bir RAD yaklaşımı kullanırken özel zorluklar ortaya çıkarır.

RAD Nedir? Hızlı Uygulama Geliştirme yazımda buraya kadardı. Rad Nedir? sorusuna güzelce cevap verdiğimizi düşünüyorum. Umarım faydalı olur.

Discord’a katılmayı unutmayın. Bu konuları içeren udemy kursum için hazırladığım timeline sayfasına bağlantıya tıklayarak ulaşabilirsiniz.  Tüm Üretim ve Yönetim Sistemleri kategorisine ait yazılara da bağlantıya tıklayarak ulaşabilirsiniz.

Diğer yazılarımızda görüşmek üzere…