आईईईई मानक। प्रोलोज़ोवा एन.ओ., नज़रोवा ओ.बी., डेवलेटकिरीवा एल.जेड.

रखरखाव को हमेशा सॉफ़्टवेयर जीवन चक्र के मुख्य चरणों में से एक के रूप में मान्यता दी गई है। 70 के दशक के मध्य तक, यह पहले से ही माना गया था कि रखरखाव एक ऐसा चरण है जो एक सॉफ्टवेयर टूल को विकसित करने और लागू करने की लागत का 50% से अधिक लेता है।

व्यावसायिक प्रक्रियाओं की निरंतरता और कंपनियों के जीवन के लिए आवश्यक कॉर्पोरेट जानकारी की सुरक्षा समर्थन और रखरखाव चरण में काम की प्रभावशीलता पर निर्भर करती है।

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

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

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

सबसे पहले, विभिन्न मानकों में समर्थन चरण की व्याख्या का विश्लेषण करना आवश्यक है।

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

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

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

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

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

इस प्रकार, आज हम समर्थन की चार श्रेणियों के बारे में बात करते हैं:

1. सुधारात्मक समर्थन इसमें सॉफ़्टवेयर उत्पाद में वास्तविक त्रुटियों को समाप्त (सही) करने की आवश्यकता के कारण होने वाले परिवर्तन शामिल हैं। यदि सॉफ़्टवेयर उत्पाद स्थापित आवश्यकताओं को पूरा नहीं करता है तो सुधारात्मक समर्थन किया जाता है।

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

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

4. निवारक समर्थन इसका उद्देश्य सॉफ़्टवेयर उत्पाद में संभावित (छिपी हुई) त्रुटियों को समाप्त (सही) करने की आवश्यकता के कारण होने वाले परिवर्तनों पर है। निवारक रखरखाव आमतौर पर मानव जीवन को सुनिश्चित करने या सुरक्षा से संबंधित सॉफ़्टवेयर उत्पादों के लिए किया जाता है।

रखरखाव सॉफ्टवेयर गुणवत्ता के संकेतकों में से एक है, साथ ही ग्राहक, आपूर्तिकर्ता और उपयोगकर्ता के लिए एक महत्वपूर्ण विशेषता है।

किसी सॉफ़्टवेयर सिस्टम की रख-रखाव या रख-रखाव को परिभाषित किया गया है, उदाहरण के लिए, IEEE 610.12-90 सॉफ़्टवेयर इंजीनियरिंग शब्दावली के लिए मानक शब्दावली, अपडेट 2002) द्वारा निर्दिष्ट आवश्यकताओं को पूरा करने के लिए रखरखाव, विस्तार, अनुकूलन और समायोजन में आसानी के रूप में। ISO/IEC 9126-01 मानक (सॉफ्टवेयर इंजीनियरिंग - उत्पाद गुणवत्ता - भाग 1: गुणवत्ता मॉडल, 2001) रखरखाव को गुणवत्ता विशेषताओं में से एक मानता है।

सॉफ़्टवेयर के विकास से पहले रख-रखाव निर्धारित किया जाना चाहिए, यानी (आईएसओ/आईईसी, #एम12291 1200009075 गोस्ट आर आईएसओ/) के अनुसार ऑर्डर प्रक्रिया की "तैयारी" कार्य के हिस्से के रूप में ग्राहक और आपूर्तिकर्ता के बीच एक उचित समझौता तैयार किया गया है। आईईसी) 12207#एस। डेवलपर एक समर्थन योजना बनाता है, जिसमें सॉफ़्टवेयर रखरखाव, उचित संसाधन और कार्य करने के लिए एक एल्गोरिदम सुनिश्चित करने के लिए विशिष्ट तरीकों को प्रतिबिंबित करना चाहिए।

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

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

जैसा कि पहले चर्चा की गई है, सॉफ़्टवेयर रखरखाव जीवन चक्र का एक महंगा चरण है, जिसके कार्य को अनुकूलित करने के लिए रखरखाव की लागत का अनुमान लगाने के लिए विभिन्न तरीकों को लागू करना आवश्यक है।

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

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

रखरखाव कार्य को कड़ाई से विनियमित और वर्णित किया जाना चाहिए, जिसमें विस्तृत प्रक्रिया इनपुट और आउटपुट शामिल हों। ये प्रक्रियाएँ मानकों में शामिल हैंआईईईई 1219 और आईएसओ/आईईसी 14764।

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

आईएसओ/आईईसी 14764 मानक रखरखाव प्रक्रिया से संबंधित 12207 जीवन चक्र मानक के प्रावधानों को स्पष्ट करता है। इस मानक में वर्णित रखरखाव कार्य आईईईई 1219 में कार्य के समान है, सिवाय इसके कि इसे थोड़ा अलग तरीके से समूहीकृत किया गया है।

आइए GOST R ISO/IEC 14764-2002 मानक के अंशों पर करीब से नज़र डालें, जिसमें अंतर्राष्ट्रीय मानक ISO/IEC 14764 का पूर्ण प्रामाणिक पाठ शामिल है।

GOST R ISO/IEC 14764-2002 के अनुसार, जो सॉफ़्टवेयर रखरखाव प्रक्रिया का वर्णन करता है, सॉफ़्टवेयर रखरखाव प्रक्रिया का विवरण दस्तावेज़ीकृत किया जाना चाहिए ताकि सहायता कर्मी एक ही प्रक्रिया के भीतर कार्य कर सकें। गुणवत्ता संकेतक (मेट्रिक्स) की प्रणाली को रखरखाव प्रक्रिया के कार्यान्वयन की सुविधा प्रदान करनी चाहिए और इस सॉफ़्टवेयर के सुधार (आधुनिकीकरण) में योगदान देना चाहिए।

अनुरक्षक (5.5.2.1 GOST R ISO/IEC 12207) संगठनात्मक मुद्दों, मौजूदा प्रणाली और अन्य प्रणालियों के साथ इंटरफ़ेस कनेक्शन पर इसके प्रभाव के लिए समस्या रिपोर्ट या संशोधन प्रस्ताव का विश्लेषण करेगा।

विश्लेषण के आधार पर, अनुरक्षक को परिवर्तन लागू करने के लिए विकल्प विकसित करना होगा (5.5.2.3 GOST R ISO/IEC 12207)। सिस्टम में परिवर्तन करने से पहले, अनुरक्षक को (5.5.2.5 GOST R ISO/IEC 12207 देखें) अनुबंध के अनुसार चयनित परिवर्तन विकल्प के लिए अनुमोदन प्राप्त करना होगा और पुष्टि करनी होगी कि किया गया परिवर्तन अनुबंध में स्थापित आवश्यकताओं को पूरा करता है (5.5 देखें) .4.2 गोस्ट आर आईएसओ/आईईसी 12207)। अनुरक्षक को (5.5.2.4 GOST R ISO/IEC 12207) दस्तावेज: एक समस्या रिपोर्ट या संशोधन प्रस्ताव, उनके विश्लेषण के परिणाम और परिवर्तनों को लागू करने के विकल्प चाहिए।

सिस्टम के स्थानांतरण को ठीक से नियंत्रित करने के लिए, सुविधा के लिए एक स्थानांतरण योजना विकसित, प्रलेखित और निष्पादित की जानी चाहिए (5.5.5.2 GOST R ISO/IEC 12207)। उपयोगकर्ताओं को नियोजित कार्य में शामिल होना चाहिए।

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

प्रसारण:डेवलपर्स से समूह, सेवा, या आगे के समर्थन के लिए जिम्मेदार संगठन में सॉफ़्टवेयर स्थानांतरित करने की नियंत्रित और समन्वित गतिविधि।

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

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

प्रभाव का विश्लेषण:मौजूदा व्यवस्था में किए गए परिवर्तनों के संभावित परिणामों का विश्लेषण।

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

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

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

नीचे दी गई तालिका 1 सूचना प्रणालियों के रखरखाव को व्यवस्थित करने में उपयोग किए जाने वाले मुख्य मानकों का संक्षिप्त विवरण प्रदान करती है।

तालिका 1. सूचना प्रणाली रखरखाव के क्षेत्र में मानक

मानक	नाम	विवरण	बाहर निकलने पर
12207 आईईईई, आईएसओ/आईईसी, गोस्ट आर आईएसओ/आईईसी	सॉफ़्टवेयर जीवन चक्र प्रक्रियाएँ	यह अंतर्राष्ट्रीय मानक, स्पष्ट रूप से परिभाषित शब्दावली का उपयोग करते हुए, सॉफ़्टवेयर जीवन चक्र प्रक्रियाओं के लिए एक सामान्य रूपरेखा स्थापित करता है जिसका उपयोग सॉफ़्टवेयर उद्योग को मार्गदर्शन करने के लिए किया जा सकता है।	1) पहचाने गए दोषों और प्रस्तावित समायोजनों पर उपयोगकर्ता रिपोर्टों के अंश (पृ. 5.5.2.1 गोस्ट आर आईएसओ/आईईसी 12207) 2) समायोजन के लिए प्रस्ताव (पृ.5.5.2.3 #एम12291 1200009075 गोस्ट आर आईएसओ/आईईसी 12207#एस ) 3) एएस (खंड) के नए संस्करण की रिलीज के बारे में उपयोगकर्ताओं को अधिसूचना।5.5.2.5 #एम12291 1200009075 गोस्ट आर आईएसओ/आईईसी 12207#एस ) 4) वस्तु स्थानांतरण योजना (पृ.5.5.5.2 #एम12291 1200009075 गोस्ट आर आईएसओ/आईईसी 12207)
14764 आईएसओ/आईईसी गोस्ट आर आईएसओ आईईसी	सॉफ्टवेयर समर्थन (सॉफ्टवेयर इंजीनियरिंग के लिए मानक - सॉफ्टवेयर रखरखाव)	यह मानक 12207 में स्थापित रखरखाव प्रक्रिया का विवरण देता है (आईएसओ/आईईसी #एम12291 1200009075 गोस्ट आर आईएसओ/आईईसी)
9126 आईएसओ/आईईसी गोस्ट आर आईएसओ/आईईसी	सूचान प्रौद्योगिकी। सॉफ्टवेयर उत्पादों का मूल्यांकन. उनके उपयोग के लिए गुणवत्ता विशेषताएँ और दिशानिर्देश	अनुरक्षकों के पास एक सॉफ्टवेयर गुणवत्ता आश्वासन कार्यक्रम शामिल होना चाहिए छह गुणवत्ता विशेषताएँ, #M12291 1200009076 GOST R ISO/IEC 9126#S में स्थापित। सॉफ़्टवेयर टूल को बनाए रखते समय, इस टूल की विशेषताओं का आकलन (मापने) के तरीकों की पहचान, वर्णन, चयन, लागू करने और सुधार करने के लिए एक उचित प्रक्रिया लागू की जानी चाहिए।	गुणवत्ता विशेषताएँ: 1) कार्यक्षमता 2) विश्वसनीयता 3) व्यावहारिकता 4) क्षमता 5) रख-रखाव 6) गतिशीलता
गोस्ट 34.603-92	स्वचालित प्रणालियों के परीक्षण के प्रकार	मानक एएस परीक्षणों के प्रकार और उनके आचरण के लिए सामान्य आवश्यकताएं स्थापित करता है। तकनीकी विशिष्टताओं (टीओआर) की आवश्यकताओं के साथ निर्मित एनपीपी के अनुपालन को सत्यापित करने के लिए एनपीपी परीक्षण GOST 34.601 के अनुसार "कमीशनिंग" चरण में किए जाते हैं।	सभी प्रकार के परीक्षणों की योजना बनाने के लिए एक दस्तावेज़ विकसित किया जाता है "परीक्षण कार्यक्रम और कार्यप्रणाली।" स्वायत्त परीक्षण कार्यक्रम इंगित करता है: 1) सूची (परीक्षण किए जाने वाले कार्य; 2) परीक्षण वस्तु और सॉफ़्टवेयर के अन्य भागों के बीच संबंधों का विवरण; 3) परिणामों के परीक्षण और प्रसंस्करण की शर्तें, प्रक्रिया और तरीके; 4) परीक्षण परिणामों के आधार पर भागों की स्वीकृति के लिए मानदंड। ट्रायल के दौरान सबस्टेशन का संचालन किया जाता है काम का लॉग, जिसमें एएस के संचालन की अवधि, विफलताओं, खराबी, आपात स्थिति, स्वचालन वस्तु के मापदंडों में परिवर्तन, दस्तावेज़ीकरण और सॉफ़्टवेयर में चल रहे समायोजन और तकनीकी उपकरणों के समायोजन के बारे में जानकारी शामिल है।
आईईईई 1219-1998	सॉफ्टवेयर रखरखाव के लिए आईईईई मानक (सॉफ़्टवेयर रखरखाव के लिए मानक)	यह मानक सॉफ़्टवेयर रखरखाव गतिविधियों के प्रबंधन और प्रदर्शन के लिए एक पुनरावृत्तीय प्रक्रिया का वर्णन करता है। इस मानक का उपयोग सॉफ़्टवेयर उत्पाद के आकार, जटिलता, गंभीरता या अनुप्रयोग तक सीमित नहीं है।

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

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

