توسعه سریع نرم‌افزار

توسعه سریع نرم‌افزار (RAD) (انگلیسی: Rapid application development‎) یک عنوان کلی برای اشاره به جایگزین‌های معمول مدل آبشاری توسعه نرم‌افزار و همچنین به عنوان نامی برای رویکرد جیمز مارتین برای توسعه سریع است. به‌طور کلی، رویکرد RAD به توسعه نرم‌افزار تأکید کمتری بر برنامه‌ریزی و تمرکز بیشتری بر فرایند دارد. در قیاس با مدل آبشاری که در آن تعریف دقیق مشخصات قبل از ورود به مرحله توسعه، خواسته می‌شود. رویکرد RAD تأکید بیشتری بر سازگاری و ضرورت تنظیم نیازمندی‌ها در پاسخ به دانش به دست آمده در پیشرفت پروژه می‌کند. نمونه‌های اولیه اغلب در کنار و در برخی مواقع به‌جای طراحی مشخصات استفاده می‌شوند.

توسعه نرم‌افزار
فعالیت‌های اصلی
پارادایم‌ها و مدل‌ها
متدولوژی‌ها و چارچوب‌ها
رشته‌های مورد حمایت
کاربردهای عملی
ابزار
استانداردها و بدنه‌های دانش
واژه‌نامه‌ها
  • Artificial intelligence
  • Computer science
  • Electrical and electronics engineering
رئوس مطالب
  • Outline of software development

RAD به خصوص مناسب (البته نه محدود به) توسعه نرم‌افزارهایی است که توسط نیازمندی‌های رابط کاربری هدایت می‌شوند. سازندگان رابط گرافیکی کاربر اغلب به نام ابزار توسعه سریع نرم‌افزار، شناخته می‌شوند. روش‌های دیگر برای توسعه سریع شامل روش‌های چالاک و مدل مارپیچ است.

History

توسعه سریع نرم‌افزار در پاسخ به فرایندهای توسعه یافته در دهه‌های ۱۹۷۰ و ۱۹۸۰ مانند روش‌های ساختاری تجزیه و تحلیل سیستم و دیگر مدل‌های آبشاری به وجود آمد. یکی از مشکلات این روش‌ها این است که آن‌ها بر اساس مدل سنتی مهندسی مورد استفاده برای طراحی و ساخت چیزهایی مانند پل‌ها و ساختمان‌ها، پایه‌گذاری شده‌اند. نرم‌افزار ذاتاً نوع دیگری از محصول است. نرم‌افزار می‌تواند شدیداً کل فرایند مورد استفاده برای حل یک مشکل را تغییر دهد. در نتیجه، دانش به دست آمده از فرایند توسعه خود می‌تواند بازخوردی باشد برای تعیین نیازمندی‌ها و طراحی راه حل.[1] راه‌حل روش آبشاری برای حل این مسئله این بود که نیازمندی‌ها و برنامه‌ریزی برای پیاده‌سازی آن‌ها به شکل صلبی تعیین شوند و فرایندی داشته باشیم که از تغییر هر یک از آن‌ها اجتناب کند. رویکرد جدید RAD از سوی دیگر فرایند توسعه نرم‌افزار را به عنوان فرایندی دانش محور به رسمیت می‌شناسد؛ و به دنبال توسعه فرایندهای انعطاف‌پذیری است که دانش به دست آمده در طول عمر پروژه را برای ابداع دوباره راه‌حل مورد استفاده قرار می‌دهد.

