परिचय

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

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

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

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

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

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

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

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

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

सीएमएमआई परिपक्वता मॉडल की संरचना और सामग्री - 1.1

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

मॉडल विवरण विकल्प एकल योजना के अनुसार बनाए गए हैं, जिसमें सामान्य खंड शामिल हैं:

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

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

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

पांच परिशिष्ट प्रदान करते हैं:

लेकिन- प्रयुक्त साहित्यिक स्रोतों और दस्तावेजों की संरचना, हालांकि, मानकों का उल्लेख नहीं है आईएसओ;

पर- संक्षेप;

से- शब्दावली आधारित शब्दावली आईएसओकेवल चार मानकों में उपयोग किया जाता है आईएसओ 9000, आईएसओ 12207, आईएसओ 15504:1-9, आईएसओ 15288;

डी - परिपक्वता स्तरों द्वारा मॉडल घटकों के गठन के लिए आवश्यकताओं और प्रस्तावों का विवरण;

ई - विकास प्रतिभागियों की सूची सीएमएमआई- परियोजना।

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

परियोजना की योजना बनाइसमें और साथ ही दूसरे मॉडल में शामिल हैं:

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

आवश्यकताएं विकास प्रक्रियाएंएक सॉफ्टवेयर उत्पाद के लिए दोनों मॉडलों में प्रक्रियाओं के समान हैं और इसमें शामिल हैं:

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

आवश्यकता प्रबंधनदोनों मॉडलों में शामिल हैं:

• ग्राहक और डेवलपर्स द्वारा पीएस परियोजना के लिए आवश्यकताओं की स्पष्ट समझ प्राप्त करना;
• सॉफ़्टवेयर उत्पाद के लिए अपनी सभी आवश्यकताओं को पूरा करने के लिए दायित्वों के डेवलपर्स से ग्राहक द्वारा प्राप्त करना;
• ग्राहक और डेवलपर के बीच सहमत पीएस परियोजना के लिए आवश्यकताओं में परिवर्तन का प्रबंधन;
• पीएस परियोजना के लिए घटकों और विशेष प्रक्रियाओं की आवश्यकताओं के लिए सामान्य आवश्यकताओं से परिवर्तनों की शुद्धता सुनिश्चित करना;
• परियोजना विकास प्रक्रियाओं और ग्राहक आवश्यकताओं के बीच विसंगतियों की पहचान और पहचान करना।

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

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

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

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

• प्राप्त की जाने वाली प्रक्रिया के समग्र उद्देश्य;
• परिचयात्मक टिप्पणी और प्रक्रिया कार्यों का एक सामान्य विवरण;
• विशिष्ट प्रक्रिया उद्देश्य;
• प्रक्रिया प्रबंधन;
• प्रक्रिया आवश्यकताओं का विकास;
• अन्य प्रक्रियाओं के साथ बातचीत और इंटरफेस;
• व्यावहारिक लक्ष्य - प्रक्रिया गतिविधियों के आवश्यक परिणाम;
• एक विशेष प्रक्रिया में योजना कार्रवाई;
• प्रक्रिया कार्यान्वयन के परिणामों का विश्लेषण और सत्यापन (अनुमोदन);
• प्रक्रिया की निगरानी और नियंत्रण।

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

मॉडलों पर जोर सीएमएमआईपीएस परियोजना की प्रबंधन प्रक्रियाओं को दिया जाता है। मॉडलों की ये आवश्यकताएं और प्रक्रियाएं व्यावहारिक रूप से मानकों में विनियमित और विस्तृत सिफारिशों के अनुरूप हैं। आईएसओ 9001:2000और जटिल पीएस जीवन चक्र मानकों के प्रोफाइल के मुख्य घटक [ , ]। मानकों के कार्यात्मक वर्गों 4-8 में प्रक्रियाओं के लिए आवश्यकताएं आईएसओ 9001, आईएसओ 9004, आईएसओ 90003सामग्री में पर्याप्त अनुभागों की तुलना मॉडल में की जा सकती है सीएमएमआई(चित्र 1 में, सामग्री ओवरलैप ज़ोन)। प्रक्रियाओं और आवश्यकताओं की समानता में समानता है: संरचना, शब्दावली, संरचना, अनुशंसित प्रबंधन प्रक्रियाओं की सूची, योजना, उपलब्ध संसाधनों के लिए लेखांकन, सॉफ्टवेयर इंजीनियरिंग प्रक्रियाओं का कार्यान्वयन, मूल्यांकन और विशेषज्ञों का संगठन।

चित्र 1. मानकों और परिपक्वता मॉडल की प्रक्रियाओं और आवश्यकताओं की समानता

बड़ी सॉफ्टवेयर परियोजनाओं के पूर्ण जीवन चक्र के समर्थन और विनियमन के दृष्टिकोण से, मॉडल की कमियां सीएमएमआईमौजूदा मानकों की रूपरेखा के संबंध में आईएसओनिम्नलिखित शामिल कर सकते हैं:

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

