استاندارد طرح انتقال و تحویل نرم‌افزار

• مجید باقری

۱- مقدمه

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

۱-۱- هدف

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

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

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

۳-۱- تعاریف

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

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

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

۳-۳-۱- نرم‌افزار هدف: منظور نرم‌افزار یا جزء نرم‌افزاری است که طرح انتقال و تحویل نرم‌افزار برای آن تهیه می‌شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

۱۶-۳-۱- طرح آزمون: سندی که دامنه، روش، برنامه اجرایی و ضوابط آزمون را از پیش مشخص می‌سازد.

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

۱۸-۳-۱- دوره ضمانت: دوره زمانی که پس از تحویل اولیه نرم‌افزار به کارفرما آغاز و تا پایان زمان اتمام تعهدات کارگزار ادامه می‌یابد و در آن کارگزار متعهد به انجام خدمات ضمانت نرم‌افزار می‌باشد. منظور از این خدمات کلیه اقداماتی است که برای فراهم آوردن امکان استفاده عملیاتی و مؤثر از نرم‌افزار توسط کاربران، باید انجام شود. حدود و شرایط این خدمات را قرارداد بین کارفرما و کارگزار تعیین می‌کند، اما به‌طورکلی ممکن است شامل فعالیت‌هایی مانند آموزش و رفع اشکال و راهنمایی کاربران، نصب و راه‌اندازی (مجدد) نرم‌افزار، رفع اشکالات مشاهده‌شده در نرم‌افزار، تغییر و اعمال اصلاحات و پیشنهادهای کارفرما در نرم‌افزار، نسخه‌برداری اطلاعات و مواردی از این قبیل گردد، مشروط بر اینکه این خدمات در قرارداد پیش‌بینی‌شده باشند.

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

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

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

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

۴-۱-۱- PMP: طرح مدیریت پروژه

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

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

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

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

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

• CDM-CV10 CDM CV.010 Data Conversion Requirements, (Template), Oracle Corporation
• CDM-CV20 CDM CV.020 Data Conversion Strategy, (Template), Oracle Corporation
• CDM-CV30 CDM CV.030 Data Conversion Workplan, (Template), Oracle Corporation
• CDM-CV40 CDM CV.040 Data Conversion Module Design, (Template),
• Oracle Corporation
• CDM-CV50 CDM CV.050 Conversion Modules, (Template), Oracle Corporation
• CDM-CV60 CDM CV.060 Conversion Modules Test Results, (Template), Oracle Corporation
• CDM-CV70 CDM CV.070 Converted and Verified Data, (Template), Oracle Corporation
• CDM-RM40 CDM RM.040 Physical Resource Plan, (Template), Oracle Corporation
• CDM-RM50 CDM RM.050 Installation Plan, (Template), Oracle Corporation
• CDM-TR10 CDM TR.010 Training Requirements, (Template), Oracle Corporation
• CDM-TR20 CDM TR.020 Training Plan, (Template), Oracle Corporation
• RUP-V2 Rational Unified Process, Version 2003, Rational Inc.
• IEEE-730 ANSI/IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans, 1998
• ISO-12207 ISO/IEC 12207, Information Technology – Software Lifecycle Processes, 1995

۲- قالب طرح انتقال و تحویل نرم‌افزار

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

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

[صفحه روکش]

[تأییدیه]

[تاریخچه]

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

۱- مقدمه

۱-۱- هدف

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

۲-۱- تعاریف

۳-۱- اختصارات

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

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

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

۲- سازمان‌دهی

۱-۲- ساختار

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

۳-۲- ارتباطات

۳- محدوده کار

۱-۳- تحویل دادنی‌ها

۲-۳- فعالیت‌های انتقال و تحویل

۴- نصب و راه‌اندازی

۱-۴- برنامه نصب

۲-۴- پیش‌نیازها

۳-۴- روش تضمین کیفیت

۵- آموزش

۱-۵- برنامه آموزش

۱-۵- محتوای دوره‌ها*

۲-۵- روش تضمین کیفیت

۶- تبدیل اطلاعات

۱-۶- برنامه تبدیل اطلاعات

۲-۶- منابع اطلاعاتی*

۳-۶- برنامه‌های تبدیل*

۴-۶- روش تضمین کیفیت*

۷- اجرای آزمایشی

۱-۷- برنامه کلی

۲-۷- برنامه اجرایی

۳-۷- روش تضمین کیفیت

۸- برنامه پذیرش و تحویل

۱-۸- مراحل و شرایط پذیرش

۲-۸- مستندسازی

۹- فرم‌ها، رویه‌ها و استانداردها

۱۰- پیوست‌ها

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

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

[صفحه روکش]

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

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

[تأییدیه]

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

[تاریخچه]

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

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

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

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

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

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

۱- مقدمه

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

۱-۱- هدف

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

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

دامنه کاربرد طرح به‌طور دقیق باید در این بند تشریح گردد. نام نرم‌افزار (های) مشمول در دامنه طرح باید ذکر گردد.

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

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

۳-۱- تعاریف و اختصارات

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

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

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

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

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

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

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

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

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

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

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

