چکیده
هدف هر مشاغل تأمین نیازهای مشتریان هدف خود است و صنعت ITاز این قاعده مستثنی نیست. بنابراین ، نسخه به روز شده آزمایش مدل Vقرار است با ترکیب نقاط ضعف نسخه اصلی مورد بحث و ترکیب آن با روشی که به آزمایش چابک معروف است. در ابتدای گزارش ، فرضیه هایی مانند نقاط قوت و ضعف آزمای ش مدل Vموجود از طریق بررسی ادبیات و مصاحبه با متخصصان مربوطه در این حوزه مورد تجزیه و تحلیل قرار گرفت. پس از آن ، مزایای احتمالی روش چابک آزمایش مورد بررسی قرار گرفت. علاوه بر این ، این گزارش راه هایی را ارائه می دهد که از طریق آنها می توان به طور طبی عی این دو مدل را برای تولید یک مدل بسیار موثرتر ترکیب کرد. به محض ارائه مدل جدید ، نقاط قوت و ضعف آن با استفاده از روش تحلیل موردی با استفاده از معیار سنجیده شد و تجزیه و تحلیل داده ها از طریق یک نظرسنجی برای ارزی ابی اعتبار مدل آینده نگر انجام شد. بی درنگ ، تحقیقات نشان داد که مدل تست پیشنهادی نتایج بهتری نسبت به نسخه رایج آزمایش مدل Vارائه می دهد. در مرحله اول ، یک سناریوی مورد واقعی تحت ارزیابی متریک مدل ها نشان داده است که مدل پیشنهادی بهتر از مدل Vاست ، زیرا می تواند جنبه های زیر را مدیریت کند. کاهش زمان آزمایش ، اشکال زدایی ، اولویت بندی الزامات ، نقشه برداری آسان از نقش ها و بهبود دید منابع پروژه. در مرحله دوم ، تجزیه و تحلیل داده های نظرسنجی مزایا ی مختلف مدل آینده را برجسته کرد. اولویت های اصلی مدل جدید از نظر پاسخ دهنده این بود: مدل جدید اولویت ها را به سرعت در حال تغییر مدیریت می کند ، زمان ورود به بازار را تسریع می کند ، بهره وری را افزایش می دهد و کیفیت را بهبود می بخشد.
.1مقدمه
با تعداد بیشماری از فرایندها و روش های توسعه نرم افزار در دسترس است که می تواند در توسعه نرم افزار مورد
استفاده قرار گیرد ، برخی از آنها سنتی هستند و توسط طرفداران فرایندهای جدیدتر و "درجه یک" و سازمان های متد مانند "قدیمی" نامیده می شوند. به عنوان روشهای چابک رویکردهای سنتی تر برای توسعه نرم افزار شامل روش های آبشار و مدل Vاست که برای چندین دهه در چرخه های توسعه نرم افزار مورد استفاده قرار گرفته اند ، اما به طور منظم مورد انتقاد قرار می گیرند. تمرکز این مقاله در درجه اول بر روی مدل Vتوسعه نرم افزار همراه با روند آزمایش رویکرد مدرن تر توسعه نرم افزار معروف به توسعه چابک خواهد بود. Vمدل توسعه نرم افزار به عنوان الگویی از مدل آبشار و در این نوع روش ها در نظر گرفته می شود. اجرای نرم افزار اجرای فرآیندها در یک رویکرد متوالی با شکل V اتفاق می افتد که شامل توالی فرآیندها است و همچنین به عنوان مدل تأیید و اعتبارسنجی در نظر گرفته می شود. مدل V به عنوان طرحی با سطح بالا از توسعه آزمون مبتنی بر آزمون (TDD) در نظر گرفته می شود و هر مرحله توسعه نرم افزار مستقیماً با یک مرحله آزمایش مربوطه مرتبط است. این بدان معنی است که هر مرحله مربوط به آزمایش به موازات مرحله توسعه برنامه ریزی شده است ، بنابراین موارد آزمون در مرحله توسعه به منظور اجرا در مرحله آزمایش مربوطه توسعه می یابد ، اما به طور معمول پس از تکمیل نرم افزار ، آزما یش انجام می شود. همانطور که در بالا ذکر شد ، از دو جنبه تأیید و اعتبار سنجی تشکیل شده است. تأیید یک فرآیند داخلی است در مقایسه با اعتبارسنجی و به طور معمول شامل بررسی انطباق نرم افزار با مشخصات فنی آن است که توسط تحلیلگر سیستم تعریف شده و هدایت می شود. از طرف د یگر اعتبار سنجی شامل انطباق نرم افزار با الزامات ، نیازها یا مشخصات مشتری است. در این حالت ، سمت چپ مدل Vجزئیات مختلف تجاری و فنی را توصیف می کند در حالی که سمت راست بیشتر نگران آزمایش است. تست نرم افزار یک کار اساسی است که به منظور اطمینان از مطابقت نرم افزار تولید شده با الزامات مشخص شده توسط کاربر انجام می شود. این نمایش کیفیت نرم افزار برای ذینفعان خود است از این رو آزمایش نرم افزار بخشی جدایی ناپذیر از توسعه نرم افزار است. تست چابک یک تکنیک نرم افزار ی است که به میزان زیادی وام می گیرد و مستقیماً قوانین Agile Manifesto را دنبال می کند که در آن توسعه نرم افزار بصورت تکراری و افزایشی انجام می شود زیرا فعالانه ذینفعان را درگیر می کند. توسعه چابک شامل انتشار تکراری و تدریجی نرم افزار است و از ای ن رو نیاز به آزمایش مکرر نرم افزار است. آزمایش چابک شامل هر عضو یک تیم متقابل است اما نیاز به تخصص یک تستر تخصصی دارد. این مطالعه سعی در بهبود آزمایش مدل Vموجود و کاهش سطح بالای عدم اطمینان و ریسکی است که توسط آزمایشگران و توسعه دهندگان در مرحله نها یی توسعه محصول مشاهده شده است. انعطاف پذیری جنبه اصلی بعدی است که در مدل آینده نگر تأمین شده است. علاوه بر این ، کاربران نهایی می توانند محصولات کاملاً عملیاتی با کیفیت بالا و حداقل هزینه را در مقایسه با مدل Vسنتی دریافت کنند. شرکتها یی که مدل اصلاح شده و بهبود یافته را در پیش بگیرند ، از منابع برای خلاص شدن از شر اشکالات بهره مند می شوند ، که توسط توسعه دهندگان و آزمایش کنندگان مورد توجه قرار نمی گیرد. علاوه بر این ، چنین رویکردی برای مشاغل مفید نیز خواهد بود ، زیرا هزینه های آنها و مسائل مربوط به تأخیر در صورت عدم حذف کامل ، حداقل به حداقل می رسد. همانطور که در بالا به وضوح ذکر شد ، اتخاذ آزمایش توسعه چابک در مدل Vیک رویکرد عاقلانه برای حل مشکل نیازهای سیستم غیرقابل پیش بینی است.
.2نقد و بررسی ادبیات
الف. سنتی Vمدل توسعه نرم افزار
مدل Vسنتی توسعه نرم افزار چرخه زندگی تست رانده توسعه ( )TDDنرم افزار روش توسعه است که شامل تعریف ، توسعه و ارزیابی موارد آزمون قبل از نوشتن کد واقعی است. این شامل برنامه ریزی واقعی در پیش بینی آنچه که محیط توسعه خواهد بود. پس از تعریف محدوده پروژه و برنامه ریزی قبل از مراحل تایید و اعتبار سنجی انجام می شود، آزمون ها در نتیجه برای توسعه فازهای آزمون. در مورد پروژه های «شرور» که مشکلات به وضوح تعریف نشده اند، دامنه پروژه مبهم است یا مشخصات ارائه شده توسط کاربر به طور مرتب تغییر می کند جایی که ذینفعان پروژه ایده ای از آنچه نیاز دارند دارند، اما مشخص نیست و معتقدند که تصویر یک بار شروع توسعه بیرون خواهد آمد و یک نمونه اولیه متعاقباً منتشر می شود. در این حالت، توسعه پرونده های آزمون توسط تحلیلگر کسب و کار دشوار می شود و طرح اعتبارسنجی نرم افزار را نمی توان نوشت.
این امر محدودیت های زیر را از مدل Vبیرون می آورد:
.1سفتی و انعطاف ناپذیری: ناتوانی در پاسخ به الزامات در حال تغییر و قادر به تنظیم توسعه.
.2تمرکز توسعه نرم افزار به یک فاز (فاز پیاده سازی.)
ب. مدل v
به مدل V نیز مدل Vee گفته می شود که یک سافت و فرایندتوسعه است. به گفته روز(2007) خاستگاه مدل v بسیاری است که در آن در توسعه محصولات برای پروژه های دفاعی دولت خود مورد استفاده قرار گرفت. به گفته
(Firesmith )2013ایجاد از تغییرات گردان در اطراف مدل توسعه rfall wateاست. فلوچارت مدل V شکل است از این رو نام آن است. جریان فرایند توسعه از سمت بالا سمت چپ Vبه سمت راست شروع می شود. (Firesmith )2013بیان می کند که تأیید و اعتبار سنجی مهم ترین بخش توسعه نرم افزار به ویژه فرایند آزمایش است. تأیید و اعتبارسنجی الزامات دو بخش بحرانی در توسعه نرم افزار و سیستم هستند. به گفته این نویسنده، تأیید نرم افزار و اعتبارسنجی اصلی ترین استراتگی ها در پشت توسعه مدل آبشار بودند که مدل Vاز آنتولید می شود. در جنبه ای دیگر، فرایند توسعه مدل
بر اساس انجمن مرحله آزمایش برای هر یک از مراحل توسعه مربوطه است. این هنگامی که در دیگر قرار داد به این معنی است که یک ارتباط مستقیم از هر مرحله توسعه بامرحله تست وجود دارد. هر مرحله پس از اتمام کامل مرحله قبل شروع می شود. تصویر بالا بازنمایی بهتری از فرایند توسعه مدل Vرا نشان می دهد، جایی که سمت چپ Vنشان دهنده فرایند تأیید است و سمت راست نشان دهنده فرایند اعتبارسنجی است که با فاز coddi ngبه هم پیوستهاند. هر مرحله توسعه دارای یک مرحله آزمایش جایگزین در طرف دیگر شکل Vاست ( .)Tutorialspoint.com, 2014بازنمایی اینمدل این است که
فازها به جای فازهای تکراری، افزایشی یا همزمان معمول در فرایندهای توسعه چابک،دنباله دار هستند. مدل Vساده
سازی فرایند توسعه را به عنوان یک کل ارائه می دهد. مدل Vنیز مانند هر مدل توسعه ای دیگر ویژگی ها، مزایا و معایب
خود را دارد. برای یک توسعه دهنده برای استفاده از مدل Vبرای توسعه نرم افزار، توسعه دهنده نیاز به الزامات ثابت
و مستند به خوبی تعریف شده، کار بر روی یک پروژه کوتاه، فن آوری به کار گرفته می شود پویا نیست و تعریف محصول
باید پایدار باشد. وضوح مورد نیاز لازم است استفاده از becaبازگشت به اصلاحیک اشتباه می تواند بسیار گران است.
انعطاف پذیری مزیت اصلی است (بوکناک ، .)1999به گفته رگولوار و همکاران ( ،)۲۰1۰مدل تأیید و اعتبارسنجی توسعه
معمولاً به عنوان مدل Vشناخته می شود و گسترشی از مدل آبشار سیاومون است که توسط بسیاری در نظر گرفته
میشود. شباهت آن با مدل آبشار پیشرفت فاز ترتیبی و توسعه خطی آن است. رگولوار و همکاران ( )۲۰1۰توافق دارند
که آغاز هر مرحله ای در فرایند پس از تکمیل موفقیت آمیز مرحله قبل است. این نویسندگان توجه داشته باشید که
فعالیت های تست در این مدل همه قبل از فرایند کدنویسی به عنوان مثال برنامه ریزی و طراحی آزمون رخ می دهد.
Regulwarو همکاران ()۲۰1۰بیان می کند که این جنبه مهمی از مدل Vتوسعه .proces sبا توجه به فعالیت های تست زود
هنگام، تیم تست در اوایل فرایند توسعه که صرفه جویی در زمان و کمک به تیم به دست آوردن درک بهتر از محصول از
فازهای توسعه اولیه خود را درگیراست. آزمایش زودهنگام نیز از این نظر سودمند است که شناسایی گسل ها در فرایند
توسعه زود هنگام است و اصلاح آن ها گران نیست. مشکل این مدل به گفته نویسندگان این است که مدل به جای خود
محصول بر فازهای توسعه پویا تمرکز می کند.
د. تست چابک
چابکی شامل تعدادی از تغییرات است. این شامل پاسخ موثر، تطبیقی و سریع به تغییر، آن را شامل ارتباط موثر در
میان ذینفعان، آن را شامل گنجاندن مشتری بر روی mچای توسعه و آن را شامل سازمان تیم به شیوه ای که می تواند
کار انجام شده را کنترل(ترک، .)۲۰۰5در این صورت نویسنده راهی برای ارائه و چابک کردن نرم افزار ایجاد می کند.
این فرایند توسط توصیف مشتری با توجه به ریوهای صحنه آنها نیاز دارند رانده می شود، فرایند به رسمیت می شناسد
کوتاه از مدت طرح ها، توسعه نرم افزار است پرداخت تاکید سنگین بر فعالیت های ساخت و ساز و فرایند دارای
افزایش نرم افزار های متعدد تحویل داده شدهاست. به گفته ترک ( ،)۲۰۰5توسعه نرم افزار چابک در مورد یک رابطه
نزدیک بین توسعه دهنده و مشتریان در طول فرایند توسعه است تا به درک الزاماتمشتری است. این کمک در توسعه
یک محصول است که از نزدیک در خط با کسب و کار تجهیز و تحویل محصول نهاییبسیار سریع تر است. در رابطه با
مقاله نویسنده، توسعه دهندگانی که توسعه نرم افزار چابک را تمرین می کنند، تغییر در فازهای اولیه فرایند توسعه
پروژه را تشویق می کنند تا اینکه آنها را در فازهای توسعه نهایی در هنگام استقرار نرم افزار دیسککنند. به گفته
نویسنده، استرس بر کیفیت طراحی و همچنین آزمایش الزامات، به طور مداوم در مراحل اولیه وجود دارد که تشخیص
آن ارزان تر و آسان تر است. زیر مقایسه ای بین توسعه نرم افزار چابک و سنتی مانند مدل آبشار است.
توسعه نرم افزار چابک نیاز به حضور مشتری در تمام زمان ها دارد و از این رو به صورت حضوری اصطلاحاً گفته می
شود. به گفته پلین ( ،)۲۰11شرکت ها و توسعه دهندگانی که استفاده از توسعه نرم افزار چابک را انتخاب می کنند، در
مقایسه با دیگر روش های توسعه، موفقیت بیشتری دارند. به گفته ورویج ( ،)۲۰1۲پنج اصل در توسعه نرم افزار چابک
در بر گرفته شده است که چابکی عمومی فرایند را بهبود می بخشد. این اصول شامل؛
)1درست در زمان کدنویسی و طراحی است که در مورد کارایی و توزیع اقتصادی از زمان ، )۲فکر می کنم ، نوشتن ،
آزمون و refactorاز روند توسعه مانند حل مشکلات پیچیده است و می تواند یک نرم افزار سخت )cess ، 3واحد تست)4مقابله با شی گرا کد به جای کدهای رویه ای و )5استفاده از اصول طراحی چابک و الگوهای مانند وابستگی تزریقآگهی تک مسئولیت اصل در میان دیگران. با توجه به ( )2007Misra توسعه چابک نرم افزار نتیجه ای از فلسفه چابکفرموله شده در تلاش برای مبارزه با تمام چالش های مدل های توسعهدیگر است. تمام مدل توسعه دیگر توسط بسیاری
از پزشکان نرم افزار های مختلف تحقق یافته و همان مردم انتقاد از این elsوزارت دفاع. فلسفه چابک در تلاش برای حل
چالش ها توسط هفده پزشک نرم افزاری که با هم تیم شده بودند، تحقق پیدا کرد. این گروه مانیفست چابک را توسعه
داد
توسعه نرم افزار که ارزش ها و اصول توسعه نرم افزار چابک را فراهم می کند. دو تصویر زیر ارزش ها و اصل فلسفه را
فراهم خواهند کرد.
ج. انتقاد
مدل V در مورد صرفه جویی در زمان و اطمینان است که محصول در هر مرحله هر چند تست از مراحل توسعه اولیه
اصلاح شده است. طول می کشد thدر هر مرحله باید کامل قبل از یکی دیگر آغاز می شود. توسعه چابک در آن مفید
است که آن را شامل مشتری در هر مرحله از توسعه از مرحله اولیه تعریف نیاز است. همچنین در مورد تحویل
افزایشی از نرم افزار سوفاست. تصویب توسعه چابک به مدل Vساده انتظار برای تحویل دیر از هر محصول به پایان
رسید. این فرایند همچنین احتمال بالاییرا که توسعه دهندگان الزامات را با گنجاندن تومر cusاز طریق فرایند توسعه
درک نمیکنند، از بین می برد. پیچیدگی نرم افزار از طریق همکاری تیم توسعه و مشتریان حذف می شود. این
فرزندخواندگی بدون عوامل محدود کننده آن نمی آید. فرایند در مورد شکستن کل فرایند ential sequبه فرایندهای
دنباله ای کوچکتر بازمان کوتاه تر است. این ممکن است زمان که به طور فزاینده ای در طول روند هماهنگی در میان
تیم های چابک مصرف صرفه جویی. این ممکن است در نهایت افزایش زمان عمومی استفاده می شود. باز هم اگر شرط
اول درک نشده باشد، کل فرایند افزایشی اشتباه پیش می رود. تصویب توسعه چابک به مدل Vمزایا و معایب خود را
برای اطمینان دارد.
.3روش و راه حل های پیشنهادی
این مطالعه در چارچوب های تحقیقات طراحی زمانی انجام شده است که قرار است یک نسخه ارتقا یافته از آزمایش مدل
Vبا ترکیب آن با روش معروف به آزمایش چابک با نقاط ضعف نسخه اصلی مورد نظر مقابله کند. این تحقیق شامل موارد
زیر بود:
•
•
•
•
• برجسته vantagesآگهی ممکن است از روش چابک از تست.
تجزیه و تحلیل راه هایی که در آن دو مدل ، مدل Vسنتی و یکی از پیشنهاد می تواند به طور طبیعیترکیب برای تولید یکی از بسیار موثرتر
طراحی چارچوب جدید
ارزیابی مدل جدید در زندگی واقعی scena rio
نظرسنجی.
ارزیابی نقاط قوت و ضعف مدل جدیدبا استفاده ازMetricsو تجزیه و تحلیلجمع آوری داده هایبه منظور آزمون این فرضیه از جمله روش های مرور ادبیات، مصاحبه ها، نظرسنجی ها و تحلیل مطالعه موردی بود.
مورد استفاده در طول مطالعه. تحقیقات نشان داد که مدل آزمایش پیشنهادی نتایج بهتری نسبت به نسخه رایج آزمایش
مدل Vارائه می دهد. روش کیفی مانند مصاحبه یک به یک برای کشف موضوعات کلیدی مانند، مزایا و معایب استفاده از
مدل Vسنتی در شرکت های واقعی در میان دیگران مورد استفاده قرار گرفت. با مهندسان نرم افزار، تیم های لیدز،
کارآموزان و مدیران مصاحبه شد تا چالش هایی را که در طول استفاده از چارچوب V mode lدر عملیات روزانه خود با
آن مواجهبودند، مطالعه کنند. همچنین، تحقیقات از طریق منبع اینترنت، مجلات و مقالات دانشگاهی در مورد
'متدولوژیجدید اتخاذ تست توسعه چابک در -Vمدل ' برای بهبود جنبه های مختلف مانند ،Time، Resourceکیفیت و هزینه
یک شرکت انجام شدهاست. هنگامی که چارچوب جدید با توسعه چابک پیشنهاد شد، از یک مطالعه موردی برای ارزیابی
اعتبار آن استفاده شد. سناریوهای مورد واقعی به یادگیری رفتارهای هر دو مدل، مدل Vسنتی و مدل جدید پیشنهادی
اتخاذ تست توسعه چابک کمک کرد.
با این حال متریک ها و تجزیه و تحلیل داده های جمع آوری شده از یک نظرسنجی برای اندازه گیری مدل پیشنهادی
جدید از نظر مزایایی که چارچوب جدید فراهم خواهد کرد، مورد استفاده قرار گرفت.
.4طراحی چارچوب جدید
همانطور که به وضوح statدر بیانیه مشکل بالا ، برای حل مشکل از الزامات نامشخص و یا در حال تغییر ، روش پیشنهادی
اجرای تست توسعه چابک درمدل Vاست. متدولوژی های چابک بسیاری هستند ودر طراحی و پیاده سازی بسته به gبه
پروژه و هدف متفاوت است. در این وضعیت خاص، روش چابک انتخاب اسکرام است. نمودار زیر معماری سنتی مدل V
را نشان می دهد.
الف. مدل پیشنهادی
پیشنهاد چابک Vمدل چهار سطح تست و همچنین مستندات مناسب تر داشته باشد. این پیشنهاد جنبه های یک مدل
Vو یک مدل چابک را ترکیب می کند ( .)Monteleone 2014, n.pمدل Vیک مدل نرم افزاری است که مستلزم ساخت
دنباله شکل Vبرای تکنیک های آزمایش درگیر با یک طراحیخاص است. تست و کدنویسیدرگیر در مدل Vبه فرایند
توسعه نرم افزار کمک می کند( .)Venantius Laulin 2014, n.pمدل پیشنهادی Agile Vویژگی های مدل چابک و مدل V
را در خود جای داده است. در زیر مدل پیشنهادی قرار گرفته است. در مدل پیشنهادی، آزمایش توسعه چابک در
مدل ،Vکاشت توالی فازها کمی متفاوت می شود که به گفته آن چهار فاز آزمایش اجرا شده است.
ب. نقشه برداری از فرایندها به ویژگی ها
ویژگی های مدل Vهمان طور که در بخش چپ نمودار دیده می شود باقی می ماند. پیشرفت توصعه برای آمدن با راه
حل قابل تحویل با کیفیت بالا وجود دارد. دنباله اول نیاز کسب و کار است. پس از آن می توان راه حلی ایجاد کرد با توجه
به اینکه از مدل می توان نرم افزار را توسعه داد. از نیاز کسب و کار، دیدن دید محصول ، ویژگی های محصول و وظایف
عملکردی نگاه می کند( .)Beal 2014، n.pمدل چابک با شکستن این ویژگی ها و وظایف از طریق چند مرحله وارد می
شود. این انتقادی در تمام زمینه های ویژگی های درگیر در مدل Vبا محاسبه نگاه می کند, ورودی, انتقال دهنده و چاپ
تمام اطلاعات برای کمک به برآورد صحیح نتیجه ویژگی ها و اینکه آیا آن را ارائه راه حل ترجیح دادهشده. این مراحل
شامل اعتبار بخشیدن به تحقق سود؛ اعتبار تایید محصول، تایید پذیرش ویژگی ها و همچنین تایید توانایی یک
کارعملکردی. سمت راست یک مدل Vنشان دهنده پیشرفت و توسعه سطوح تست گنجانیده شده است که در وسط
بودند. به عنوان مثال، در این مورد اولین دنباله در سمت چپ شناسایی نیازهای کسب و کار شرکت بود. در سمت
راست، یک ارزیابی موردی ممکن است با استفاده از شاخص های اقتصادی انجام شود تا اطمینان حاصل شود که مزایای
شرکت تحقق خواهد داشت. این شاخص های اقتصادی شامل محاسبه بازده سرمایه گذاری ،دوره بازپرداخت، ارزش
خالص حاضر ونسبت سود-هزینه است. برای دید محصول، مالک محصول را برای کیفیت آن آزمایش می کند. ویژگی
های محصول از طریق تجزیه و تحلیل رگرسیون برای اطمینان از قابلیت، عملکرد و قابلیت استفاده آزمایش می شوند.
وظایف عملکردی تحت تجزیه و تحلیل توسعه آزمون محور به باز فاکتوری و کد (.)Ambler 2007، n.p
.5نتایج و بحث ها
این بخش ارائه سناریو موردی از یک پروژه نرم افزار و همچنین ارائه مقایسه ای از روش های توسعه مناسب تجزیه و
تحلیل نرم افزار است . سناریو موردی از توسعه سیستم مراقبت های بهداشتی انجام شد برای برجسته کردن جنبه های
متمایز از دو رویکرد نرم افزار تست و مزایایی که مدل پیشنهادی ، رویکرد توسعه نرم افزار ، Scrumبیش از مدل Vدر
نرم افزار در حال آزمایشاست. اسکرام یک رویکرد توسعه نرم افزار است که بر اساس اصول و مفاهیم توسعه نرم افزار
چابک تأسیس شده است، هم از توسعه افزایشی و هم از توسعه ایی پشتیبانی می کند. از سوی دیگر، مدل Vرویکرد
سنتی به نرم افزار توسعه است که با پیشرفت رو به بالا فازها، پس از فازهای کدنویسی، برای تشکیل یک شکل Vمشخصه
مشخص میشود. این مدل پیشنهادی روابطی را نشانمی دهد که بین هر فاز چرخه عمر توسعه ( )DLCو فاز آزمایش متفقین
وجوددارد.
الف. سناریوی نمونه
بیمارستان XYZشده است در حال توسعه یک سیستم اختصاصی مدیریت بهداشت و درمان داخلی. این سیستم بزرگ،
سفارشی و بسیار پیچیده با چهار ماژول هسته و شش ماژول پشتیبانی است. ماژول های اصلی شامل مدیریت بیمار و
مراقبت، سابقه پزشکی الکترونیکی و ماژول های دپارتمانی است. ماژول های پشتیبانی شامل سیستم های صورتحساب،
داشبورد، خانه داری، مدیریت منابع انسانی، حساب ها و مالی، و مدیریتموجودی است. این سازمان یک ارائه دهنده
خدمات درمانی تجاری بزرگ است که در یک صنعت بهداشت و درمان بسیار رقابتی فعالیت می کند. در آینده نزدیک دو
شاخه دیگر که در دو ایالت مختلف آمریکا قرار خواهند گرفت، آلر ایدی در خطوطلوله هستند. این جنبه چند اجتماعی
از سازمان چالش قابل توجهی برای پیاده سازی و آزمایش سیستم بهداشت و درمان به شمار می رود. در حال یک پروژه
پیشگامبرای شرکت، مسائلی مانند دامنه تعریف شده نامشخص و مبهم نیاز به mentsمشخص پروژه است. تازگی،
شایستگی و تجربه گسترده در طراحی و توسعه سیستم کامپیوتری و همچنین در ارائه و مدیریت مراقبت های بهداشتی
از عواملی هستند که دلالت قابل توجهی بر موفقیت پروژه دارند. مدیریت بیمارستان XYZانتظار داشت که این پروژه در
یک سال به پایان برسد. مدل Vرا می توان به عنوان روش اولیه برای طراحی، توسعه، پیاده سازی و تست بیمارستان
XYZسیستم مدیریت بهداشت و درمان استفاده می شود. متدولوژی وظایف یا فعالیت های اولیه توسیه را به فعالیت
های تست مربوطه که بعدها در چرخه توسعه انجام شد متصل می کند. توسعه سیستم مدیریت بهداشت و درمان
بیمارستان XYZزیر مدل Vانجام شده است. با این حال، مدل پیشنهادی یک متدولوژی مناسب برای طراحی، توسعه،
و پیاده سازی و آزمایش سیستم مدیریت بهداشت و درمان بیمارستان XYZارائه می دهد، جایی که ابزارهای آزمایش به
مجموعه الزامات و طراحی مرتبط هستند و به ترتیب نزولی به میل برنامه ابزارهای تأیید و اعتبارسنجی منعکس میشوند.
منابع تیم برابر به کدنویسی و آزمایش درون مدل داده می شود و در نتیجه نیاز دارد که کدنویسی هم زمان با آزمایش و
مستندات مدل های مختلفی که در یک اسپرینت واحد توسعه یافته اند، انجام شود. ایده در اینجا این است که یک طرح
پیاده سازی است که مانع از مرحله تست و اسناد برای هر با حداکثر سرعت دویدن تنها از یک جزء توسعه به منظور
کاهش وقوع مغایرت در فرایند توسعه و نه در انتظار تکمیل کل سیستم به طوری که برای رسیدگی به تست و اسناد.
ب- ارزش گذاری و بحث های موردی مطالعه
شرکت Aواقع در موریس دریافت پروژه برای بیمارستان .XYZیکی از نویسندگان این فرصت توسط شرکت Aبرای انجام
تجزیه و تحلیل داده ها برای نرم افزار برای بیمارستان XYZبا اعضاهای تیم موریس nدر این هدف گزارش توسعه دادهشد.
بیش از یک به یک مصاحبه توسط یکی از نویسندگان با برخی از اعضای تیم کلیدی برای این گزارش سازماندهی شد و
در نهایت، نتایج که جمع آوری شد، برجسته مزایای مدرن (و اینده)بنابراین رویکرد توسعه نرم افزار ، ،Scrumدر برابر
مدل Vسنتی با استفاده از سناریوی زندگگی واقعی، بیمارستان .XYZ
مدل پیشنهادی، توسعه چابک در مدل ،vمزایای بالقوه ای بر مدل vسنتی دارد که در زیر ذکر شده است:
• قابلیت اطمینان – مدل جدید بسیار ساده تر و ساده تر از مدل Vسنتی در نتیجه مناسب تر برای تجزیه وتحلیل نرم افزار است.
هزینه کمتر - استفاده از روش هایی مانند نرخ بازده داخلی • ( ،)IRRارزش ( Net Present )NPRو بازده سرمایهگذاری ( )ROIساختاری را ارائه می دهد که هزینه طراحی و تولید را به حداقل می رسد چرا که الزامات سیستم
را قبل از مرحله پیاده سازی به دقت ارزیابی می کند.
• کاهش استفاده از منابع و زمان – مدل پیشنهادی ارائه تجزیه و تحلیل بسیار فشرده تر و ساده تر systemاست که اجازه می دهد تا برای زمان مناسبنگه داشتن استراتژی.
• رفع نقص کمتر – این سیستم به گونه ای طراحی شده است که از جریان نزولی نقص ها در جریان آن اجتنابکند.علاوه بر مزایا ، مدل پیشنهادی از نظر مدیریت خطرات از مدل vبهتر است
مرتبط با پروژه خاص سیستم اطلاعات مراقبت های بهداشتی که توسط اعضای تیم برجسته شده است.
ج. نتایج اعتبارسنجی از طریق متریک ها
این بخش جایی است که متریک های مشتق شده به سناریوی موردی بیمارستان XYZاعمال شدهاست. هر دو متدولوژی
تحت نظر قرار گرفته اند. برای سناریوی مورد اول، کاربرد متدولوژی مدل Vدر اقدام با توسعه محصول و در دست
دوم، فرض شده اما صرفاً حقایق موجه اعضای کلیدی در tمدل پیشنهادی او اعمال شدهاست. در زیر نتایج ارزیابی
انجام شده برای سیستم XYZبیمارستان. با انجام مقایسه مدل Vسنتی در برابر مدل پیشنهادی، جنبه های زیر به نفع
مدل آینده نگر نشان داده شده است.
• کاهش زمان تست
مدل پیشنهادی با ادغام قابلیت های متنوع متدولوژی توسعه چابک و راه حل سنتی مدل سازی Vکار می کند و با انجام
آزمایش هر ماژول در پایان یک اسپرینت توسعه واحد، زمانی را که در طول فرایند توسعه نرم افزار صرف می شود،
کاهش می دهد. این ارائه مزیت کاهش زمان تست کلی و اشکال زدایی به عنوان تست به موازات کدنویسی و فرایند
توسعه انجام شده است. علاوه بر این، استفاده از ماهیت ضروری آن از روش توسعه چابک نشان می دهد که ویژگی
های سیستم به صورت افزایشی تحویل داده می شود، در نتیجه اجازه می دهد تحقق برخی از مزایای سیستم در فازهای
اولیه توسعه سیستماست. این اعتماد به نفس سهام و نسل از الزامات را افزایش می دهد, که به طور موثر به توسعه
یک سیستم است که به موقع در خدمت عملیات مورد نیازمنجر شود. اصل کلیدی سیستم پیشنهادی این است که
آزمایش و اشکال زدایی احتمالی سیستم در طول کل چرخه عمر توسعه سیستم انجام می شود و در نتیجه امکان بازرسی
منظم از تحویل در هر با حداکثر سرعت دویدن را قادر می سازد. این امر ذینفعان را قادر خواهد ساخت تا تنظیمات لازم
(در صورت لزوم) را انجام دهند و سیگنال های اولیه هر گونه مسائل کیفیت عملیاتی را که نیاز به اصلاح دارد، به تیم
توسعه دهند. از مطالعه موردی توسعه، مدل Vسه هفته مستقیم طول کشید تا ثبات های کاری سیستم را در رابطه با
الزامات ذینفعان آزمایش کند. این است که به این واقعیت است که Vمدل تست شامل تجزیه و تحلیل کل سیستم در
رابطه با نیازهای کاربر دیر, در نتیجه گرفتن یک زمان نسبتا طولانی تر برای تعیین قابل استفاده از الزامات کاربربرآورده.
مدل یکپارچه پیشنهادی شش روز جداگانه طول کشید تا هر تک تک سرعت دویدن توسعه را آزمایش کند. این به این
دلیل است که نرم افزار توسعه یافته از شش اسپرینت مختلف تشکیل شده بود که هر کدام با ارزیابی مجدد الزامات
ذینفعان بودند. برای هر با حداکثر سرعت دویدنقابل تحویل، آزمایش چابک انجام شد وجود yبه طور موثر کاهش بخش
عمده ای از سیستم توسعه زمان تست. هر جلسه تست یک روز به طول انجامید از جلسات تست قبلی هر گونه عملیاتی ناهماهنگی
های مورد نیاز ndدر تحویل قبلی حذف شده بود، به طور قابل توجهی کاهش مقدار زمان مورد نیاز برایآزمایش.
• اشکال زدایی
مدل پیشنهادی برای انجام اشکال زدایی اجرا شونده در پایان هر تک تک با حداکثر سرعت دویدن توسعه طراحی شده
است. این نشان می دهد که تیم توسعه نرم افزار مورد نیاز برای انجام اشکال زدایی ذهنی از ماژول توسعه یافته در هر
با حداکثر سرعت دویدن، از بین بردن هر گونه اشکالات توسعه ای و عملیاتی است که ممکن است مانع عملیات جمعی
از سیستم یکپارچه است. از دیدگاه یک توسعه دهنده، این کاهش می دهد تیم کل موثر eاست که مورد نیاز برای
اشکال زدایی کل سیستم، همراه با بار است که به توسعه دهندگان و سهولت که با آن آنها می توانند قادر به پیدا کردن
اشکالات مرتبط است. بر این اساس مطالعه موردی اقدامات زمانی اشکال زدایی زیر را نشان داد:
اشکال زدایی با استفاده از مدل Vدر زمان چهار هفته برای به انجام رساندن، از آن نیاز به اشکال زدایی جمعی از کل
سیستم به طوری که اطمینان حاصل شود که تمام ماژول های سیستم به عنوان مورد نیاز کار می کرد. به طور اجباری،
مدل پیشنهادی 9روز جداگانه طول کشید تا هر یک از شش نمونه با حداکثر سرعت دویدن را اشکال زدایی کند (هر
یک از جلسات اشکال زدایی که تقریباً 1٫5روز طول میکشد). با ارائه این اشکال زدایی در مدل فازدار، ذینفعان توانستند
به تعدادی از ناهماهنگی های عملیاتی سیستم اشاره کنند که به راحتی در اسپرینت های زیر اصلاح شدند.
• اولویت بندی الزامات
با استفاده از backlogسیستم قابل تحویل و اولویت بندی مورد نیاز کاربر برای هر با حداکثر سرعت دویدن تنها، سیستم
پیشنهادی ویل lاجازه می دهد توسعه دهندگان سیستم را به انجام الزامات مخاطره آمیز تر و با ارزش در طول مراحل
اولیه چرخه توسعهاست. بر این اساس، این روش توسعه اجازه می دهد تا توسعه برخی از روش ها و قابلیت های درون
اسپرینت های اولیه در مقایسه با دیگر قابلیت های غیر اولویت بندی شده است. در این راستاسیستم پیشنهادی این
امکان را برای توسعه رابط های اشتراک ورود و ثبت در طول اسپرینت های اولیه فراهم کرد که برای ارزیابی به ذینفعان
تحویل دادهشد. این امر به طور مثبت بر نسل و توسعه الزامات کاربر به شیوه ای سریع تأثیر داشت، چرا که کاربران
می توانستند تصور کنند که سیستم چه کاری می تواند انجام دهد و قابلیت های عنصری که می خواستند به سیستم
اضافه کنند تا آن را بهتر کنند. شار از سوابق و واگذاری مسئولیت های عملیاتی در اوایل در طول توسعه به دست آمد،
و در نتیجه اجازه می دهد توسعه رابط های مرتبط مطابق با الزاماتمجموعه.
• بهبود دید منابع پروژه
مدل پیشنهادی اجازه خواهد داد برای افزایش دید با استفاده از وظایف و هیئت مدیره آزمون همراه با اسپرینت روزانه/
هفتگی. بر این اساس، مدل پیشنهادی برای افزایش دید استفاده از منابع پروژه همراه با کاربران عضو پروژه مرتبط با آنها
طراحی شده است و به طور مؤثری بودجه و محدودیت های زمانی احتمالی مرتبط با پروژه را کاهش می دهد. بر این
اساس، این تعریف نسبت زمان گرفته شده توسط فعالیت متمایز به هزینه های زمانی برآورد شده است.
• نقشه برداری آسان از نقش ها
مدل پیشنهادی یک وسیله ساده تر ارائه می دهد که از طریق آن توسعه دهندگان می توانند شیوه های چابک موجود را
به مدل Vسنتی ترکیب کنند. مزیت اولیه این ادغام، نقشه برداری مستقیم نقش ها بدون نیاز به توسعه نقش های اضافی
است. یعنی مدل پیشنهادی اجازه گنجاندن نقش های مثبت از هر روش را می دهد که منجر به کاهش ابهام رویه های
عملیاتی اعضای تیم می شود.
.6نتیجه گیری و توصیه ها
توسعه نرم افزار وجیره بندی integیک شکل چند وجهی از محاسبات است. در دسترس بودن ابزار نرم افزاری کاربردی
و کارآمد برای بررسی روندها و فعالیت ها می تواند منجر به موفقیت کسب و کار شود. مدل Vیکی از فرایندهای
توسعه نرم افزار است، با این حال، سافت دبلیو پیشنهادی فرایند توسعه کارآمدتر ازمدل Vاست. مطالعات موردی در
دست بررسی نشان داده اند که مدل پیشنهادی بهتر از مدل Vاست، از آنجا که می تواند کاهش زمان تست، اشکال
زدایی، اولویت بندی الزامات، نقشه برداری آسان نقش ،o fو بهبود دید منابع پروژه را ادارهکند. علاوه بر این، چک های
اعتبارسنجی بهتر در سیستم های پیشنهادی اجرا می شوند.
از نظر هزینه، سیستم پیشنهادی iدر مقایسه با مدل Vهزینه کمتری دارد از این رو چالش های مالیغیرضروری را از بین
می برد. مدل پیشنهادی باید در هر سیستم پیاده سازی و یکپارچه شود. توصیه های زیر ایده آل برای شرکت هایی است
که مشتاق سرمایه گذاری بر روی منابع مالی غیر عادی mدر اختیار برای طراحی نرم افزارهستند. شرکت ها باید منابعی
را به کار گیرند که تجربه ای با روش های چابک دارند، این امر به تبلیغ دانش او برای اتخاذ توسعه چابک کمک خواهد
کرد. همچنین باید ذهن خود را تغییر دهید مجموعه ای برای پذیرش این عصر جدید از توسعه نرم افزار، از این رو فشار
خارجی یا داخلی کمتر به دنبال فازها و شیوه های مدل Vسنتی وجود خواهد داشت. این واقعیت را فراموش نکنید که
یک پشتیبانی مدیریت عنصر کلیدی برای موفقیت پروژه است. اگر استخدام eesاحساس خوبی در محل کار خود رفتار
می شود، مسئله عدم تمایل تیم به پیروی از یک مفهوم جدید از توسعه چابکریشه کن خواهد شد. بهبود کار گروهی و
افزایش بهره وری مورد علاقه خواهد بود. آخرین اما نه حداقل، آموزش بسیار واردات ntاست. به عنوان اهداف اصلی در
نظر گرفته شده است که یک فرد باید به دست آوردن قبل از او می تواند مفهوم مدل چابک vتسلط. این سرمایه گذاری
است که برای شرکت بسیار سودآور خواهد بود. هیچ از دست دادن بر اساس زمان طولانی وجود دارد به عنوان
منابعخواهد شد مور eتکمیل کننده و کاملاآگاه.
مراجع
.." مجله دکتر دابAgile testing strategies" (2007) ."] "امبلر"، "اسکات1[
http://www.bridging-the-gap.com/traditional-vs-agile- :". موجود درTraditional vs. Agile: The future is Hybrid" (2014) . ] بال ، آدریانا2[
.the-future-is-hybrid/ ]Accessed 28 November 2017[
pdf. مدلhttp://www.bucanac.com/documents/The_V ". موجود درBucanac, Christian. (1999) "The V-Model ]3[
http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315 :". موجود درFiresmith, Don. (2013). "Using V Models for Testing ]4[
.]Accessed 15 November 2017[
[ ]5کوستیک، دوسکو & جوسیموویچ, )" Ljubisa. (2013ویژگی های مدیریت پایه مهندسی نرم افزار", فاسیکل مدیریت و مهندسی تکنولوژیسرقت. .pp. 107-111 ,2
Misra, Subhas Chandra. (2007) "Adopting agile software development practices: Success factors, changes required, and ]6[
.http://search.proquest.com/docview/304888117?accountid=12085 ". در دسترس درchallenges
A Proposal for an Agile Development Testing V-Model". Business Analyst Community & Resources" (2014) . ] مونته لئونه ، مارک7[
http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1967:| تحلیلگر مدرن. موجود در
2-1 شمارهOn Understanding Software Agility- A Social Complexity Point of View". E:CO Issue Vol. 13" .(2011) . ] پلین ، جوزف8[
pp.26-37 2011
Regulwar Ganesh, Deshmukh Prashant, Tugnayat Rohit, Jawandhiya Pradip and Gulhane Veena. (2010). "Variations in ]9[
V model for software development". International Journal of Advanced Research in Computer Science,1(2) Available at
http://search.proquest.com/docview/1443699838?accountid=12085
Available at: http://searchsoftwarequality.techtarget.com/definition/V-Model " چیه؟Rouse, Mike (2007). "V -Model(Vee-Model) ]10[
.]Accessed 15 November 2017[
."Turk Dan, France Robert and Rumpe Bernhard. (2005). "Assumptions underlying agile software-development processes ]11[
.Journal of Database Management, 16(4), 62-87
:." موجود درVenantius Laulin Madhu (2014). "Agile Testing: Key Points for Unlearning ]12[
.january/agile-testing-key-points- for-unlearning ]Accessed 28 November 2017[/2012//مقالاتhttps://www.scrumalliance.org/comm
[Verwijs, Christiaan. (2012). "ChristiaanVerwijs.nl | 5 P ]13شستشو برای )چابک( توسعه نرم افزار است که بهبود چابکی )و شما را توسعه دهنده
Available at: http://www.christiaanverwijs.nl/post/2012/10/04/5 -Principles-for-(Agile)-Software-Development-that-" .(بهتر
.improve-Agility-(and-make-you-a-better-developer).aspx ]Accessed 15 November 2017
