مقدمه‌ای بر CMMI

مقدمه‌ای بر CMMI – ایران ترجمه – Irantarjomeh

مقالات ترجمه شده آماده گروه کامپیوتر

مقالات ترجمه شده آماده کل گروه های دانشگاهی

مقالات

چگونگی سفارش مقاله

الف – پرداخت وجه بحساب وب سایت ایران ترجمه(شماره حساب)ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.comشامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر --مقالات آماده سفارش داده شده پس از تایید به ایمیل شما ارسال خواهند شد.

مقدمه‌ای بر CMMI و رویه  ارزیابی آن

چکیده

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

اغلب گفته می شود که CMMI از سازمانهای نسبتا بزرگ و اداری حمایت می کند و به دلیل  تمرکز بیش از اندازه آن بر یک فرآیند مورد انتقاد است.

CMMI مشابه با ISO/IEC 15504 می‌باشد (که غالبا بعنوان SPICE به آن اشاره می‌شود)، اما به آسانی نمی‌توان آنها را با هم مقایسه کرد. تیم هایی که یک سازمان را انطباق با CMMI ارزیابی می کنند، باید نیاز های زیادی  نظیر تجربه و آموزشهای ویژه را در نظر گیرند. برای روشن شدن اهداف این مقوله، در اینجا دو نمونه از ارزیابی CMMI را ارائه می کنیم.

فهرست

1. مقدمه

۱٫۱     مدل های پردازش و تقویت فرآیند

۲ .  CMMI

۲٫۱       اصول CMMI

۲٫۱٫۱   ساختار CMMI

۲٫۱٫۲     شاخص های CMMI

۲٫۱٫۳   سطوح مهارت

۲٫۱٫۴   سطوح تکامل

• نقد CMM(I)

    ۲٫۲٫۱مطلوب برای موارد بسیار بزرگ

• صرف نظر از بقیه موارد

۳          CMMI و SW-CMM

۳٫۱       تفاوت بین  CMMI و SW-CMM

۳٫۱٫۱  مقررات چندگانه

۳٫۱٫۲  تغییرات ساختاری

۳٫۱٫۳  سطوح تکامل و نواحی پردازشیی

4. CMMI و ISO/IEC 15504(SPICE)

          ۴٫۱       تفاوت های CMMI با ISO/IEC 15504(SPICE)

5. تیم ارزیابی

6. نمونه های ارزیابی CMMI

۶٫۱ ارزیابی یک CMMI برای مهندسین مشاور HNIT توسط دانشجویان دانشگاه ایسلند

۶٫۱٫۱ مدیریت نیازمندی ها

۶٫۱٫۲ اندازه گیری و تحلیل

۶٫۱٫۳ مدیریت پیکربندی(وضعیت)

۶٫۲ ارزیابیهای پایه CMMI برای تست ابزار AVL Graz توسط راهکار KaSSE

مقدمه‌ای بر CMMI

۱- مقدمه

در توسعه نرم افزار، سه مؤلفه اصلی کیفیت یک محصول را تعیین می کنند: افرادی که سیستم نرم افزار را توسعه می‌دهند، تکنولوژی بکار گرفته شده و سازمان فرآیند توسعه.  بر خلاف دو مؤلفه اول – حدودا از ۱۰ سال پیش –  فرآیند توسعه اخیرا با افزایش دائمی اندازه و پیچیدگی پروژه های نرم افزاری خود را به تنهایی به عنوان عامل اصلی نشان داده است. دلیل این امر ممکن است به خاطر این حقیقت باشد که فرآیندهای توسعه، اصولا در ارتباط با مدیریت پشتیبانی پروژه های نرم افزاری است و در نتیجه نمی‌توانند نتایج قابل فهم زیادی در قالب محصولات یا مشابه آن را ایجاد کنند. “نتیجه” یک فرآیند دارای عملکرد خوب تنها ممکن است در صورتی قابل رؤیت باشد که شخص به فرآیند توجهی نداشته باشد. در چنین مواردی، برخی علائم بیماری- هزینه بالا، تأخیر در تحویل و غیره–  ممکن است (که به احتمال زیاد چنین خواهد بود)  در یک پروژه نرم افزاری مشاهده شوند. عامل اضافی دیگری که اهمیت مدیریت فرآیند را پنهان می کند این است که تولید نرم افزار با کیفیت بالا در یک فرآیند بدون مدیریت ، اکیدا غیر ممکن نیست. بر این اساس، این امر تنها به تلاش و مهارت بیشتر از جانب افراد درگیر در فرآیند نیاز دارد.

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

