اعتبار و درستی‌سنجی نرم‌افزار

از ویکی‌پدیا، دانشنامهٔ آزاد
(تغییرمسیر از اعتبار و درستی‌سنجی)
پرش به ناوبری پرش به جستجو

اعتبار و صحت‌سنجی[۱] (به انگلیسی: Validation and Verification) در مهندسی نرم‌افزار به فرآیندی گفته می‌شود که پس از تولید یا در طی آن اعمال می‌گردد تا از صحت و کارایی سیستم مورد نظر اطمینان حاصل شود. در مدیریت پروژه‌های نرم‌افزاری، تست نرم‌افزار و مهندسی نیازمندی‌ها، اعتبارسنجی و صحت سنجی فرایندی است که به بررسی برآورده شدن موارد تعیین شده در مستند توصیف نیازمندی‌ها توسط سیستم مورد نظر می‌‎‎پردازد. از این فرایند همچنین به عنوان کنترل کیفیت نرم‌افزار یاد می‌شود و معمولا توسط آزمون‌گرهای نرم‌افزار به عنوان بخشی از چرخه توسعه نرم‌افزار انجام می‌گیرد. در بیانی ساده صحت‌سنجی نرم‌افزار را میتوان در قالب این مثال در نظر گرفت: "فرض کنید که قابلیت x بایستی تحقق یابد، حال آیا نرم‌افزار توانسته این هدف سیستم را بدون هیچگونه نقص و باگی پیاده‌سازی کند؟" در مقابل اعتبارسنجی نرم‌افزار را می‌توان در قالب این مثال بیان کرد: "آیا قابلیت x لزوم پیاده‌سازی دارد؟ آیا x نیازمندی‌ها در سطوح بالاتر را برآورده می‌کند؟"

هر دو واژه اعتبارسنجی و صحت‌سنجی مرتبط با مفاهیم کیفیت و تضمین کیفیت نرم‎‌افزار می‌باشند. هر چند به خودی خود این دو تضمین کننده کیفیت سیستم‌ نرم‌افزاری نخواهند بود. در واقع برای دست‌یابی به یک نرم‌افزار با کیفیت، برنامه‌ریزی صحیح، ردیابی، مدیریت پیکربندی و سایر جنبه‌های مهندسی نرم‌‎افزار نیاز می‌باشد.

تعاریف[ویرایش]

صحت‌سنجی و اعتبارسنجی دو مفهوم مشابه نیستند، و گاها افراد در تشخیص این دو دچار ابهام می‌شوند. Boehm به طور خلاصه این دو را به شرح زیر توصیف می‌کند:

  • صحت‌سنجی: به مفهوم انطباق کامل سیستم با توصیفی است که از سیستم ارائه شده (کار را درست انجام می‌دهد). آیا سیستم، صحیح ‌پیاده‌سازی شده است؟ آیا محصول نرم‌افزاری قابلیت‌های پیاده‌‎سازی شده را به درستی انجام می‌دهد؟ پیاده‌سازی سیستم به طرز صحیح یعنی سیستم بر اساس مستند توصیفات به درستی پیاده‌سازی شده باشد. لذا مستند‌ نیازمندی‌های سیستم به عنوان ورودی فاز بعدی فرایند توسعه یعنی طراحی سیستم در فاز دامنه راه‌حل داده می‌شود و خروجی این فاز مستند توصیف طراحی می‌باشد. به طور مشابه توصیف طراحی به عنوان ورودی فاز پیاده‌سازی در نظر گرفته می‌شود. به عبارتی دیگر هر مرحله که خروجی فاز به طرز صحیح نیازمندی‌های توصیف شده در مستندی که به عنوان ورودی آن فاز در نظر گرفته شده است را پیاده‌سازی می‌کند، محصول نرم‌افزاری یک گام به صحت‌سنجی نهایی نزدیک‌تر می‌شود. اگر خروجی یک فرایند صحیح نباشد، سیستم بر اساس نیازهای کاربران به طرز صحیح پیاده‌سازی نشده است.
  • اعتبارسنجی: به مفهوم انطباق نتایجی که پس از اجرای سیستم گرفته می‌شود با نتایجی که هدف ساخت سیستم بوده، می‌باشد (کارِ درست را انجام می‌دهد). آیا سیستمِ صحیح، پیاده‌سازی کرده‌ایم؟ بدر اینجا به بررسی لزوم پیاده‌سازی نیازمندها بر اساس نیاز کاربران پرداخته می‌شود. به عبارتی دیگر این فرایند به ایجاد مستند توصیف نیازمندی‌ها بر اساس نیازها و اهداف ذینفعان سیستم‌ نرم‌افزاری اشاره دارد چراکه اگر این مصنوع نرم‌افزاری ناقص و یا اشتباه باشد، توسعه‌دهندگان محصولی را ایجاد خواهند کرد که در واقع نیاز ذینفعان سیستم نبوده است.

صحت‌سنجی نرم‌افزار[ویرایش]

این مفهوم اشاره به بررسی صحت پیاده‌سازی مستندات در سطح مختلف با استفاده از اجرای نرم‌‎افزار دارد. هرچند انجام این فرایند در موارد از شفافیت کافی برخوردار نیست. برای مثال چگونه می‌توان از صحت پیاده‌سازی طراحی یا معماری سیستم تنها با اجرای نرم‎افزار مطمئن شد؟ تنها با انجام فرایندهای مروری بر روی مصنوعات مرتبط، میتوان از صحت پیاده‌سازی مستنداتی نظیر طراحی یا معماری مطمئن شد.

