arc42 के फैसला रिकॉर्ड टेम्पलेट

https://arc42.org/overview

1. परिचय आ लक्ष्य

जरूरत सभ के छोट वर्णन, प्रेरक ताकत, जरूरत के सार (चाहे संक्षेप)। आर्किटेक्चर खातिर ऊपर के तीन (अधिकतम पाँच) गुणवत्ता लक्ष्य जे मुख्य हितधारक लोग खातिर सबसे ऊँच प्राथमिकता रखेला। आर्किटेक्चर के बारे में उनकर अपेक्षा संगे जरूरी हितधारक लोग के एगो तालिका।

1.1 जरूरत के अवलोकन

सामग्री

कार्यात्मक जरूरत, प्रेरक ताकत, जरूरत के सार (चाहे संक्षेप) के छोट वर्णन। (उम्मीद बा कि मौजूद) जरूरत के दस्तावेज के लिंक, ई जानकारी संगे कि ऊ कहाँ मिली।

प्रेरणा

अंतिम उपयोगकर्ता के नजरिया से, कारोबारी गतिविधि के सहायता बढ़ावे आ/चाहे गुणवत्ता सुधारे खातिर कवनो सिस्टम बनावल चाहे बदलल जाला।

रूप

छोट पाठ वर्णन, शायद तालिका वाला उपयोग-मामला रूप में। अगर जरूरत के दस्तावेज मौजूद बा त ई अवलोकन ओह दस्तावेज के हवाला देवे के चाहीं।

ई अंश जेतना हो सके छोट राखीं। एह दस्तावेज के पढ़े-लायक होखे आ जरूरत के दस्तावेज के हिसाब से संभावित दोहराव के बीच संतुलन बनावीं।

1.2 गुणवत्ता लक्ष्य

सामग्री

आर्किटेक्चर खातिर ऊपर के तीन (अधिकतम पाँच) गुणवत्ता लक्ष्य जेकर पूर्ति मुख्य हितधारक लोग खातिर सबसे जरूरी बा। हमनी के मतलब सच में आर्किटेक्चर खातिर गुणवत्ता लक्ष्य से बा। एकरा के परियोजना के लक्ष्य से मत मिलाईं। ई जरूरी नइखे कि एक जइसन होखे। ISO 25010 मानक संभावित दिलचस्प विषय के नीमन अवलोकन देला।

प्रेरणा

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

रूप

सबसे जरूरी गुणवत्ता लक्ष्य आ ठोस परिदृश्य वाला एगो तालिका, प्राथमिकता के क्रम में।

1.3 हितधारक

सामग्री

सिस्टम के हितधारक लोग के साफ अवलोकन, यानी सब आदमी, भूमिका, चाहे संगठन जे

• आर्किटेक्चर जानल चाहीं

• आर्किटेक्चर के बारे में कायल कइल जाए के चाहीं

• आर्किटेक्चर चाहे कोड संगे काम करे के पड़ेला

• अपना काम खातिर आर्किटेक्चर के दस्तावेज चाहीं

• सिस्टम चाहे ओकर विकास के बारे में फैसला लिहे के पड़ेला

प्रेरणा

रउआ सिस्टम के विकास में शामिल चाहे सिस्टम से प्रभावित सब पक्ष के जानल चाहीं। ना त, रउआ के विकास प्रक्रिया में बाद में अप्रिय आश्चर्य मिल सकेला। ई हितधारक रउआ के काम आ ओकर नतीजा के दायरा आ ब्योरा के स्तर तय करेले।

रूप

भूमिका के नाम, आदमी के नाम, आ आर्किटेक्चर आ ओकर दस्तावेज के संबंध में उनकर अपेक्षा वाला तालिका।

2. बंदिश

कुछ भी जे डिजाइन आ कार्यान्वयन फैसला चाहे संबंधित प्रक्रिया के बारे में फैसला में टीम के बाँधेला। कबो-कबो अलग-अलग सिस्टम से आगे जा सकेला आ पूरा संगठन आ कंपनी खातिर वैध होखेला।