۱-۱٫ مدل های فرآیند و توسعه فرآیند

از آنجائیکه فرآیندهای توسعه، به دلیل آنکه تأثیر زیادی بر کیفیت نرم افزار دارند، هر روز بیشتر مورد پذیرش قرار می گیرند، روش های گوناگونی برای مدلسازی فرآیند ها بوجود آمده و دائما در حال رشد و نمو هستند. بر اساس چنین مدلهایی، بسیاری از سازمان ها در جستجوی ارزیابی فرآیندهای خود هستند و کیفیت نرم افزار خود را با ارتقای اجرای فرآیند افزایش می دهند. به این کار “ارتقای فرآیند” گویند.

در این مقاله به یکی از این دسته از مدلهای پردازش که بنام مدل بلوغ قابلیت (CMM) خوانده می‌شود و مابعد آن CMM مجتمع (CMMI) نگاهی می‌اندازیم. تحت یک توصیف کلی، تعامل بین CMMI و ISO/IEC 15504  را توصیف می کنیم، که عموما    (اما نه اشتباها) به عنوان “SPICE” به آن اشاره می شود. همچنین ارزیابی CMM(I) را با دو مثال نشان خواهیم داد.

مقدمه‌ای بر CMMI

۲– CMMI

CMM توسط انستیتو مهندسی نرم افزار (SEI) در دانشگاه Carnegie Mellon در اواخر دهه ۱۹۸۰ توسعه یافت. این برنامه همراه با SEI همگی توسط دپارتمان دفاعی (DOD) آمریکا پشتیبانی می‌شوند. بنابراین، CMM  (و CMMI) تا حد مشخصی متناسب با نیازها و مطابق با خصوصیات سازمانهای دولتی می‌باشند. این ویژگی در میان خصوصیاتی از CMMI، که اکثرا مورد نقد قرار می گیرند، وجود دارد (بخش ۲٫۲ را ملاحظه کنید).

بر طبق نظر SEI، “یک مدل بلوغ قابلیت (CMM)، مدل مرجعی از رفتارهای تکاملی مقررات مشخص شده است که برای تقویت و ارزیابی مهارت یک گروه جهت اجرای آن مقررات به کار می رود”. از آنجایی که این تعریف خود را به پردازش توسعه نرم افزار محدود نمی کند ممکن است این امر تعجب آور نباشد که بسیاری از CMM های متفاوت برای مقررات دیگری توسعه یابند، مثلا برای مهندسی سیستمها. حتی می‌توان گفت که CMM ها برای فرآیندهای غیر تکنیکی نظیر مدیریت و توسعه نیروهای کاری ایجاد شدند (P-CMM).

از این نقطه، پروژه CMMI در میان اهداف اصلی خود، با ترکیب سه نوع متفاوت از این  CMMها شکل گرفت:  CMM برای نرم افزار (SW-CMM)، استاندارد موقتی اتحادیه صنایع الکترونیک (EIA/IS) (انجمن صنایع الکترونیک) ۷۳۱، و CMM توسعه محصول مجتمع (IPD). هدف دیگر امکان پذیر نمودن امر یکپارچه سازی مدل های آینده بود. (انتظار می رود که این اتفاق با افزودن نواحی پردازشیی جدید رخ دهد). بدلیل این اهداف، CMMI بعنوان یک چارچوب مدلی بوجود آمد که می‌توانست با توجه به مجموعه مقررات انتخاب شده توسط یک سازمان، که با فرض داشتن بیشترین ارتباط با اهداف تجاری آن سازمان انتخاب شده بودند، بصورت پارامتریک نمود یابد. معمولا،۴  قانون در CMMI وجود دارد: مهندسی سیستم ها (SE)، مهندسی نرم افزار(SW)، محصول یکپارچه و توسعه پردازش(IPPD) و منبع یابی پشتیبان(SS). بخش ۳٫۱٫۱ جزئیات بیشتری درباره این قوانین بیان می کند. تمرکز ما بر قانون SW است.