صحت‌سنجی توصیف یا مصنوع[ویرایش]

خروجی هر فاز از فرایند توسعه می‌تواند در فرایند صحت‌‌‎سنجی در مقابل توصیف ورودی در آن فاز مورد بررسی قرار بگیرد.

مثال‌هایی از صحت‌سنجی مصنوعات:

  • توصیف طراحی در مقابل توصیف نیازمندی‌ها: آیا توصیفاتی نظیر طراحی معماری، طراحی جزئی و مدل‌های منطقی پایگاه‌داده‌‎ای به درستی نیازمندی‌‎‎های کارکردی و کیفتی موجود در مستند نیازمندهای را پیاده‌سازی کرده‌اند؟
  • مصنوعات ساخته شده در مقابل مستند طراحی: آیا کد منبع، واسط‌های کاربری، مدل‌ فیزکی پایگاه‌داده به درستی براساس مستند توصیف طراحی پیاده‌‎سازی شده‌اند؟

اعتبارسنجی‌ نرم‌افزار[ویرایش]

این فرایند بررسی می‌کند که آیا محصول نرم‌‎افزاری از دیدگاه کلیه ذینفعان سیستم، نیازمندی‌هایی که باید/نباید برآورده کند را ارضا می‌کند یا خیر. به طور کلی دو راه برای انجام اعتبارسنجی وجود دارد. اعتبارسنجی داخلی و خارجی. در طول اعتبارسنجی داخلی این فرض در نظر گرفته می‌شود که اهداف ذینفعان به درستی اخذ شده است و در مصنوعات نیازمندی با دقت بالا و کامل توصیف شده‎‌‎‎‎‎‎‎‎‎اند. سپس اگر نرم‌افزار موارد ذکر شده در مستند توصیف نیاز‌مندها را برآورده کند، آنگاه نرم‌افزار از دیدگاه داخلی اعتبارسنجی شده است.

در نقطه مقابل، در اعتبارسنجی خارجی از ذینفعان سیستم پرسیده می‌شود که آیا سیستم نیازهای آن‌ها را برآورده کرده است یا خیر. متدولوژی‌های توسعه نرم‌افزار سطوح مختلفی برای مشارکت و اخذ بازخورد از کاربران و ذینفعان در طول فرایند توسعه در نظر می‌گیرند، بنابراین اعتبارسنجی خارجی می‌تواند به طورت گسسته یا مداوم در طول این فرایند صورت گیرد. در واقع یک اعتبارسنجی خارجی نهایی وقتی موفق است که تمام ذینفعان بر روی محصول نرم‌‎افزاری توافق داشته و برآورده شدن نیازهای خود توسط آن را تایید کنند.

اعتبارسنجی توصیف یا مصنوع[ویرایش]

نیازمندی‌ها باید پیش از ساخت سیستم نرم‌افزاری اعتبارسنجی شوند. (در مدل فرایند آبشاری نیاز است تا نیازمند‌ی‌ها پیش از شروع فاز طراحی به کامل و دقیق تعریف شده باشند. هر چند در مدل فرایند تکراری مرز دقیقی در تعریف تمام نیازمندی‌ها وجود ندارد و این موضوع اجازه بهبود و تکامل آن‌ها را در طول فرایند توسعه فراهم می‌سازد.

مثال‌هایی از اعتبارسنجی مصنوعات:

  • اعتبارسنجی توصیف نیازمندی‌های کاربر: نیازمندی‌های کاربران در مستند توصیف نیازمندی کاربران جمع‌آوری می‌‎شود و با بررسی اینکه آیا این نیازمندی‌ها در واقع اهداف ذینفعان سیستم را برآورده می‌کنند یا خیر، اعتبارسنجی می‌شوند. فرایند اعتبارسنجی به دو صورت می‌تواند صورت گیرد: 1- مصاحبه مستقیم با ذینفعان و اعتبارسنجی نیازمندی‌ها از طریق سوالات مرتبط (تست ایستا) 2- ساخت نمونه‌های اولیه و اعتبارسنجی نیازمندی‌ها از طریق کارکردن با این نمونه‌ها (تست دینامیک)
  • اعتبارسنجی ورودی‌های کاربر: ورودی‌های کاربر (جمع‌‎‎آوری شده از طریق کیبورد، سنسورها و ...) با استفاده از بررسی تطابق ورودی‌های کاربر با محدودیت‌ها و دامنه در نظر گرفته شده برای سیستم (برای مثال نوع، محدوده و فرمت داده)، اعتبارسنجی می‌شوند.

مقالات مرتبط[ویرایش]

منابع[ویرایش]

  1. اعتبار و درستی‌سنجی برابر مصوب فرهنگستان زبان و ادب فارسی به جای verification & validation در انگلیسی است. «فرهنگ واژه‌های مصوّب فرهنگستان ـ دفتر پنجم، بخش لاتین». فرهنگستان زبان و ادب فارسی. ص. ۱۱۷. بایگانی‌شده از اصلی در ۳ اوت ۲۰۰۹. دریافت‌شده در ۲۱ ژانویه ۲۰۱۲.