مقاله رایگان درباره نرم افزار، کسب و کار، چرخه عمر

مبدع اسکرام 1 الي 6 هفته بيان شده است[12] اما اين دوره معمولا 4 هفته لحاظ مي گردد[2].
* پشتيباني از تيم هاي غير متمرکز: اگرچه در اسکرام اشاره اي صريح به تيمهاي غير متمرکز نشده است، اما يک پروژه مي‌تواند شامل چندين تيم توزيع شده باشد. اگرچه به دليل برگزاري جلسات روزانه اسکرام و همچنين تعاملات تيم با يکديگر معمولا اعضاي يک تيم نمي توانند به صورت غيرمتمرکز کارکنند.
* حساسيت سيستم: اسکرام به طور صريح به حساسيت پروژه اشاره اي ندارد.
2-5-3 خانواده کريستال20
روشهاي کريستال در اوائل دهه 90 ميلادي معرفي مي شوند. مبدع اين روشها، Alistar Cockborn، معتقد بود که يکي از بزرگترين موانعي که بر سر راه توسعه محصولات وجود دارد، ارتباطات ضعيف و ناکارا است و از اين روي روشهاي خانواده کريستال را براي پوشش اين نقيصه مدل نمود. فلسفه اصلي او اين بود که ” به ميزاني که بتوان مستندات نوشتاري را با تعاملات رو در رو جايگزين کرد، به همان ميزان ميتوان وابستگي و اتکا به محصولات نوشتاري را کاهش داده و به بهبود سيستم قابل ارائه پرداخت. هر چه در دفعات بيشتري بتوان بخش هاي تست شده و آماده اجرايي را از سيستم [ به مشتري] تحويل داد به همان ميزان مي‌توانيد از وابستگي خود به تعهدات نوشتاري کاسته و امکان تحويل سيستم را افزايش دهيد”[1].
روشهاي کريستال بر افراد، تعاملات، انجمن، مهارت ها، استعدادها و ارتباطات به عنوان اولين عامل موثر بر کارايي تأکيد دارند. اگرچه فرايند اجرايي نيز در کارايي مهم است، اما در مقايسه با عوامل اشاره شده در رده بعدي قرار دارد[2]. اين گروه به نام کريستال نامگذاري شده است به اين معني که از هر وجه به آن نگاه شود، ورژن ديگري از فرايند قابل مقايسه است و همه حول يک هسته يکسان گرد هم آمده اند[2]. متدهاي اين مجموعه به نام رنگهاي مختلف نامگذاري شده اند و هر چه چابکي بيشتري در آنها قابل تصور باشد، رنگ روشن تري به آنها منتسب شده است. چابک ترين روش، کريستال شفاف21 است و پس از آن کريستال زرد22، کريستال نارنجي23، کريستال قرمز24 و … مي آيد. تعداد افرادي که قرار است در پروژه مداخله کنند عاملي است که بر اساس آن نوع کريستال انتخاب مي شود. اين تعبير نشانگر سطوح مختلف تأکيد بر ارتباطات است. در شکل 2 اين امر نشان داده شده است.
همه روشهاي کريستال با يک مجموعه اصلي از نقش ها، محصولات کاري، تکنيکها و نمادها شروع مي‌شود و همزمان با رشد تيم يا سختي روش، اين مجموعه اوليه نيز رشد مي کند. هرچه محدوديت هاي بيشتري اعمال شود، روش مورد استفاده، چابکي کمتري خواهد داشت. با اين حال به دليل استفاده از يک هسته چابک مشترک، کماکان روش کلي چابک خواهد ماند.

شکل 2-2: خانواده کريستال
ساير ويژگيها:
* اندازه تيم: خانواده کريستال با هر اندازه تيم سازگار است، اگرچه مزيت و اولويت با افراد نخبه است (تأکيد بر افراد شايسته و کارا).
* زمان (طول) هر تکرار: حداکثر طول هر تکرار 4 ماه و براي پروژه هاي حساس در نظر گرفته شده است، اگر چه چندان مورد توصيه نيستند.
* حمايت از تيم هاي غيرمتمرکز: اين خانواده از تيم هاي غير متمرکز و توزيع شده حمايت نمي‌کند.
* حساسيت سيستم: خانواده کريستال از پروژه هاي حساس مربوط به زندگي و جان افراد حمايت نمي کند.
2-5-4 توسعه ويژگي رانده Feature Driven development(FDD)
متدولوژي FDD در اواخر دهه نود و در جريان يک پروژه سيستم وام پيچيده معرفي شد. پيمانکار قبلي اين پروژه پيچيده پس از 2 سال کار و تهيه بيش از 3500 صفحه مستندات و بدون توليد هيچگونه کدي عزل گرديده بود [7]. مجريان جديد پروژه بر اساس تجارب قبلي خود و با شروع از مدل سازي اشياء، ديدگاه مبتني بر ويژگي که FDD ناميده مي‌شود را بنا نهادند. ارزشهاي اصلي و پايه در اين نگرش عبارتند از [7]:
* فرايند ساده و کاملاً تعريف شده بهتر کار مي‌کند.
* چرخه هاي عمر کوتاه، تکراري و مبتني بر ويژگي بهترينند.
* گامهاي فرايند بايستي منطقي بوده و ارزش آنها به سرعت توسط هر يک از اعضا تيم قابل درک باشد.
فرايند توسعه در FDD شامل گامهاي زير است:
1- توسعه يک مدل کلي:
چنانچه در شکل 3 نشان داده شده است، فرايند FDD با توسعه يک مدل آغاز مي‌گردد. اعضاء تيم و متخصصين براي ساخت يک نسخه گذر25 از سيستم با يکديگر همکاري مي‌کنند.
2- تهيه يک ليست از ويژگي:
اعضا تيم يک ليست از ويژگي هايي که معرف سيستم هستند تهيه مي‌کنند. اين ويژگي ها موارد کوچکي هستند که از نظر کاربر مفيد هستند. اين ويژگيها مثل داستانهاي کاربر در روش XP به زباني ساده و قابل فهم براي همه ذي نفعان تعريف مي‌شوند. هر ويژگي بايستي در عرض 10 روز قابل پياده سازي باشد [2]. ويژگي هايي که بيش از 10 روز زمان نياز دارند. بايستي به چند زير ويژگي شکسته شوند.