تحت مدل پردازش حقیقی، SEI نسبت به انتشار ماژول اکتساب CMMI اقدام نموده است، گزارشی که “رفتارهای مؤثر و کارآمد را برای پروژه های اکتساب تعیین می کند”   و نیازمندی های ارزیابی CMMI (ARC)، که نیازمندی های ضروری روش های ارزیابی به منظور استفاده در مدل های CMMI را تعیین می‌کند. علاوه بر ARC، یک روش استاندارد ارزیابی CMMI هم برای توسعه پروسه (SCAMPI) که توسط SEI توسعه یافته  بود وجود داشت. البته، SEI دوره های آموزشی مختلفی را عرضه می‌داشت که از «مقدمه ای بر CMMI » تا  «آموزش ارزیاب پیشرو SCAMPI» را در بر داشت.

۱-۲٫ اصول CMMI

زمانیکه CMM در ابتدا توسعه یافته بود، اصول آن با توجه به چهار اصل بیان گردید:

1. توسعه پروسه امکان پذیر است و زمان بر می‌باشد

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

2. بلوغ پردازش از طریق مراحل واضح و جداگانه تعریف می‌شود

این باور به عنوان نتیجه ای از مطالعات گوناگون توسط SEI  طی اواخر دهه ۱۹۸۰ و اوایل دهه ۱۹۹۰ شکل گرفت. در آن زمان، نشان داده شد که در هر مرحله از بلوغ یک پروسه توسعه سازمانی قرار داشته باشد، در آن مرحله نمونه‌هایی از فرآیندهای نرم افزاری به کاربرده شده یافت می‌شود.

3. …

۱-۱-۲٫ ساختار CMMI

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

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

۲-۱-۲٫ شاخص‌های CMMI

هر مدل CMMI به دو حالت متفاوت ایجاد می شود: شاخص مداوم و شاخص مرحله‌ای. هر دو شاخص، ۲۵ ناحیه پردازشی  را به مجموعه های واضح گروه بندی می‌کنند (۴ مورد در حالت شاخص مداوم و ۵ مورد در شاخص مرحله ای).

شاخص مداوم تنها یکی از ۶ سطح مهارت را برای هر ناحیه پردازشی  به کار می گیرد. فرآیند توسعه را تنها به عنوان یک واحد درجه بندی نمی‌کنند. سطوح مهارت در بخش ۲٫۱٫۳ توضیح داده می شود.

گروه های ناحیه پردازشی زیر (آنها را بعنوان دسته‌بندیهای داخل مدلها می‌نامند) در شاخص مداوم به کار می روند:

• مدیریت پردازش؛عبارت است از :

• تمرکز سازمانی(OF)

• تعیین فرآیند سازمانی(OPD)

• آموزش سازمانی(OT)

• اجرای فرآیند سازمانی(OPP)

• آرایش و بدعت سازمانی(OID)

• مدیریت پروژه؛عبارت است از:

• برنامه ریزی پروژه(PP)

• کنترل و نظارت پروژه(PMO)

• مدیریت توافق حامی(SMA)

• مدیریت پروژه یکپارچه(IPM)

• مدیریت خطر(RIM)

• تشکیل تیم مجتمع (IT)

• مدیریت حامی مجتمع(ISM)

• مدیریت پروژه کمیتی (QPM)

• مهندسی؛عبارت است از :

• مدیریت نیازمندی ها(REQM)

• توسعه نیازمندی ها(RD)

• راه حل تکنیکی(TS)

• یکپارچه سازی محصول(PI)

• رسیدگی (تصدیق)(Ve)

• ارزیابی (Va)

  • پشتیبانی؛عبارت است از:

  • مدیریت پیکربندی(CM)

  • تضمین کیفیت محصول و فرآیند(PPQA)

  • بررسی و اندازه گیری(MA)

  • تحلیل و تجزیه تصمیم (DAR)

  • محیط سازمانی برای مجتمع سازی(OEI)

  • تحلیل و تجزیه تصادفی (CAR)

از طرف دیگر در شاخص مرحله ای، CMMIنواحی پردازشی را به ترتیب سطح تکامل به ۵ زیر مرحله تقسیم می کند. زمانی که تمام نواحی پردازشی یک سطح و تمام سطوح زیرین بر یک سطح مهارت کمینه مشخص قرار دارند، انتظار می رود فرآیند نرم افزاری یک سازمان به سطح تکامل مطلوب برسد.

