3.9 सिस्टम्स इंजीनियरिंग

अवलोकन और प्रेरणा

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

यह सॉफ़्टवेयर आर्किटेक्चर से अलग है। सॉफ़्टवेयर आर्किटेक्चर (अध्याय 3.1) यह तय करता है कि सॉफ़्टवेयर घटक कैसे संरचित हैं और वे एक-दूसरे से कैसे बात करते हैं। सिस्टम्स इंजीनियरिंग एक स्तर ऊपर बैठती है। यह पूछती है कि पूरे सिस्टम को क्या करना चाहिए, सॉफ़्टवेयर, हार्डवेयर, और मानव ऑपरेटर काम को कैसे बाँटते हैं, और आप यह कैसे साबित करेंगे कि बना हुआ अंतिम उत्पाद काम करता है। इसका पेशेवर घर INCOSE है, इंटरनेशनल काउंसिल ऑन सिस्टम्स इंजीनियरिंग, और इसका आधार मानक ISO/IEC/IEEE 15288 है, जो किसी सिस्टम के जीवन की प्रक्रियाओं को परिभाषित करता है।

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

यह अध्याय सॉफ़्टवेयर आवश्यकताओं (अध्याय 2.8), आर्किटेक्चर फ़ंडामेंटल्स (अध्याय 3.1), सॉफ़्टवेयर मॉडल और मेथड (अध्याय 2.12), इंटरऑपरेबिलिटी और ओपन स्टैंडर्ड (अध्याय 3.8), और प्रोजेक्ट मैनेजमेंट (अध्याय 10.6) से जुड़ता है।

मुख्य सिद्धांत

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

सिफारिशें

पूरे सिस्टम जीवनचक्र को प्रबंधित करें

सिस्टम को एक पूरे जीवन वाला मानें, और हर चरण की योजना बनाएँ। एक आम जीवनचक्र इस तरह चलता है: अवधारणा (concept) (ज़रूरत को समझें और विकल्पों को खोजें), आवश्यकताएँ (ठीक-ठीक बताएँ कि सिस्टम को क्या करना चाहिए), डिज़ाइन (आर्किटेक्चर और पुर्ज़े तय करें), एकीकरण (integration) (पुर्ज़ों को साथ लाएँ), वेरिफ़िकेशन और वैलिडेशन (साबित करें कि यह काम करता है और यह सही सिस्टम है), संचालन (operation) (इसे चलाएँ और अनुरक्षित करें), और रिटायरमेंट (इसे सुरक्षित रूप से डीकमिशन करें, जिसमें डेटा और निपटान (disposal) शामिल है)। ISO/IEC/IEEE 15288 इसके लिए एक प्रक्रिया ढाँचा देता है। इन चरणों का एक कठोर वॉटरफ़ॉल होना ज़रूरी नहीं है; आप इटरेट कर सकते हैं, प्रोटोटाइप बना सकते हैं, और वृद्धियों (increments) में डिलीवर कर सकते हैं। बात यह है कि आप हर चरण को सचेत रूप से संबोधित करें, जिसमें वे महँगे बाद के चरण भी शामिल हैं जिन्हें शुरुआती योजनाएँ अक्सर नज़रअंदाज़ कर देती हैं।

हितधारकों की ज़रूरतों को समझें और ट्रेसेबिलिटी के साथ आवश्यकताएँ आबंटित करें

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

इंटरफ़ेस को स्पष्ट रूप से प्रबंधित करें

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

एकीकृत करें और फिर वेरिफ़ाई व वैलिडेट करें

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

मॉडल-आधारित सिस्टम्स इंजीनियरिंग अपनाएँ

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

उभरते व्यवहार पर सिस्टम्स थिंकिंग लागू करें

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

हार्डवेयर और सॉफ़्टवेयर को साथ-साथ इंजीनियर करें

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

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

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

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

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

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

क्षेत्रीय दृष्टिकोण

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

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

एंटरप्राइज़। बड़े पैमाने पर समस्या कई टीमों और आपूर्तिकर्ताओं में एकरूपता की है: ISO/IEC/IEEE 15288 के अनुरूप एक साझा जीवनचक्र प्रक्रिया, हर आपूर्तिकर्ता सीमा के लिए एक इंटरफ़ेस कंट्रोल डॉक्यूमेंट और एक नामित स्वामी, और एंड-टू-एंड ट्रेसेबिलिटी ताकि एक घटक का बदलाव पूरे कार्यक्रम को हड़बड़ी में न डाल दे। MBSE में निवेश करें जहाँ एक साझा मॉडल ठेकेदारों में आवश्यकताओं, इंटरफ़ेस, और टेस्ट को संरेखित रखता है। प्रक्रिया को इस तरह गवर्न करें कि वेरिफ़िकेशन और वैलिडेशन अलग-अलग बने रहें और हर आवश्यकता एक ज़िम्मेदार हिस्से को आबंटित हो।

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

निवेश पर प्रतिफल (ROI, खर्च किए गए मुक़ाबले प्राप्त मूल्य) के लिए, फ़ायदा है टला हुआ पुनर्कार्य (rework), कम इंटीग्रेशन विफलताएँ, और ऐसे कार्यक्रम जो ओवररन करने के बजाय शेड्यूल और बजट को पूरा करते हैं। बड़े कार्यक्रमों के उद्योग अध्ययन बार-बार पाते हैं कि मज़बूत सिस्टम्स इंजीनियरिंग प्रयास छोटे ओवररन से सह-संबंधित (correlate) होता है। कुल स्वामित्व लागत (TCO, किसी सिस्टम को बनाने, चलाने, और रिटायर करने की पूरी आजीवन लागत) के लिए, सिस्टम्स इंजीनियरिंग उन संचालन और रिटायरमेंट चरणों का हिसाब रखती है जो दीर्घकालिक लागत पर हावी रहते हैं लेकिन जिन्हें तदर्थ (ad hoc) परियोजनाएँ नज़रअंदाज़ कर देती हैं। शुरू से ही अनुरक्षणीयता, इंटरफ़ेस, और निपटान के लिए डिज़ाइन करना उन दशकों की लागत घटाता है जो सिस्टम सेवा में बिताता है। प्रोजेक्ट मैनेजमेंट (अध्याय 10.6) देखें।

एंटी-पैटर्न और नुकसान

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

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

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

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

लेवल 3: मानकीकरण। सिस्टम्स इंजीनियरिंग एक दस्तावेज़ीकृत, संगठन-व्यापी अनुशासन है जो ISO/IEC/IEEE 15288 के अनुरूप है और टीमों में लागू है। पूरे जीवनचक्र की योजना बनाई जाती है, ट्रेसेबिलिटी को एंड-टू-एंड बनाए रखा जाता है, इंटरफ़ेस औपचारिक रूप से नियंत्रित हैं, और वेरिफ़िकेशन व वैलिडेशन अलग-अलग और योजनाबद्ध हैं। जटिल कार्यक्रमों पर MBSE का उपयोग किया जाता है।

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

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
• ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
• ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
• Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modeling Language
• NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
• Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
• Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
• Donella H. Meadows, Thinking in Systems: A Primer
• Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
• U.S. Department of Defense, Defense Acquisition Guidebook (systems engineering guidance)