3- برنامه ريزي بر اساس ويژگي:
مجموعه ويژگي هاي جمع آوري شده در گام بعدي در بخشهاي کوچکتري به نام پکيج هاي طراحي اولويت بندي مي‌شوند. اين پکيج هاي طراحي به برنامه نويس ارشدي داده مي‌شود تا بين بقيه برنامه نويسان توزيع نمايد.
4- طراحي بر اساس ويژگي و ساخت بر اساس ويژگي:
پس از اينکه بسته هاي طراحي تحويل برنامه نويس ارشد گرديد، قسمت تکراري فرايند شروع مي‌شود. برنامه نويس ارشد زير مجموعه از ويژگي ها را که 1 تا 2 هفته زمان پياده سازي نياز دارند را انتخاب کرده و سپس براي طراحي جزئيات، ساخت، تست و يکپارچه سازي برنامه ريزي مي‌کند.

شکل 2-3 : مدل توسعه ويژگي رانده

ساير ويژگي هاي FDD:
* اندازه تيم: اندازه تيم بر اساس ميزان پيچيدگي ويژگي اي که در حال ساخت است متغير است. در اين روش، اولويت بکارگيري نيروها، افراد ممتاز و ترجيحاً متخصصين مدلسازي مي‌باشند.
* زمان (طول) تکرار: طول هر تکرار تا 2 هفته پيش بيني شده است.
* حساسيت پروژه: در اين روش بحثي در مورد حساسيت پروژه نشده است.

2-5-5 توسعه ناب Lean Development
توسعه ناب ابتدا در صنايع خودرو سازي مطرح گرديد و پس از مطرح شدن چابکي در صنعت نرم افزار، اين مفهوم نيز در نرم افزار شکل گرفت. اصول دوازده گانه توسعه ناب روي استراتژي هاي مديريت زير تأکيد دارند [7]:
1- رضايت مشتري بالاترين اولويت را دارد.
2- همواره بيشترين ارزش را بايد براي پول قائل شد.
3- توفيق به مشارکت مشتري فعال وابسته است.
4- هر پروژه در توسعه ناب يک تلاش تيمي است.
5- هر چيزي قابل بحث و ادعا است.
6- توجه به حوزه و نه يک مساله خاص
7- کامل کردن به جاي ساختن
8- راه حل 80 درصدي امروز بهتر از راه حل 100 درصدي فردا است.
9- مينيماليسم يک ضرورت است.
10- نيازها تکنولوژي را مشخص مي‌کنند.
11- رشد محصول، رشد ويژگي ها است و نه رشد اندازه آن.
12- هرگز توسعه ناب را به فراتر از محدوديتهايش نرانيد.

به عنوان يک اصل نانوشته (اصل 13 ناب) تأکيد بر ابزار انساني است.
از آنجايي که تفکر ناب، بيشتر فلسفه مديريتي است تا فرايند توسعه، مفاهيمي چون اندازه تيم، طول تکرار، توزيع تيم و حساسيت سيستم مستقيماً مورد توجه نبوده اند.
2-5-6 روش توسعه سيستمهاي پويا Dynamic Systems Development Method (DSDM)
روش DSDM طبق اظهارات مبدعين آن، بيشتر از آنچه که يک روش توسعه باشد، يک چارچوب کاري است. اين روش که در اوايل دهه 90 معرفي شد، به نوعي رسمي سازي فرايندهاي توسعه سريع است [7]. چنانچه در شکل 4 نشان داده شده است، چرخه عمر در DSDM داراي 6 مرحله به شرح زير است:
* قبل از پروژه:
در اين فاز پيش نيازهاي شروع پروژه و تأمين مالي و همه مواردي که لازم است فراهم شوند مورد توجه قرار ميگيرند. توفيق پروژه تا حد زيادي به اين مرحله وابسته است.
* مطالعه امکان سنجي:
در اين روش بر انجام يک مطالعه امکان سنجي کوتاه مدت (کمتر از چند هفته) تأکيد شده است [19]. در کنار همه فعاليت هاي معمول يک مطالعه امکان سنجي، لازم است مناسب بودن روش DSDM براي پروژه نيز بررسي شود.

