HIZLI UYGULAMA GELİŞTİRME (RAPID APPLICATION DEVELOPMENT)

 

Hızlı uygulama geliştirme (RAD), uygulamaları sık yinelemeler ve sürekli geri bildirim yoluyla hızla geliştirmeye odaklanan bir metodolojidir.

RAD çerçevesi, 1991 yılında, yazılımın geliştirme modellerini tasarlamak için sonsuz işlenebilirliğini tanıyan ve bundan yararlanan teknoloji danışmanı ve yazar James Martin tarafından tanıtıldı. RAD, çevik proje yönetiminin öncüsü oldu ve büyüyen iş ve müşteri ihtiyaçlarına ayak uyduran yöntemler arayan çevik işletmeler arasında giderek daha popüler hale geldi. Maliyetli planlamadan ziyade hızlı prototip oluşturmaya ve yinelemelere odaklanan hızlı uygulama geliştirmedir.

Hızlı uygulama geliştirme, çalışan yazılımların erken ve sürekli teslimi yoluyla müşteri memnuniyetine odaklanarak, geleneksel yazılım geliştirme yöntemlerinde bulunan komplikasyonları hafifletir. Hız vurgulanırken, belirli zaman dilimleri tavsiye edilmez. RAD, geliştirmenin sonlarında bile değişen gereksinimleri memnuniyetle karşılar. Tüm paydaşlar ilerlemeyi ölçmek, sorunları çözmek ve verimliliği artırmak için sık sık iletişim kurar. Müşterinin geliştirme döngüsü boyunca aktif olarak yer alması, kullanıcı gereksinimlerine uymama riskini azaltarak zamandan ve paradan tasarruf sağlar.

RAD AŞAMALARI


1.Proje Gereksinimlerin Tanımlanması

Bu aşamada geliştirilecek uygulamanın etki edeceği sahanın bir ön değerlendirmesi yapılır. Kabaca sistemin neler içerdiği ve bu yönde yazılımın sahip olması gereken fonksiyonları belirlenmeye çalışılır.


Tüm proje paydaşları - geliştiriciler, müşteriler, yazılım kullanıcıları ve ekipler - proje gereksinimlerini ve geliştirme sırasında ortaya çıkabilecek olası sorunları ele alma stratejilerini belirlemek için iletişim kurar.


Gereksinimler:

  • Hedefleri 

  • Beklentileri

  • Zaman çizelgelerini 

  • Bütçeyi 

içerir.

Müşteri, ürün için bir vizyon sağlar. Diğer paydaşlarla işbirliği içinde, her paydaşın onayı ile gereksinimleri sonuçlandırmak için bir araştırma yapılır. Geliştirme döngüsünün başlarında her paydaşın aynı sayfada olmasını sağlamak, ekiplerin iletişimsizlikten ve maliyetli hatalardan kaçınmasına yardımcı olur. 


2.Prototipleme



Bir projenin kapsamı belirlendikten sonra, ekipler ilk modelleri ve prototipleri oluşturmaya başlar. Amaç, müşteriye gösterilebilecek bir çalışma tasarımını hızla üretmektir. Geliştiriciler ve tasarımcılar, müşterinin ihtiyaçlarının karşılandığından emin olmak için nihai ürün hazır olana kadar müşterilerle el ele çalışır. Bu adım, genellikle proje geliştikçe gerektiği kadar tekrarlanır. 


Hızla oluşturulmuş prototiplerin kullanımı, bir tasarım belgesinin soyut değerlendirmelerini yapmaya çalışmak yerine, canlı bir sistemde kullanıcı katılımını, testi ve geri bildirimi teşvik eder. Paydaşlar, neyin işe yarayıp neyin yaramadığını hızlı ve kolay bir şekilde belirleyerek deneyimler yoluyla iletişim kurar ve öğrenirler. Böylelikle hataların daha erken keşfedilme olasılığı çok daha yüksektir.


Son kullanıcılar ve BT personeli, sistem süreçlerini birlikte geliştirir. Bu, Son kullanıcıların, ihtiyaçlarını karşılayan sistemin çalışan bir modelini anlamasına, değiştirmesine ve sonunda onaylamasına olanak tanıyan sürekli etkileşimli bir süreç olmalıdır.


