استاندارد طرح تصدیق و صحه‌گذاری (VVP)

• مجید باقری

۱- مقدمه

این مطلب، از استاندارد طرح تصدیق و صحه‌گذاری از مجموعه گزارش‌های خروجی پروژه نظام‌مهندسی و استانداردهای تولید و توسعه نرم‌افزار (نماتن) – فاز ۲ برگرفته شده است. فرآیندهای تصدیق و صحه‌گذاری (V&V) از مهم‌ترین فرآیندهای پشتیبان توسعه نرم‌افزار است که اجرای صحیح و دقیق آن‌ها نقش عمدهای در تضمین کیفیت پروژه‌های نرم‌افزاری ایفا می‌کند. گام نخست در اجرای این فرآیندها، برنامه‌ریزی فعالیت‌های V&V است که نتیجه آن به شکل طرح تصدیق و صحه‌گذاری تدوین و ارائه می‌گردد. ازاین‌رو استانداردسازی قالب و محتوای این‌گونه طرح‌ها به‌منظور ارتقای کیفی پروژه‌های نرم‌افزاری، اقدامی ضروری است.

۱-۱- هدف

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

۲-۱- دامنه کاربرد

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

از استاندارد ارائه‌شده در این سند می‌توان برای تهیه طرح تصدیق و صحه‌گذاری برای پروژه‌هایی که به‌صورت زیرپروژه ای از یک پروژه اصلی (که ممکن است پروژه نرم‌افزاری نباشد) اجرا می‌شوند، نیز استفاده نمود.

هرچند آزمون نرم‌افزار جزء فعالیت‌های تصدیق و صحه‌گذاری محسوب می‌گردد، به دلیل وجود استاندارد ویژه‌ای برای طرح‌های آزمون نرم‌افزار در مجموعه استانداردهای نماتن (به شناسه، NMTN.STD.TestPlan) توصیه می‌شود برای تهیه طرح‌های آزمون از استاندارد یادشده استفاده شود.

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

۳-۱- تعاریف

در نگارش این طرح، از اصطلاحات زیر استفاده شده است:

۱-۳-۱- پروژه: منظور از پروژه در این سند، هر پروژه نرم‌افزاری است که از قالب ارائه شده در این استاندارد، برای تهیه طرح تصدیق و صحه‌گذاری در آن استفاده می‌شود.

۲-۳-۱- پروژه نرم‌افزاری: پروژه‌ای است که موضوع آن انجام همه یا بخشی از فعالیت‌های زیست چرخ توسعه نرم‌افزار[۲] باشد.

۳-۳-۱- زیرپروژه[۳]: بخشی از یک پروژه که با توجه به دامنه، اهداف، نتایج و یا منابع موردنیاز، بتوان آن را به‌صورت یک پروژه مستقل در نظر گرفت.

۴-۳-۱- کارفرما: شخص حقیقی یا حقوقی است که پروژه به درخواست و سفارش او اجرا می‌شود.

۵-۳-۱- کارگزار[۴]: شخص حقیقی یا حقوقی است که نسبت به اجرای پروژه متعهد گردیده است.

۶-۳-۱- کارگزار فرعی[۵]: شخص حقیقی یا حقوقی است که انجام بخشی از پروژه از سوی کارگزار به او واگذار شده است.

۷-۳-۱- کاربر: هر یک از افراد واجد صلاحیتی که پس از تهیه نرم‌افزار، از آن استفاده خواهند نمود.

۸-۳-۱- ناظر: منظور از ناظر، شخص حقیقی یا حقوقی است که از سوی کارفرما به‌منظور نظارت بر حسن اجرای پروژه تعیین‌شده است. ناظر ممکن است شخص حقیقی یا حقوقی مستقل از سازمان کارفرما، یکی از واحدهای تابعه سازمان کارفرما و یا یک یا چند نفر از کارکنان کارفرما باشد که عهده‌دار انجام وظایف نظارتی می‌گردند.

