انتخاب رویکرد توسعه (قسمت اول)
در مقالات قبلی خط دید به بررسی چندین روش مطرح در مدیریت پروژۀ توسعه‌های نرم‌افزاری پرداختیم. اگر مدیر پروژه، توسعه‌دهندۀ ارشد و یا حتی عضوی از تیم توسعه هستید که نیاز به بررسی این روش‌ها دارید، مرور مقالاتِ پیش‌نیاز قبلی برای فهم کامل‌تر این مقاله توصیه می‌شود. اما اگر با این مبحث ازپیش آشنایی دارید، حتماً آمادۀ چالش انتخاب رویکرد توسعه هستید!
منظور از رَوِشگانِ [1] (متدولوژیِ) توسعۀ سیستم، یک چارچوب‌کاری است که برای ساختاربندی، برنامه‌ریزی و کنترل فرایند توسعۀ یک سیستم اطلاعات به‌کاربرده می‌شود. در طی سال‌ها این چارچوب‌های کاری، با تنوع گسترده‌ای تکامل یافته‌اند و هرکدام نقاط قوت و ضعف مشخص خود را دارند. به‌کارگیری یک روشگان یکسان برای توسعۀ سیستم‌های تمام پروژه‌ها، همیشه کار درستی نیست. هرکدام از این روشگان‌های موجود، برحسب ملاحظات تیمی، پروژه‌ای، سازمانی و فنی، متفاوت، و برای نوع بخصوصی از پروژه‌ها مناسب است. در این مقالۀ چندقسمتیِ خط دید، به روشگان‌هایی که در محیط‌های فنی، سازمانی، کاربردی و تجاریِ مطرح استفاده می‌شوند می‌پردازیم.
روشگان‌های مطرح برای توسعۀ سیستم
Waterfall (واترفال: روش آبشاری)
نوع چارچوب: خطی
اصول پایه:
- پروژه به فازهای متوالی تقسیم می‌شود، کمی تداخل و هم‌پوشانی بین فازها قابل‌قبول است؛
- تأکید بر برنامه‌ریزی، زمان‌بندی، تاریخ‌های اهداف، بودجه‌ها و پیاده‌سازی کل سیستم به‌طور هم‌زمان است؛
- حیات پروژه با به‌کارگیری مستنداتِ مکتوب و بازبینی‌های رسمی، شدیداً کنترل می‌شود؛ کاربر و مدیر فناوری اطلاعات خاتمۀ هر فاز را در انتهای هر فاز، قبل از شروع فاز بعدی تأیید می‌کنند.
نقاط قوت:
- برای پشتیبانی مدیران پروژه و تیم‌های پروژه‌ای که کم‌تجربه‌تر هستند یا تیم‌های پروژه‌ای که ترکیب آن‌ها متغیر است، ایدئال است؛
- برای اطمینان از کافی بودن بازبینی‌های طراحی و مستندسازی برای کیفیت مناسب، قابلیت اطمینان و قابلیت نگهداریِ نرم‌افزار درحال‌توسعه، مراحل توسعه طبقِ یک توالی مرتب و تحتِ کنترل سخت‌گیرانه‌ای به‌پیش می‌رود؛
- پیشروی توسعۀ سیستم قابل‌اندازه‌گیری است؛
- منابع را حفظ می‌کند.
نقاط ضعف:
- انعطاف‌پذیر نبودن، کند بودن، پرهزینه بودن و دست‌وپا گیر بودن به دلیل ساختار و کنترل‌های شدید؛
- تأکید بر جلو بردن پروژه و فقدان نگرش به اکتسابات قبلی؛
- فضای کم برای به‌کارگیریِ تکرار؛ که از قابلیت مدیریت‌پذیری، در صورت به‌کارگیری این قابلیت، می‌کاهد؛
- متکی بودن بر شناسایی و تعیین اولیۀ نیازمندی‌ها؛ درحالی‌که ممکن است کاربران قادر به تعریف اولیۀ آنچه در ابتدای پروژه نیاز دارند نباشند؛
- تناقض نیازمندی‌ها؛ از دست رفتن بعضی از مؤلفه‌های سیستم؛ نیازهای غیرمنتظرۀ توسعه غالباً در روندِ طراحی و کدنویسی کشف می‌شوند؛
- مکشوف نشدن مشکلات معمولاً تا مرحلۀ آزمودن سیستم؛
- ناتوانی در آزمودن سیستم تا تکمیل کدنویسی؛ عملکرد سیستم را نمی‌توان تا زمانی که سیستم کاملاً کدنویسی شود آزمود؛ ممکن است بهبود وضعیتِ زیرِ ظرفیت [2] دشوار باشد.
- دشواری پاسخ‌دهی به تغییرات؛ تغییراتی که بعداً در چرخۀ حیاتی ایجاد می‌شوند، هزینه بیشتری می‌برند؛ درنتیجه به چنین تغییراتی ترغیب نمی‌شود.
- افراطی بودن تولید مستندات و به‌روز نگه‌داشتن آن به علت زمان‌بر بودن پیشروی‌های پروژه؛
- دشواری خواندن مشخصات مکتوب و توجه به آن برای کاربران، در اغلب مواقع؛
- وجود فاصلۀ بین کاربران و توسعه‌دهندگان، به علتِ تقسیم معین مسئولیت‌ها.
موقعیت‌هایی که بیشتر برای آن مناسب است:
- پروژه حول توسعۀ یک سیستم دسته‌ای تراکنش‌محور و مبتنی بر بزرگ‌رایانه‌ها باشد.
- پروژه بزرگ، پرهزینه و پیچیده باشد.
- پروژه اهداف و راهکار مشخصی داشته باشد.
- فشاری برای پیاده‌سازیِ فوری نباشد.
- نیازمندی‌های پروژه را بتوان به‌وضوح و بدون ابهام بیان کرد.
- نیازمندی‌های پروژه در طی چرخۀ حیاتی توسعۀ سیستم پایدار و تغییرناپذیر باشند.
- جامعۀ کاربری ازلحاظ تجاری و کاربردی کاملاً آگاه باشند.
- اعضای تیم بی‌تجربه باشند.
- ترکیب تیم ناپایدار باشد و انتظار نوسان و تغییر برود.
- مدیر پروژه چندان باتجربه نباشد.
- نیاز به حفظ منابع باشد.
- نیاز جدی به تأییدهای رسمیِ مایلستون‌های تعیین‌شده باشد.
موقعیت‌هایی که کمتر برای آن مناسب است:
- پروژه‌های بزرگ که شناخت مناسبی از نیازمندی‌های آن موجود نباشد یا به هر دلیلی مثل تغییرات خارجی، تغییر انتظارات، تغییرات بودجه یا تغییرات سریع فناوری، نیازمندی‌ها تغییر کنند.
- برای سیستم‌های اطلاعات وب (WIS)؛ اساساً به دلایلی چون سریع بودن پیاده‌سازی پروژه‌های WIS؛ دائماً در تکامل بودن نیازمندی‌های پروژه؛ نیاز به اعضای انعطاف‌پذیر و باتجربه در تیم که از زمینه‌های مختلفی گردهم آمدند؛ و ناتوانی در پیش‌بینی سطح دانش کاربران.
- سیستم‌های بلادرنگ؛
- سیستم‌های رویدادمحور؛
- کاربردهای پیشرفته.
این تنها روش تکرارشوندۀ توسعه نیست؛ در قسمت بعدی این مقاله به روش پیش‌نمونه‌سازی (Prototyping) می‌پردازیم.
نحوۀ انتخاب رویکرد توسعه را در خط دید دنبال کنید:
انتخاب رویکرد توسعه (قسمت دوم)
[1] روشگان، واژۀ مصوب برای کلمۀ انگلیسیِ ‘methodology’ است. به نظر می‌رسد وقتی کلمۀ متدولوژی به معنای عمل شناختن روش‌ها باشد، می‌توان از واژۀ «روش‌شناسی» استفاده کنیم؛ اما زمانی که از متن مفهومِ مجموعۀ روش‌ها برآید، بهتر است از واژۀ «رَوِشگان» استفاده کنیم.
[2] (کمبود عرضه نسبت به تقاضا) undercapacity