ईस्टर्न एक्सप्रेस सीआईएस के रखरखाव में कई प्रकार का समर्थन शामिल है (GOST R ISO IEC 14764-2002 के अनुसार)। अर्थात्, सुधारात्मक समर्थन, जो सॉफ़्टवेयर उत्पाद में वास्तविक त्रुटियों को समाप्त (सही) करने की आवश्यकता के कारण होने वाले परिवर्तनों से जुड़ा है। यदि सॉफ़्टवेयर उत्पाद स्थापित आवश्यकताओं को पूरा नहीं करता है तो सुधारात्मक समर्थन किया जाता है। साथ ही अनुकूली और पूर्ण समर्थन जो सॉफ़्टवेयर उत्पाद को आधुनिक बनाता है।

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

अनुकूली समर्थन की आवश्यकता तब उत्पन्न होती है जब किसी व्यावसायिक प्रक्रिया के कामकाज में परिवर्तन होता है (पदोन्नति करना, बाहरी मुद्रित प्रपत्र बदलना, प्रधान कार्यालय से आदेश, आदि), या जब कोई संचालन करना असुविधाजनक होता है, जिसमें परिवर्तन की आवश्यकता होती है सिस्टम इंटरफ़ेस में.

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

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

तालिका 2 समर्थन के मुख्य चरणों और संलग्न दस्तावेज़ीकरण पैराग्राफ में आउटपुट को दर्शाती है।

तालिका 2. सूचना प्रणाली रखरखाव प्रक्रिया के चरण

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

GOST R ISO/IEC 12207 के 5.5.2.1 के अनुसार, अनुरक्षक को समस्या की उपयोगकर्ता रिपोर्ट का विश्लेषण करना चाहिए। ओरिएंट एक्सप्रेस सीआईएस के उपयोगकर्ताओं से अनुरोधों के पंजीकरण और रिकॉर्डिंग को स्वचालित करने के लिए, मेंटिसबीटी घटना पंजीकरण प्रणाली का उपयोग किया जाता है। सिस्टम में पंजीकृत डेटा के आधार पर मंटिसबीटी एक दस्तावेज़ तैयार करता है "उपयोगकर्ताओं द्वारा पहचाने गए दोषों पर रिपोर्ट" जिसमें निम्नलिखित फ़ील्ड शामिल हैं: घटना संख्या, निर्माण तिथि, श्रेणी, घटना का सार, प्रस्तावित समाधान।

विश्लेषण के आधार पर, अनुरक्षक को परिवर्तनों को लागू करने के लिए विकल्प विकसित करना होगा (5.5.2.3 GOST R ISO/IEC 12207)। इस उद्देश्य के लिए, दस्तावेज़ "सीआईएस के नए मूल संस्करण के लिए तैयार और अनुमोदित समायोजन का जर्नल" विकसित किया जा रहा है, जिसमें निम्नलिखित डेटा शामिल है: श्रेणी, सहायक संगठन द्वारा पहचाना गया दोष, सीआईएस उपयोगकर्ताओं द्वारा पहचाना गया दोष, समायोजन।

इसके बाद, अनुरक्षक को (5.5.4.2 GOST R ISO/IEC 12207) पुष्टि प्राप्त करनी होगी कि किया गया परिवर्तन अनुबंध में स्थापित आवश्यकताओं को पूरा करता है। इन उद्देश्यों के लिए, एक दस्तावेज़ "सीआईएस के नए संस्करण की रिलीज़ के बारे में उपयोगकर्ताओं को अधिसूचना" तैयार की जाती है और नई रिलीज़ को स्थापित करने के लिए सहमति की पुष्टि अपेक्षित है।

सिस्टम के स्थानांतरण को ठीक से नियंत्रित करने के लिए, वहाँ होना चाहिए

GOST 34.603-92 स्वचालित प्रणालियों के परीक्षण के प्रकार

आईईईई 1219-1998 सॉफ्टवेयर रखरखाव के लिए आईईईई मानक

सॉफ़्टवेयर रखरखाव (SWEBOK द्वारा सॉफ़्टवेयर रखरखाव) // ‒ एक्सेस मोड:

पत्रिका "नेटवर्क" संख्या 2.2001 लेख "सूचना प्रणाली का जीवन चक्र" // ‒ एक्सेस मोड: http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44

सूचना प्रणाली विकसित करने की पद्धति और प्रौद्योगिकी। खुली सूचना प्रणालियों की प्रोफाइल // ‒ एक्सेस मोड: http://gendocs.ru/v7394/lectures_on_theory_of_information_processes_and_systems?page=9

प्रकाशन को देखे जाने की संख्या: कृपया प्रतीक्षा करें

ISO/IEC 12207 मानक के अनुसार सॉफ़्टवेयर जीवन चक्र की संरचना प्रक्रियाओं के तीन समूहों पर आधारित है (चित्र 1):

· सॉफ्टवेयर जीवन चक्र की मुख्य प्रक्रियाएं (खरीद, वितरण, विकास, संचालन, समर्थन);

· सहायक प्रक्रियाएं जो मुख्य प्रक्रियाओं (प्रलेखन, कॉन्फ़िगरेशन प्रबंधन, गुणवत्ता आश्वासन, सत्यापन, प्रमाणन, मूल्यांकन, लेखापरीक्षा, समस्या समाधान) के कार्यान्वयन को सुनिश्चित करती हैं;

· संगठनात्मक प्रक्रियाएं (परियोजना प्रबंधन, परियोजना बुनियादी ढांचे का निर्माण, परिभाषा, मूल्यांकन और जीवन चक्र में सुधार, प्रशिक्षण)।

चावल। 1. सॉफ्टवेयर जीवन चक्र प्रक्रियाएं।

अधिग्रहण प्रक्रिया(अधिग्रहण प्रक्रिया). इसमें क्रियाएं शामिल हैं

और सॉफ़्टवेयर खरीदने वाले ग्राहक के कार्य। इस प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1) अधिग्रहण की शुरूआत;

2) बोली प्रस्ताव तैयार करना;

3) अनुबंध की तैयारी और समायोजन;

4) आपूर्तिकर्ता की गतिविधियों का पर्यवेक्षण;

5) कार्य की स्वीकृति एवं पूर्णता।

वितरण की प्रक्रिया(आपूर्ति प्रक्रिया). इसमें विक्रेता द्वारा की गई गतिविधियों और कार्यों को शामिल किया गया है जो ग्राहक को सॉफ़्टवेयर उत्पाद या सेवा प्रदान करता है। इस प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1) डिलीवरी की शुरूआत;

2) बोली प्रस्तावों पर प्रतिक्रिया तैयार करना;

3) अनुबंध की तैयारी;

4) योजना बनाना;

5) निष्पादन और नियंत्रण;

6) निरीक्षण और मूल्यांकन;

7) कार्य की डिलीवरी और समाप्ति।

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

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

1) सिस्टम आवश्यकताओं का विश्लेषण;

2) सिस्टम आर्किटेक्चर का डिज़ाइन;

3) सॉफ्टवेयर आवश्यकताओं का विश्लेषण;

4) सॉफ्टवेयर आर्किटेक्चर डिजाइन;

5) विस्तृत सॉफ्टवेयर डिजाइन;

6) सॉफ्टवेयर कोडिंग और परीक्षण;

7) सॉफ्टवेयर एकीकरण;

8) सॉफ्टवेयर योग्यता परीक्षण;

9) सिस्टम एकीकरण;

10) प्रणाली का योग्यता परीक्षण;

11) सॉफ़्टवेयर स्थापना;

12) सॉफ्टवेयर की स्वीकृति.

संचालन प्रक्रिया(संचालन प्रक्रिया)। इसमें ऑपरेटर - सिस्टम को संचालित करने वाले संगठन - के कार्यों और कार्यों को शामिल किया गया है। इस प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1) परिचालन परीक्षण;

2) सिस्टम का संचालन;

3) उपयोगकर्ता समर्थन.

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

आवश्यकताएं। मौजूदा सॉफ़्टवेयर में किए गए परिवर्तनों का उल्लंघन नहीं होना चाहिए

इसकी अखंडता. रखरखाव प्रक्रिया में सॉफ़्टवेयर को दूसरे वातावरण में स्थानांतरित करना (माइग्रेशन) शामिल है और सॉफ़्टवेयर को बंद करने के साथ समाप्त होता है।

रखरखाव प्रक्रिया में निम्नलिखित क्रियाएं शामिल हैं:

1) सॉफ़्टवेयर संशोधन के लिए समस्याओं और अनुरोधों का विश्लेषण;

2) सॉफ्टवेयर संशोधन;

3) निरीक्षण और स्वीकृति;

4) सॉफ़्टवेयर को दूसरे वातावरण में स्थानांतरित करना;

5) सॉफ्टवेयर को डीकमीशन करना।

सहायक प्रक्रियाओं के समूह में शामिल हैं:

दस्तावेज़ीकरण;

विन्यास प्रबंधन; गुणवत्ता आश्वासन;

सत्यापन; प्रमाणीकरण;

सहभागी मूल्यांकन;

समस्या का समाधान।

दस्तावेज़ीकरण प्रक्रिया(दस्तावेज़ीकरण प्रक्रिया). यह सॉफ़्टवेयर जीवन चक्र के दौरान बनाई गई जानकारी का औपचारिक विवरण प्रदान करता है। दस्तावेज़ीकरण प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1) डिजाइन और विकास;

2) दस्तावेज़ जारी करना;

3) दस्तावेज़ीकरण समर्थन।

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

तकनीकी दस्तावेज़ीकरण में स्थापित और सॉफ़्टवेयर में कार्यान्वित विशेषताएँ।

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

सॉफ़्टवेयर के लिए कॉन्फ़िगरेशन प्रबंधन"। कॉन्फ़िगरेशन प्रबंधन प्रक्रिया में निम्नलिखित क्रियाएं शामिल हैं:

1) कॉन्फ़िगरेशन पहचान;

2) विन्यास नियंत्रण;

3) कॉन्फ़िगरेशन स्थिति का लेखा-जोखा;

4) कॉन्फ़िगरेशन मूल्यांकन;

5) रिलीज प्रबंधन और वितरण।

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

1) उत्पाद की गुणवत्ता सुनिश्चित करना;

2) प्रक्रिया की गुणवत्ता सुनिश्चित करना;

3) सिस्टम गुणवत्ता के अन्य संकेतक सुनिश्चित करना।

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

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

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

लेखापरीक्षा प्रक्रिया(ऑडिट प्रक्रिया). यह आवश्यकताओं, योजनाओं और अनुबंध की शर्तों के अनुपालन का निर्धारण है।

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

सॉफ़्टवेयर जीवन चक्र की संगठनात्मक प्रक्रियाओं के समूह में शामिल हैं:

नियंत्रण;

बुनियादी ढांचे का निर्माण;

सुधार;

नए संस्करणों का विमोचन;

शिक्षा।

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

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

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

कार्मिक।

सीखने की प्रक्रिया(प्रशिक्षण प्रक्रिया). इसमें प्रारंभिक प्रशिक्षण और उसके बाद चल रहे स्टाफ विकास को शामिल किया गया है।

आईटी क्षेत्र में, सबसे व्यावहारिक मानक निम्नलिखित संगठनों द्वारा प्रकाशित किए जाते हैं:

इंस्टीट्यूट ऑफ़ इलेक्ट्रिकल एंड इलेक्ट्रॉनिक्स इंजीनियर्स(आईईईई, www.ieee.org) कई वर्षों से एक अग्रणी वैज्ञानिक और तकनीकी संगठन रहा है, जिसमें सॉफ्टवेयर दस्तावेज़ीकरण मानकों का निर्माण भी शामिल है। अधिकांश मानक अनुभवी और जिम्मेदार पेशेवर इंजीनियरों से बनी विभिन्न समितियों द्वारा विकसित किए जाते हैं। IEEE के कुछ मानक ANSI (अमेरिकन नेशनल स्टैंडर्ड इंस्टीट्यूट) मानक भी बन गए हैं। मुख्य रूप से आईईईई मानकों ने सीपी के लिए एमयू की तैयारी का आधार बनाया। श्मिट एम. आईईईई सॉफ्टवेयर इंजीनियरिंग मानकों को लागू करना।
मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ)दुनिया भर में, विशेष रूप से यूरोपीय संघ (ईयू) से संबंधित उत्पादक संगठनों के बीच इसका बहुत बड़ा प्रभाव है। वर्तमान में, रूसी संघ में अनुवादित और अपनाए गए लगभग सभी आधुनिक आईटी मानक आईएसओ द्वारा अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन - आईईसी के साथ संयुक्त रूप से तैयार किए गए मानक हैं। आप जानते हैं कि अंतरराष्ट्रीय स्तर पर उत्पाद की गुणवत्ता सुनिश्चित करने के मुद्दों पर विशेष ध्यान दिया जाता है, इसलिए, 02/02/1998 की रूसी सरकार की डिक्री संख्या 113 के अनुसार, आईएसओ 9000 (गुणवत्ता प्रबंधन को विनियमित करने वाले मानकों की एक श्रृंखला) की आवश्यकताओं का अनुपालन उद्यमों में) सरकारी आदेश प्राप्त करने के लिए एक शर्त है।
सॉफ्टवेयर इंजीनियरिंग प्रौद्योगिकी संस्थान(सॉफ्टवेयर इंजीनियरिंग इंस्टीट्यूट - SEI, sei.cmu.edu - 1000 से अधिक लेख) रक्षा विभाग के ठेकेदारों के बीच सॉफ्टवेयर प्रौद्योगिकी के स्तर को बढ़ाने के लिए कार्नेगी मेलन विश्वविद्यालय में अमेरिकी रक्षा विभाग द्वारा स्थापित किया गया था। एसईआई के काम को कई वाणिज्यिक कंपनियों ने भी अपनाया है जो सॉफ्टवेयर विकास प्रक्रिया में सुधार को एक रणनीतिक कॉर्पोरेट उद्देश्य मानते हैं। हम एसईआई द्वारा विकसित मानकों में से एक को देखेंगे जिसे क्षमता परिपक्वता मॉडल (सीएमएम) कहा जाता है।
ऑब्जेक्ट मैनिपुलेशन टेक्नोलॉजी कंसोर्टियम(ऑब्जेक्ट मैनेजमेंट ग्रुप, www.omg.org) लगभग 700 सदस्य कंपनियों वाला एक गैर-लाभकारी संगठन है। OMG वितरित ऑब्जेक्ट-ओरिएंटेड कंप्यूटिंग के लिए मानक निर्धारित करता है। यह ध्यान दिया जाना चाहिए कि ओएमजी परियोजनाओं का वर्णन करने के लिए अपने मानक के रूप में एकीकृत मॉडलिंग भाषा यूएमएल का उपयोग करता है। हम यूएमएल का विस्तार से अध्ययन करेंगे, क्योंकि... रैशनल की एकीकृत प्रक्रिया के साथ इस भाषा का उपयोग पाठ्यक्रम परियोजना के मूल को विकसित करने का आधार है।

सिस्टम जीवन चक्र की अवधारणा

सॉफ्टवेयर विकास के मानकीकरण की आवश्यकता को मानक की शुरूआत में सबसे अच्छी तरह वर्णित किया गया है GOST R ISO/IEC 12207-99 “सूचना प्रौद्योगिकी। सॉफ़्टवेयर जीवन चक्र प्रक्रियाएँ": “सॉफ्टवेयर सूचना प्रौद्योगिकी और परिवहन, सैन्य, चिकित्सा और वित्तीय जैसी पारंपरिक प्रणालियों का एक अभिन्न अंग है। सॉफ़्टवेयर के विकास और प्रबंधन के लिए कई अलग-अलग मानक, प्रक्रियाएँ, विधियाँ, उपकरण और ऑपरेटिंग वातावरण के प्रकार हैं। यह विविधता सॉफ़्टवेयर डिज़ाइन और प्रबंधन में चुनौतियाँ पैदा करती है, विशेषकर सॉफ़्टवेयर उत्पादों और सेवाओं के संयोजन में। सॉफ़्टवेयर विकास रणनीति के लिए इस भीड़ से एक सामान्य क्रम की ओर बढ़ने की आवश्यकता है जो सॉफ़्टवेयर चिकित्सकों को सॉफ़्टवेयर विकसित और प्रबंधित करते समय "समान भाषा बोलने" की अनुमति देगा। यह अंतर्राष्ट्रीय मानक वह सामान्य आदेश प्रदान करता है।"

मानक गोस्ट आर आईएसओ/आईईसी 12207-99एक सॉफ्टवेयर सिस्टम की मूल अवधारणा को परिभाषित करता है - "जीवन चक्र" (GOST R ISO/IEC TO 15271-2002 "सूचना प्रौद्योगिकी। GOST R ISO/IEC 12207 के अनुप्रयोग के लिए दिशानिर्देश")।

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

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

जीवन चक्र प्रक्रियाओं को तीन समूहों में विभाजित किया गया है:मुख्य, सहायक और संगठनात्मक।

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

चित्र - आईएस जीवन चक्र की मुख्य प्रक्रियाएँ

सहायक प्रक्रियाओं के समूह में ऐसी प्रक्रियाएँ शामिल हैं जो मुख्य प्रक्रियाओं के निष्पादन को सुनिश्चित करती हैं:

दस्तावेज़ीकरण;
विन्यास प्रबंधन;
गुणवत्ता आश्वासन;
सत्यापन;
प्रमाणीकरण;
श्रेणी;
अंकेक्षण;
समस्या को सुलझाना।

संगठनात्मक प्रक्रियाओं के समूह में निम्नलिखित प्रक्रियाएँ शामिल हैं:

परियोजना प्रबंधन;
परियोजना के बुनियादी ढांचे का निर्माण;
जीवन चक्र को परिभाषित करना, उसका आकलन करना और उसमें सुधार करना;
शिक्षा।

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

वक्ताओं के लिए आवश्यकताओं का गठन,
एसी अवधारणा का विकास,
तकनीकी कार्य,
प्रारंभिक डिजाइन,
तकनीकी परियोजना,
कामकाजी दस्तावेज,
कमीशनिंग,
संगत.

चरणों को चरणों में विभाजित किया गया है, जिनकी सामग्री GOST 12207-99 में वर्णित कई कार्यों की सामग्री के साथ ओवरलैप होती है।

विकास की प्रक्रिया

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

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

प्रारंभिक कार्य

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

आवश्यकताओं के विश्लेषण

सॉफ़्टवेयर आवश्यकताओं के विश्लेषण में प्रत्येक सॉफ़्टवेयर घटक के लिए निम्नलिखित विशेषताओं का निर्धारण शामिल है:

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

वास्तुकला डिजाइन

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

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

विस्तृत डिजाइन

पीएस में निम्नलिखित कार्य शामिल हैं:

निचले स्तर पर सॉफ़्टवेयर घटकों और उनके बीच इंटरफेस का विवरण, जो उनके बाद के स्वतंत्र कोडिंग और परीक्षण के लिए पर्याप्त है;
विस्तृत डेटाबेस डिज़ाइन का विकास और दस्तावेज़ीकरण;
परीक्षण आवश्यकताओं का विकास और दस्तावेज़ीकरण और सॉफ़्टवेयर घटकों के लिए एक परीक्षण योजना;

कोडिंग और परीक्षण

पीएस निम्नलिखित कार्यों को कवर करता है:

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

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

GOST R ISO/IEC 12119-2000 “सूचना प्रौद्योगिकी। सॉफ्टवेयर का संकुल। गुणवत्ता आवश्यकताएँ और परीक्षण"इसमें ऐसे निर्देश शामिल हैं जो किसी उत्पाद की गुणवत्ता आवश्यकताओं के अनुपालन के लिए परीक्षण की प्रक्रिया निर्धारित करते हैं। परीक्षण एक श्रम-गहन प्रक्रिया है. कुछ विशेषज्ञों के अनुसार प्रतिशत
डिज़ाइन-विकास-परीक्षण प्रक्रियाओं के बीच समय का वितरण 40-20-40 के अनुपात में है। इस संबंध में, परीक्षण स्वचालन प्रणाली व्यापक होती जा रही है। आईईईई 1209-1992 मानक, "केस टूल के मूल्यांकन और चयन के लिए अनुशंसित अभ्यास", परीक्षण स्वचालन उपकरण की कार्यक्षमता के लिए सामान्य आवश्यकताओं को निर्धारित करता है।

प्रणाली एकीकरण

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

सिस्टम इंस्टालेशन

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

प्रणाली की स्वीकृति

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

सॉफ़्टवेयर जीवन चक्र मॉडल

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

आज तक, दो मुख्य जीवन चक्र मॉडल सबसे व्यापक हो गए हैं:

कैस्केड (झरना) मॉडल;
सर्पिल मॉडल.

कैस्केड मॉडल

कैस्केड मॉडलविभिन्न अनुप्रयोग क्षेत्रों में विभिन्न प्रणालियों के विकास के लिए एक शास्त्रीय दृष्टिकोण प्रदर्शित करता है। सूचना प्रणाली के विकास के लिए इस मॉडल का व्यापक रूप से 70 के दशक और 80 के दशक के पूर्वार्द्ध में उपयोग किया गया था। यह कैस्केड मॉडल है जो GOST श्रृंखला 34.xxx और अमेरिकी रक्षा विभाग मानक DOD-STD-2167A का आधार बनता है। GOST 12207-99 को GOST 34.601-90 में संसाधित करता है “स्वचालित सिस्टम। सृजन के चरण"चरण कहलाते हैं और संरचना में थोड़ा भिन्न होते हैं।
कैस्केड मॉडल प्रक्रियाओं के अनुक्रमिक संगठन के लिए प्रदान करता है। इसके अलावा, अगली प्रक्रिया में परिवर्तन तभी होता है जब पिछली प्रक्रिया का सारा काम पूरी तरह से पूरा हो जाता है। प्रत्येक प्रक्रिया दस्तावेज़ के एक पूरे सेट के जारी होने के साथ समाप्त होती है, जो पर्याप्त हो ताकि किसी अन्य विकास टीम द्वारा काम जारी रखा जा सके।

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

इसके अलावा, कैस्केड मॉडल के नुकसान में शामिल हैं:

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

सर्पिल मॉडल

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

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

रैपिड अनुप्रयोग का विकास

20वीं सदी के 90 के दशक में, सर्पिल मॉडल के आधार पर "रैपिड एप्लिकेशन डेवलपमेंट" - आरएडी (रैपिड एप्लिकेशन डेवलपमेंट) नामक एक व्यावहारिक तकनीक की स्थापना की गई थी। इस मामले में, जीवन चक्र में चार चरण शामिल थे:

आवश्यकताओं का विश्लेषण और योजना,
डिज़ाइन,
कार्यान्वयन,
कार्यान्वयन।

आरएडी के मूल सिद्धांत:

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

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

एक्सट्रीम प्रोग्रामिंग के सिद्धांत इस प्रकार हैं:

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

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

सी - दोषों के कारण सुविधा का नुकसान होता है;
डी - दोषों के कारण वसूली योग्य धन (सामग्री या वित्तीय) की हानि होती है;
ई - दोषों के कारण अपूरणीय धन की हानि होती है;
एल - दोष मानव जीवन के लिए खतरा पैदा करते हैं।

पैमाना परियोजना में भाग लेने वाले डेवलपर्स की संख्या से निर्धारित होता है:

1 से 6 लोगों तक - छोटे पैमाने पर;
6 से 20 लोगों तक - मध्यम स्तर;
20 से अधिक लोग - बड़े पैमाने पर।

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

