सॉफ्टवेयर विकास: गुणवत्ता मानक। क्षमता परिपक्वता मॉडल (सीएमएम) उद्यम गुणवत्ता प्रणाली और सॉफ्टवेयर जीवन चक्र के बुनियादी दस्तावेज

राज्य और अंतर्राष्ट्रीय मानकों के अलावा, विकास प्रक्रिया के प्रमाणीकरण के लिए कई दृष्टिकोण हैं। रूस में उनमें से सबसे प्रसिद्ध, जाहिरा तौर पर, सीएमएम और सीएमएमआई हैं।

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

सीएमएम और सीएमएमआई आवश्यकताएँ

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

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

सीएमएम और सीएमएमआई और पुनरावृत्त विकास के बीच संबंध अधिक अप्रत्यक्ष है। औपचारिक रूप से, न तो कोई और न ही कोई झरना या पुनरावृत्त दृष्टिकोण का पालन करने के लिए विशिष्ट आवश्यकताओं को सामने रखता है। हालाँकि, कुछ विशेषज्ञों के अनुसार, सीएमएम झरना दृष्टिकोण के साथ अधिक संगत है, जबकि सीएमएमआई पुनरावृत्त दृष्टिकोण के उपयोग की भी अनुमति देता है।

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

आरयूपी पद्धति

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

इस प्रकार, आरयूपी एक पुनरावृत्तीय पद्धति है जिसमें विकास प्रक्रिया को औपचारिक बनाने के संदर्भ में संभावित समाधानों की एक विस्तृत श्रृंखला है।

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

हम अगले भाग में चर्चा करेंगे कि यह इतना महत्वपूर्ण क्यों है।

वी. इलिन।

टॉपएसबीआई कंपनी के गुणवत्ता सेवा प्रमुख

"अगर आप कुछ भी करते हैं

ग़लत - कोई ज़रूरत नहीं
सही परिणाम की उम्मीद करें।"

चीनी लोक ज्ञान

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

लेकिन इस सवाल का कि क्या गुणवत्ता प्रणाली का कार्यान्वयन और सफल प्रमाणीकरण गुणवत्ता वाले उत्पाद की रिहाई की गारंटी देता है, इसका उत्तर ईमानदारी से दिया जाना चाहिए - "नहीं।"

इस बात पर ज़ोर देते हुए कि ISO 9000 एक "महान विचार" है, गार्टनर समूह अनुशंसा करता है कि ISO 9001 प्रमाणन को केवल गुणवत्ता के मार्ग पर एक प्रारंभिक बिंदु माना जाना चाहिए (1)।

यह गुणवत्ता प्रणाली का "कंकाल" तैयार करता है, और इस प्रणाली को "मांसपेशियों" (विशेष उद्योग मानकों और पद्धतियों जैसे सीएमएम पर आधारित पेशेवर सामग्री) से भरकर गुणवत्ता का एक स्तर सुनिश्चित किया जा सकता है जो बढ़ती बाजार आवश्यकताओं को पूरा करता है।

उपरोक्त के संबंध में, पद्धतिगत और व्यावहारिक दोनों दृष्टिकोण से, गुणवत्ता प्रबंधन के क्षेत्र में कई विशेषज्ञ आईटी कंपनियों के लिए निम्नानुसार विकास रणनीति बनाने की सलाह देते हैं:

सबसे पहले, ISO 9001:2000 मॉडल के अनुसार QMS विकसित और कार्यान्वित करें। (आखिरकार, अधिकांश कंपनियां जो अब एसडब्ल्यू-सीएमएम के चौथे और पांचवें स्तर पर हैं, पहले अपनी प्रक्रियाओं को आईएसओ मॉडल के अनुपालन में लाती थीं। जैसा कि अभ्यास से पता चलता है, क्यूएमएस के विकास के प्रबंधन के मामले में यह सबसे अच्छा विकल्प है। और जोखिम कम करना)।

और उसके बाद ही एसडब्ल्यू-सीएमएम मॉडल और फिर, यदि आवश्यक हो, सीएमएमआई मॉडल की प्रमुख प्रक्रियाओं को विकसित और कार्यान्वित करना शुरू करें।

यह वास्तव में कितना सही है यह समझने के लिए आइए इन मॉडलों की तुलना करें।

1. आवेदकों की समीक्षा.

आइए सबसे लोकप्रिय मानकों का संक्षिप्त अवलोकन करें जिनका उपयोग एक आईटी कंपनी अपनी व्यावसायिक प्रक्रियाओं को अनुकूलित करने के लिए कर सकती है।

आईएसओ 9001।सबसे लोकप्रिय, और विशेष रूप से यूरोप में, ISO 9001 (2) है

एक ही समय में, व्यवस्थित रूप से, जटिल प्रणालियों के निर्माण के अनुशासन के अनुसार, आईएसओ 9001 मानक, एक ओर, "ऊपर से नीचे तक" एक संगठनात्मक प्रणाली के निर्माण के लिए प्रदान करता है: उद्यम के लक्ष्यों और उसकी नीतियों से - संगठनात्मक संरचना और व्यावसायिक प्रक्रियाओं के गठन के लिए, और दूसरी ओर - माप और सुधार तंत्र के माध्यम से संगठनात्मक प्रणाली का पुनरावृत्त विकास।

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

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

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

SW-CMM v.1.1 (सॉफ्टवेयर के लिए क्षमता परिपक्वता मॉडल) में 316 प्रमुख प्रथाएं हैं। मुख्य प्रथाएँ वे हैं जिन्हें उद्यम में लागू किया जाना चाहिए और प्रक्रिया मूल्यांकन करने वाली टीम किस पर ध्यान देगी। उन्हें क्षेत्रों में संयोजित किया जाता है - मुख्य अभ्यास क्षेत्र (केपीए) - ये पहले से ही परस्पर जुड़ी प्रक्रियाओं के सेट हैं, जो एक साथ निष्पादित होने पर, लक्ष्यों के एक निश्चित सेट की उपलब्धि की ओर ले जाते हैं।

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

