CMMI

از هفته دیگر دوره Rational Unified Process در شرکت فراتر از دانش شروع می‏شود. یکی از موضوعاتی که می‏خواهم تأکید بیشتری روی آن داشته باشم، CMMI است. این امر بهانه‏ای شد تا در این مورد مطلبی بنویسم که در ادامه آمده است.

موضوع خیلی ساده است: «کیفیت سیستم یا محصول به شدت تحت تأثیر فرآیندی است که برای توسعه و نگهداری آن به کار گرفته شده است». انستیتو مهندسی نرم¬افزار دانشگاه کارنگی ملون (CMU-SEI به اختصار SEI) طرح مدلهای بلوغ قابلیتها را با اعتقاد به این اصل شروع کرد. نتیجه آن چندین مدل بلوغ قابلیت بود که از سال ۱۹۹۱ به بعد تهیه شدند مانند
• SW-CMM(Software Engineering CMM)
•Systems Engineering CMM (SE-CMM)
•People-CMM
نکته‏ی حائز اهمیت آن است که پروژه‏ها تحت تأثیر سه عامل (People, Process, Tools) هستند که SEI سعی کرد در حوزه‏های دیگر غیر از فرآیند نیز مدلهایی ارائه دهد.
تنوع و تعدد مدلها (علاوه بر مدلهای CMM، مدلهای دیگری نیز در صنعت وجود داشت) باعث بروز مشکلاتی شد که طرح مدل بلوغ قابلیتهای یکپارچه Capability Maturity Model Integrated یا به اختصار CMMI، برای حل مشکل مذکور پیشنهاد و از سال ۱۹۹۷ شروع شد واولین نسخه آن در سال ۲۰۰۰ انتشار پیدا کرد.
در حقیقت انگیزه SEI از توسعه CMMI ارائه مدل بلوغ قابلیتی برای پوشش کارهای مرتبط با توسعه و نگهداری محصول و سرویس که شامل حوزه‏های زیر بوده و قابلیت گسترش به حوزه‏های جدید را نیز داشته باشد، بود.
-مهندسی سیستم(Systems engineering)
-مهندسی نرم‏افزار(Software engineering)
-توسعه محصول و فرآیند یکپارچه (Integrated product and process development)
-تأمین منابع (Supplier sourcing)
صرف نظر از این که مدل ارائه شده از دیدگاه تخصصی چه ویژگی‏هایی دارد، چارچوبی را برای بهبود فرآیند توسعه و نگهداری محصول و سرویس در سازمانها ارائه می‏دهد. به عنوان مثال یکی از حوزه‏های فرآیندی که باید برای بهبود سازمان در نظر گرفت مدیریت پیکربندی (Configuration Management) است که مفید است اگر تعریف آن را با هم مرور کنیم.
هدف:
هدف از مدیریتپیکربندی، شناسایی، کنترل و ممیزی محصولات کاری و نگهداری یکپارچگی آنها است.
از جمله محصولات کاری می‏توان به موارد زیر اشاره کرد:
•طرحها (Plans)
•نیازمندی‏ها (Requirements)
•کدهای برنامه (Code)
•طراحی‏ها (Design)
برای روشن شدن کاربرد، اجازه بدهید مثالی عرض کنم. فرض کنید که قرار است نامه‏ای برای یکی از مشتریان ارسال شود. ابتدا نامه توسط کارشناس، تهیه، سپس توسط مدیر عامل تأیید و سپس توسط مسئول دفتر مدیریت، ویراستاری، ثبت و پرینت می‏گردد. واضح است که نامه بین مدیر، کارشناس و مسئول دفترمدیریت چندین بار جابه‏جا گردیده تا به نسخه نهایی تبدیل گردد. از طرف دیگر پس از ارسال نباید تغییر کند. آیا نسخه¬های بینابینی (نسخه‏هایی که بین مدیر، کارشناس و مسئول دفتر جابه‏جا شده است)، باید نگهداری گردد(شناسایی و تعیین اقلام پیکربندی). در صورتی که جواب مثبت است، چگونه این کار را انجام دهیم؟ چه کسانی مسئول کار باشند؟ (فرآیند پیکربندی) چه کسانی حق دسترسی به نامه پس از ارسال یا نسخه‏های میانی را داشته باشد (ضوابط فرآیند پیکربندی).
سئوال مهم‏تر این است که آیا چارچوبی برای مشخص کردن نیازهای یک سازمان یا پروژه برای نگهداری اقلام تحت کنترل (اقلام پیکربندی) وجود دارد؟ آیا مرجعی بری کارهایی که باید انجام دهیم تا اقلام پروژه تحت کنترل باشند، وجود دارد؟ یکی از جوابها و مراجع معتبر، CMMI و حوزه فرآیندی Configuration Management آن است.

توجه داشته باشید کهCMMI تنها یک مدل است و نه راهکار اجرایی. بلکه باید متناسب با هر سازمان، پیاده‏سازی و عملیاتی گردد.
پرواضح است که بیان تمامی ابعاد و کاربردهای CMMI در اینجا میسر نیست، لذا توصیه می‏شود برای اطلاعات به آدرس http://www.sei.cmu.edu/cmmiمراجعه نمایید.

گزیده:
لغت نامه مهندسین در جلسات کارفرما
کاملا انجام شده یعنى: راجع به ۱۰ درصد کار تنها برنامه ریزى شده !
تمام انتخاب اولیه به کنار گذاشته شد. یعنى: تنها فردى که این موضوع را مى فهمید از تیم خارج شده است!
روى چند انتخاب بطور همزمان در حال کار هستیم. یعنى: هنوز تصمیم نگرفته ایم چه کنیم!