مدلهای فرآیند تولید نرم‌افزار

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

‏مدلهای فرآیند تولید نرم‌افزار سنتی (ساختیافته)

مدل‌های فرآیند تولید نرم‌افزار سنتی بر دو دسته‌ی کلی غیرتکاملی سنتی و تکاملی سنتی هستند:

مدل‌های غیرتکاملی سنتی

‏مدل‌های فرآیند غیرتکاملی سنتی یا تجویزی (Prescriptive) در ابتدا برای نظم بخشیدن به فرآیند تولید نرم‌افزار پیشنهاد شدند. این مدل‌های سنتی به میزان نسبتاً قابل قبولی به کار مهندسی نرم‌افزار ساختار بخشیده‌اند و راهنمای اثربخشی برای تیم‌های نرم‌افزاری بوده‌اند. این مدل‌ها را تجویزی می‌نامند، زیرا مجموعه‌ای از فعالیت‌های چارچوبی و چتری را برای هر پروژه تجویز می‌کنند. در این مدل‌ها، تولید نرم‌افزار مطابق فعالیت‌های چارچوبی، مراحل مختلفی دارد که هر مرحله‌ دارای ورودی، فعالیت و خروجی خاص خود می‌باشد. خروجی هر مرحله در این مدل‌ها، ورودی مرحله بعدی است و از فعالیت ارتباطات تا استقرار ادامه می‌یابند.

۱- مدل آبشاری (Waterfall model)

‏مدل آبشاری، که گاه از آن به عنوان چرخه‌ی حیات کلاسیک یاد می‌شود، روشی ترتیبی برای تولید نرم‌افزار پیشنهاد می‌کند. این مدل با فعالیت ارتباطات شروع می‌شود و با فعالیت‌های برنامه‌ریزی، مدل‌سازی (تحلیل و طراحی) و ساخت (پیاده‌­سازی و تست) پیش می‌رود و با فعالیت استقرار پایان می‌یابد، تحویل پروژه انجام می‌گیرد و کار تمام می‌شود. و دیگر فرصت و تکرار دیگری در کار نخواهد بود تا خواسته‌های فراموش شده یا جدید به پروژه اضافه گردد.

‏خصوصیت اصلی این مدل این است که هیچ‌گونه بازخوردی بین مراحل این مدل وجود ندارد. مانند آب که نمی‌تواند در آبشار به عقب برگردد، در این مدل نیز بعد از ورود به یک فعالیت به فعالیت‌­های قبلی نمی‌توان بازگشت. این مدل زمانی کاربرد دارد که کلیه‌ی نیازمندی‌های مشتری در همان ابتدای پروژه مشخص، ثابت و بدون تغییر باشد. بنابراین این مدل در تولید پروژه‌های کوچک ساده (مانند سیستم حقوق و دستمزد واحد حسابداری که نیازمندی‌های مشخص و ثابتی دارد.) و یا تولید مجدد پروژه‌های بزرگ و حتی پیچیده‌ی از قبل از ساخته شده (به دلیل مشخص بودن لیست نیازمندی‌ها در تولید مجدد) کارایی بالایی دارد و کارآمد خواهد بود.

‏اما در پروژه‌های بزرگ و پیچیده به دلیل عدم مشخص بودن تمام نیازمندی‌ها در ابتدای پروژه و حتی تغییرات نیازمندی‌ها در حین انجام پروژه کارایی پایینی خواهد داشت. مدل آبشاری در شرایطی که خواسته‌ها به طور کامل و جامع مشخص، ثابت و پایدار است و قرار است که کار تا پایان به شیوه‌ای خطی پیش برود، می‌تواند به عنوان مدلی مفید، مورد استفاده قرار گیرد.

برای مثال، در بسیاری از پروژه‌های ساختمان‌سازی، نیازمندی‌ها از قبل مشخص هستند، بنابراین فرآیند تولید پروژه را می‌توان براساس مدل آبشاری بنا نهاد. اما در دنیای نرم‌افزار چنین پروژه‌هایی به ندرت وجود دارد. به گونه‌ای که بسیاری از متخصصان نرم‌افزار بر این عقیده‌اند که تمام پروژه‌هایی که نیازمندی‌هایش به طور جامع و کامل مشخص باشند، قبلاً توسط دیگران انجام شده‌اند!

توجه: به مدل آبشاری، مدل خطی (Linear Model) و مدل ترتیبی (Sequential Model) نیز گفته می‌­شود.

معایب مدل آبشاری

