بسم الله الرحمن الرحيم
منشور اخلاق پژوهش
با ياري از خداوند سبحان و اعتقاد به اين که عالم محضر خداست و همواره ناظر براعمال انسان و به منظور پاس داشت مقام بلند دانش و پژوهش و نظر به اهميت جايگاه دانشگاه در اعتلاي فرهنگ وتمدن بشري، ما دانشجويان و اعضاي هيات علمي واحدهاي دانشگاه آزاد اسلامي متعهد مي گرديم اصول زير را درانجام فعاليتهاي پژوهشي مد نظر قرارداده و از آن تخطي نکنيم:
1. اصل حقيقت جويي: تلاش در راستاي پي جويي حقيقت و وفاداري به آن و دوري از هرگونه پنهان سازي حقيقت.
2. اصل رعايت حقوق: التزام به رعايت کامل حقوق پژوهشگران و پژوهيدگان (انسان، حيوان ونبات)و ساير صاحبان حق.
3. اصل مالکيت مادي ومعنوي: تعهد به رعايت کامل حقوق مادي و معنوي دانشگاه و کليه همکاران پژوهش.
4. اصل منافع ملي: تعهد به رعايت مصالح ملي و در نظر داشتن پيشبرد وتوسعه کشور در کليه مراحل پژوهش.
5. اصل رعايت انصاف وامانت: تعهد به اجتناب از هرگونه جانب داري غير علمي و حفاظت از اموال، تجهيزات ومنابع در اختيار.
6. اصل رازداري: تعهد به صيانت از اسرار و اطلاعات محرمانه افراد، سازمانها وکشور وکليه افراد ونهادهاي مرتبط با تحقيق.
7. اصل احترام: تهعد به رعايت حريم ها و حرمت ها در انجام تحقيقات و رعايت جانب نقد و خودداري از هرگونه حرمت شکني.
8. اصل ترويج: تعهد به رواج دانش و اشاعه نتايج تحقيقات و انتقال آن به همکاران علمي ودانشجويان به غير ازمواردي که منع قانوني دارد.
9. اصل برائت: التزام به برائت جويي از هرگونه رفتار غير حرفه اي و اعلام موضع نسبت به کساني که حوزه علم وپژوهش را به شائبه هاي غير علمي مي آلايند.
محل امضاي محقق و تاريخ
پرديس علوم و تحقيقات لرستان
تعهد نامه اصالت رساله يا پايان نامه
اينجانب الهام اداوي دانش آموخته مقطع کارشناسي ارشد ناپيوسته/ دکتراي حرفه اي/ دکتراي تخصصي در رشته مهندسي کامپيوتر – نرم افزار که در تاريخ ………………………….از پايان نامه/ رساله خود تحت عنوان:
” ارائه مدلي براي اندازه گيري ميزان چابکي در شرکت هاي نرم افزاري بر اساس اصول چابک ”
با کسب نمره ………….. و درجه ……………….. دفاع نموده ام بدينوسيله متعهد مي شوم:
1- اين پايان نامه/ رساله حاصل تحقيق و پژوهش انجام شده توسط اينجانب بوده و در مواردي که از دستاوردهاي علمي وپژوهشي ديگران ( اعم از پايان نامه ، کتاب، مقاله و………..) استفاده نموده ام، مطابق ضوابط و رويه موجود، نام منبع مورد استفاده و ساير مشخصات آن را در فهرست مربوطه ذکر و درج کرده ام.
2- اين پايان نامه/ رساله قبلاً براي دريافت هيچ مدرک تحصيلي (هم سطح، پايين تر يا بالاتر) در ساير دانشگاه ها و موسسات آموزش عالي ارائه نشده است.
3- چنانچه بعد فراغت از تحصيل ، قصد استفاده و هرگونه بهره برداري اعم از چاپ کتاب، ثبت اختراع و…….. ازاين پايان نامه داشته باشم، از حوزه معاونت پژوهشي واحد مجوزهاي مربوطه را اخذ نمايم.
4- چنانچه در هر مقطعي زماني خلاف موارد فوق ثابت شود، عواقب ناشي از آن را مي پذيرم و واحد دانشگاهي مجاز است با اينجانب مطابق ضوابط و مقررات رفتار نموده و در صورت ابطال مدرک تحصيلي ام هيچگونه ادعايي نخواهم داشت.
نام و نام خانوادگي:
تاريخ و امضاء:
دانشگاه آزاد اسلامي
پرديس علوم و تحقيقات لرستان
گروه كامپيوتر
پايان‌نامه براي دريافت درجه كارشناسي ارشد در رشته مهندسي کامپيوتر(M.Sc)
گرايش نرم‌افزار
عنوان
ارائه مدلي براي اندازه گيري ميزان چابکي در شرکت هاي نرم افزاري بر اساس اصول چابک

استاد راهنما
دکتر حسن نادري

استاد مشاور
دکتر فردين ابدالي محمدي

نگارش
الهام اداوي