सामग्री

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

प्रेरणा

आर्किटेक्ट के ठीक-ठीक जानल चाहीं कि ऊ अपना डिजाइन फैसला में कहाँ आजाद बा आ कहाँ बंदिश के पालन करे के पड़ी। बंदिश सभ के हमेशा निपटावे के पड़ेला; हालांकि, ऊ बातचीत लायक हो सकेला।

रूप

स्पष्टीकरण संगे बंदिश के सादा तालिका। जरूरत पड़े त रउआ ओकरा के तकनीकी बंदिश, संगठनात्मक आ राजनीतिक बंदिश, आ परंपरा (जइसे प्रोग्रामिंग चाहे संस्करण दिशानिर्देश, दस्तावेज चाहे नामकरण परंपरा) में बाँट सकीले

3. संदर्भ आ दायरा

रउआ सिस्टम के ओकर (बाहरी) संवाद साथी (पड़ोसी सिस्टम आ उपयोगकर्ता) से अलग करेला। बाहरी इंटरफेस तय करेला। कारोबारी/क्षेत्र नजरिया से (हमेशा) चाहे तकनीकी नजरिया से (वैकल्पिक) देखावल जाला

सामग्री

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

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

प्रेरणा

संवाद साथी सभ के साथे क्षेत्र इंटरफेस आ तकनीकी इंटरफेस रउआ सिस्टम के सबसे नाजुक पहलू में से हवे। पक्का करीं कि रउआ ओकरा के पूरा तरी से समझत बानी।

रूप

• अलग-अलग संदर्भ आरेख

• संवाद साथी आ उनकर इंटरफेस के सूची।

3.1 कारोबारी संदर्भ

सामग्री

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

प्रेरणा

सब हितधारक लोग के समझल चाहीं कि सिस्टम के माहौल संगे कवन डेटा के आदान-प्रदान होला।

रूप

सब तरह के आरेख जे सिस्टम के काला डिब्बा के रूप में देखावेला आ संवाद साथी सभ के साथे क्षेत्र इंटरफेस तय करेला।

चाहे (चाहे अतिरिक्त रूप से) रउआ तालिका इस्तेमाल कर सकीले। तालिका के शीर्षक रउआ सिस्टम के नाम होला, तीन स्तंभ में संवाद साथी के नाम, इनपुट, आ आउटपुट होला।

3.2 तकनीकी संदर्भ

सामग्री

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

प्रेरणा

बहुत हितधारक सिस्टम आ ओकर संदर्भ के बीच तकनीकी इंटरफेस के आधार पर आर्किटेक्चर फैसला लेवेले। खास कर इन्फ्रास्ट्रक्चर चाहे हार्डवेयर डिजाइनर लोग ई तकनीकी इंटरफेस तय करेला।

रूप

जइसे UML डिप्लॉयमेंट आरेख जे पड़ोसी सिस्टम तक के चैनल के बतावेला, संगे एगो मैपिंग तालिका जे चैनल आ इनपुट/आउटपुट के बीच के रिश्ता देखावेला।

4. समाधान रणनीति

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

सामग्री

बुनियादी फैसला आ समाधान रणनीति के छोट सारांश आ स्पष्टीकरण, जे सिस्टम के आर्किटेक्चर के आकार देला। एह में शामिल बा

• तकनीक के फैसला

• सिस्टम के ऊपरी स्तर के विघटन के बारे में फैसला, जइसे कवनो आर्किटेक्चर पैटर्न चाहे डिजाइन पैटर्न के इस्तेमाल

• मुख्य गुणवत्ता लक्ष्य कइसे पावल जाए एकरा पर फैसला

• प्रासंगिक संगठनात्मक फैसला, जइसे विकास प्रक्रिया चुनल चाहे कुछ काम तीसरा पक्ष के सौंपल।

