Visual Paradigm Desktop | 
Visual Paradigm Online
जटिल प्रणाली इंजीनियरिंग के क्षेत्र में, आवश्यकताओं का प्रबंधन अक्सर सबसे महत्वपूर्ण चुनौती होती है। प्रणालियाँ जटिलता में बढ़ती हैं, इंटरफेस बढ़ते हैं, और स्टेकहोल्डर की आवश्यकताएँ बदलती हैं। एक संरचित दृष्टिकोण के बिना, सूचना के अलगाव होते हैं, और उच्च स्तर की स्टेकहोल्डर आवश्यकता और निम्न स्तर के घटक विवरण के बीच का संबंध टूट जाता है। यहाँ मॉडल-आधारित प्रणाली इंजीनियरिंग (एमबीएसई) और प्रणाली मॉडलिंग भाषा (सिसएमएल) एक मजबूत आधार प्रदान करते हैं। विशेष रूप से, आवश्यकता फ्लो विश्लेषण प्रणाली जीवनचक्र के दौरान अखंडता बनाए रखने के लिए मुख्य आधार के रूप में कार्य करता है।
यह मार्गदर्शिका सिसएमएल निर्माण के उपयोग से एंड-टू-एंड ट्रेसेबिलिटी स्थापित और बनाए रखने के तरीकों का अध्ययन करती है। हम आवश्यकता संबंधों के तकनीकी पहलुओं, सत्यापन गतिविधियों के एकीकरण और प्रतिबंध बिना परिवर्तन प्रबंधन के रणनीतियों का अध्ययन करेंगे। लक्ष्य एक जीवंत मॉडल बनाना है जो प्रणाली की वास्तविकता को दर्शाता है, यह सुनिश्चित करते हुए कि प्रत्येक आवश्यकता तर्कसंगत, डिज़ाइन की गई और सत्यापित की गई हो।
आवश्यकता फ्लो विश्लेषण केवल डेटाबेस में आइटम की सूची बनाने के बारे में नहीं है। यह उपयोगकर्ता संदर्भ से शुरू होकर भौतिक वास्तविकता तक आवश्यकताओं के तार्किक प्रगमन को मानचित्रित करने की प्रक्रिया है। एक पारंपरिक दस्तावेज़-आधारित दृष्टिकोण में, ट्रेसेबिलिटी अक्सर एक रेखीय स्प्रेडशीट अभ्यास होता है। मॉडलिंग वातावरण में, यह संबंधों का एक नेटवर्क बन जाता है।
जब आप फ्लो विश्लेषण करते हैं, तो आप मूल रूप से सूचना के मार्ग का लेखा-जोखा कर रहे होते हैं। आप पूछते हैं: क्या यह आवश्यकता मॉडल में मौजूद है? क्या इसे एक ब्लॉक से जोड़ा गया है? क्या इसे एक परीक्षण से जोड़ा गया है? यदि कोई लिंक अनुपस्थित है, तो फ्लो टूट जाता है। टूटा हुआ फ्लो अस्पष्टता, पुनर्कार्य और संभावित सुरक्षा समस्याओं की ओर जाता है।
ट्रेसेबिलिटी को अक्सर सुसंगतता के चेकबॉक्स के रूप में देखा जाता है। हालांकि, इसका मूल्य जोखिम कम करने और निर्णय समर्थन में निहित है। जब आवश्यकताओं को पूरी तरह से ट्रेस किया जाता है, तो किसी भी परिवर्तन का प्रभाव तुरंत दिखाई देता है। यदि कोई स्टेकहोल्डर किसी प्रदर्शन मापदंड में परिवर्तन की मांग करता है, तो आप तुरंत देख सकते हैं कि कौन से उपप्रणाली, इंटरफेस और परीक्षण मामले प्रभावित होंगे।
कठोर ट्रेसेबिलिटी के लाभ शामिल हैं:
सिसएमएल आवश्यकताओं को संभालने के लिए डिज़ाइन किए गए विशिष्ट आरेख प्रकार और संबंध प्रकार प्रदान करता है। सही मॉडलिंग के लिए इन तत्वों को समझना आवश्यक है।
आवश्यकता ब्लॉक ट्रेसेबिलिटी की परमाणु इकाई है। इसे अद्वितीय रूप से पहचाना जाना चाहिए, आमतौर पर एक पदानुक्रमिक आईडी (उदाहरण के लिए, SYS-REQ-001) का उपयोग करके। प्रत्येक आवश्यकता में विशिष्ट गुण होने चाहिए:
यह आरेख केवल आवश्यकताओं और उनके संबंधों के लिए समर्पित है। इससे आप आवश्यकताओं को तार्किक रूप से समूहित कर सकते हैं और उनके बीच प्रवाह को परिभाषित कर सकते हैं। आपको इस आरेख को ब्लॉक या उपयोग केस से भरने की आवश्यकता नहीं है, जब तक कि संदर्भ के लिए आवश्यक न हो।
SysML की शक्ति इसके संबंधों में है। ये ट्रेस की दिशा और प्रकृति को परिभाषित करते हैं:
प्रवाह विश्लेषण मॉडल का निर्माण एक अनुशासित दृष्टिकोण की आवश्यकता होती है। आप बस आवश्यकताओं को एक आरेख में डालकर ट्रेसेबिलिटी काम करने की उम्मीद नहीं कर सकते। मॉडल को परतों में निर्मित किया जाना चाहिए।
सिस्टम संदर्भ से शुरुआत करें। उपयोगकर्ता के मिशन का प्रतिनिधित्व करने वाली उच्चतम स्तर की आवश्यकताओं को परिभाषित करें। ये अक्सर गुणात्मक या उच्च स्तर के मात्रात्मक बयान होते हैं। इन्हें सिस्टम से बाहरी एजेंसियों से जोड़ें जो सिस्टम से बातचीत करती हैं।
उच्चतम स्तर की आवश्यकताओं को कार्यात्मक आवश्यकताओं में बांटें। ” का उपयोग करेंसुधारें संबंध को एक वृक्ष संरचना बनाने के लिए बनाएं। इससे सुनिश्चित होता है कि भागों का योग पूर्णता के बराबर होता है।
यह वह स्थान है जहां मॉडल अमूर्त आवश्यकताओं से वास्तविक संरचना में संक्रमण करता है। आप ब्लॉक परिभाषा आरेख (BDD) और आंतरिक ब्लॉक आरेख (IBD) का उपयोग करके प्रणाली संरचना का प्रतिनिधित्व करेंगे।
एक सामान्य गलती यह है कि आवश्यकताओं और डिज़ाइन को अलग-अलग धाराओं के रूप में माना जाए। उन्हें एक साथ आना चाहिए। प्रवाह विश्लेषण सुनिश्चित करता है कि डिज़ाइन केवल कार्यात्मक नहीं, बल्कि अनुपालन भी है।
| निशान दिशा | संबंध प्रकार | उद्देश्य | उदाहरण |
|---|---|---|---|
| आवश्यकता से आवश्यकता | सुधारें / व्युत्पन्न करें | पदानुक्रम स्थापित करें | प्रणाली आवश्यकता उपप्रणाली आवश्यकता द्वारा सुधारी गई |
| आवश्यकता से ब्लॉक | पूरा करें | डिज़ाइन अनुपालन | पावर सप्लाई ब्लॉक पावर आवश्यकता को पूरा करता है |
| आवश्यकता से संचालन | आवंटित करें | कार्यात्मक आवंटन | संचालन ‘इंजन शुरू करें’ नियंत्रण आवश्यकता को पूरा करता है |
| परीक्षण के लिए आवश्यकता | सत्यापित करें | सत्यापन | परीक्षण केस ‘वोल्टेज चेक’ पावर आवश्यकता की पुष्टि करता है |
तत्वों के नक्शे बनाते समय, एक स्थिर नामकरण पद्धति का उपयोग करें। ट्रेस में एक आवश्यकता पहचानकर्ता दिखाई देना चाहिए। उदाहरण के लिए, यदि एक ब्लॉक का नाम हैपावर सप्लाई_01, तो वह संतुष्ट करने वाली आवश्यकता हो सकती हैREQ_PWR_001। इस स्थिरता के कारण स्वचालित रिपोर्टिंग में सहायता मिलती है।
सत्यापन के बिना ट्रेसेबिलिटी अधूरी है। एक आवश्यकता जिसका डिज़ाइन किया गया है लेकिन कभी परीक्षण नहीं किया गया है, एक जोखिम है। SysML आपको सत्यापन गतिविधियों को सीधे आवश्यकताओं से जोड़ने की अनुमति देता है।
सत्यापन गतिविधियों को निम्न रूप में दर्शाया जा सकता है:
का उपयोग करनासत्यापित करें यहाँ महत्वपूर्ण है। यह एक बंद लूप बनाता है। जब कोई परीक्षण विफल होता है, तो ट्रेस उस विशिष्ट आवश्यकता को उजागर करता है जो पूरी नहीं हुई है। इससे त्वरित मूल कारण विश्लेषण संभव होता है। यदि परीक्षण किसी घटक त्रुटि के कारण विफल होता है, तो ट्रेस आपको बताता है कि घटक को किस आवश्यकता को पूरा करना था।
वास्तविक दुनिया के प्रणालियाँ अक्सर रेखीय संबंधों के साथ नहीं होती हैं। आवश्यकताएँ आमतौर पर एक दूसरे पर निर्भर होती हैं। कुछ आवश्यकताएँ कॉन्फ़िगरेशन विकल्पों के आधार पर शर्ती हो सकती हैं। इन निर्भरताओं के प्रबंधन के लिए सावधानीपूर्वक मॉडलिंग की आवश्यकता होती है।
सभी प्रणालियाँ सभी मोड में काम नहीं करती हैं। का उपयोग करेंव्युत्पत्ति यासुधारें संबंधों का उपयोग शर्ताधीन तर्क को दिखाने के लिए करें। आपके पास एक आवश्यकता हो सकती है जो केवल तभी सक्रिय होती है जब एक विशिष्ट मोड का चयन किया जाता है। इस शर्त को आवश्यकता गुण में दस्तावेज़ीकृत करें या संबंध पर एक गार्ड शर्त के माध्यम से।
आवश्यकताएं अक्सर बहुत से उपप्रणालियों को छूती हैं। एक लेटेंसी आवश्यकता में सॉफ्टवेयर और हार्डवेयर दोनों शामिल हो सकते हैं। इन ब्लॉक्स के बीच डेटा प्रवाह को दृश्यमान बनाने के लिए आंतरिक ब्लॉक आरेखों का उपयोग करें। सुनिश्चित करें कि इंटरफेस परिभाषा आवश्यकता सीमाओं के अनुरूप हो।
SysML बहु-दृष्टिकोण वाला है। एक आवश्यकता को आवश्यकता आरेख में वर्णित किया जा सकता है, BDD में आवंटित किया जा सकता है, और परीक्षण केस आरेख में परीक्षण किया जा सकता है। इन दृष्टिकोणों को समायोजित रखना एक प्रमुख चुनौती है। यह सुनिश्चित करने के लिए कि एक आरेख में परिवर्तन दूसरे आरेख में ट्रेस को नष्ट न करे, मॉडल का नियमित रूप से ऑडिट करना आवश्यक है।
उच्च गुणवत्ता वाली ट्रेसेबिलिटी प्राप्त करना कठिन है। टीमें अक्सर ऐसी जाल में फंस जाती हैं जिससे समय के साथ मॉडल का मूल्य कम हो जाता है।
सभी चीजों को एक दूसरे से जोड़ने से एक ‘स्पैगेटी मॉडल’ बनता है जिसे नेविगेट करना मुश्किल होता है। केवल आवश्यक चीजों को ही जोड़ें। यदि एक आवश्यकता एक सामान्य प्रणाली व्यवहार द्वारा संतुष्ट होती है, तो उसे हर विशिष्ट ब्लॉक से जोड़ें नहीं, जब तक कि वह ब्लॉक आवश्यक न हो।
यदि एक स्तर का विवरण बहुत विस्तृत है और अगला स्तर धुंधला है, तो ट्रेस अर्थहीन हो जाता है। सुनिश्चित करें कि विभाजन वृक्ष में विवरण का स्तर संगत हो।
मॉडल को अपडेट करना अक्सर वर्ड दस्तावेज़ को अपडेट करने से कठिन होता है। टीमें आमतौर पर मॉडल को बनाए जाने के बाद उसे अपडेट करना बंद कर देती हैं। मॉडल को एकमात्र सत्य स्रोत के रूप में लें। यदि कोई परिवर्तन होता है, तो मॉडल को पहले अपडेट करना होगा।
एक कठोर नामाकरण मानक स्थापित करें। प्रकार को दर्शाने के लिए प्रीफिक्स का उपयोग करें (जैसे REQ, BLK, INT)। यह मॉडल विश्लेषण उपकरणों के उपयोग में खोज और फ़िल्टर करना आसान बनाता है।
ट्रेसेबिलिटी ग्राफ की आवधिक समीक्षा की योजना बनाएं। जांचें:
ट्रेसेबिलिटी रिपोर्ट बनाने के लिए स्क्रिप्टिंग या निर्मित विश्लेषण विशेषताओं का उपयोग करें। मैन्युअल जांच मनुष्य द्वारा त्रुटि के अधिक झंझट में होती है। स्वचालित रिपोर्ट्स कवरेज और अंतराल के एक वस्तुनिष्ठ दृश्य प्रदान करती हैं।
परिवर्तन अविश्वसनीय है। एक आवश्यकता नए नियमों, तकनीकी परिवर्तन या उपयोगकर्ता प्रतिक्रिया के कारण बदल सकती है। SysML मॉडल की ताकत इन परिवर्तनों के तरंग प्रभाव को दिखाने की क्षमता में है।
जब एक आवश्यकता में संशोधन किया जाता है:
इस प्रक्रिया से बदलाव प्रबंधन अनुमान लगाने के खेल से डेटा-आधारित निर्णय में बदल जाता है। आपको बिल्कुल पता होता है कि किससे संपर्क करना है और क्या परीक्षण करना है।
आप कैसे जानेंगे कि आपकी ट्रेसेबिलिटी काम कर रही है? आपको मापदंडों की आवश्यकता है। मात्रात्मक मापदंड क्षेत्रों के जोखिम को पहचानने में मदद करते हैं।
महत्वपूर्ण आवश्यकताओं पर 100% कवरेज का लक्ष्य रखें। कम प्राथमिकता वाली वस्तुओं के लिए कम सीमा स्वीकार्य हो सकती है, लेकिन इसे दस्तावेज़ित किया जाना चाहिए। समय के साथ इन मापदंडों का निरंतर ट्रैकिंग प्रवृत्तियों को उजागर करता है। यदि कवरेज गिरती है, तो इंजीनियरिंग प्रक्रिया में विफलता का संकेत है।
SysML एक खाली स्थान में नहीं मौजूद है। इसे सॉफ्टवेयर विकास, निर्माण और रखरखाव जैसे अन्य जीवन चक्र चरणों के साथ एकीकृत करना चाहिए। ट्रेसेबिलिटी मॉडल को इन क्षेत्रों के बीच सेतु के रूप में कार्य करना चाहिए।
इस एकीकरण से यह सुनिश्चित होता है कि प्रणाली डिलीवरी के बिंदु पर समाप्त नहीं होती है। ट्रेसेबिलिटी श्रृंखला उत्पाद के पूरे संचालन जीवनकाल तक फैली रहती है।
SysML आवश्यकता प्रवाह विश्लेषण को लागू करना समय और प्रयास का महत्वपूर्ण निवेश है। इसके लिए अनुशासन, प्रशिक्षण और मॉडल अखंडता के प्रति प्रतिबद्धता की आवश्यकता होती है। हालांकि, निवेश का लाभ एक ऐसी प्रणाली है जो समझने में आसान है, बदलने में आसान है और प्रमाणीकरण में आसान है।
केवल सामग्री के बजाय संबंधों पर ध्यान केंद्रित करके, आप प्रणाली इंजीनियरिंग के लिए एक टिकाऊ ढांचा बनाते हैं। प्रवाह विश्लेषण सुनिश्चित करता है कि प्रणाली की तर्क यही रहता है, भले ही विवरण बदलते रहें। महत्वपूर्ण मार्गों से शुरुआत करें, ऊपरी स्तर की आवश्यकताओं को मजबूत बनाएं और ट्रेसेबिलिटी को बाहर की ओर फैलाएं। लिंक की गुणवत्ता को कमजोर करने वाले छोटे रास्तों से बचें। टूटे लिंक वाले पूर्ण मॉडल की तुलना में एक साफ मॉडल अधिक मूल्यवान है।
याद रखें कि लक्ष्य केवल एक आरेख बनाना नहीं है। लक्ष्य प्रोजेक्ट लाइफसाइकल के दौरान निर्णय लेने में सहायता करने वाले विश्वसनीय ज्ञान आधार को बनाना है। कठोर प्रवाह विश्लेषण के साथ, आप सुनिश्चित करते हैं कि प्रणाली के हर भाग का एक उद्देश्य है, और हर उद्देश्य की पुष्टि की जाती है।