استاندارد سند توصیف متدولوژی (MDD)

562 277 مشاور فناوری اطلاعات - IT consultant

۱- مقدمه

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

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

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

۱-۱- هدف

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

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

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

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

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

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

فرآیندهای هر پروژه بسته به متدولوژی و مدل فرآیند انتخابی متفاوت است و ممکن است به نام‌های دیگری مانند «گردش کار[۹]» یا «دیسیپلین[۱۰]» نیز نامیده شود. به‌عنوان‌مثال، متدولوژی CDM اوراکل (گونه کلاسیک) از ۱۱ فرآیند زیر تشکیل شده است:

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

همچنین در متدولوژی، RUP فرآیند زیر (به‌عنوان دیسیپلین) معرفی شده است:

  • مدل‌سازی کسب‌وکار
  • نیازها
  • تحلیل و طراحی
  • پیاده‌سازی
  • آزمون
  • انتقال
  • مدیریت پروژه
  • مدیریت پیکربندی و تغییرات
  • محیط

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

  • تعریف
  • تحلیل
  • طراحی
  • ساخت
  • انتقال
  • تولید

همچنین، هر پروژه نرم‌افزاری مطابق با روش RUP از چهار مرحله زیر تشکیل می‌شود:

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

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

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

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

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

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

۴-۱-۴- V&V: تصدیق و صحه‌گذاری

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

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

مشخصات شناسه

  • ISO-12207 Information technology- Software Lifecycle processes, ISOIEC 12207, 1st Edition, 1999
  • CDM-HND CDM Classic Method Handbook, Oracle Corporation, Release 6.0, 2000
  • CDM-PJT CDM Project Management Process and Task Reference, Oracle Corporation, 1999
  • RUP-DVC RUP Development Case Samples HUGHES-99 Hughes, B. and M. Cotterell, Software Project Management, 2nd Edition, McGraw-Hill, 1999 GOL-PPC
  • شیوه‌نامه برنامه‌ریزی و کنترل پروژه، شرکت مهندسی نرم‌افزاری گلستان، ۱۳۸۲
  • MTD-80 مقایسه متدولوژی‌های ایجاد و توسعه سیستم‌های اطلاعاتی، انتشارات انستیتو ایزایران- ۱۳۸۰

۲- قالب سند توصیف متدولوژی

قالب استاندارد سند توصیف متدولوژی (MDD) در این فصل ارائه می‌شود. در استفاده از قالب استاندارد ارائه شده در این سند باید به نکات زیر توجه نمود:

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

[صفحه روکش]

[تأییدیه]

[تاریخچه]

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

۱- مقدمه

۱-۱- هدف

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

۳-۱- تعاریف

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

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

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

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

۲- کلیات

۱-۲- متدولوژی مرجع*

۲-۲- مدل فرآیند

۳- فرآیندها

۴- مراحل

۵- وظایف

۶- فرآورده‌ها

۷- پیوست‌ها

در این بخش هریک از سرفصل‌های قالب یادشده تشریح می‌گردد.

[صفحه روکش]

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

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

[تأییدیه]

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

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

[تاریخچه]

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

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

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

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

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

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

۱- مقدمه

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

۱-۱- هدف

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

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

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

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

۳-۱- تعاریف

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

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

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

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

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

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

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

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

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

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

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

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

۲- کلیات

مدل فرآیند توسعه باید حداقل شامل بندهای زیر باشد:

۱-۲- متدولوژی مرجع*

درصورتی‌که از یک متدولوژی شناخته‌شده عیناً استفاده می‌شود، فقط نام و شماره نسخه متدولوژی موردنظر باید ذکر شود. درصورتی‌که از یک متدولوژی شناخته‌شده با اعمال تغییراتی استفاده می‌شود، علاوه بر ذکر نام و شماره نسخه متدولوژی موردنظر، تغییراتی که در نسخه اصلی داده شده است نیز باید ذکر شود.

۲-۲- مدل فرآیند

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

۳- فرآیندها

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

  • عنوان
  • هدف: تشریح هدف اصلی از اجرای این فرآیند و ارتباط آن با سایر فرآیندها در زیست چرخ توسعه نرم‌افزار
  • فهرست وظایف*
  • نمودار وابستگی* وظایف وظایفی که در تشریح فرآیندها به آن‌ها اشاره‌شده است، باید در بخش (۵) معرفی شوند.

۴- مراحل

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

  • عنوان
  • هدف: تشریح هدف اصلی از اجرای این مرحله و جایگاه آن در زیست چرخ توسعه نرم‌افزار
  • فهرست فرآیندهایی که در این مرحله اجرا می‌شوند.
  • نمودار وابستگی* فرآیندها
  • مقاطع مهم[۲۶] و نحوه تصمیم‌گیری در مورد گذار به مراحل دیگر

۵- وظایف

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

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

 

[۱] MDD: Methodology Description Document

[۲] Software Development Lifecycle

[۳] Sub-project

[۴] Contractor

[۵] Subcontractor

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

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

[۸] CDM-HND: p.1-5

[۹] Workflow

[۱۰] Discipline

[۱۱] Phase

[۱۲] Inception

[۱۳] Elaboration

[۱۴] Construction

[۱۵] Transition

[۱۶] Task

[۱۷] Document Control

[۱۸] Cover Page

[۱۹] Approval

[۲۰] History

[۲۱] Approval

[۲۲] Hyperlink

[۲۳] Glossary

[۲۴] Abbreviations (Acronyms)

[۲۵] Identification

[۲۶] Milestones

مجید باقری

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

همه مطالب ارسالی توسط: مجید باقری