मानक आईएसओ 15504:1-5:2003-2006उद्यमों द्वारा निष्पादित सॉफ़्टवेयर टूल और सिस्टम बनाने, बनाए रखने और सुधारने की प्रक्रियाओं की परिपक्वता के मूल्यांकन और प्रमाणन को नियंत्रित करता है:

• अपना राज्य स्थापित करने के लिए तकनीकी प्रक्रियाएंऔर उनका सुधार;
• विशिष्ट आवश्यकताओं या ग्राहकों की आवश्यकताओं के वर्गों को पूरा करने के लिए स्वयं की प्रक्रियाओं की उपयुक्तता का निर्धारण करने के लिए;
• प्रदर्शन के लिए इसकी उपयुक्तता की दृष्टि से कुछ संधियाँ PS और सिस्टम के ग्राहकों के साथ।

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

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

मानक में अनुमोदन से निपटा जाता है दो पहलू: किसी विशेष उद्यम के पीएस और सिस्टम की जीवन चक्र प्रक्रियाओं में सुधार करने के लिए और यह निर्धारित करने के लिए कि परियोजना या उद्यम समर्थन प्रक्रियाओं की घोषित परिपक्वता उपयोग की जाने वाली वास्तविक प्रक्रियाओं से मेल खाती है या नहीं। यह मानक के निम्नलिखित पांच भागों में परिलक्षित होता है। आईएसओ 15504:1-5:2003-2006.

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

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

भाग 3 - प्रमाणीकरण के उत्पादन के लिए मार्गदर्शन।परिपक्वता मूल्यांकन प्रक्रियाओं को निष्पादित करने और आवश्यकताओं के कार्यान्वयन की व्याख्या करने के लिए प्रौद्योगिकी का एक सिंहावलोकन प्रदान करता है। यह दर्शाता है: प्रमाणन का प्रदर्शन; परिपक्वता प्रक्रियाओं को निर्धारित करने के लिए माप उपकरण; प्रमाणन उपकरणों का चयन और अनुप्रयोग; प्रमाणनकर्ताओं की क्षमता का आकलन करना; घोषित आवश्यकताओं के अनुप्रमाणन की अनुरूपता का सत्यापन। सत्यापन उपकरण का उपयोग उद्यमों द्वारा उनके अधिग्रहण, विकास, अनुप्रयोग और रखरखाव में सॉफ्टवेयर उत्पादों और प्रणालियों की योजना, प्रबंधन, निगरानी, ​​नियंत्रण और सुधार में किया जा सकता है।

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

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

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

सॉफ्टवेयर उत्पादों के प्रमाणन का संगठन

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

प्रमाणन कार्य एक निकाय या एक परीक्षण प्रयोगशाला की मान्यता के साथ शुरू होता है, एक आवेदन का गठन और प्रस्तुत करना और मान्यता की व्यवहार्यता पर निर्णय के लिए केंद्रीय प्रमाणन निकाय को दस्तावेजों का एक सेट। यदि परीक्षण के परिणाम सकारात्मक हैं, तो एक मान्यता प्रमाण पत्र तैयार किया जाता है और जारी किया जाता है।

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

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

• परीक्षण और परीक्षाओं के गुणवत्ता आश्वासन के क्षेत्र में नीति;
• केंद्र को प्रासंगिक कार्यप्रणाली सामग्री और सॉफ्टवेयर और परीक्षण उपकरणों से लैस करना;
• परीक्षण वस्तुओं के लिए आवश्यकताओं की औपचारिकता;
• केंद्र के तकनीकी उपकरणों और कर्मचारियों के विकास के क्षेत्र में नीति;
• प्रमाणन परिणामों के दस्तावेज़ीकरण का संग्रहण और सुरक्षा नियंत्रण।

प्रमाणीकरण के अधीन उत्पादों या प्रक्रियाओं के मूल्यांकन के लिए, आवेदक प्रमाणन प्रणाली में अपनाए गए फॉर्म में प्रमाणन निकाय को एक आवेदन भेजता है। प्रमाणन निकाय आवेदन पर उत्पाद प्रमाणन की तैयारी और संगठन पर काम करता है। इस कार्य में शामिल हैं:

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

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

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

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

सॉफ्टवेयर उत्पादों और उद्यम गुणवत्ता प्रणालियों के प्रमाणन की प्रक्रिया में शामिल हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• गैर-अनुपालन के कारणों की पहचान करना और उन्हें समाप्त करना;
• उत्पाद की गुणवत्ता में सुधार और सुनिश्चित करने के लिए किए गए कार्यों पर एक रिपोर्ट के प्रमाणन निकाय को प्रस्तुत करना;
• विधियों के अनुसार और प्रमाणन निकाय के नियंत्रण में उत्पादों के अतिरिक्त परीक्षण करना और सकारात्मक परिणाम प्राप्त करना।

प्रक्रियाओं का दस्तावेजीकरण और सॉफ्टवेयर उत्पादों के प्रमाणन के परिणाम

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

प्रमाणन के लिए बुनियादी दस्तावेजों के एक सांकेतिक सेट में तीन समूह होते हैं:

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

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

उद्यम गुणवत्ता प्रणाली और सॉफ्टवेयर जीवन चक्र के बुनियादी दस्तावेज

