بهینه سازی تست نرم افزار

چکیدههدف هر مشاغل تأمین نیازهای مشتریان هدف خود است و صنعت 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 ,2Misra, Subhas Chandra. (2007) "Adopting agile software development practices: Success factors, changes required, and ]6[.http://search.proquest.com/docview/304888117?accountid=12085 ". در دسترس درchallengesA 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 2011Regulwar 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 athttp://search.proquest.com/docview/1443699838?accountid=12085Available 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