Sonuç olarak, 

  • Yazılım daha sağlamdır.

  • Daha az hataya açıktır.

  • Gelecekteki tasarım eklemeleri için daha iyi yapılandırılmıştır.


3.Hızlı Yapılandırma ve Geri Bildirim Toplama

Hızlı yapılandırma, uygulama kodlamasının, sistem testinin ve birim entegrasyonunun gerçekleştiği, prototip ve beta sistemlerini çalışan bir modele dönüştürdüğü yerdir. Bu aşama, yeni bileşenleri ve değişiklikleri destekleyerek gerektiği kadar tekrar edilebilir.


Kullanıcı sorunlarının ve istemci değişikliklerinin çoğu, yinelemeli prototip oluşturma aşamasında ele alındığından, geliştiriciler, geleneksel bir geliştirme yaklaşımını izlediklerinden daha hızlı bir son çalışma modeli oluşturabilirler. Yazılım ve uygulamalar bu aşamada kapsamlı bir şekilde test edilir ve nihai sonucun müşteri beklentilerini ve hedeflerini karşılamasını sağlar. Geliştiriciler, arayüz ve işlevsellik hakkında geri bildirim toplamak ve ürünün tüm yönlerini iyileştirmek için müşteriler ve son kullanıcılarla birlikte çalışır.


Müşteriler, keşfedildikçe sorunları çözen değişiklikler veya yeni fikirler önererek bu aşama boyunca kapsamlı girdi verir. Müşteriler pratikte bazı kavramların işe yaramadığını görebilir. Bu girdiyle, geliştiriciler ya prototip oluşturmaya devam eder ya da geri bildirim kesinlikle olumluysa, son adıma geçer.


4.Uygulamayı Sonlandırma 

Burada yazılımın özellikleri, işlevleri, estetiği ve arayüzü müşteri ile birlikte son halini alır. 


Müşteriye teslim edilmeden önce 

  • Kararlılık 

  • Kullanılabilirlik  

  • Sürdürülebilirlik 

çok önemlidir.

Uygulama aşaması, geliştirme ekiplerinin bileşenleri, gerekli tam ölçekli testlerin veya eğitimin gerçekleştirilebileceği canlı bir üretim ortamına taşıdığı yerdir. Ekipler müşteriye eksiksiz bir ürün vermeden önce eksiksiz dokümantasyon yazar ve gerekli diğer bakım görevlerini tamamlar.


RAD NE ZAMAN KULLANILABİLİR?


Hızlı Biten Bir Projeye İhtiyaç Varsa

Sınırlı bir teslim tarihi ve sistemi kısa sürede (2-3 ayda) üretme ihtiyacı varsa, hızlı uygulama geliştirme iyi bir seçimdir.


Prototiplerin Güvenilir Şekilde Test Edilebileceği Zaman

Yapılan prototipler hakkında tutarlı ve güvenilir geri bildirimde bulunabilecek bir kullanıcı havuzu varsa, RAD takip etmek için harika bir modeldir. RAD modeli aracılığıyla oluşturulan prototipler, önceki yinelemelerden alınan geri bildirimlere bağlıdır, bu nedenle güvenilir kaynaklardan gelen güvenilir geri bildirimler son derece yardımcı olabilir.


Yeterli Bütçeye Sahip Olunduğunda

Diğer geliştirme modelleriyle karşılaştırıldığında, hızlı uygulama geliştirme nispeten ucuzdur, ancak hızlı uygulama geliştirmenin pahalı olabileceği bazı durumlar da vardır. Yetenekli personeli işe almak, onlara uygun maaşlar verilmesi gerektiği anlamına gelir. İşin iyi yanı, eğer böyle bir kadro varsa fikrin diğer modellerden çok daha hızlı geliştirilmesi sağlanabilir.





AVANTAJLARI
  • İncelemeler hızlıdır.
  • Geliştirme süresi büyük ölçüde azalır.
  • Prototipler ve yinelemeler arasındaki süre kısadır.
  • Daha az insanla daha fazla üretkenlik mevcuttur.
  • Gereksinimler herhangi bir zamanda değiştirilebilir.
  • Müşteri geri bildirimini teşvik eder ve önceliklendirir.