اولین RAD جایگزین توسعه Barry Boehm توسعه داده شد و به عنوان مدل مارپیچ شناخته می‌شود. روش Boehm و دیگر روش‌های RAD پس از آن تاکیید بیشتری بر توسعه نمونهٔ اولیه به جای مشخصات صلب طراحی دارند و در مواردی هم نمونهٔ اولیه را جایگزین این مشخصات صلب طراحی می‌دانند. نمونه‌های اولیه مزایای زیادی نسبت به مشخصات سنتی دارند:

  • کاهش ریسک. یک نمونه اولیه می‌تواند برخی از سخت‌ترین قطعات سیستم را در اوایل چرخهٔ زندگی، تست کند. این می‌تواند اطلاعات ارزشمندی در خصوص امکان‌سنجی طراحی در اختیار قرار دهد و از در نظر دنبال کردن راه‌حل‌هایی که خیلی پیچیده یا خیلی زمانبر هستند جلوگیری کند. اینکه در روش RAD مشکلات در مراحل زودتری از چرخه زندگی نمایان می‌شوند نکتهٔ اصلی مزیت رویکرد RAD است. هدایت یک مشکل هرچه سریعتر شناسایی شود ارزانتر است.
  • کاربران در استفاده کردن و بازخورد نشان دادن بهتر از تعیین مشخصات عمل می‌کنند. رایج بود که در مدل آبشاری کاربر مجموعه‌ای از نیازمندی‌ها را مورد تأیید قرار دهد ولی زمانی که با سیستم پیاده‌سازی شده مواجه می‌شود، ناگهان پی می‌برد که آنچه طراحی شده برخی قابلیت‌های حیاتی را ندارد یا بسیار پیچیده است به‌طور کلی، اکثر کاربران زمانی که تجربه کار با یک نمونه اولیه در حال کار را دارند بازخورد بسیار بهتری می‌دهند تا زمانی که به‌طور انتزاعی تعریف می‌کنند که سیستم باید چگونه عمل کند.
  • نمونه‌های اولیه می‌تواند قابل استفاده باشند و به یک محصول کامل تکامل یابند. یکی از روش‌های مورد استفاده در برخی از روش‌های RAD ساخت این سیستم به عنوان یک سری از نمونه‌های اولیه است؛ که از تکامل یک نمونه اولیه با حداقل قابلیت‌ها شروع و به‌طور مناسب به سمت یک سیستم کامل تکامل میابد. استفاده از این علاوه بر دو مزیت بالا، مزیت دیگری هم دارد که کاربران می‌تواند قابلیت‌های کاربردی را بسیار زودتر در این فرایند در اختیار داشته باشند.[2]

با شروع از ایده‌های بری بوهم و دیگران، James Martin رویکرد توسعه سریع نرم‌افزار را در طول دههٔ ۱۹۸۰ در IBM توسعه داد و در نهایت آن را توسط چاپ کتابی به عنوان توسعه سریع نرم‌افزار در ۱۹۹۱ بیان کرد. این موضوع منجر به برخی سردرگمی‌ها در خصوص عبارت RAD شد، این سردرگمی در میان متخصصان IT هم دیده می‌شد. این مهم است که بین RAD به‌طور کلی و به یک جایگزین برای مدل آبشاری و مدل RAD به عنوان روش خاص ایجاد شده توسط مارتین، تفکیک قائل شویم. روش مارتین برای سیستم‌های کسپ و کاری با بار دانشی و رابط کاربری فشرده طراحی شده‌است.

با تلاش پشگامان روش RAD این ایده بیشتر توسعه یافت و بهینه شد. افرادی مانند James Kerr و Richard Hunter که کتاب اولیه‌ای در خصوص موضوع نگاشته‌اند تحت عنوان Inside RAD[3] که روند یه مدیر پروژه RAD را در پیشبرد و پالایش RAD، دنبال می‌کند. روش‌شناسی در زمان واقعی بر روی یک پروژه حقیقی RAD. این متخصصین و افرادی مشابه آن‌ها کمک کردند تا RAD به عنوان یک جاگزین نسبت به روش سنتی محبوبیت پیدا کند.