मुख्य प्रथाओं में वृद्धि सीएमएमआई विकसित करने के उद्देश्य से संबंधित है - मॉडल को विभिन्न उद्योग सीएमएम मॉडल के उपयोग से जुड़ी समस्याओं से बचने में मदद करनी चाहिए।

(1991 से, सीएमएम मॉडल विभिन्न अनुप्रयोगों के लिए विकसित किए गए हैं, जिनमें से सबसे महत्वपूर्ण हैं:

सॉफ़्टवेयर विकास प्रक्रिया परिपक्वता मॉडल (सॉफ़्टवेयर के लिए क्षमता परिपक्वता मॉडल - SW-CMM)
- सिस्टम रीइंजीनियरिंग के लिए प्रक्रिया परिपक्वता मॉडल (इलेक्ट्रॉनिक इंडस्ट्रीज एलायंस अंतरिम मानक - ईआईए/आईएस 731)
- एकीकृत उत्पाद विकास प्रक्रियाओं का परिपक्वता मॉडल एकीकृत उत्पाद विकास क्षमता परिपक्वता मॉडल - आईपीडी-सीएमएम)

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

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

चावल। 1 सीएमएम और सीएमएमआई मॉडल में केपीए संरचना की तुलना।

इसके अलावा, अधिकृत होने के बाद से सीएमएमआई के लिए मूल्यांकन काफी अधिक महंगा होगा एसईआई लीड मूल्यांकनकर्ता"अभी भी बहुत कम होंगे, और ये सेवाएँ सीएमएम मॉडल के अनुपालन का आकलन करने की तुलना में बहुत अधिक महंगी होंगी।

इसके अलावा, गुणवत्ता प्रबंधन के क्षेत्र में कई विदेशी विशेषज्ञ (जिनकी राय से मैं इस समय पूरी तरह सहमत हूं) छोटे और मध्यम आकार के संगठनों में कार्यान्वयन के लिए इसकी उपयोगिता के संदर्भ में सीएमएमआई के बारे में काफी संशय में हैं (ठीक ऐसे संगठन रूस के लिए विशिष्ट हैं) ). एक राय यह भी व्यक्त की गई है कि कुछ समय बाद SEI को या तो एक अनुकूलित SW-CMM v.2 जारी करना होगा, या कुछ इसी तरह के कदम उठाने होंगे। वे। यदि बाजार मॉडल को स्वीकार नहीं करता है, और इस लेख को लिखने के समय ऐसी पूर्वापेक्षाएँ पहले से मौजूद हैं, तो एसईआई को बाजार की आवश्यकताओं के अनुरूप ढलने की आवश्यकता होगी।

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

आइए इसे निम्नलिखित निर्देशांक में निष्पादित करें (देखें। चावल। 2) :

विकास प्रक्रियाओं के नियमन की डिग्री - आइए इस अवधारणा को निरूपित करें - आर.पी.,

नियोजित परिणाम प्राप्त करने की संभावना - आइए इस अवधारणा को निरूपित करें - पी क्यू.

चित्र में. चित्र 2 विकास और कार्यान्वयन की प्रक्रियाओं में इन मॉडलों की आवश्यकताओं को पेश करने के अभ्यास के परिणामों के आधार पर लेखक द्वारा किए गए विनियमन की डिग्री और नियोजित परिणामों को प्राप्त करने की संभावना के बीच संतुलन का एक विशेषज्ञ मूल्यांकन दिखाता है। सॉफ्टवेयर (सॉफ्टवेयर)।

गणितीय शब्दों में, व्युत्पन्न का परिमाण है: एफ(क्यू) = dPQ\dRQ(गुणवत्ता प्राप्त करने में दक्षता में वृद्धि डीपीक्यूआवश्यकताओं की पूर्ति के समर्थन पर खर्च किए जाने वाले कार्य समय में वृद्धि के साथ डीआरक्यू), निम्नलिखित क्रम में तदनुसार घटता है : आईएसओ 9000, सीएमएम, सीएमएमआई।

इसलिए चित्र. 2 स्पष्ट रूप से और सरलता से समझाता है:

ISO 9000 मॉडल की लोकप्रियता,

कार्यप्रणाली की शुद्धता: पहले आईएसओ, और उसके बाद ही, यदि आवश्यक हो, सीएमएम,

सीएमएमआई मॉडल की प्रभावशीलता के संबंध में कुछ संदेह।

चावल। 2 विनियमन की डिग्री और नियोजित परिणाम प्राप्त करने की संभावना के बीच संतुलन का विश्लेषण (लेखक के विशेषज्ञ मूल्यांकन के अनुसार)

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

यह PMBOK(परियोजना प्रबंधन निकाय ज्ञान के लिए मार्गदर्शिका) एक परियोजना प्रबंधन संस्थान परियोजना है जो परियोजना प्रबंधन के क्षेत्र में संचित ज्ञान को शामिल करती है। दस्तावेज़ का नवीनतम संस्करण 2000 में प्रकाशित हुआ था और साथ ही इसे अमेरिकी मानक संस्थान एएनएसआई के मानक का दर्जा प्राप्त हुआ था (हालांकि एएनएसआई और आईईईई मानकों को औपचारिक रूप से अमेरिकी माना जाता है, उनमें से अधिकतर प्रकृति में वास्तव में अंतरराष्ट्रीय हैं)। पीएमबीओके की एक महत्वपूर्ण विशेषता यह है कि यह आईटी जैसे विशिष्ट विषय क्षेत्रों के संदर्भ के बिना, सामान्य अर्थ में परियोजना प्रबंधन पर विचार करता है, और इसलिए इसे स्वतंत्र रूप से उपयोग नहीं किया जा सकता है - नीचे हम आईएसओ 9000 के साथ संयोजन में उपयोग किए जाने पर इसके प्रभाव को देखेंगे।

आइए अब विचार करें कि पहले से ही लोकप्रिय आईएसओ 9001:2000 मानक की आवश्यकताएं तेजी से लोकप्रिय सीएमएम मॉडल के सामान्य गुणों से कैसे संबंधित हैं {3}- सेमी। चावल। 3.

