घटकों पर इंटरफेस

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

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

उदाहरण: एक संचार प्रणाली जो 25°C पर ठीक 100 Mbps ट्रैफिक के लिए डिज़ाइन की गई है, 110 Mbps तक ट्रैफिक स्पाइक करने या तापमान 40°C तक बढ़ने पर विफल हो जाएगी। एक सिस्टम सीमा 'किसी भी तापमान में 90% उपयोग को 60°C से नीचे नहीं होना चाहिए' के साथ अधिक उपयोगी है, भले ही इसका शिखर प्रदर्शन थोड़ा कम हो।

सिस्टम्स इंजीनियर की नौकरी: न तो A और न ही B को व्यक्तिगत रूप से अनुकूलित करना, बल्कि A+B+C... को एक पूरे के रूप में अनुकूलित करना, बाधाओं के अधीन।

शिक्षा प्रणाली: विफल सिस्टम्स इंजीनियरिंग

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

लेकिन एक सिस्टम के रूप में देखा जाए, बड़े अंतराल दिखाई दिए:

- गणितीय प्रेरण: हाई स्कूल के बाद शायद ही कभी उल्लेख किया जाता है।

- जटिल संख्याएं: बीजगणित में संक्षिप्त रूप से पेश की जाती हैं, फिर लीनियर अलजेब्रा में देर तक टाली जाती हैं जब जटिल eigenvalues दिखाई देते हैं। छात्र दो नई, कठिन विचारों का सामना करते हैं एक साथ बिना पूर्व तैयारी के।

- अनिर्धारित गुणांक: संक्षेप में उल्लेख किया गया।

- असंभवता प्रमाण: लगभग पूरी तरह से अनुपस्थित।

- असतत गणित: बड़े पैमाने पर अनदेखा किया गया।

प्रत्येक घटक (प्रत्येक पाठ्यक्रम) का अनुकूलन इंटरफेस अंतराल बनाता है: पाठ्यक्रमों के बीच अनुपस्थित वैचारिक पुल। सिस्टम का आउटपुट — शिक्षित इंजीनियर और वैज्ञानिक — पीड़ित थे, भले ही प्रत्येक पाठ्यक्रम का आउटपुट मेट्रिक्स में सुधार हुआ था।

टूटे हुए हिस्से को ठीक करने की प्राकृतिक इच्छा का प्रतिरोध करना

हैमिंग की टिप्पणी: सिस्टम्स इंजीनियरिंग के बारे में सही शब्द कहना आसान है। बहुत कम लोग वास्तव में ऐसा कर सकते हैं जब पल आता है।

सिस्टम विफलता के समय प्राकृतिक प्रतिक्रिया: सबसे स्पष्ट रूप से टूटे घटक की पहचान करें और इसे ठीक करें। यह घटक सोच है। सिस्टम विफलता का कारण घटकों, इंटरफेस, और बाधाओं की बातचीत में शामिल होता है — लेकिन सबसे दृश्यमान विफलता आमतौर पर एकल घटक पर होती है।

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

बड़े संगठनों में संचार बाधा इस पैटर्न का पालन करती है: एक विभाग खराब संचार करता है (दृश्यमान विफलता)। घटक समाधान: बेहतर संचारक काम पर रखें। सिस्टम्स समाधान: सूचना प्रवाह आर्किटेक्चर को पुनर्डिज़ाइन करें ताकि समन्वय प्राप्त करने के लिए कम संचार की आवश्यकता हो।

सिस्टम्स निदान

भेद: एक घटक समाधान एक लक्षण को ठीक करता है। एक सिस्टम्स समाधान कारण को ठीक करता है। कारण आमतौर पर सिस्टम की संरचना में शामिल होता है — कौन से घटक मौजूद हैं, कौन सी इंटरफेस उन्हें जोड़ते हैं, कौन सी बाधाएं उनके ऑपरेशन को सीमित करती हैं।