प्रेरणा

ई फैसला रउआ आर्किटेक्चर के आधारशिला बनावेला। ई आउर कई विस्तृत फैसला चाहे कार्यान्वयन नियम के आधार ह।

रूप

एह मुख्य फैसला के स्पष्टीकरण छोट राखीं।

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

रउआ समाधान-दृष्टिकोण के सूची चाहे तालिका इस्तेमाल कर सकीले।

5. बिल्डिंग ब्लॉक दृश्य

सिस्टम के स्थिर विघटन, सोर्स-कोड के अमूर्तन, सफेद डिब्बा (जेमें काला डिब्बा शामिल) के पदानुक्रम के रूप में देखावल गइल, ब्योरा के उचित स्तर तक।

सामग्री

बिल्डिंग ब्लॉक दृश्य सिस्टम के बिल्डिंग ब्लॉक (मॉड्यूल, घटक, उपसिस्टम, क्लास, इंटरफेस, पैकेज, लाइब्रेरी, फ्रेमवर्क, परत, विभाजन, स्तर, फंक्शन, मैक्रो, ऑपरेशन, डेटा संरचना, …) में स्थिर विघटन आ उनकर निर्भरता (रिश्ता, संबंध, …) देखावेला

ई दृश्य हर आर्किटेक्चर दस्तावेज खातिर अनिवार्य बा। घर के जइसे ई फर्श के नक्शा ह।

प्रेरणा

अपना सोर्स कोड के अवलोकन बनवले राखीं, ओकर बनावट के अमूर्तन के जरिए समझे-लायक बना के।

एह से रउआ अपना हितधारक लोग संगे अमूर्त स्तर पर संवाद कर सकीले, कार्यान्वयन के ब्योरा खोलले बिना।

रूप

बिल्डिंग ब्लॉक दृश्य काला डिब्बा आ सफेद डिब्बा (नीचे के आकृति देखीं) के पदानुक्रमित संग्रह आ उनकर वर्णन ह।

5.1 पूरा सिस्टम के सफेद डिब्बा

इहाँ रउआ नीचे के सफेद डिब्बा टेम्पलेट इस्तेमाल करके पूरा सिस्टम के विघटन के वर्णन करीले। एमे शामिल बा

• एगो अवलोकन आरेख

• विघटन खातिर प्रेरणा

• शामिल बिल्डिंग ब्लॉक के काला डिब्बा वर्णन। एकरा खातिर हमनी विकल्प देत बानी:

  • सब शामिल बिल्डिंग ब्लॉक आ उनकर इंटरफेस के छोट आ व्यावहारिक अवलोकन खातिर एगो तालिका इस्तेमाल करीं

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

  • (वैकल्पिक:) जरूरी इंटरफेस, जे बिल्डिंग ब्लॉक के काला डिब्बा टेम्पलेट में समझावल नइखे, लेकिन सफेद डिब्बा के समझे खातिर बहुत जरूरी बा।

चूँकि इंटरफेस तय करे के बहुत तरीका बा एहसे हमनी ओकरा खातिर कवनो खास टेम्पलेट ना देनी।

सबसे नीमन हालत में रउआ उदाहरण चाहे सादा हस्ताक्षर से काम चला लेब।

5.2 स्तर 2

इहाँ रउआ स्तर 1 के (कुछ) बिल्डिंग ब्लॉक के भीतरी बनावट के सफेद डिब्बा के रूप में तय कर सकीले।

रउआ तय करे के पड़ी कि रउआ सिस्टम के कवन बिल्डिंग ब्लॉक एतना जरूरी बा कि अइसन विस्तृत वर्णन के सही ठहरा सके। कृपया पूर्णता के बजाय प्रासंगिकता के पसंद करीं। जरूरी, चौंकावे वाला, जोखिम वाला, जटिल चाहे अस्थिर बिल्डिंग ब्लॉक तय करीं। रउआ सिस्टम के सामान्य, सादा, उबाऊ चाहे मानकीकृत हिस्सा छोड़ दीं

