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

From Vigyanwiki

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

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

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


अवलोकन

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

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


इतिहास

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

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

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

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

अग्रदूत

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

वाट्स हम्फ्री ने IBM में अपने 27 साल के करियर के बाद के चरणों के अतिरिक्त अपनी प्रक्रिया परिपक्वता अवधारणाओं को विकसित करना प्रारंभ किया था।[11]


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

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

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

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

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

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

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

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


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

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

मॉडल विषय

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

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

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

संरचना

मॉडल में 5 पहलू सम्मिलत हैं:

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

स्तर

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

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

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

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

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

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


आलोचना

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

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

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

टाइप डिस्क्रिप्शन
पॉलिसीय प्रमुख प्रक्रिया क्षेत्रों द्वारा अनुशंसित नीति सामग्री और KPA लक्ष्यों का वर्णन करता है।
स्टैण्डर्ड मुख्य प्रक्रिया क्षेत्रों में वर्णित चुनिंदा कार्य उत्पादों की अनुशंसित सामग्री का वर्णन करता है।
प्रोसेस मुख्य प्रक्रिया क्षेत्रों द्वारा अनुशंसित प्रक्रिया सूचना सामग्री का वर्णन करता है। इन्हें निम्नलिखित के लिए जाँच सूचियों में परिष्कृत किया गया है:
  • भूमिकाएँ, प्रवेश मानदंड, इनपुट, गतिविधियाँ, आउटपुट, निकास मानदंड, समीक्षाएँ और ऑडिट, प्रबंधित और नियंत्रित कार्य उत्पाद, माप, दस्तावेज़ीकृत प्रक्रियाएँ, प्रशिक्षण और उपकरण है।
प्रोसीजर मुख्य प्रक्रिया क्षेत्रों में वर्णित लिखित प्रक्रियाओं की अनुशंसित सामग्री का वर्णन करता है।
लेवल ओवरकम संपूर्ण परिपक्वता स्तर का अवलोकन प्रदान करता है। इन्हें निम्नलिखित के लिए जाँच सूचियों में और परिष्कृत किया गया है:
  • मुख्य प्रक्रिया क्षेत्र के उद्देश्य, लक्ष्य, नीतियां और मानक; प्रक्रिया विवरण; प्रक्रियाएं; प्रशिक्षण; औजार; समीक्षाएँ और लेखापरीक्षा; कार्य उत्पाद; मापन है।


यह भी देखें

संदर्भ

  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.


बाहरी संबंध