۹-۳-۱- تضمین کیفیت: به مجموعه اقدامات برنامه‌ریزی‌شده و سامانمندی گفته می‌شود که برای حصول اطمینان از تطابق ویژگی‌های همه یا بخشی از فرآورده‌ها با مشخصات و نیازهای اعلام‌شده باید انجام شود[۶].

۱۰-۳-۱- مدل فرآیند: چارچوبی شامل فرآیندها، فعالیت‌ها و وظایفی که در طی مراحل توسعه، بهره‌برداری و نگهداری از یک فرآورده نرم‌افزاری اجرا می‌شوند[۷].

۱۱-۳-۱- فرآیند[۸]:۸ مجموعه‌ای از فعالیت‌های مرتبط که ورودی‌های مشخصی را به خروجی‌های مشخصی تبدیل می‌کنند[۹]. یک فرآیند مجموعه‌ای است همگن از وظایف مرتبط که یکی از اهداف پروژه را برآورده می‌کنند. هر فرآیند به تولید یک یا چند فرآورده کلیدی پروژه منجر می‌شود. هر فرآیند رشته‌ای از فعالیت‌های مرتبط است که معمولاً برای انجام آن‌ها مهارت‌های مشابه و مرتبط لازم است[۱۰]. به‌عبارت‌دیگر، فرآیندها بالاترین سطح تقسیم‌بندی وظایف یک پروژه نرم‌افزاری ازنظر نوع وظایف است.

۱۲-۳-۱- تصدیق[۱۱]: فرآیندی است که برای اطمینان از تطابق ویژگی‌های فرآورده (های) یک فعالیت در چرخه توسعه نرم‌افزار، با نیازهای اعلام‌شده همان مرحله انجام می‌شود[۱۲].

۱۳-۳-۱- صحه‌گذاری[۱۳]: فرآیند ارزیابی یک محصول نرم‌افزاری که با هدف اطمینان از تطابق ویژگی‌های آن با نیازهای کاربر انجام می‌شود[۱۴].

۱۴-۳-۱- بازنگری (بازنگری فنی)[۱۵]: بررسی رسمی فرآورده‌ها و فرآیندهای پروژه برای اطمینان از تطابق این فرآورده‌ها و فرآیندها با استانداردهای پروژه و/یا نیازهای کاربران که به شکل گروهی و در طی جلسات رسمی انجام می‌گردد. موضوع هر بازنگری فنی ممکن است بررسی و ارزیابی یک

فرآورده یا فرآیند خاص پروژه باشد[۱۶].

۱۵-۳-۱- بازرسی[۱۷]: بررسی رسمی فرآورده‌های پروژه توسط یک یا چند نفر (غیر از تهیه‌کننده فرآورده) که به‌منظور شناسایی خطاها و موارد عدم تطابق این فرآورده‌ها با استانداردهای توسعه یا نیازهای کاربران، پس از تهیه این فرآورده‌ها انجام می‌شود[۱۸]. تفاوت بازرسی با بازنگری فنی در این است که (۱) در بازرسی تنها فرآورده‌ها بررسی می‌شوند، نه فرآیندها و (۲) بازرسی برخلاف بازنگری فنی تنها پس از تهیه فرآورده انجام می‌شود، نه در حین تهیه.

۱۶-۳-۱- بازنگری گام‌به‌گام[۱۹]: بررسی غیررسمی فرآورده‌های پروژه برای اطمینان از تطابق این فرآورده‌ها و فرآیندها با استانداردهای پروژه و/یا نیازهای کاربران که به شکل گروهی و در طی جلسات غیررسمی انجام می‌گردد[۲۰].

۱۷-۳-۱- ممیزی[۲۱]: بررسی رسمی فرآورده‌ها یا فرآیندهای پروژه برای ارزیابی تطابق این فرآورده‌ها و فرآیندها با استانداردهای پروژه و/یا نیازهای کاربران که توسط شخص یا گروهی مستقل از تهیه‌کنندگان فرآورده‌ها یا مجریان فرآورده‌ها انجام می‌شود[۲۲].