شکل 2-4 : چرخه عمر روش DSDM

* مطالعه کسب و کار:
اين فاز، يک فرايند کاملاً مشارکتي است که افراد با دانش و داراي اختيار طي برگزاري کارگاه ها و نشست هاي گروهي اولويت هاي مورد نظر در فرايند توسعه را به اشتراک مي گذارند و در خصوص آنها به اجماع مي رسند. نتيجه اين فاز تعريف حوزه کسب و کار که در آن کاربران، بازارها و فرايندهاي تجاري که سيستم در آنها تأثير دارد، تعريف مي‌شوند]19[.
* تکرار مدل کاربردي:
اين فاز بر اساس نيازمنديهاي سطح بالايي که در فاز قبل تعريف شده بودند، شکل ميگيرد. چارچوب DSDM بر اساس ساخت چند نمونه اوليه (بر پايه ريسک) و تکامل اين نمونه ها به سيستم کامل کار مي‌کند. اين فاز و فاز طراحي و ساخت يک فرايند يکسان دارند:
1- تعيين آنچه قرار است توليد شود.
2- توافق بر سر زمان و چگونگي ساخت آن
3- ساخت يک محصول
4- کنترل و بازرسي صحت ساخت (با مرور مستندات، نمايش نمونه اوليه و تست بخشهاي سيستم)
* تکرار طراحي و ساخت:
نمونه هاي اوليه تهيه شده در فاز قبل تکميل شده و با ترکيب و تست آنها، سيستم کاري که بايد به مشتري تحويل داده شود، تکميل مي شود.
* پياده سازي:
در اين فاز سيستم براي استفاده منتقل مي‌شود. يک مستند مرور افزايشي در طي پياده سازي به منظور بحث در خصوص وضعيت سيستم تهيه مي‌شود. يا سيستم همه نيازمنديها را پوشش داده و واقعاً به عنوان پايان يافته تلقي مي‌شود و يا هنوز داراي نواقصي است که در اين صورت فازهاي مدل کاربردي، طراحي و ساخت و پياده سازي بايستي تا تکميل سيستم، تکرار شوند.
* پس از پروژه:
اين فاز شامل فعاليت هاي معمول پس از پروژه شامل پاک کردن و مرتب سازي و وارد شدن به پشتيباني و نگهداري است. در خصوص چارچوب DSDM به دليل ماهيت آن اشاره دقيقي به مباحثي چون اندازه تيم، طول (مدت) تکرار، توزيع تيم و حساسيت سيستم نشده است.
2-5-7 مدل سازي چابک(AM) Agile Modeling
اين روش بر اساس ارزش ها، اصول و فعاليت هايي است که به مدل سازي و مستند سازي نرم افزار تأکيد دارند [14]. AM ضمن تأکيد بر نقش حياتي مدلسازي در توفيق يک پروژه، چگونگي تهيه مدل کارا و چابک را بيان مي‌کند [20, 21].
سه هدف اصلي AM عبارتند از:
1- تعريف و نمايش چگونگي قرار دادن مجموعه اي از ارزشها، اصول و فعاليت ها در يک فعاليت به نحوي که منجر به مدلسازي کارا و سبک وزن شود.
2- نشان دادن چگونگي اعمال تکنيک هاي مدلسازي در فرايندهاي توسعه نرم افزار چابک.
3- نشان دادن چگونگي اعمال تکنيک هاي مدلسازي کارا به توسعه دهندگان مستقل از فرايند نرم افزاري که در حال استفاده از آن هستند.
روش AM اگر چه يک روش کامل توسعه نرم افزار نيست، اما در عوض با تأکيد مناسبي که بر مدلسازي و مستند سازي دارد، مي‌تواند همراه هر فرايند توسعه نرم افزار بکار رود. براي اين امر کافي است که با يک فرايند توسعه پايه شروع نمود و آن را براي استفاده از AM سفارشي نماييم. مبدع اين روش اسکات امبلر، به عنوان نمونه چگونگي استفاده از AM در دو روش XP و UP را شرح داده است [19]. ارزشهاي حاکم بر AM شامل ارزشهايي از XP همچون ارتباطات، سادگي، بازخورد و جسارت (جرأت) است. همچنين فروتني و تواضع نيز به عنوان ارزش ديگري در اين مدل مطرح شده است. براي موفقيت پروژه وجود ارتباطات کارا بين افراد تيم و ديگر ذي نفعان پروژه الزامي است. به علاوه بايد تلاش شود که ساده ترين راه حلي که نيازمنديها را پاسخ داده و قابليت بازخورد سريع و دائمي داشته باشد تهيه شود. همچنين لازم است جرأت و جسارت تصميم گيري و دفاع از آن تصميم وجود داشته باشد و در عين حال فروتني لازم براي پذيرش اينکه احتمالاً همه چيز در خصوص سيستم در يک فرد نيست و ديگران هم ممکن است

دیدگاهتان را بنویسید