در دورانی که مهندسی دوباره کسب و کار رونق یافت، روبکرد RAD به بلوغ رسید. ایده مهندسی مجدد کسب و کار این بود که با توجه به ظرفیت‌های فناوری اطلاعات به‌طور رادیکال به فرایندهای اصلی سازمانی دوباره فکر شود. فرایندهایی نظیر فروش و پشتیبانی از مشتریان. RAD اغلب یک بخش ضروری از برنامه مهندسی مجدد در کسب و کارهای بزرگ بود. رویکرد نمونه سازی سریع در RAD شد یک ابزار کلیدی برای کمک به کاربران و تحلیلگران بود تا بتوانند «ذهن خود را فراتر ببرند» در مورد روش‌های نوآورانه در تکنولوژی که ممکن است اساساً اختراع دوباره یک هسته کسب و کار را موجب شود.[4][5]

روش RAD توسط James Martin
فازهای در رویکرد James Martin نسبت به RAD

James Martin رویکرد RAD را به چهار فاز مجزا تقسیم کرده‌است:

  1. فاز برنامه‌ریزی نیازمندی‌ها – ترکیبی از عناصر از فاز برنامه‌ریزی سیستم و تحلیل سیستم در چرخه زندگی توسعه سیستم‌ها (SDLC). کاربران و مدیران و کارکنان IT در خصوص نیازهای کسب و کار، محدوده پروژه، قیود و نیازمندی‌های سیستم به بحث می‌کنند و به اتفاق‌نظر می‌رسند. این فاز زمانی به پایان می‌رسد که تیم در خصوص مسائل کلیدی به توافق برسند و تأیید مدیریتی را برای ادامه کار به‌دست بیاورند.
  2. فاز طراحی کاربر – در این فاز کاربران با تحلیلگران سیستم‌های مدل‌های توسعه و نمونه‌های اولیه را که بیانگر تمامی فرایندهای سیستم، ورودی‌ها و خروجی‌ها است را تبیین می‌کنند. گروه‌ها و زیرگروه‌های RAD به‌طور معمول نیازهای کاربر را به مدل‌های کاری با استفاده از ترکیب تکنیک‌های توسعه مشترک نرم‌افزارها (JAD) و ابزار CASE ترجمه می‌کنند. . طراحی کاربر یک فرایند پیوسته تعاملی است که به کاربر این امکان را می‌دهد تا با درک، تبدیل و در مواردی بهبود یک مدل کاری این امکان را فرآهم کنند تا سیستمی داشته باشند که پاسخگوی نیاز کاربران باشد.
  3. فاز ساخت – در این فاز مشابه SDLC، تمرکز بر برنامه توسعه برنامه است. در RAD, اما کاربران همچنان مشارکت خواهند داشت و می‌توانند در ساخت صفحات واقعی و گزارش‌ها پیشنهادهایی برای تغییرات و بهینه‌سازی ارائه دهند. وظایف در این فاز عبارتند از برنامه‌نویسی، توسعه برنامه، کد نویسی، متصل کردن واحدها و تست کردن سیستم.
  4. فاز تحویل – شبیه کارهای نهایی در فاز استقرار SDLC شامل تبدیل داده‌ها، تست، مهاجرت به سیستم جدید و آموزش کاربر است. در مقایسه با مدل‌های سنتی، همه فرایند فشرده‌سازی شده‌است. در نتیجه، سیستم جدید خیلی زودتر توسعه داده شده، تحویل می‌شود و در جایگاه عملیاتی قرار می‌گیرد.[6]

مزایا و معایب توسعه سریع نرم‌افزار

در محیط‌های مدرن تکنولوژی اطلاعات، سیستم‌های زیادی با استفاده کم و بیش از توسعه سریع نرم‌افزار گسترش یافته‌اند.[7] (و نه لزوماً رویکرد جیمز مارتین). علاوه بر روش مارتین روش Agile و منطقی فرایند یکپارچه اغلب برای توسعه سریع نرم‌افزار استفاده می‌شوند.

