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।)

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

रूप

जोखिमों और/या तकनीकी ऋणों की सूची, जिसमें संभवतः जोखिमों को कम करने, घटाने या टालने, या तकनीकी ऋण घटाने के सुझावित उपाय शामिल हों।