1. प्रदर्शन सुधार के लिए अवधारणा, शब्दावली, आवश्यकताएं और मार्गदर्शन - गुणवत्ता प्रबंधन प्रणाली - आईएसओ 9000:2000या सीएमएमआई परिपक्वता मॉडल का एक संस्करण।
2. अनुकूलित संस्करण या अनुभागों की सूची और मानकों की सिफारिशें आईएसओ 12207, आईएसओ 15504, उनके परिवर्तन और अनुप्रयोग दिशानिर्देश, अनुकूलन के दौरान चुने गए और किसी विशेष उद्यम या सॉफ़्टवेयर उत्पाद परियोजना की गुणवत्ता प्रणाली में उपयोग के लिए अनिवार्य हैं।
3. अनुकूलित संस्करण या अनुभागों की सूची और मानक की सिफारिशें आईएसओ 900003, अनुकूलन के दौरान चयनित और एक सॉफ्टवेयर उत्पाद का उत्पादन करने वाले उद्यम की गुणवत्ता प्रणाली में उपयोग के लिए अनिवार्य।
4. पीएस परियोजना की बुनियादी विशेषताओं और गुणवत्ता विशेषताओं, मानकों के आधार पर पहचान, अनुकूलित और निर्दिष्ट आईएसओ 12182, आईएसओ 9126, आईएसओ 14598, आईएसओ 25000.
5. मानकों की सिफारिशों के आधार पर रखरखाव और विन्यास प्रबंधन मैनुअल का अनुकूलित संस्करण और अनुमोदित संस्करण आईएसओ 14764, आईएसओ 10007, आईएसओ 15846.
6. नौकरी के विवरण का एक सेट जो एक विशिष्ट पीएस परियोजना के लिए उद्यम गुणवत्ता प्रणाली की प्रक्रियाओं में शामिल कर्मियों के काम के प्रदर्शन और जाँच के लिए जिम्मेदारी, अधिकार और प्रक्रिया को परिभाषित करता है।

किसी विशेष सॉफ़्टवेयर टूल के जीवन चक्र की विशेषताओं को दर्शाने वाले स्रोत दस्तावेज़

1. उद्यम, प्रणाली और उनके जीवन चक्र के बाहरी वातावरण में बनाए गए सॉफ्टवेयर उत्पादों की विशेषताओं का विवरण, पीएस परियोजना के मानकों और आवश्यकताओं के काम के संस्करणों के अनुकूलन और तैयारी के लिए आवश्यक है और उद्यम गुणवत्ता प्रणाली के अनुसार मानकों की सिफारिशें आईएसओ 12207, आईएसओ 15504, आईएसओ 90003तथा आईएसओ 9126.
2. गुणवत्ता प्रणाली के क्षेत्र में उद्यम-डेवलपर के लक्ष्यों, आवश्यकताओं और दायित्वों का विवरण, सॉफ्टवेयर के पूरे जीवन चक्र के विकास, वितरण और समर्थन की प्रक्रियाओं और उत्पादों के लिए गुणवत्ता मानदंड।
3. अनुकूलित मानकों के आधार पर सॉफ्टवेयर उत्पाद के एक विशिष्ट संस्करण के जीवन चक्र और उपयोग को सुनिश्चित करने के लिए ग्राहक और उपयोगकर्ताओं को आपूर्ति किए गए परिचालन दस्तावेजों का एक सेट आईएसओ 9294, आईएसओ 15910, आईएसओ 18019.
4. एक सॉफ्टवेयर उत्पाद के जीवन चक्र को सुनिश्चित करने के लिए उपयोग किए जाने वाले डिजाइन, विकास, संशोधन, नियंत्रण और परीक्षण के लिए प्रलेखन और स्वचालन उपकरण।
5. आवेदन के परीक्षण और उद्यम की गुणवत्ता प्रणाली और सॉफ्टवेयर उत्पाद की प्रक्रियाओं की प्रभावशीलता का मूल्यांकन करने के लिए योजनाएं और तरीके।
6. रखरखाव के तरीके, सॉफ्टवेयर उत्पाद घटकों की पहचान और प्रलेखन, विश्लेषण और सॉफ्टवेयर और डेटा परिसरों के संस्करणों का अनुमोदन।
7. कॉन्फ़िगरेशन प्रबंधन, अनुमोदन, भंडारण, सुरक्षा, सॉफ़्टवेयर उत्पाद संस्करणों की प्रतिलिपि बनाने और साथ में दस्तावेज़ों के साथ-साथ सॉफ़्टवेयर उत्पाद संस्करणों के जीवन चक्र के दौरान एंटरप्राइज़ संग्रह में पंजीकृत गुणवत्ता विशेषताओं पर डेटा के संचय और भंडारण के लिए कार्यप्रणाली।

परिणामी परीक्षण दस्तावेज - उद्यम और / या सॉफ्टवेयर उत्पाद की गुणवत्ता प्रणाली का प्रमाणन

