تعیین آنچه قرار است تولید شود.

توافق بر سر زمان و چگونگی ساخت آن

ساخت یک محصول

کنترل و بازرسی صحت ساخت (با مرور مستندات، نمایش نمونه اولیه و تست بخشهای سیستم)

تکرار طراحی و ساخت:

نمونه های اولیه تهیه شده در فاز قبل تکمیل شده و با ترکیب و تست آنها، سیستم کاری که باید به مشتری تحویل داده شود، تکمیل می شود.

پیاده سازی:

در این فاز سیستم برای استفاده منتقل می‌شود. یک مستند مرور افزایشی در طی پیاده سازی به منظور بحث در خصوص وضعیت سیستم تهیه می‌شود. یا سیستم همه نیازمندیها را پوشش داده و واقعاً به عنوان پایان یافته تلقی می‌شود و یا هنوز دارای نواقصی است که در این صورت فازهای مدل کاربردی، طراحی و ساخت و پیاده سازی بایستی تا تکمیل سیستم، تکرار شوند.

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

پس از پروژه:

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

۲-۵-۷ مدل سازی چابک(AM) Agile Modeling

این روش بر اساس ارزش ها، اصول و فعالیت هایی است که به مدل سازی و مستند سازی نرم افزار تأکید دارند [۱۴]. AM ضمن تأکید بر نقش حیاتی مدلسازی در توفیق یک پروژه، چگونگی تهیه مدل کارا و چابک را بیان می‌کند [۲۰, ۲۱].
سه هدف اصلی AM عبارتند از:

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

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

نشان دادن چگونگی اعمال تکنیک های مدلسازی کارا به توسعه دهندگان مستقل از فرایند نرم افزاری که در حال استفاده از آن هستند.

روش AM اگر چه یک روش کامل توسعه نرم افزار نیست، اما در عوض با تأکید مناسبی که بر مدلسازی و مستند سازی دارد، می‌تواند همراه هر فرایند توسعه نرم افزار بکار رود. برای این امر کافی است که با یک فرایند توسعه پایه شروع نمود و آن را برای استفاده از AM سفارشی نماییم. مبدع این روش اسکات امبلر، به عنوان نمونه چگونگی استفاده از AM در دو روش XP و UP را شرح داده است [۱۹]. ارزشهای حاکم بر AM شامل ارزشهایی از XP همچون ارتباطات، سادگی، بازخورد و جسارت (جرأت) است. همچنین فروتنی و تواضع نیز به عنوان ارزش دیگری در این مدل مطرح شده است. برای موفقیت پروژه وجود ارتباطات کارا بین افراد تیم و دیگر ذی نفعان پروژه الزامی است. به علاوه باید تلاش شود که ساده ترین راه حلی که نیازمندیها را پاسخ داده و قابلیت بازخورد سریع و دائمی داشته باشد تهیه شود. همچنین لازم است جرأت و جسارت تصمیم گیری و دفاع از آن تصمیم وجود داشته باشد و در عین حال فروتنی لازم برای پذیرش اینکه احتمالاً همه چیز در خصوص سیستم در یک فرد نیست و دیگران هم ممکن است بتوانند ارزشی به پروژه اضافه کنند وجود داشته باشد.
برخی از اصول AM به صورت خلاصه عبارتند از [۲۲]:

فرض سادگی: فرض کنید که ساده ترین راه حل ممکن بهترین راه حل ها است.

محتوا بسیار مهم تر از ظاهر است: آنچه اهمیت دارد محتوا است.

از تغییرات استقبال کنید: این واقعیت که تغییرات اتفاق میافتد را بپذیرید.

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

هر کس از هر کس دیگری می‌تواند بیاموزد: بپذیرید که شما هرگز نمی‌توانید متخصص همه امور باشید و همیشه فرصتهایی برای یادگیری از دیگران برای شما وجود دارد.

تغییرات تدریجی: به جای این که سعی در ارائه یک سیستم کامل در یک مرحله نمایید، سعی کنید که در هر مرحله بخش کوچکی از سیستم را تغییر دهید.

مدلهای خود را بشناسید: برای استفاده کارا از مدلها لازم است نقاط قوت و ضعف آنها را بشناسید.

انطباق محلی: می توانید AM را مناسب محیط خود تطبیق دهید.

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

مدل هدفمند: اگر نمی‌توانید مشخص کنید که چرا چیزهایی انجام می‌دهید، چرا خود را به زحمت می‌اندازید؟