در این بند، روش و ضوابط تجدیدنظر و تغییر طرح باید تشریح گردد.

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

۲- سازمان‌دهی

بخش سازمان‌دهی باید حداقل شامل بندهای زیر باشد:

۱-۲- ساختار

در این بند آن بخش از ساختار سازمانی پروژه که در فرآیند تحویل نرم‌افزار به‌صورت مستقیم درگیراست، باید در قالب یک نمودار تشکیلاتی^[۲۷] ارائه گردد. ضوابط ترسیم این نمودار به استانداردهای سازمانی کارگزار بستگی دارد، اما رعایت نکات زیر ضروری است:

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

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

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

در این بند، وظایف، اختیارات و مسئولیت‌های هریک از ارکان و عناصر مؤثر در فرآیند تحویل نرم‌افزار که در بند ()۱-۲ ذکرشده‌اند، باید تشریح گردد. رعایت قالب خاصی برای تشریح این وظایف و اختیارات لازم نیست، اما درهرصورت توضیحات ارائه شده باید به‌اندازه کافی تعیین‌کننده مسئولیت و حدود اختیارات هریک از ارکان یادشده باشد.

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

۳-۲- ارتباطات

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

مطالب این بند را می‌توان به طرح مدیریت پروژه یا سایر اسناد مشابه ارجاع داد.

۳- محدوده کار

بخش محدوده کار باید حداقل شامل بندهای زیر باشد:

۱-۳- تحویل دادنی‌ها

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

۲-۳- فعالیت‌های انتقال و تحویل

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

• نصب و راه‌اندازی نرم‌افزار در محیط عملیاتی
• آموزش کاربران
• تبدیل اطلاعات اولیه سیستم
• اجرای آزمایشی
• پذیرش تحویل دادنی‌ها توسط کارفرما

برنامه فعالیت‌های تحویل که در این بخش ذکر می‌گردد، باید دربردارنده اطلاعات زیر باشد:

• عنوان هر فعالیت
• زمان شروع و خاتمه هر فعالیت
• فعالیت (های) پیش‌نیاز برای هر فعالیت
• توضیحات بیشتر در مورد فعالیت‌ها را می‌توان به بندهای متناظر در طرح انتقال و تحویل نرم‌افزار ارجاع داد.

۴- نصب و راه‌اندازی

بخش نصب و راه‌اندازی باید حداقل شامل بندهای زیر باشد:

۱-۴- برنامه نصب

• برنامه نصب نرم‌افزار در محیط عملیاتی باید در این قسمت تشریح شود. توضیحات ارائه شده در این بند باید پرسش‌های زیر را پاسخ دهند:
• مرحله‌بندی نصب: آیا نصب به‌صورت مرحله‌ای صورت می‌گیرد، یا یک‌باره؟ در پارهای از موارد ممکن است نصب نرم‌افزار ابتدا در یک محیط آزمایشی^[۲۸] صورت گرفته و سپس در محیط استفاده واقعی نصب شود. همچنین ممکن است اجزای مختلف نرم‌افزار در مراحل مختلف نصب گردند.
• مکان: نرم‌افزار دقیقاً در چه محل (یا محل‌هایی) نصب خواهد شد.
• زمان: تاریخ دقیق نصب (در صورت مرحله‌ای بودن: تاریخ‌های دقیق نصب.) درصورتی‌که فعالیت‌های نصب بیش از یک روز به طول می‌انجامد، تاریخ شروع و خاتمه نصب باید ذکر شود.
• مسئولیت: کدام‌یک از نفرات اشاره‌شده در بند ۱-۲ مسئول نصب نرم‌افزار خواهد بود؟

۲-۴- پیش‌نیازها

در این بند پیش‌نیازهایی که پیش از نصب نرم‌افزار تأمین آن‌ها لازم است، اعم از سخت‌افزار، نرم‌افزار، فضای کاری، مجوزهای ورود و خروج و … باید به‌دقت و به‌روشنی ذکر گردد. در هر مورد، مسئولیت تأمین هر پیش‌نیاز باید مشخص گردد.

همچنین توصیه می‌شود روش برخورد با موارد اضطراری که ممکن است منجر به عدم تأمین پیش‌نیازها گردد نیز تشریح شود.

۳-۴- روش تضمین کیفیت

در این بند روش تضمین کیفیت فعالیت‌های نصب نرم‌افزار باید تشریح گردد. توضیحات ارائه شده باید روشن کند این فعالیت‌ها از سوی کارگزار و کارفرما چگونه کنترل‌شده و با تحقق چه شرایطی خاتمه یافته تلقی می‌شوند؟

۵- آموزش

بخش آموزش باید حداقل شامل بندهای زیر باشد:

۱-۵- برنامه آموزش

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

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

۲-۵- محتوای دوره‌ها*

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

۳-۵- روش تضمین کیفیت