1. उद्यम गुणवत्ता प्रणाली की आवश्यकताओं और प्रावधानों के अनुकूल प्रलेखन की उपलब्धता, प्रासंगिकता और व्यवस्थित निष्पादन पर एक रिपोर्ट, जो सॉफ्टवेयर उत्पाद के पूरे जीवन चक्र में एक एकीकृत गुणवत्ता आश्वासन प्रक्रिया प्रदान करती है।
2. गुणवत्ता प्रणाली की स्थिति और अनुप्रयोग की निगरानी और परीक्षण के परिणाम, इसकी उपयुक्तता और प्रभावशीलता को निर्धारित करने के लिए समय-समय पर किए जाते हैं।
3. ग्राहक के साथ प्रमाणन समझौते की आवश्यकताओं को पूरा करने के लिए प्राप्त गुणवत्ता के परिणामों पर निरीक्षण और प्रलेखित रिपोर्ट आयोजित करने के तरीकों की उपलब्धता और रखरखाव पर रिपोर्ट।
4. सॉफ्टवेयर पैकेज की प्राप्त गुणवत्ता विशेषताओं के पंजीकरण के परिणाम: सॉफ्टवेयर उत्पाद और उसके घटकों की गुणवत्ता की विशेषताओं और विशेषताओं पर पंजीकृत डेटा की पहचान, संचय, भंडारण।
5. विकास योजना के कार्यान्वयन के परिणाम, पीएस के जीवन चक्र के कार्यान्वयन की जाँच के लिए विकास चरणों और प्रोटोकॉल के प्रलेखित इनपुट और आउटपुट डेटा।
6. गुणवत्ता कार्यक्रम के व्यावहारिक कार्यान्वयन और पीएस के जीवन चक्र के सभी चरणों में गुणवत्ता के क्षेत्र में विनियमित गतिविधियों के कार्यान्वयन के परिणाम।
7. पर्यावरण सिमुलेटर और परीक्षण जनरेटर के प्रमाणीकरण के परिणाम, साथ ही एक सॉफ्टवेयर उत्पाद के प्रमाणन परीक्षण करने के लिए उनकी पर्याप्तता का आकलन।
8. योजनाओं और परीक्षण विधियों के कार्यान्वयन के विश्लेषण के परिणाम, परीक्षण रिपोर्ट, आवश्यकताओं के साथ परीक्षण के परिणामों के अनुपालन का आकलन, साथ ही आवेदक, ग्राहक और आपूर्तिकर्ता के प्रतिनिधियों द्वारा अनुमोदित परीक्षा परिणाम।
9. सॉफ्टवेयर सिस्टम के जीवन चक्र की वास्तविक विशेषताओं और उद्यम की गुणवत्ता प्रणाली के सत्यापन के परिणामों का कार्य, एक सॉफ्टवेयर उत्पाद के उत्पादन के प्रमाणन के लिए आवश्यकताओं के अनुपालन के बारे में निष्कर्ष।
10. उद्यम और / या सॉफ्टवेयर उत्पाद की गुणवत्ता प्रणाली का प्रमाण पत्र और इसके जीवन चक्र को सुनिश्चित करना, अनुरूपता चिह्नों के उपयोग के लिए लाइसेंस।

साहित्य

वी.वी. लिपेव -- सॉफ्टवेयर जीवन चक्र मानक प्रोफाइल। -- जेट इंफो, न्यूजलेटर, एन 12 , 2005

के. मिलमैन, एस. मिलमैन -- एसएमएमआई भविष्य में एक कदम है। -- ओपन सिस्टम।, एन 5-6। (2005), एन 2। (2006), 2005, 2006

सॉफ्टवेयर उपकरण और सूचना प्रणाली आईएसओ आईईसी टीआर 15504-सीएमएमआई बनाने और बनाए रखने के लिए प्रक्रियाओं की परिपक्वता का आकलन और प्रमाणीकरण। प्रति. अंग्रेजी से -- एम.: किताब और व्यापार, 2001

वी.वी. लिपेव -- जटिल सॉफ्टवेयर के जीवन चक्र की प्रक्रियाएं और मानक। निर्देशिका।-- एम.: सिनटेग, 2006

वी.वी. लिपेव -- बड़े पैमाने पर सॉफ्टवेयर की गुणवत्ता सुनिश्चित करने के तरीके।- एम .: आरएफबीआर। सिनटेग, 2003

"; एंटीसोर्स: "सॉफ्टवेयर उत्पादों का उपयोग अब मानव गतिविधि के लगभग सभी क्षेत्रों में प्रबंधन समस्याओं को हल करने के लिए किया जाता है: अर्थव्यवस्था, सामाजिक, सैन्य और अन्य क्षेत्रों में। देश और विश्व बाजार में विभिन्न अनुप्रयोगों के लिए बड़े पैमाने पर विकास और वितरण के दौरान घरेलू सॉफ्टवेयर उत्पादों की उच्च गुणवत्ता सुनिश्चित करना एक रणनीतिक कार्य बन गया है।"; शर्त: 1] $

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

चावल। 7.1

अंजीर पर। 7.1 में निम्नलिखित अवधारणाएँ हैं।

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

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

चावल। 7.2.

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

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

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

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

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

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

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

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

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

संचालन जारी

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

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