۱- پروژه‌های واقعی به ندرت جریان ترتیبی پیشنهاد شده توسط این مدل را دنبال می‌کنند. ترتیبی بودن روال فعالیت‌های ارتباطات تا استقرار در این مدل نیازمند مشخص بودن تمامی نیازمندی‌های پروژه در ابتدای کار می‌باشد اما ماهیت اغلب پروژه‌های نرم‌افزاری بدین گونه نیست که تمامی نیازمندی‌ها در ابتدای پروژه مشخص باشند. بنابراین این مدل در مواردی که همه‌ی نیازمندی‌ها در ابتدای پروژه مشخص نباشد به دلیل ماهیت ترتیبی بودن مدل و عدم بازگشت به عقب کارایی لازم را نخواهد داشت. زیرا لازم است همه چیز ‏از ابتدا مشخص باشند، که اغلب محال است! در یک بیان ساده اینطور می‌توان بیان کرد که ماهیت اغلب پروژه‌های نرم‌افزاری بدین شکل است که به ندرت پیش می‌آید که یک مرحله را به طور کامل تمام کنند و وارد مرحله بعدی شوند. از آنجا که در اغلب پروژه‌های نرم‌افزاری نیازمندی‌ها ذره ذره شناسایی می‌شوند و منجر به تکامل نرم‌افزار در طی فعالیت‌های چارچوبی بعدی می‌شوند، مدل آبشاری در این موارد کارا نخواهد بود.

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

۳- ‏مشتری باید حوصله داشته باشد. زیرا نسخه‌ی عملیاتی را دیر می‌بیند. به عبارت دیگر تا پایان تولید نهایی نرم‌افزار امکان دیدن آن توسط مشتری وجود ندارد. بنابراین، مشتری باید تا پایان کار پروژه صبور باشد، در این میان، ایجاد یک نقص در برنامه‌ی تولید شده و یا تولید چیزی غیر از خواسته‌های مشتری ممکن است فاجعه بار باشد، زیرا مشتری پس از فعالیت ارتباطات و بیان خواسته‌ها، دیگر در حین فعالیت‌های بعدی پروژه حضور نداشته است. بنابراین مهمترین مشکل رویکرد آبشاری، ضعف ذاتی آن در غلبه بر ریسک است. در اینجا، منظور از ریسک، کلیه‌ی شرایط، عوامل و نگرانی‌هایی است که می‌توانند مانع از دستیابی به موفقیت (شناسایی نیازهای دقیق مشتری، مقرون به صرفه بودن و در زمان مورد انتظار بودن) شوند. بسیاری از ریسک‌ها تنها در زمان پیاده‌سازی و تست آشکار می‌شوند. از آنجایی که در مدل آبشاری، پیاده‌سازی و تست سیستم به انتهای پروژه موکول می‌شود، در صورت آشکار شدن یک ریسک، فرصت کمی برای مدیریت آن وجود خواهد داشت و اغلب هزینه‌های زیادی برای مقابله با آن باید صرف شود. برای مثال، وجود نقص در مدل طراحی ممکن است ناشی از وجود نقص در مدل تحلیل و شناسایی نیازمندی‌ها باشد. این مشکل تنها در زمان پیاده‌سازی و تست، آشکار می‌گردد، یعنی زمانی که تصحیح آن باعث افزایش هزینه‌ها و طولانی‌تر شدن پروژه و یا حتی بسته شدن و شکست آن می‌شود. ضعف مدل آبشاری در مواجه با ریسک‌های پیچیده در پروژه‌های امروزی، مهمترین عامل انزوای این مدل در دنیای مهندسی نرم‌افزار مدرن است. فرض کنید ‏مشتری سفارش ساخت یک میز را به نجار می‌دهد و نجار به سرعت آن را می‌سازد اما بعداً، از در اتاق مورد نظر خانه‌ی مشتری عبور نمی‌کند. زیرا مشتری و سازنده یادشان رفت بر سر اندازه‌های میز توافق کنند. این یعنی فاجعه، البته در این مورد خاص کمی فاجعه! این است که می‌گوییم اغلب مشتری در همان ابتدای کار نمی‌داند چه می‌خواهد یا یادش می‌رود دقیقاً چه می‌خواهد، انسان است و جایزالخطا بودنش، بنابراین باید بپذیریم که انسان فراموش می‌کند دقیقاً چه می‌خواهد، اما دوست دارد به او فرصت دهیم تا در حین کار و با دیدن نمونه‌هایی از پروژه بقیه‌ی خواسته‌هایش را بگوید. او اینطور خوشحال می‌شود. مدل‌های بعدی سعی در خوشحال نمودن مشتری دارند.

ارسطو خلیلی‌فر

مولف کتاب مهندسی نرم افزار راهیان ارشد

0 پاسخ ها

دیدگاه خود را ثبت کنید

آیا می خواهید به بحث بپیوندید؟
در صورت تمایل از راهنمایی رایگان ما استفاده کنید!!

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *