क्षमता परिपक्वता मॉडल

From Vigyanwiki
Revision as of 13:40, 11 July 2023 by alpha>Arnikapal

क्षमता परिपक्वता मॉडल (CMM) एक विकास मॉडल है जिसे 1986 में अमेरिकी रक्षा विभाग के साथ अनुबंधित संगठनों से एकत्र किए गए डेटा के अध्ययन के बाद बनाया गया था, जिन्होंने अनुसंधान को वित्त पोषित किया था। शब्द "परिपक्वता" प्रक्रियाओं की औपचारिकता और अनुकूलन की डिग्री से संबंधित है, तदर्थ प्रथाओं से लेकर औपचारिक रूप से परिभाषित चरणों तक, प्रबंधित परिणाम मेट्रिक्स तक, प्रक्रियाओं के सक्रिय अनुकूलन तक था।

मॉडल का उद्देश्य मौजूदा सॉफ़्टवेयर विकास प्रक्रियाओं में सुधार करना है, लेकिन इसे अन्य प्रक्रियाओं पर भी लागू किया जा सकता है।

2006 में, कार्नेगी मेलन विश्वविद्यालय के सॉफ्टवेयर इंजीनियरिंग संस्थान ने क्षमता परिपक्वता मॉडल एकीकरण विकसित किया, जिसने काफी हद तक सीएमएम को हटा दिया है और इसकी कुछ कमियों को दूर किया है।[1]


अवलोकन

क्षमता परिपक्वता मॉडल मूल रूप से एक अनुबंधित सॉफ्टवेयर परियोजना को लागू करने के लिए सरकारी ठेकेदारों की प्रक्रियाओं की क्षमता का निष्पक्ष मूल्यांकन करने के लिए एक उपकरण के रूप में विकसित किया गया था। मॉडल प्रक्रिया परिपक्वता ढांचे पर आधारित है जिसका वर्णन पहले आईईईई सॉफ्टवेयर में किया गया था[2] और बाद में, 1989 में वाट्स हम्फ्री की पुस्तक मैनेजिंग द सॉफ्टवेयर प्रोसेस में किया गया था। इसे बाद में 1993 में एक रिपोर्ट में प्रकाशित किया गया था[3] और 1995 में उन्हीं लेखकों द्वारा एक पुस्तक के रूप में प्रकाशित किया गया था।

हालाँकि यह मॉडल सॉफ्टवेयर विकास के क्षेत्र से आता है, इसका उपयोग आम तौर पर व्यावसायिक प्रक्रियाओं में सहायता के लिए एक मॉडल के रूप में भी किया जाता है, और दुनिया भर में सरकारी कार्यालयों, वाणिज्य और उद्योग में भी इसका बड़े पैमाने पर उपयोग किया जाता है।[4][5]


इतिहास

सॉफ़्टवेयर प्रक्रियाओं की पूर्व आवश्यकता

1980 के दशक में, कंप्यूटर का उपयोग अधिक व्यापक, अधिक लचीला और कम खर्चीला हो गया। संगठनों ने कम्प्यूटरीकृत सूचना प्रणाली को अपनाना शुरू कर दिया और सॉफ्टवेयर विकास की मांग में उल्लेखनीय वृद्धि हुई। सॉफ़्टवेयर विकास के लिए कई प्रक्रियाएँ अपनी प्रारंभिक अवस्था में थीं, जिनमें कुछ मानक या "सर्वोत्तम अभ्यास" दृष्टिकोण परिभाषित थे।

परिणामस्वरूप, विकास के साथ-साथ बढ़ती तकलीफें भी हुईं: परियोजना विफलता आम थी, कंप्यूटर विज्ञान का क्षेत्र अभी भी अपने प्रारंभिक वर्षों में था, और परियोजना के पैमाने और जटिलता की महत्वाकांक्षाएं नियोजित बजट के भीतर पर्याप्त उत्पाद वितरित करने की बाजार क्षमता से अधिक थीं। एडवर्ड योर्डन,[6] लैरी कॉन्स्टेंटाइन, गेराल्ड वेनबर्ग,[7] टॉम डेमार्को,[8] और डेविड पारनास जैसे व्यक्तियों ने सॉफ्टवेयर-विकास प्रक्रियाओं को पेशेवर बनाने के प्रयास में शोध परिणामों के साथ लेख और किताबें प्रकाशित करना शुरू किया।[4][9]

1980 के दशक में, सॉफ्टवेयर उपठेकेदारों से जुड़ी कई अमेरिकी सैन्य परियोजनाएं बजट से अधिक चलीं और योजनाबद्ध तरीके से बहुत देर से पूरी हुईं, यदि पूरी भी हुईं। यह निर्धारित करने के प्रयास में कि ऐसा क्यों हो रहा था, संयुक्त राज्य वायु सेना ने सॉफ्टवेयर इंजीनियरिंग इंस्टीट्यूट (एसईआई) में एक अध्ययन को वित्त पोषित किया था।

अग्रदूत

आईटी में चरणबद्ध परिपक्वता मॉडल का पहला अनुप्रयोग सीएमयू/एसईआई द्वारा नहीं, बल्कि रिचर्ड एल. नोलन द्वारा किया गया था, जिन्होंने 1973 में आईटी संगठनों के लिए विकास मॉडल के चरणों को प्रकाशित किया था।[10]

वाट्स हम्फ्री ने आईबीएम में अपने 27 साल के करियर के बाद के चरणों के दौरान अपनी प्रक्रिया परिपक्वता अवधारणाओं को विकसित करना शुरू किया था।[11]


सॉफ्टवेयर इंजीनियरिंग संस्थान में विकास

अमेरिकी रक्षा सॉफ्टवेयर इंजीनियरिंग संस्थान (एसईआई) विभाग द्वारा मॉडल का सक्रिय विकास 1986 में शुरू हुआ जब हम्फ्री आईबीएम से सेवानिवृत्त होने के बाद पिट्सबर्ग, पेंसिल्वेनिया में कार्नेगी मेलॉन विश्वविद्यालय में स्थित सॉफ्टवेयर इंजीनियरिंग संस्थान में शामिल हो गए। अमेरिकी वायु सेना के अनुरोध पर उन्होंने अनुबंध देने के हिस्से के रूप में सॉफ्टवेयर ठेकेदारों की क्षमता का मूल्यांकन करने में अमेरिकी रक्षा विभाग की सहायता के लिए अपनी प्रक्रिया परिपक्वता रूपरेखा को औपचारिक रूप देना शुरू किया था।

वायु सेना के अध्ययन का परिणाम सेना के लिए सॉफ्टवेयर उपठेकेदारों की प्रक्रिया क्षमता परिपक्वता के वस्तुनिष्ठ मूल्यांकन के रूप में उपयोग करने के लिए एक मॉडल था। हम्फ्री ने इस ढांचे को फिलिप बी. क्रॉस्बी द्वारा अपनी पुस्तक "क्वालिटी इज फ्री" में विकसित पहले के गुणवत्ता प्रबंधन परिपक्वता ग्रिड पर आधारित किया है।[12] हम्फ्री का दृष्टिकोण उनकी अनूठी अंतर्दृष्टि के कारण भिन्न था कि संगठन एक विशिष्ट क्रम में प्रक्रिया समस्याओं को हल करने के आधार पर अपनी प्रक्रियाओं को चरणों में परिपक्व करते हैं। हम्फ्री ने प्रत्येक अलग विकास प्रक्रिया की परिपक्वता को स्वतंत्र रूप से मापने के बजाय, एक संगठन के भीतर सॉफ्टवेयर विकास प्रथाओं की एक प्रणाली के चरणबद्ध विकास पर अपना दृष्टिकोण आधारित किया। इस प्रकार सीएमएम का उपयोग विभिन्न संगठनों द्वारा सामान्य व्यावसायिक प्रक्रिया प्रदर्शन को समझने और फिर उसमें सुधार करने के लिए एक सामान्य और शक्तिशाली उपकरण के रूप में किया गया है।

वाट्स हम्फ्री का क्षमता परिपक्वता मॉडल (सीएमएम) 1988 में प्रकाशित हुआ था[13] और 1989 में सॉफ्टवेयर प्रक्रिया के प्रबंधन में एक पुस्तक के रूप में प्रकाशित हुआ था।[14]

संगठनों का मूल्यांकन मूल रूप से सॉफ्टवेयर इंजीनियरिंग संस्थान में हम्फ्री और उनके सहयोगियों द्वारा तैयार एक प्रक्रिया परिपक्वता प्रश्नावली और एक सॉफ्टवेयर क्षमता मूल्यांकन पद्धति का उपयोग करके किया गया था।

पांच परिपक्वता स्तरों में से प्रत्येक पर परिभाषित प्रक्रिया क्षेत्रों और प्रथाओं के एक सेट के रूप में क्षमता परिपक्वता मॉडल का पूर्ण प्रतिनिधित्व 1991 में शुरू किया गया था, संस्करण 1.1 जनवरी 1993 में पूरा हुआ था।[15] सीएमएम को 1995 में इसके प्राथमिक लेखकों, मार्क सी. पॉल्क, चार्ल्स वी. वेबर, बिल कर्टिस और मैरी बेथ क्रिसिस द्वारा एक पुस्तक के रूप में प्रकाशित किया गया था।

क्षमता परिपक्वता मॉडल एकीकरण

सॉफ़्टवेयर विकास में सीएमएम मॉडल का अनुप्रयोग कभी-कभी समस्याग्रस्त रहा है। ऐसे अनेक मॉडलों को लागू करना जो किसी संगठन के भीतर और भीतर एकीकृत नहीं हैं, प्रशिक्षण, मूल्यांकन और सुधार गतिविधियों में महंगा हो सकता है। क्षमता परिपक्वता मॉडल एकीकरण (सीएमएमआई) परियोजना का गठन सॉफ्टवेयर विकास प्रक्रियाओं के लिए कई मॉडलों का उपयोग करने की समस्या को हल करने के लिए किया गया था, इस प्रकार सीएमएमआई मॉडल ने सीएमएम मॉडल को हटा दिया है, हालांकि सीएमएम मॉडल एक सामान्य सैद्धांतिक प्रक्रिया क्षमता मॉडल बना हुआ है जिसका उपयोग सॉफ्टवेयर विकास प्रक्रियाओं के लिए किया जाता है। सार्वजनिक डोमेन.[16][citation needed][17]


अन्य प्रक्रियाओं के लिए अनुकूलित

सीएमएम का उद्देश्य मूल रूप से एक अनुबंधित सॉफ्टवेयर परियोजना को निष्पादित करने के लिए सरकारी ठेकेदारों की क्षमता का मूल्यांकन करने के लिए एक उपकरण के रूप में था। यद्यपि यह सॉफ्टवेयर विकास के क्षेत्र से आता है, इसे आईएस/आईटी (और अन्य) संगठनों में प्रक्रिया की परिपक्वता (उदाहरण के लिए, आईटी सेवा प्रबंधन प्रक्रियाओं) के एक सामान्य मॉडल के रूप में व्यापक रूप से लागू किया जा सकता है, किया जा रहा है और जारी रखा जा रहा है।

मॉडल विषय

परिपक्वता मॉडल

एक परिपक्वता मॉडल को संरचित स्तरों के एक सेट के रूप में देखा जा सकता है जो बताता है कि किसी संगठन के व्यवहार, अभ्यास और प्रक्रियाएं कितनी विश्वसनीय और स्थायी रूप से आवश्यक परिणाम उत्पन्न कर सकती हैं।

एक परिपक्वता मॉडल का उपयोग तुलना के लिए एक बेंचमार्क के रूप में और समझने में सहायता के रूप में किया जा सकता है - उदाहरण के लिए, विभिन्न संगठनों के तुलनात्मक मूल्यांकन के लिए जहां कुछ समान है जिसे तुलना के आधार के रूप में इस्तेमाल किया जा सकता है। उदाहरण के लिए, सीएमएम के मामले में, तुलना का आधार संगठनों की सॉफ्टवेयर विकास प्रक्रियाएं होंगी।

संरचना