चावल। 3. सीएमएम के सामान्य गुणों और आईएसओ 9001:2000 के तत्वों के बीच पत्राचार

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

सीएमएम सॉफ्टवेयर विकास से संबंधित सभी प्रक्रियाओं को परिभाषित नहीं करता है; यह केवल उन पर प्रकाश डालता है जो एसएमएम स्तर को प्राप्त करने के लिए आवश्यक हैं, और उन्हें इसमें शामिल किया गया है किलो पास्कल. प्रत्येक किलो पास्कल 5 सामान्य गुणों (सामान्य विशेषताएं) में विभाजित है: प्रदर्शन करने की प्रतिबद्धता (प्रदर्शन करने के लिए टिप्पणी); प्रदर्शन करने की क्षमता; गतिविधियों का प्रदर्शन; मापन और विश्लेषण; कार्यान्वयन का सत्यापन

सामान्य संपत्ति " की जाने वाली कार्रवाइयां"लक्ष्यों को प्राप्त करने के लिए किए जाने वाले कार्यों का वर्णन करता है किलो पास्कलशेष चार सामान्य गुण उन औपचारिक कारकों का वर्णन करते हैं जो प्रक्रिया को संगठनात्मक संस्कृति का हिस्सा बनाते हैं। सभी का पूर्ण निष्पादन प्रमुख प्रथाएँसभी सामान्य गुण लक्ष्यों की प्राप्ति सुनिश्चित करते हैं किलो पास्कल. मुख्य प्रथाएं बताती हैं कि वर्कफ़्लो (या प्रक्रिया तत्व, या बुनियादी ढांचे का टुकड़ा) क्या बनना चाहिए, लेकिन उपलब्धि की विधि (विशिष्ट प्रौद्योगिकियों या तकनीकों) को परिभाषित नहीं करते हैं, हालांकि कुछ प्रथाओं के लिए सामान्य सिफारिशें दी जाती हैं। विभिन्न स्थितियों के लिए, एक ही परिणाम अलग-अलग तरीकों से प्राप्त किया जा सकता है। ये विशिष्ट कार्यों के बजाय सामान्य संचालन सिद्धांत हैं।

सामान्य गुणों का लगातार कार्यान्वयन वास्तव में व्यवसाय प्रक्रिया सुधार (बिजनेस-प्रोसेस सुधार -) के चक्र को लागू करता है बी.पी.आई-सेमी। चावल। 5.), अर्थात। व्यावसायिक प्रक्रियाओं (बीपी) में निरंतर सुधार।

चावल। 5. सीएमएम मॉडल और आईएसओ 9000:2000 के अनुसार व्यावसायिक प्रक्रियाओं के निरंतर सुधार का चक्र।

कम से कम समय में अनुरूपता का प्रमाण पत्र प्राप्त करने की इच्छा गुणवत्ता प्रबंधन में शामिल परामर्श कंपनियों और विशेषज्ञों को अपने स्वयं के "स्वार्थी" उद्देश्यों के लिए सभी सूचीबद्ध उच्च-स्तरीय मॉडलों की आवश्यकताओं के लचीलेपन और ढांचे का उपयोग करने के लिए मजबूर करती है।
घटनाओं के इस दबाव के परिणामस्वरूप, उदाहरण के लिए, एक संगठन, जिसे ISO 9000:2000 प्रमाणपत्र प्राप्त हुआ है, के पास ISO 9001 का अनुपालन करने के लिए परिभाषित प्रक्रियाओं का केवल न्यूनतम आवश्यक सेट है, और वे सभी प्रक्रियाएँ नहीं हैं जिनकी कंपनी को आवश्यकता होती है। प्रभावी ढंग से कार्य करें - देखें। चावल। 2. इसके अलावा, प्रक्रियाओं के अंदर क्या हो रहा है और प्रक्रिया के भीतर किन कार्यों के लिए कौन जिम्मेदार है, इसकी स्पष्ट समझ के लिए प्रक्रियाओं में विवरण का स्तर पर्याप्त नहीं हो सकता है।
सर्वोत्तम स्थिति में, केवल कुछ परीक्षण परियोजनाएँ ही नई प्रक्रियाओं से गुज़री हैं, और कुछ समय बाद उनके समायोजन और परिवर्धन की आवश्यकता स्पष्ट हो जाती है। अक्सर, क्यूएमएस प्रमाणन के तुरंत बाद, प्रक्रियाओं को अगले निगरानी ऑडिट तक भुला दिया जाता है, खर्च किए गए वित्तीय संसाधनों और कर्मचारियों के उत्साह के बारे में भुला दिया जाता है।
दरअसल, जब आप एक स्वतंत्र लेखा परीक्षक के रूप में कार्य करते हैं, तो यह साबित करना बहुत मुश्किल होता है कि प्रक्रिया विवरण का अपनाया गया स्तर कंपनी के क्यूएमएस के प्रभावी कामकाज के लिए स्पष्ट रूप से पर्याप्त नहीं है। लेकिन ISO 9000 ऑडिट के लिए आवंटित समय में विपरीत साबित करना बेहद मुश्किल है (ऑडिटर का विरोध करते समय इसका उपयोग बहुत सफलतापूर्वक किया जा सकता है)। अभ्यास से पता चलता है कि तीसरे परिपक्वता स्तर (साथ ही आईएसओ 9000 पर आधारित प्रक्रियाओं) की प्रभावी प्रक्रियाओं को जल्दी से बनाना असंभव है।
इसे प्राप्त करने के लिए, केवल चुने हुए मॉडल की आवश्यकताओं को ध्यान में रखते हुए प्रक्रियाओं का वर्णन करना पर्याप्त नहीं है। मुख्य कठिनाई यह है कि यह आवश्यक है संगठन के भीतर उत्पादन संस्कृति को नया स्वरूप दें .

और प्रबंधन के दृढ़ इच्छाशक्ति वाले निर्णय से ऐसा करना असंभव है। यही कारण है कि सीएमएम में परिभाषित दृष्टिकोण आईएसओ 9000-सेमी मॉडल की तुलना में अधिक व्यवहार्य और यथार्थवादी है। चावल। 5.