۱۸-۳-۱- آزمون[۲۳]: فرآیند بررسی یا اجرای یک نرم‌افزار یا جزء نرم‌افزاری به‌صورت دستی یا خودکار، به‌منظور ارزیابی تطابق ویژگی‌های آن با نیازهای مشخص‌شده از قبل و یا به‌منظور مقایسه بین نتایج موردانتظار و نتایج واقعی. آزمون اساساً پس از هر واحد پیاده‌سازی قابل‌اعمال است و موضوع آن برنامه‌های نوشته‌شده و قابل‌اجرا می‌باشد. بسته به سطح تکامل برنامه‌های موضوع آزمون، سطوح مختلفی از آزمون قابل‌اجرا است.

۱۹-۳-۱ آزمون واحد[۲۴]: نوعی آزمون است که در سطح واحدهای پایه‌ای سیستم (زیر برنامه‌ها، توابع، روال‌های پایگاه دادهای و برنامه‌های نیم ساخته) انجام می‌شود.

۲۰-۳-۱ آزمون یکپارچگی[۲۵]: پس از ترکیب و یکپارچه‌سازی اجزا و عناصر نرم‌افزاری با یکدیگر و تولید برنامه‌های اجرایی، آزمون یکپارچگی با هدف اطمینان از صحت کارکرد واحدهای نرم‌افزاری در ترکیب با یکدیگر اجرا می‌شود. موضوع آزمون یکپارچگی، برنامه‌های اجرایی یکپارچه و قابل‌اجرا است.

۲۱-۳-۱- آزمون سیستم[۲۶]: سطحی از آزمون است که در آن‌همه عناصر یک سیستم با همدیگر به‌عنوان یک کل مورد آزمایش قرار می‌گیرند. این اجزا عبارت‌اند از برنامه‌های اجرایی، پایگاه داده‌ها، مستندات کاربر، نیروی انسانی و تجهیزات سخت‌افزاری. هدف از آزمون سیستم اطمینان از این نکته است که همه بخش‌های سیستم به‌درستی با یکدیگر تبادل داده و عملیات انجام می‌دهند و در گردش اطلاعات هیچ شکاف[۲۷] پیش‌بینی‌نشده‌ای موجود نیست. به‌ویژه ارتباط سیستم با روال‌های دستی (غیرمکانیزه) باید آزمون شود. رویکرد اصلی در آزمون سیستم، طراحی و اجرای سناریوهای آزمون است.

۲۲-۳-۱- آزمون پذیرش[۲۸]: آزمون پذیرش که آزمون پذیرش کاربر هم نامیده می‌شود، پس از تحویل نسخه اجرایی نرم‌افزار در محل استفاده عملیاتی و توسط کاربران نهایی (معمولاً با برنامه‌ریزی و هدایت مشترک تیم مجری پروژه) اجرا می‌شود. هدف از این آزمون اطمینان از این نکته است که سیستم در شرایط عملیاتی معمولی و با اطلاعات واقعی قادر به برآورده کردن نیازهای کاربران می‌باشد.

۲۳-۳-۱- پیکربندی: مجموعه مستندات، ابزارها و اجزای نرم‌افزاری که یک نسخه خاص از یک نرم‌افزار را مشخص می‌کند.

۲۴-۳-۱- مدیریت پیکربندی ([۲۹]CM) فرآیند شناسایی اقلام پیکربندی، کنترل ارائه و تغییرات این اقلام در طول زیست چرخ توسعه نرم‌افزار، ثبت و گزارش دهی وضعیت اقلام پیکربندی و درخواست‌های تغییر و تصدیق صحت اقلام پیکربندی را مدیریت پیکربندی می‌نامیم.

۴-۱- اختصارات

در نگارش این طرح، از اختصارات زیر استفاده شده است:

۴-۱-۱- V&V: فرآیندهای تصدیق و صحه‌گذاری نرم‌افزار

۴-۱-۲- VVP: طرح تصدیق و صحه‌گذاری

۴-۱-۳- MDD: سند توصیف متدولوژی

۴-۱-۴- CMP: طرح مدیریت پیکربندی

۴-۱-۵- QA: تضمین کیفیت

۴-۱-۶- QAP: طرح تضمین کیفیت

۵-۱- منابع و مراجع

از مراجع زیر برای تهیه این استاندارد استفاده شده است:

• IEEE-1012 ANSI/IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation, 1998
• IEEE-1028 ANSI/IEEE Std 1028-1997, IEEE Standard for Software Reviews, 2002
• IEEE-730 ANSI/IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans, 1998
• ISO-12207 Information technology- Software Lifecycle processes, ISOIEC 12207, 1st Edition, 1999
• ANDRIOLE-86 Andriole, S.J. (ed.), Software Validation, Verification, Testing and Documentation, Petrocelli Books, 1986
• SEI-CM03 Collofello, J.S., Software Technical Review Process, CMU-SEI Curriculum Module, 1998 NIST-234
• Reference Information for the Software Verification and Validation Process, National Institute of Standards and Technology, 1996
• NASA-2210 Software Assurance Standard, NASA-STD-2210-93, 1992 TICKIT-5 The TickIT Guide, Issue 5.0, 2001 ESA-76
• استانداردهای مهندسی نرم‌افزار ـ آژانس فضایی اروپا، ترجمه: ا.مرآت نیا و ن.مرآت نیا، اداره کل آمار و اطلاعات وزارت کشاورزی ـ ۱۳۷۶
• ISO-9001 استاندارد ایران – ایزو – ۹۰۰۱ مؤسسه استاندارد و تحقیقات صنعتی ایران، چاپ اول، دی‌ماه ۱۳۷۴

۲- قالب طرح تصدیق و صحه‌گذاری

قالب استاندارد طرح تصدیق و صحه‌گذاری در این فصل ارائه می‌شود. در استفاده از قالب استاندارد ارائه شده باید به نکات زیر توجه نمود:

• سرفصل‌های ارائه شده در قالب استاندارد، باید به‌عنوان سرفصل‌های حداقل تلقی گردد. به‌این‌ترتیب افزودن سرفصل‌های دیگر به طرح‌های تصدیق و صحه‌گذاری، به دلیل الزامات قراردادی یا دلایل دیگر مجاز می‌باشد. در این صورت توصیه می‌گردد افزودن مطالب اضافی به‌گونه‌ای صورت پذیرد که سرفصل‌های موجود در این استاندارد، با همین ترتیب و همین شماره‌گذاری قابل‌تشخیص باشد.
• برخی از سرفصل‌های ذکرشده در قالب استاندارد، با علامت (*) مشخص‌شده‌اند. ذکر مطالب ذیل این سرفصل‌ها در طرح، برخلاف سایر سرفصل‌ها اجباری نیست و می‌توان به دلیل حجم پروژه، توافق کارفرما و کارگزار، یا بلاموضوع بودن مطالب آن سرفصل با توجه به موضوع پروژه، چنین سرفصل‌هایی را از یک طرح حذف نمود، بی‌آنکه تطابق آن طرح با این استاندارد خدشه‌دار گردد. در صورت حذف مطالب این سرفصل‌ها از یک طرح، عناوین سرفصل‌های حذف‌شده باید در طرح ذکرشده و دلایل و توجیهات حذف هر سرفصل بیان گردد.
• در تشریح مطالب استاندارد، از واژه‌های «ضروری است…»، «باید…» و «نباید…» برای بیان ضرورت و الزام استفاده شده است. رعایت موارد مشخص‌شده با این واژه‌ها برای تطابق یک طرح با این استاندارد ضروری است.
• همچنین از واژه «توصیه می‌شود…» برای بیان مواردی استفاده شده است که رعایت آن‌ها برای تطابق یک طرح با این استاندارد ضروری نیست، اما رعایت آن‌ها توصیه می‌گردد.
• واژه «می‌توان…» نیز برای بیان موارد اختیاری استفاده شده است. رعایت موارد مشخص‌شده با این واژه برای تطابق یک طرح با این استاندارد ضروری نیست.
• در صورت توافق کارگزار با کارفرما، می‌توان طرح تصدیق و صحه‌گذاری را به‌صورت تدریجی تکمیل و ارائه کرد. در این صورت هریک از سرفصل‌هایی که در اصلاحیه‌های بعدی طرح تکمیل خواهد شد، باید با عباراتی نظیر «در اصلاحیه‌های بعدی تکمیل خواهد شد»، مشخص گردد.
• قسمت‌های ابتدایی هر طرح که به‌منظور کنترل مستندات[۳۰] در هر سند گنجانده می‌شود (مانند صفحه روکش[۳۱]، تأییدیه[۳۲]، تاریخچه[۳۳]،۳۳ فهرست مطالب و)…، جزء الزامات این استاندارد نبوده و مشمول ضوابط عمومی مستندسازی هر پروژه می‌باشد.