मॉडल में पाँच पहलू शामिल हैं:

  • परिपक्वता स्तर: एक 5-स्तरीय प्रक्रिया परिपक्वता सातत्य - जहां सबसे ऊपर (5वां) स्तर एक काल्पनिक आदर्श स्थिति है जहां प्रक्रियाओं को प्रक्रिया अनुकूलन और निरंतर प्रक्रिया सुधार के संयोजन द्वारा व्यवस्थित रूप से प्रबंधित किया जाएगा।
  • मुख्य प्रक्रिया क्षेत्र: एक मुख्य प्रक्रिया क्षेत्र संबंधित गतिविधियों के एक समूह की पहचान करता है, जो एक साथ निष्पादित होने पर, महत्वपूर्ण माने जाने वाले लक्ष्यों के एक सेट को प्राप्त करते हैं।
  • लक्ष्य: एक प्रमुख प्रक्रिया क्षेत्र के लक्ष्य उन स्थितियों का सारांश प्रस्तुत करते हैं जो उस प्रमुख प्रक्रिया क्षेत्र को प्रभावी और स्थायी तरीके से लागू करने के लिए मौजूद होनी चाहिए। लक्ष्यों को किस हद तक पूरा किया गया है यह इस बात का संकेतक है कि संगठन ने उस परिपक्वता स्तर पर कितनी क्षमता स्थापित की है। लक्ष्य प्रत्येक प्रमुख प्रक्रिया क्षेत्र के दायरे, सीमाओं और इरादे को दर्शाते हैं।
  • सामान्य विशेषताएं: सामान्य विशेषताओं में ऐसी प्रथाएं शामिल हैं जो एक प्रमुख प्रक्रिया क्षेत्र को लागू और संस्थागत बनाती हैं। पाँच प्रकार की सामान्य विशेषताएँ हैं: प्रदर्शन करने की प्रतिबद्धता, प्रदर्शन करने की क्षमता, की गई गतिविधियाँ, माप और विश्लेषण, और कार्यान्वयन की पुष्टि करना।
  • प्रमुख प्रथाएं: प्रमुख प्रथाएं बुनियादी ढांचे और अभ्यास के तत्वों का वर्णन करती हैं जो क्षेत्र के कार्यान्वयन और संस्थागतकरण में सबसे प्रभावी ढंग से योगदान करती हैं।

स्तर

एसईआई के अनुसार, मॉडल की निरंतरता के साथ पांच स्तर परिभाषित हैं: माना जाता है कि जैसे-जैसे संगठन इन पांच स्तरों पर आगे बढ़ता है, किसी संगठन की सॉफ्टवेयर प्रक्रियाओं की भविष्यवाणी, प्रभावशीलता और नियंत्रण में सुधार होता है। कठोर न होते हुए भी, आज तक के अनुभवजन्य साक्ष्य इस विश्वास का समर्थन करते हैं।[18]

  1. प्रारंभिक (अराजक, तदर्थ, व्यक्तिगत वीरता) - एक नई या अनिर्दिष्ट दोहराव प्रक्रिया के उपयोग के लिए प्रारंभिक बिंदु।
  2. दोहराने योग्य - प्रक्रिया को कम से कम पर्याप्त रूप से प्रलेखित किया गया है ताकि समान चरणों को दोहराने का प्रयास किया जा सके।
  3. परिभाषित - प्रक्रिया को एक मानक व्यावसायिक प्रक्रिया के रूप में परिभाषित/पुष्टि किया गया है
  4. सक्षम - प्रक्रिया को सहमत मैट्रिक्स के अनुसार मात्रात्मक रूप से प्रबंधित किया जाता है।
  5. कुशल - प्रक्रिया प्रबंधन में जानबूझकर प्रक्रिया अनुकूलन/सुधार शामिल है।

इनमें से प्रत्येक परिपक्वता स्तर के भीतर प्रमुख प्रक्रिया क्षेत्र हैं जो उस स्तर की विशेषता बताते हैं, और ऐसे प्रत्येक क्षेत्र के लिए पांच कारक हैं: लक्ष्य, प्रतिबद्धता, क्षमता, माप और सत्यापन। ये आवश्यक रूप से सीएमएम के लिए अद्वितीय नहीं हैं, जैसा कि वे करते हैं - उन चरणों का प्रतिनिधित्व करते हैं जिनसे संगठनों को परिपक्व होने के रास्ते पर गुजरना होगा।

मॉडल एक सैद्धांतिक सातत्य प्रदान करता है जिसके साथ प्रक्रिया परिपक्वता को एक स्तर से दूसरे स्तर तक क्रमिक रूप से विकसित किया जा सकता है। स्तरों को छोड़ना अनुमति/संभव नहीं है।