5.2.1 बिल्डिंग ब्लॉक 1 खातिर सफेद डिब्बा

बिल्डिंग ब्लॉक 1 के आंतरिक बनावट तय करेला।

सफेद डिब्बा टेम्पलेट (ऊपर देखीं) इस्तेमाल करीं।

6. रनटाइम दृश्य

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

सामग्री

रनटाइम दृश्य सिस्टम के बिल्डिंग ब्लॉक के ठोस व्यवहार आ बातचीत के नीचे के क्षेत्र के परिदृश्य के रूप में बतावेला:

• जरूरी उपयोग मामला चाहे फीचर: बिल्डिंग ब्लॉक ओकरा के कइसे चलावेला?

• नाजुक बाहरी इंटरफेस पर बातचीत: बिल्डिंग ब्लॉक उपयोगकर्ता आ पड़ोसी सिस्टम संगे कइसे सहयोग करेला?

• संचालन आ प्रशासन: शुरू, चालू, बंद

• गलती आ अपवाद परिदृश्य

टिप्पणी: संभावित परिदृश्य (क्रम, कार्यप्रवाह) चुने के मुख्य कसौटी उनकर आर्किटेक्चर संबंधी प्रासंगिकता ह। बहुत सारा परिदृश्य के वर्णन करे के जरूरी नइखे। रउआ के बल्कि प्रतिनिधि चुनाव दर्ज करे के चाहीं।

प्रेरणा

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

रूप

परिदृश्य के वर्णन करे के कई तरीका बा, जइसे

• कदम के गिनल सूची (प्राकृतिक भाषा में)

• गतिविधि आरेख चाहे फ्लो चार्ट

• सीक्वेंस आरेख

• BPMN चाहे EPC (इवेंट प्रोसेस चेन)

• स्टेट मशीन

• वगैरह।

6.n रनटाइम परिदृश्य n (1, 2, 3, वगैरह)

रनटाइम आरेख चाहे परिदृश्य के पाठ वर्णन डालीं।

एह आरेख में देखावल बिल्डिंग ब्लॉक उदाहरण के बीच बातचीत के उल्लेखनीय पहलू के वर्णन डालीं।

7. डिप्लॉयमेंट दृश्य

माहौल, कंप्यूटर, प्रोसेसर, टोपोलॉजी संगे तकनीकी इन्फ्रास्ट्रक्चर। (सॉफ्टवेयर) बिल्डिंग ब्लॉक के इन्फ्रास्ट्रक्चर तत्व पर मैपिंग।

सामग्री

डिप्लॉयमेंट दृश्य बतावेला:

• रउआ सिस्टम चलावे खातिर इस्तेमाल होखे वाला तकनीकी इन्फ्रास्ट्रक्चर, जेमें भौगोलिक स्थान, माहौल, कंप्यूटर, प्रोसेसर, चैनल आ नेट टोपोलॉजी जइसन इन्फ्रास्ट्रक्चर तत्व आ आउर इन्फ्रास्ट्रक्चर तत्व शामिल बा आ

• (सॉफ्टवेयर) बिल्डिंग ब्लॉक के ओह इन्फ्रास्ट्रक्चर तत्व पर मैपिंग।

अक्सर सिस्टम अलग-अलग माहौल में चलेला, जइसे विकास माहौल, परीक्षण माहौल, प्रोडक्शन माहौल। अइसन हाल में रउआ सब प्रासंगिक माहौल के दस्तावेज बनावे के चाहीं।

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

सॉफ्टवेयर के नजरिया से, इन्फ्रास्ट्रक्चर के ओह तत्व के दर्ज कइल काफी बा जे रउआ बिल्डिंग ब्लॉक के डिप्लॉयमेंट देखावे खातिर चाहीं। हार्डवेयर आर्किटेक्ट एकरा से आगे जा सकेले आ इन्फ्रास्ट्रक्चर के ब्योरा के कवनो भी स्तर तक बता सकेले जे ऊ दर्ज करे के चाहेलें।