[صفحه روکش]

[تأییدیه]

[تاریخچه]

[فهرست مطالب]

۱- مقدمه

۱-۱- هدف

۲-۱- دامنه کاربرد

۳-۱- تعاریف

۴-۱- اختصارات*

۵-۱- اسناد مرتبط

۶-۱- مرور طرح*

۷-۱- روش تغییر طرح*

۲- مدیریت فرآیندهای V&V

۱-۲- سازمان

۲-۲- مقاطع زمانی انجام فعالیت‌های V&V

۳-۲- زمان‌بندی انجام فعالیت‌های *V&V

۴-۲- منابع موردنیاز

۵-۲- مسئولیت‌ها

۶-۲- ابزارها و روش‌ها

۳- فعالیت‌های V&V

۴- گزارش دهی

۵- پیوست‌ها*

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

[صفحه روکش]

در صفحه روکش طرح حداقل مطالب زیر باید ذکرشده باشد:

• عنوان «طرح تصدیق و صحه‌گذاری»
• عنوان کامل پروژه
• عنوان کارفرما
• عنوان کارگزار
• تاریخ تهیه طرح
• شناسه سند (به انضمام شماره اصلاحیه)
• تعداد صفحات سند

[تأییدیه]

در قسمت تأییدیه، حداقل مطالب زیر باید ذکرشده باشد:

• نام، سمت و امضای تهیه‌کننده (یا تهیه‌کنندگان) سند
• نام، سمت و امضای فرد (یا افراد) مسئول کنترل کیفی سند
• نام، سمت و امضای فرد (یا افراد) مسئول تأیید و تصویب سند
• تاریخ بررسی و تأیید سند توسط هریک از تأییدکنندگان

[تاریخچه]

در قسمت تاریخچه، حداقل مطالب زیر باید ذکرشده باشد:

• شماره و تاریخ تصویب[۳۴] هر یک از اصلاحیه‌های پیشین و اصلاحیه فعلی
• شرح مختصری از دلایل صدور هر اصلاحیه و شماره صفحات یا شماره بندهایی که تغییر کرده است.

[فهرست مطالب]

در فهرست مطالب، حداقل مطالب زیر باید ذکرشده باشد:

• شماره بندهای سند
• عنوان کامل هر بند
• شماره صفحه شروع هر بند

توصیه می‌گردد در نسخه الکترونیکی سند، عنوان هر بند با استفاده از امکان اتصال ابرمتنی[۳۵]، به ابتدای بند مربوطه در سند متصل شود.

۱- مقدمه

مقدمه طرح باید حداقل شامل بندهای زیر باشد:

۱-۱- هدف

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

۲-۱- دامنه کاربرد

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

۳-۱- تعاریف

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