एकीकृत सॉफ्टवेयर विकास प्रक्रिया

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

वहीं, जीवन चक्र को 4 चरणों में बांटा गया है:

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

प्रत्येक यूएसडीपी चरण में परियोजना के आकार के आधार पर एक या अधिक पुनरावृत्तियाँ शामिल हो सकती हैं। प्रत्येक पुनरावृत्ति के दौरान, 5 मुख्य और कई अतिरिक्त कार्यकर्ता थ्रेड निष्पादित किए जा सकते हैं।
यूएसडीपी में मुख्य कार्य धाराओं में शामिल हैं:

आवश्यकताओं की परिभाषा (आरडी);
विश्लेषण (ए);
डिज़ाइन (पी);
कार्यान्वयन (पी);
परीक्षण (टी)।

अतिरिक्त कार्य सूत्र में शामिल हो सकते हैं:

गुणवत्ता आश्वासन कार्य (के),
दस्तावेज़ीकरण (डी),
परियोजना प्रबंधन (पी),
कॉन्फ़िगरेशन प्रबंधन (सीएम),
बुनियादी ढांचे का निर्माण और प्रबंधन (आई)
और दूसरे।

चित्र - एकीकृत सॉफ्टवेयर विकास प्रक्रिया के अनुसार जीवन चक्र मॉडल

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

चित्र - विकास प्रक्रिया से जुड़े विनियामक दस्तावेज़

जीवन चक्र प्रक्रियाओं का समर्थन करना

गुणवत्ता आश्वासन प्रक्रिया

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

चित्र - सहायक जीवन चक्र प्रक्रियाओं की संरचना

GOST R ISO/IEC 9126-93 के संदर्भ में। "सूचान प्रौद्योगिकी। सॉफ्टवेयर उत्पादों का मूल्यांकन. गुणवत्ता विशेषताएँ और उनके उपयोग के लिए दिशानिर्देश" गुणवत्ता विशेषता को "किसी सॉफ़्टवेयर उत्पाद के गुणों (विशेषताओं) का एक सेट" के रूप में समझा जाता है जिसके द्वारा इसकी गुणवत्ता का वर्णन और मूल्यांकन किया जाता है।

मानक छह व्यापक विशेषताओं को परिभाषित करता है जो न्यूनतम दोहराव के साथ सॉफ़्टवेयर की गुणवत्ता का वर्णन करते हैं:

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

GOST 28195-89 “सॉफ़्टवेयर की गुणवत्ता का आकलन। सामान्य प्रावधान"शीर्ष पर, पहले, स्तर पर, यह 6 संकेतकों की पहचान करता है - गुणवत्ता कारक: विश्वसनीयता, शुद्धता, उपयोग में आसानी, दक्षता, बहुमुखी प्रतिभा और रखरखाव। इन कारकों को दूसरे स्तर पर 19 गुणवत्ता मानदंडों द्वारा सामूहिक रूप से विस्तृत किया गया है। गुणवत्ता संकेतकों का और अधिक विवरण मेट्रिक्स और मूल्यांकन तत्वों द्वारा दर्शाया गया है, जिनमें से लगभग 240 हैं। उनमें से प्रत्येक को 0 से 1 तक विशेषज्ञ रूप से मूल्यांकन करने की अनुशंसा की जाती है। उपयोग किए गए कारकों, मानदंडों और मेट्रिक्स की संरचना का चयन करने का प्रस्ताव है सॉफ़्टवेयर जीवन चक्र के उद्देश्य, कार्यों और चरणों के आधार पर।

GOST 28806-90 मानक "सॉफ्टवेयर की गुणवत्ता। शब्द और परिभाषाएं"किसी प्रोग्राम, सॉफ़्टवेयर टूल, सॉफ़्टवेयर उत्पाद और उनकी गुणवत्ता की सामान्य अवधारणाओं को औपचारिक रूप दिया जाता है। कार्यक्रम की विशेषताओं के आकलन से जुड़े 18 सबसे अधिक इस्तेमाल किए जाने वाले शब्दों की परिभाषाएँ दी गई हैं। GOST 28195-89 में दिए गए बुनियादी गुणवत्ता संकेतकों की अवधारणाओं को स्पष्ट किया गया है।
सॉफ़्टवेयर की गुणवत्ता सुनिश्चित करने के मुद्दे पर विशेष ध्यान देने की आवश्यकता है, क्योंकि रूसी संघ की सरकार संख्या 113 दिनांक 02.02.1998 के अनुसार, गुणवत्ता आश्वासन और गुणवत्ता प्रबंधन आईएसओ 9000 के लिए अंतर्राष्ट्रीय मानक की आवश्यकताओं का अनुपालन प्राप्त करने के लिए एक शर्त है। एक सरकारी आदेश.
वर्तमान चरण में, उत्पादित और उपयोग किए गए सॉफ़्टवेयर (आउटपुट नियंत्रण) की गुणवत्ता का आकलन करने के लिए केवल तरीकों का होना पर्याप्त नहीं है; गुणवत्ता की योजना बनाने, सॉफ़्टवेयर जीवन चक्र के सभी चरणों में इसे मापने और समायोजित करने में सक्षम होना आवश्यक है गुणवत्ता में सुधार के लिए सॉफ्टवेयर उत्पादन प्रक्रिया।

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

दस्तावेज़ीकरण,
आवश्यकताएं,
विश्लेषण परिणाम,
डिज़ाइन,
लिस्टिंग, आदि

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

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

निरीक्षण करने के लिए निम्नलिखित चरणों की आवश्यकता होती है:

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

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

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

विश्वसनीयता और सुरक्षा

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

सूचना सुरक्षा मानकों को दो समूहों में बांटा गया है:

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

सबसे महत्वपूर्ण मूल्यांकन मानकों में शामिल हैं:

रूस का राज्य तकनीकी आयोग। मार्गदर्शक दस्तावेज़. कंप्यूटर सुविधाएं. फ़ायरवॉल. सूचना तक अनधिकृत पहुंच के विरुद्ध सुरक्षा. सूचना तक अनधिकृत पहुंच के विरुद्ध सुरक्षा के संकेतक। - मॉस्को, 1997 - सात-स्तरीय संदर्भ मॉडल के डेटा प्रवाह फ़िल्टरिंग के स्तर के अनुसार फ़ायरवॉल को वर्गीकृत करता है।
आईएसओ/आईईसी 15408:1999 सूचना प्रौद्योगिकी की सुरक्षा का आकलन करने के लिए मानदंड।

दूसरे समूह में निम्नलिखित दस्तावेज़ शामिल हैं:

X.800 "ओपन सिस्टम इंटरकनेक्शन के लिए सुरक्षा आर्किटेक्चर।" मुख्य नेटवर्क सुरक्षा सेवाओं पर प्रकाश डाला गया है: प्रमाणीकरण, पहुंच नियंत्रण, गोपनीयता और/या डेटा अखंडता सुनिश्चित करना। सेवाओं को लागू करने के लिए, निम्नलिखित नेटवर्क सुरक्षा तंत्र और उनके संयोजन प्रदान किए जाते हैं: एन्क्रिप्शन, इलेक्ट्रॉनिक डिजिटल हस्ताक्षर, एक्सेस नियंत्रण, डेटा अखंडता नियंत्रण, प्रमाणीकरण, ट्रैफ़िक जोड़, रूटिंग नियंत्रण, नोटरीकरण।
इंटरनेट समुदाय विनिर्देश आरएफसी 1510, केर्बरोस नेटवर्क प्रमाणीकरण सेवा (वी5), नेटवर्क पर एकल साइन-ऑन की अवधारणा के समर्थन के साथ एक विषम वितरित वातावरण में प्रमाणीकरण की समस्या का समाधान करता है;
X.500 "निर्देशिका सेवाएँ: अवधारणाओं, मॉडलों और सेवाओं का अवलोकन", X.509 "निर्देशिका सेवाएँ: सार्वजनिक कुंजी और विशेषता प्रमाणपत्र फ़्रेमवर्क"।

सत्यापन, प्रमाणन और लेखापरीक्षा प्रक्रियाएँ

सत्यापन, योग्यता और ऑडिट SQAP IEEE 739-1989 गुणवत्ता नियंत्रण योजना का एक अभिन्न अंग हैं।
सत्यापन इस प्रश्न का उत्तर देता है: "क्या हम वही कर रहे हैं जो हमने इस स्तर पर योजना बनाई थी?" प्रमाणन और लेखापरीक्षा इस प्रश्न का उत्तर देती है: "क्या निर्माणाधीन सुविधा ग्राहक की ज़रूरतों को पूरा करती है?"
IEEE 1012-1986 सॉफ़्टवेयर सत्यापन और सत्यापन योजना (एसवीवीपी) मानक प्रमाणीकरण और ऑडिट प्रक्रियाओं को जोड़ती है जिन्हें सत्यापन कहा जाता है और परिभाषित करता है कि उन्हें कैसे किया जाता है।

सत्यापन प्रक्रिया के दौरान, निम्नलिखित शर्तों की जाँच की जाती है:

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

संयुक्त समीक्षा प्रक्रिया

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

समस्या समाधान प्रक्रिया

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

जोखिमों के उभरने के कारण निम्नलिखित हो सकते हैं:

आवश्यकताओं का अस्पष्ट और/या अधूरा निरूपण;
परियोजना में हितधारकों की अपर्याप्त भागीदारी;
ख़राब योजना - सक्षम परियोजना प्रबंधन की कमी;
कार्यक्षेत्र, परियोजना लक्ष्यों और अन्य कारणों में परिवर्तन के कारण आवश्यकताओं में बार-बार परिवर्तन;
प्रयुक्त डिज़ाइन तकनीक की अपूर्णता;
कलाकारों के बीच ज्ञान या कौशल का अभाव.

जोखिमों को रोकने के दो तरीके हैं:

परियोजना आवश्यकताओं में परिवर्तन करना जो जोखिम के कारण को समाप्त करता है;
प्रौद्योगिकियों का विकास जो जोखिम के उद्भव से जुड़ी समस्या का समाधान करता है।

परियोजना प्रबंधन प्रक्रिया के दौरान, प्रबंधक को समय-समय पर उपचार की प्रतीक्षा कर रहे जोखिमों की एक सूची संकलित करने के लिए परियोजना के विभिन्न हिस्सों में जोखिमों की पहचान करने की प्रक्रिया शुरू करनी चाहिए। प्रत्येक जोखिम के लिए, तीन मान निर्धारित किए जाते हैं: जोखिम घटित होने की संभावना; यदि ऐसा होता है तो इस जोखिम से परियोजना को होने वाली क्षति; जोखिम को ख़त्म करने की लागत का अनुमान लगाना। सभी मान समान पैमाने का उपयोग करते हैं, उदाहरण के लिए 1 - 10.

दस्तावेज़ीकरण और कॉन्फ़िगरेशन प्रबंधन प्रक्रिया

"सॉफ़्टवेयर प्रोजेक्ट दस्तावेज़ीकरण के प्रबंधन के लिए महत्वपूर्ण संगठनात्मक प्रयासों की आवश्यकता होती है, क्योंकि... दस्तावेज़ीकरण एक जटिल प्रणाली है, जो निरंतर परिवर्तनों के अधीन है जिसे कई लोगों द्वारा एक साथ किया जा सकता है" (ई. ब्रैड)

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

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

दस्तावेज़ प्रबंधनइसका अर्थ है इसे पूर्ण और सुसंगत रखना (कुछ लेखक यहां कॉन्फ़िगरेशन प्रबंधन शामिल करते हैं)।

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

प्रत्येक आवश्यकता का पता लगाया जाना चाहिएइसे प्राप्त करने के लिए, प्रत्येक आवश्यकता को एक अद्वितीय संख्या दी जाती है, जिसे तब अवधारणा विकास, डिज़ाइन और विधि लिस्टिंग के दौरान संदर्भित किया जाता है।

// आवश्यकता 4.3
// लेखक
// संस्करण
// तर्क
...विधि सूची...

परियोजना भागों में न केवल कार्यक्रमों का स्रोत कोड, बल्कि परियोजना योजना सहित सभी दस्तावेज भी शामिल हैं। उनके जीवन के दौरान, परियोजनाओं में दो दिशाओं में परिवर्तन होते हैं:

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

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