खंड "माप और

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

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

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

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

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

नवंबर 1986 में, अमेरिकन सॉफ्टवेयर इंजीनियरिंग इंस्टीट्यूट (SEI) ने Miter Corporation के साथ मिलकर एक सॉफ्टवेयर डेवलपमेंट प्रोसेस मैच्योरिटी रिव्यू विकसित करना शुरू किया, जिसका उद्देश्य उनकी आंतरिक प्रक्रियाओं को बेहतर बनाने में मदद करना था।

इस समीक्षा के विकास को सॉफ्टवेयर विकास के लिए उप-ठेकेदारों के मूल्यांकन के लिए एक विधि के लिए अमेरिकी संघीय सरकार के अनुरोध से प्रेरित किया गया था। वास्तविक समस्या प्रबंधन करने में असमर्थता थी बड़ी परियोजनाएं. कई कंपनियों में, परियोजनाओं को काफी देर से और अधिक बजट में वितरित किया गया था। इस समस्या का समाधान खोजना जरूरी था।

सितंबर 1987 में, SEI ने जारी किया संक्षिप्त समीक्षासॉफ्टवेयर विकास प्रक्रियाओं को उनके परिपक्वता स्तरों के विवरण के साथ-साथ कंपनी में उन क्षेत्रों की पहचान करने के लिए डिज़ाइन किया गया एक प्रश्नावली जिसमें सुधार की आवश्यकता थी। हालाँकि, अधिकांश कंपनियों ने इस प्रश्नावली को एक तैयार मॉडल के रूप में माना, जिसके परिणामस्वरूप, 4 वर्षों के बाद, प्रश्नावली को एक वास्तविक मॉडल, सॉफ्टवेयर के लिए क्षमता परिपक्वता मॉडल (CMM) में बदल दिया गया। 1991 में जारी CMM (संस्करण 1.0) का पहला संस्करण 1992 में कार्यकारी बैठक के प्रतिभागियों द्वारा संशोधित किया गया था, जिसमें लगभग 200 सॉफ्टवेयर विशेषज्ञों और डेवलपर समुदाय के सदस्यों ने भाग लिया था।

1. प्राथमिक। संगठन की सबसे आदिम स्थिति। संगठन सॉफ्टवेयर विकसित करने में सक्षम है। संगठन के पास स्पष्ट रूप से जागरूक प्रक्रिया नहीं है, और उत्पाद की गुणवत्ता पूरी तरह से डेवलपर्स की व्यक्तिगत क्षमताओं से निर्धारित होती है। एक पहल करता है और टीम उसके निर्देशों का पालन करती है। एक परियोजना की सफलता दूसरे की सफलता की गारंटी नहीं देती है। परियोजना के अंत में, श्रम लागत, अनुसूची और गुणवत्ता पर डेटा दर्ज नहीं किया जाता है।
2. दोहराने योग्य कुछ हद तक, प्रक्रिया की निगरानी की जाती है। रिकॉर्ड श्रम लागत और योजनाओं से बने होते हैं। प्रत्येक परियोजना की कार्यक्षमता लिखित रूप में वर्णित है। 1999 के मध्य में, केवल 20% संगठन स्तर 2 या उच्चतर थे।
3. स्थापित। एक परिभाषित, प्रलेखित और स्थापित प्रक्रियाव्यक्तियों से स्वतंत्र कार्य। यानी सहमत पेशेवर मानक, और डेवलपर्स उन्हें लागू करते हैं। इस तरह के संगठन पहले पूरी की गई परियोजनाओं के समान ही परियोजनाओं की लागत का काफी मज़बूती से अनुमान लगाने में सक्षम हैं।
4. प्रबंधित। वे काम के समय और लागत का सटीक अनुमान लगा सकते हैं। संचित माप का एक डेटाबेस है। लेकिन नई तकनीकों और प्रतिमानों के उदय के साथ कोई बदलाव नहीं आया है।
5. अनुकूलित। नई और बेहतर विधियों और उपकरणों को खोजने और उसमें महारत हासिल करने के लिए एक सतत प्रक्रिया है।

विकास

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

यह सभी देखें

लिंक

एमआईटी छात्र मंच> मुख्य खंड> परीक्षण> नियंत्रण प्रणाली सिमुलेशन

राय पूर्ण संस्करण: नियंत्रण प्रणाली का अनुकरण

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

अंतिम परीक्षा 100 में से 100

क्या परिणाम हर बार अलग होता है?

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

मॉड्यूल 1:
व्यवसाय प्रक्रिया की पहचान के रूप में क्या नहीं माना जाना चाहिए?

मूल्य संवर्धन

एक उत्तर चुनें:
एक प्रक्रिया का एक उत्पाद जो पहले से निर्धारित लक्ष्यों का प्रतीक है

एक उत्तर चुनें:

फाइनल में (4 पर पारित किया गया।

क्षमता परिपक्वता मॉडल क्या है? (सीएमएम)

ये प्रश्न + जो पहले से ही मंच पर हैं):
1. सही कथन चुनें।
एक उत्तर चुनें:
डिवीजनों की व्यावसायिक प्रक्रिया में विभिन्न मूल्य श्रृंखलाएं होती हैं (UNSURE)
एंड-टू-एंड बिजनेस प्रोसेस में बिजनेस प्रोसेस होते हैं विभिन्न संगठन
क्रॉस-फ़ंक्शनल व्यवसाय प्रक्रिया, एक नियम के रूप में, विभागों की व्यावसायिक प्रक्रियाएँ शामिल हैं

2. यूनिवर्सल बिजनेस प्रोसेस फ्लो चार्ट का एक तत्व क्या नहीं है?
एक या अधिक उत्तर चुनें:
प्रक्रिया संसाधन
जोखिम
व्यवसाय प्रक्रिया प्रबंधन गतिविधियाँ
वातावरणीय कारक
इनपुट को आउटपुट में बदलने की गतिविधि

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

28.03.2014, 10:07

मॉड्यूल 1:
क्या व्यवसाय प्रक्रिया की पहचान नहीं मानी जानी चाहिए? एक या अधिक उत्तर चुनें:
इनपुट को आउटपुट में बदलना
बाहरी उपभोक्ता को उत्पाद की डिलीवरी
मूल्य संवर्धन
अधिशेष और/या उपयोग मूल्य का गठन

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

व्यवसाय प्रक्रिया के भीतर प्रतिक्रिया क्या है?
एक उत्तर चुनें:
वांछित परिणाम सुनिश्चित करने के लिए डिज़ाइन की गई प्रक्रिया पर उद्देश्यपूर्ण और सचेत प्रभाव
पहले से निर्धारित लक्ष्यों के साथ प्रक्रिया के परिणामों का विश्लेषण और तुलना
वस्तुओं की प्रणाली और पर्यावरण के कारकों पर प्रभाव, जो प्रणाली के कामकाज में विभिन्न प्रकार के विचलन के स्रोत हैं
मैंने ऐसा उत्तर दिया! लेकिन यह अभी भी निकला 4

फाइनल में - ये प्रश्न + वे जो पहले से मौजूद हैं:
1 सूची से डिजाइन-लक्षित संरचनाओं की कमियों का चयन करें।

2 सूची से कमांड उपयोग के उदाहरण चुनें।
गुणवत्ता मग
समितियों
कार्य दल

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

4 सूची से परियोजना-आधारित संगठनात्मक संरचनाओं के लाभों का चयन करें।
परियोजना प्रबंधक को कर्मचारियों की प्रत्यक्ष अधीनता और इस प्रकार इन कर्मचारियों के प्रयासों की दिशा की अस्पष्टता हासिल की जाती है

5 सहायक प्रक्रियाएं:
प्रदान करना प्रभावी कार्यान्वयनमुख्य प्रक्रियाएं

अंतिम ग्रेड 5
प्रश्न 1
कमांड उपयोग उदाहरणों की सूची में से चुनें।

गुणवत्ता मग
समितियों
कार्य दल

प्रश्न 2
कार्यात्मक संरचना के भीतर बिचौलियों का क्या उपयोग किया जाता है?

विभिन्न संरचनात्मक प्रभागों की गतिविधियों को एकीकृत करने के लिए

प्रश्न 3
SADT मॉडल में संबंधों के प्रकारों के नाम बताइए:
नियंत्रण
निकास तंत्र
इनपुट फीडबैक

प्रश्न 4
निम्नलिखित में से कौन सी व्यावसायिक प्रक्रिया सबसे छोटी है?
डिवीजन व्यापार प्रक्रिया

प्रश्न 5
व्यावसायिक प्रक्रिया सूचना मॉडल बनाने के लिए किन विधियों, पद्धतियों और उपकरणों का उपयोग किया जा सकता है?

जिन-सरसन पद्धति
चेन और बार्कर की मॉडलिंग भाषा

प्रश्न 6
कौन सा व्यवसाय प्रक्रिया प्रतिनिधित्व निम्नतम स्तर (सूचीबद्ध लोगों में से) से मेल खाता है?

व्यवसाय प्रक्रिया संचालन

प्रश्न 7
व्यवसाय प्रक्रिया की लंबाई:

यह व्यक्तिपरक है

प्रश्न 8
प्रक्रियाओं के मूल तत्व के रूप में भौतिक संसाधन हैं:

प्रक्रियाओं को अंजाम देने के लिए उपयोग किए जाने वाले निष्क्रिय साधन और गतिविधि की वस्तुएं

प्रश्न 9
सूची से परियोजना-आधारित संगठनात्मक संरचनाओं के लाभों का चयन करें।

परियोजना प्रबंधक को कर्मचारियों की प्रत्यक्ष अधीनता लागू की जाती है और इस प्रकार इन कर्मचारियों के प्रयासों की दिशा की अस्पष्टता प्राप्त होती है

प्रश्न 10
सूची में से मैट्रिक्स संगठनात्मक संरचनाओं के लाभों का चयन करें।

लचीले ढंग से अनुकूलित करने की संभावना संगठनात्मक संरचनाएक विस्तृत स्पेक्ट्रम के भीतर: कमजोर से मजबूत मैट्रिक्स तक