DEZAVANTAJLARI
  • Büyük ekiplerle çalışamaz.
  • Çok yetenekli geliştiricilere ihtiyaç duyar.
  • Ürünün yaşam döngüsü boyunca kullanıcı gereksinimine ihtiyaç duyar.
  • Yalnızca modüler hale getirilebilen sistemler geliştirilebilir.
  • Yalnızca geliştirme süresinin kısa olduğu projeler için uygundur.

RAD vs WATERFALL



WATERFALL


RAD

Planlanmış bir programı takip eder. Önemli değişiklikler ortaya çıkarsa, projenin baştan başlaması gerekir.


Zaman

Açık uçludur. Müşteri mutlu olduğunda proje yapılır.

Çok küçük veya çok büyük projelerde kullanılır.

İdeal 

Proje 

Boyutu


Küçük-orta ölçekli projelerde kullanılır.

Ekibin katı hiyerarşik yapısı nedeniyle projenin küçüklüğü büyüklüğü farketmeksizin 15 kişiden fazla olabilir.

Ekipteki 

Üye 

Sayısı


Ekip küçük olmalıdır. (Genellikle 3-9 ekip üyesi civarında)

Çok tecrübeli kişiler olma zorunluluğu yoktur.

Ekip 

Deneyimi

Çok yetenekli, çok deneyimli, esnek ve çeşitli becerilere sahip kişiler olmalıdır.

Son derece dokunaklı ve başından itibaren ne istediklerini tam olarak bilir.

En İyi 

Müşteri

Sürece çok dahil olan, fikirlere ve önerilere açık ve büyük resmi paylaşabilen iyi bir iletişimcidir.

Potansiyel riskleri başlangıçta değerlendirilir ve hesaba katılır. Başka riskler ortaya çıkarsa, bunlara öncelik verilmemeli veya proje yol haritasını bozmamalıdır.



Risk


Risklere sürekli yanıt verir ve hazırlıklıdır.

Değişim, proje yol haritası için son derece olumsuz ve yıkıcı veya zararlı olarak görülür.


Değişim

Değişim memnuniyetle karşılanır ve benimsenir.

Özellikler belirlendikten sonra hiçbir değişiklik yapılamaz.

Yeni 

Teknoloji

Her an yeni değişiklikler ve uyarlamalar getirilebilir.

Projenin kapsam belirlemeye dönmesine neden olan hiçbir değişiklik olmadığı varsayılarak maliyetler sabittir.


Maliyet


Yineleme sayısına bağlı olarak değişkenlik gösterir.



RAD vs AGILE


Genellikle araştıranlar geliştirme metodolojilerini karşılaştırır. En yaygın olarak, hızlı uygulama geliştirme, doğrudan Agile ile karşılaştırılır. Ne yazık ki, bu karşılaştırmayı yapmak zordur. RAD, çevikliğin atasıdır, ancak Agile, bir geliştirme modelinden çok daha fazlasını kapsar. Bir metodolojiden çok bir felsefedir.


Agile, RAD'den çok daha sonra tanıtıldığından, nispeten daha gelişmiş ve aynı zamanda daha popüler olanıdır.


Agile, RAD'den farklı olarak, modellerine ve ideal çalışma ortamına daha fazla vurgu yapar. Öte yandan, RAD çok daha elastik bir modeldir. Sunum için kullanılan teknikler ve zaman çerçevesinden çok, sonucun kalitesine odaklanır. Bu nedenle, iyi kurulmuş Agile modellere sahip olmayan kuruluşlar, ideal geliştirme modeli olarak genellikle RAD'yi tercih eder.


Her iki durumda da, erken ve sürekli yazılım teslimi ve geliştirmenin sonraki aşamalarında bile değişen gereksinimler için önemli bir vurgu vardır.




KAYNAKÇA




Yorumlar

Bu blogdaki popüler yayınlar

Operasyonel Mükemmellik (OPEX) Araçları

Kullanıcıların Senaryoları Use Case'ler

Değer Akışı Haritalama / Value Stream Mapping