استاندارد طرح نظارت نرم‌افزار

• مجید باقری

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

۱-۱- هدف

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

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

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

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

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

۹-۳-۱- طرح نظارت: سندی است که به‌منظور روشن شدن دامنه و نحوه انجام فعالیت‌های نظارتی بر یک پروژه تدوین می‌گردد. مسئولیت تدوین طرح نظارت بر یک پروژه، معمولاً به عهده ناظر پروژه است.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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
• CFG-AUD Auditing Standard (Template), CFG Microsystems Ltd., IT Department, 1997
• TICKIT-5 The TickIT Guide, Issue 5.0, 2001
• NMTN.MNT.03
• نظام‌مهندسی و استانداردهای تولید و توسعه نرم‌افزار (نماتن)، مرحله اول: نحوه ارجاع کار، فصل سوم، نظارت بر پروژه‌های نرم‌افزاری

۲- قالب طرح نظارت

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

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

[صفحه روکش]

[تأییدیه]

[تاریخچه]

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

۱- مقدمه

۱-۱- هدف

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

۳-۱- تعاریف

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

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

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

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

۲- دامنه

۱-۲- موضوع پروژه

۲-۲- دامنه نظارت

۳-۲- محل اجرا

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

۱-۳- ساختار

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

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

۴- فعالیت‌های نظارتی

۵- نظارت بر فرآورده‌ها

۶- نظارت بر فرآیندها

۷- گزارش دهی و رفع اشکالات

۱-۷- گزارش‌های مدیریتی*

۲-۷- گزارش‌های فنی

۳-۷- نحوه رفع اشکالات

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

۹- پیوست‌ها

۱-۹- واژه‌نامه

۲-۹- چک‌لیست‌های نظارتی

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

[صفحه روکش]

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

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

[تأییدیه]

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

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

[تاریخچه]

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

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

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

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

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

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

۱- مقدمه

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

۱-۱- هدف

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

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

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

۶-۱ مرور طرح*

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

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

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

۲- دامنه

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

۱-۲- موضوع پروژه

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

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

۲-۲- دامنه نظارت

در این بند، حدودوثغور فعالیت‌های نظارتی باید روشن گردد. فعالیت‌ها و وظایف نظارتی در جلد سوم گزارش‌های نظام‌مهندسی و استانداردهای پروژه‌های نرم‌افزاری شامل موارد زیر می‌گردد (ولی محدود به این موارد نمی‌باشد):

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

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

۳-۲- محل اجرا

در این بند محل اجرای فعالیت‌های نظارتی باید ذکر گردد.

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

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

۱-۳- ساختار

در این بند ساختار سازمانی نظارت بر پروژه، باید در قالب یک نمودار تشکیلاتی[۳۱] ارائه گردد. ضوابط ترسیم این نمودار به استانداردهای سازمانی ناظر بستگی دارد، اما رعایت نکات زیر ضروری است:

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

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

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

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

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

۴- فعالیت‌های نظارتی

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

• بازنگری
• بازرسی
• ممیزی
• آزمون

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

• این فعالیت با چه هدفی انجام می‌شود؟
• این فعالیت توسط چه کسانی انجام می‌شود؟
• برای انجام این فعالیت از چه استانداردها، یا چک‌لیست‌هایی استفاده می‌شود؟

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

۵- نظارت بر فرآورده‌ها

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

۶- نظارت بر فرآیندها

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

۷- گزارش دهی و رفع اشکالات

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

۱-۷- گزارش‌های مدیریتی*

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

۲-۷- گزارش‌های فنی

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

۳-۷- نحوه رفع اشکالات

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

• گردش کار ارائه گزارش اشکال، بررسی و تأیید گزارش اشکال، ابلاغ و اعلام اشکال به کارگزار، اعلام رفع اشکال و بررسی مجدد
• مسئولیت‌های هریک از ارکان سازمانی در این گردش کار
• مهلت‌های زمانی
• نحوه حل‌وفصل موارد اختلاف بین ناظر و کارگزار

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

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

۹- پیوست‌ها

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

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

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

۲-۹- چک‌لیست‌های نظارتی*

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

[۱] Software Development Lifecycle

[۲] Sub-project

[۳] Contractor

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

[۲۲] Acceptance test

[۲۳] Document Control

[۲۴] Cover Page

[۲۵] Approval

[۲۶] History

[۲۷] Approval

[۲۸] Hyperlink

[۲۹] Glossary

[۳۰] Abbreviations (Acronyms)

[۳۱] Organization Chart