स्तर 1 - आरंभिक
इस स्तर पर प्रक्रियाओं की यह विशेषता है कि वे (आमतौर पर) अप्रलेखित और गतिशील परिवर्तन की स्थिति में हैं, जो उपयोगकर्ताओं या घटनाओं द्वारा तदर्थ, अनियंत्रित और प्रतिक्रियाशील तरीके से संचालित होती हैं। यह प्रक्रियाओं के लिए एक अराजक या अस्थिर वातावरण प्रदान करता है। (उदाहरण - एक सर्जन एक नया ऑपरेशन कम संख्या में कर रहा है - नकारात्मक परिणाम के स्तर ज्ञात नहीं हैं)।
स्तर 2 - दोहराने योग्य
परिपक्वता के इस स्तर की विशेषता यह है कि कुछ प्रक्रियाएं दोहराई जा सकती हैं, संभवतः सुसंगत परिणामों के साथ। प्रक्रिया अनुशासन के कठोर होने की संभावना नहीं है, लेकिन जहां यह मौजूद है, यह सुनिश्चित करने में मदद मिल सकती है कि तनाव के समय में मौजूदा प्रक्रियाएं बनी रहें।
स्तर 3 - परिभाषित
इस स्तर पर प्रक्रियाओं की यह विशेषता है कि वहां परिभाषित और प्रलेखित मानक प्रक्रियाओं के सेट स्थापित हैं और समय के साथ कुछ हद तक सुधार के अधीन हैं। ये मानक प्रक्रियाएं मौजूद हैं. प्रक्रियाओं को व्यवस्थित रूप से या बार-बार उपयोग नहीं किया गया हो सकता है - उपयोगकर्ताओं को सक्षम बनाने के लिए या कई स्थितियों में प्रक्रिया को मान्य करने के लिए पर्याप्त है। इसे एक विकासात्मक चरण माना जा सकता है - व्यापक परिस्थितियों में उपयोग और उपयोगकर्ता क्षमता विकास के साथ प्रक्रिया परिपक्वता के अगले स्तर तक विकसित हो सकती है।
स्तर 4 - प्रबंधित (सक्षम)
इस स्तर पर प्रक्रियाओं की विशेषता है कि, प्रक्रिया मेट्रिक्स का उपयोग करके, प्रक्रिया उद्देश्यों की प्रभावी उपलब्धि को कई परिचालन स्थितियों में प्रमाणित किया जा सकता है। कई वातावरणों में प्रक्रिया की उपयुक्तता का परीक्षण किया गया है और प्रक्रिया को परिष्कृत और अनुकूलित किया गया है। प्रक्रिया उपयोगकर्ताओं ने कई और विविध स्थितियों में प्रक्रिया का अनुभव किया है, और क्षमता प्रदर्शित करने में सक्षम हैं। प्रक्रिया परिपक्वता गुणवत्ता के मापनीय नुकसान या विनिर्देशों से विचलन के बिना विशेष परियोजनाओं के लिए अनुकूलन को सक्षम बनाती है। इस स्तर से प्रक्रिया क्षमता स्थापित की जाती है। (उदाहरण - सर्जन सैकड़ों बार एक ऑपरेशन करता है और नकारात्मक परिणाम का स्तर शून्य के करीब होता है)।
स्तर 5 - अनुकूलन (कुशल)
इस स्तर पर प्रक्रियाओं की एक विशेषता यह है कि वृद्धिशील और नवीन तकनीकी परिवर्तनों/सुधारों के माध्यम से प्रक्रिया प्रदर्शन में लगातार सुधार पर ध्यान केंद्रित किया जाता है। परिपक्वता स्तर 5 पर, प्रक्रियाओं का संबंध प्रक्रिया भिन्नता के सांख्यिकीय सामान्य कारणों को संबोधित करने और प्रक्रिया प्रदर्शन में सुधार के लिए प्रक्रिया को बदलने (उदाहरण के लिए, प्रक्रिया प्रदर्शन के माध्य को स्थानांतरित करने के लिए) से है। यह स्थापित मात्रात्मक प्रक्रिया-सुधार उद्देश्यों को प्राप्त करने की संभावना को बनाए रखने के साथ-साथ किया जाएगा।

2008 और 2019 के बीच, दिए गए लगभग 12% मूल्यांकन परिपक्वता स्तर 4 और 5 पर थे।[19][20]


आलोचना

मॉडल का उद्देश्य मूल रूप से एक सॉफ्टवेयर परियोजना को निष्पादित करने के लिए सरकारी ठेकेदारों की क्षमता का मूल्यांकन करना था। इसका उपयोग किया गया है और यह उस उद्देश्य के लिए उपयुक्त हो सकता है, लेकिन आलोचक[who?]ने बताया कि सफल सॉफ्टवेयर विकास के लिए सीएमएम के अनुसार प्रक्रिया परिपक्वता अनिवार्य नहीं है।

सॉफ़्टवेयर प्रक्रिया ढाँचा