زمستان 92
سپاسگذاري
براي نگارش اين پايان نامه از حضور استادان عزيز و گرامي جناب آقاي دکتر حسن نادري و جناب آقاي دکتر فردين ابدالي محمدي بهره بردم که اين يادآوري، نمايانگر سپاس بي پايان من نسبت به کمک هاي بي دريغ آنان است.
با احترام تقديم به
پدرم، اول استادم ، که همواره چتر محبتش بر سرم است
بزرگواري که الفباي زندگي را از او آموختم.
مادرم ، بلند تکيه گاهم ، که دامان پرمهرش يگانه پناهم است
مهرباني که عشق ورزيدن را از او آموختم.
فهرست مطالب
عنوانشماره صفحه
چکيده
فصل اول : کليات تحقيق
1-1- مقدمه3
1-2- بيان مساله اساسي تحقيق بطور کلي3
1-3- ضرورت تحقيق4
1-4- نوآوري4
1-5- اهداف4
1-6- فرضيه هاي تحقيق5
1-7- روش تحقيق5
فصل دوم: مروري بر ادبيات و پيشينه تحقيق
2-1- مقدمه7
2-2- تاريخچه7
2-3- بيانيه چابک9
2-4- توسعه نرم افزار چابک12
2-5- مجموعه اي از روش هاي چابک13
2-5-1 روش XP13
2-5-2 اسکرام scrum17
2-5-3 خانواده کريستال20
2-5-4 توسعه ويژگي رانده (FDD)22
2-5-5 توسعه ناب24
2-5-6 روش توسعه سيستم هاي پويا (DSDM)25
2-5-7 مدلسازي چابک27
2-6- کارهاي مرتبط29
2-6-1 چابکي نسبي29
2-6-2 ابزار سنجش thoughtworks30
2-6-3 ساير موارد31
فصل سوم: روش اجراي تحقيق
3-1- مقدمه33
3-2- نحوه گزينش معيارهاي ارزيابي33
3-3- معيارهاي ارزيابي34
3-4- مدلسازي58
3-5- جمع آوري اطلاعات59
فصل چهارم: تجزيه وتحليل داده ها
4-1- مقدمه61
4-2- تحليل داده ها61
4-2-1 جامعه آماري61
4-2-2 تحليل اوليه62
4-2-3 محاسبه اوزان ـ مدلسازي63
4-2-4 نحوه استفاده از مدل اندازه گيري63
4-2-5 پياده سازي نرم افزار66
فصل پنجم: نتيجه گيري و پيشنهادات
5-1- نتيجه گيري68
5-2- پيشنهادات68
منابع و مآخذ69
فهرست منابع انگليسي70
ضمائم و پيوست ها73
پيوست 1- پرسشنامه74
پيوست2- داده هاي خام78
چکيده انگليسي81
فهرست جداول
عنوانشماره صفحه
جدول 3-1-36
جدول 4-1-162
جدول 4-1-263
جدول 4-2-64
جدول 4-3-66
فهرست شکل ها
عنوانشماره صفحه
شکل 2-1-18
شکل 2-2-22
شکل 2-3-24
شکل 2-4-26
شکل 4-1-61
چکيده
استفاده از روشهاي چابک در توسعه نرم افزار به جاي روشهاي سنتي چندي است در حال گسترش است. اين روشها که به عنوان واکنشي به مشکلات موروثي روشهاي سنتي ارائه شده اند، تحقق اهداف و ارزشهاي نويني را وعده داده اند. بر خلاف روشهاي سنتي، اين روشها سعي دارند تا فرايند توسعه نرم افزاري چابکي را در سازمان بنا نهند که در نتيجه آن هم مشتري و هم سازمان از نتايج راضي باشند. انطباق کامل با روشهاي چابک به دليل تمرکز آنها بر افراد و نه فرايند ها، در کوتاه مدت ميسر نبوده و نيازمند زمان مناسبي مي باشد. بدين جهت، هر چه سازمان چابکي بيشتري بتواند فراهم نمايد، ارزشهاي چابکي بيشتري را ميتواند براي خود و مشتريانش فراهم نمايد. با توجه به نياز به ابزار سنجش چابکي، در اين تحقيق سعي شده است که مدل اندازه گيري چابکي فراهم گردد که بر اساس معيارهاي قابل پذيرش جهاني، بتواند ميزان چابکي را در سازمانهاي نرم افزاري محاسبه نمايد. اگر چه سنجش کمي يک ارزش کيفي شايد دقت لازم را نداشته باشد، اما مي تواند به عنوان معياري براي بهبود و ارتقا چابکي در سازمان به کار گرفته شود. در اين تحقيق، به جاي تمرکز بر روشهاي چابک، تمرينات چابک به عنوان زيربناي مدل اندازه گيري در نظر گرفته شده اند. بدين ترتيب مدل طراحي شده، مستقل از روشهاي توسعه بوده و مي تواند در همه شرکتها، حتي شرکتهايي که فقط بخشي از روشهاي چابک را به کار گرفته اند، مورد استفاده قرار گيرد.
کلمات کليدي : چابکي ، معماري سازماني چابکي ، روش هاي چابک ، مدلسازي چابک
فصل اول : کليات تحقيق
1-1 مقدمه
بيش از 60 سال است که شرکتهاي توليد کننده نرم افزار از روشهاي سنتي براي توليد محصولات نرم افزاري خود استفاده مي کنند. در اين مدت فرصت مناسبي بوده که اين روشهاي توسعه به طور مناسبي مدون شده و به نوعي استاندارد مناسبي براي توسعه نرم افزار در اختيار توسعه دهندگان قرار دهند. از اوائل قرن جديد و همزمان با توسعه روز افزون اينترنت و وب و همچنين فراگير شدن استفاده از بسته هاي نرم افزاري مشکلات سنتي روشهاي توسعه نرم افزار بيش از پيش خود را نشان دادند. تاخير در تحويل بسته هاي نرم افزاري، امکان عدم تغيير در نيازمندي هاي مشتريان و در نهايت نارضايتي مشتريان موارد است که توسعه نرم افزار با روشهاي سنتي را نج ميدهد. ظهور روشهاي نوين توسعه که مستلزم ساز و کاري جديد در محيط توسعه نيز مي باشد به عنوان راه حلي براي مشکلات مزبور در نظر گرفته شد. روشهاي نوين که آنها را روشهاي توسعه چابک ناميده اند، سعي دارند که با ارائه فرايندهاي توسعه جديد چابکي مناسبي به شرکتهاي توليد کننده نرم افزار بدهد.
1-2 بيان مسأله اساسي تحقيق به طور كلي
امروزه روشهاي چابک در توسعه نرم افزار (Agile methodologies) در حال جايگزيني با روشهاي سنتي توسعه نرم افزار(Traditional methodologies) هستند [1]. روشهاي چابک که به نوعي واکنشي به روشهاي سنتي هستند، ارزشهاي متفاوتي را در مقايسه با روشهاي سنتي دنبال ميکنند [2]. يکي از مسائلي که شرکتها و سازمانهاي نرم افزاري در مسير تغيير روش خود از سنتي به چابک به کرات با آن مواجه هستند، اندازه گيري ميزان چابکي است که در هر برهه زماني حاصل نموده اند. نکته در اينجاست که اين تغيير، فرايندي ناگهاني نيست و گاها بيش از يکسال زمان نياز دارند و گاها با دشواري هاي فراواني نيز همراه است [3]. اين امر، ميزان نياز به يک ابزار سنجش را بيشتر نشان ميدهد. متاسفانه ابزار سنجشي که توافق مناسبي بر آن باشد هنوز وجود ندارد. معيار اندازه گيري مناسب، بايد به نحوي باشد که ضمن داشتن پشتوانه علمي مناسب، از سادگي نيز برخوردار بوده و به راحتي توسط شرکتها و سازمانها ( حتي سازمانهاي کوچک) قابل بهره برداري باشد. استفاده از اصول چابک به عنوان معياري که توافق کلي بر روي آن وجود دارد ميتواند در اين راستا کمک کننده باشد [4]. بر اين اساس ارزشهاي چابک که در بيانه چابک [2] و الحاقيه آن مطرح شده اند به عنوان معياري براي چابک سازي سازماني در نظر گرفته شود. اما مسلما ارزشها و اصول چابک براي آنکه بتوانند در يک محيط عملي مورد قضاوت واقع شوند چندان مناسب نيستند. چرا که هر کدام از روشهاي چابک مانند اسکرام(Scrum) [5]يا اکس پي (XP) [6]و يا روشهاي ديگر داراي فعاليت ها، نقش ها و ويژگي هاي خاص بوده که با روشهاي ديگر قابل مقايسه نخواند بود. به عنوان يک پيشنهاد بهتر استفاده از تمرينات چابک به عنوان هسته اوليه ابزار اندازه گيزي مزبور مي باشد. در واقع بر اساس تطبيق اين تمرينات در سازمان و ميزان تمريناتي که در سازمان به صورت نهادينه شده در حال استفاده مي باشند، مي توان چابکي سازمان را برآورد کرد. اين معيار زيربناي اندازه گيري مورد نظر اين تحقيق مي باشد.
1-3 ضرورت تحقيق
شرکتهاي متعددي که در حال تغيير روش هاي توسعه نرم افزار خود از روشهاي سنتي به روشهاي چابک هستند، در مقاطع زماني مختلف نيازمند بررسي ميزان پيشرفت خود در چابک سازي هستند. اين مساله هم ميتواند در راستاي بررسي پتانسيل ارزشهاي قابل حصول در سازمان کمک نمايد و هم مي تواند با ايجاد فضاي مثبت ناشي از پيشرفت فرايند چابک سازي در روحيه تيمي افراد در افزايش راندمان و منافع سازماني مفيد واقع شود. داشتن ابزاري که بتواند بر اساس يک تحقيق علمي ميزان چابکي را نشان دهد ميتواند به شدت مورد توجه شرکتهاي مزبور باشد. همچنين اين ابزار ميتواند يک مبنايي براي تعيين فرايندهاي آتي قابل انتخاب براي چابک کردن سازمان باشد. به اين ترتيب علاوه بر بحث اندازه گيري راهنماي مناسبي نيز براي فرايند تغيير رفتار سازمان نيز خواهد بود.
1-4 نوآوري
آنچه اين تحقيق را در نوع خود نوآور مي نمايد، ارائه يک مدل اندازه گيري چابکي است که وظيفه اصلي آن نشان دادن ميزان چابکي است که تا کنون سازمان به آن دست يافته است. همچنين در يک گام اضافه ميتواند تمريناتي که هنوز در سازمان نهادينه نشده اند را با ميزان تاثير آنها در چابکي سازمان نشان دهد.
چنين مدلي ميتواند به عنوان راهنمايي براي چابک تر شدن شرکتهاي نرم افزاري باشد. شايد به عنوان يک ابزار کمکي در فرايند چابک شدن شرکتهاي نرم افزاري نيز قابل به کار گيري باشد.
1-5 اهداف
در پايان اين پروژه، يک ابزار ساده اندازه گيري چابکي در قالب يک برنامه کاربردي يا وب سايت تهيه خواهد شد. در اين وب سايت سازمانها بايستي سوالاتي را که از آنها در مورد تمرينات چابک پرسيده مي شود پاسخ دهند. بر اساس اين پاسخ ها، ميزان چابکي سازمان نشان داده مي شود.
سازمانها يا شرکتهاي توليد کننده نرم افزار با کمک اين ابزار ميتوانند رشد خود در دستيابي به آرمانهاي چابکي را محک بزنند. اين ابزار هم براي شرکتهايي که خواهان استفاده از روشهاي چابک ميباشند مناسب است و هم براي آناني که در حال استفاده از برخي از جنبه هاي چابکي مي باشند.
1-6 فرضيه هاي تحقيق
موارد زير در اين تحقيق مفروض مي باشند:
* اين تحقيق به بحث تطبيق متدولوژي هاي چابک با سازمان و پروژه هاي نرم افزاري وارد نخواهد شد.
* به دليل نياز به ارائه يک مدل مورد پذيرش عمومي، تنها مدارک و مستنداتي که در چارچوب روشهاي چابک مورد توجه شرکتهاي نرم افزاري است، مورد توجه قرار ميگيريد.
* اين تحقيق مستقل از متدولوژي مي باشد. بدين ترتيب همه سازمانها و شرکتهاي نرم افزاري که در همه يا بخشي از پروژه هاي خود، يک يا چند روش توسعه نرم افزار چابک را به کار ميگيرند، قادر به بهره گيري از نتايج تحقيق خواهند بود.
1-7 روش تحقيق
انجام هر کار تحقيقاتي مستلزم بستر سازي مناسب براي انجام موضوع تحقيق است. اهميت استفاده از روش تحقيق مناسب تا حدي است که مي تواند به شدت نتايج تحقيق را متاثر سازد. از اين روي است که در همه تحقيقات پژوهشي به منطور شفاف سازي و ايجاد درک مناسب از نتايج تحقيق، پيش از شروع عمليات تحقيق، روش و گامهاي انجام پژوهش به صورت مشخص بيان مي گردد.
در اين تحقيق موارد زير انجام خواهد شد:
1- استخراج معيارهاي اندازه گيري چابکي
2- کلاسه بندي کردن اين معيارها به منظور سادگي تفسير نتايج
3- تعيين وزن هر کدام از معيارها بر اساس نظر سنجي از متخصصين
4- تدوين ساختار مدل اندازه گيري
5- پياده سازي ابزار
6- مستند سازي
فصل دوم : مروري بر ادبيات و پيشينه تحقيق
2-1 مقدمه
سرعت زندگي نسبت به گذشته بسيار بيشتر شده است. کامپيوترها هر روز سريع تر و قوي تر از قبل مي شوند و انسانها در تمام شبانه روز از طريق کابل، مودم، تلفن همراه و ابزارهاي الکترونيکي ديگر همواره متصل به شبکه هاي کامپيوتري اند. همه چيز در حال تغيير است و تغيير جزو لاينفک زندگي الکترونيکي مردم شده است. در اين ميان مهندسي نرم افزار به عنوان تامين کننده فرايندهاي لازم براي زندگي ديجيتالي ملزم به رشد سريع و عقب نماندن از قافله لجام گسيخته رشد تکنولوژي است.
مهندسي نرم افزار بايستي فرايندهايي را توليد کند که نه تنها به تغييرات پاسخ دهند بلکه از آنها استقبال هم بنمايند. اين فرايندها و متدها، روشهاي چابک ناميده مي‌شوند و امروزه جاي خود را در شرکتهاي توليد کننده نرم افزار در برخي از نقاط دنيا يافته اند و در برخي ديگر کم کم نمود خواهند يافت.
در اين بخش به بررسي اين روشها و جايگاه آنها در مهندسي نرم افزار خواهيم پرداخت. در بخش اول اين گزارش تاريخچه اي از چگونگي شکل گيري اين روشها ارائه خواهد شد، سپس در بخش بعد ضمن بررسي مفهوم چابکي متدهاي معروف را بررسي خواهيم کرد.
2-2 تاريخچه
روشهاي چابک به عنوان يک واکنش به مشکلات روشهاي سنتي توليد نرم افزار معرفي شده اند. روشهاي سنتي با مشکلاتي چون “مستند سازي سنگين، قراردادهاي کاري دقيق، برنامه ريزي کامل، طراحي نهايي و …” شناخته مي‌شوند[2]. در واقع در روشهاي سنتي، کار با يک مستند دقيق و کامل به نام “نيازمنديهاي سيستم” شروع مي‌شود، سپس طراحي معماري و طراحي سطح بالا و جزئيات به دنبال آن بايد اجرا گردند و کار با توسعه (توليد کد) و بازرسي دنبال مي گردد. از نيمه دوم دهه نود برخي از صاحبنظران نرم افزار به اين نتيجه رسيدند که شروع فرايند توليد نرم افزار با فازهاي سنگين و دقيق مطالعه نيازمندي ها و طراحي کامل، بسيار وقت گير و در مواقعي غير قابل انجام است[7]. در واقع رشد سريع صنعت و لزوم تغيير نيازمنديها مجالي براي استفاده از روشهاي سنتي نميداد. بسياري از مشتريان در ابتداي کار نمي‌توانستند نيازمندي هاي خود را به طور دقيق و کامل بيان کنند، در عين حال انتظارات آنها از محصول نهايي هم فراتر از بيان اوليه آنها بود. در نهايت برخي از متخصصين به طور مجزا به ايجاد تغييراتي در فرايندهاي توليد نرم افزار خود نمودند که به نحوي بتوانند پاسخگوي مشکل فوق باشند. در واقع با ايجاد فعاليتهاي جديد در فرايند توسعه نرم افزار اقدام به ايجاد ارزشهايي در فرايند توسعه نموده اند که تا حدي مي توانست مسائل مربوط به تغيير سريع صنعت و نياز آن را جوابگو باشد. بررسي اجمالي اين روشها نشان مي‌دهد که در خيلي از موارد اين روشها فعاليت کاملاً جديدي را نشان نمي دهند]8[، آنچه در اين روشها بيشتر به چشم ميخورد توجه به ارزشهايي است که نسبت به روشهاي سنتي پررنگ تر شده اند. بهبود فرايند نرم افزار فرايندي تکاملي است به نحوي که فرايندهاي جديدتر بر پايه توفيق ها و يا شکستهاي فرايندهاي پيشين ساخته مي‌شوند و شايد حقيقت امر اين باشد که براي شناخت روشهاي چابک لازم باشد فرايندهاي پيش از اين روشها نيز بررسي شوند.
روش (مدل) آبشاري 1 اولين فرايند توسعه نرم افزار بوده]9[که با شناخت و تحليل کامل نيازمنديهاي کاربر شروع مي‌شود. براي اين امر تحليل گران لازم است تا چندين ماه به طور کامل همه نيازمنديهاي کاربر را بررسي کرده و مستندات دقيقي در خصوص آنها تهيه و به تأئيد کاربر برسانند. سپس برنامه نويسان با بررسي کامل اين مستندات اقدام به طراحي دقيق جزئيات کاربردي نرم افزار نموده و پس از آن مرحله توليد (کدنويسي) سيستم انجام ميگيرد و در نهايت پس از تست کامل سيستم، محصول به بازار عرضه مي‌گردد [10].
اين فرايند در حالت تئوري خوب و مناسب به نظر ميرسد، اما در عمل برخلاف آنچه به نظر ميرسد، در موارد زيادي درست کار نمي‌کند. در درجه اول کاربران پس از مدتي نظراتشان عوض مي شود و گاهاً پس از ماهها و يا حتي سالها عليرغم تهيه مستندات کامل از نيازمنديهاي کاربران، آنها هنوز مطمئن نيستند که دقيقاً چه چيزي نياز دارند. در درجه دوم پس از مدتي نيازمنديهاي گفته شده، در ذهن توليدکنندگان نقش مي‌بندد و تغيير اين موارد دشوارتر از قبل خواهد شد. روشهاي سنتي وقتي نرخ تغييرات در نيازمنديها پايين باشند، هنوز هم مناسب هستند]11[، چرا که کاربران، توليدکنندگان، معماران و مديران سيستم لازم است که همه تغييرات (هرچند کوچک) را در نظر بگيرند و لحاظ نمايند. در مدل آبشاري فرض بر اين است که نيازمنديها تغيير نمي يابند و تا پايان پروژه ثابت هستند و براي اطمينان از اين امر، در مواردي تائيد رسمي کاربر را نيز دريافت مي‌کنند. اما در نهايت ممکن است، محصول کاربردي مناسبي ايجاد نگردد. تکنيکهاي توسعه نرم افزار تدريجي (تکاملي) و تکراري براي حل نقص فوق، بر پايه تقسيم چرخه توليد نرم افزار آبشاري به چندين قسمت، بنا نهاده شده اند [12]. روش توسعه تدريجي تأکيد بر کاهش زمان توسعه دارد و براي حصول به اين امر، اقدام به شکست پروژه به چندين بخش مي نمايد که اين بخشها مي توانند در زمان توسعه همپوشاني داشته باشند، اگرچه اين تکامل باز هم بر اساس مدل آبشاري انجام ميگيرد. در واقع تنها دستاورد اين روش (ها) کاهش زمان توسعه است و کماکان مسائل مربوط به نيازمنديها و مشکل تغيير در آنها وجود دارد.
در زماني که روشهاي توسعه تدريجي2، کاهش زمان توسعه را به ارمغان آورده بودند، روشهاي تکاملي ديگر نيز چون روش اسپيرال3 و روشهاي تکراري4 با هدف مديريت بهتر تغييرات نيازمندي ها و ريسک توسعه پا به عرصه گذاشتند. روشهاي تکراري، پروژه را به چند بخش مجزا (قابل تکرار) تقسيم ميکردند که هر بخش مي‌توانست در يک تکرار به طور کامل توسعه و آماده تحويل گردد. اولين چرخه تکرار، با ابتدايي ترين بخشهاي قابل تحويل شروع مي‌شد و تکرارهاي بعد، ويژگي ها و کاربردهاي بيشتري را به آنها اضافه مي کردند. هر تکه از محصول از طريق روش آبشاري با بررسي نيازمنديهاي خاص آن بخش و پس از آن طراحي، پياده سازي و تست توسعه مي يافت. در واقع در هر تکرار، تنها نيازمنديهاي مربوط به همان تکرار مورد بررسي قرار ميگيرد و نيازي به بررسي کامل نيازمنديهاي کاربر در همه زمينه ها نيست و به همين دليل تا حدي اجازه بررسي بيشتر نيازمندي ها به کاربر داده مي‌شد. همچنين در مدل اسپيرال امکان اولويت بندي نيازمنديهاي کاربر نيز وجود دارد و اين امر تا حدي از ريسک پروژه ميکاهد. توسعه چرخشي (اسپيرال) و تکراري گام بزرگي در جهت چابک سازي فرايند آبشاري ارائه دادند. بسياري از صاحبنظران معتقدند که اين تکنيک نيز جوابگوي تغيير نيازمنديهاي کاربران نيست و پاسخگويي سريع به تغيير نيازمنديها امروزه امري حياتي و الزامي است.
2-3 بيانيه چابک
در ابتداي سال 2001، هفده تن از حاميان تفکر چابک در مهندسي نرم افزار، گرد هم آمدند تا به بررسي روشهاي جديد توسعه نرم افزار بپردازند. در پايان اين نشست آنها با تدوين و امضاي بيانيه اي که بيانيه چابک ناميده مي‌شود، رسماً روشهاي چابک را معرفي نمودند]2[. افراد حاضر در اين گردهمايي نمايندگان روشهاي چابکي بودند که قبلاً به صورت مجزا در حال بهبود فرايند توسعه نرم افزار بودند. برخي از اين روشها عبارتند از [1] :
Crystal, Scrum, Extreme Programming (XP), FDD, ASD, DSDM, Agile Modeling and Pragmatic Programming
اين افراد اذعان داشتند که حرکت به سوي چابکي يک ضد متدولوژي نيست، بلکه حرکت به سوي توازن توسعه نرم افزار و دادن اعتبار بيشتر به متدولوژي است. آنها در سخنان خود اشاره کردند که از مدلسازي استقبال مي‌کنند اما مخالف توليد فايلهاي متعدد و دياگرامهاي ناکارا هستند. همچنين از مستندسازي نيز استقبال خواهند کرد، اما نه از مستند سازي که منجر به توليد چند صد صفحه بلا استفاده و ناکارا باشد. برنامه ريزي نيز به صورتي که خلاصه و کارا باشد مورد تأئيد است. آنچه در اين ميان مشهود است تأکيد بر عوامل اصلي ناکارايي متدولوژي هاي پيشين در برخورد با واقعيت هاي جاري صنعت و ذي نفعان نرم افزار است. آنچه در اين گردهمايي متخصصين به چشم ميخورد اين بود که روشهايي که هر کدام ارائه مي‌دادند شايد در ظاهر داراي تعاريف و تمرينات و فعاليت هاي مخصوص به خود بودند ولي هدف و خاستگاه همه آنها دستيابي به ارزش هايي است که در روشهاي سنتي يا نمي توان به آنها رسيد يا دستيابي به آنها مستلزم هزينه و پيچيدگي بيشتر مي باشد.
اين افراد ضمن تأکيد بر مشترکات خود مبنايي غير فني و مستقل از فعاليت هاي مربوط به متدولوژي هاي توسعه نرم افزار را براي رسميت بخشيدن به روشهاي چابک بنا نهادند و طي يک بيانه مشترک که بيانيه چابک نامگذاري شد، رسالت اين متدولوژي ها را بيان کردند.
اين بيانيه به اين شرح است:
بيانيه چابک تبديل به بخش مهمي از حرکت (انقلاب) چابک گرديده است چرا که در آن ضمن برشمردن ارزشهاي چابک تفاوت چابکي با روشهاي سنتي نيز پررنگ شده است.
ارزش اول ارائه شده از آنجا ناشي مي‌شود که مهندسين نرم افزار در روشهاي سنتي بيش از حد درگير پيگيري فرايند هستند و ساختار اين متدولوژي ها نيز چنان است که توجه چنداني به افراد و نقش آنها در فرايند توسعه نشده است[13]. در حالي که امروزه اکثر دست اندر کاران صنعت نقش افراد را در توليد، پررنگ تر از فرايند مي‌دانند [13]. در خصوص ارزش دوم تأکيد بر خود نرم افزار نهايي است. اگرچه مستندات نيز اهميت خود را دارند، اما آنچه هدف نهايي فرايند توسعه نرم افزار است، محصول کاربردي است و در عمل هم تجربه چند دهه قبل نشانگر بلا استفاده بودن کوهي از مستندات توليد شده است. در بيان ارزش سوم، تأکيد بر روي رضايت مشتري است و آن را بر پيروي از قرارداد ارجح مي‌داند. در واقع ارزش محصول مناسب براي کاربر، فراتر از محصول ايجاد شده بر اساس قرارداد و عدم عدول از آن است. اين امر شايد منتقداني نيز داشته باشد [13] اما در نهايت با تعامل مناسب با مشتري ميتوان در قرارداد کاري نيز اجازه مانور به هر دو طرف داد. ارزش چهارم که شايد يکي از کليدي ترين مفاهيم چابک باشد، بر استقبال از تغييرات در برابر پيروي از يک برنامه تأکيد دارد. در واقع برنامه ريزي کامل که در مهندسي نرم افزار بر پايه تشخيص کامل نيازمنديها صورت ميپذيرد، ناقض و مانع چابکي فرايند در پاسخگويي به تغييرات نيازمنديها مي‌باشد .
عمده انتقاداتي که طرفداران روشهاي سنتي از روشهاي چابک دارند به اصول فوق برمي‌گردد. ، عمده نگراني هاي طرفداران روشهاي سنتي پيروي آنها از مدلهاي معروفي چون CMMI است که شايد در رويارويي با تفکر چابک در مواردي نفي گردند
در ادامه بيانيه چابک اصول دوازده گانه چابک به عنوان متمم آن و به شرح زير آمده اند.
اين اصول تا حدي نشانگر چارچوب فعاليت هاي مورد نياز براي دستيابي به اصول چابک هستند. فعاليت هاي چابک عمدتاً براي دستيابي به اين اصول طراحي و به کار گرفته مي‌شوند.
1. توسعه نرم افزار چابک
2-4 توسعه نرم افزار چابک
در اين قسمت به بررسي چابکي و روشهاي چابک منتخب خواهيم پرداخت.
چابکي5 به معناي واقعي
هدف از روشهاي چابک اين است که به سازمانها اجازه دهند که چابک باشند اما واقعا معناي چابکي چيست؟ در پاسخ به اين سوال نظرات متعددي ارائه شده است.
يک نظريه، چابکي را اينگونه تعبير مي کند ” تحويل سريع، تغيير سريع و تغيير دائم” . در حالي که روشهاي چابک در فعاليت ها و تأکيد بر ارزش ها متفاوت هستند اما در مواردي چون تأکيد بر توسعه تکراري، ارتباطات، کاهش محصولات غير ضروري يکسان هستند. توسعه نرم افزار در يک فرايند تکراري به تيم توسعه دهنده امکان تطبيق سريع با تغيير نيازمنديها را مي‌دهد. کار در يک مکان بسته و تأکيد بر ارتباطات به اين معني است که تيم مي‌تواند سريع تصميم گيري نموده و بر اساس اين تصميمات اقدام نموده و منتظر دريافت پاسخ و نظر از خارج سازمان نباشد. کاهش محصولات مياني که ارزش افزوده اي براي محصول نهايي و قابل ارائه ندارند، کمک مي‌کند که منابع بيشتري در بخش توسعه محصول اصلي صرف شده و در نتيجه محصول سريع تر توليد شود. بخش عمده اي از جنبش چابک مربوط به قدرت و توان برنامه نويس است [13, 14]. اين توانمندي اجازه مانور بيشتري به افراد در فرايند توسعه نرم افزار مي‌دهد [15]. اين دقيقا همان نقطه اي است که فرايند چابک مي‌تواند سريع تر به تغيير نيازمندي ها در مقايسه با روشهاي سنتي پاسخ دهد.
در نظريه ديگري در خصوص چابک سازي اشاره شده است که فعاليت هاي ارائه شده در فرايندهاي چابک چندان نشانگر چابکي نيست، بلکه چيزي که آنها را واقعا چابک مي کند، به رسميت شناختن افراد به عنوان عامل اصلي موفقيت پروژه به همراه تأکيد شديد بر کارايي و قابليت مانور آنها است [8].
همه صاحبنظران تأکيد دارند که چابک شدن صرفا به پيروي ساده از يک سري دستورالعملها نيست. چابکي واقعي فراتر از مجموعه اي از فعاليت ها است. چابکي واقعي يک چارچوب (قالب) فکري است. در واقع شايد با اجراي مجموعه اي از فعاليت ها به نظر برسد که چابک شده ايم اما چابکي را حس نخواهيم کرد[1, 15].
2-5 مجموعه اي از روشهاي چابک
روشهاي چابک در موارد متعددي چون ارزشها مشترک هستند، اما در فعاليت هايي که هر کدام ارائه مي‌دهند، متفاوت مي‌باشند. براي آشنايي بيشتر با اين روشها و خصوصيات آنها چند روش به صورت اجمالي معرفي خواهند شد. سعي مي شود که عمق و وسعت بحث آتي در مورد هر کدام از آنها فراتر از مجال اين مطالعه نباشد. طبعا مطالعه کاملتر هر روش حوصله اي فراتر از اين گزارش را مي خواهد که هدف اصلي اين رساله نيست. نکته قابل ملاحظه در اين خصوص عدم تناسب مستندات موجود در خصوص اين روشها است. به عنوان مثال در خصوص روش XP مستندات بسيار مناسب و جامعي موجود است اما در مورد روشي چون DSDM چندان مستند قابل اتکايي وجود ندارد. بقيه روشها نيز از اين حيث در بين اين دو قرار دارند.
2-5-1 روش Extreme Programming (XP)
روشXP بي شک يکي از معروفترين و پر طرفدارترين روشهاي چابک است. اين روش که در ابتدا در سال 1998 معرفي شد [16]، در سال بعد آن با انتشار کتاب معروف Kent Beck به نام ” Extreme Programming Explained: Embracing change” بيشتر مورد توجه قرار گرفت. اين روش بيشتر مورد توجه برنامه نويساني قرار گرفت که از روشهاي سنتي توسعه نرم افزار سرخورده شده بودند[7] و به دنبال فعاليت هاي جديد و فوق العاده تري بودند. دوازده قاعده XP مانند خود روش، ساده و مختصر هستند. اين سادگي چنان است که هر کس مي تواند بدون خواندن حتي يک صفحه از کتاب فوق آن را پياده نمايد[10].
* بازي برنامه ريزي6
نيازمندي ها را داستان هاي کاربر مي نامند. هر نيازمندي بر روي يک کارت داستان درج مي‌گردد و زمان مورد نياز براي اجراي آن نيز تخمين زده مي شود. در اين روش نيازمندي ها به زباني ساده و داستان گونه که براي همه عوامل قابل فهم باشند، نوشته مي شوند. در شروع هر تکرار، در جلسه اي با حضور مشتري، مديران و توسعه دهندگان، نيازمندي هاي کاربر، براي آن تکرار بررسي شده و اولويت بندي مي‌گردند.
* نشرهاي کوچک7
يک ورژن ابتدايي از سيستم پس از چند تکرار اول، به عنوان محصول اوليه شناخته مي شود. سپس هر چند روز/هفته، نسخه جديدتري (تکامل يافته تر) ارائه مي گردد. روش XP مدل مارپيچي اسپيرال را براي نشرهاي خود به کار ميگيرد و نشرهاي کوچک آن هر 3 يا 4 هفته يکبار منتشر مي‌گردند. در انتهاي هر نشر مشتري ضمن بررسي و بازرسي محصول، ايرادات و پيشنهادات خود را مطرح مي کند.
* استعاره (تشبيه)8
مشريان، مديران و توسعه دهندگان XP تشبيه يا استعاره هايي را براي مدل سازي سيستم مي سازند. در واقع اعتقاد بر اين است که هر سيستم نرم افزاري بر اساس يک استعاره يکپارچه سازي شده است. بر اساس کتاب Beck، استعاره سيستم، داستاني است که همه مشتريان، برنامه نويسان و مديران مي توانند در مورد چگونگي کار سيستم بيان کنند. در واقع بياني عاميانه از سيستم در حال توسعه را به عنوان ملاکي براي بحث در مورد سيستم به رسميت مي شناسد.
* تست ها
توسعه دهندگان قبل از هر کاري تست هاي مربوط به آن بخش را تهيه مي کنند. در واقع تهيه تست پذيرش، مرحله اي قبل از نوشتن کد توسعه سيستم است. مشتريان نيز تست هاي کاربردي يا عملياتي را براي هر تکرار تهيه مي کنند و در پايان هر تکرار، همه تست ها اجرا مي شوند.
* طراحي ساده
از توسعه دهندگان خواسته شده که طراحي را تا حد ممکن ساده انجام دهند. ” همه چيز يکبار و فقط يکبار گفته مي شود” [5] در طراحي ساده فرض بر اين است که توسعه دهندگان نبايد نيازهاي پروژه را پيش بيني نمايند و بايد فقط ساده ترين کاري که قابل انجام است را انجام دهند.
* بازسازي9
در همان حالي که توسعه دهندگان در حال کار هستند، طراحي بايد به نحوي باشد که آن را حتي الامکان ساده نگه دارد. در اين ديدگاه بدون تغيير هر وظيفه، سعي در بهبود ساختار آن مي شود. تکرار مستمر اين امر يکي از تأکيدات XP است.
* برنامه نويسي جفتي(زوج برنامه نويسي)
دو توسعه دهنده پشت يک کامپيوتر ( يک کيبورد و يک مانيتور) نشسته و کد را به صورت جفتي مي نويسند.
* يکپارچه سازي مستمر10
برنامه نويسان بايستي کد هاي جديد را به طور مستمر به سيستم اضافه نمايند. پس از افزودن کد جديد لازم است تمام تست هاي کاربردي مجددآً روي سيستم اعمال شود و در صورت وجود نقص، کد اضافه شده را براي رفع مشکل از سيستم حذف نمايند.
* مالکيت جمعي11
مالکيت کد متعلق به همه توسعه دهندگان است و هر کس در هر زمان و هر جا که لازم باشد مي تواند تغييرات مورد نياز را روي آن اعمال کند.
* مشتري در محل
براي هر محصول لازم است يک نفر از طرف مشتري همراه تيم توسعه به طور دائم کار کند. اين فرد لازم است به سوالات احتمالي توسعه دهندگان پاسخ داده، تستهاي مورد نياز براي پذيرش محصول را انجام دهد و از روند پيشرفت توسعه چنانچه توقع دارد، اطمينان حاصل کند.
* هفته هاي 40 ساعتي
نيازمندي هاي هر تکرار بايد به نحوي انتخاب شود که توسعه دهندگان به زمان بيشتري براي اضافه کاري در هفته در طول يک تکرار نياز نداشته باشند. در XP عقيده بر آن است که اضافه کاري موجب خستگي و در نتيجه افت کيفيت محصول توليدي خواهد شد.
* فضاي کاري باز
توسعه دهندگان بايستي در يک فضاي کاري مشترک در کنار همديگر کار کنند به نحوي که ماشين هاي توسعه مشترک در مرکز اين مکان قرار گيرند. هدف از اين اصل، تسهيل روابط بين افراد در سطح سازمان است.
متخصصين معتقدند که قدرت و توانمندي XP از هيچ يک از اصول 12گانه فوق به طور منفرد حاصل نمي شود و در واقع ترکيب آنها موجب ايجاد توانمندي در اين متدولوژي مي‌باشد. همچنين پنج اصل کليدي در XP که توسط فعاليت هاي اين روش محقق مي شوند عبارتند از “ارتباطات”، “سادگي”، “بازخورد”، “جرات” و “کار با کيفيت” [7] دست اندرکاران توسعه درXP به راحتي مي توانند در مورد مفيد بودن يا نبودن مدل در توسعه نرم افزار نظر دهند.
ساير ويژگيهاي XP عبارتند از:
* اندازه تيم: از آنجا که تيم توسعه بايد بتواند در يک فضاي مشترک کار کند، اندازه تيم محدود به تعداد نفراتي است که بتوانند در يک اتاق جاي گيرند و با هم کار کنند و معمولا بين 2 الي 10 نفر در نظر گرفته مي شود.
* طول هر دوره تکرار: XP داراي کوتاهترين طول هر تکرار بين روشهاي چابک بوده و توصيه شده است که تکرار ها زير دو هفته باشند.
* پشتيباني از تيم هاي غير متمرکز: به دليل تأکيد XP بر حضور افراد در يک محل و حداکثر ارتباط آنها در اين روش، از تيم هاي غير متمرکز پشتياني نمي‌شود. اگر چه امروزه با استفاده از ابزارهاي ارتباطي تا حدي ارتباطات تيمي به صورت الکترونيکي تامين مي شود، اما در نهايت کماکام موانعي در اين خصوص (جنبه هاي انساني توسعه) وجود دارد.
* حساسيت سيستم: روش XP براي توسعه يک طيف سيستم خاص طراحي نشده است و به خودي خود محدوديتي براي کاربرد آن در سيستم هاي حساس وجود ندارد.
2-5-2 اسکرام Scrum
اسکرام به همراه XP يکي از متداولترين روشهاي چابک مي باشد. اين روش در سال 1996 با شعار “اسکرام مي پذيرد که فرايند توسعه قابل پيش بيني نيست” معرفي شد و توسط چند توسعه دهنده نرم افزار با موفقيت مورد استفاده قرار گرفت. نام اين روش از بازي راگبي گرفته شده است. در اين بازي وقتي اسکرام رخ مي‌دهد که بازيکنان يک تيم در کنار همديگر جمع مي شوند و براي پيشبرد بازي تلاش مي کنند [1, 7]. در شکل 1 شماي چرخه حيات توسعه در روش اسکرام نشان داده شده است. پروژه هاي اسکرام به تکرار هاي متعددي تقسيم مي شوند. هر تکرار در اسکرام، اسپرينت12 ناميده مي شود و شامل موارد زير است[5] :
* برنامه ريزي قبل از اسپرينت: همه کارهايي که در سيستم بايد انجام گيرند در محلي به نام بک لاگ13 نگهداري مي شوند و طي جلسه برنامه ريزي قبل از هر اسپرينت، مواردي از بک لاگ که قرار است در آن اسپرينت انجام گيرند، انتخاب مي شوند. همه موارد موجود در بک لاگ توسط نماينده مشتري که صاحب محصول14 ناميده مي شود اولويت بندي مي‌شوند و تيم توسعه بر اساس اولويت آنها اقدام به انتخاب آنها مينمايد. اين موارد منتخب، بک لاگ اسپرينت را تشکيل مي دهند.
شکل 2-1: چارچوب کاري اسکرام
* اسپرينت: به محض اتمام جلسه برنامه ريزي، بک لاگ اسپرينت تحويل تيم مي‌گردد. در اين مرحله همه وظايف موجود در بک لاگ اسپرينت تثبيت شده و در طول اسپرينت غير قابل تغيير خواهند بود. اعضاي تيم از بين وظايف موجود وظايف مورد نظر خود را انتخاب کرده و کار بر روي آنها را شروع مي کنند. جلسات کوتاه روزانه اسکرام15 در توفيق اسکرام بسيار حياتي هستند. اين جلسات هر روز صبح براي بررسي اقدامات انجام شده، مشکلات پيش رو و وضعيت پروژه بين اعضاي تيم برگزار مي گردد. اين جلسات که بايد حداکثر 15 دقيقه باشند، با هدف افزايش ارتباطات بين افراد تيم و تأکيد بر هدف مشترک و رفع موانع برگزار مي گردند.
* جلسات پس از اسپرينت (دمو): در پايان هر اسپرينت، جلسه اي با حضور همه عوامل پروژه برگزار مي گردد. در اين جلسه ضمن بررسي و تحليل پيشرفت پروژه، سيستم ساخته شده فعلي نيز نمايش داده مي شود. اين جلسه حدود 4 ساعت به طول خواهد انجاميد.
* جلسه بازنگري اسپرينت16: اين جلسه که پس از جلسات دموي اسپرينت برگزار مي گردد با هدف بررسي آنچه در طول اسپرينت قبلي رخ داده است تشکيل مي گردد.
نقش افراد در اسکرام
در يک تيم اسکرام افراد تيم در قالب يکي از نقش هاي زير سازماندهي مي شوند:
* مدير اسکرام (اسکرام مستر)17: وظيفه تسهيل اسکرام بر عهده اين فرد است. مدير اسکرام وظيفه دارد که موارد و مشکلات پيش روي تيم را رفع کرده و به افراد تيم در دستيابي به اهداف اسکرام کمک نمايد. اگر چه مدير اسکرام نقش رهبري تيم را بر عهده دارد، اما وظيفه دارد که تيم را به کار بر روي وظايف اسپرينت متمرکز نمايد.
* صاحب محصول: اين فرد نماينده ذي نفعان پروژه و به نوعي صداي مشتري است. اين فرد وظيفه دارد که اطمينان حاصل کند که تيم ارزش هايي را براي کسب و کار ايجاد مينمايد.
* تيم توسعه: تيم توسعه متشکل از افرادي است که وظيفه توسعه سيستم قابل ارائه را بر عهده دارند. اين تيم متشکل از افرادي است که وظايف مختلف را بر عهده دارند. اين وظايف شامل تحليل، طراحي، توسعه، تست، مستند سازي و ارتباطات مي باشند. اين تيم خود سازمانده بوده و تقسيم وظايف در آن با مشارکت جمعي و تعامل گروهي انجام مي گيرد.
مبدع اسکرام اصول کليدي زير را براي اسکرام تعريف نموده است [17, 18] :
1- تيم هاي کاري کوچک که ارتباطات آنها حداکثر، بالاسري آنها حداقل و به اشتراک گذاري دانش ضمني در آنها حداکثر است.
2- تطبيق پذيري به تغييرات فني و تجاري براي حصول اطمينان از اينکه بهترين محصولي که مي تواند ساخته شود، توليد گردد.
3- “ساخت18” هاي مکرر که بتوانند تست، بازرسي و مستند سازي شوند.
4- تقسيم کردن کار و وظايف تيم به بخش هايي با حداقل وابستگي
5- تست مداوم و مستند سازي محصول به محض ساخته



قیمت: تومان


پاسخ دهید