مدلهای چندگانه: شما تنوعی از محصولات مدلها در اختیار دارید. (مثل دیاگرامهای UML، مدلهای داده ای و مدلهای رابط کاربر)

ارتباطات باز و صادقانه: با چنین ارتباطاتی افراد می‌توانند تصمیمات بهتری بگیرند.

کار با کیفیت: تلاش شما باید به نحوی باشد که محصولات ماندگار (کد و مستندات) کیفیت مناسبی داشته باشند.

بازخورد های سریع: بازخوردهای سریع همیشه نسبت به واکنشهای با تأخیر اولویت دارند.

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

سبک سفر کنید: فقط مدلها و مستنداتی که لازم است را تهیه کنید.

با غرایز مردم کار کنید: غرایز شما می‌توانند در تلاشهای شما برای مدلسازی موثر باشند.

۲-۶ کارهای مرتبط
در بین شرکتهای نرم افزاری که به سوی چابک شدن گام برداشته اند، همواره بحث میزان پیشرفت آنها در چابکی مورد توجه بوده است. در واقع ارزیابی چابکی به عنوان ملاکی برای سنجش توفیق آنها در انطباق روشها و تمرینات چابکی بوده است. اگر چه ابزارهای اندکی در قالب وب سایت های سنجش و معیارهای ارزیابی ارائه شده است، اما تنها چند مورد محدود آنها مقبولیت نسبی پیدا کرده است. اگر چه این موارد نیز با انتقاداتی مواجه بوده اند و ضمن نداشتن پایه علمی مناسب، به صورت جدی مورد توجه شرکتهای کامپیوتری نبوده اند. در ادامه این بحث این موارد را بررسی اجمالی خواهیم کرد.
۲-۶-۱ چابکی نسبی (مقایسه ای)[۲۶]
برخی از شرکتها به جای اینکه بخواهند به سمت “چابکی کامل”[۲۷] حرکت کنند، تنها در تلاشند تا از رقبای خود چابک تر باشند. در واقع هدف آنها دستیابی به چابکی کامل نبوده و نگران رقبای خود در این خصوص هستند [۲۳]. ابزار CA به این شرکتها کمک میکند که میزان چابکی خود را با شرکتهای دیگر که اطلاعات خود را به قبلا به این ابزار داده اند، مقایسه کنند.ابزار CA یک ابزار مبتنی بر نظر سنجی است، به این ترتیب که شرکتهای نرم افزاری به سوالات نظرسنجی پاسخ میدهند و ابزار CA نیز بر مبنای پاسخ های آنها، گزارشی مقایسه ای از میزان چابکی آنها در بخش های مختلف ارائه میدهد و ضمنا اطلاعات دریافتی را برای اصلاح بانک اطلاعاتی خود نیز به کار میبرد. موارد مرتبط با چابکی در قالب پرسشهای ۵ جوابی چابکی را در زمینه های مختلفی چون کارهای تیمی، فرهنگ سازمانی، تمرینات فنی، کیفیت محصول نهایی، برنامه ریزی و غیره بیان می کند [۲۳, ۲۴]. در خصوص این ابزار انتقاداتی وجود دارد که باید به آنها توجه کرد.
قالب سوالات به گونه ای است که شاید میزان اعتبار ارزیابی را مورد تشکیک قرار دهد [۲۵]. مفهوم و برداشت از بسیاری از سوالات، در بین پاسخ دهندگان یکسان نیست و این امر، به عنوان یک ریسک برای کیفیت ارزیابی محسوب می گردد. همچنین، هنگام مقایسه شرکتها، نمی توان به روشنی درک کرد که آیا آنها اهداف یکسانی از چابکی داشته اند یا خیر، چرا که داشتن اهداف متفاوت موجب می شود که هر کدام یک جنبه چابکی را بیشتر مورد توجه قرار داده اند. این امر موجب می شود که مقایسه شرکتها در حالی که اهداف متفاوتی دارند، چندان منطقی نباشند[۲۵].
۲-۶-۲ ابزار سنجش Thoughtworks
شرکت Thoughtworks که یکی از شرکتهای پیشرو در زمینه خدمات مشاوره و پیاده سازی روش های چابک می باشد، اقدام به ارائه یک ابزار سنجش ساده بر روی وب سایت خود نموده است. این ابزار نیز مانند CA یک ابزار مبتنی بر نظر سنجی بوده و میزان چابکی را بر اساس ۲۰ سوال مختلف تعیین مینماید، اگر چه بر خلاف روش قبل مقایسه شرکتها مورد توجه نیست.
در خصوص این ابزار نیز موارد انتقاد متعددی وجود دارد. این ابزار نیز شامل سوالاتی است که مشکلاتی مانند سوالات مطرح شده در CA در خصوص آنها نیز صادق است. اگر چه سعی شده است، میزان چابکی بر اساس تمرینات چابک و میزان استقرار آنها مورد توجه قرار گیرد. اما تعداد ۲۰ مورد سوال برای چنین هدفی ناکافی به نظر می رسد [۲۵, ۲۶]. نکته دیگر جایگاه این شرکت در بازار مشاوره می باشد. این شرکت پس از ارائه گزارش چابکی سعی در ترغیب شرکتهای نرم افزاری برای استفاده از خدمات خود در زمینه چابک تر شدن می نماید و این امر موجب می شود که این شرکت در مظان اتهام بهره برداری تجاری از ابزار قرار گرفته و عملا اعتبار ارزیابی اعلام شده مورد تردید واقع شود. در واقع سوالات مطرح شده، عمدتا چک لیستی از خدمات این شرکت برای ارائه به شرکتهای نرم افزاری می باشد. ضمنا مبنای علمی چگونگی ارزیابی نیز به درستی معین نشده است، یا اینکه حداقل به اطلاع عموم نرسیده است.
۲-۶-۳ سایر موارد
در چند کار فرعی دیگر، میزان چابکی به صورت سطح چابکی ارائه گردیده است که در همه این موارد با الهام از مدل کیفیت فرایند CMMI، چند سطح چابکی تدوین گردیده است[۲۷, ۲۸]. در این موارد نیز به دلیل ماهیت موضوعی چابکی، سطح بندی آن، کاملاً مورد تردید بوده و مورد توجه شرکتها و فعالان چابک نیز واقع نشده است. این سطح بندی بر مبنای قرار دادن تمرینات مختلف در سطوح مختلف چابکی می باشد. این امر نه تنها با دیدگاه چابکی در تضاد است، بلکه مبنای قراردادن این تمرینات در سطوح مختلف و به نوعی اولویت بندی آنها، اثبات نشده می باشد. [۲۹, ۳۰].
فصل سوم : روش اجرای تحقیق
۳-۱ مقدمه
فصل قبل اشاره ای به روش های چابک در توسعه نرم افزار شد. با توجه به هدف اصلی این تحقیق لازم است پس از شناخت این روشها و آشنایی با فرایند های توسعه نرم افزار به کمک آنها، ساز و کار مناسبی برای سنجش میزان چابکی سازمان های نرم افزاری استفاده کننده از این روشها پیدا کرد. در این فصل، بر اساس مطالعه ادبیات موضوع معیارهای سنجش مورد مطالعه قرار میگیرد. این معیارها شالوده ابزار سنجش خواهند بود و همین ویژگی نشان دهنده جایگاه خطیر آنها در این بحث می باشد. در ادامه ضمن بیان ویژگیهای این معیارها به بررسی آنها خواهیم پرداخت.
۳-۲ نحوه گزینش معیارهای ارزیابی
سنجش میزان چابکی سازمان ها و شرکتهای نرم افزاری استفاده کننده از روش های چابک مستقیما متاثر از نحوه انتخاب معیارهای سنجش خواهد بود. به دلیل محوریت روش های چابک در سنجش چابکی معیارهای انتخاب شده باید ویژگی های زیر را داشته باشند:
الف- مستقل از روش[۲۸]
معیار انتخاب شده نبایستی منحصر به یک روش خاص باشد و یا به نوعی نشان دهنده برتری یک روش به روش های دیگر باشد. به عنوان مثال تعداد “نفرات تیم” شاید نشان دهنده چابکی باشد، اما این معیار نمی تواند ملاک مناسبی باشد چرا که هیچ روش چابکی محدودیت قطعی برای تعداد نفرات قرار نداده است، هر چند توصیه هایی در این خصوص شده است. شاید تعداد ۷-۹ نفر در اسکرام بهترین باشد[۵]، اما این تعداد در روش های کریستال کاملا متاثر از نوع پروژه و حساسیت آن می باشد[۳۱].
ب- نشان دهنده چابکی
معیارهای انتخاب شده بایستی نشان دهنده تغییر سازمانی، رفتاری یا فرایندی در روش توسعه سازمان باشد[۳۲]. به عبارت دیگر این معیارها بایستی مستقل از روش های سنتی و یا معیارهایی باشند که در روش های سنتی نیز بکار می آیند، باشند. این امر موجب می شود که سازمان فی نفسه این معیار ها را نداشته باشد و یا به ارث نبرده باشد. این ویژگی کمک می کند که هر بهبودی در به دست آوردن این معیار ها و ارتقا ارزش این معیارها مستقیما در اثر تلاش برای چابکی به دست آید. در واقع معیار انتخابی بایستی برآمده از تفکر چابکی در سازمان باشد[۳۳].
ج- سادگی
معیار انتخابی بایستی به اندازه کافی ساده و قابل فهم باشد. روشن است که معیار و میزان ارزیابی تنها در صورتی میتواند کارایی داشته باشد که قابل حس و درک باشد. این امر موجب می شود که ابزار سنجش در عمل کارآیی بالایی پیدا کنند و اقبال مناسبی برای استفاده در صنعت داشته باشد[۳۲, ۳۴].
۳-۳ معیارهای ارزیابی
با توجه ویژگی هایی که در بخش قبل به آنها اشاره شد، تمرینات چابکی[۲۹] به عنوان معیارهای ارزیابی میزان چابکی در نظر گرفته می شوند[۳۵].
تمرین چابکی: فعالیتی است که در راستایی دستیابی به اهداف چابکی در بخشی از /کل سازمان میتواند اجرا گردد.
تمرینات چابکی از حیث نوع فعالیت پوشش دهنده گام های مختلف توسعه نرم افزار (برنامه ریزی، جمع آوری نیازمندی ها، طراحی، تحلیل، پیاده سازی و تست و تحویل) می باشند و از لحاظ پوشش نقش های سازمانی نیز پوشش دهنده همه افراد درگیر در فرایند توسعه می باشند. در واقع این ویژگی ها باعث می شود که از لحاظ پوشش رفتار سازمانی و فرایندهای فنی توسعه نرم افزار واجد شرایطی که قبلا اشاره شد نیز باشند. همچنین به دلیل درگیری افراد و توجه خاص به افراد در این روشها، توسعه دهندگان نرم افزار امکان درک مناسب آنها را پیدا میکنند. شرکتهای نرم افزاری میتوانند بر اساس نیاز خود و بستر فنی و بضاعت نیروی انسانی خود از همه و یا تعدادی از این تمرینات بهره گیری نمایند. روشن است که متناسب با افزایش میزان استفاده و استقرار این تمرینات در سازمان بیشتر شود، میزان چابکی سازمان در توسعه نرم افزار نیز افزایش پیدا کرده و سازمان در این زمینه چابک تر میگردد[۳۵].
جدول ۱ نشان دهنده تمرینات چابکی می باشند. اگر چه استانداردی در این زمینه وجود ندارد، مقبولیت عمومی و پذیرش جمعی این تمرینات شایستگی آنها را برای بکارگیری در ابزار سنجش تائید می کند. در ادامه این فصل هر کدام از این تمرینات به صورت خلاصه توضیح داده می شوند. در این تحقیق ۴۰ تمرین از بین تمرینات چابکی که بیش از بقیه در تیم های چابک مورد توجه اند، مورد بررسی قرار گرفته و به عنوان معیار به کار گرفته می شود[۴, ۳۶-۳۸].
یکپارچگی مداوم[۳۰]
یگپارچگی مداوم یک تمرین توسعه نرم افزار است که طی آن افراد تیم به صورت تکرار شونده کارهایشان را یکپارچه سازی میکنند[۳۹]. به طور معمول هر فرد روزانه کار خود را یکپارچه سازی میکند. هر یکپارچه سازی به وسیله یک سازنده اتوماتیک[۳۱] جهت یافتن خطاهای موجود (تا حد امکان) تست و بررسی میشود[۲۰]. بسیاری از تیم ها معتقدند این روش مشکلات مربوط به یکپارچه سازی را به طور چشمگیری کاهش داده و این امکان را به تیمها میدهد تا با سرعت بیشتری یک نرم افزار جامع را توسعه دهند.
جدول ۳-۱- تمرینات چابکی