درصورتی‌که سند دیگری به‌عنوان واژه‌نامه[۳۶] پروژه تهیه شده است، می‌توان به‌جای تکرار مطالب آن در این بند، به آن سند ارجاع داد.

۴-۱- اختصارات*

کلیه اختصارات (کوته‌نوشت[۳۷] های) مورداستفاده در طرح، باید فهرست شده و تشریح گردند.

۵-۱- اسناد مرتبط

در این بند فهرست و مشخصات اسناد زیر باید ذکر شود:

• منابع و مراجعی که برای تهیه طرح از آن‌ها استفاده شده است (کتاب‌های مرجع، اسناد قراردادی و قانونی و …)
• سایر اسناد پروژه که در این طرح به آن‌ها ارجاع داده شده است.
• استاندارد حاضر

برای هر سند فهرست شده در این بند، مشخصات کامل سند تا حدی که شناسایی سند به‌صورت یگانه ممکن باشد، باید ذکر گردد. در مورد کتاب‌ها، ذکر عنوان، نام نویسنده (یا نویسندگان)، ناشر، نوبت چاپ و تاریخ انتشار توصیه می‌شود. در مورد سایر اسناد، عنوان کامل، شناسه سند، شماره اصلاحیه (در صورت وجود) و تاریخ انتشار باید قید گردد.

۶-۱- مرور طرح*

در این بند، قسمت‌های مختلف طرح و محتوای اجمالی هر قسمت، باید به‌صورت گذرا تشریح گردد.

۷-۱- روش تغییر طرح*

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

۲- مدیریت فرآیندهای V&V

این بخش حداقل باید حاوی بندهای زیر باشد.

۱-۲- سازمان

عناصر درگیر در انجام فعالیت‌های V&V همراه با شرح وظایف مربوطه در این بند معرفی می‌شوند. بخشی از واحدها و عناصر موجود در ساختار سازمانی پروژه که در فعالیت‌های V&V مؤثرند، باید در قالب یک نمودار تشکیلاتی[۳۸] تشریح گردند. ضوابط ترسیم این نمودار به استانداردهای سازمانی کارگزار بستگی دارد، اما رعایت نکات زیر ضروری است:

• برای هر یک از عناصر موجود در نمودار، عنوان کامل و گویایی باید ذکر شود.
• واحدهای سازمانی (کمیته، گروه، واحد و …) باید به نحو مناسبی از افراد (مدیر، مسئول و …) متمایز گردند.
• خطوط فرماندهی و گزارش دهی باید به‌طور مشخص و بدون ابهام ترسیم شده باشند.

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

در مورد همه عناصر سازمانی درگیر در فرآیندهای،V&V وابستگی یا استقلال سازمانی از تیم تهیه نرم‌افزار باید به‌روشنی تصریح گردد.

۲-۲- مقاطع زمانی انجام فعالیت‌های V&V

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

۳-۲- زمان‌بندی انجام فعالیت‌های *V&V

در این بند باید زمان‌بندی انجام فعالیت‌های V&V بر اساس زمان‌بندی ارائه شده در طرح مدیریت پروژه ارائه شود. درواقع این برنامه زمانی می‌تواند همان زمان‌بندی انجام پروژه باشد که در آن فعالیت‌های V&V به نحوی متمایز شده‌اند.

۴-۲- منابع موردنیاز

منابع موردنیاز برای انجام فعالیت‌های V&V در این بند باید تعیین گردد. برحسب مورد به موارد زیر می‌توان اشاره نمود:

• نیروی انسانی: برحسب تخصص‌ها و مدت‌زمان موردنیاز
• سخت‌افزار: نوع، تعداد و مدت‌زمان استفاده از کامپیوترها و سایر تجهیزات سخت‌افزاری
• نرم‌افزار: نوع و تعداد نرم‌افزارهای موردنیاز
• سایر منابع موردنیاز

۵-۲- مسئولیت‌ها

