انتخاب رویکرد توسعه (قسمت پنجم-پایانی)

در آخرین بخش مقالۀ انتخاب رویکرد توسعۀ نرم‌افزار، روش توسعۀ سریع نرم‌افزار (RAD) را بررسی می‌کنیم. اگر بخش‌های قبلی این مقاله را مطالعه نکرده‌اید، برای دستیابی به قسمت‌های قبلی، بر پیوندهای انتهای این مقاله کلیک کنید.

توسعۀ سریع نرم‌افزار (RAD, Rapid Application Development)

نوع چارچوب: تکرارشونده

اصول پایه‌ای:

1. هدف اصلی، توسعۀ سریع و تحویل یک سیستمِ کیفیت‌بالا با هزینۀ سرمایه‌گذاری نسبتاً پایین است.
2. تلاش برای کاهش خطر ذاتی پروژه با تقسیم کردن پروژه به قطعات کوچک‌تر و تسهیل تغییرات در طی فرایند توسعه است.
3. هدف آن تولید سریع دستگاه‌های باکیفیت است؛ اساساً ازطریق پیش‌نمونه‌سازی تکرارشونده (در هر سطحی از توسعه)، مشارکت فعال کاربر، ابزار توسعۀ رایانه‌ای (در هر مرحله از توسعه). این ابزار ممکن است شامل سازنده‌های واسطه گرافیکی کاربر (GUI)، ابزار مهندسی نرم‌افزار به کمک رایانه (CASE)، دستگاه‌های مدیریتی پایگاه‌داده‌(DBMS)، زبان‌های برنامه‌نویسی نسل چهارم، تولیدکننده کد، تکنیک‌های شیءمحور.
4. تأکید مؤکدی بر برآورد نیاز تجاری است، درحالی‌که ویژگی مهندسی و فناوری از اهمیت کمتری برخوردار است.
5. در کنترل پروژه، با اولویت‌بندی و تعریف تاریخ‌های تحویل یا جعبه‌های زمانی (تایم باکس‌ها) توسعه صورت می‌گیرد. اگر پروژه از کنترل خارج شود، تأکید بر کاهش زمان‌بندی‌ها برای انطباق با جعبه‌های زمان و ممانعت از افزایش زمان‌های تحویل است.
6. عموماً شامل توسعۀ کاربردی مشارکتی (JAD) است که در آن کاربران مشارکت بسیاری در طراحی سیستم دارند، چه ازطریق سازه‌هایی که در کارگاه‌های ساختاریافته بر آن‌ها توافق می‌شود، چه تعاملاتی که ازطریق الکترونیکی آسان می‌شوند.
7. مشارکت فعالانه کاربر از اهمیت برخوردار است.
8. برخلاف پیش‌نمونه‌های یک‌بارمصرف، نرم‌افزار به‌طور تکرارشونده تولید می‌شود.
9. برای تسهیل توسعه و نگهداری آسان آن در آینده، مستندات تهیه می‌شوند.
10. می‌توان تحلیل دستگاه‌های استاندارد و تکنیک‌های طراحی را با این چارچوب تطبیق داد.

نقاط قوت:

1. در این روش نسخۀ عملیاتی یک برنامۀ کاربردی بسیار زودتر از واترفال (آبشاری)، اینکریمنتال (افزایشی)، یا اسپیرال (مارپیچی) قابل‌دسترس است.
2. به دلیل اینکه RAD سریع‌تر سیستم‌ها را تولید می‌کند و این کار را با تمرکز تجاری انجام می‌دهد، این رویکرد معمولاً سیستم‌ها را با هزینۀ کمتری تولید می‌کنند.
3. نسبت به چارچوب‌های اسپیرال، اینکیریمنتال، واترفال، مستلزم میزان بالایی از تعهد ذی‌نفعان است، چه ازلحاظ تجاری، چه ازلحاظ فنی. به نظر می‌رسد که کاربران حس مالکیت بیشتری نسبت به سیستم داشته باشند و توسعه‌دهندگان، رضایت بیشتری از تولید سریع‌تر سیستم‌های موفق کسب کنند.
4. ازنقطه‌نظر کاربر، تمرکز بر مؤلفه‌های اساسی سیستم است.
5. تغییر سریع طراحی سیستم مطابق تقاضای کاربران ممکن است.
6. انطباق نزدیک‌تری مابین نیازمندی‌های کاربر و مشخصات سیستم حاصل می‌شود.
7. در زمان، پول و تلاش‌های انسانی بسیار صرفه‌جویی می‌شود.