प्रेरणा

सॉफ्टवेयर हार्डवेयर के बिना ना चलेला। ई अंतर्निहित इन्फ्रास्ट्रक्चर रउआ सिस्टम आ/चाहे कुछ क्रॉसकटिंग अवधारणा पर असर डाल सकेला आ डाली। एहसे, रउआ इन्फ्रास्ट्रक्चर के जानल जरूरी बा।

रूप

शायद सबसे ऊपरी स्तर के डिप्लॉयमेंट आरेख पहिलहीं खंड 3.2. में तकनीकी संदर्भ के रूप में बा, जेमें रउआ अपना इन्फ्रास्ट्रक्चर के एक काला डिब्बा के रूप में देखावल गइल बा। एह खंड में रउआ अतिरिक्त डिप्लॉयमेंट आरेख से एह काला डिब्बा में जूम करब।

• UML एह दृश्य के बतावे खातिर डिप्लॉयमेंट आरेख देला। जब रउआ इन्फ्रास्ट्रक्चर जादा जटिल होखे त एकरा के, शायद नेस्टेड आरेख संगे, इस्तेमाल करीं।

• जब रउआ (हार्डवेयर) हितधारक लोग UML डिप्लॉयमेंट आरेख के बजाय आउर तरह के आरेख पसंद करे, त उनके ऊहे इस्तेमाल करे दीं जे इन्फ्रास्ट्रक्चर के नोड आ चैनल देखा सके।

7.1 इन्फ्रास्ट्रक्चर स्तर 1

(आम तौर पर आरेख, तालिका, आ पाठ के मेल में) वर्णन करीं:

• रउआ सिस्टम के कई स्थान, माहौल, कंप्यूटर, प्रोसेसर, .. में वितरण आ उनकर बीच भौतिक संबंध

• एह डिप्लॉयमेंट बनावट खातिर जरूरी औचित्य चाहे प्रेरणा

• इन्फ्रास्ट्रक्चर के गुणवत्ता आ/चाहे प्रदर्शन विशेषता

• सॉफ्टवेयर आर्टिफैक्ट (बिल्डिंग ब्लॉक) के इन्फ्रास्ट्रक्चर तत्व पर मैपिंग

कई माहौल चाहे वैकल्पिक डिप्लॉयमेंट खातिर, कृपया arc42 के ऊ खंड सब प्रासंगिक माहौल खातिर कॉपी करीं। **

7.2 इन्फ्रास्ट्रक्चर स्तर 2

इहाँ रउआ इन्फ्रास्ट्रक्चर स्तर 1 के (कुछ) इन्फ्रास्ट्रक्चर तत्व के भीतरी बनावट शामिल कर सकीले।

कृपया हर चुनल तत्व खातिर स्तर 1 से बनावट कॉपी करीं।

8. क्रॉसकटिंग अवधारणा

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

सामग्री

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

प्रेरणा

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

ई टेम्पलेट में ऊ जगह ह जे हमनी अइसन अवधारणा के एकजुट विनिर्देश खातिर देले बानी।

एमे से कई अवधारणा रउआ कई बिल्डिंग ब्लॉक से जुड़ल चाहे प्रभावित करेला।

रूप

रूप बदलत रह सकेला:

• कवनो भी बनावट वाला अवधारणा पत्र

• उदाहरण कार्यान्वयन, खास कर के तकनीकी अवधारणा खातिर

• क्रॉसकटिंग मॉडल अंश चाहे आर्किटेक्चर दृश्य के संकेतन इस्तेमाल करे वाला परिदृश्य

एह खंड के बनावट

अपना सिस्टम खातिर सबसे जादा जरूरी विषय चुनीं आ एह खंड में हर एक के स्तर-2 शीर्षक दीं (जइसे 8.1, 8.2 वगैरह)।

