क्षमता परिपक्वता मॉडल (सीएमएम) और सॉफ्टवेयर इंजीनियरिंग में इसके स्तर
सीएमएम क्या है?
क्षमता परिपक्वता मॉडल का उपयोग किसी संगठन की सॉफ्टवेयर प्रक्रिया की परिपक्वता को मापने के लिए एक बेंचमार्क के रूप में किया जाता है।
सीएमएम को 80 के दशक के अंत में सॉफ्टवेयर इंजीनियरिंग संस्थान में विकसित किया गया था। इसे उपठेकेदारों के काम का मूल्यांकन करने के तरीके के रूप में अमेरिकी वायु सेना द्वारा वित्तपोषित एक अध्ययन के परिणामस्वरूप विकसित किया गया था। Later सॉफ्टवेयर विकास की परिपक्वता का आकलन करने के लिए 1991 में बनाए गए CMM-SW मॉडल के आधार पर, कई अन्य मॉडलों को CMM-I के साथ एकीकृत किया गया है।
क्षमता परिपक्वता मॉडल (सीएमएम) स्तर क्या है?
- प्रारंभिक
- दोहराने योग्य/प्रबंधित
- परिभाषित
- मात्रात्मक रूप से प्रबंधित
- अनुकूलन
सीएमएम के विभिन्न स्तरों पर क्या होता है?
स्तर | क्रियाएँ | फ़ायदे |
---|---|---|
स्तर 1 प्रारंभिक |
|
कोई नहीं। परियोजना पूरी तरह से अराजकतापूर्ण है |
स्तर 2 प्रबंधित |
|
|
स्तर-3 परिभाषित |
|
|
स्तर-4 मात्रात्मक रूप से प्रबंधित |
|
|
स्तर-5 अनुकूलन |
|
|
निम्नलिखित आरेख, विभिन्न CMM स्तर पर क्या होता है इसका एक सचित्र प्रतिनिधित्व देता है
सीएमएम को लागू करने में कितना समय लगता है?
किसी भी सॉफ्टवेयर विकास कंपनी के लिए उत्पाद की गुणवत्ता बनाए रखने के लिए सीएमएम सबसे वांछनीय प्रक्रिया है, लेकिन इसके कार्यान्वयन में अपेक्षा से थोड़ा अधिक समय लगता है।
- सीएमएम का क्रियान्वयन रातोरात नहीं होता
- यह महज एक “कागजी कार्रवाई” नहीं है।
- कार्यान्वयन के लिए सामान्य समय है
- 3 - 6 महीने -> तैयारी के लिए
- 6 - 12 महीने -> कार्यान्वयन के लिए
- 3 महीने -> मूल्यांकन की तैयारी के लिए
- 12 महीने ->प्रत्येक नए स्तर के लिए
सीएमएम की आंतरिक संरचना
सीएमएम में प्रत्येक स्तर को परिभाषित किया गया है मुख्य प्रक्रिया क्षेत्र या केपीए, स्तर-1 को छोड़कर। प्रत्येक KPA संबंधित गतिविधियों के एक समूह को परिभाषित करता है, जिसे सामूहिक रूप से निष्पादित करने पर सॉफ़्टवेयर क्षमता में सुधार के लिए महत्वपूर्ण माने जाने वाले लक्ष्यों का एक सेट प्राप्त होता है
विभिन्न सीएमएम स्तरों के लिए, केपीए का एक सेट होता है, उदाहरण के लिए सीएमएम मॉडल-2 के लिए, केपीए हैं
- REQM- आवश्यकता प्रबंधन
- पीपी- परियोजना नियोजन
- पीएमसी- परियोजना निगरानी और नियंत्रण
- एसएएम- आपूर्तिकर्ता अनुबंध प्रबंधन
- पीपीक्यूए-प्रक्रिया और गुणवत्ता आश्वासन
- सीएम-कॉन्फ़िगरेशन प्रबंधन
इसी तरह, अन्य CMM मॉडल के लिए, आपके पास विशिष्ट KPA हैं। यह जानने के लिए कि KPA का कार्यान्वयन प्रभावी, स्थायी और दोहराने योग्य है या नहीं, इसे निम्नलिखित आधार पर मैप किया जाता है
- प्रदर्शन के प्रति प्रतिबद्धता
- प्रदर्शन करने की क्षमता
- गतिविधियाँ निष्पादित करें
- मापन और विश्लेषण
- कार्यान्वयन का सत्यापन
सीएमएम मॉडल की सीमाएँ
- सीएमएम यह निर्धारित करता है कि किसी प्रक्रिया को किस प्रकार कार्यान्वित किया जाना चाहिए, न कि यह कि उसे किस प्रकार कार्यान्वित किया जाना चाहिए
- यह सॉफ्टवेयर प्रक्रिया सुधार की हर संभावना की व्याख्या नहीं करता है
- यह सॉफ्टवेयर मुद्दों पर ध्यान केंद्रित करता है लेकिन रणनीतिक व्यापार योजना, प्रौद्योगिकियों को अपनाने, उत्पाद लाइन की स्थापना और मानव संसाधन प्रबंधन पर विचार नहीं करता है
- यह नहीं बताया गया है कि किसी संगठन को किस प्रकार का व्यवसाय करना चाहिए
- सीएमएम इस समय संकटग्रस्त परियोजना में उपयोगी नहीं होगा
सीएमएम का उपयोग क्यों करें?
आज CMM सॉफ्टवेयर उद्योग में "स्वीकृति की मुहर" के रूप में कार्य करता है। यह सॉफ्टवेयर की गुणवत्ता को बेहतर बनाने में विभिन्न तरीकों से मदद करता है।
- यह दोहराए जाने योग्य मानक प्रक्रिया की ओर मार्गदर्शन करता है और इस प्रकार काम कैसे किया जाए, इस बारे में सीखने का समय कम करता है
- सीएमएम का अभ्यास करने का अर्थ है विकास के लिए मानक प्रोटोकॉल का अभ्यास करना, जिसका अर्थ है कि यह न केवल टीम को समय बचाने में मदद करता है बल्कि यह भी स्पष्ट दृष्टिकोण देता है कि क्या करना है और क्या अपेक्षा करनी है
- गुणवत्तापूर्ण गतिविधियाँ परियोजना के साथ अच्छी तरह से मेल खाती हैं, न कि एक अलग घटना के रूप में सोची जाती हैं
- यह परियोजना और टीम के बीच एक संयोजक के रूप में कार्य करता है
- सीएमएम का प्रयास हमेशा प्रक्रिया में सुधार की ओर रहता है
सारांश
सीएमएम को पहली बार 80 के दशक के अंत में अमेरिकी वायु सेना में उपठेकेदारों के काम का मूल्यांकन करने के लिए पेश किया गया था। Later उन्नत संस्करण के साथ, इसे सॉफ्टवेयर विकास प्रणाली की गुणवत्ता पर नज़र रखने के लिए लागू किया गया था।
संपूर्ण सीएमएम स्तर को पांच स्तरों में विभाजित किया गया है।
- स्तर 1 (प्रारंभिक): जहां सिस्टम के लिए आवश्यकताएं आमतौर पर अनिश्चित, गलत समझी गई और अनियंत्रित होती हैं। प्रक्रिया आमतौर पर अव्यवस्थित और तदर्थ होती है।
- स्तर 2 (प्रबंधित): परियोजना लागत, शेड्यूल और कार्यक्षमता का अनुमान लगाएं। सॉफ्टवेयर मानक परिभाषित किए गए हैं
- स्तर 3 (परिभाषित): यह सुनिश्चित करता है कि उत्पाद आवश्यकताओं और इच्छित उपयोग को पूरा करता है
- स्तर 4 (मात्रात्मक रूप से प्रबंधित): परियोजना की प्रक्रियाओं और उप-प्रक्रियाओं को सांख्यिकीय रूप से प्रबंधित करता है
- स्तर 5 (परिपक्वता): आवश्यकताओं और व्यावसायिक उद्देश्यों को पूरा करने के लिए नए उपकरणों और प्रक्रिया सुधारों की पहचान करना और उन्हें लागू करना