فرایند یکپارچه رشنال

با توجه بیشتر به مدل حلزونی نسبت به مدل توسعه سریع برنامه کاربردی(RAD) و با هدف توسعه برنامه های کاربردیِ مقیاس بزرگ که نیرومندی، مقیاس پذیری و قابلیت گسترش در آن ها ضروری هستند، فرایندی تحت عنوان فرایند یکپارچه رشنال(RUP) در دهه 1990 راه اندازی شد. RUP مدل فرایند نرم افزار تکراری و تدریجی است که به طور گسترده برای توسعه نرم افزار مورد استفاده قرار می گیرد. فرایند RUP توسط بخش نرم افزار رشنال که متعلق به شرکت IBM است به طور فعال به بازار عرضه و پشتیبانی می شود. ثابت شده است که RUP برای راهنمایی و مدیریت عملی توسعه برنامه های کاربردی دارای مقیاس بزرگ چارچوبی موثری است. این فرایند به طور گسترده در صنعت مورد استفاده قرار می گیرد(دارای میلیون ها شاغل است) و با موفقیت بر روی هزاران پروژه از انواع مختلف اعمال شده است. به طوری که این موفقیت ها شامل پروژه هایی با مقیاس های بسیار بزرگ نیز هستند. فرایند یکپارچه رشنال، اولین فرایند نرم افزاری است که به طور گسترده مورد استفاده قرار گرفت و ضرورت هم پوشانی فعالیت ها در چرخه عمر فازهای آغازین، تشریح، ساخت و انتقال را تشخیص داد. به عنوان نمونه، فعالیت هایی همانند «نیازمندی ها» فقط به یک فاز منفرد واگذار نمی گردند. اگرچه، فعالیت های نیازمندی ها بیشتر در فازهای آغازین و تشریح مورد توجه قرار می گیرند، اما با این وجود تشریح و تغییر نیازمندی ها به صورت فرایندی مداوم در طول چرخه عمر پروژه نیز اتفاق می افتد. اخیراً، نمونه های سبک وزن تر و چابک تری از RUP شامل Agile RUP و OpenUP(یک فرایند متن  باز که تحت نظر بنیاد اکلیپس است) در دسترس قرار گرفته اند.

(فرایند یکپارچه رشنال)

توسعه سریع برنامه کاربردی

توسعه سریع برنامه کاربردی(RAD) اکنون به عنوان اصطلاحی عام برای یک نوع فرایند توسعه که توسط جیمز مارتین در اوایل دهه 1990 معرفی شد، در نظر گرفته می شود. این مدل اساساً مدل فرایند نرم افزار به خوبی تعریف شده است که بر روی توسعه تکراری و ساخت مجموعه ای از نمونه های اولیه متمرکز است به طوری که امروزه به عنوان مخفف تعدادی از رهیافت های سبک وزنی( این رهیافت ها زبان های نسل چهارم و چارچوب هایی همانند چارچوب های برنامه کاربردی وب را استفاده می کنند) که قابلیت دسترسی نرم افزار اجرای را شتاب می دهند، مورد استفاده قرار می گیرد. این چارچوب ها و رهیافت های سطح بالا بر روی سرعت استقرار و بازخوردها تاکید بیشتری نسبت به کارایی و قابلیت مقیاس پذیری دارند. از دیدگاه نیازمندی های نرم افزار اگر بتوانیم نیازمندی ها را قبل از اینکه تغییر کنند به سرعت پیاده سازی کنیم امکان موفقیت بیشتری خواهیم داشت. در صورتی که نیازمندی ها را اشتباه پیاده سازی کنید، ابزارها به اندازه کافی آسان و سبک وزن هستند که بتوانید دوباره آن ها را سریع تر از روش های کشف نیازمندی های سنتی و کاغذی بسازید. در حقیقت، این تصور نوید دهنده ظهور روش ها است. این مدل در شکل ذیل نشان داده شده است.

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

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

حتی با وجود این شواهد آشکار، امروزه مدل آبشاری باز هم به طور گسترده مورد استفاده قرار می گیرد. همان طوری که در شکل ذیل نشان داده شده است. با توجه به کمبودهای مدل آبشاری جای بسی تعجب است که چرا این مدل تا سال 2010 و حتی پس از آن هم مورد استفاده قرار می گیرد. شاید به دلیل وجود برخی دلایل قابل درک ذیل باشد:

• خود مدل برای برطرف کردن مسائلی که در گذشته وجود داشت متولد شده بود. یکی از این مسائل مربوط به نگرش «کد نویسی کن، خطای آن را برطرف کن، دوباره کد نویسی کن تا زمانی که آن قابل نگهداری باشد» بود. 
• مدل به شدت منطقی و تجویزی است. در ابتد نیازمندی ها درک می شود پس از آن سیستم منطبق با نیازمندی ها طراحی می گرد و در نهایت سیستم پیاده سازی و آزمون می شود. چه چیزی می تواند عاقلانه تر و منطقی تر از این رهیافت باشد؟ 
• توسط این مدل نرم افزارهای بسیاری را عرضه کردایم و هنوز هم عرضه می کنیم. در نتیجه شرکت ها مدل های حاکمیتی پروژه و برنامه خود را حول چرخه نرم افزار معیوب شان ساخته اند. این مدل ها شامل مورد کسب و کار و تاییدیه ای سرمایه گذاری، نقاط عطف مرور پروژه و تضمین کیفیت و مواردی از این قبیل هستند. 
• مدل آبشاری تداوم واقعیت بازار را منعکس می کند(مشتریان هنوز هم توافقاتی با تاریخ و نیازمندی های ثابت را بر روی تامین کنندگان تحمیل می کنند و احتمالا آن ها این کار را برای سال های آینده نیز ادامه خواهند داد. البته گاهی اوقات خود ما هستم که آن ها را بر روی خودمان تحمیل می کنیم)

(مدلی که در دهه 1970 ابداع شده است، به طوری که امروزه نیز استفاده می گردد)

آیا نباید اسب مرده را مورد ضرب و شتم قرار داد؟

مدل آبشاری را در اینجا بیش از حد توضیح دادیم در صورتی که نباید «اسب مرده را مورد ضرب و شتم» قرار داد، اما تصدیق می کنیم که این اسب خاص ممکن است هنوز هم زنده باشد و به بسیاری از زمینه های کسب و کار لگد بزند. بدون توجه به اینکه چگونه می خواهیم چابک باشیم، مجبور خواهیم بود تا از ضربه های سُم این اسب در آینده جلوگیری کنیم. در حقیقت این می تواند بر روی آزادی عمل ما در پیاده سازی تجربه های نیازمندی های چابک شدیداً تاثیر بگذارد. کار ما به عنوان متخصصان چابک این است که به کسب و کار کمک کنیم تا به یک الگوی چابک موثر مهاجرت کند. بنابراین، ما نمی خواهیم از مدل آبشاری استفاده کنیم، اما مجبور هستیم آن را به دلیل اینکه در حال حاضر استفاده می شود درک کنیم.

نیازمندی ها در مدل آبشاری: مثلث آهنین

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

(هنگامی که نیازمندی ها شناخته شده باشند می توانید هزینه و زمانبندی را تخمین بزنید)

احتمالا در مثلث آهنین زمانبندی و بودجه نیز ثابت بودند(از همه گذشته، چه کسب و کاری می تواند منابع و هزینه پروژه به شدت متغیر را برنامه ریزی کند؟). بنابراین از یک دیدگاه واقع بینانه تر، این موضوع ما را به سوی تله «مثلث آهنین» هدایت می کند. همان طوری که شکل ذیل نشان می دهد.

در حقیقت، فرض « ثابت بودن محدوده نیازمندی ها» علت اصلی شکست پروژه است. به عنوان نمونه، یک مطالعه مهم انجام شده بر روی 1027 پروژه تکنولوژی اطلاعات در انگلیس [Thomas 2001] بیان می کند که: «مدیریت محدوده وابسته به تجربه های مدل آبشاری بزرگ ترین معیار مشارکت کننده برای شکست پروژه بود است». نتیجه مطالعه به شرح ذیل است:

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

(تله مثلث آهنینِ مدل آبشاری)

مشکلات مربوط به مدل آبشاری

همانطوری که احتمالا رویس پیش بینی کرده بود، مدل آبشاری برای پروژه های نرم افزاری بزرگ به خوبی کار نمی کرد و ما برای توسعه نرم افزار، زیر بار این مدل سخت تقلا می کردیم. نتایج آمارها در طول یک یا دو دهه گذشته خیلی خوب نبودند. به عنوان نمونه، استندیش گروپ در گزارش [Standish 1994] به موارد ذیل اشاره کرده است: 

• 31 درصد از پروژه ها قبل از اینکه به اتمام برسند، کنسل شده اند.
• 53 درصد از پروژه ها بیش از 189 درصد از تخمین شان، هزینه صرف کرده اند.
• تنها 16 درصد از پروژه ها در زمان مقرر و با بودجه مصوب به پایان رسیده اند.
• پروژه های تکمیل شده در شرکت های بزرگ تر تنها 42 درصد از ویژگی ها و کارکردهای اصلی خود را تحویل داده اند.

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

• فقدان ورودی کاربر: 13 درصد از کل پروژه ها
• نیازمندی ها و مشخصات ناقص: 12 درصد از کل پروژه ها 
• تغییر نیازمندی ها و مشخصات: 12 درصد از کل پروژه ها

فرایندهای پیشگویانه و آبشاری

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

ویستون رویس که در آن زمان در TRW بود به دلیل ایجاد این مدل مورد تحسین و تکریم قرار گرفت. از قضا، رویس بیان کرده بود که این مدل برای توسعه سیستم های نرم افزاری با مقیاس بزرگ پیشنهاد نمی شود. او در مقاله بنیادین [Royce1970] مطلب ذیل را عنوان کرده است:

طبق تجربه ام، مدل ساده ای [همانند آنچه در شکل بالا نشان داده شده است] برای توسعه نرم افزار بزرگ هرگز کار نخواهد کرد.

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

جنبش های فرایند نرم افزار

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