مقدمه‌ای بر CMMI

۳-۱-۲٫ سطوح مهارت و توانایی

یک سطح مهارت، مجموعه ای از رفتار هایی که باید برای یک ناحیه پردازشی مشخص اجرا شوند را تعیین می کند، تا بدینوسیله به سطح مهارت مطلوب دسترسی حاصل شود. در بسیاری از موارد این موضوع بدین معنی است که برخی اهداف برای مهارت خاصی تعیین شده اند و تمام رفتارهای مربوط به این هدف باید اجرا شوند. اما گاهی اوقات، یک هدف خاص رفتار وابسته ای دارد که بنام ” رفتار پیشرفته” خوانده می شود. چنین رفتارهایی تنها برای رسیدن به سطوح بالاتر مهارت مورد نیاز هستند.در مثال استفاده شده از REQM، اهداف ۲ و ۴ رفتارهای پیشرفته هستند و برای سطح ۲ مهارت مورد نیازند. بقیه تنها برای رسیدن به سطح ۱ مورد نیاز هستند.

برای هر سطح مهارت غیر بدیهی، یک سطح کلی وجود دارد که باید برای سطح مهارت مطلوب به دست آید. اهداف کلی (و رفتارهای مطلوب) هر سطح مهارت برای تمام ۲۵ ناحیه پردازشی  یکسان می‌باشند. اهداف خاص تنها برای سطح ۱ مورد نیازند (اما به خاطر داشته باشید که ممکن است رفتارهای خاصی مورد نیاز سطوح بالاتر وجود داشته باشند).

شش سطح مهارت به کاربرده شده در شاخص توالی عبارتند از :

1. نا تمام

هر ناحیه پردازشی  که اجرا نشده باشد ناتمام به حساب می آید.

1. اجرا شده

قرارداشتن در سطح اجرا شده یعنی آن که اهداف خاص نواحی پردازشی بدست می آیند .هدف کلی این سطح مهارت “بدست آوردن اهداف خاص” می‌باشد، که یک رفتار عمومی تنها آن را دارد “اجرای رفتارهای پایه”. (یک “رفتار پایه” رفتار خاصی است که برای سطح ۱ مورد نیاز است.)

۲- مدیریت شده

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

3. تعریف شده

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

4. مدیریت کمی

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

5. بهینه سازی

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

۴-۱-۲٫ سطوح تکامل یا بلوغ

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