आमतौर पर, कॉन्फ़िगरेशन प्रबंधन प्रणालियाँ निम्नलिखित न्यूनतम आवश्यकताओं को पूरा करती हैं:

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

IEEE ने IEEE 828-1990 मानक विकसित किया"सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन योजना (एससीएमपी)।" मानक का शीर्षक और कॉन्फ़िगरेशन प्रबंधन योजना का एक उदाहरण एरिक ब्रैड की पुस्तक में दिया गया है।

चित्र - सहायक जीवन चक्र प्रक्रियाओं के विनियामक दस्तावेज़

संगठनात्मक जीवन चक्र प्रक्रियाएँ

जीवन चक्र की संगठनात्मक प्रक्रियाओं में शामिल हैं: बुनियादी ढांचे के निर्माण की प्रक्रिया, सुधार की प्रक्रिया, प्रशिक्षण की प्रक्रिया, प्रबंधन की प्रक्रिया।

चित्र - संगठनात्मक जीवन चक्र प्रक्रियाओं की संरचना

बुनियादी ढांचा निर्माण प्रक्रिया

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

चयनित प्रणाली के बुनियादी संकेतकों की पहचान की जाती है, जो किसी दिए गए एसीएस को डिजाइन करते समय इसकी विशेषताओं, सीमाओं, संसाधनों आदि को ध्यान में रखते हुए महत्वपूर्ण होते हैं।
सभी संकेतकों को एक तालिका में संक्षेपित किया गया है (तालिका 5 देखें), जिसमें, विशेषज्ञ आकलन के आधार पर, प्रत्येक संकेतक को एक वजन गुणांक वीआई (उदाहरण के लिए, 1 से 10 तक) सौंपा गया है, जो दूसरों की तुलना में इस संकेतक के महत्व को दर्शाता है। सभी भार गुणांकों के मानों का योग भार गुणांक की ऊपरी सीमा (उदाहरण के लिए, 10) के बराबर होना चाहिए।
साहित्यिक स्रोतों और/या विशेषज्ञों से प्राप्त डेटा का उपयोग करते हुए, प्रत्येक जे-वें सिस्टम के लिए प्रत्येक आई-वें संकेतक के लिए, उपयोगिता यूआई, जे की डिग्री निर्धारित की जाती है (1 - न्यूनतम, 10 - अधिकतम तक)। उदाहरण के लिए, एक कॉन्फ़िगरेशन प्रबंधन प्रणाली जो अपेक्षाकृत महंगी है, उसकी उपयोगिता रेटिंग 1 हो सकती है, जबकि एक स्वतंत्र रूप से उपलब्ध प्रणाली की उपयोगिता रेटिंग 10 होगी।
तुलना की जा रही प्रत्येक jth प्रणाली के लिए, मूल्यांकन फ़ंक्शन के मान की गणना सूत्र का उपयोग करके की जाती है: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
मूल्यांकन फ़ंक्शन के मूल्य के आधार पर, चयनित मानदंडों और निर्दिष्ट प्रतिबंधों को ध्यान में रखते हुए, किसी दिए गए प्रोजेक्ट में किसी विशेष प्रणाली का उपयोग करने की उपयुक्तता के बारे में निष्कर्ष निकाला जाता है। वह प्रणाली जिसके लिए मूल्यांकन फ़ंक्शन का मूल्य अधिक है, तुलनात्मक विकल्पों में से चयन के मामले में सबसे अच्छा है।

सीखने की प्रक्रिया

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

सुधार प्रक्रिया

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

सबसे अधिक उपयोग किए जाने वाले मेट्रिक्स हैं:

प्रदर्शन किए गए कार्य की मात्रा, भौतिक इकाइयों में मापी गई (उदाहरण के लिए, कोड की पंक्तियों की संख्या);
काम पर बिताया गया समय;
दोष दर (उदाहरण के लिए, कोड की प्रति 1000 पंक्तियों में दोषों की संख्या, प्रति दस्तावेज़ पृष्ठ दोषों की संख्या, आदि)।

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

प्रोजेक्ट डिलीवरी के बाद 12 सप्ताह के भीतर पहचाने गए सॉफ़्टवेयर कोड की प्रति हजार लाइनों में दोषों की संख्या।
प्रत्येक चरण में अनुसूची में विचलन: (वास्तविक अवधि - नियोजित अवधि) / नियोजित अवधि।
लागत में विचलन: (वास्तविक लागत - नियोजित लागत) / नियोजित लागत।
कुल डिज़ाइन समय / कुल प्रोग्रामिंग समय (कुछ अनुमानों के अनुसार कम से कम 50% होना चाहिए)।
किसी स्तर पर दोष किस हद तक प्रकट होते हैं और उनका पता लगाया जाता है, यह सबसे सरल मैट्रिक्स में से एक है।

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

वे चरण जिन पर दोष खोजे गए (इस परियोजना/मानक में)	दोष युक्त चरण
वे चरण जिन पर दोष खोजे गए (इस परियोजना/मानक में)	आवश्यकताओं का गठन	तकनीकी कार्य	प्रारंभिक डिजाइन
आवश्यकताओं का गठन	2/5
तकनीकी कार्य	0,5/1,5	3/1
प्रारंभिक डिजाइन	0,1/0,3	1/3	2/2

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

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

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

संगठनात्मक क्षमता परिपक्वता मॉडल

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

प्रबंधन की प्रक्रिया

परियोजना प्रबंधन लागत, क्षमताओं, गुणवत्ता और अनुसूची के बीच संतुलन हासिल करने के बारे में है। परियोजना प्रबंधन प्रक्रिया से जुड़े कई पहलू हैं: कार्मिक प्रबंधन, शेड्यूलिंग, परियोजना लागत अनुमान।

कार्मिक प्रबंधन

अनुभवजन्य डेटा को टीम के सदस्यों की इष्टतम संख्या निर्धारित करने के लिए जाना जाता है।

चित्र - विकास दल की प्रभावशीलता की उसकी संरचना पर निर्भरता

यह निर्भरता पदानुक्रमित प्रबंधन संरचनाओं का उपयोग करने की आवश्यकता की ओर ले जाती है

चित्रा - पदानुक्रमित प्रबंधन संरचना

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

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

एक शेड्यूल तैयार करना

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

चित्र - गैंट चार्ट का अनुमानित दृश्य

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

पीएस बनाने की लागत का अनुमान

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

श्रम तीव्रता का आकलन करने के लिए सबसे आम तरीकों में निम्नलिखित हैं:

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

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

सॉफ़्टवेयर विकास की श्रम तीव्रता का आकलन करने की प्रक्रिया में निम्नलिखित चरण शामिल हैं:

विकसित किये जा रहे उत्पाद के आकार का अनुमान लगाना;
मानव-महीना या मानव-घंटे में श्रम तीव्रता का आकलन;
कैलेंडर महीनों में परियोजना अवधि का अनुमान;
परियोजना लागत अनुमान.

सॉफ़्टवेयर आकार माप की मुख्य इकाइयाँ हैं:

कोड की पंक्तियों की संख्या (LOC - कोड की पंक्तियाँ);
फ़ंक्शन पॉइंट्स (एफपी - फ़ंक्शन पॉइंट्स)।

कार्यात्मक आकार का आकलन करने की पद्धति

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

- तार्किक रूप से संबंधित डेटा का एक उपयोगकर्ता-मान्यता प्राप्त समूह जो एप्लिकेशन के भीतर स्थित होता है और बाहरी इनपुट के माध्यम से परोसा जाता है।

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

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

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

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

गोस्ट आर 56376-2015/आईईईई सी37.92(2005)

रूसी संघ का राष्ट्रीय मानक

विद्युत मापने वाले कन्वर्टर्स

इलेक्ट्रॉनिक वोल्टेज और वर्तमान कन्वर्टर्स से सुरक्षात्मक रिले के एनालॉग इनपुट

विद्युत ट्रांसड्यूसर. इलेक्ट्रॉनिक वोल्टेज और वर्तमान ट्रांसड्यूसर से सुरक्षात्मक रिले के लिए एनालॉग इनपुट

ओकेएस 17.020

परिचय दिनांक 2016-01-01

प्रस्तावना

1 संघीय राज्य एकात्मक उद्यम "ऑल-रूसी रिसर्च इंस्टीट्यूट ऑफ मेट्रोलॉजिकल सर्विस" (एफएसयूई "वीएनआईआईएमएस") द्वारा पैराग्राफ 4 में निर्दिष्ट मानक के अंग्रेजी संस्करण के रूसी में अपने स्वयं के अनुवाद के आधार पर तैयार किया गया।

2 मानकीकरण के लिए तकनीकी समिति द्वारा प्रस्तुत टीसी 445 "ऊर्जा कुशल अर्थव्यवस्था की मेट्रोलॉजी"

3 मार्च 27, 2015 एन 192-सेंट के तकनीकी विनियमन और मेट्रोलॉजी के लिए संघीय एजेंसी के आदेश द्वारा अनुमोदित और प्रभावी किया गया

4 यह मानक अंतर्राष्ट्रीय मानक IEEE मानक C37.92(2005)* "इलेक्ट्रॉनिक वोल्टेज और करंट ट्रांसड्यूसर से सुरक्षात्मक रिले के एनालॉग इनपुट के लिए IEEE मानक", IDT) के समान है।
________________
* पाठ में उल्लिखित अंतरराष्ट्रीय और विदेशी दस्तावेजों तक पहुंच ग्राहक सहायता से संपर्क करके प्राप्त की जा सकती है। - डेटाबेस निर्माता का नोट।

इस मानक का नाम GOST R 1.5-2012 (खंड 3.5) के अनुपालन में लाने के लिए निर्दिष्ट अंतर्राष्ट्रीय मानक के नाम के सापेक्ष बदल दिया गया है।

इस मानक को लागू करते समय, संदर्भ अंतरराष्ट्रीय मानकों के बजाय, संबंधित राष्ट्रीय मानकों का उपयोग करने की अनुशंसा की जाती है, जिसके बारे में जानकारी अतिरिक्त परिशिष्ट हाँ में दी गई है।

5 पहली बार पेश किया गया

6 पुनर्प्रकाशन. अप्रैल 2019

इस मानक को लागू करने के नियम स्थापित किए गए हैं 29 जून 2015 के संघीय कानून का अनुच्छेद 26 एन 162-एफजेड "रूसी संघ में मानकीकरण पर" . इस मानक में परिवर्तनों के बारे में जानकारी वार्षिक (चालू वर्ष के 1 जनवरी तक) सूचना सूचकांक "राष्ट्रीय मानक" में प्रकाशित की जाती है, और परिवर्तनों और संशोधनों का आधिकारिक पाठ मासिक सूचना सूचकांक "राष्ट्रीय मानक" में प्रकाशित किया जाता है। इस मानक के संशोधन (प्रतिस्थापन) या रद्दीकरण की स्थिति में, संबंधित सूचना मासिक सूचना सूचकांक "राष्ट्रीय मानक" के अगले अंक में प्रकाशित की जाएगी। प्रासंगिक जानकारी, नोटिस और पाठ सार्वजनिक सूचना प्रणाली में भी पोस्ट किए जाते हैं - इंटरनेट पर तकनीकी विनियमन और मेट्रोलॉजी के लिए संघीय एजेंसी की आधिकारिक वेबसाइट (www.gost.ru) पर

1 उपयोग का क्षेत्र

1.1 सामान्य प्रावधान

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

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

1.2 लक्ष्य

माप प्रणाली और रिले सुरक्षा प्रणालियों के बीच सामान्यीकृत माप संकेत एक एनालॉग विद्युत संकेत है जिसका अधिकतम आयाम ±11.3 V और अधिकतम शक्ति 3.2 mW है।

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

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

चित्र 1 में चिह्नित क्षेत्र इस मानक द्वारा परिभाषित इंटरफेस का स्थान दिखाता है।

चित्र 1 - एक मानकीकृत एनालॉग इंटरफ़ेस के साथ ऑप्टिकल वर्तमान माप प्रणाली

2 मानक संदर्भ

यह मानक निम्नलिखित मानकों के मानक संदर्भों का उपयोग करता है। दिनांक संदर्भ के लिए, केवल संस्करण लागू किया। अदिनांकित लोगों के लिए, नवीनतम संस्करण (सभी संशोधनों और परिवर्तनों सहित)।