आइए अब विचार करें कि व्यवहार में दोनों मॉडलों के साथ संगत क्यूएमएस बनाना कैसे संभव है।

आईएसओ 9000:2000 आवश्यकताओं के साथ प्रमुख सीएमएम प्रक्रियाओं के कवरेज की डिग्री का एक विशेषज्ञ मूल्यांकन, स्वयं सीएमएम लेखकों के मूल्यांकन के अनुसार (4), में दिखाया गया है चित्र 6.

दरअसल, उनका मूल्यांकन दो निर्देशांकों के अनुसार किया गया था:

सीएमएम के ढांचे के भीतर परिपक्वता स्तर के साथ विकास प्रक्रियाओं (एसडब्ल्यूपी) के अनुपालन के आश्वासन की डिग्री (% में) -" प्रावधान";

ऐसे प्रावधान की संभावना की डिग्री (% में), जो ISO 9000:2000 द्वारा दी गई है - " अवसर".

जैसा कि देखा जा सकता है चावल। 6, ISO 9000:2000 आवश्यकताएँ SWP परिपक्वता के ऊपरी (CMM स्तर 5) स्तर को भी प्राप्त करने का एक वास्तविक अवसर बनाती हैं।

हालाँकि, पहले से ही कम से कम तीसरे (सीएमएम स्तर 3) स्तर की एसडब्ल्यूपी परिपक्वता सुनिश्चित करने के अर्थ में, आईएसओ 9000:2000 मॉडल के अनुसार क्यूएमएस को थोड़ा संशोधित करने की आवश्यकता है - अर्थात्, दो और संगठनात्मक प्रक्रियाओं को विकसित और कार्यान्वित करने के लिए ( संगठन प्रक्रिया परिभाषाऔर फोकस) और सामान्य प्रबंधन प्रक्रिया ( एकीकृत सॉफ्टवेयर प्रबंधन ), जिसका कंटेंट किसी भी आईटी कंपनी के लिए मुश्किल नहीं है।

लेकिन आप आगे बढ़ सकते हैं और जाना चाहिए (सीएमएम स्तर 4) - उदाहरण के लिए, कोष्ठक में इस लेख के लेखक का मूल्यांकन दिखाया गया है (उसी निर्देशांक में - समर्थनशीलता और क्षमताएं), जो आईएसओ 9000 के अनुसार क्यूएमएस से मेल खाती है: 2000 मॉडल, जिसमें QMS प्रक्रिया परिदृश्य को ऊपर उल्लिखित किसी अन्य मानक की आवश्यकताओं के अनुसार प्रक्रिया परियोजना प्रबंधन के साथ पूरक किया गया है पीएम बोक- इससे आपको ऐसे और अधिक की परिपक्वता बढ़ाने में उल्लेखनीय मदद मिलेगी एसडब्ल्यूपी, कैसे:

परियोजनाओं की प्रगति की निगरानी करना (सॉफ्टवेयर प्रोजेक्ट ट्रैकिंग और निरीक्षण);

• सॉफ्टवेयर परियोजना योजना;

सामान्य सॉफ़्टवेयर प्रबंधन (एकीकृत सॉफ़्टवेयर प्रबंधन);

मात्रात्मक आकलन के माध्यम से प्रक्रिया प्रबंधन (मात्रात्मक प्रक्रिया प्रबंधन)।

चावल। 6. आईएसओ 9000:2000 आवश्यकताओं के साथ प्रमुख सीएमएम प्रक्रियाओं के कवरेज की डिग्री का विशेषज्ञ मूल्यांकन

जैसा कि देखा जा सकता है चित्र 6., सीएमएम मॉडल, इसमें अंतर्निहित सिद्धांतों के अनुसार, आईएसओ 9001:2000 मानक के अनुसार निर्मित क्यूएमएस के बहुत करीब है और इसके अनुसार परियोजना प्रबंधन प्रक्रियाओं के साथ पूरक है। पीएम बीओके..

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

आवश्यकताओं को पूरा करता है आईएसओ 9001:2000एक प्रक्रिया दृष्टिकोण की शुरूआत पर;

दस्तावेज़ सभी आवश्यक सीएमएमप्रक्रियाएं ( किलो पास्कल);

ऐसी कई महत्वपूर्ण आवश्यकताओं को लागू करता है आईएसओ 9001:2000कैसे:

मेट्रिक्स-आधारित प्रक्रिया प्रबंधन (मात्रात्मक प्रक्रिया प्रबंधन);

उपअनुबंध प्रबंधन के आधार पर आपूर्तिकर्ताओं का प्रबंधन ( सॉफ्टवेयर उपअनुबंध प्रबंधन );

उपभोक्ता आवश्यकताओं के आधार पर विश्लेषण आवश्यकता प्रबंधन (आवश्यकता प्रबंधन );

मानव संसाधन प्रबंधन पर आधारित है प्रशिक्षण कार्यक्रम );

संचार प्रबंधन पर आधारित है संगठनात्मक प्रक्रियाओं के औपचारिक मॉडल बनाना (संगठन प्रक्रिया परिभाषा );

एक सुधार तंत्र को ट्रिगर करता है (योजना-करें-जांच-कार्रवाई)सभी वर्णित प्रक्रियाएँ (एसडब्ल्यूपी)सभी पाँचों के सुसंगत कार्यान्वयन के माध्यम से सामान्य सुविधाएं-सेमी। चावल। 5.

इस प्रकार, यदि आप केपीए सीएमएम को बीपी के रूप में उपयोग करते हैं और सॉफ्टवेयर विकसित करने के लिए परियोजना प्रबंधन प्रक्रियाओं के लिए आवश्यकताओं का उपयोग करते हैं पीएम बोके,तब इस तरह से निर्मित क्यूएमएस का मूल्यांकन किया जा सकता है सीएमएम लेवल 4 - सेमी. चावल। 7.

चावल। 7. आईएसओ 9000 क्यूएमएस मॉडल और पीएम बीओके 2000 गाइड का एक साथ उपयोग करके सीएमएम स्तर 4 प्राप्त करने की योजना।