प्रश्न 11
व्यवसाय प्रणाली प्रबंधन के दूसरे लूप में क्या शामिल है?

ऑपरेशन कंट्रोल सबसिस्टम
विकास प्रबंधन उपप्रणाली

प्रश्न 12
व्यवसाय प्रणाली के सामान्य प्रक्रिया मॉडल में निम्नलिखित तत्व शामिल हैं:

बाहर निकलना
प्रक्रिया
प्रवेश
अशांति

प्रश्न 13
कौन सा आईडीईएफ मानक आपको गतिविधियों, प्रवाहों और वस्तुओं की स्थिति को मॉडल करने की अनुमति देता है?

प्रश्न 14
एक मजबूत मैट्रिक्स संरचना में परियोजना प्रबंधक की शक्तियां क्या हैं?

मध्यम से उच्च

प्रश्न 15
निवेश और वित्तीय प्रक्रियाओं के मुख्य तत्वों के लिए क्या जिम्मेदार ठहराया जा सकता है?

निवेशकों
ऋणदाताओं

प्रश्न 16
सूची से डिजाइन-लक्षित संरचनाओं की कमियों का चयन करें।

कार्यात्मक क्षेत्रों में कम विनिर्माण क्षमता

नियंत्रण प्रणाली मॉडलिंग.रार (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

SADT आरेखों में प्रभुत्व का क्रम क्या है?
उत्तर: सबसे प्रमुख कार्य ऊपरी बाएँ कोने में स्थित हैं।

3प्रशिक्षण में मदद करें जिसके पास यह है

1 मिनट के बाद जोड़ा गया
मैं किसी ऐसे व्यक्ति से 3 प्रशिक्षण मांगता हूं जिसके पास मॉडलिंग ऑफ कंट्रोल सिस्टम है

vBulletin® v3.8.7, कॉपीराइट 2000-2018, vBulletin Solutions, Inc.

अनुवाद जो आप कह सकते हैं:

आईएस के विकास के लिए कार्यप्रणाली। सीएमएम/सीएमएमआई मैच्योरिटी मॉडल।

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

कार्नेगी मेलन (सॉफ्टवेयर इंजीनियरिंग इंस्टीट्यूट, एसईआई) ने सॉफ्टवेयर उत्पादों के विकास के लिए सीएमएम परिपक्वता मॉडल (क्षमता परिपक्वता मॉडल) बनाया। समय के साथ, मॉडलों का एक पूरा परिवार जारी किया गया है:

SW-CMM - सॉफ्टवेयर उत्पादों के लिए, SE-CMM - सिस्टम इंजीनियरिंग के लिए, अधिग्रहण CMM - खरीद के लिए, लोग CMM - मानव संसाधन प्रबंधन के लिए, ICMM - उत्पाद एकीकरण के लिए।

विभिन्न प्रकार के मॉडल समझने और कार्यान्वित करने में काफी कठिन साबित हुए। चूंकि वे बनाए गए थे विभिन्न समूहविशेषज्ञ, इन मॉडलों की सामग्री हमेशा एक-दूसरे के साथ-साथ संगत नहीं थी

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

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

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

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

कोरोलरी 2. सीएमएमआई का उपयोग कंपनियों को उनकी प्रक्रियाओं की परिपक्वता के लिए प्रमाणित करने के लिए किया जाता है। प्रारंभ में, 80 के दशक के अंत और 90 के दशक की शुरुआत में, सीएमएम (तब अभी तक सीएमएमआई नहीं) को प्रमाणन के साधन के रूप में बनाया गया था।

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

उदाहरण के लिए, विमानन, एयरोस्पेस उद्योग। यानी सॉफ्टवेयर डेवलपमेंट

अन्य प्रकार के इंजीनियरिंग कार्य के साथ होता है। और अक्सर ऐसा होता है कि एक प्रोजेक्ट में दो से अधिक विभिन्न प्रकार की इंजीनियरिंग शामिल होती है। सीएमएमआई का कार्य ऐसी परियोजनाओं और कंपनियों को विकास प्रक्रिया के आयोजन के लिए एक मंच प्रदान करना है।

शास्त्रीय सीएमएम मॉडल के विपरीत, जो कड़ाई से पदानुक्रमित था और स्तरों द्वारा प्रक्रियाओं के केवल अनुक्रमिक सुधार की अनुमति देता था, सीएमएमआई मॉडल के दो आयाम हैं - अनुक्रमिक, जैसे

सीएमएम के समान, और निरंतर, संगठन में प्रक्रियाओं में कुछ हद तक मनमाने ढंग से सुधार की अनुमति देता है। यहां हम ध्यान देंगे अनुक्रमिक मॉडल. इसके 5 स्तर हैं

प्रक्रिया परिपक्वता (चित्र। 1)।

प्रथम स्तर(परिपक्वता स्तर 1) वह स्तर है जिस पर, परिभाषा के अनुसार, कोई भी कंपनी है। इस स्तर पर, सॉफ्टवेयर विकास कमोबेश अराजक है।

प्रबंधित स्तर(परिपक्वता स्तर 2) - कंपनी स्तर पर स्वीकृत प्रक्रियाओं के आयोजन की नीतियां और प्रक्रियाएं यहां पहले से ही दिखाई देती हैं। लेकिन प्रक्रियाओं की पूरी सीमा केवल व्यक्तिगत परियोजनाओं के ढांचे के भीतर ही मौजूद है।

एक निश्चित स्तर(परिपक्वता स्तर 3) - यहाँ एक मानक प्रक्रिया समग्र रूप से पूरी कंपनी के स्तर पर दिखाई देती है।

क्षमता परिपक्वता मॉडल (सीएमएम) क्या है? सीएमएम स्तर क्या हैं?

यह प्रक्रिया संपत्तियों का एक बड़ा और लगातार बढ़ता हुआ सेट है: दस्तावेज़ टेम्पलेट,

जीवन चक्र मॉडल, सॉफ्टवेयर उपकरण, अभ्यास आदि। इस मानक से काटकर कोई विशिष्ट प्रक्रिया प्राप्त की जाती है।

मात्रात्मक स्तर(परिपक्वता स्तर 4) कंपनी में माप की एक प्रणाली के उद्भव का तात्पर्य है, जो एक मानक प्रक्रिया के आधार पर होती है और विकास के मात्रात्मक प्रबंधन की अनुमति देती है।

अनुकूलन स्तर(परिपक्वता स्तर 5) विकास प्रक्रियाओं में निरंतर सुधार, वृद्धिशील, वृद्धिशील और क्रांतिकारी दोनों का तात्पर्य है। साथ ही, ये परिवर्तन मजबूर नहीं हैं, बल्कि सक्रिय समस्याएं और कठिनाइयाँ हैं। इस प्रक्रिया में अपने आप सुधार किया जा रहा है और लगातार, उपयुक्त तंत्र लागू किया गया है।

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

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

क्षमता परिपक्वता मॉडल (सीएमएम)

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

हालांकि, सूचीबद्ध मॉडलों में से कोई भी सीखना बेहतर है। और अगर पूरे सीआईएस (लगभग 250-300 लोगों) के लिए सीएमएमआई-डीईवी मॉडल में प्रशिक्षित कई सौ लोग हैं, तो सीआईएस में सीएमएमआई-एसवीसी मॉडल में प्रशिक्षित केवल 6 लोग हैं। हम प्रशिक्षितों की बात कर रहे हैं, प्रशिक्षकों की नहीं। दिसंबर 2011 तक यह मुख्य समस्या थी: सीएमएमआई-डीईवी के लिए, पूरी दुनिया में एसईआई (सीएमएमआई मॉडल डेवलपर) द्वारा प्रमाणित केवल एक रूसी-भाषी प्रशिक्षक था, और अन्य मॉडलों के लिए कोई भी नहीं था! अब ऐसा प्रशिक्षक भी सीएमएमआई-एसवीसी मॉडल (इसलिए पहले 6 प्रशिक्षित) के अनुसार सामने आया है। यह प्रशिक्षक इस प्रकाशन का लेखक है, जो उल्लिखित मॉडलों और औपचारिक प्रशिक्षण के बारे में किसी भी प्रश्न का उत्तर देने के लिए उपलब्ध है। पूछना!

यह सामग्री Club.CNews समुदाय के एक सदस्य का एक निजी रिकॉर्ड है।
CNews के संपादक इसकी सामग्री के लिए ज़िम्मेदार नहीं हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

संगठनात्मक प्रक्रियाओं के प्रबंधन में 5 विकासवादी चरण। क्षमता परिपक्वता मॉडल की व्याख्या। सीएमएम

सीएम-सीईआई क्षमता परिपक्वता मॉडल एक संगठनात्मक मॉडल है जो 5 विकासवादी चरणों (स्तरों) का वर्णन करता है जिस पर एक संगठन में प्रक्रियाओं का प्रबंधन किया जाता है।

मूल रूप से सॉफ्टवेयर विकास के लिए बनाया गया, क्षमता परिपक्वता मॉडल की बात यह है कि एक संगठन को अपने सॉफ्टवेयर अनुप्रयोगों को स्वीकार और समर्थन करने में सक्षम होना चाहिए। यह मॉडल संगठन को अगले स्तर तक बढ़ने में मदद करने के लिए ठोस कदम और पहल का भी सुझाव देता है।

क्षमता परिपक्वता मॉडल के 5 चरण

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

सॉफ्टवेयर विकास मॉडल

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

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

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

फ़ीचर डेवलपमेंट मॉडल की संरचना

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

एक प्रक्रिया को परिभाषित करने के लिए मानदंड

एक प्रक्रिया को परिभाषित करने के लिए मानदंड प्रक्रिया तत्वों का एक समूह है जिसे लोगों को व्यवहार में उपयोग करने के लिए एक सॉफ्टवेयर प्रक्रिया विवरण में शामिल करने की आवश्यकता होती है। मानदंड निर्धारित करने के लिए, आपको यह प्रश्न पूछने की आवश्यकता है - "किस जानकारी पर सॉफ्टवेयर प्रक्रियादस्तावेज़ीकरण के लिए आवश्यक है?