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

جهت دانلود متن کامل پایان نامه به سایت azarim.ir مراجعه نمایید.
 

بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند می‌باشد
 

استقبال از تغییر نیازمندی ها، حتی در اواخر فرایند توسعه. فرایندهای چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار می‌کنند.
 

تحویل زود به زود نرم‌افزار قابل استفاده دو،سه هفته یک بار تا دو ، سه ماه یک بار، با ترجیح بر فاصله‌های زمانی کوتاه‌تر.
 

ذی نفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنند.
 

پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند.
 

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

نرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت است.
 

فرایندهای چابک توسعه پایدار را ترویج می دهند حامیان مالی , توسعه دهندگان و کاربران باید بتوانند
سرعت پیشرفت ثابتی را برای مدت نامحدودی حفظ کنند.
 

توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.
 

سادگی — هنر به حداکثر رساندن مقدار کار انجام نشده — ضروری است.
 

بهترین معماری ها، نیاز مندی ها و طراحی ها از تیم های خود سازمانده پدیدار می شود.
 

در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و همسو مینماید.
 

توسعه نرم افزار چابک
 

۲-۴ توسعه نرم افزار چابک
در این قسمت به بررسی چابکی و روش های چابک منتخب خواهیم پرداخت.

چابکی[۵] به معنای واقعی
 

هدف از روش های چابک این است که به سازمانها اجازه دهند که چابک باشند اما واقعا معنای چابکی چیست؟ در پاسخ به این سوال نظرات متعددی ارائه شده است.
یک نظریه، چابکی را اینگونه تعبیر می کند « تحویل سریع، تغییر سریع و تغییر دائم» . در حالی که روش های چابک در فعالیت ها و تأکید بر ارزش ها متفاوت هستند اما در مواردی چون تأکید بر توسعه تکراری، ارتباطات، کاهش محصولات غیر ضروری یکسان هستند. توسعه نرم افزار در یک فرایند تکراری به تیم توسعه دهنده امکان تطبیق سریع با تغییر نیازمندیها را می‌دهد. کار در یک مکان بسته و تأکید بر ارتباطات به این معنی است که تیم می‌تواند سریع تصمیم گیری نموده و بر اساس این تصمیمات اقدام نموده و منتظر دریافت پاسخ و نظر از خارج سازمان نباشد. کاهش محصولات میانی که ارزش افزوده ای برای محصول نهایی و قابل ارائه ندارند، کمک می‌کند که منابع بیشتری در بخش توسعه محصول اصلی صرف شده و در نتیجه محصول سریع تر تولید شود. بخش عمده ای از جنبش چابک مربوط به قدرت و توان برنامه نویس است [۱۳, ۱۴]. این توانمندی اجازه مانور بیشتری به افراد در فرایند توسعه نرم افزار می‌دهد [۱۵]. این دقیقا همان نقطه ای است که فرایند چابک می‌تواند سریع تر به تغییر نیازمندی ها در مقایسه با روش های سنتی پاسخ دهد.
در نظریه دیگری در خصوص چابک سازی اشاره شده است که فعالیت های ارائه شده در فرایندهای چابک چندان نشانگر چابکی نیست، بلکه چیزی که آنها را واقعا چابک می کند، به رسمیت شناختن افراد به عنوان عامل اصلی موفقیت پروژه به همراه تأکید شدید بر کارایی و قابلیت مانور آنها است [۸].
همه صاحبنظران تأکید دارند که چابک شدن صرفا به پیروی ساده از یک سری دستورالعملها نیست. چابکی واقعی فراتر از مجموعه ای از فعالیت ها است. چابکی واقعی یک چارچوب (قالب) فکری است. در واقع شاید با اجرای مجموعه ای از فعالیت ها به نظر برسد که چابک شده ایم اما چابکی را حس نخواهیم کرد[۱, ۱۵].

۲-۵ مجموعه ای از روش های چابک
 

روش های چابک در موارد متعددی چون ارزشها مشترک هستند، اما در فعالیت هایی که هر کدام ارائه می‌دهند، متفاوت می‌باشند. برای آشنایی بیشتر با این روشها و خصوصیات آنها چند روش به صورت اجمالی معرفی خواهند شد. سعی می شود که عمق و وسعت بحث آتی در مورد هر کدام از آنها فراتر از مجال این مطالعه نباشد. طبعا مطالعه کاملتر هر روش حوصله ای فراتر از این گزارش را می خواهد که هدف اصلی این رساله نیست. نکته قابل ملاحظه در این خصوص عدم تناسب مستندات موجود در خصوص این روشها است. به عنوان مثال در خصوص روش XP مستندات بسیار مناسب و جامعی موجود است اما در مورد روشی چون DSDM چندان مستند قابل اتکایی وجود ندارد. بقیه روشها نیز از این حیث در بین این دو قرار دارند.

۲-۵-۱ روش Extreme Programming (XP)
 

روشXP بی شک یکی از معروفترین و پر طرفدارترین روش های چابک است. این روش که در ابتدا در سال ۱۹۹۸ معرفی شد [۱۶]، در سال بعد آن با انتشار کتاب معروف Kent Beck به نام « Extreme Programming Explained: Embracing change» بیشتر مورد توجه قرار گرفت. این روش بیشتر مورد توجه برنامه نویسانی قرار گرفت که از روش های سنتی توسعه نرم افزار سرخورده شده بودند[۷] و به دنبال فعالیت های جدید و فوق العاده تری بودند. دوازده قاعده XP مانند خود روش، ساده و مختصر هستند. این سادگی چنان است که هر کس می تواند بدون خواندن حتی یک صفحه از کتاب فوق آن را پیاده نماید[۱۰].

بازی برنامه ریزی[۶]
 

نیازمندی ها را داستان های کاربر می نامند. هر نیازمندی بر روی یک کارت داستان درج می‌گردد و زمان مورد نیاز برای اجرای آن نیز تخمین زده می شود. در این روش نیازمندی ها به زبانی ساده و داستان گونه که برای همه عوامل قابل فهم باشند، نوشته می شوند. در شروع هر تکرار، در جلسه ای با حضور مشتری، مدیران و توسعه دهندگان، نیازمندی های کاربر، برای آن تکرار بررسی شده و اولویت بندی می‌گردند.

نشرهای کوچک[۷]
 

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

استعاره (تشبیه)[۸]
 

مشریان، مدیران و توسعه دهندگان XP تشبیه یا استعاره هایی را برای مدل سازی سیستم می سازند. در واقع اعتقاد بر این است که هر سیستم نرم افزاری بر اساس یک استعاره یکپارچه سازی شده است. بر اساس کتاب Beck، استعاره سیستم، داستانی است که همه مشتریان، برنامه نویسان و مدیران می توانند در مورد چگونگی کار سیستم بیان کنند. در واقع بیانی عامیانه از سیستم در حال توسعه را به عنوان ملاکی برای بحث در مورد سیستم به رسمیت می شناسد.

تست ها
 

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

طراحی ساده
 

از توسعه دهندگان خواسته شده که طراحی را تا حد ممکن ساده انجام دهند. « همه چیز یکبار و فقط یکبار گفته می شود» [۵] در طراحی ساده فرض بر این است که توسعه دهندگان نباید نیازهای پروژه را پیش بینی نمایند و باید فقط ساده ترین کاری که قابل انجام است را انجام دهند.

بازسازی[۹]