निष्कर्ष में, स्पष्टता के कारणों के आधार पर (लेखक की शैली में), मैं आईएसओ 9000 और सीएमएम मॉडल के लगातार कार्यान्वयन के साथ एक आईटी कंपनी के क्यूएमएस के कामकाज का एक आरेख प्रस्तुत करता हूं - देखें। चावल। 8.

चावल। 8. आईएसओ 9000 और सीएमएम मॉडल (लेखक की शैलीकरण) के लगातार कार्यान्वयन के साथ क्यूएमएस के कामकाज की योजना

यहां यह समझना महत्वपूर्ण है कि सीएमएम और आईएसओ 9001:2000 दोनों स्वयं निरंतर सुधार के लिए उपकरण मात्र हैं।

इस प्रकार, आईएसओ 9001:2000 मानक के अनुसार प्रमाणीकरण और प्रमाणपत्र की पुष्टि को कंपनी की प्रक्रियाओं की गुणवत्ता के विकास में योगदान देना चाहिए, जहां प्रक्रिया की गुणवत्ता के विकास का आकलन करने की कसौटी उद्यम का एक नए स्तर पर पहुंचना है। बी.पी.आईयानी उनका मूल्यांकन पहले से ही मॉडल पर आधारित है सीएमएम {3}.

साहित्य

"सॉफ़्टवेयर की गुणवत्ता का आकलन", वी. लिपाएव, सिंटेग, 2001।

आईएसओ 9001:2000. गुणवत्ता प्रबंधन प्रणाली। आवश्यकताएं।

पॉलक एम.सी., कर्टिस बी., क्रिसिस एम.बी., वेबर सी.वी. सॉफ़्टवेयर के लिए क्षमता परिपक्वता मॉडल (एसडब्ल्यू-सीएमएम), संस्करण 1.1। // सीएमयू/एसईआई-93-टीआर-024, - फरवरी, 1993।

एनोटेशन: सॉफ़्टवेयर विकास प्रक्रियाओं में सुधार के लिए संभवतः सबसे प्रसिद्ध पद्धति - सीएमएम - में अंतर्निहित विचारों की श्रृंखला का विस्तार से अध्ययन किया गया है। एचएमएम के तर्क और संरचना का विश्लेषण किया जाता है। एचएमएम और पहले अध्ययन किए गए प्रक्रिया मॉडल के बीच संबंध दिखाया गया है।

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

SMM के उद्भव का इतिहास इस प्रकार है। 80 के दशक के अंत में. पिछली शताब्दी में, अमेरिकी रक्षा विभाग ने इंस्टीट्यूट ऑफ सॉफ्टवेयर इंजीनियरिंग 1eng का आदेश दिया था। एसईआई - सॉफ्टवेयर इंजीनियरिंग संस्थानकार्नेगी मेलन विश्वविद्यालय सॉफ्टवेयर विकास परियोजनाओं में उपठेकेदारों के चयन के लिए मानदंड की एक प्रणाली बनाने पर काम कर रहा है। काम 1991 में पूरा हुआ और परिणाम सीएमएम मॉडल था। यह तुरंत आरक्षण करना आवश्यक है कि मॉडल में कोई वित्तीय, आर्थिक, राजनीतिक, संगठनात्मक शामिल नहीं है चयन मानदंडउपठेकेदार, साथ ही वर्गीकृत कार्य तक पहुंच की संभावना के मानदंड (शायद ऐसे कार्य निर्धारित नहीं किए गए थे)। हम केवल उन मानदंडों के बारे में बात कर रहे हैं जो सॉफ्टवेयर सिस्टम विकसित करने के संदर्भ में संभावित उपठेकेदार की क्षमताओं का वर्णन करते हैं।

सीएमएम संरचना

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

धारणा 1. परिपक्वता के गुणात्मक रूप से भिन्न स्तर होते हैं डिज़ाइन संगठन, विकसित होना जानकारी के सिस्टम(एचएमएम मॉडल में ऐसे पांच स्तर हैं)।

अनुमान 2. प्रत्येक विकास संगठन परिपक्वता के उच्च स्तर पर जाने में रुचि रखता है (न केवल रक्षा विभाग के अनुबंधों के लिए प्रतिस्पर्धा में अपनी संभावनाओं को बढ़ाने के लिए, बल्कि अपने स्वयं के सुधार के उद्देश्य से भी)।

अनुमान 3. क्रम में अगले स्तर तक ही संक्रमण संभव है। एक स्तर पर "कूदना" असंभव है (अधिक सटीक रूप से, संगठन के लिए जोखिम तेजी से बढ़ जाते हैं)।

इस प्रकार, स्तर एक "सीढ़ी" बनाते हैं जिसके साथ संगठन विकसित होते हुए ऊपर उठता है। प्रत्येक स्तर को संगठन की प्रक्रियाओं की एक निश्चित संरचना और गुणों की विशेषता होती है। एसएमएम की "स्तरों की सीढ़ी" को व्यापक मान्यता और प्रसार प्राप्त हुआ है। वह ऐसी दिखती है.

स्तर 1 "शुरुआती". समग्र रूप से उत्पादन प्रक्रिया को हर बार एक विशिष्ट परियोजना के लिए बनाया जाता है, और कभी-कभी अराजक भी माना जाता है। केवल कुछ प्रक्रियाएं परिभाषित हैं, और परियोजना की सफलता व्यक्तियों के प्रयासों पर निर्भर करती है।

लेवल 2 "दोहराने योग्य". बुनियादी परियोजना प्रबंधन प्रक्रियाएं स्थापित की गई हैं जो आपको लागतों को ट्रैक करने, कार्य अनुसूची और निर्मित सॉफ़्टवेयर समाधान की कार्यक्षमता की निगरानी करने की अनुमति देती हैं। समान अनुप्रयोग विकास परियोजनाओं में पिछली सफलताओं को दोहराने के लिए आवश्यक प्रक्रिया अनुशासन स्थापित किया गया है।