आईईईई कक्षा 525™, सबस्टेशनों में केबल सिस्टम के डिजाइन और स्थापना के लिए आईईईई गाइड
_______________
आईईईई प्रकाशन इंस्टीट्यूट ऑफ इलेक्ट्रिकल एंड इलेक्ट्रॉनिक्स इंजीनियर्स, इंक., 445 होस लेन, पिस्काटावे, एनजे 08854, यूएसए (http://standards.ieee.org/) से खरीदे जा सकते हैं।

आईईईई कक्षा 1050™, उत्पादन स्टेशनों में इंस्ट्रुमेंटेशन और नियंत्रण उपकरण ग्राउंडिंग के लिए आईईईई गाइड

IEEE Std C37.90™, इलेक्ट्रिक पावर उपकरण से जुड़े रिले और रिले सिस्टम के लिए IEEE मानक (बिजली उपकरणों की सुरक्षा और नियंत्रण के लिए उपयोग किए जाने वाले रिले और रिले सिस्टम)

आईईईई मानक सी37.90.1™, इलेक्ट्रिक पावर उपकरण से जुड़े रिले और रिले सिस्टम के लिए आईईईई मानक सर्ज झेलने की क्षमता (एसडब्ल्यूसी) परीक्षण (बिजली उपकरण की सुरक्षा और नियंत्रण के लिए उपयोग किए जाने वाले रिले और रिले सिस्टम के वोल्टेज उछाल के प्रतिरोध के लिए परीक्षण)

आईईईई मानक सी37.90.2™, ट्रांससीवर्स से विकिरणित विद्युत चुम्बकीय हस्तक्षेप के लिए रिले सिस्टम की क्षमता का सामना करने के लिए आईईईई मानक

आईईईई मानक सी57.13™, उपकरण ट्रांसफार्मर के लिए आईईईई मानक आवश्यकताएँ। आईईईई प्रकाशन इंस्टीट्यूट ऑफ इलेक्ट्रिकल एंड इलेक्ट्रॉनिक्स इंजीनियर्स, इंक., 445 होस लेन, पिस्काटावे, एनजे 08854, यूएसए (http://standards.ieee.org/) (इंस्ट्रूमेंट ट्रांसफार्मर आवश्यकताएँ) से उपलब्ध हैं।

3 नियम और परिभाषाएँ

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

3.1 एक सापेक्ष इकाईएक प्रति यूनिट (संक्षिप्त रूप में: 1 पी.यू.): माप प्रणाली का मापा आउटपुट मान या आउटपुट जो माप सर्किट में वोल्टेज या करंट के नाममात्र प्राथमिक आरएमएस मापा मूल्य से मेल खाता है।

3.2 रिले इनपुट(रिले इनपुट): किसी भी रिले टर्मिनल, मीटर, मापने या नियंत्रण उपकरण, या बुद्धिमान इलेक्ट्रॉनिक उपकरण का एनालॉग इलेक्ट्रॉनिक इनपुट जो इस मानक का अनुपालन करता है।

3.3 माप प्रणाली(सेंसिंग सिस्टम): इलेक्ट्रॉनिक सेंसर, डिवाइस, ऑप्टिकल-इलेक्ट्रॉनिक इंटरफ़ेस या एनालॉग सिग्नल स्रोत जो विद्युत नेटवर्क में मापा वोल्टेज या वर्तमान मान उत्पन्न करता है, जिसका आउटपुट इस मानक का अनुपालन करता है।

4 सामान्य आवश्यकताएँ

4.1 कनेक्शन डिवाइस

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

4.2 पृथ्वी से गैल्वेनिक अलगाव

माप प्रणाली के दोनों आउटपुट टर्मिनलों और किसी भी रिले इनपुट को डीसी या पावर फ्रीक्वेंसी सिग्नल के संपर्क में आने पर सुरक्षात्मक जमीन या फ्रेम ग्राउंड से अलग किया जाना चाहिए। किसी भी टर्मिनल और जमीन के बीच अनुमत धारिता 0.01 µF से अधिक नहीं होनी चाहिए।

4.3 ध्रुवता चिह्न और विपरीत ध्रुवता का प्रतिरोध

इंटरफेस में पारंपरिक "सीटीएस" और "वीटीएस" से युक्त ध्रुवीयता चिह्न होना चाहिए। आईईईई कक्षा सी57.13 देखें।
_______________
लिंक जानकारी अनुभाग 2 में प्रदान की गई है।

माप प्रणाली के असंतुलित आउटपुट के लिए, सिग्नल आउटपुट टर्मिनल को उपयुक्त ध्रुवता चिह्न या पारंपरिक माप ट्रांसफार्मर के द्वितीयक टर्मिनल X1 के रूप में चिह्नित किया जाना चाहिए।

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

प्रत्येक मापन प्रणाली और प्रत्येक रिले पर एक निर्माता का लेबल होना चाहिए जो यह बताता हो कि यह केवल गैर-प्रतिवर्ती ध्रुवता में उपलब्ध है या इसका उपयोग विपरीत ध्रुवता में किया जा सकता है।

प्रतिवर्ती ध्रुवता एक पूरी तरह से पृथक या संतुलित इनपुट या आउटपुट को संदर्भित करती है जिसे निर्दिष्ट ध्रुवता में जोड़ा जा सकता है।

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

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

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

नोट - किसी विशेष सुरक्षा रिले की आंतरिक या सॉफ़्टवेयर सेटिंग्स इनपुट की ध्रुवीयता को बदल सकती हैं;

- यदि कई रिले के प्रत्येक इनपुट के लिए प्रतिवर्ती ध्रुवता का उपयोग किया जाता है, तो प्रत्येक रिले को आवश्यक ध्रुवता के साथ जोड़ा जा सकता है, भले ही स्रोत से आउटपुट गैर-प्रतिवर्ती न हो।

इससे इलेक्ट्रॉनिक माप प्रणाली के एनालॉग आउटपुट का उपयोग करके रिवर्स पोलरिटी इनपुट वाले रिले और अन्य उपकरणों का उपयोग करने का लचीलापन बढ़ जाता है।

सममित या प्रतिवर्ती आउटपुट टर्मिनल जमीन के संबंध में सममित होने चाहिए।

4.4 माप प्रणालियों के अतिरिक्त आउटपुट

4.4.1 चेतावनी आउटपुट

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

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

4.4.2 प्रेषित डेटा की शुद्धता का आउटपुट सिग्नल

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

यह आउटपुट निम्नलिखित में से एक या दोनों रूप ले सकता है:

- संपर्क प्रकार "ए", संभावित-मुक्त, और माप प्रणाली के निर्माता द्वारा निर्दिष्ट। सामान्य, सही परिचालन स्थितियों के तहत, सिग्नल प्रदान करने या गलत आउटपुट सिग्नल के लिए सुरक्षा लॉक प्रदान करने के लिए रिले वाइंडिंग (कॉइल) को हमेशा सक्रिय रहना चाहिए। संपर्क IEEE मानक C37.90 के अनुसार किया जाना चाहिए। ट्रिगर प्रभाव (संपर्क बाउंस) की स्थिति में आउटपुट ब्लॉकिंग विलंब 12 एमएस से अधिक नहीं होना चाहिए;

- टीटीएल तर्क स्तर (0 से 5 वी) की प्रतिक्रिया 1 एमएस या इससे तेज है (5.8 देखें)। इस मामले में, तार्किक स्तर (5 वी) का मतलब प्रेषित डेटा की शुद्धता है।

4.5 विद्युत चुम्बकीय अनुकूलता परीक्षण

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

4.5.1 ढांकता हुआ परीक्षण

ये परीक्षण IEEE Std C37.90 में वर्णित ढांकता हुआ परीक्षण विधियों के अनुसार आयोजित किए जाएंगे। परीक्षण वोल्टेज केवल इनपुट या आउटपुट टर्मिनलों की प्रत्येक जोड़ी और सुरक्षात्मक अर्थ या फ्रेम अर्थ के बीच सामान्य मोड में लागू किया जाता है। 50 V तक के सिग्नल सर्किट का परीक्षण IEEE मानक C37.90 के अनुसार निम्न ढांकता हुआ परीक्षण वोल्टेज पर किया जाता है।

5.1.1 वर्तमान माप प्रणाली के लिए सिग्नल विवरण

गतिशील रेंज: 0.05 से 40 गुना नाममात्र;

नाममात्र आउटपुट स्तर (या 1 पी.यू.): 200 एमवी (आरएमएस);

अधिकतम तात्कालिक मान: 0.200x40x1.414 = 11.3 वी (शिखर)।

आयाम और चरण त्रुटियां 50 या 60 हर्ट्ज पर स्केल किए गए प्राथमिक सिग्नल के वास्तविक मूल्य से अधिकतम विचलन हैं।

तालिका 1 - वर्तमान माप प्रणाली के लिए सिग्नल का विवरण


वर्तमान श्रृंखला	आयाम त्रुटि	चरण त्रुटि
0.05 पी.यू. से. 0.1 पी.यू. तक
0.10 पी.यू. से. 1.0 पी.यू. तक
1.0 पी.यू. से. 5.0 पी.यू. तक
5.0 पी.यू. से. 40 पी.यू. तक

अरैखिक विरूपण कारक का कुल मान आयाम त्रुटि से कम या उसके बराबर होना चाहिए।

सिग्नल-टू-शोर अनुपात 0.1 पी.यू. से अधिक सिग्नल के साथ 54 डीबी से अधिक या उसके बराबर होना चाहिए। माप पावर फ्रीक्वेंसी सिग्नल पर किया जाना चाहिए और शोर माप बैंडविड्थ 120 हर्ट्ज के भीतर होना चाहिए।

वर्तमान माप प्रणाली को 1 p.u. पर नाममात्र 2 Vrms अतिरिक्त आउटपुट प्रदान किया जा सकता है, अधिकतम आउटपुट मान 4 p.u. यह आउटपुट उन अनुप्रयोगों के लिए है जहां आवश्यक माप सटीकता आम तौर पर स्वीकृत से अधिक है। हिरासत हस्तांतरण अनुप्रयोगों के लिए, सेंसर निर्माता को उचित सटीकता मानक, जैसे IEEE Std C57.13 या उसके कुछ हिस्सों के अनुपालन को अलग से प्रदर्शित करना होगा।

5.1.2 वोल्टेज मापने वाली प्रणालियों के लिए सिग्नल विवरण

गतिशील रेंज नाममात्र मूल्य से 0.05 से 2.0 गुना तक।

नाममात्र आउटपुट स्तर (या 1 पु.): 4 वी (आरएमएस)।

अधिकतम आउटपुट: 4.0 x 2.0 x 1.414 = 11.3 वी (पीक)।

आयाम और चरण त्रुटियां 50 या 60 हर्ट्ज पर वास्तविक स्केल किए गए प्राथमिक सिग्नल के मूल्य से अधिकतम विचलन हैं।

तालिका 2 - वोल्टेज माप प्रणाली सिग्नल का विवरण


वोल्टेज की सीमा	आयाम त्रुटि	चरण त्रुटि
0.05 पी.यू. से. 0.85 पी.यू. तक
0.85 पी.यू. से. 1.15 पी.यू. तक.
1.15 पु. से. 2.0 पी.यू. तक

अरेखीय विरूपण कारक का कुल मान त्रुटि मान से कम या उसके बराबर होना चाहिए।

सिग्नल-टू-शोर अनुपात 0.85 पी.यू. से अधिक सिग्नल के साथ 70 डीबी से अधिक या उसके बराबर होना चाहिए। माप एक पावर फ्रीक्वेंसी सिग्नल और कम से कम 120 हर्ट्ज की शोर माप बैंडविड्थ का उपयोग करके किया जाना चाहिए।

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

हिरासत हस्तांतरण अनुप्रयोगों के लिए, सेंसर निर्माता को प्रासंगिक सटीकता मानकों, जैसे IEEE Std C57.13 या उसके हिस्सों के अनुपालन को अलग से प्रदर्शित करना होगा।

5.2 चरण सुधार

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

नोट यह ऊपर उल्लिखित कोणीय त्रुटियों का अनुपालन करने के लिए माप प्रणाली की आवश्यकता को समाप्त नहीं करता है।

5.3 रेटेड लोड

लगभग 5 kOhm के लोड और 5 nF तक के कैपेसिटिव लोड को कनेक्ट करते समय माप प्रणाली की सटीकता को इस मानक की आवश्यकताओं को पूरा करना चाहिए। माप प्रणाली के एक आउटपुट को समानांतर में कई रिले या अन्य माप उपकरणों से जोड़ा जा सकता है। रिले या अन्य कनेक्टेड डिवाइस में कम से कम 50 kOhm का इनपुट प्रतिबाधा होना चाहिए, लेकिन 200 kOhm से अधिक नहीं।

5.4 सामान्य मोड कटौती

माप सर्किट इनपुट और आउटपुट के लिए सामान्य मोड क्षीणन ±50 वी तक के सामान्य मोड सिग्नल के लिए 50 या 60 हर्ट्ज पर 86 डीबी से अधिक होना चाहिए। यह मान वर्तमान माप के इनपुट पर 20 वी की वोल्टेज गड़बड़ी के लिए निर्दिष्ट है सिस्टम। जिस पर वर्तमान मान 0.5 पी.यू. है, और जब सामान्य प्रकार का शोर मापा सिग्नल स्तर के 10% से कम है।

5.5 शून्य क्षेत्र से आउटपुट सिग्नल का विचलन

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

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

5.6 बैंडविड्थ और क्षणिक प्रतिक्रिया

माप प्रणाली के आपूर्तिकर्ता को आवृत्ति प्रतिक्रिया निर्दिष्ट करनी होगी। 5.1 में निर्दिष्ट बिजली आवृत्ति (मुख्य आवृत्ति) का विचलन 45 और 65 हर्ट्ज के बीच होना चाहिए। प्रतिक्रिया कम से कम 3 kHz तक 0 से -1 dB और 5 kHz तक 0 से -3 dB होनी चाहिए। निचली कट-ऑफ आवृत्ति (यदि मौजूद हो) को इस तरह सेट किया जाना चाहिए कि सिस्टम निरंतर सिग्नल ऑफसेट प्रतिक्रिया के लिए निम्नलिखित आवश्यकता को पूरा कर सके।

20 पी.यू. के मान के साथ प्राथमिक धारा ("निरंतर सिग्नल ऑफसेट") की घातीय क्षय प्रतिक्रिया को पूरी तरह से ऑफसेट करने के लिए। 100 एमएस तक स्थिर किसी भी समय के लिए तात्कालिक स्केलिंग कारक त्रुटि 10% से अधिक नहीं होनी चाहिए।

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

कुछ ग्राहकों को कम सटीकता आवश्यकताओं के साथ 65 से 75 हर्ट्ज रेंज में आवृत्तियों के लिए सिस्टम संचालन की आवश्यकता हो सकती है। यह अनुशंसा की जाती है कि माप प्रणाली का आपूर्तिकर्ता इस आवृत्ति रेंज में इसके संचालन की तकनीकी विशेषताओं के लिए आवश्यकताओं को परिभाषित करे।

5.7 त्रुटि सिग्नल का पता लगाने की स्थापना

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

आमतौर पर, समस्या की पहचान त्रुटियों का पता लगाने के लिए उसी विधि का उपयोग करके की जाती है, जैसा कि आउटपुट से डेटा संचारित करने के लिए शुद्धता की जांच के दौरान किया जाता है, जैसा कि 4.4.2 में वर्णित है।

5.8 प्रेषित डेटा की शुद्धता के लिए सिग्नल का विवरण

4.4.2 डेटा वैधता जानकारी देने वाला वैकल्पिक सिग्नल एक टीटीएल स्तर सिग्नल (0 या 5 वी) होगा, जो सुरक्षात्मक पृथ्वी से अलग होगा, और एनालॉग माप प्रणाली सिग्नल के प्रसारण के लिए उसी कनेक्शन विधि का उपयोग करके प्रसारित करने का इरादा होगा (अनुभाग देखें) 7). 3.0 से 5.5 वी तक की एक तार्किक इकाई माप प्रणाली के आउटपुट पर सही डेटा की उपस्थिति के बारे में सूचित करती है। 0 से 0.5 V की सीमा में एक तार्किक शून्य को माप प्रणाली के आउटपुट पर डेटा त्रुटि का संकेत देना चाहिए। इस वैकल्पिक सिग्नल का आउटपुट निर्दिष्ट विनिर्देशों के भीतर 200 ओम या उससे अधिक के लोड प्रतिबाधा में वोल्टेज देने में सक्षम होना चाहिए। ट्रिगरिंग इवेंट से आउटपुट स्थिति में बदलाव तक की देरी 1 एमएस से अधिक नहीं होनी चाहिए।

इस सिग्नल को प्राप्त करने के लिए सुरक्षात्मक रिले में इनपुट सर्किट को सुरक्षात्मक जमीन से अलग किया जाना चाहिए और 2 kOhm से अधिक का इनपुट प्रतिरोध होना चाहिए। इस मामले में, केवल 2.5 वी से ऊपर के स्तर वाले संकेतों को एक तार्किक इकाई के रूप में माना जाना चाहिए।

6 मध्यवर्ती उपकरण

6.1 उद्देश्य

मध्यवर्ती उपकरणों का उपयोग माप प्रणालियों के व्यक्तिगत आउटपुट का योग या अंतर बनाने के लिए किया जा सकता है। उनका उपयोग माप प्रणाली के एकल आउटपुट से जुड़े विभिन्न प्रकार के रिले या मीटर के इनपुट को अलग करने के लिए भी किया जा सकता है। मध्यवर्ती उपकरणों में एकता लाभ हो सकता है या माप प्रणाली के लाभ को बदलने के लिए व्यक्तिगत इनपुट की स्केलिंग शामिल हो सकती है।

मध्यवर्ती उपकरणों का उपयोग पारंपरिक उपकरण ट्रांसफार्मर के आउटपुट को माप इलेक्ट्रॉनिक प्रणाली के आउटपुट के साथ मिलान करने के लिए भी किया जा सकता है। इस अनुभाग में परिभाषित ऑपरेटिंग आवश्यकताएँ केवल एनालॉग इलेक्ट्रॉनिक आउटपुट वाले मध्यवर्ती उपकरणों पर लागू होती हैं।

6.2 मध्यवर्ती उपकरणों के लिए प्रदर्शन आवश्यकताएँ

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

तालिका 3 - मध्यवर्ती डिवाइस प्रदर्शन आवश्यकताएँ


हार्मोनिक विरूपण (कुल हार्मोनिक विरूपण)	1 पी.यू. का 0.1% से कम। 1 हर्ट्ज से 20 किलोहर्ट्ज़ की सीमा में करंट
त्रुटि प्राप्त करें	1 पी.यू. का 0.1% से कम। 45 हर्ट्ज से 75 किलोहर्ट्ज़ की सीमा में धारा
चरण त्रुटि	45 हर्ट्ज से 75 किलोहर्ट्ज़ तक 0.1° से कम
आवृत्ति प्रतिक्रिया	निर्माता द्वारा स्थापित; 15 हर्ट्ज से 10 किलोहर्ट्ज़ की सीमा में 0 ... -1 डीबी के भीतर रैखिक
शोर अनुपात करने के लिए संकेत	1 पी.यू. पर 80 डीबी से बेहतर। 120 हर्ट्ज तक बैंडविड्थ के साथ करंट या वोल्टेज

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

6.3 मध्यवर्ती उपकरणों के लिए अन्य आवश्यकताएँ

मध्यवर्ती उपकरण धारा 4 और 5 की अन्य सभी आवश्यकताओं का अनुपालन करेंगे, लेकिन 6.2 में निर्दिष्ट आवश्यकताओं का नहीं। उन्हें IEEE Std C37.90 में निर्दिष्ट परिचालन, परिवहन और भंडारण स्थितियों की सीमा के भीतर आवश्यकताओं को पूरा करना होगा।

मध्यवर्ती उपकरणों के लिए 7 स्थापना निर्देश

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

आपको निम्नलिखित मुख्य विशेषताओं पर ध्यान देना चाहिए, जो सभी चित्रों में समान हैं:

- वायर्ड कनेक्शन मानता है कि उपकरण ने धारा 4 में निर्दिष्ट सामान्य मोड अस्वीकृति परीक्षण पास कर लिया है और धारा 5 में निर्दिष्ट सामान्य मोड अस्वीकृति अनुपात ज्ञात है;

- कोई भी मुड़ा हुआ सिग्नल कंडक्टर किसी भी बिंदु पर ग्राउंडेड नहीं है;

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

- ध्यान दें कि एकल-समाप्त या गैर-प्रतिवर्ती ध्रुवता वाला कोई भी मीटरिंग सिस्टम या रिले, जिसका सुरक्षा ग्राउंड इंटरफ़ेस के सामान्य या गैर-ध्रुवीकृत आउटपुट से आंतरिक संबंध है, सिग्नल समस्याएं पैदा कर सकता है या अन्य उपकरणों की इन्सुलेशन सुरक्षा से समझौता कर सकता है;

चित्र 2 - एक माप प्रणाली और एक रिले इनपुट

चित्र 3 - एकाधिक रिले इनपुट के साथ एक माप प्रणाली

चित्र 4 - एकाधिक माप प्रणाली और मध्यवर्ती उपकरण

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

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

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

परिशिष्ट ए (संदर्भ के लिए)। सुरक्षित उपयोग

परिशिष्ट ए
(जानकारीपूर्ण)

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

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

A.1 कम आवृत्ति क्षेत्र में आयाम-आवृत्ति प्रतिक्रिया

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

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

A.3 कदम प्रतिक्रिया

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

उपयोगकर्ता को इन विकृतियों के प्रति रिले की प्रतिक्रिया की जांच करनी चाहिए। कृपया ध्यान रखें कि सकारात्मक या नकारात्मक उछाल के कारण उच्च गति रिले गलत तरीके से संचालित हो सकते हैं।

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

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

यह ध्यान दिया जाना चाहिए कि 5.6 में माप प्रणाली की क्षणिक विशेषताएं शामिल हैं, जो एक चरण पल्स की प्रतिक्रिया द्वारा निर्धारित होती हैं।

A.4 चरण विलंब

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

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

धारा 5.2 निर्माता द्वारा प्रदान किए गए चरण सुधार के चयन के लिए एक अतिरिक्त विकल्प का वर्णन करता है।

A.5 भार क्षमता

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

A.6 दोष और अलार्म

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

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

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

A.7 अंशांकन

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

दोषपूर्ण इलेक्ट्रॉनिक रूपांतरण मॉड्यूल को प्रतिस्थापित करते समय माप प्रणाली आपूर्तिकर्ता को ग्राहक को यह निर्देश देना चाहिए कि सिस्टम अंशांकन के साथ क्या करना है।

A.8 डिजिटल इंटरफेस

यह मानक केवल निम्न-स्तरीय एनालॉग इंटरफेस को कवर करता है, जिसमें बड़े सिस्टम में एम्बेडेड वे भी शामिल हैं जिनमें डिजिटल डेटा इंटरफेस हैं और जहां एनालॉग इंटरफेस के लिए इंटरऑपरेबिलिटी निर्माताओं और उपयोगकर्ताओं दोनों के लिए महत्वपूर्ण है।

डिजिटल इंटरफेस को माप प्रणाली और रिले के बीच संचार के लिए नमूना प्रक्रियाओं, प्रदर्शन और बहु-परत संचार प्रोटोकॉल परतों के विनिर्देश की आवश्यकता होती है। विद्युत नेटवर्क जानकारी प्रदान करने के लिए डिजिटल डेटा इंटरफेस आईईसी 61850-9-1, आईईसी 61850-9-2, आईईसी 60044-7 और आईईसी 60044-8 में प्रदान किए गए हैं।

परिशिष्ट हाँ (आवश्यक)। राष्ट्रीय मानकों के साथ संदर्भ अंतर्राष्ट्रीय मानकों के अनुपालन पर जानकारी

आवेदन हाँ
(आवश्यक)

तालिका डीए.1


संदर्भ अंतर्राष्ट्रीय मानक का पदनाम	अनुपालन की डिग्री	संबंधित राष्ट्रीय मानक का पदनाम और नाम



आईईईई कक्षा सी37.90.1
आईईईई कक्षा सी37.90.2

*इसके अनुरूप कोई राष्ट्रीय मानक नहीं है। इसे अपनाने से पहले, इस अंतर्राष्ट्रीय मानक के रूसी अनुवाद का उपयोग करने की अनुशंसा की जाती है।

ग्रन्थसूची

आईईईई पी1331 ड्राफ्ट 8.3, अप्रैल 1999: सुरक्षात्मक रिलेइंग के लिए कम ऊर्जा एनालॉग सिग्नल इनपुट के लिए परीक्षण उपयोग मानक


यूडीसी 621.3.089.6:006.354

मुख्य शब्द: विद्युत मापने वाले कनवर्टर, एनालॉग इनपुट, सुरक्षात्मक रिले, वोल्टेज और वर्तमान कनवर्टर

इलेक्ट्रॉनिक दस्तावेज़ पाठ
कोडेक्स जेएससी द्वारा तैयार और इसके विरुद्ध सत्यापित:
आधिकारिक प्रकाशन
एम.: स्टैंडआर्टिनफॉर्म, 2019

बैरिशनिकोवा मरीना युरेविना
एमएसटीयू इम. एन.ई. बाऊमन
कैफ़े. आईयू-7

व्याख्यान 3

सॉफ्टवेयर जीवन चक्र
प्रावधान

सॉफ्टवेयर जीवन चक्र

समय की एक अवधि है जो शुरू होती है
निर्णय लेने का क्षण
सॉफ्टवेयर बनाने की आवश्यकता
प्रावधान और इस समय समाप्त होता है
यह सेवा से पूर्णतः अलग है
(आईईईई कक्षा 610.12-19990 सॉफ्टवेयर की मानक शब्दावली
इंजीनियरिंग शब्दावली)

जीवन चक्र को परिभाषित करने में शामिल बुनियादी अवधारणाएँ

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

आईएसओ/आईईसी 12207:1995 मानक के अनुसार सॉफ्टवेयर जीवन चक्र
"अंतर्राष्ट्रीय प्रौद्योगिकी - सॉफ्टवेयर जीवन चक्र प्रक्रियाएं"
(गोस्ट आईएसओ आईईसी 12207-99 सूचना प्रौद्योगिकी।
सॉफ़्टवेयर जीवन चक्र)
जीवन चक्र
संगठनात्मक
प्रक्रियाओं
नियंत्रण
परियोजना
निर्माण
आधारभूत संरचना
मूल्यांकन एवं सुधार
जीवन चक्र
शिक्षा
बुनियादी
प्रक्रियाओं
अधिग्रहण
सहायक
प्रक्रियाओं
प्रलेखन
आपूर्ति
नियंत्रण
विन्यास
विकास
सुरक्षा
गुणवत्ता
शोषण
सत्यापन
अनुरक्षण
प्रमाणीकरण
संयुक्त
श्रेणी
अंकेक्षण
अनुमति
समस्या

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

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

विकास की प्रक्रिया

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

विकास की प्रक्रिया

जीवन चक्र मॉडल चुनना
सिस्टम आवश्यकताओं का विश्लेषण
सिस्टम आर्किटेक्चर डिज़ाइन
सॉफ़्टवेयर आवश्यकताओं का विश्लेषण
विस्तृत सॉफ़्टवेयर डिज़ाइन
सॉफ्टवेयर कोडिंग और परीक्षण
सॉफ्टवेयर एकीकरण
सॉफ्टवेयर योग्यता परीक्षण
प्रणाली एकीकरण
सिस्टम योग्यता परीक्षण
सॉफ्टवेयर स्थापना
सॉफ्टवेयर स्वीकृति

10. सिस्टम आवश्यकताओं का विश्लेषण

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

11. सॉफ्टवेयर आवश्यकताओं का विश्लेषण

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

12. सॉफ्टवेयर आर्किटेक्चर डिजाइन

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

13. विस्तृत सॉफ्टवेयर डिजाइन (सॉफ्टवेयर विकास कार्य योजना)

निम्नलिखित कार्य शामिल हैं:
सॉफ़्टवेयर घटकों और इंटरफ़ेस का विवरण
उन्हें उनके लिए पर्याप्त मात्रा में
बाद में स्वतंत्र कोडिंग और
परिक्षण
विस्तृत का विकास एवं प्रलेखन
डेटाबेस प्रोजेक्ट
उपयोगकर्ता दस्तावेज़ीकरण अद्यतन करना
के लिए आवश्यकताओं का विकास और दस्तावेज़ीकरण
परीक्षण और सॉफ्टवेयर घटक परीक्षण योजना

14. सॉफ़्टवेयर कोडिंग और परीक्षण में निम्नलिखित कार्यों को हल करना शामिल है:

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

15. सिस्टम एकीकरण

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

16. सॉफ्टवेयर योग्यता परीक्षण

डेवलपर की उपस्थिति में किया गया
ग्राहक को यह प्रदर्शित करना होगा कि सॉफ्टवेयर
इसके विनिर्देशों को पूरा करता है और
परिस्थितियों में उपयोग के लिए तैयार
संचालन
यह पूर्णता की भी जाँच करता है
तकनीकी और उपयोगकर्ता दस्तावेज़ीकरण और
सॉफ़्टवेयर घटकों के लिए इसकी पर्याप्तता

17. सॉफ्टवेयर की स्थापना और स्वीकृति

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

18. सॉफ्टवेयर संचालन

में सिस्टम संचालित है
इस उद्देश्य के लिए पर्यावरण का इरादा है
प्रथा के अनुसार
प्रलेखन
स्थापना शामिल है
परिचालन मानक और
संचालन करना
परिक्षण

19. सॉफ्टवेयर रखरखाव (आईईईई - 90 मानक के अनुसार)

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

20. सॉफ़्टवेयर जीवन चक्र की सहायक प्रक्रियाएँ

प्रलेखन
विन्यास प्रबंधन
गुणवत्ता आश्वासन
सत्यापन
प्रमाणीकरण
सहभागी मूल्यांकन
अंकेक्षण
समस्या का समाधान

21. दस्तावेज़ीकरण प्रक्रिया

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

22. विन्यास प्रबंधन

सॉफ्टवेयर कॉन्फ़िगरेशन है
इसके कार्यात्मक और भौतिक की समग्रता
तकनीकी में स्थापित विशेषताएँ
दस्तावेज़ीकरण और कार्यक्रमों में कार्यान्वित
यह प्रक्रिया आपको व्यवस्थित रूप से व्यवस्थित करने की अनुमति देती है
परिवर्तनों को ध्यान में रखें और नियंत्रित करें
जीवन चक्र के सभी चरणों में सॉफ़्टवेयर
कॉन्फ़िगरेशन प्रबंधन के लिए सामान्य सिद्धांत और अनुशंसाएँ परिलक्षित होती हैं
आईएसओ/आईईसी सीडी 12207 - 2:1995 में "सूचना प्रौद्योगिकी - सॉफ्टवेयर" मानक
चक्र प्रक्रियाएं. भाग 2. सॉफ़्टवेयर के लिए कॉन्फ़िगरेशन प्रबंधन”

23. गुणवत्ता आश्वासन प्रक्रिया

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

24. सत्यापन

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

25. प्रमाणीकरण

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

26. सॉफ़्टवेयर जीवन चक्र की संगठनात्मक प्रक्रियाएँ

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

27. ईएसपीडी मानकों के समूह

समूह कोड
0
1
2
3
4
5
6
7
8
9
समूह नाम
सामान्य प्रावधान
मौलिक मानक
विकास दस्तावेज़ीकरण निष्पादित करने के नियम
विनिर्माण दस्तावेज़ीकरण पूरा करने के नियम
समर्थन दस्तावेज निष्पादित करने के नियम
परिचालन प्रलेखन के कार्यान्वयन के लिए नियम
सॉफ़्टवेयर दस्तावेज़ीकरण के संचलन के नियम
आरक्षित समूह
अन्य मानक
ईएसपीडी मानक के पदनाम में निम्न शामिल हैं:
संख्या 19 (ईएसपीडी मानकों के वर्ग को सौंपा गया);
मानकों के वर्गीकरण समूह के कोड को दर्शाने वाला एक अंक (बिंदु के बाद),
तालिका में दर्शाया गया है;
मानक के पंजीकरण के वर्ष को दर्शाने वाली दो अंकों की संख्या (डैश के बाद)।

28. ईएसपीडी दस्तावेजों की सूची

गोस्ट 19.001-77 ईएसपीडी। सामान्य प्रावधान
गोस्ट 19.101-77 ईएसपीडी। प्रोग्राम के प्रकार और प्रोग्राम दस्तावेज़
गोस्ट 19.102-77 ईएसपीडी। विकास के चरण
गोस्ट 19.103-77 ईएसपीडी। कार्यक्रमों और कार्यक्रम दस्तावेजों का पदनाम
गोस्ट 19.104-78 ईएसपीडी। मूल शिलालेख
गोस्ट 19.105-78 ईएसपीडी। कार्यक्रम दस्तावेज़ों के लिए सामान्य आवश्यकताएँ
गोस्ट 19.106-78 ईएसपीडी। मुद्रित प्रोग्राम दस्तावेज़ों के लिए आवश्यकताएँ
गोस्ट 19.201-78 ईएसपीडी। तकनीकी कार्य. सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.202-78 ईएसपीडी। विशिष्टता. सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.301-79 ईएसपीडी। परीक्षण प्रक्रिया और कार्यप्रणाली
गोस्ट 19.401-78 ईएसपीडी। कार्यक्रम पाठ. सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.402-78 ईएसपीडी। कार्यक्रम विवरण
गोस्ट 19.404-79 ईएसपीडी। व्याख्यात्मक नोट। सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.501-78 ईएसपीडी। रूप। सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.502-78 ईएसपीडी। आवेदन का विवरण. सामग्री और डिज़ाइन के लिए आवश्यकताएँ
गोस्ट 19.503-79 ईएसपीडी। सिस्टम प्रोग्रामर गाइड. सामग्री आवश्यकताएँ और
पंजीकरण
गोस्ट 19.504-79 ईएसपीडी। प्रोग्रामर गाइड
गोस्ट 19.505-79 ईएसपीडी। नियम - पुस्तक संचालक
गोस्ट 19.506-79 ईएसपीडी। भाषा विवरण
गोस्ट 19.508-79 ईएसपीडी। रखरखाव निर्देशिका। सामग्री आवश्यकताएँ और
पंजीकरण
गोस्ट 19.604-78 ईएसपीडी। निष्पादित प्रोग्राम दस्तावेज़ों में परिवर्तन करने के नियम
मुद्रित रूप में
गोस्ट 19.701-90 ईएसपीडी। एल्गोरिदम, प्रोग्राम, डेटा और सिस्टम की योजनाएं। कन्वेंशन और
निष्पादन नियम
गोस्ट 19.781-90. सूचना प्रसंस्करण प्रणाली प्रदान करना

29. ईएसपीडी मानकों का उपयोग करने के लाभ

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

30. ईएसपीडी मानकों के नुकसान

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

31. मानक GOST 34.601-90: एक स्वचालित प्रणाली बनाने के चरण और चरण

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

32.

मानक GOST 34.601-90: चरण और चरण
एक स्वचालित प्रणाली का निर्माण
5.
तकनीकी परियोजना
6.
कामकाजी दस्तावेज
7.
एनपीपी और उसके भागों के लिए कार्यशील दस्तावेज़ीकरण का विकास
कार्यक्रमों का विकास एवं अनुकूलन
चालू
8.
सिस्टम और उसके भागों के लिए डिज़ाइन समाधान का विकास
स्पीकर सिस्टम और उसके भागों के लिए दस्तावेज़ीकरण का विकास
घटकों की आपूर्ति के लिए दस्तावेज़ीकरण का विकास और निष्पादन
परियोजना के निकटवर्ती भागों में डिज़ाइन कार्यों का विकास
एक स्वचालन वस्तु तैयार करना
कर्मियों का प्रशिक्षण
आपूर्ति किए गए उत्पादों (सॉफ्टवेयर और हार्डवेयर) के साथ स्पीकर का पूरा सेट
सॉफ्टवेयर और हार्डवेयर सिस्टम, सूचना उत्पाद)
निर्माण एवं स्थापना कार्य
कमीशनिंग कार्य
प्रारंभिक परीक्षण करना
ट्रायल ऑपरेशन का संचालन
स्वीकृति परीक्षण करना
एसी समर्थन
वारंटी दायित्वों के अनुसार कार्य करना
वारंटी के बाद की सेवा