استاندارد طرح مدیریت پیکربندی (CMP)

• مجید باقری

۱- مقدمه

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

۱-۱- هدف

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

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

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

۱۵-۳-۱- مبناگذاری[۱۴]: عمل تبدیل بخشی از فرآورده‌های یک پروژه نرم‌افزاری به مبنا را مبناگذاری می‌نامیم.

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

۱۷-۳-۱- ممیزی پیکربندی: فرآیند تصدیق تطابق اقلام پیکربندی واقعی با مشخصات فیزیکی و کارکردی ثبت‌شده را ممیزی پیکربندی می‌نامیم.

۱۸-۳-۱- کنترل پیکربندی: فرآیند بررسی، تأیید یا رد و هماهنگ کردن تغییرات اقلام پیکربندی پس از مبناگذاری آن‌ها را کنترل پیکربندی می‌نامیم.

۱۹-۳-۱- مرجع کنترل پیکربندی ([۱۵]CCB): فرد یا گروه خاصی که مجاز به بررسی و تأیید یا رد تغییرات درخواست شده و کنترل پیاده‌سازی تغییرات تأییدشده می‌باشد.

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

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

۴-۱-۱- CM: مدیریت پیکربندی

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

۴-۱-۱- CI: قلم پیکربندی

۴-۱-۱- CCB: مرجع کنترل پیکربندی

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

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

۴-۱-۱- QAP: طرح تضمین کیفیت پروژه

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

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

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

• IEEE-828 ANSI/IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans, 1998
• ISO-12207 Information technology- Software Lifecycle processes, ISOIEC 12207, 1st Edition, 1999 ISO-15846
• Information technology- Software Lifecycle processesConfiguration Management, ISO-IEC TR 15846, 1st Edition, 1998
• BERSOFF-97 Bersoff, E.H., Elements of Software Configuration Management, in THAYER-97
• MIL-61A Configuration Management Guidance, US Department Of Defense, 2001
• SEI-CM04 Tomayko, J.E., Software Configuration Management, CMUSEI Curriculum Module, 1990
• CDM-PJM CDM Project Management Method Handbook, Oracle Corporation, 1999
• CDM-PJT CDM Project Management Process and Task Reference, Oracle Corporation, 1999
• RUP-V2 Rational Unified Process, Version 2003, Rational Inc.
• LYON-00 Lyon, D.D, Practical CM: Best Configuration Management, Butterworth-Heinemann, 2000 ESA-76
• استانداردهای مهندسی نرم‌افزار ـ آژانس فضایی اروپا، ترجمه: ا.مرآت نیا و ن.مرآت نیا، اداره کل آمار و اطلاعات وزارت کشاورزی ـ ۱۳۷۶

۲- قالب طرح مدیریت پیکربندی

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

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

[صفحه روکش]

[تأییدیه]

[تاریخچه]

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

۱- مقدمه

۱-۱- هدف

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

۳-۱- تعاریف

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

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

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

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

۲- مدیریت

۱-۲- سازمان اجرایی

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

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

۳- فعالیت‌های پیکربندی

۱-۳- شناسایی

۲-۳- کنترل پیکربندی

۳-۳- گزارش وضعیت پیکربندی

۴-۳- ارزیابی پیکربندی

۵-۳- نسخه‌برداری

۶-۳- کنترل واسط‌ها

۷-۳- کنترل تأمین‌کنندگان*

۴- برنامه زمانی

۵- منابع

۱-۵- نیروی انسانی

۲-۵- سخت‌افزار

۳-۵- نرم‌افزار

۴-۵- سایر منابع*

۶- ابزارها، روش‌ها و استانداردها

۷- پیوست‌ها

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

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

[صفحه روکش]

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

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

[تأییدیه]

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

[تاریخچه]

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

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

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

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

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

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

۱- مقدمه

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

۱-۱- هدف

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

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

دامنه کاربرد طرح به‌طور دقیق باید در این بند تشریح گردد. موارد زیر باید مورداشاره قرار گیرد:

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

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

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

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

در این بند، روش و ضوابط تجدیدنظر و تغییر طرح باید تشریح گردد. توصیه می‌شود موارد زیر تشریح گردد:

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

۲- مدیریت

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

۱-۲- سازمان اجرایی

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

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

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

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

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

در این بند، وظایف، اختیارات و مسئولیت‌های هریک از واحدها یا پست‌های سازمانی درگیر در فرآیند مدیریت پیکربندی پروژه که در بند (۱-۲) ذکرشده‌اند، در اجرای فعالیت‌های مدیریت پیکربندی (مندرج در بخش ۳ طرح) باید تشریح گردد.

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

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

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

۳- فعالیت‌های پیکربندی

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

