منبع پایان نامه درمورد بهره بردار، نرم افزار

نيز بايستي به صورت اتوماتيک قابل اجرا باشد. در واقع ساخت اتوماتيک سيستم (ساخت در ده دقيقه) توام با اجراي اتوماتيک موارد آزمون نيز بايستي باشد.
شرح و بسط به موقع نيازمندي ها106
در هر تکرار در چرخه توسعه نرم افزار، صاحبان محصول، مشتري و يا افراد تحليلگر تجاري تمرکز خود را بر تعريف نيازمندي ها و قرار دادن آنها در بک لاگ مي نمايند. همزمان با اينکار لازم است که معيارهاي پذيرش اين آيتمها را نيز تدوين نمايند. چنين مدلي تحت عنوان گردآوري به موقع نيازمنديها شناخته مي شود. در اين تمرين، در ابتداي هر تکرار تنها نيازمنديهايي که قرار است در تکرار پيش رو توسعه پيدا کنند، مورد بحث و تجزيه و تحليل قرار ميگيرند. بحث و بررسي نيازمنديهايي که در تکرارهاي بعدي قرار است توسعه يابند، منحصرا به همان زمان موکول مي گردند[10].
قرارداد محدوده مذاکره شده107
قرارداد هاي کاري در پروژه هاي چابک با پروژه هاي متداول در شيوه هاي سنتي متفاوت است. اگر چه انواعي متفاوتي از قرارداد ها در اين خصوص مي توان تعريف کرد، اما تمرکز قرارداد بر امکان مذاکره و شفاف سازي و يا حتي تغيير در طول پروژه است. با اين وضعيت نوشتن قراردادي با قيمت و مدت قطعي چندان معقول به نظر نمي رسد، هر چند ميتوان چنين قراردادي را امضا کرد ولي به نحوي امکان تغيير در دامنه نيازمندي ها، زمان مورد نياز اجرا و مبلغ قرارداد را در آن پيشبيني کرد. يک روش معمول در اين خصوص نوشتن قرارداد اوليه اي با مبلغ پايين و محدوده عملياتي متناسب با آن است که به مرور پيشرفت کار و تشخيص نيازهاي واقعي مي توان دامنه، مدت و مبلغ را متناسب با تغييرات مورد نياز تغيير داد[10]. به اين طريق، هم تيم توسعه دهنده و هم مشتري مي توانند انتظارات خود را در حوزه قراردادي با واقعيت تطبيق دهند. تدوين چنين قراردادهايي يکي از توصيه هاي ديدگاه چابک است که مانند مکانيزمي است که طرفين را براي دستيابي به هدف نهايي پروژه تشويق به مذاکره نموده و باعث مي شود که با ديدي روشن و به دور از الزامات تعهد آور قراردادهاي طولاني مبني بر تهيه مواردي که شايد چندان هم مورد نياز نباشند، محصول نهايي کاراتري را دنبال کنند.
انجام تست ويژگيهاي “تکميل شده” در هر تکرار108
در هر تکرار تعدادي از ويژگي هاي مورد نياز مشتري توسعه داده مي شود. پس از پايان تکرار تعدادي و يا همه ويژگي هاي تحت توسعه، که به نوعي “تکميل شده” تلقي ميگردند، لازم است تست شوند[55]. جداي از نحوه و چگونگي فرايند تست، انجام تست اين ويژگي ها توسط توسعه دهندگان و مشتري يا صاحب محصول داراي اهميت فراواني است. در اين خصوص توجه به مفهوم و توافق “تعريف انجام شده” که پيشتر نيز شرح داده شد، ضروري است.
مديريت پيکربندي109
توسعه نرم افزار چابک مبتني بر تحويل زودهنگام بخش هايي از محصول نهايي است که آماده بهره برداري توسط مشتري مي باشند. بهره برداري از بخش هاي آماده شده محصول در صورتي ريسک اندکي را در بر خواهد داشت که به نحوي در طول توسعه سيستم، نظارت و کنترل مناسبي براي تهيه آن شده باشد. چنين فعاليتي که مديريت پيکربندي ناميده مي شود، به کنترل محصول در حال توسعه، نظارت بر يکپارچه سازي بخش هاي مختلف آن و انجام تنظيمات خاص سيستم به منظور بهره برداري مشتري از سيستم بکار گرفته مي شود[52]. با توجه به اينکه محصول توليدي در روشهاي چابک در چندين مرحله ممکن است تحويل مشتري گردد، اين فعاليت در ديدگاه چابک جايگاه خاص تري نسبت به روشهاي سنتي دارد و توجه مناسب به آن منجر به توليد سيستمي با کيفيت مناسب تر خواهد گرديد.
نوشتن نيازمنديها به شکل داستانهاي غير رسمي110
نيازمنديهاي مشتري در روشهاي چابک به شکل نوشتن داستانهاي کاربر مستند مي شوند. داستانهاي کاربر چنانچه پيشتر بيان گرديد، به صورت متن هاي ساده و کوتاه که بيان کننده ويژگيهاي مورد نياز مشتري هستند، مدون مي گردند. غالبا نحوه تدوين اين نيازمنديها به صورت متون غير رسمي و غير فني مي باشد. اين ويژگي به ذي نفعان پروژه و مخصوصا مشتري امکان مي دهد که فهم بهتري از کليات سيستم داشته باشد و در مذاکرات آتي شفاف تر نيازمندي هاي خود را بيان کند. هر چند تيم توسعه در هنگام شروع به کار بر روي اين داستانها، با اخذ جزئيات فني و عملياتي، آنها را به بخش هاي کوچک تر تقسيم مي نمايد. در برخي از روشهاي چابک، وجود اين تمرين الزامي مي باشد، اما در برخي ديگر به صورت مستتر مورد توجه است. با اينحال، وجود چنين تمريني منافع متعددي بالاخص براي ايجاد فهم بهتر سيستم براي همه دست اندرکاران در پي خواهد داشت.
برنامه ريزي تحويل111
هر گونه برنامه ريزي و تخمين در دنياي چابک تنها به يک کليد معيار بستگي دارد: سرعت تيم توسعه. اين معيار چنان

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