نقاط ضعف:

1. سرعت بیشتر و هزینۀ کمتر ممکن است در مجموع، به کم‌کیفیت شدن سیستم بینجامد.
2. به‌علت از دست رفتن اطلاعات، خطرِ هم‌طرازی نبودن سیستمِ توسعه‌یافته با کسب‌وکار وجود دارد.
3. ممکن است که پروژه‌ها به نیازمندی‌هایی منتهی شوند که بیش از نیازمندی‌های موردنیاز است (اضافه‌کاری).
4. به دلیل اضافه شدن ویژگی‌های بیشتر و بیشتر در روند توسعه، امکان از دست رفتن ویژگی‌ها وجود دارد.
5. امکانِ ناسازگاری طراحی‌ها، درون سیستم‌ها یا در مجموع سیستم‌ها وجود دارد.
6. به دلیل قراردادهای نام‌گذاری ناسازگار و مستندات متناقض، امکان تعدی از استانداردهای برنامه‌نویسی وجود دارد.
7. استفاده مجدد از ماژول برای دستگاه‌های آینده دشوار است.
8. امکان مقیاس‌ناپذیری سیستم طراحی‌شده وجود دارد.
9. امکان بی‌توجهی به نیازهای بعدی مدیریت سیستم که باید در سیستم پیاده‌سازی شود وجود دارد.
10. تعهد کارکنان اصلیِ کاربر، هزینۀ بالایی دارد.
11. حسابرسی‌ها و بازبینی‌های رسمی نسبت به یک سیستم کامل دشوارتر است.
12. تمایل به تعویق انداختن مشکلات دشوار وجود دارد تا موفقیت اولیه به مدیریت نشان داده شود.
13. به دلیل اینکه برخی از ماژول‌ها سریع‌تر از بقیه کامل می‌شوند، نیاز به واسطهایی است که به‌خوبی تعریف شوند.

موقعیت‌هایی که بیشتر برای آن مناسب است:

1. پروژه در مقیاس کوچک تا متوسط باشد و طول‌مدت آن کوتاه باشد (روند توسعه، بیش از 6 سال انسانی نباشد).
2. حوزۀ پروژه متمرکز باشد، تا اهداف تجاری محدود و به‌خوبی تعریف شوند.
3. کاربرد بسیار تعاملی باشد، گروه کاربری، تعریف معینی داشته باشد و ازلحاظ محاسباتی پیچیده نباشد.
4. کارکرد سیستم در واسط کاربر کاملاً مشاهده‌پذیر باشد.
5. کاربران از حوزۀ کاربرد اطلاع دقیقی داشته باشند.
6. مدیر ارشد متعهد به جلب مشارکت  کاربر نهایی باشد.
7. نیازمندی‌های سیستم نامشخص و غیرقطعی باشند.
8. امکان تعریف دقیق نیازمندی‌های سیستم سریع‌تر از موعد نباشد زیرا شرایط جدید است و سیستم به‌کارگرفته‌شده بسیار ابتکاری است.
9. اعضای تیم هم از مهارت‌های تجاری و هم از مهارت‌های اجتماعی برخوردار باشند.
10. ترکیب تیم قطعی باشد؛ بتوان تیم اصلی توسعه را تثبیت کرد.
11. کنترل مؤثر پروژه حتماً ممکن باشد.
12. توسعه‌دهندگان در به‌کارگیری ابزار پیشرفته مهارت داشته باشند.
13. داده‌های پروژه ازپیش موجود باشند (کاملاً یا بخشی از آن) و  پروژه تحلیل و گزارش‌های گسترده‌ای داشته باشد.
14. تعرزف معماری فنی شفاف باشد.
15. مؤلفه‌های فنی کلیدی در محل مناسبی اعمال شوند و آزموده شده باشند.
16. نیازمندی‌های فنی (به‌طور مثال، زمان‌های پاسخگویی، توان عملیاتی، اندازه پایگاه‌داده‌و غیره) معقول، و در محدودۀ ظرفیت‌های فنی  باشند. عملکرد هدف باید کمتر از 70 درصد از محدوده‌های فنی را پوشش داده باشد.
17. تیم توسعه قادر به تصمیم‌گیری‌های روزانه دربارۀ طراحی، بدون نیاز به مشورت با مافوق‌ها باشد و تصمیمات را  تعداد کمی از افراد که در دسترس و ترجیحاً در یک محل هستند اتخاذ کنند.