• ऊपर के आरेख के सब विषय के कवर करे के कोशिश मत करीं।

पृष्ठभूमि

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

कुछ अवधारणा सिस्टम के सब तत्व से जुड़ सकेला, आउर बस कुछ के लिए प्रासंगिक हो सकेला।

9. आर्किटेक्चर फैसला

औचित्य संगे जरूरी, महंगा, नाजुक, बड़ पैमाना वाला चाहे जोखिम वाला आर्किटेक्चर फैसला।

सामग्री

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

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

प्रेरणा

रउआ सिस्टम के हितधारक लोग रउआ फैसला के समझ आ फेर से खोज सके के चाहीं।

रूप

• हर जरूरी फैसला खातिर ADR (आर्किटेक्चर फैसला रिकॉर्ड)

• महत्त्व आ नतीजा के क्रम में सूची चाहे तालिका चाहे

• हर फैसला खातिर अलग खंड के रूप में जादा विस्तार से

पृष्ठभूमि (ADR के बारे में)

दस्तावेज के छोट टुकड़ा पढ़े, बनावे आ संभाले में आसान होला। जब आर्किटेक्चर फैसला के बात आवेला, त विकास टीम अक्सर:

• फैसला के बारे में जानेली, काहेकि ऊ जइसे सोर्स कोड में देखाई देला, लेकिन

• ऊ फैसला के पीछे के प्रेरणा चूक जालेली (देखीं Nygard 2011)

एहसे रउआ कुछ जरूरी फैसला के ओकर प्रेरणा, तर्क के संगे दस्तावेज बनावे के चाहीं

फैसला के बारे में हमनी के प्रस्ताव

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

10. गुणवत्ता जरूरत

परिदृश्य के रूप में गुणवत्ता जरूरत, ऊपरी स्तर के अवलोकन देवे खातिर गुणवत्ता पेड़ संगे। सबसे जरूरी गुणवत्ता लक्ष्य खंड 1.2. (गुणवत्ता लक्ष्य) में वर्णित हो चुकल होखे के चाहीं।

सामग्री

एह खंड में सब प्रासंगिक गुणवत्ता जरूरत बा।

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

प्रेरणा

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

आउर जानकारी

https://quality.arc42.org पर व्यापक Q42 गुणवत्ता मॉडल देखीं।

10.1 गुणवत्ता जरूरत के अवलोकन

सामग्री

गुणवत्ता जरूरत के अवलोकन चाहे सारांश।

प्रेरणा