लेवल 3 "परिभाषित". उत्पादन प्रक्रिया को प्रबंधन और डिज़ाइन दोनों के लिए प्रलेखित और मानकीकृत किया गया है। यह प्रक्रिया संगठन की मानक उत्पादन प्रक्रिया में एकीकृत है। सभी परियोजनाएं संगठन की मानक विनिर्माण प्रक्रिया के अनुमोदित, अनुकूलित संस्करण का उपयोग करती हैं।

लेवल 4 "प्रबंधित". उत्पादन प्रक्रिया और निर्मित उत्पाद की गुणवत्ता के विस्तृत मात्रात्मक संकेतक एकत्र किए जाते हैं। उत्पादन प्रक्रिया और उत्पाद दोनों का मूल्यांकन और नियंत्रण मात्रात्मक दृष्टिकोण से किया जाता है।

स्तर 5 "अनुकूलन". प्रक्रिया से मात्रात्मक प्रतिक्रिया और उसमें उन्नत विचारों और प्रौद्योगिकियों के कार्यान्वयन के माध्यम से निरंतर प्रक्रिया सुधार प्राप्त किया जाता है।

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

आगे क्या होता है, जैसा कि वे कहते हैं, तकनीक का मामला है। मॉडल की संरचना निर्धारित की जाती है (चित्र 7.1), परिभाषाएँ दी जाती हैं, और प्रत्येक स्तर पर प्रत्येक प्रक्रिया का सटीक वर्णन करने के लिए श्रमसाध्य कार्य शुरू होता है। जो किया गया है उसके व्यावहारिक मूल्य का मूल्यांकन करने के लिए, हम इस मार्ग पर चलेंगे।

चावल। 7.1.

चित्र में. 7.1 में निम्नलिखित अवधारणाएँ शामिल हैं।

मुख्य प्रक्रिया समूह. जैसा कि (पॉल्क, एट अल., 1995) में कहा गया है, "प्रमुख प्रक्रियाओं का प्रत्येक समूह संबंधित गतिविधियों के एक ब्लॉक को परिभाषित करता है, जिसके परिणामस्वरूप लक्ष्यों का एक सेट प्राप्त होता है जो उत्पादन प्रक्रिया की उत्पादकता बढ़ाने के लिए महत्वपूर्ण हैं। उदाहरण के लिए, प्रमुख प्रक्रियाओं के समूह के लिए" आवश्यकता प्रबंधन"(चित्र 7.2 देखें) लक्ष्य ग्राहक और डेवलपर के बीच एक सॉफ्टवेयर विकास परियोजना की आवश्यकताओं में सामंजस्य स्थापित करना है।"

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

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

विशेषण "कुंजी" का तात्पर्य है कि वहाँ हैं प्रक्रिया समूह(यानी, प्रथाओं का एक सेट) जो एक विशिष्ट परिपक्वता स्तर के दृष्टिकोण से महत्वपूर्ण नहीं हैं, यानी, इस स्तर के लक्ष्यों को प्राप्त करने से संबंधित नहीं हैं (नीचे देखें)। एचएमएम मॉडल हर चीज़ का वर्णन नहीं करता है प्रक्रिया समूहसॉफ्टवेयर विकास और रखरखाव से संबंधित। यह केवल उन समूहों का वर्णन करता है जिन्हें उत्पादन प्रक्रिया में उत्पादकता के प्रमुख निर्धारक के रूप में पहचाना जाता है।

लक्ष्य. एचएमएम में लक्ष्य प्रक्रियाओं से नहीं, बल्कि प्रमुख प्रक्रियाओं के समूहों से जुड़े हैं। जैसा कि ऊपर उल्लेख किया गया है, प्रमुख प्रथाओं के कार्यान्वयन के माध्यम से लक्ष्य प्राप्त किए जाते हैं। सीएमएम में, एक लक्ष्य प्राप्त करने का मतलब है कि, सबसे पहले, प्रमुख प्रथाओं को पूरा करने के बाद, वांछित परिणाम प्राप्त किया जाता है, और दूसरे, यह काफी लगातार प्राप्त किया जाता है। प्रमुख प्रक्रियाओं के समूह के उद्देश्यों को प्राप्त करने का तरीका अंतर के आधार पर परियोजना दर परियोजना भिन्न हो सकता है विषय क्षेत्रया पर्यावरण.

यदि ये लक्ष्य सभी परियोजनाओं के लिए हासिल किए जाते हैं, तो इसका मतलब है कि संगठन उत्पादन प्रक्रिया की परिपक्वता के स्तर तक पहुंच गया है, जिससे प्रमुख प्रक्रियाओं का यह समूह जुड़ा हुआ है।

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

प्रदर्शन दायित्व

उन गतिविधियों का वर्णन करें जो किसी संगठन को किसी प्रक्रिया की स्थापना और स्थिरता सुनिश्चित करने के लिए करनी चाहिए। कार्यान्वयन प्रतिबद्धताएँ आम तौर पर संगठनात्मक नीतियों की स्थापना और वरिष्ठ प्रबंधन से समर्थन से संबंधित होती हैं।

आवश्यक शर्तें

उन पूर्व शर्तों का वर्णन करें जिन्हें किसी उत्पादन प्रक्रिया के सक्षम कार्यान्वयन के लिए किसी परियोजना या संगठन में पूरा किया जाना चाहिए; आमतौर पर संसाधनों, संगठनात्मक संरचनाओं और आवश्यक प्रशिक्षण से संबंधित होते हैं।

संचालन किया गया

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

माप और विश्लेषण

अनुभाग "माप और

"प्रमुख प्रक्रियाओं का प्रत्येक समूह प्रमुख प्रथाओं द्वारा व्यक्त किया जाता है, जिसका कार्यान्वयन समूह के लक्ष्यों की प्राप्ति में योगदान देता है। मुख्य प्रथाएं बुनियादी ढांचे और संचालन का वर्णन करती हैं जो प्रमुख प्रक्रियाओं के समूह के प्रभावी कार्यान्वयन और स्थापना में सबसे बड़ा योगदान देती हैं।