موقعیت‌هایی که کمتر برای آن مناسب است:

1. پروژه‌های زیرساختاری و بسیار بزرگ؛ خصوصاً سیستم‌های اطلاعات توزیع‌شده و بزرگ، مثل پایگاه‌داده‌های مشارکتی.
2. سیستم‌هایی که بلادرنگ باشند و امنیت برای آن‌ها ضرورت عاجل داشته باشد.
3. سیستم‌هایی که ازلحاظ محاسباتی پیچیده باشند و  نیاز به تحلیل، طراحی و تولید داده‌های پیچیده و پرحجمی در محدودۀ پروژه باشد.
4. محدودۀ پروژه گسترده و اهداف تجاری مبهم باشد.
5. کاربردهایی که در آن نیازمندی‌های مربوط به کارکردها، باید قبل از نوشتن برنامه‌ها کاملاً تعیین‌ شده باشند.
6. افراد بسیاری در تصمیمات مربوط به پروژه مشارکت داشته باشند و دسترسی به تصمیم‌گیرنده‌ها طبق زمان‌بندی معینی نباشد؛ یا تصمیم‌گیرنده‌ها ازلحاظ جغرافیایی پراکنده باشند.
7. تیم پروژه بزرگ باشد و چندین تیم که نیاز به هماهنگی میان آن‌ها است موجود باشند.
8. وقتی‌که منابع و یا تعهد کاربر کم باشد.
9. هیچ قهرمان پروژه‌ای [1] برای اجرای امور در هیچ سطحی وجود نداشته باشد.
10. فناوری‌های جدید بسیاری در پروژه تعریف شوند، یا معماری فنی نامشخص باشد و بیشتر فناوری‌ها برای اولین‌بار در پروژه استفاده شوند.
11. نیازمندی‌های فنی (به‌طور مثال زمان پاسخگویی، توان عملیاتی، اندازۀ پایگاه‌داده‌ و غیره) برای تجهیزاتی که قرار است استفاده شود، محدود باشد.

این مقاله در اینجا به پایان می‌رسد. اگر برای مدیریت پروژۀ توسعه‌های نرم‌افزاری نیاز به اطلاعات بیشتری دارید، انتخاب روش‌های مناسب برای مدیریت پروژه را مطالعه کنید.

بخش‌های قبلی این مقاله را در خط دید نرم‌افزار مطالعه کنید:

انتخاب رویکرد توسعه (قسمت اول)

انتخاب رویکرد توسعه (قسمت دوم)

انتخاب رویکرد توسعه (قسمت سوم)

انتخاب رویکرد توسعه (قسمت چهارم)

[1] project champion

قهرمان پروژه به شخصی در سازمانِ مجریِ پروژه گفته می‌شود که مسئولیت هماهنگی و جلب مشارکت تمام افراد مشغول در پروژه و اطمینان از موفقیت پروژه را به عهده دارد.