الف – پرداخت وجه بحساب وب سایت ایران ترجمه(شماره حساب)ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.comشامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر --مقالات آماده سفارش داده شده پس از تایید به ایمیل شما ارسال خواهند شد.
قیمت
قیمت این مقاله: 38000 تومان
(ایران ترجمه - Irantarjomeh)
توضیح
بخش زیادی از این مقاله بصورت رایگان ذیلا قابل مطالعه می باشد.
بررسی مدیریت ریسک در روش های مختلف توسعه نرم افزار
نام انگلیسی
A Review of Risk Management in Different Software Development Methodologies
تعداد صفحه به فارسی
۳۱
تعداد صفحه به انگلیسی
۵
کلمات کلیدی به فارسی
مهندسی نرم افزار, مدیریت ریسک, ریسک, مدل فرآیند توسعه نرم افزار, روش شناسی توسعه نرم افزار, مدل آبشاری, مدل حلزونی, مدل نموی, مدل-V, مدل چابک
کلمات کلیدی به انگلیسی
Software Engineering, Risk management, Software development process model, Software development methodology, Waterfall, Spiral, Incremental, V-model, Agile
مرجع به فارسی
دانشگاه سالت، اردن
ژورنال بین المللی کاربردها کامپیوتر
مرجع به انگلیسی
International Journal of Computer Applications, Hashemite University, Zarqa, Jordan
کشور
اردن
بررسی مدیریت ریسک در روش های مختلف توسعه نرم افزار
چکیده
روش های مختلفی در ارتباط با توسعه نرم افزار وجود دارند. انتخاب روشی که به بهترین وجه در تناسب با پروژه نرم افزاری باشد به عوامل متعددی وابسته است. یک عامل مهم میزان ریسک پذیری پروژه می باشد. عامل دیگر میزانی است که هر روش برحسب آن قابلیت پشتیبانی از مدیریت ریسک را خواهد داشت. در حقیقت، این مبحث در چنین مطالعاتی که هدف از آنها مقایسه مدلهای فرآیند توسعه نرم افزار موجود از نقطه نظرهای مختلف می باشد را می توان به عنوان یک مبحث غنی به حساب آورد. در مقابل، تلاش اندکی در زمینه مقایسه مدل های فرآیند موجود با توجه به پشتیبانی از مدیریت ریسک انجام شده است. در این مقاله، ما نسبت به بررسی حالت ریسک و مدیریت ریسک در مهم ترین مدلهای فرآیند توسعه نرم افزار اقدام می نماییم (این مدل ها عبارتند از: مدل آبشاری، مدل_v، مدل نموی، مدل حلزونی و مدل چابک). این خطی مشی در مطالعات مرتبط بر مبنای ویژگی های مختلفی مد نظر خواهد بود. از نظر فنی، چنین رویه ای به مدیران پروژه کمک می نماید که قابلیت انتخاب بهترین روشی را داشته باشند که به بهترین وجه در تناسب با پروژه های آنها باشد. از نقطه نظر دیگر، این راهکار راه را برای مطالعات آتی، که هدف از آنها ارتقای فرآیند توسعه نرم افزار می باشد، هموار می نماید.
عبارات کلی: مهندسی نرم افزار، مدیریت ریسک.
کلمات کلیدی: ریسک، مدیریت ریسک، مدل فرآیند توسعه نرم افزار، روش شناسی توسعه نرم افزار، مدل آبشاری، مدل حلزونی، مدل نموی، مدل-V ، مدل چابک.
مدیریت ریسک روش های توسعه نرم افزار
۱- مقدمه
گزارش مطرح شده اخیر به وسیله گروه استندیش (Standish) در سال ۲۰۰۹ نشان داد که تنها یک سوم از پروژه های نرم افزاری را می توان به عنوان پروژه های موفق در نظر گرفت [۱]. این امر موکد آن است که نرخ شکست پروژه های نرم افزاری هم چنان به صورت غیر قابل پذیرشی بالا است، که می توان آن را در ارتباط با پیچیدگی فزاینده پروژه های توسعه نرم افزار، همراه با عدم وجود یا وجود یک فرآیند مدیریت ریسک کاربردی ضعیف دانست.
به منظور حصول موفقیت در پروژه، ما عقیده داریم که بهترین روش جهت مدیریت ریسک در پروژه های نرم افزاری انتخاب مناسب ترین روشی می باشد که به بهترین شکل با پروژه هدف ما در تناسب بوده و بنابراین باید این موضوع را در طی فرآیند توسعه به عنوان راهکاری جهت مدیریت ریسک مد نظر قرار داد.
روش شناسی توسعه نرم افزار یا مدل فرآیند توسعه نرم افزار در خصوص چرخه عمر توسعه نرم افزار (SDLC) به عنوان رویکردی بشمار می آید که تشریح کننده ترتیب مراحلی است که می بایست آن ها را به هنگام توسعه پروژه های نرم افزاری دنبال نمود [۲،۳].
…
روش های مختلف توسعه نرم افزار به صورت فی النفسه در سطوح مختلف از مدیریت ریسک پشتیبانی می کنند. در بخش های متعاقب ما وضعیت مدیریت ریسک را در قالب روش های شایع توسعه نرم افزار مورد بررسی قرار می دهیم. روش تحقیقاتی دنبال شده یک بررسی سیستماتیک می باشد که هدف آن صرفا مقایسه روش های توسعه نرم افزار موجود نیست، بلکه این روش همچنین سعی در انجام یک مطالعه تطبیقی بین اینگونه از مدل ها با توجه به شاخص های آنها در ارتباط با مدیریت ریسک دارد. هدف اصلی این بررسی ارائه مجموعه ای از شواهدی است که مشخص کننده نیاز به مدیریت ریسک در هرگونه روش توسعه نرم افزار حتی روش های ریسک- مبنا هستند.
مدیریت ریسک روش های توسعه نرم افزار
۲- تحقیقات مرتبط
تحقیقات زیادی در ارتباط با رشته توسعه نرم افزار انجام شده است. غالب این مطالعات فراهم آورنده نوعی تحلیل تطبیقی بین این روش ها از نقطه نظرات مختلف می باشد. در حقیقت، این مبحث از تحلیل های تطبیقی کافی بر حسب مدیریت ریسک بهره مند نبوده است. در سال ۱۹۹۶، Sommerville [4] اقدام به بررسی مدل های شایع نموده و نتیجه گیری نمود که نمی توان بین مدل های موجود مدلی را برگزید که در تناسب کامل با اهداف ما باشد. Guimaraes و Vilela [2] در سال ۲۰۰۵ اقدام به مقایسه مدل های آبشاری و حلزونی با استفاده از یک رویکرد سیستماتیکی تر تحت عنوان “مقایسه مدل توسعه” (CDM) نمودند. مولفه های قابل قیاسی که در مطالعه آن ها به کار گرفته شده اند عبارتند از: اهداف، خواسته ها، تحلیل ها، رویه ها، پروژه ها، آزمایش ها و عملیات. در سال ۲۰۰۸، Shahzad و همکاران [۵] با استفاده از مدل نموی عوامل اصلی که ممکن است در طی فاز توسعه محصول رخ دهند را مورد بررسی قرار دادند. Rodrguez و همکاران یک مطالعه تطبیقی توصیفی را در سال ۲۰۰۹ بین مدل های فرآیند SDLC انجام دادند. آن ها از یک فرا مدل استفاده کرده و پیشنهاد نمودند که هر مدل را می بایست به عنوان یک نمونه تلقی کرد. در ۲۰۰۸، Nyfjord و Kajko- Mattsson [7] یک مطالعه تطبیقی بین روش های آبشاری و توسعه نموی تکراری(IID) را انجام دادند، آن ها سه پارامتر را در مقایسه خود مشخص نمودند که عبارتند از: هزینه، مدت و مقایسه. در سال ۲۰۱۰، Dash و Dash [8] مدل آبشاری و مواجه آن با ریسک بر مبنای SDLC را مورد بحث قرار دادند. در همین سال [۳] اقدام به بررسی شایع ترین فرآیند های توسعه نرم افزار برحسب انواع سیستم ها کاربردی و تناسب آنها نمود. به علاوه در سال ۲۰۱۰، Munassar و Govardhan [9] یک مطالعه تطبیقی بین روش های حاکم را انجام داده و فازهای آن ها همراه با مزیت ها و معایب هر یک از این مدل ها را مورد بررسی قرار داده و مشخص نمودند که آن ها چه تفاوتی با یکدیگر دارند.
مدیریت ریسک روش های توسعه نرم افزار
۳- آنالیز
در این بخش ما روش های پیشروی توسعه نرم افزار (همانند روش های آبشاری، مدل-v، نموی، حلزونی و چابک) را مرور می نماییم و وضعیت مدیریت ریسک در هر یک از این مدل ها را بررسی خواهیم نمود. برای هر مدل، ما منابع قابل توجه ریسک و همچنین ریسک هایی که ممکن است از اعمال فرآیند پیاده سازی صحیح جلوگیری کنند را مورد بررسی و کنکاش قرار می دهیم.
۳-۱٫ مدل آبشاری
این مدل در ابتدا و بدون ذکر نام خاصی به وسیله Royce در سال ۱۹۷۰ ارائه شد. این مدل دربردارنده چکیده ای از فعالیت های توسعه ضروری نرم افزار (همانند نیازها، آنالیز، طراحی، برنامه نویسی، آزمایش و اجرا) به یک روش ترتیبی می باشد.
فرآیند توسعه روش آبشاری جهت اجتناب از ریسک هایی پیشنهاد شد که ممکن است بواسطه عملیات برنامه نویسی و یا در تکنیکهای ثابت، از طریق درج ضروریات / نیازها و مراحل تحلیلی قبل از مرحله کامل برنامه نویسی، بوجود آیند. چنین فرآیندی این اطمینان را خواهد داد که نیازهای کاربران در ابتدا کاملا تعریف شده از این طریق قابلیت تعدیل زمان و وقت صرف شده در این پروسه، بواسطه احتمال انجام فرآیند های تکراری متعدد برنامه نویسی و تثبیت عملیات، فراهم می شود.
به منظور ممانعت از ریسک محدودیت ها یا قیدهای عملیاتی، Royce [10] این مورد را پیشنهاد نمود که فاز طراحی اولیه ای بین فاز خواسته ها و فاز آنالیز درج شود تا آن که این محدودیت ها نوعا به تحلیل گران سیستم تحمیل گردد. چنین رویه ای به درستی با استفاده از لوپ یا حلقه تکرار بین طراحی اولیه و مراحل آنالیز اعمال گردید تا آن که یک طراحی اولیه رضایت بخش حاصل شود.
منابع اصلی ریسک در مدل آبشاری
از مبحث فوق، ما می توانیم به این نتیجه دست یابیم که ریسک ها در مدل آبشاری، حتی در مدل آبشاری اطلاح شده Royce، غیر قابل اجتناب هستند. علت این امر بواسطه ذات مرتبط با چنین مدلی می باشد. منابع اصلی ریسک در مدل آبشاری به شرح ذیل هستند:
تغییر خواسته ها بصورت پیوسته
عامل اصلی ریسکی که پروژه های آبشاری را با خطر مواجه می سازد تغییر پیوسته خواسته ها یا ضروریات در طی فاز توسعه می باشد. مدل آبشاری بواسطه ساختار اکید خود قابلیت جای دادن این تغییرات را ندارد. در مدل آبشاری کلیه خواسته ها می بایست بطور آشکار و از قبل در مرحله مشخص سازی ضروریات تعیین و مشخص شده باشند تا آنکه این اطمینان حاصل شود که دیگر نیازی به اعمال تغییر در طی فرآیند توسعه نخواهیم داشت. بطور آشکار این مورد را می توان به عنوان یک موقعیت ایده آلیستی مدنظر قرار داد، چرا که برای پروژه های حقیقی امکان مشخص نمودن کلیه ضروریات از قبل وجود نخواهد داشت. بنابراین، حتی تضمین این موضوع که ضروریات مشخص شده احتمال تغییر ندارند نیز وجود ندارد. در حقیقت تغییر پیوسته ضروریات بعنوان مشکلی قابل حل تلقی نمی شود و حتی چنین مشکلی صرفا خاص مدل آبشاری نیست. این مورد را می توان در طبیعت بی ثبات مجموعه پروژه های نرم افزاری و ذات کاملا اکید مدل آبشاری جستجو کرد، موردی که سبب می شود تا پیامدهای آن عمدتا در مدل آبشاری مهم و معنی دار در نظر گرفته شود.
عدم همپوشانی بین مراحل
منبع دیگر ریسک در مدل آبشاری آن است که در چنین مدلی می بایست قبل از حرکت به سمت مراحل متعاقب به طور کامل مرحله قبلی تکمیل شده باشد. بعبارت دیگر، این فرآیند اجازه همپوشانی بین مراحل را نخواهد داد. بطور آشکار، چنین موردی سبب اتلاف وقت، هزینه و منابع دیگر میشود، چرا که این مراحل در مدل آبشاری نسبتا طولانی هستند. از اینرو، غالب اعضای تیم که مسئول مراحل خاصی می باشند اغلب وقت خود را به انتظار تکمیل مراحل دیگر می نشینند تا آنکه بتوانند مرحله کاری خود را آغاز کنند.
عدم تضمین کیفیت
عدم وجود کیفیت و تضمین آن در طی فازهای مختلف فرآیند توسعه منبع دیگر ریسک در این ارتباط می باشد. اعتبار سنجی محصول محدود به یک فاز تست تکی می باشد که در آخر فرآیند توسعه اعمال می شود. بنابراین، فاز تست در مدل آبشاری بعنوان فازی تلقی می شود که دارای بالاترین سطح ریسک است، چرا که این فاز در حقیقت جزء مرحله آخر به حساب می آید که در آن سیستم به عنوان یک آبجکت حاصل آمده تحت تست قرار می گیرد. بنابراین، کلیه مشکلات، باگ ها و ریسک ها بسیار دیر کشف شده و امر اصلاح و بازیابی این مشکلات نیازمند انجام کار گسترده ای خواهد بود که سبب به هدر رفتن وقت، هزینه و تلاش خواهد شد.
مراحل نسبتا طولانی
منبع دیگر ریسک در این مدل مراحل نسبتا طولانی آن می باشد که امر ارزیابی آن را با مشکل مواجه ساخته و علاوه بر این چنین پروسه ای را زمانبر و پرهزینه نموده و به منابع دیگری جهت تکمیل موفق هر مرحله نیاز خواهد بود. بعلاوه در مدل آبشاری، هیچگونه محصول مشخصی وجود ندارد جزء آنکه مراحل به انتها رسیده باشند و محصول تقریبا تکمیل گردیده باشد که در این مرحله نیز اعمال تغییرات ناممکن خواهد بود. حتی موضوع بدتر آن است که تصور کنید که محصول حاصله نتواند انتظارات کاربران را مرتفع سازد.
مدیریت ریسک روش های توسعه نرم افزار
۳-۲٫ توسعه نموی
توسعه نموی یا افزایشی یکی از گونه های مدل آبشاری به شمار می آید که شامل یکسری از چرخه های عمر آبشاری می باشد که در آن پروژه توسعه نرم افزار به بخش های کوچکتری متشکل از نموها تقسیم می شود.
پیشنهاد توسعه نموی با توجه به ریسک های ذاتی ناشی از پیاده سازی کل پروژه نرم افزاری در یک چرخه عمر واحد در مدل مطلق آبشاری مد نظر قرار گرفت [۱۱].
منابع اصلی ریسک در توسعه نموی
ذکر این مورد قابل توجه است که فرآیند توسعه نموی هنوز نیز از منابع مختلف ریسکهایی که ذیلا بیان شده اند در رنج می باشد:
پیاده سازی خواسته های معوق
یک ریسک اصلی مدل نموی در این ارتباط می باشد که توسعه گرهای سیستمی تمایل به تعویق انداختن خواسته ها دارند، به گونه ای که بتوانند آنها را متعاقبا در بخشهای نموی بعدی مدنظر قرار دهند. بطور آشکار، می بایست از این عامل ریسک اجتناب نمود، چرا که خواسته های معوق یا به تاخیر افتاده ممکن است به عنوان یک ضروریت اصلی قلمداد شوند و پذیرش کلی کاربر بدان ویژگی مرتبط باشد. بنابراین توصیه می شود که کلیه خواسته ها شناسایی شده را در بخشهای نموی اولیه سیستم مخاطب قرار داد و بخشهای بعدی را صرفا برای خواسته های جدید یا اعمال تغییرات در بخشهای تعریف شده قبلی مدنظر قرار داد.
انتشار باگ ها از طریق بخشهای نموی
منبع دیگر ریسک آن است که در این سیستم اجازه داده می شود تا هر نوع باگ کشف نشده در یک بخش نموی در بخشهای متعاقب انتشار یابد. امر اصلاح باگ ها در بخشهای نموی اولیه فرآیند توسعه آسانتر می باشد، و به تعویق انداختن این مورد پس از بزرگ شدن سیستم بسیار مشکل و حتی غیر محتمل خواهد بود. چنین امری احتمالا بواسطه تست ضعیف و فرآیند حفظ و نگهداری ضعیفی می باشد که در انتهای هر بخش نموی اجرا می گردد.
سهل انگاری در وقت و دیگر منابع مورد نیاز برای هر بخش نموی
ارزیابی نادرست زمان، هزینه و دیگر منابع مورد نیاز برای هر بخش نموی بر روی ویژگی های پروژه تاثیرگذار خواهد بود. ناچیزشماری وقت مورد نیاز برای هر بخش نموی سبب تاخیر انداختن پیاده سازی هر یک از بخشهای متعاقب می شود. این تاخیر در نهایت منجر می شود تا نتوانیم پروژه خود را در موعد مقتضی تحویل دهیم.
استفاده بیش از حد از وقت و هزینه
بهره گیری بیش از حد از وقت و هزینه به عنوان یک مولفه حیاتی بشمار می آید. این مورد سبب ایجاد وقفه در فرآیند توسعه خواهد شد. علیرغم این حقیقت که هر نوع وقفه ای در هر کجا از فرآیند توسعه نموی منجر به آن خواهد شد تا سیستم تحت بررسی قابلیت تکمیل به موقع را نداشته باشد، غالبا چنین سیستمی به عنوان یک سیستم ناتمام تلقی شده که در آن برخی از عملکردها هنوز اجرا نشده اند.
۳-۳٫ مدل –V
همانگونه که قبلا بحث شد، یکی از عوامل ریسک اصلی که مدل آبشاری را با خطر روبرو می سازد روشهای تایید و اعتبار سنجی ضعیف است، که خود تنها محدود به فاز تستی می باشد که صرفا در انتهای فرآیند توسعه انجام می گردد.
۳-۴٫ توسعه حلزونی
مدل حلزونی به وسیله Boehm [13] در سال ۱۹۸۸ بعنوان یک مدل فرآیند توسعه نرم افزار ریسک – مبنا پیشنهاد شد، که در آن کل فرآیند توسعه با استفاده از ریسکهای شامل شده مورد بررسی و کنترل قرار می گیرد. هدف آن شناسایی و ارزیابی ریسک های پروژه نرم افزاری و کمک به کاهش این ریسکها و کنترل هزینه پروژه به منظور حصول یک پروژه نرم افزاری با قابلیت کنترل بهتر می باشد. در حقیقت، تفاوت قابل توجهی بین مدیریت صریح ریسک در مدل حلزونی با مدلهای فرآیند دیگر، که صرفا در بخش های فرعی برخی از موارد مرتبط با مدیریت ریسک را اعمال می دارند، وجود دارد [۱۴]. در مدل حلزونی، این خصیصه سبب می شود که این تضمین به وجود آید که غالب ریسکها به صورت زودهنگام و بسیار زودتر از مشخص شدن در مدلهای فرآیند دیگر، قابلیت شناسایی خواهند بود.
فرآیند توسعه حلزونی سبب پشتیبانی از مدیریت ریسک در پروژه های نرم افزاری به طرق متعددی می شود که آن را به شرح ذیل خلاصه نموده ایم:
آنالیز اولیه ریسک که داشتن نگاهی به جلو هدف ذیل را پیگیری می کند:
شناسایی غالب ریسکهایی که پروژه را به خطر می اندازد.
دسته بندی ریسکها به ریسکهای رابط کاربر و ریسکهای توسعه
ارزیابی ریسکها جهت مشخص سازی چگونگی رویارویی با آنها در هر چرخه. بعلاوه این دسته بندی به توسعه دهندگان در زمینه اجرای تکنیکهای حل ریسک نظیر پروتوتایپ نمودن و معیارسنجی کمک خواهد نمود.
پروتوتایپ تکاملی حلزونی که هدف آن مرتفع ساختن ریسکهای مرتبط با عملکرد و مسائل مربوط به رابط کاربر می باشد. این ویژگی های حلزونی به ما در زمینه کاهش ریسک های اصلی قبل از ورود به فرآیند توسعه کمک خواهد نمود.
…
مدیریت ریسک روش های توسعه نرم افزار
منابع اصلی ریسک در مدل حلزونی
علیرغم طبیعت ریسک مبنای پروسه حلزونی، این فرآیند دارای منابع خاص ریسکهای مخصوص خود می باشد که به شرح ذیل خلاصه می گردند:
اتکای بالا به عامل انسانی
هنوز کلیه فعالیتهای مرتبط با شناسایی، تحلیل و حل ریسکها متکی به تجربه توسعه دهندگان و قابلیتهای آنها در شناسایی و مدیریت ریسک می باشد [۱۳]. در صورتیکه این قابلیتها موجود نباشند، ریسکهای اصلی ممکن است برای چندین چرخه عمر محصول مخفی مانده و هنگامی کشف شوند که سیستم به حد تکامل خود رسیده و بنابر این مشکلات متعددی بوجود خواهد آمد. در چنین زمانی، هزینه انجام مجدد فرآیندها جهت مرتفع ساختن ریسکهای مربوطه بسیار بالا خواهد بود.
فرآیند مدیریت ریسک با جزئیات آن
در فرآیند حلزونی به واسطه طبیعت ویژه آن احتمال افزایش ریسکهای مربوط به هزینه و زمانبندی وجود دارد، این مورد مخصوصا برای پروژه های کم ریسک که در آن ارزیابی ریسک در سطح مطلوب آن اعمال نمی گردد بیشتر محسوس است.
۳-۵٫ توسعه چابک
عبارت چابک در حقیقت واژه ای می باشد که در ابتدا در سال ۲۰۰۱ برای اشاره به یک سری از روشهای سبک توسعه نرم افزار، که در اواسط دهه ۱۹۹۰ ارتقاء یافته بودند به کار گرفته شد. این فرآیند شامل روشهای اسکرام (۱۹۹۵) کریستال کلییر، اکستریم پروگرامینگ (۱۹۹۶)، توسعه تطبیقی نرم افزار، توسعه ویژگی- مبنا و روش توسعه سیستمهای دینامیکی (DSDM) (1995) می باشند [۱۵]. در تعارض با روشهای سنگین وزن (همانند روش آبشاری)، روشهای سبک وزن چندان توجهی به مرحله فرآیند رسمی نداشته اند. آنها فرآیند توسعه را بدون انتظار جهت وصول ضروریات رسمی و مشخصه های طراحی طی می نمودند.
منابع اصلی ریسک در توسعه چابک
علیرغم ادعاهایی که در ارتباط با مدیریت ریسک می شود، فرآیند توسعه چابک دارای ویژگی های تفصیلی جهت مدیریت ریسک نمی باشد. بنابراین منابع متعدد ریسک بدون حل باقی می مانند. موارد ذیل منابع اصلی ریسک در فرآیند توسعه چابک به شمار می آیند:
سیستم نرم افزاری بسیار بزرگ
مدیریت ذاتی ریسک در توسعه چابک برای سیستمهای نرم افزاری پیچیده و بزرگ کافی نمی باشد، چرا که بخشهای نموی حاصله نسبتا بزرگ هستند. این مورد سبب افزایش طول زمان بین این بخشها شده و بنابراین نیازمند هزینه بیشتر جهت تعامل با تغییرات و باگها در صورت اکتشاف خواهند بود.
تیم بزرگ توسعه
این سیستم برای تیم های بزرگ مناسب نمی باشد چرا که مدیریت ارتباطات بین اعضای آنها بسیار مشکلتر خواهد بود.
اتکای بالا بر عامل انسانی
این سیستم اتکای کاملی بر تجربه تیم توسعه و قابلیت های آن جهت برقراری ارتباط توام با موفقیت با مشتری دارد. در صورتیکه این پروژه چنین شرط هایی را نداشته باشد، بنابراین شکست این پدیده غیر قابل اجتناب خواهد بود.
نماینده نامناسب مشتری
عدم وجود یک نماینده مناسب از سوی مشتری یکی دیگر از عوامل ریسک به حساب می آید. در حقیقت این عامل بر روی فرآیند توسعه و عامل مربوط به اعضای تیمی تاثیرگذار است.
محیط توسعه توزیعی
این دیدگاه برای توسعه پروژه های نرم افزاری در محیط توزیعی مناسب نمی باشد چرا که این سیستم نیازمند یک ارتباط تعاملی چهره به چهره بین تیم توسعه می باشد. در غیر اینصورت، روشهای ارتباطاتی دیگر نظیر کنفرانس ویدئویی را می بایست به صورت روزمره در نظر گرفت.
خزش گستره
از جمله عامل دیگر مهم خزش گستره می باشد، چنین موردی غالبا به واسطه برنامه ریزی حداقلی به وجود می آید و سبب می شود تا توسعه دهندگان از پروژه اصلی خود منحرف گردند. در نتیجه، پروژه بزرگ شده و از پیچیدگی بیشتری برخوردار گردیده و در نهایت این پروژه بسیار زمانبر و هزینه بر خواهد شد.
مدیریت ریسک روش های توسعه نرم افزار
۴- نتیجه گیری و تحقیقات آتی
در این مقاله ما مدلهای فرآیند پیشروی توسعه نرم افزار را مورد بررسی قرار داده و مدیریت ریسک در هرکدام از این مدلها را مطالعه نمودیم. در نتیجه، ما دریافتیم که برخی از روشهای توسعه نرم افزار به طور ذاتی شامل مدیریت ریسک می باشند. برای هر روش، بهره گیری از چنین موردی نیازمند شرایط خاصی است. این مورد موکد آن است که ریسکها در غالب روشهای توسعه نرم افزاری غیر قابل اجتناب بوده و آنکه کلیه روشهای توسعه نرم افزار، شامل روش ریسک مبنا، نیازمند آن هستند تا مدیریت ریسک در آنها ارتقاء یابد.
بعنوان یک بعد قابل توجه برای تحقیقات آتی لازم است تا اقدام به یافتن نوعی استراتژی نماییم که هدف آن ارتقای مدیریت ریسک در روشهای توسعه نرم افزاری مختلف باشد.
لطفا به جای کپی مقالات با خرید آنها به قیمتی بسیار متناسب مشخص شده ما را در ارانه هر چه بیشتر مقالات و مضامین ترجمه شده علمی و بهبود محتویات سایت ایران ترجمه یاری دهید.
