در اولین قسمت مقالۀ انتخاب رویکرد توسعه، به متدلوژی (رَوِشگانِ *) آبشاری یا واترفال پرداختیم. در قسمت دوم این مقاله، «پیش‌نمونه‌سازی» یا Prototyping را بررسی می‌کنیم.
پیش‌نمونه‌سازی (Prototyping)
نوع چارچوب کار: تکرارشونده
اصول پایه:
- روشگانِ توسعۀ کامل و مستقلی نیست بلکه رویکردی برای کنترل دیگر روشگان‌های توسعۀ سنتی‌تر و بزرگ‌تر است (به‌طور مثال: روش افزایشی (اینکریمنتال) (Incremental)، مارپیچی (اسپیرال) (Spiral) یا توسعۀ سریع نرم‌افزار (RAD)).
- در این روشگان، با تقسیم پروژه به بخش‌های کوچک‌تر و آسان کردن تغییرات در روند توسعه، سعی می‌شود که ریسک ذاتی پروژه کاهش یابد.
- کاربر در این فرایند به مشارکت واداشته می‌شود؛ ازاین‌رو احتمال اینکه پیاده‌سازی نهایی موردقبول او باشد زیاد است.
- بر ماکت‌های کوچک‌مقیاس سیستم کار می‌شود؛ برای آنکه پیش‌نمونه آنقدر تکامل یابد که نیازمندی‌های کاربران را برآورده سازد، یک روند اصلاح‌کنندۀ تکرارشونده اتخاذ می‌شود.
- درحالی‌که انتظار می‌رود بیشتر پیش‌نمونه‌هایی که توسعه می‌یابند دور انداخته شوند، در برخی از موارد ممکن است پیش‌نمونه به یک سیستم کارا تکامل یابد.
- برای اجتناب از اشتباه گرفتن یک مسئله و صرف وقت برای حل آن، درک پایه‌ای از مشکل اصلی تجاری ضرورت دارد.
نقاط قوت:
- «ارائۀ یک سیستم غیرقطعی و موقتی به کاربران، در سریع‌ترین زمان ممکن و برای اهداف آزمایشگاهی، مسئلۀ ناتوانی بسیاری از کاربران را در تعیین نیازهای اطلاعاتی و مشکل تحلیلگران را در درک محیط کاربر حل می‌کند.» (جیسون و اسمیت، [۱] ).
- « می‌توان از آن برای مدل‌سازی واقع‌بینانۀ جنبه‌های مهم یک سیستم در هر فاز از چرخۀ حیاتی استفاده کرد.» (هافاکر، ۱۹۸۶) [۲].
- موجب افزایش مشارکت کاربر در توسعۀ سیستم و همین‌طور، ارتباطات مابین ذی‌نفعان پروژه می‌شود.
- خصوصاً برای اهداف نامشخص؛ توسعه و اعتبارسنجی نیازمندی‌های کاربر؛ آزمایش و مقایسۀ راهکارهای مختلف طراحی؛ یا برای بررسی عملکرد و واسط‌های مابین رایانه و انسان مفید واقع می‌شود.
- این پتانسیل را دارد که بتوان در تکرار اولیه، هم‌زمان با پیشرویِ تکرارهای بعدیِ توسعه، دانش حاصله را استخراج کرد.
- موجب آسان شدن تشخیص عملکردهای دشوار و گیج‌کننده و کارکردهای جاافتاده می‌شود.
- می‌توان دراین روش برای برنامه‌های کاربردی تولیدی، مشخصاتی را ایجاد کرد.
- بستر ابتکار و طراحی‌های انعطاف‌پذیر را فراهم می‌کند.
- امکان پیاده‌سازی سریع یک کاربرد ناکامل اما کارا وجود دارد.
نقاط ضعف:
- روند تأیید و کنترل، سخت‌گیرانه نیست.
- ممکن است تحلیل مشکلات ناکافی و ناکامل باشد و فقط به نیازهای آشکار و سطحی پرداخته شود، درنتیجه در سیستم‌های جدید، روش‌های ناکارآمد به‌کارگرفته می‌شوند.
- ممکن است که دفعات تغییر نیازمندی‌ها زیاد باشد.
- شناسایی مؤلفه‌های ناکارا برای سند کردن دشوار است.
- ممکن است که طراحان با شتاب افراطی پیش‌نمونه‌سازی کنند، تحلیل‌های نیازمندی‌های کاربران کافی نباشد؛ درنتیجه، طراحی نامنعطف باشد و گسترده نبودن محدودۀ تمرکز، پتانسیل ارتقاء سیستم را در آینده محدود کند.
- امکان دارد طراحان از مستندسازی چشم‌پوشی کنند و درنتیجه محصول نهایی به‌کفایت، توجیه‌پذیر نباشد و گزارش‌ها برای آینده، نابسنده باشند.
- امکان ضعیف بودن طراحی سیستم‌ها وجود دارد. ممکن است طراحانِ بی‌مهارت، پیش‌نمونه را با یک طراحی مناسب جایگزین کنند و درنتیجه، بدون در نظر گرفتن ملاحظات کامل برای یکپارچه‌سازی مؤلفه‌ها، طراحی به یک «سیستم سروته به‌هم آورده» بینجامد. اگرچندکه هدف از توسعۀ اولیۀ نرم‌افزار غالباً «یک‌بارمصرفِ» آن است، تلاش برای طراحی یک سیستم ثابت با رجوع به گذشته، گاهی مشکل‌ساز می‌شود.
- اگر مشتری به‌اشتباه معتقد است که سیستم «تکمیل شده است؛» درحالی‌که این‌گونه نیست، انتظارات اشتباه به وجود بیاید؛ سیستم به نظر خوب است و واسطه‌های کاربری کافی دارد، اما واقعاً کارا نیست.
- تکرارها موجب افزایش بودجه‌های پروژه و زمان‌بندی‌ها می‌شود؛ درنتیجه هزینۀ اضافه باید نسبت به منافع بالقوه سنجیده شود. شاید برای پروژه‌های بسیار کوچک، زمان و هزینۀ اضافی توجیه‌پذیر نباشد؛ اما برای بخش‌های پرخطر پروژه‌های بسیار پیچیده و بزرگ پیش‌نمونه‌سازی می‌تواند مفید باشد.
- امکان کافی نبودن تعدیل‌ها و بررسی‌های کافی برای پیش‌نمونه وجود دارد.
موقعیت‌هایی که بیشتر برای آن مناسب است:
- در پروژه نیاز به توسعۀ سیستم‌های آنلاینی باشد که به مکالمات گسترده با کاربر نیاز دارند؛ یا سیستم‌های پشتیبانی تصمیم‌گیری و سیستم‌های خبره‌ای که تعریف مناسبی نداشته باشند.
- پروژه، گسترده و مملو از عملکرد، روابط داخلی و کاربران بسیار باشد و در تعریف نیازمندی‌های پروژه لازم باشد که ریسک کاهش بیابد.
- اهداف پروژه شفاف نباشند.
- برای پیاده‌سازی فوری چیزی، فشار وجود داشته باشد.
- احتمال تغییر مکرر و شدید نیازمندی‌های مربوط به کارکرد وجود داشته باشد.
- آگاهی کاربر کامل نباشد.
- اعضای تیم باتجربه باشند (خصوصاً در صورت یک‌بارمصرف نبودن پیش‌نمونه).
- ترکیب تیم ثابت باشد.
- مدیر پروژه باتجربه باشد.
- کمینه کردن مصرف منابع ضرورت عاجل نداشته باشد.
- در مایلستون‌های معین، نیاز به تأیید نیازمندی‌های جدی نباشد.
- تحلیلگران/کاربران قبل از شروع پروژه، پذیرای چالش‌های تجاری پروژه باشند.
- به طراحی‌های انعطاف‌پذیر و ابتکاری که باید با تغییرات آینده سازگار باشند نیاز نباشد.
موقعیت‌هایی که کمتر برای آن مناسب است:
- سیستم‌های دسته‌ای تراکنش‌محور و مبتنی بر بزرگ‌رایانه‌ها (پردازنده‌های مرکزی)؛
- سیستم‌های تجارت الکترونیک و تحت وب (web-enabled)؛
- تیم‌های پروژه با ترکیب‌های ناثابت؛
- ضروری بودن مقیاس‌پذیری طراحی برای آینده؛
- واضح بودن اهداف پروژه و کم بودن ریسک تعریف نیازمندی‌های پروژه.
در این دو قسمت «انتخاب رویکرد توسعه» به دو روشگان تکرارشونده پرداختیم: روش آبشاری و روش پیش‌نمونه‌سازی؛ اما در قسمت بعدی این مقاله به چارچوبی می‌پردازیم که از ترکیب دو رویکرد تکرارشونده و خطی حاصل می‌شود: روشگانِ Incremental یا افزایشی.
انتخاب رویکرد توسعه (قسمت اول)
انتخاب رویکرد توسعه (قسمت سوم)
* رجوع شود به زیرنویس [۱] قسمت اول همین مقاله
[۱] Janson and Smith, 1985
[۲] Huffaker, 1986