در این بند روش تضمین کیفیت فعالیت‌های آموزش نرم‌افزار باید تشریح گردد. توضیحات ارائه شده باید روشن کند این فعالیت‌ها از سوی کارگزار و کارفرما چگونه کنترل‌شده و با تحقق چه شرایطی خاتمه یافته تلقی می‌شوند؟ توصیه می‌شود روش ارزیابی آموزش‌های ارائه شده (آزمون، مصاحبه، پرسشنامه و …) مشخص گردد.

۶- تبدیل اطلاعات

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

۱-۶- برنامه تبدیل اطلاعات

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

• آیا اصولاً استفاده عملی از نرم‌افزار، با اطلاعات اولیه آغاز خواهد شد؟ در این صورت چه اطلاعاتی به‌عنوان اطلاعات اولیه تولید و تحویل می‌گردد؟
• برای تولید اطلاعات اولیه از چه منابع اطلاعاتی، در چه محدوده زمانی و در چه قالبی (دستی یا مکانیزه) استفاده خواهد شد؟
• آیا پس از تبدیل و تحویل اطلاعات اولیه، بازنگری و تصحیح این اطلاعات توسط کاربران ضروری است؟

۲-۶- منابع اطلاعاتی*

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

در مورد منابع مکانیزه (اطلاعاتی که در محیط‌های رایانه‌ای ذخیره‌شده و قابل بازیابی می‌باشند)، اطلاعات زیر باید مشخص گردد:

• عنوان
• قالب فیزیکی (فرمت): درصورتی‌که اطلاعات این منبع دریکی از قالب‌های شناخته‌شده (Excel, DBF, …) ذخیره شده است، تنها ذکر نوع قالب کافی است. در غیر این صورت، اطلاعات لازم برای استخراج اطلاعات باید ذکر گردد.
• نام بانک اطلاعاتی، جدول، فایل یا سایر اطلاعات لازم برای شناسایی محل فیزیکی یا منطقی ذخیره‌سازی داده‌ها
• محل نگهداری فیزیکی نسخه‌ای از منبع اطلاعاتی که به‌عنوان ورودی مورداستفاده قرار خواهد گرفت.
• شناسه اقلام یا ستون‌های مورداستفاده در تبدیل (ورودی)
• شناسه اقلام یا ستون‌های خروجی به ازای هر قلم یا ستون ورودی
• ضوابط و شرایط پذیرش مقادیر ورودی
• ضوابط تبدیل (فرمول‌ها، تبدیل کدها و …)

در مورد منابع دستی (اطلاعاتی که به‌صورت کاغذی موجودند)، اطلاعات زیر باید مشخص گردد:

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

درصورتی‌که اطلاعات یادشده در اسناد طراحی سیستم ذکرشده باشد، مطالب این بند را می‌توان به اسناد مرتبط ارجاع داد.

۳-۶- برنامه‌های تبدیل*

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

۴-۶- روش تضمین کیفیت*

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

۷- اجرای آزمایشی

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

۱-۷- برنامه کلی

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

• استراتژی اجرای آزمایشی: اجرای موازی با سیستم قبلی، نصب و تسری مرحله‌به‌مرحله نرم‌افزار به واحدهای مختلف استفاده‌کننده، …
• مدت اجرای آزمایشی
• آزمون‌های لازم

۲-۷- برنامه اجرایی

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

۳-۷- روش تضمین کیفیت

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

۸- برنامه پذیرش و تحویل

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

۱-۸- مراحل و شرایط پذیرش

درصورتی‌که پذیرش نرم‌افزار توسط کارفرما در چند مرحله صورت می‌گیرد (به‌عنوان‌مثال، تحویل موقت و تحویل دائم)، در این بند شرایط پذیرش در هر مرحله باید تشریح گردد. پذیرش نرم‌افزار توسط کارفرما معمولاً منوط به انجام یک دوره آزمون پذیرش است که در آن توانایی نرم‌افزار تحویل‌شده در برآورده کردن نیازهای اعلام‌شده در اسناد قبلی باید بررسی و اثبات شود (تحلیل قابلیت ردیابی^[۲۹].) در این صورت طرح (های) آزمون پذیرش یا سایر اسناد مرتبط که به این منظور تهیه شده یا خواهد شد، باید مورداشاره قرار گیرد.

۲-۸- مستندسازی

در این بند مستندات لازم برای ثبت و مستندسازی فرآیند پذیرش فرآورده نرم‌افزاری (مانند فرم‌ها و صورت‌جلسات تحویل) باید مشخص شود. در مورد هر سند، مسئولیت تنظیم و تأیید باید تعیین گردد.

۹- فرم‌ها، رویه‌ها و استانداردها

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

۱۰- پیوست‌ها

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

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

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

[۱] Deployment Plan

[۲] Software Development Lifecycle

[۳] Contractor

[۴] Subcontractor

[۵] 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

[۱۸] Acceptance test

[۱۹] IEEE-730: p.3

[۲۰] Document Control

[۲۱] Cover Page

[۲۲] Approval

[۲۳] History

[۲۴] Approval

[۲۵] Glossary

[۲۶] Abbreviations (Acronyms)

[۲۷] Organization Chart

[۲۸] Pilot

[۲۹] Traceability Analysis

[۳۰] Abbreviation