مزایای استفاده از RAD عبارتند از:

  • کیفیت بهتر. عملکرد کسب و کاری در یک پروژه RAD با توجه به تعامل کاربران با نمونه‌های اولیه در حال تحول معمولاً می‌تواند بسیار بیشتر از آنچیزی باشد که با استفاده از مدل آبشاری حاصل می‌شود. نرم‌افزار می‌تواند کاربردی‌تر باشد و شانس بیشتری وجود دارد که تمرکز بر روی مشکلات کسب کاری که برای کاربر نهایی وجود دارد قرار گیرد تا مشکلات فنی که مورد علاقه توسعه‌دهندگان است.
  • کنترل ریسک. اگر چه بسیاری از متون RAD بر تمرکز روی سرعت و دخالت کاربر به عنوان ویژگی‌های مهم RAD تاکیید می‌کنند، یک ویژگی حیاتی RAD اگر به درستی پیاده شود، کاهش ریسک است. ارزش آن را دارد تا یادآور شویم که Boehm در ابتدا مشخصهٔ مدل مارپیچی یک مدل بر مبنای ریسک عنوان کرده‌است. یک رویکرد RAD در ابتدا می‌تواند بر روی فاکتورهای کلیدی ریسک تمرکز کند و بر اساس آن‌ها و اطلاعات بدست آمده در مراحل اولیه فرایند تنظیمات لازم را انجام دهد. به عنوان مثال، ریسک پیچیدگی را با ساختن نمونهٔ اولیه از قسمت‌هایی از سیستم که بیشترین پیچیدگی را دارند.
  • پروژه‌های بیشتری در زمان و با بودجه مشخص، تکمیل می‌شوند. با تمرکز بر توسعه تدریجی واحدها شانس شکست فاجعه بار که همواره در کمین پروژه‌های بزرگ مدل آبشاری است، کاهش می‌یابد. در مدل آبشاری رایج است که پس از شش ماه یا بیشتر از تجزیه و تحلیل و توسعه به این درک برسند که نیازمند یک بازاندیشی رادیکال در خصوص کل سیستم هستند. با RAD این نوع از اطلاعات را می‌توان در فرایند زودتر کشف کرد و به آن‌ها پاسخ داد.[2][8]

معایب RAD عبارتند از:

  • خطر یک رویکرد جدید. برای اکثر بنگاه‌های IT رویکرد RAD یک رویکرد جدید است که نیازمند متخصصانی با تجربه است که در خصوص نحوه کار خود بازاندیشی کنند. انسان‌ها تقریباً همیشه با تغییر مخالفت می‌کنند و هر پروژه‌ای که با ابزارها یا روش جدید انجام شده باشد، شانس بیشتری برای شکست خواهد داشت. این شکست به سادگی با توجه به نیاز تیم برای یادگیری اتفاق می‌افتد.
  • نیاز به زمان منابع کمیاب. چیزی که تقریباً در میان تمامی روش‌های RAD مشترک است، این است که تعامل بسیار بیشتری میان کاربران و توسعه دهندگان در طی جرخه زندگی روی می‌دهد. در مدل آبشاری کاربران نیازمندی‌ها را تعریف می‌کنند و پس از آن عمدتاً می‌روند و توسعه دهندگان سیستم را ایجاد می‌کنند. در RAD کاربران از همان ابتدا و از طریق تقریباً در کل پروژه، درگیر هستند. این مستلزم آن است که کسب و کار مایل به سرمایه‌گذاری زمان کارشناسان خبره در حوضه نرم‌افزار باشند. پارادوکس این است که هر چه متخصص بهتر باشد، بیشتر با دامنه مورد بررسی آشنایی دارند و در عین حال نیاز بیشتری به حضور واقعی آن‌ها برای پیشبرد کارها است و این سخت خواهد بود که مدیران آن‌ها را متقاعد کنیدم که زمان آن‌ها را برای پروژه تخصیص دهند. بدون چنین تعهداتی یک پروژه RADموفق نخواهد شد.
  • کنترل کمتر. یکی از مزایای استفاده از RAD این است که فرایند انعطاف‌پذیر و سازگار فراهم می‌کند. ایده‌آل این است که قادر به انطباق سریع به مشکلات و فرصت‌ها باشد. مصالحه اجتناب‌ناپذیری بین انعطاف‌پذیری و کنترل وجود دارد. بیشتر از یک معنی کمتر از دیگری را می‌دهد. اگر یک پروژه (به عنوان مثال نرم‌افزاری که جان انسان‌ها سر و کار دارد) ارزش کنترل بیش از چابکی باشد، RAD روش مناسبی نیست.
  • طراحی ضعیف. تمرکز بیش از حد بر روی نمونه‌های اولیه گرفته می‌شود در برخی موارد منجر به یک روش «هک و تست» می‌شود که در آن توسعه دهندگان به‌طور مداوم تغییرات جزئی در بخش‌ها ایجاد می‌کنند و با نادیده گرفتن معماری سیستم مسائلی را که می‌تواند منجر به طراحی بهتر شود را نادیده می‌گیرند. این می‌تواند به خصوص یک مشکل برای روش‌هایی مانند روش مارتین که تمرکز بیشتری بر رابط کاربری سیستم دارد، بیشتر است.[9]
  • عدم مقیاس پذیری. RAD به‌طور معمول بر روی تیم‌های پروژه کوچک تا متوسط تمرکز دارد. دیگر مسائل ذکر شده در بالا (طراحی و کنترل کمتر) در حال حاضر چالش‌های خاصی در هنگام استفاده از راد برای سیستم‌های مقیاس بزرگ هستند.[10][11][12]