प्रत्येक मुख्य अभ्यास में एक वाक्य होता है, जिसे अक्सर अधिक विस्तृत विवरण में विस्तारित किया जाता है जिसमें उदाहरण और स्पष्टीकरण शामिल हो सकते हैं। कोर प्रथाएँ, जिन्हें कभी-कभी शीर्ष-स्तरीय कोर प्रथाएँ भी कहा जाता है, प्रमुख प्रक्रियाओं के समूह के लिए बुनियादी नीतियों, प्रक्रियाओं और संचालन को स्थापित करती हैं। विस्तृत विवरण के घटकों को अक्सर उप-प्रथाएँ कहा जाता है।"

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

आईटी प्रबंधन गतिविधियों का एक दृश्य, जिसमें प्रक्रियाओं के बजाय, उनके घटकों - प्रमुख प्रथाओं पर विचार किया जाता है, और प्रक्रियाएं केवल वस्तुतः मौजूद होती हैं, जैसे कि कुछ ऐसा जो प्रमुख प्रथाओं से बनाया जा सकता है, पहली नज़र में कुछ हद तक विदेशी लगता है। अब तक, आईटी प्रबंधन में सुधार का कार्य एक संदर्भ प्रक्रिया मॉडल से तैयार प्रक्रियाओं को शुरू करके हल किया गया था। अब ऐसे कई स्तर हैं जिनमें अलग-अलग (यानी, प्रक्रियाओं में एकीकृत नहीं) प्रमुख प्रथाएं और स्तरों के माध्यम से प्रगति का एक अनुशंसित क्रम शामिल है। सीएमएम के अनुसार, जैसे-जैसे यह परिपक्वता के उच्च स्तर की ओर बढ़ता है, आईटी प्रशासन में सुधार होता है। ऐसी उन्नति से क्या होता है?

स्तरों की परिभाषा में (चित्र 7.2 देखें), "उत्पादन प्रक्रिया" जैसी अवधारणा दिखाई दी। यह प्रमुख प्रक्रियाओं के समूह की परिभाषा में भी मौजूद है, और यह कोई संयोग नहीं है। उत्पादन प्रक्रिया, या, जैसा कि इसे एसएमएम में सटीक रूप से कहा जाता है, संगठन की मानक उत्पादन प्रक्रिया (एसपीपीओ), पूरे मॉडल की केंद्रीय अवधारणाओं में से एक है।

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

मॉडल में मुख्य बात है एस एम एमसंगठनात्मक परिपक्वता की अवधारणा है.

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

प्रौढ़यदि निम्नलिखित शर्तें पूरी होती हैं तो एक संगठन पर विचार किया जाता है:

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

तो मानक एस एम एमएक गुणवत्ता आश्वासन मॉडल है जिसमें किसी संगठन की परिपक्वता का आकलन करने के लिए मानदंड और मौजूदा प्रक्रियाओं में सुधार के लिए नुस्खे शामिल हैं। मॉडल में एस एम एमसंगठनों की परिपक्वता के पाँच स्तर परिभाषित किए गए हैं, जिनकी विशेषताएँ चित्र में प्रस्तुत की गई हैं। 5.3.

चावल। 5.3. मॉडल परिपक्वता के पाँच स्तरएस एम एम

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

यह माना जाना चाहिए कि प्रारंभिक स्तर पर, तनावपूर्ण स्थितियों में जो मानव कारक पर बहुत अधिक निर्भर होती हैं, विकास प्रक्रिया कोड लिखने और न्यूनतम परीक्षण तक सीमित हो जाती है।

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

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

चौथे पर, प्रबंधनीय स्तर (प्रबंधित स्तर)उद्यम मात्रात्मक गुणवत्ता संकेतक स्थापित करता है - सॉफ्टवेयर उत्पादों और समग्र रूप से उनके निर्माण की प्रक्रियाओं दोनों के लिए। इस प्रकार, विभिन्न परियोजना संकेतकों के अंतर को कम करके बेहतर परियोजना प्रबंधन हासिल किया जाता है। इस मामले में, कार्यान्वित सॉफ़्टवेयर निर्माण प्रक्रियाओं की सार्थक (संकेत) विविधताओं को प्रक्रिया के यादृच्छिक (शोर) विविधताओं से अलग किया जाता है।

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

सुधार मॉडल

आवश्यकताओं की प्रक्रियाओं में सुधार

उत्पादन को व्यवस्थित करने के एक तरीके के रूप में गुणवत्ता प्रबंधन प्रतिमान बहुत समय पहले सामने आया था। ISO9000 मानकों के समूह में अंतर्निहित विचार 1) , विशेष रूप से, युक्तिकरण प्रस्तावों, सलाह आदि के समर्थन के रूप में ऐसे "सोवियत" आविष्कारों में निहित हैं।

प्रक्रिया-उन्मुख व्यावसायिक संगठन की आधुनिक अवधारणा में, निरंतर गुणवत्ता सुधार की प्रक्रिया प्रमुख पदों में से एक है।

सॉफ्टवेयर उद्योग के संबंध में, ISO9000 श्रृंखला के अलावा, सबसे सफलतापूर्वक सिद्ध गुणवत्ता मानक SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), बूटस्ट्रैप, TickIT हैं।

पश्चिम में गुणवत्ता प्रबंधन विधियों का सक्रिय परिचय 1960 के दशक की शुरुआत में शुरू हुआ। आईएसओ9000 श्रृंखला मानक सीपीआई (सतत प्रक्रिया सुधार) और टीक्यूएम (कुल गुणवत्ता प्रबंधन) दृष्टिकोण के दर्शन पर आधारित हैं। युद्ध के बाद जापान की आर्थिक सुधार काफी हद तक टीक्यूएम में निहित विचारों के कारण थी।

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

इसलिए, कोई भी कार्य शुरू करने से पहले, आपको प्रश्नों के उत्तर प्राप्त करने चाहिए: क्या करने की आवश्यकता है, कौन जाँच करेगा कि क्या किया गया है, इसे कैसे किया जाना चाहिए और यह कैसे निर्धारित किया जाए कि कार्य पूरा हो गया है? आपको यह भी विचार करने की आवश्यकता है कि आप इस प्रक्रिया को कैसे प्रबंधित करेंगे और इसे कैसे बेहतर बनाया जा सकता है।