प्रलेखित सॉफ्टवेयर प्रक्रिया रूपरेखा का उद्देश्य उन लोगों का मार्गदर्शन करना है जो प्रमुख प्रक्रिया क्षेत्रों के साथ किसी संगठन या परियोजना की स्थिरता का आकलन करना चाहते हैं। प्रत्येक परिपक्वता स्तर के लिए पाँच चेकलिस्ट प्रकार हैं:

Type Description
Policy Describes the policy contents and KPA goals recommended by the Key Process Areas.
Standard Describes the recommended content of select work products described in the Key Process Areas.
Process Describes the process information content recommended by the Key Process Areas. These are refined into checklists for:
  • Roles, entry criteria, inputs, activities, outputs, exit criteria, reviews and audits, work products managed and controlled, measurements, documented procedures, training, and tools
Procedure Describes the recommended content of documented procedures described in the Key Process Areas.
Level overcome Provides an overview of an entire maturity level. These are further refined into checklists for:
  • Key Process Areas purposes, goals, policies, and standards; process descriptions; procedures; training; tools; reviews and audits; work products; measurements


यह भी देखें

संदर्भ

  1. Nayab, N. (2010-04-27). "सीएमएमआई बनाम सीएमएम के बीच अंतर". Bright Hub PM. Retrieved 2020-02-15.
  2. Humphrey, W. S. (March 1988). "Characterizing the software process: a maturity framework". IEEE Software. 5 (2): 73–79. doi:10.1109/52.2014. ISSN 0740-7459. S2CID 1008347.
  3. Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (February 1993). "Capability Maturity Model for Software (Version 1.1)" (PDF). Technical Report. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. CMU/SEI-93-TR-024 ESC-TR-93-177. Archived (PDF) from the original on 2011-01-03.
  4. 4.0 4.1 McKay, Vivienne. "What is the Capability Maturity Model? (CMM) | Process Maturity | FAQ". www.selectbs.com (in British English). Retrieved 2017-03-20.
  5. White, Sarah K. (2018-03-16). "What is CMMI? A model for optimizing development processes". CIO (in English). Retrieved 2020-06-04.
  6. Yourdon, E. (1989). 1989. Modern Structured Analysis. New York: Prentice Hall. ISBN 978-0135986240.
  7. Weinberg, G. M. (1992). Quality Software Management: Anticipating Change. Vol. 1: Systems Thinking. New York: Dorset House Pub. ISBN 978-0-932633-72-9.
  8. DeMarco, T.; Lister, T. (1997). Waltzing with Bears: Managing Risk on Software Projects. New York: Dorset House Pub. ISBN 978-0-932633-60-6.
  9. "सीएमएमआई-सिक्स सिग्मा, उनकी जड़ें". Process Enhancement Partners, Inc. (in English). 2011-01-23. Retrieved 2018-05-11.
  10. Nolan, R. L. (July 1973). "Managing the computer resource: A stage hypothesis". Comm. ACM. 16 (7): 399–405. doi:10.1145/362280.362284. S2CID 14053595.
  11. "People Capability Maturity Model (P-CMM) Version 2.0". resources.sei.cmu.edu. Retrieved 2017-01-17.
  12. Crosby, P. B. (1979). Quality is Free. New York: New American Library. ISBN 0-451-62247-2.
  13. Humphrey, W. S. (March 1988). "Characterizing the software process: A maturity framework" (PDF). IEEE Software. 5 (2): 73–79. doi:10.1109/52.2014. S2CID 1008347.
  14. Humphrey, W. S. (1989). Managing the Software Process. SEI series in software engineering. Reading, Mass.: Addison-Wesley. ISBN 0-201-18095-2.
  15. Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. SEI series in software engineering. Reading, Mass.: Addison-Wesley. ISBN 0-201-54664-7.
  16. Juran (2010-08-26). Juran'S Quality Hb 6E (in English). McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898.
  17. Natarajan, R (2015). इंजीनियरिंग शिक्षा में परिवर्तन पर अंतर्राष्ट्रीय सम्मेलन की कार्यवाही. Springer.
  18. State of Michigan SDLC Appendix on CMM Attests to 2001 use of the text so it couldn't have come from here.
  19. "CMMI Adoption Trends - 2019 Mid Year Update". CMMI Institute. 2019-10-21.
  20. Fishman, Charles (1996-12-31). "वे सही सामग्री लिखते हैं". Fast Company (in English). Retrieved 2020-02-15.


बाहरी संबंध