مسئولیت انجام هریک از فعالیت‌های V&V باید در این بند مشخص شود. درصورتی‌که مسئولیت یک فعالیت به عهده یک گروه یا یک کمیته باشد، باید فرد پاسخگو از طرف کمیته یا گروه نیز مشخص گردد.

۶-۲- ابزارها و روش‌ها

در این بند ابزارها و روش‌های بکار گرفته شده برای انجام فرآیندهای (V&V مانند چک‌لیست‌ها، ابزارهای نرم‌افزاری و …) و الزامات استفاده از آن‌ها باید مشخص شود. درصورتی‌که بخشی از این ابزارها و روش‌ها در سایر اسناد پروژه (مثلاً طرح آزمون نرم‌افزار) تشریح شده است، می‌توان به آن اسناد ارجاع داد.

۳- فعالیت‌های V&V

فعالیت‌های طراحی‌شده برای تصدیق و صحه‌گذاری، به تفکیک مراحل زیست چرخ توسعه، همچنین فعالیت‌های لازم برای مدیریت فرآیندهای V&V در این فصل باید ارائه گردد.

به ازای هریک از فعالیت‌ها مشخصات زیر باید ارائه گردد:

• عنوان فعالیت
• شناسه
• هدف
• روش‌ها و معیارها
• ورودی‌ها
• فرآورده‌ها
• مسئولیت‌ها

۴- گزارش دهی

کلیه فعالیت‌هایی که در چهارچوب فرآیندهای V&V پروژه انجام می‌شوند، باید به‌صورت رسمی ثبت‌شده و نتایج آن‌ها به نحو مناسبی گزارش شود. در این فصل نحوه گزارش دهی راجع به انجام فعالیت‌های V&V باید تعیین گردد.

۵- پیوست‌ها*

کلیه مطالب کمکی که ذکر آن‌ها برای فهم مطالب طرح لازم است، باید به‌صورت پیوست به انتهای طرح افزوده شود. به‌ویژه وجود فرم‌هایی که در متن طرح به آن‌ها اشاره‌شده است و همچنین پیوست زیر در انتهای طرح توصیه می‌شود:

۱-۵- واژه‌نامه*

کلیه واژگان و اصطلاحات فنی استفاده شده در طرح باید در این بخش توضیح داده شوند. برای هر واژه، ذکر برابر انگلیسی و کوته‌نوشت (در صورت وجود) ضروری است. واژه‌نامه باید برحسب حروف الفبای فارسی مرتب شده باشد. توصیه می‌شود واژه‌نامه انگلیسی-فارسی نیز ارائه گردد.

[۱] VVP: Verification & Validation Plan

[۲] Software Development Lifecycle

[۳] Sub-project

[۴] Contractor

[۵] Subcontractor

[۶] IEEE-730: p.3

[۷] ISO-12207: p.3 (Life cycle model)

[۸] Process

[۹] ISO-12207: p.4 (Process)

[۱۰] CDM-HND: p.1-5

[۱۱] Verification

[۱۲] ISO-12207: p.5 (Verification)

[۱۳] Validation

[۱۴] ISO-12207: p.5 (Validation)

[۱۵] Technical review

[۱۶] IEEE-1028: p.5 (Technical Review)

[۱۷] Inspection

[۱۸] IEEE-1208: p.4 (Inspection)

[۱۹] Walk-through (Walkthrough)

[۲۰] IEEE-1028: p.5 (Walk-through)

[۲۱] Auditing

[۲۲] IEEE-1028: p.4(Audit)

[۲۳] Test

[۲۴] Unit test

[۲۵] Integration test

[۲۶] System test

[۲۷] Gap

[۲۸] Acceptance test

[۲۹] CM: Configuration Management

[۳۰] Document Control

[۳۱] Cover Page

[۳۲] Approval

[۳۳] History

[۳۴] Approval

[۳۵] Hyperlink

[۳۶] Glossary

[۳۷] Abbreviations (Acronyms)

[۳۸] Organization Chart