مهندسی نرم افزار بایستی فرایندهایی را تولید کند که نه تنها به تغییرات پاسخ دهند بلکه از آنها استقبال هم بنمایند. این فرایندها و متدها، روش های چابک نامیده میشوند و امروزه جای خود را در شرکتهای تولید کننده نرم افزار در برخی از نقاط دنیا یافته اند و در برخی دیگر کم کم نمود خواهند یافت.
در این بخش به بررسی این روشها و جایگاه آنها در مهندسی نرم افزار خواهیم پرداخت. در بخش اول این گزارش تاریخچه ای از چگونگی شکل گیری این روشها ارائه خواهد شد، سپس در بخش بعد ضمن بررسی مفهوم چابکی متدهای معروف را بررسی خواهیم کرد.
۲-۲ تاریخچه
روش های چابک به عنوان یک واکنش به مشکلات روش های سنتی تولید نرم افزار معرفی شده اند. روش های سنتی با مشکلاتی چون «مستند سازی سنگین، قراردادهای کاری دقیق، برنامه ریزی کامل، طراحی نهایی و …» شناخته میشوند[۲]. در واقع در روش های سنتی، کار با یک مستند دقیق و کامل به نام “نیازمندیهای سیستم” شروع میشود، سپس طراحی معماری و طراحی سطح بالا و جزئیات به دنبال آن باید اجرا گردند و کار با توسعه (تولید کد) و بازرسی دنبال می گردد. از نیمه دوم دهه نود برخی از صاحبنظران نرم افزار به این نتیجه رسیدند که شروع فرایند تولید نرم افزار با فازهای سنگین و دقیق مطالعه نیازمندی ها و طراحی کامل، بسیار وقت گیر و در مواقعی غیر قابل انجام است[۷]. در واقع رشد سریع صنعت و لزوم تغییر نیازمندیها مجالی برای استفاده از روش های سنتی نمیداد. بسیاری از مشتریان در ابتدای کار نمیتوانستند نیازمندی های خود را به طور دقیق و کامل بیان کنند، در عین حال انتظارات آنها از محصول نهایی هم فراتر از بیان اولیه آنها بود. در نهایت برخی از متخصصین به طور مجزا به ایجاد تغییراتی در فرایندهای تولید نرم افزار خود نمودند که به نحوی بتوانند پاسخگوی مشکل فوق باشند. در واقع با ایجاد فعالیتهای جدید در فرایند توسعه نرم افزار اقدام به ایجاد ارزشهایی در فرایند توسعه نموده اند که تا حدی می توانست مسائل مربوط به تغییر سریع صنعت و نیاز آن را جوابگو باشد. بررسی اجمالی این روشها نشان میدهد که در خیلی از موارد این روشها فعالیت کاملاً جدیدی را نشان نمی دهند]۸[، آنچه در این روشها بیشتر به چشم میخورد توجه به ارزشهایی است که نسبت به روش های سنتی پررنگ تر شده اند. بهبود فرایند نرم افزار فرایندی تکاملی است به نحوی که فرایندهای جدیدتر بر پایه توفیق ها و یا شکستهای فرایندهای پیشین ساخته میشوند و شاید حقیقت امر این باشد که برای شناخت روش های چابک لازم باشد فرایندهای پیش از این روشها نیز بررسی شوند.
روش (مدل) آبشاری [۱] اولین فرایند توسعه نرم افزار بوده]۹[که با شناخت و تحلیل کامل نیازمندیهای کاربر شروع میشود. برای این امر تحلیل گران لازم است تا چندین ماه به طور کامل همه نیازمندیهای کاربر را بررسی کرده و مستندات دقیقی در خصوص آنها تهیه و به تأئید کاربر برسانند. سپس برنامه نویسان با بررسی کامل این مستندات اقدام به طراحی دقیق جزئیات کاربردی نرم افزار نموده و پس از آن مرحله تولید (کدنویسی) سیستم انجام میگیرد و در نهایت پس از تست کامل سیستم، محصول به بازار عرضه میگردد [۱۰].
این فرایند در حالت تئوری خوب و مناسب به نظر میرسد، اما در عمل برخلاف آنچه به نظر میرسد، در موارد زیادی درست کار نمیکند. در درجه اول کاربران پس از مدتی نظراتشان عوض می شود و گاهاً پس از ماه ها و یا حتی سالها علیرغم تهیه مستندات کامل از نیازمندیهای کاربران، آنها هنوز مطمئن نیستند که دقیقاً چه چیزی نیاز دارند. در درجه دوم پس از مدتی نیازمندیهای گفته شده، در ذهن تولیدکنندگان نقش میبندد و تغییر این موارد دشوارتر از قبل خواهد شد. روش های سنتی وقتی نرخ تغییرات در نیازمندیها پایین باشند، هنوز هم مناسب هستند]۱۱[، چرا که کاربران، تولیدکنندگان، معماران و مدیران سیستم لازم است که همه تغییرات (هرچند کوچک) را در نظر بگیرند و لحاظ نمایند. در مدل آبشاری فرض بر این است که نیازمندیها تغییر نمی یابند و تا پایان پروژه ثابت هستند و برای اطمینان از این امر، در مواردی تائید رسمی کاربر را نیز دریافت میکنند. اما در نهایت ممکن است، محصول کاربردی مناسبی ایجاد نگردد. تکنیکهای توسعه نرم افزار تدریجی (تکاملی) و تکراری برای حل نقص فوق، بر پایه تقسیم چرخه تولید نرم افزار آبشاری به چندین قسمت، بنا نهاده شده اند [۱۲]. روش توسعه تدریجی تأکید بر کاهش زمان توسعه دارد و برای حصول به این امر، اقدام به شکست پروژه به چندین بخش می نماید که این بخشها می توانند در زمان توسعه همپوشانی داشته باشند، اگرچه این تکامل باز هم بر اساس مدل آبشاری انجام میگیرد. در واقع تنها دستاورد این روش (ها) کاهش زمان توسعه است و کماکان مسائل مربوط به نیازمندیها و مشکل تغییر در آنها وجود دارد.
در زمانی که روش های توسعه تدریجی[۲]، کاهش زمان توسعه را به ارمغان آورده بودند، روش های تکاملی دیگر نیز چون روش اسپیرال[۳] و روش های تکراری[۴] با هدف مدیریت بهتر تغییرات نیازمندی ها و ریسک توسعه پا به عرصه گذاشتند. روش های تکراری، پروژه را به چند بخش مجزا (قابل تکرار) تقسیم میکردند که هر بخش میتوانست در یک تکرار به طور کامل توسعه و آماده ت
حویل گردد. اولین چرخه تکرار، با ابتدایی ترین بخشهای قابل تحویل شروع میشد و تکرارهای بعد، ویژگی ها و کاربردهای بیشتری را به آنها اضافه می کردند. هر تکه از محصول از طریق روش آبشاری با بررسی نیازمندیهای خاص آن بخش و پس از آن طراحی، پیاده سازی و تست توسعه می یافت. در واقع در هر تکرار، تنها نیازمندیهای مربوط به همان تکرار مورد بررسی قرار میگیرد و نیازی به بررسی کامل نیازمندیهای کاربر در همه زمینه ها نیست و به همین دلیل تا حدی اجازه بررسی بیشتر نیازمندی ها به کاربر داده میشد. همچنین در مدل اسپیرال امکان اولویت بندی نیازمندیهای کاربر نیز وجود دارد و این امر تا حدی از ریسک پروژه میکاهد. توسعه چرخشی (اسپیرال) و تکراری گام بزرگی در جهت چابک سازی فرایند آبشاری ارائه دادند. بسیاری از صاحبنظران معتقدند که این تکنیک نیز جوابگوی تغییر نیازمندیهای کاربران نیست و پاسخگویی سریع به تغییر نیازمندیها امروزه امری حیاتی و الزامی است.
۲-۳ بیانیه چابک
در ابتدای سال ۲۰۰۱، هفده تن از حامیان تفکر چابک در مهندسی نرم افزار، گرد هم آمدند تا به بررسی روش های جدید توسعه نرم افزار بپردازند. در پایان این نشست آنها با تدوین و امضای بیانیه ای که بیانیه چابک نامیده میشود، رسماً روش های چابک را معرفی نمودند]۲[. افراد حاضر در این گردهمایی نمایندگان روش های چابکی بودند که قبلاً به صورت مجزا در حال بهبود فرایند توسعه نرم افزار بودند. برخی از این روشها عبارتند از [۱] :
Crystal, Scrum, Extreme Programming (XP), FDD, ASD, DSDM, Agile Modeling and Pragmatic Programming
این افراد اذعان داشتند که حرکت به سوی چابکی یک ضد متدولوژی نیست، بلکه حرکت به سوی توازن توسعه نرم افزار و دادن اعتبار بیشتر به متدولوژی است. آنها در سخنان خود اشاره کردند که از مدلسازی استقبال میکنند اما مخالف تولید فایلهای متعدد و دیاگرامهای ناکارا هستند. همچنین از مستندسازی نیز استقبال خواهند کرد، اما نه از مستند سازی که منجر به تولید چند صد صفحه بلا استفاده و ناکارا باشد. برنامه ریزی نیز به صورتی که خلاصه و کارا باشد مورد تأئید است. آنچه در این میان مشهود است تأکید بر عوامل اصلی ناکارایی متدولوژی های پیشین در برخورد با واقعیت های جاری صنعت و ذی نفعان نرم افزار است. آنچه در این گردهمایی متخصصین به چشم میخورد این بود که روشهایی که هر کدام ارائه میدادند شاید در ظاهر دارای تعاریف و تمرینات و فعالیت های مخصوص به خود بودند ولی هدف و خاستگاه همه آنها دستیابی به ارزش هایی است که در روش های سنتی یا نمی توان به آنها رسید یا دستیابی به آنها مستلزم هزینه و پیچیدگی بیشتر می باشد.
این افراد ضمن تأکید بر مشترکات خود مبنایی غیر فنی و مستقل از فعالیت های مربوط به متدولوژی های توسعه نرم افزار را برای رسمیت بخشیدن به روش های چابک بنا نهادند و طی یک بیانه مشترک که بیانیه چابک نامگذاری شد، رسالت این متدولوژی ها را بیان کردند.
این بیانیه به این شرح است:
ما با توسعه نرم افزار و کمک به دیگران در انجام آن در حال کشف راه های بهتری برای توسعه نرم افزار هستیم
از این طریق باید به این ارزشها دست یابیم:
افراد و تعاملات بالاتر از فرآیندها و ابزارها
نرم افزار کارکننده بالاتر از مستندات جامع
مشارکت مشتری در انجام کار بالاتر از قرارداد کار
پاسخگویی به تغییرات بالاتر از پیروی یک طرح
با وجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.
بیانیه چابک تبدیل به بخش مهمی از حرکت (انقلاب) چابک گردیده است چرا که در آن ضمن برشمردن ارزشهای چابک تفاوت چابکی با روش های سنتی نیز پررنگ شده است.
ارزش اول ارائه شده از آنجا ناشی میشود که مهندسین نرم افزار در روش های سنتی بیش از حد درگیر پیگیری فرایند هستند و ساختار این متدولوژی ها نیز چنان است که توجه چندانی به افراد و نقش آنها در فرایند توسعه نشده است[۱۳]. در حالی که امروزه اکثر دست اندر کاران صنعت نقش افراد را در تولید، پررنگ تر از فرایند میدانند [۱۳]. در خصوص ارزش دوم تأکید بر خود نرم افزار نهایی است. اگرچه مستندات نیز اهمیت خود را دارند، اما آنچه هدف نهایی فرایند توسعه نرم افزار است، محصول کاربردی است و در عمل هم تجربه چند دهه قبل نشانگر بلا استفاده بودن کوهی از مستندات تولید شده است. در بیان ارزش سوم، تأکید بر روی رضایت مشتری است و آن را بر پیروی از قرارداد ارجح میداند. در واقع ارزش محصول مناسب برای کاربر، فراتر از محصول ایجاد شده بر اساس قرارداد و عدم عدول از آن است. این امر شاید منتقدانی نیز داشته باشد [۱۳] اما در نهایت با تعامل مناسب با مشتری میتوان در قرارداد کاری نیز اجازه مانور به هر دو طرف داد. ارزش چهارم که شاید یکی از کلیدی ترین مفاهیم چابک باشد، بر استقبال از تغییرات در برابر پیروی از یک برنامه تأکید دارد. در واقع برنامه ریزی کامل که در مهندسی نرم افزار بر پایه تشخیص کامل نیازمندیها صورت میپذیرد، ناقض و مانع چابکی فرایند در پاسخگویی به تغییرات نیازمندیها میباشد .
عمده انتقاداتی که طرفداران روش های سنتی از روش های چابک دارند به اصول فوق برمیگردد. ، عمده نگرانی های طرفداران روش های سنتی پیروی آنها از مدلهای معروفی چون CMMI است که شاید در رویارویی با تفکر چابک در مواردی نفی گردند
در ادامه بیانیه چابک اصول دوازده گانه چابک به عنوان متمم آن و به شرح زیر آمده اند.
این اصول تا حدی نشانگر چارچوب فعالیت
های مورد نیاز برای دستیابی به اصول چابک هستند. فعالیت های چابک عمدتاً برای دستیابی به این اصول طراحی و به کار گرفته میشوند.
بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند میباشد
استقبال از تغییر نیازمندی ها، حتی در اواخر فرایند توسعه. فرایندهای چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند.
تحویل زود به زود نرمافزار قابل استفاده دو،سه هفته یک بار تا دو ، سه ماه یک بار، با ترجیح بر فاصلههای زمانی کوتاهتر.
ذی نفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنند.
پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند.
کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم، گفتگوی چهره به چهره است.
نرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت است.
فرایندهای چابک توسعه پایدار را ترویج می دهند حامیان مالی , توسعه دهندگان و کاربران باید بتوانند
سرعت پیشرفت ثابتی را برای مدت نامحدودی حفظ کنند.
توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.
سادگی – هنر به حداکثر رساندن مقدار کار انجام نشده – ضروری است.
بهترین معماری ها، نیاز مندی ها و طراحی ها از تیم های خود سازمانده پدیدار می شود.
در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و همسو مینماید.
توسعه نرم افزار چابک
۲-۴ توسعه نرم افزار چابک
در این قسمت به بررسی چابکی و روش های چابک منتخب خواهیم پرداخت.
چابکی[۵] به معنای واقعی
هدف از روش های چابک این است که به سازمانها اجازه دهند که چابک باشند اما واقعا معنای چابکی چیست؟ در پاسخ به این سوال نظرات متعددی ارائه شده است.
یک نظریه، چابکی را اینگونه تعبیر می کند « تحویل سریع، تغییر سریع و تغییر دائم» . در حالی که روش های چابک در فعالیت ها و تأکید بر ارزش ها متفاوت هستند اما در مواردی چون تأکید بر توسعه تکراری، ارتباطات، کاهش محصولات غیر ضروری یکسان هستند. توسعه نرم افزار در یک فرایند تکراری به تیم توسعه دهنده امکان تطبیق سریع با تغییر نیازمندیها را میدهد. کار در یک مکان بسته و تأکید بر ارتباطات به این معنی است که تیم میتواند سریع تصمیم گیری نموده و بر اساس این تصمیمات اقدام نموده و منتظر دریافت پاسخ و نظر از خارج سازمان نباشد. کاهش محصولات میانی که ارزش افزوده ای برای محصول نهایی و قابل ارائه ندارند، کمک میکند که منابع بیشتری در بخش توسعه محصول اصلی صرف شده و در نتیجه محصول سریع تر تولید شود. بخش عمده ای از جنبش چابک مربوط به قدرت و توان برنامه نویس است [۱۳, ۱۴]. این توانمندی اجازه مانور بیشتری به افراد در فرایند توسعه نرم افزار میدهد [۱۵]. این دقیقا همان نقطه ای است که فرایند چابک میتواند سریع تر به تغییر نیازمندی ها در مقایسه با روش های سنتی پاسخ دهد.
در نظریه دیگری در خصوص چابک سازی اشاره شده است که فعالیت های ارائه شده در فرایندهای چابک چندان نشانگر چابکی نیست، بلکه چیزی که آنها را واقعا چابک می کند، به رسمیت شناختن افراد به عنوان عامل اصلی موفقیت پروژه به همراه تأکید شدید بر کارایی و قابلیت مانور آنها است [۸].
همه صاحبنظران تأکید دارند که چابک شدن صرفا به پیروی ساده از یک سری دستورالعملها نیست. چابکی واقعی فراتر از مجموعه ای از فعالیت ها است. چابکی واقعی یک چارچوب (قالب) فکری است. در واقع شاید با اجرای مجموعه ای از فعالیت ها به نظر برسد که چابک شده ایم اما چابکی را حس نخواهیم کرد[۱, ۱۵].
۲-۵ مجموعه ای از روش های چابک
راهنمای نگارش پایان نامه در مورد ارائه مدلی برای اندازه گیری میزان چابکی در ...