अक्सर हमनी के दर्जन भर (चाहे सैकड़ो) विस्तृत गुणवत्ता जरूरत मिलेला। एह अवलोकन खंड में रउआ संक्षेप करे के कोशिश करीं, जइसे श्रेणी चाहे विषय के बतावत (जइसन ISO 25010:2023 चाहे Q42 सुझावेला

अगर ई सारांश वर्णन पहिलहीं सटीक, काफी खास आ नापे-लायक बा, त रउआ खंड 10.2 छोड़ सकीले।

रूप

एगो सादा तालिका इस्तेमाल करीं जेमें हर पंक्ति में एगो श्रेणी चाहे विषय आ गुणवत्ता जरूरत के छोट वर्णन होखे। चाहे, रउआ एह गुणवत्ता जरूरत के ढाँचा बनावे खातिर माइंडमैप इस्तेमाल कर सकीले।

साहित्य में, गुणवत्ता विशेषता पेड़ के विचार भी बतावल गइल बा, जे आम शब्द "गुणवत्ता" के जड़ के रूप में रखेला आ "गुणवत्ता" शब्द के पेड़-जइसन परिष्कृत रूप इस्तेमाल करेला। [Bass+21] एही मकसद से "Quality Attribute Utility Tree" शब्द लेके अइलन।

10.2 गुणवत्ता परिदृश्य

सामग्री

गुणवत्ता परिदृश्य गुणवत्ता जरूरत के ठोस बनावेला आ ई तय करे देला कि ऊ पूरा भइल कि ना (स्वीकृति कसौटी के अर्थ में)। पक्का करीं कि रउआ परिदृश्य खास आ नापे-लायक होखे।

दू तरह के परिदृश्य खास कर के काम के बा:

• उपयोग परिदृश्य (जेकरा के एप्लिकेशन परिदृश्य चाहे उपयोग-मामला परिदृश्य भी कहल जाला) कवनो खास उत्प्रेरक पर सिस्टम के रनटाइम प्रतिक्रिया के बतावेला। एमे ऊ परिदृश्य भी शामिल बा जे सिस्टम के कार्यकुशलता चाहे प्रदर्शन के बतावेला। उदाहरण: सिस्टम उपयोगकर्ता के अनुरोध पर एक सेकंड के भीतर प्रतिक्रिया देला।

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

रूप

विस्तृत परिदृश्य खातिर आम जानकारी में ई शामिल बा:

छोट रूप में (Q42 मॉडल में पसंदीदा):

• संदर्भ/पृष्ठभूमि: कवन तरह के सिस्टम चाहे घटक, माहौल चाहे हालात का बा?

• स्रोत/उत्प्रेरक: के चाहे का कवनो व्यवहार, प्रतिक्रिया चाहे कार्रवाई शुरू चाहे उत्प्रेरित करेला।

• मापदंड/स्वीकृति कसौटी: माप चाहे मापदंड सहित एगो प्रतिक्रिया

परिदृश्य के लमहर रूप (SEI आ [Bass+21] के पसंदीदा) जादा विस्तृत होला आ एमे ई जानकारी शामिल बा:

• परिदृश्य ID: परिदृश्य खातिर एगो अनोखा पहचानकर्ता।

• परिदृश्य के नाम: परिदृश्य खातिर एगो छोट, वर्णनात्मक नाम।

• स्रोत: ऊ इकाई (उपयोगकर्ता, सिस्टम, चाहे घटना) जे परिदृश्य शुरू करेला।

• उत्प्रेरक: ऊ घटना चाहे हालत जवना के सिस्टम के संबोधित करे के पड़ेला।

• माहौल: ऊ संचालन संदर्भ चाहे हालत जेमें सिस्टम उत्प्रेरक के अनुभव करेला।

• आर्टिफैक्ट: उत्प्रेरक से प्रभावित बिल्डिंग-ब्लॉक चाहे सिस्टम के आउर तत्व।

• प्रतिक्रिया: उत्प्रेरक के जवाब में सिस्टम जवन नतीजा चाहे व्यवहार देखावेला।

• प्रतिक्रिया माप: ऊ कसौटी चाहे मापदंड जेकरा से सिस्टम के प्रतिक्रिया के मूल्यांकन कइल जाला।

इहो देखीं

जनवरी 2023 से, arc42 एगो व्यावहारिक गुणवत्ता मॉडल देवेला, जे गुणवत्ता जरूरत के हैशटैग चाहे लेबल जइसे #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable से चिह्नित करे के सुझाव देला।

11. जोखिम आ तकनीकी कर्ज

जानल तकनीकी जोखिम चाहे तकनीकी कर्ज। सिस्टम के भीतर चाहे आसपास कवन संभावित समस्या बा? विकास टीम के का बात से दुख होला?

सामग्री

पहचानल गइल तकनीकी जोखिम चाहे तकनीकी कर्ज के सूची, प्राथमिकता के क्रम में

प्रेरणा

"जोखिम प्रबंधन बड़ लोग खातिर परियोजना प्रबंधन ह" (Tim Lister, Atlantic Systems Guild.)

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

रूप

जोखिम आ/चाहे तकनीकी कर्ज के सूची, शायद जोखिम के कम करे, नरम करे चाहे टालल चाहे तकनीकी कर्ज घटावे खातिर सुझावल उपाय सहित।