۱-۳- شناسایی

در این بند ضوابط حاکم بر شناسایی اقلام تحت مدیریت پیکربندی پروژه باید تشریح گردد. این ضوابط باید حداقل موارد زیر را دربرگیرد:

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

۲-۳- کنترل پیکربندی

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

• نحوه درخواست تغییر، شامل عناصر مجاز به درخواست، نحوه اعلام و ثبت درخواست، فرم‌ها و رویه‌های مورداستفاده در ثبت و نگهداری سوابق درخواست
• نحوه تأیید یا رد درخواست تغییر، شامل عناصر مجاز به بررسی و اعلام نظر، فرم‌ها و رویه‌های مورداستفاده در ثبت و نگهداری سوابق بررسی و تصمیم‌گیری در مورد تأیید یا رد درخواست تغییر
• نحوه پیاده‌سازی و اعمال تغییرات تأییدشده، نحوه کنترل و تأیید تغییرات صورت گرفته و نحوه مبناگذاری نسخه‌های جدید ضوابط و اطلاعات ارائه‌شده باید به‌گونه‌ای باشد که بتوان سوابق، تاریخچه و نتایج هر تغییر در CI های مبناگذاری شده را دقیقاً ردیابی نمود.

۳-۳- گزارش وضعیت پیکربندی

ضوابط حاکم بر فعالیت گزارش وضعیت پیکربندی در فرآیند مدیریت پیکربندی پروژه باید در این بند تشریح گردد. این ضوابط باید حداقل موارد زیر را دربرگیرد:

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

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

۴-۳- ارزیابی پیکربندی

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

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

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

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

۵-۳- مدیریت انتشار

روش‌ها و ضوابط مدیریت انتشار[۲۶] نرم‌افزار باید در این قسمت تشریح شوند. مدیریت انتشار شامل تمهیدات زیر می‌گردد:

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

۶-۳- نسخه‌برداری

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

• برنامه زمانی یا رویدادهای فعال‌کننده نسخه‌برداری
• روش نسخه‌برداری
• رسانه (های) فیزیکی مورداستفاده در نسخه‌برداری
• تعداد نسخه‌های تهیه‌شده
• روش مستندسازی و شناسایی نسخه‌ها
• محل نگهداری هر نسخه
• روش کنترل دسترسی به اطلاعات نسخه‌برداری‌شده
• رویه بازیابی اطلاعات نسخه‌برداری‌شده
• مدت‌زمان نگهداری اطلاعات نسخه‌برداری‌شده

۷-۳- کنترل واسط‌ها

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

• سخت‌افزارهای مورداستفاده برای توسعه نرم‌افزار
• نرم‌افزارهای پایه شامل سیستم‌عامل، نرم‌افزارهای مدیریت پایگاه داده‌ها، نرم‌افزارهای سیستمی، میان‌افزارها
• نتایج سایر پروژه‌های مرتبط

در این بند باید فهرست واسطه‌ای مؤثر بر اقلام تحت مدیریت پیکربندی پروژه ارائه گردد. همچنین نحوه ارتباط تغییر در CI های پروژه با تغییر در هر یک از این واسط‌ها باید مشخص گردد.

۸-۳- کنترل تأمین‌کنندگان*

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

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

۴- برنامه زمانی

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

۵- منابع

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

۱-۵- نیروی انسانی

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

۲-۵- سخت‌افزار

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

۳-۵- نرم‌افزار

نرم‌افزارهای لازم برای انجام فعالیت‌های مدیریت پیکربندی باید مشخص گردد.

۴-۵- سایر منابع*

درصورتی‌که برای انجام فعالیت‌های مدیریت پیکربندی، منابع (تجهیزات، امکانات، تسهیلات و …) دیگری غیر از موارد مذکور در بندهای (۱-۵) تا (۳-۵) موردنیاز است، این منابع باید مشخص گردند.

۶- ابزارها، روش‌ها و استانداردها

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

۷-پیوست‌ها

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

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

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

[۱] CMP: Configuration Management Plan

[۲] Software Development Lifecycle

[۳] Sub-project

[۴] Contractor

[۵] Subcontractor

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

[۷] Technical review

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

[۹] Auditing

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

[۱۱] CI: Configuration Item

[۱۲] CM: Configuration Management

[۱۳] Baseline

[۱۴] Baselining

[۱۵] CCB: Configuration Control Board

[۱۶] Document Control

[۱۷] Cover Page

[۱۸] Approval

[۱۹] History

[۲۰] Approval

[۲۱] Hyperlink

[۲۲] Glossary

[۲۳] Abbreviations (Acronyms)

[۲۴] Organization Chart

[۲۵] Configuration evaluation

[۲۶] Release management