CMMI

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

موضوع خيلی ساده است: «کيفيت سيستم يا محصول به شدت تحت تأثير فرآيندی است که برای توسعه و نگهداری آن به کار گرفته شده است». انستيتو مهندسی نرم¬افزار دانشگاه کارنگی ملون (CMU-SEI به اختصار SEI) طرح مدلهای بلوغ قابليتها را با اعتقاد به اين اصل شروع کرد. نتيجه آن چندین مدل بلوغ قابليت بود که از سال 1991 به بعد تهيه شدند مانند
• SW-CMM(Software Engineering CMM)
•Systems Engineering CMM (SE-CMM)
•People-CMM
نکته‏ی حائز اهميت آن است که پروژه‏ها تحت تأثير سه عامل (People, Process, Tools) هستند که SEI سعی کرد در حوزه‏های ديگر غير از فرآيند نيز مدلهايی ارائه دهد.
تنوع و تعدد مدلها (علاوه بر مدلهای CMM، مدلهای ديگری نيز در صنعت وجود داشت) باعث بروز مشکلاتی شد که طرح مدل بلوغ قابليتهای يکپارچه Capability Maturity Model Integrated یا به اختصار CMMI، برای حل مشکل مذکور پيشنهاد و از سال 1997 شروع شد واولين نسخه آن در سال 2000 انتشار پيدا کرد.
در حقيقت انگيزه 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مراجعه نماييد.

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