۲-۲٫ نقد  (CMM(I

مانند تمامی دیگر متدولوژیها یا روشها ایجاد نرم افزار، CMM و CMMI هم مورد نقد و انتقاد قرار می گیرند. از میان خصوصیت هایی که مورد انتقاد قرار گرفته اند، دو مورد برجسته تر می‌باشد:

• به نظر می رسد CMM(I) برای سازمان های بزرگ و اداری استفاده شود

• تأکید شدید CMM(I) بر فرآیند

 اکنون به این موضوعات می پردازیم.

۱-۲-۲٫  انتفاع موسسات بسیار بزرگ

نکته اولیه مورد انتقاد به احتمال زیاد ناشی از این حقیقت است که SEI مورد حمایت وزارت دفاع آمریکا قرار گرفت.سازمان های دولتی با خاصیت بزرگ بودن، دارای ساختارهای اداری، بوجود آمده از مفاد بالا می‌باشند. (علاوه بر آن، بسیاری از انتقادات اغلب دارای حس سوء‌ظن نسبت به “دولت” می باشد.) اغلب چنین خصوصیاتی در سازمان های بزرگی نظیر شرکت های چند ملیتی یا انحصاری دیده می شوند.خصوصیت رایج دیگر در میان چنین سازمان هایی این است که آنها اکثر با مشتریان تجاری سر و کار دارند – یعنی دیگر شرکت ها یا سازمان های بزرگ مشابه. در یک چنین مجموعه ای اغلب کمبود زمان برای فروش هم وجود دارد.

۲-۲-۲٫ صرف نظر از بقیه موارد

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

 از آنجایی که ضمانت های محکم به سختی در هر شرایطی پا برجا باقی می‌مانند، باید از این موضوع متشکر بود که ” CMM قصد نداشت برای همه افراد همه چیز باشد یا تمام جنبه های ممکن توسعه سیستم و نرم افزار را تحت پوشش قرار دهد”. CMMIبه طور سنجیده بر فرآیند تمرکز می کند و افراد و تکنولوژی را حذف می کند. بنابراین، بیشتر یا کمتر از یک سوم توسعه نرم افزار را پوشش نمی دهد – و ادعا نمی کند که بیش از این را انجام می دهد. البته باید علاوه بر مدیریت فرآیند صرف، به افراد و تکنولوژی هم توجه شود. اما اجرای CMM(I) به طور قابل توجهی احتمال موفقیت در فرآیند نرم افزاری را افزایش می دهد.

مقدمه‌ای بر CMMI

۳- CMMI  و SW-CMM

در سال ۲۰۰۰،  SW-CMM به CMMI ارتقاء یافت. SEI دیگر مدل SW-CMM را پشتیبانی نمی‌کند. همانطور که تاکنون اشاره شد، پروژه CMMI برای ایجاد چارچوبی مناسب جهت بسط مدل های فعلی و آتی  و ساخت مجموعه‌های اولیه از مدل های جامع شکل گرفت، چرا که مدل های قدیمی CMM :

• تداخل و تناقص داشتند

• اصطلاحات، قالب ها ، ساختار ها و شیوه های اندازه گیری متفاوتی داشتند

• موجب سردرگمی می شدند، خصوصا زمانیکه بیش از یکی همزمان مورد استفاده قرار می گرفتند

• جامعیت و یکپارچه‌سازی آنها به یک برنامه پیشرفت ترکیب شده دشوار بود

• استفاده آن در انتخاب مربوط به تامین کننده و قرارداد های فرعی دشوار بود

۱-۳٫ تفاوت های بین CMMI  و SW-CMM

بدیهی است، مقایسه CMMI  و SW-CMM به طور کلی اهمیتی ندارد، زیرا CMMI بیش از یک مدل تکاملی برای توسعه نرم افزار است. اما مقایسه بر حسب مهندسی SW قابل قبول است. بنابراین لازم است تا یک طرح مختصر از آنچه طی انتقال از CMMI  و SW-CMM تغییر کرده است را نشان دهیم.

۱-۱-۳٫ مقررات چندگانه

بدیهی ترین تغییر این است که CMMI مقررات چندگانه را تحت پوشش قرار می‌دهد. معمولا CMMI 4 قانون یا مقررات را بررسی می کند که به صورت زیر توصیف شده اند:

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

۳-۱-۳٫ سطوح تکامل و نواحی پردازشی

سطوح تکامل CMMI به شیوه مدل های قبلی تعریف می شوند، اگر چه تغییراتی در نام سطوح ایجاد شده است. سطوح ۱،۳ و ۵ نام خود را حفظ کرده‌اند، یعنی شروع، تعریف شده و بهینه سازی ، اما سطوح ۲ و ۴  از نظر نام و بصورت کمی مدیریت شده‌اند، که شاید برای تأکید بیشتر بر تکامل فرآیند های مدیریت از تمرکز کیفی به تمرکز کمی باشد.

CMMI شامل ۲۵ ناحیه پردازشی  برای ۴ اصل تحت پوشش می باشد (شکل ۲ را ببینید). در مقایسه، SW-CMM شامل ۱۸ ناحیه پردازشی می‌باشد. اگرچه بسیاری از نواحی پردازشی موجود در CMMI لزوما شبیه همتاهای خود در SW-CMM هستند، برخی از آنها تغییرات قابل توجهی در طرح و هدف را بازتاب داده و مابقی، فرآیند هایی را پوشش می دهند که قبلا به آنها اشاره نشده است.

۴- CMMI و ISO/IEC 15504 (SPICE)

برای توسعه استاندارد ISO/IEC 15504  لازم است از متخصصان بین المللی در این فرآیند استفاده شود. در نتیجه پروژه SPICE با دستور توسعه اولین پیش نویس استاندارد (و تحویل به گروه کاری ISO) و هدایت بررسیهای کاربر در زمینه استاندارد نوظهور و در حال توسعه، قبل از انتشار، آغاز بکار نمود.

پروژه SPICE  به طور رسمی در سال ۲۰۰۳ بسته شد و جایگزین شبکه SPICE گردید که در آن گروه کاربری SPICE آن را میزبانی می‌نمودند. این سیستم اخیرا به استاندارد تحت عنوانISO/IEC 15504 (SPICE) ، استاندارد مربوط به SPICE نامیده می‌شود، البته اغلب به  ISO /IEC 15504  به اشتباه به عنوان SPICE  اشاره می شود. تلاش در جهت مشارکت بین المللی برای توسعه یک استاندارد از سال ۱۹۹۰ (به طور غیر رسمی) و از ژانویه ۱۹۹۳، بطور رسمی، در دست اقدام قرار گرفت.

۱-۴٫ تفاوت های بین CMMI  و ISO/IEC 15504 (SPICE)

در این بخش تفاوت های اصلی بین CMMI  و ISO/IEC 15504 (SPICE) به طور خلاصه بیان می شوند.این تفاوت ها عبارتند از :

نواحی پردازشی

جدول ۱ خلاصه ای از دسته های پردازشی موجود در CMMI  و ISO/IEC 15504 (SPICE) را ارائه می کند.

فرآیند ها

چند فرآیند در ISO/IEC 15504 وجود دارد که معادل مستقیمی در CMMI ندارد. این فرایند ها عبارتند از:

• ۴ (فرآیند عملیاتی)

• ۷ (فرآیند بازبینی)

• ۱ (فرآیند مدیریت)

• ۴ (فرآیند زیربنایی)

• ۶ (فرآیند استفاده مجدد)

شاخص

بر خلاف CMMI، ISO/IEC 15504 تنها یک شاخص ارائه می دهد– یک شاخص مداوم .

توان سازمانی

در CMMI ، توان سازمانی به طور صریح  برحسب سطوح تکامل توصیف شده است. این موضوع در مورد ISO/IEC 15504 صدق نمی کند، زیرا ISO/IEC 15504 یک شاخص مداوم را ارائه می کند (و در نتیجه بر فرآیند ها تمرکز می‌کند). در ISO/IEC 15504، توان سازمانی ضمنی است؛ می توان آن را مستقیما با توجه به فرآیند های سازمانی، خصوصیات فرآیند و وابستگی هایشان درک کرد.

نقش ارزیاب پیشرو

CMMI به شدت به ارزیاب یا سنجشگر پیشرو و راهنما وابسته است، زیرا تفاوت زیادی بین سنجشگر راهنما و دیگر  اعضای تیم در ISO/IEC 15504 وجود ندارد. در CMMI تمام مسئولیت کیفیت، درستی، اجرا و غیره  با سنجشگر راهنما برابر است. در ISO/IEC 15504 هر یک از اعضای تیم مسئول دسته خویش است.

مقدمه‌ای بر CMMI

۵- تیم ارزیابی

شرایط ارزیاب یا سنجشگر راهنما

• آموزش مقدماتی CMMI

• تجربه تیم ارزیابی

• آموزش پیشرفته CMMI

• آموزش سنجشگرراهنمای SCAMPI یا آموزش افزایش یافته (برای سنجشگر های راهنمای رایج)

تیم ارزیابی باید شرایط خاصی هم برای بدست آوردن نتایج  بهتر داشته باشد:

• اعضای تیم ارزیابی باید تجارت و سازمانی که در آن قراردارد را بشناسند و علاقمند باشند که سازمان نسبت به بهبود فرآیند های خود اقدام نماید.

• اعضای تیم ارزیابی باید یک پیش زمینه اساسی از مهندسی نرم افزاری داشته باشد، ترجیحا با حداقل ۱۰ سال تجربه در نرم افزار، و نه کمتر از ۵ سال.

• کل زمان چرخه حیات نرم افزار باید تحت پوشش تجربه جمعی تیم ارزیابی کننده باشد.

• یکی از اعضای تیم باید حداقل ۶ سال تجربه مدیریت داشته باشند. یک تیم به طور کلی باید حداقل ۱۵ سال تجربه مدیریت داشته باشد.

• برخی از اعضای تیم ارزیابی سازمانی باید به درستی فرهنگ سازمان را بشناسند.

• حداقل یکی از اعضای تیم باید دسترسی آسانی به تیم مدیریت ارشد سازمان داشته باشد.

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

• تیم ارزیابی باید شامل اعضایی باشد که با مفاهیم موجود در تضمین کیفیت و مدیریت پیکربندی سیستم آشنا باشند.

• برخی از اعضای تیم ارزیابی باید در ارزیابی تجربه داشته باشند

• سازمان باید به مهارت ها و اختیارات اعضای تیم ارزیابی سازمانی احترام بگذارد.

• هر عضو تیم ارزیابی باید بخواهد و بتواند با یک تیم ارزیابی کار کند

• تمام اعضای تیم ارزیابی باید مهارت های انسانی خوبی داشته باشند و باید مصاحبه را به صورت غیر تهدید آمیز هدایت کنند.

• حداقل یکی از اعضای تیم سازمانی باید تجربه و مهارت بالایی در ارائه آن  به مدیریت ارشد داشته باشد

• حضور یک عضو تیم ارزیابی در تیم ارزیابی نباید موجب شود تا شخصی که مورد مصاحبه قرار گرفته،نتواند به راحتی در مورد موضوعات فرآیند صحبت کند

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

مقدمه‌ای بر CMMI

۶- نمونه هایی از ارزیابی CMMI

اکنون فرآیند ارزیابی CMMI را با چند مثال نشان می دهیم.

۱-۶٫ ارزیابی یک CMMI برای مهندسان مشاور HNIT توسط دانشجویان دانشگاه ایسلند

ارزیابی CMMI که در این بخش نشان داده شده در فوریه ۲۰۰۵ توسط Guðlaugur Kr. JörundSSon ، Sveinbjörn GuðmundSSon و Martin Höggerl برای درس مدیریت کیفیت نرم افزاری در دانشگاه ایسلند انجام گرفت. واحد سازمان (OU) انتخاب شده، اداره نرم افزار مهندسان مشاور HNIT در Reykjavík ،ایسلند بود. سه ناحیه پردازشی  تعیین شدند:

• مدیریت نیازمندی ها (REQM)

• تحلیل و ارزیابی (MA)

• مدیریت وضعیت(CM)

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

۱-۱-۶٫ مدیریت نیازمندی ها

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

شواهد :

• آنها مدارکی ارائه کردند مبنی بر اینکه چگونه با مشتریان خود با هم کار می کردند تا نیازمندی ها را بشناسند.

مضمون :

• OU به جمع آوری اطلاعات درباره تغییرات مورد نیاز و ناسازگاری های بحرانی بین کار پروژه و نیازمندی ها می پردازد.

• آنها همچنین تلاش کردند که قابلیت ردیابی دو سویه نیازمندی ها را حفظ کنند. بنابراین، رتبه REQM حداقل بر سطح ۱ مهارت قرار گرفت.

نتایج :

• REQM به خوبی مدیریت شده است و اگر به خاطر کمبود برنامه آموزشی مدیریت شده برای مردم نبود، AT می‌توانست REQM را برای رسیدن به هدف فرآیند مدیریت شده ارزیابی کند.

• OU فرآیند REQM را تعریف کرده است. فرآیند مورد نظر در کتاب راهنمای مدیریت کیفیت از HNIT تعریف شده است.

• توصیه های کارمندان در این درباره برای ارتقای فرآیندها جمع آوری شده اند. هدف فرآیند تعریف شده بدست می آید.

• از آنجایی که هدف فرآیند توصیه شده کاملا بدست نیامده است، سطح مهارت REQM تنها بر سطح ۱ قرار دارد. بهبود آموزش افراد آن را به سطح ۳ افزایش می دهد.

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

۲-۱-۶٫  ارزیابی و تحلیل

ناحیه پردازشی MA سخت ترین مرحله بود، نه از نظر زمان یا شناخت، بلکه از نظر برداشت های نادرست و بحث های شدید.

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

شواهد و مدارک:

مسئله مهم این بود که، تیم ارزیابی نتوانست ، به دو دلیل، بخش زیادی از یک مدرک مربوط به  این ناحیه پردازشی  را مشاهده کند :

• کمبود زمان.حتی اگر مدارک زیادی هم وجود داشت، تیم ارزیابی زمان زیادی برای رسیدگی به آنها را نداشت.

• OU ، مستند سازی زیادی برای ارائه نداشت.

مضمون :

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

• قانون مشابهی برای هزینه یک پروژه استفاده می شود. اگر افزایش هزینه %۲۰ یا بیشتر باشد، این موضوع هم باید به مدیریت ابلاغ شود.

نتایج :

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

• در پایان، برای رسیدن به سطح ۱ کمبود زیادی نبود.

• در یک شرکت نسبتا کوچک ، می توان راهبردها را بدون مستند سازی و تعریف آنها و تنها با صحبت کردن با کارمندان حفظ کرد.

۳-۱-۶٫ مدیریت وضعیت

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

مدارک و شواهد :

• هیچ .

مضمون :

• هیچ

نتایج  :

• در پایان نتیجه این شد که حتی اگر OU از چندین ابزار CM نظیر محافظ نصب و امنیت منبع استفاده می کرد، ارزیابی کنندگان نمی‌توانستند تمام ناحیه پردازشی  را ارزیابی کنند.

۲-۶٫ ارزیابی های مبنی بر CMMI برای سیستم های تست ابزار Graz  AVL توسط  راهکار   KaSSE

 درباره تیم ارزیابی

• ارزیابی کننده بعنوان یک مشاور مدیرفعالیت می‌نمود

• هماهنگ کننده تیم ارزیابی برای هر ۵ سایت یکسان بود

• اعضای تیم ارزیابی اضافی در ابتدا از طریق پیشرفت فرآیند یا تمرکز و علاقه بر شغل مدیریت انتخاب شدند.

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

• تمام مکان های تجاری AVL ، دارای اعضای اصلی تیم ارزیابی بودند که  در معرفی SEI به CMMI شرکت داشتند

هر واحد تجاری AVL که در ابتدا برای یک ارزیابی برنامه ریزی شده مشخص شده بودند، خلاصه‌ای از اطلاعات مربوط به پیشرفت مرتبط با یک فرآیند را  ارائه کرده بودند (مهندسی نرم افزار،SPI، CMMI، …).

هر واحد تجاری باید پرسشنامه هایی را پرکند، به طور مثال درباره شرکت، درباره آمادگی برای تغییرات برخی از موارد، درباره ساختار سازمانی و درباره فرآیند های مستند سازی شده. راهکار KaSSE مرور آنلاین فرآیند های مستند سازی شده را پیشنهاد می کند.” مالکان فرآیند ” یا حداقل توسعه دهندگان مدیریت فرآیند باید ناحیه پردازشی  خاصی  را ارائه یا حداقل آن را بررسی کنند. درخواست های رایج هنگام مرور فرآیند های مستند سازی شده عبارتند از :

• لطفا مطلبی را توضیح داده یا آن را روشن کنید.

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

• لطفا مثال هایی از پروژه را نشان دهید که آن رویه را دنبال کرده باشد یا از آن الگو استفاده کرده باشد.

• چرا این اطلاعات در این سند گذاشته شده نه در سند دیگری، با ارتباط با همترازی با روش CMMI .

• لطفا نسخه ای از آن بخش رویه را چاپ بگیرید یا لطفا همه رویه را چاپ کنید.

بر اساس راهکار KaSSE ،یک چنین مرور آنلاینی چندین فایده دارد :

• زمان مورد نیاز برای مشاهده دقیق فرآیند های مستند شده را کاهش می دهد

• کسانی که فرآیند را ارائه می کنند متخصص در زمینه ارائه ایده‌های مهم در چارچوب مستندات می‌باشد.

• هر موضوع را می توان با اندکی اتلاف زمان دوباره بازبینی کرد

• پیگیری رویه ها، راهبردها، الگو ها و لیست های موارد مورد بررسی سریع انجام می‌شود.

• اگر رتبه بندی آن یکی از اهداف ارزیابی باشد، از این طریق سریع تر انجام می شود

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

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

ایده انتخاب شده توسط راهکار KaSSE  جهت ارائه نتایج این ارزیابی های مبنی بر CMMI عبارتند از :

• ارائه اهداف ارزیابی

• ارائه محدوده ارزیابی

• خلاصه اجرایی شامل نواحی پردازشی قوی، نواحی پردازشی ضعیف و نماد عمومی رضایت از تمارین کلی

• شاخص فعالیت های عمومی برای مجموعه‌ای از نواحی پردازشی دنبال شده

• شاخص نواحی پردازشی بر حسب نقاط مثبت، ضعف ها، نتایج تجاری و پیشنهادات

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