منابع
  1. Brooks, Fred (1986). Kugler, H.J., ed. No Silver Bullet Essence and Accidents of Software Engineering (PDF). Information Processing '86. Elsevier Science Publishers B.V (North-Holland). ISBN 0-444-70077-3. Retrieved 2 July 2014.
  2. Boehm, Barry (May 1988). "A Spiral Model of Software Development" (PDF). IEEE Computer. Archived from the original (PDF) on 29 March 2018. Retrieved 1 July 2014.
  3. Kerr, James M. ; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. ISBN 0-07-034223-7.
  4. Drucker, Peter (November 3, 2009). Post-Capitalist Society. Harper Collins e-books. ISBN 0-88730-620-9.
  5. Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8.
  6. Martin, James (1991). Rapid Application Development. Macmillan. pp. 81–90. ISBN 0-02-376775-8.
  7. Hotle, Matt (April 13–14, 2010). "The Disintegration of AD: Putting it Back Together Again" (PDF). http://www.gartner.com.br. Enterprise Integration Summit, São Paulo, Brazil: Gartner Group. Archived from the original (PDF) on 14 July 2014. Retrieved 1 July 2014. External link in |website= (help)
  8. Beck, Kent (2000). Extreme Programming Explained. Addison Wesley. pp. 3–7. ISBN 0-201-61641-6.
  9. Gerber, Aurona; Van Der Merwe, Alta; Alberts, Ronell (16–18 November 2007). "Practical Implications of Rapid Development Methodologies". Proceedings of the Computer Science and Information technology Education Conference, CSITEd-2007. Computer Science and IT Education Conference. Mauritius. pp. 233–245. ISBN 978-99903-87-47-6. Retrieved 9 October 2016.
  10. Andrew Begel, Nachiappan Nagappan. "Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study, Microsoft Research" (PDF). Retrieved 2008-11-15.
  11. E. M. Maximilian and L. Williams. (2003). "Assessing Test-driven Development at IBM". Proceedings of International Conference of Software Engineering, Portland, OR, pp. 564-569, 2003.
  12. M. Stephens, Rosenberg, D. (2003). "Extreme Programming Re factored: The Case Against XP". Apress, 2003.

مطالعه بیشتر
  • Steve McConnell (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press Books, ISBN 978-1-55615-900-8
  • Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. ISBN 0-07-034223-7.
  • Ellen Gottesdiener (1995). "RAD Realities: Beyond the Hype to How RAD Really Works" Application Development Trends
  • Ken Schwaber (1996). Agile Project Management with Scrum, Microsoft Press Books, ISBN 978-0-7356-1993-7
  • Steve McConnell (2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers, Addison-Wesley, ISBN 978-0-321-19367-4
  • Dean Leffingwell (2007). Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley Professional, ISBN 978-0-321-45819-3
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.