सिस्टम आर्किटेक्ट

Systems architect

Systems architects divide large and complex systems into manageable subsystems that can be handled by individual engineers.
Occupation
Names	Systems architect
Occupation type	Profession
Activity sectors	Systems engineering Systems Design Engineering
Description
Competencies	user domain knowledge, scientific knowledge, engineering, planning and management skills
Education required	See education

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

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

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

सिंहावलोकन

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

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

सिस्टम डिज़ाइन में, आर्किटेक्ट (और इंजीनियर) इसके लिए ज़िम्मेदार हैं:

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

सिस्टम आर्किटेक्ट: विषय

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

उपयोगकर्ता और प्रायोजक

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

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

उच्च स्तरीय आवश्यकताएँ

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

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

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

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

लागत/लाभ विश्लेषण

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

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

विभाजन और परत बनाना

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

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

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

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

प्रत्येक परत पर वास्तुकला को पर्याप्त रूप से सरल बनाए रखने के लिए वास्तुकला को स्तरित करना महत्वपूर्ण है ताकि यह एक ही दिमाग के लिए समझ में आ सके। जैसे-जैसे परतें चढ़ती जाती हैं, निचली परतों पर संपूर्ण सिस्टम ऊपरी परतों पर सरल घटक बन जाते हैं, और उच्चतम परतों पर पूरी तरह से गायब हो सकते हैं।

स्वीकृति परीक्षण

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

उपयोगकर्ताओं और इंजीनियरों के साथ संचार

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

वास्तुकार रूपक

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

यह भी देखें

• उद्यम स्थापत्य
• एंटरप्राइज़ आर्किटेक्ट
• हार्डवेयर वास्तुकला
• आवश्यकताओं के विश्लेषण
• सॉफ़्टवेयर वास्तुशिल्प
• सॉफ्टवेयर इंजीनियरिंग
• सिस्टम आर्किटेक्चर
• सिस्टम मॉडलिंग
• प्रणाली अभियांत्रिकी
• सिस्टम डिज़ाइन
• व्यापार विश्लेषक
• सेवा-उन्मुख मॉडलिंग ढांचा (एसओएमएफ)

अग्रिम पठन

• Donald Firesmith et al.: The Method Framework for Engineering System Architectures, (2008)
• Mark W. Maier and Rechtin, Eberhardt, The Art of Systems Architecting, Third Edition (2009)
• Gerrit Muller, "Systems architecting: A business perspective," CRC Press, (2012).
• Eberhardt Rechtin, Systems Architecting: Creating & Building Complex Systems, 1991.
• J. H. Saltzer, M. F. Kaashoek, Principles of Computer System Design: An Introduction, Morgan Kaufmann, 2009.
• Rob Williams, Computer Systems Architecture: a Networking Approach, Second Edition (December 2006).

बाहरी संबंध

• Principles of Computer System Design: An Introduction – MIT OpenCourseWare
• Systems Architecture: Canaxia Brings an Architect on Board, Article