ISO9000 के मूल सिद्धांत:

• ग्राहकों की जरूरतों पर एकाग्रता;
• प्रबंधन की सक्रिय नेतृत्वकारी भूमिका;
• सुधार प्रक्रियाओं में कलाकारों को शामिल करना;
• प्रक्रिया दृष्टिकोण का कार्यान्वयन;
• प्रबंधन के लिए व्यवस्थित दृष्टिकोण;
• निरंतर सुधार सुनिश्चित करना;
• तथ्य-आधारित निर्णय लेना;
• आपूर्तिकर्ताओं के साथ पारस्परिक रूप से लाभप्रद संबंध।

इस समूह के मानकों का निस्संदेह लाभ इस तथ्य के कारण है कि दुनिया भर के कई उद्यमों में उनका परीक्षण किया गया है। हालाँकि, इन मानकों की सिफारिशें काफी सामान्य हैं और आईटी उद्योग में उद्यमों की विशिष्टताओं को ध्यान में नहीं रखती हैं। इसे प्राप्त करने के लिए, विशेष दृष्टिकोण विकसित किए गए हैं, जिनकी चर्चा नीचे की गई है।

सीएमएम (क्षमता परिपक्वता मॉडल) मानक कार्नेगी मेलन विश्वविद्यालय में सॉफ्टवेयर इंजीनियरिंग संस्थान (एसईआई) द्वारा विकसित किया गया था।

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

2000 में, SEI ने CMMI-SE/SW जारी किया, जो सॉफ्टवेयर और सिस्टम डिज़ाइन क्षमताओं दोनों में सुधार के लिए एक एकीकृत मॉडल है।

सीएमएमआई-एसई/एसडब्ल्यू के दो रूप हैं। चरणबद्ध प्रतिनिधित्व स्तर के नामों के मामूली स्पष्टीकरण के साथ एसडब्ल्यू-सीएमएम संरचना से मेल खाता है। पांच परिपक्वता स्तरों में 22 प्रक्रिया क्षेत्र शामिल हैं, जिन्हें तालिका 14.1 में दिखाया गया है। (सीएमयू/एसईआई, 2000ए)। निरंतर प्रतिनिधित्व एक अलग दृष्टिकोण लेता है: समान 22 क्षेत्रों को 4 श्रेणियों में संरचित किया गया है: प्रक्रिया प्रबंधन, परियोजना प्रबंधन, निर्माण और समर्थन (सीएमयू/एसईआई, 2000बी)।

परिपक्वता स्तरों के बजाय, निरंतर दृश्य प्रत्येक प्रक्रिया क्षेत्र के लिए छह क्षमता स्तरों को परिभाषित करता है। यह दृश्य प्रत्येक संगठन को यह निर्णय लेने की अनुमति देता है कि वह 22 प्रक्रिया क्षेत्रों में से प्रत्येक में किस स्तर की क्षमता के लिए योग्य है।

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

आवश्यकताएँ प्रबंधन प्रक्रिया क्षेत्र

मुख्य विषयों में शामिल है कि कैसे विकास टीम को आवश्यकताओं की समझ हासिल करनी चाहिए और ग्राहकों के साथ मुद्दों को हल करना चाहिए, आवश्यकताओं के काम में परियोजना के सदस्यों को शामिल करना चाहिए और परिवर्तन का प्रबंधन करना चाहिए। एसडब्ल्यू-सीएमएम के विपरीत, ट्रेसिंग (प्रमुख आवश्यकताओं गुणों में से एक) विचाराधीन प्रक्रिया क्षेत्र में शामिल है। मानक निम्नलिखित रूटिंग गुणों पर चर्चा करता है:

• निम्न-स्तरीय या माध्यमिक आवश्यकताओं के स्रोतों को दर्ज करना सुनिश्चित करना;
• प्रत्येक आवश्यकता को द्वितीयक आवश्यकताओं तक खोजना और उसे कार्यों, वस्तुओं, प्रक्रियाओं और निष्पादकों में रखना;
• एक ही प्रकार की आवश्यकताओं के बीच क्षैतिज संबंध स्थापित करना।

आवश्यकताएँ इंजीनियरिंग प्रक्रिया क्षेत्र

सीएमएमआई-एसई/एसडब्ल्यू आवश्यकताओं इंजीनियरिंग तकनीकों के तीन सेटों का वर्णन करता है:

• ऐसी तकनीकें जो ग्राहकों की आवश्यकताओं के एक पूरे सेट को परिभाषित करती हैं, जिनका उपयोग किसी उत्पाद के लिए आवश्यकताओं को विकसित करने के लिए किया जाता है (परियोजना हितधारकों की जरूरतों की पहचान करना; जरूरतों और बाधाओं को ग्राहक आवश्यकताओं में बदलना);
• ऐसी तकनीकें जो किसी उत्पाद के लिए आवश्यकताओं का एक पूरा सेट परिभाषित करती हैं (उत्पाद घटकों को स्थापित करना; उत्पाद घटकों के लिए आवश्यकताओं को निर्धारित करना; इंटरफ़ेस आवश्यकताओं को निर्धारित करना);
• माध्यमिक आवश्यकताओं को प्राप्त करने, आवश्यकताओं को समझने और उन्हें मान्य करने की तकनीकें (परिचालन अवधारणाओं और परिदृश्यों को स्थापित करना; सिस्टम की आवश्यक कार्यक्षमता निर्धारित करना; माध्यमिक आवश्यकताओं का विश्लेषण करना; उत्पाद बनाने की लागत, समय और जोखिम का अनुमान लगाना; आवश्यकताओं को मंजूरी देना)।

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

सीएमएमआई-एसई/एसडब्ल्यू आवश्यकता प्रबंधन, आवश्यकता इंजीनियरिंग और अन्य प्रक्रिया क्षेत्रों के बीच संबंधों को नियंत्रित करता है (चित्र 14.1)।