arc42 चा निर्णय नोंद साचा

https://arc42.org/overview

१. प्रस्तावना आणि उद्दिष्टे

आवश्यकता, प्रेरक शक्ती यांचे संक्षिप्त वर्णन, आवश्यकतांचा सारांश (किंवा गोषवारा). प्रमुख भागधारकांसाठी सर्वाधिक प्राधान्य असलेली आर्किटेक्चरची पहिली तीन (जास्तीत जास्त पाच) गुणवत्ता उद्दिष्टे. आर्किटेक्चरबद्दल त्यांच्या अपेक्षांसह महत्त्वाच्या भागधारकांचा तक्ता.

१.१ आवश्यकतांचे विहंगावलोकन

सामग्री

कार्यात्मक आवश्यकता, प्रेरक शक्ती यांचे संक्षिप्त वर्णन, आवश्यकतांचा सारांश (किंवा गोषवारा). (आशा आहे की अस्तित्वात असलेल्या) आवश्यकता दस्तऐवजांचे दुवे, ते कुठे सापडतील याच्या माहितीसह.

प्रेरणा

अंतिम वापरकर्त्यांच्या दृष्टिकोनातून, एखाद्या व्यावसायिक क्रियाकलापाला अधिक चांगला आधार देण्यासाठी आणि/किंवा गुणवत्ता सुधारण्यासाठी प्रणाली तयार केली जाते किंवा बदलली जाते.

स्वरूप

संक्षिप्त मजकूर वर्णन, शक्यतो तक्त्याच्या स्वरूपातील वापर प्रकरण स्वरूपात. आवश्यकता दस्तऐवज अस्तित्वात असल्यास, या विहंगावलोकनाने त्या दस्तऐवजांचा संदर्भ दिला पाहिजे.

हे उतारे शक्य तितके संक्षिप्त ठेवा. या दस्तऐवजाची वाचनीयता आणि आवश्यकता दस्तऐवजांच्या संदर्भातील संभाव्य पुनरावृत्ती यांच्यात समतोल राखा.

१.२ गुणवत्ता उद्दिष्टे

सामग्री

आर्किटेक्चरची पहिली तीन (जास्तीत जास्त पाच) गुणवत्ता उद्दिष्टे, ज्यांची पूर्तता प्रमुख भागधारकांसाठी सर्वात महत्त्वाची आहे. आम्हाला खरोखर आर्किटेक्चरसाठीची गुणवत्ता उद्दिष्टे म्हणायचे आहे. त्यांना प्रकल्प उद्दिष्टांशी गल्लत करू नका. ती परस्पर समान असतीलच असे नाही. ISO 25010 मानक संभाव्य आवडीच्या विषयांचे उत्तम विहंगावलोकन देते.

प्रेरणा

तुम्हाला तुमच्या सर्वात महत्त्वाच्या भागधारकांची गुणवत्ता उद्दिष्टे माहीत असली पाहिजेत, कारण ती मूलभूत आर्किटेक्चरल निर्णयांवर प्रभाव टाकतील. या गुणवत्तांबद्दल अतिशय ठोस राहा, प्रचलित शब्द टाळा. तुम्हाला, आर्किटेक्ट म्हणून, तुमच्या कामाच्या गुणवत्तेचे मूल्यमापन कसे केले जाईल हे माहीत नसेल तर …

स्वरूप

सर्वात महत्त्वाची गुणवत्ता उद्दिष्टे आणि ठोस परिस्थिती असलेला तक्ता, प्राधान्यक्रमानुसार मांडलेला.

१.३ भागधारक

सामग्री

प्रणालीच्या भागधारकांचे स्पष्ट विहंगावलोकन, म्हणजे असे सर्व लोक, भूमिका किंवा संस्था जे

• आर्किटेक्चर जाणून घेतले पाहिजेत

• आर्किटेक्चरबद्दल पटवून द्यावे लागतात

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

• त्यांच्या कामासाठी आर्किटेक्चरच्या दस्तऐवजीकरणाची गरज असते

• प्रणालीबद्दल किंवा तिच्या विकासाबद्दल निर्णय घ्यावे लागतात

प्रेरणा

प्रणालीच्या विकासात सहभागी असलेले किंवा प्रणालीमुळे प्रभावित होणारे सर्व पक्ष तुम्हाला माहीत असले पाहिजेत. अन्यथा, विकास प्रक्रियेत नंतर तुम्हाला अप्रिय धक्के बसू शकतात. हे भागधारक तुमच्या कामाची व्याप्ती आणि तपशीलाची पातळी ठरवतात.

स्वरूप

भूमिकांची नावे, व्यक्तींची नावे आणि आर्किटेक्चर व त्याच्या दस्तऐवजीकरणाबद्दल त्यांच्या अपेक्षा असलेला तक्ता.

२. मर्यादा

रचना आणि अंमलबजावणीच्या निर्णयांमध्ये किंवा संबंधित प्रक्रियांबद्दलच्या निर्णयांमध्ये संघांना मर्यादित करणारे सर्व काही. काही वेळा वैयक्तिक प्रणालींच्या पलीकडे जाऊन संपूर्ण संस्था आणि कंपन्यांना लागू असू शकते.

सामग्री

सॉफ्टवेअर आर्किटेक्ट्सना त्यांच्या रचना आणि अंमलबजावणी निर्णयांच्या स्वातंत्र्यात किंवा विकास प्रक्रियेबद्दलच्या निर्णयात मर्यादित करणारी कोणतीही आवश्यकता. या मर्यादा काही वेळा वैयक्तिक प्रणालींच्या पलीकडे जातात आणि संपूर्ण संस्था व कंपन्यांना लागू असतात.

प्रेरणा

आर्किटेक्ट्सना त्यांच्या रचना निर्णयांमध्ये ते नेमके कुठे मुक्त आहेत आणि कुठे मर्यादांचे पालन करावे लागते हे अचूक माहीत असले पाहिजे. मर्यादांना नेहमीच सामोरे जावे लागते; त्या वाटाघाटीयोग्य असू शकतात.

स्वरूप

स्पष्टीकरणांसह मर्यादांचे साधे तक्ते. आवश्यक असल्यास तुम्ही त्यांचे तांत्रिक मर्यादा, संघटनात्मक आणि राजकीय मर्यादा आणि परंपरा (उदा. प्रोग्रामिंग किंवा आवृत्ती मार्गदर्शक तत्त्वे, दस्तऐवजीकरण किंवा नामकरण परंपरा) यांत उपविभाजन करू शकता.

३. संदर्भ आणि व्याप्ती

तुमची प्रणाली तिच्या (बाह्य) संवाद भागीदारांपासून (शेजारील प्रणाली आणि वापरकर्ते) वेगळी करते. बाह्य इंटरफेस निर्दिष्ट करते. व्यवसाय/क्षेत्र दृष्टिकोनातून (नेहमी) किंवा तांत्रिक दृष्टिकोनातून (ऐच्छिक) दाखवले जाते

सामग्री

प्रणालीची व्याप्ती आणि संदर्भ - नावाप्रमाणेच - तुमची प्रणाली (म्हणजे तुमची व्याप्ती) तिच्या सर्व संवाद भागीदारांपासून (शेजारील प्रणाली आणि वापरकर्ते, म्हणजे तुमच्या प्रणालीचा संदर्भ) वेगळी करते. त्यामुळे ती बाह्य इंटरफेस निर्दिष्ट करते.

आवश्यक असल्यास, व्यवसाय संदर्भ (क्षेत्र-विशिष्ट इनपुट आणि आउटपुट) तांत्रिक संदर्भापासून (चॅनेल, प्रोटोकॉल, हार्डवेअर) वेगळा करा.

प्रेरणा

संवाद भागीदारांशी असलेले क्षेत्रीय इंटरफेस आणि तांत्रिक इंटरफेस हे तुमच्या प्रणालीचे सर्वात महत्त्वाचे पैलू आहेत. तुम्ही ते पूर्णपणे समजून घेतल्याची खात्री करा.

स्वरूप

• विविध संदर्भ आकृत्या

• संवाद भागीदारांच्या आणि त्यांच्या इंटरफेसच्या याद्या.

३.१ व्यवसाय संदर्भ

सामग्री

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

प्रेरणा

प्रणालीच्या वातावरणाशी कोणता डेटा देवाणघेवाण केला जातो हे सर्व भागधारकांना समजले पाहिजे.

स्वरूप

प्रणालीला ब्लॅक बॉक्स म्हणून दाखवणाऱ्या आणि संवाद भागीदारांशी क्षेत्रीय इंटरफेस निर्दिष्ट करणाऱ्या सर्व प्रकारच्या आकृत्या.

पर्यायाने (किंवा अतिरिक्त) तुम्ही तक्ता वापरू शकता. तक्त्याचे शीर्षक तुमच्या प्रणालीचे नाव असते, तीन स्तंभांमध्ये संवाद भागीदाराचे नाव, इनपुट आणि आउटपुट असतात.

३.२ तांत्रिक संदर्भ

सामग्री

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

प्रेरणा

अनेक भागधारक प्रणाली आणि तिचा संदर्भ यांच्यातील तांत्रिक इंटरफेसवर आधारित आर्किटेक्चरल निर्णय घेतात. विशेषतः पायाभूत सुविधा किंवा हार्डवेअर डिझाइनर्स हे तांत्रिक इंटरफेस ठरवतात.

स्वरूप

उदा. शेजारील प्रणालींशी चॅनेल वर्णन करणारी UML डिप्लॉयमेंट आकृती, तसेच चॅनेल आणि इनपुट/आउटपुट यांच्यातील संबंध दाखवणारा मॅपिंग तक्ता.

४. उपाय धोरण

आर्किटेक्चरला आकार देणाऱ्या मूलभूत निर्णयांचा आणि उपाय धोरणांचा सारांश. तंत्रज्ञान, सर्वोच्च-स्तरीय विघटन, सर्वोच्च गुणवत्ता उद्दिष्टे साध्य करण्याचे दृष्टिकोन आणि संबंधित संघटनात्मक निर्णय यांचा समावेश असू शकतो.

सामग्री

प्रणालीच्या आर्किटेक्चरला आकार देणाऱ्या मूलभूत निर्णयांचा आणि उपाय धोरणांचा संक्षिप्त सारांश आणि स्पष्टीकरण. यात पुढील गोष्टींचा समावेश आहे

• तंत्रज्ञान निर्णय

• प्रणालीच्या सर्वोच्च-स्तरीय विघटनाबद्दलचे निर्णय, उदा. आर्किटेक्चरल पॅटर्न किंवा डिझाइन पॅटर्नचा वापर

• प्रमुख गुणवत्ता उद्दिष्टे कशी साध्य करायची याबद्दलचे निर्णय

• संबंधित संघटनात्मक निर्णय, उदा. विकास प्रक्रिया निवडणे किंवा काही कामे तृतीय पक्षांना सोपवणे.

प्रेरणा

हे निर्णय तुमच्या आर्किटेक्चरचे आधारस्तंभ आहेत. ते इतर अनेक तपशीलवार निर्णयांचा किंवा अंमलबजावणी नियमांचा पाया आहेत.

स्वरूप

या प्रमुख निर्णयांचे स्पष्टीकरण संक्षिप्त ठेवा.

तुमचे समस्या विधान, गुणवत्ता उद्दिष्टे आणि प्रमुख मर्यादा यांवर आधारित तुम्ही काय ठरवले आणि तसे का ठरवले याची प्रेरणा सांगा. पुढील विभागांमधील तपशिलांचा संदर्भ द्या (संरचनात्मक तपशिलांसाठी विभाग ५, आडव्या छेदणाऱ्या संकल्पनांसाठी विभाग ८).

तुम्ही उपाय-दृष्टिकोनांची यादी किंवा तक्ता वापरू शकता.

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

प्रणालीचे स्थिर विघटन, स्रोत कोडचे अमूर्तीकरण, योग्य तपशील पातळीपर्यंत व्हाइट बॉक्सच्या (ज्यात ब्लॅक बॉक्स असतात) पदानुक्रमाच्या स्वरूपात दाखवलेले.

सामग्री

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

हे दृश्य प्रत्येक आर्किटेक्चर दस्तऐवजीकरणासाठी अनिवार्य आहे. घराच्या तुलनेत, हा मजल्याचा आराखडा आहे.

प्रेरणा

अमूर्तीकरणाद्वारे तुमच्या स्रोत कोडची रचना समजण्याजोगी करून त्याचे विहंगावलोकन टिकवून ठेवा.

यामुळे तुम्ही अंमलबजावणीचे तपशील उघड न करता तुमच्या भागधारकांशी अमूर्त पातळीवर संवाद साधू शकता.

स्वरूप

बिल्डिंग ब्लॉक दृश्य म्हणजे ब्लॅक बॉक्स आणि व्हाइट बॉक्स यांचा पदानुक्रमी संग्रह (खालील आकृती पहा) आणि त्यांची वर्णने.

५.१ संपूर्ण प्रणालीचा व्हाइटबॉक्स

येथे तुम्ही पुढील व्हाइट बॉक्स साचा वापरून संपूर्ण प्रणालीचे विघटन वर्णन करता. त्यात खालील गोष्टी असतात

• एक विहंगावलोकन आकृती

• विघटनाची प्रेरणा

• समाविष्ट बिल्डिंग ब्लॉक्सची ब्लॅक बॉक्स वर्णने. यासाठी आम्ही तुम्हाला पर्याय देतो:

  • सर्व समाविष्ट बिल्डिंग ब्लॉक्स आणि त्यांच्या इंटरफेसच्या संक्षिप्त आणि व्यावहारिक विहंगावलोकनासाठी एक तक्ता वापरा

  • ब्लॅक बॉक्स साच्यानुसार (खाली पहा) बिल्डिंग ब्लॉक्सच्या ब्लॅक बॉक्स वर्णनांची यादी वापरा. तुमच्या साधनाच्या निवडीनुसार ही यादी उप-प्रकरणे (मजकूर फाईलींमध्ये), उप-पाने (Wiki मध्ये) किंवा नेस्टेड घटक (मॉडेलिंग साधनात) असू शकते.

  • (ऐच्छिक:) महत्त्वाचे इंटरफेस, जे बिल्डिंग ब्लॉकच्या ब्लॅक बॉक्स साच्यांमध्ये स्पष्ट केलेले नाहीत, पण व्हाइट बॉक्स समजण्यासाठी अतिशय महत्त्वाचे आहेत.

इंटरफेस निर्दिष्ट करण्याचे इतके मार्ग असल्याने आम्ही त्यांच्यासाठी विशिष्ट साचा देत नाही.

सर्वोत्तम परिस्थितीत तुम्ही उदाहरणे किंवा साध्या स्वाक्षऱ्यांवर निभावून न्याल.

५.२ स्तर २

येथे तुम्ही स्तर १ मधील (काही) बिल्डिंग ब्लॉक्सची अंतर्गत रचना व्हाइट बॉक्स म्हणून निर्दिष्ट करू शकता.

अशा तपशीलवार वर्णनाला न्याय्य ठरवण्याइतके तुमच्या प्रणालीचे कोणते बिल्डिंग ब्लॉक्स महत्त्वाचे आहेत हे तुम्हाला ठरवावे लागेल. कृपया पूर्णतेपेक्षा सुसंगततेला प्राधान्य द्या. महत्त्वाचे, आश्चर्यकारक, धोकादायक, गुंतागुंतीचे किंवा अस्थिर बिल्डिंग ब्लॉक्स निर्दिष्ट करा. तुमच्या प्रणालीचे सामान्य, साधे, कंटाळवाणे किंवा प्रमाणित भाग वगळा

५.२.१ बिल्डिंग ब्लॉक १ साठी व्हाइट बॉक्स

बिल्डिंग ब्लॉक १ ची अंतर्गत रचना निर्दिष्ट करते.

व्हाइट बॉक्स साचा वापरा (वर पहा).

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

बिल्डिंग ब्लॉक्सचे वर्तन परिस्थितींच्या स्वरूपात, ज्यात महत्त्वाची वापर प्रकरणे किंवा वैशिष्ट्ये, गंभीर बाह्य इंटरफेसवरील परस्परक्रिया, संचालन आणि प्रशासन तसेच त्रुटी आणि अपवाद वर्तन समाविष्ट आहे.

सामग्री

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

• महत्त्वाची वापर प्रकरणे किंवा वैशिष्ट्ये: बिल्डिंग ब्लॉक्स ती कशी कार्यान्वित करतात?

• गंभीर बाह्य इंटरफेसवरील परस्परक्रिया: बिल्डिंग ब्लॉक्स वापरकर्ते आणि शेजारील प्रणालींशी कसे सहकार्य करतात?

• संचालन आणि प्रशासन: प्रक्षेपण, सुरुवात, थांबवणे

• त्रुटी आणि अपवाद परिस्थिती

टीप: संभाव्य परिस्थिती (क्रम, कार्यप्रवाह) निवडण्याचा मुख्य निकष त्यांची आर्किटेक्चरल सुसंगतता आहे. मोठ्या संख्येने परिस्थिती वर्णन करणे महत्त्वाचे नाही. त्याऐवजी तुम्ही प्रातिनिधिक निवड दस्तऐवजीकृत करावी.

प्रेरणा

तुमच्या प्रणालीचे बिल्डिंग ब्लॉक्स (चे उदाहरणे) रनटाइमवेळी त्यांचे काम कसे करतात आणि संवाद कसा साधतात हे तुम्हाला समजले पाहिजे. स्थिर मॉडेल्स (बिल्डिंग ब्लॉक दृश्य, डिप्लॉयमेंट दृश्य) वाचण्यास आणि समजून घेण्यास कमी इच्छुक किंवा सक्षम असलेल्या भागधारकांना तुमचे आर्किटेक्चर कळवण्यासाठी तुम्ही मुख्यतः तुमच्या दस्तऐवजीकरणात परिस्थिती नोंदवाल.

स्वरूप

परिस्थिती वर्णन करण्यासाठी अनेक नोटेशन आहेत, उदा.

• क्रमांकित पायऱ्यांची यादी (नैसर्गिक भाषेत)

• क्रियाकलाप आकृत्या किंवा प्रवाह तक्ते

• क्रम आकृत्या

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

• स्थिती यंत्रे

• इत्यादी

६.n रनटाइम परिस्थिती n (१, २, ३, इत्यादी)

परिस्थितीची रनटाइम आकृती किंवा मजकूर वर्णन घाला.

या आकृतीत दाखवलेल्या बिल्डिंग ब्लॉक उदाहरणांमधील परस्परक्रियांच्या उल्लेखनीय पैलूंचे वर्णन घाला.

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

वातावरणे, संगणक, प्रोसेसर, टोपोलॉजी असलेली तांत्रिक पायाभूत सुविधा. (सॉफ्टवेअर) बिल्डिंग ब्लॉक्सचे पायाभूत सुविधा घटकांशी मॅपिंग.

सामग्री

डिप्लॉयमेंट दृश्य पुढील वर्णन करते:

• तुमची प्रणाली चालवण्यासाठी वापरलेली तांत्रिक पायाभूत सुविधा, ज्यात भौगोलिक स्थाने, वातावरणे, संगणक, प्रोसेसर, चॅनेल आणि नेट टोपोलॉजी तसेच इतर पायाभूत सुविधा घटक यांसारखे पायाभूत सुविधा घटक असतात, आणि

• (सॉफ्टवेअर) बिल्डिंग ब्लॉक्सचे त्या पायाभूत सुविधा घटकांशी मॅपिंग.

प्रणाली अनेकदा वेगवेगळ्या वातावरणांत चालवल्या जातात, उदा. विकास वातावरण, चाचणी वातावरण, उत्पादन वातावरण. अशा बाबतीत तुम्ही सर्व संबंधित वातावरणांचे दस्तऐवजीकरण केले पाहिजे.

तुमचे सॉफ्टवेअर एकापेक्षा जास्त संगणक, प्रोसेसर, सर्व्हर किंवा कंटेनर असलेल्या वितरित प्रणाली म्हणून चालवले जात असताना, किंवा तुम्ही स्वतःचे हार्डवेअर प्रोसेसर आणि चिप्स डिझाइन आणि तयार करत असताना डिप्लॉयमेंट दृश्याचे विशेषतः दस्तऐवजीकरण करा.

सॉफ्टवेअरच्या दृष्टिकोनातून, तुमच्या बिल्डिंग ब्लॉक्सची डिप्लॉयमेंट दाखवण्यासाठी आवश्यक असलेले पायाभूत सुविधा घटक नोंदवणे पुरेसे आहे. हार्डवेअर आर्किटेक्ट्स त्यापलीकडे जाऊन त्यांना हव्या असलेल्या कोणत्याही तपशील पातळीपर्यंत पायाभूत सुविधा वर्णन करू शकतात.

प्रेरणा

हार्डवेअरशिवाय सॉफ्टवेअर चालत नाही. ही अंतर्निहित पायाभूत सुविधा तुमच्या प्रणालीवर आणि/किंवा काही आडव्या छेदणाऱ्या संकल्पनांवर प्रभाव टाकू शकते आणि टाकेल. म्हणून, तुम्हाला पायाभूत सुविधा माहीत असणे आवश्यक आहे.

स्वरूप

कदाचित सर्वोच्च-स्तरीय डिप्लॉयमेंट आकृती विभाग ३.२ मध्ये तांत्रिक संदर्भ म्हणून, तुमच्या स्वतःच्या पायाभूत सुविधांसह एक ब्लॅक बॉक्स म्हणून, आधीच समाविष्ट आहे. या विभागात तुम्ही अतिरिक्त डिप्लॉयमेंट आकृत्या वापरून या ब्लॅक बॉक्समध्ये झूम कराल.

• UML हे दृश्य व्यक्त करण्यासाठी डिप्लॉयमेंट आकृत्या देते. तुमची पायाभूत सुविधा अधिक जटिल असताना, शक्यतो नेस्टेड आकृत्यांसह, ती वापरा.

• जेव्हा तुमचे (हार्डवेअर) भागधारक UML डिप्लॉयमेंट आकृतीऐवजी इतर प्रकारच्या आकृत्या पसंत करतात, तेव्हा पायाभूत सुविधांचे नोड आणि चॅनेल दाखवू शकणारा कोणताही प्रकार वापरू द्या.

७.१ पायाभूत सुविधा स्तर १

वर्णन करा (सामान्यतः आकृत्या, तक्ते आणि मजकूर यांच्या संयोगात):

• तुमच्या प्रणालीचे अनेक स्थाने, वातावरणे, संगणक, प्रोसेसर, .. यांमध्ये वितरण तसेच त्यांच्यातील भौतिक जोडण्या

• या डिप्लॉयमेंट रचनेचे महत्त्वाचे समर्थन किंवा प्रेरणा

• पायाभूत सुविधांची गुणवत्ता आणि/किंवा कार्यक्षमता वैशिष्ट्ये

• सॉफ्टवेअर आर्टिफॅक्ट्सचे (बिल्डिंग ब्लॉक्स) पायाभूत सुविधा घटकांशी मॅपिंग

अनेक वातावरणे किंवा पर्यायी डिप्लॉयमेंटसाठी कृपया arc42 चा तो विभाग सर्व संबंधित वातावरणांसाठी कॉपी करा. **

७.२ पायाभूत सुविधा स्तर २

येथे तुम्ही पायाभूत सुविधा स्तर १ मधील (काही) पायाभूत सुविधा घटकांची अंतर्गत रचना समाविष्ट करू शकता.

कृपया प्रत्येक निवडलेल्या घटकासाठी स्तर १ ची रचना कॉपी करा.

८. आडव्या छेदणाऱ्या संकल्पना

एकंदरीत, प्रणालीच्या अनेक भागांमध्ये (→ आडव्या छेदणाऱ्या) संबंधित मूलभूत नियम आणि उपाय दृष्टिकोन. संकल्पना अनेकदा अनेक बिल्डिंग ब्लॉक्सशी संबंधित असतात. क्षेत्र मॉडेल, आर्किटेक्चर पॅटर्न आणि शैली, विशिष्ट तंत्रज्ञान वापरण्याचे नियम आणि अंमलबजावणी नियम यांसारखे विविध विषय समाविष्ट करा.

सामग्री

हा विभाग आडव्या छेदणाऱ्या संकल्पना (पद्धती, पॅटर्न, नियम किंवा उपाय कल्पना) वर्णन करतो. अशा संकल्पना अनेकदा अनेक बिल्डिंग ब्लॉक्सशी संबंधित असतात. त्यात अनेक भिन्न विषयांचा समावेश असू शकतो.

प्रेरणा

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

अशा संकल्पनांच्या सुसंगत निर्दिष्टीकरणासाठी आम्ही दिलेले हे साच्यातील स्थान आहे.

यापैकी अनेक संकल्पना तुमच्या अनेक बिल्डिंग ब्लॉक्सशी संबंधित असतात किंवा त्यांना प्रभावित करतात.

स्वरूप

स्वरूप वेगवेगळे असू शकते:

• कोणत्याही प्रकारच्या रचनेचे संकल्पना पेपर

• उदाहरण अंमलबजावणी, विशेषतः तांत्रिक संकल्पनांसाठी

• आर्किटेक्चर दृश्यांचे नोटेशन वापरून आडव्या छेदणारे मॉडेल उतारे किंवा परिस्थिती

या विभागाची रचना

तुमच्या प्रणालीसाठी सर्वात आवश्यक विषयच निवडा आणि प्रत्येकाला या विभागात स्तर-२ शीर्षक द्या (उदा. ८.१, ८.२ इत्यादी).

• वर उल्लेख केलेल्या आकृतीतील सर्व विषय समाविष्ट करण्याचा प्रयत्न करू नका.

पार्श्वभूमी

प्रणालींमधील काही विषय अनेकदा अनेक बिल्डिंग ब्लॉक्स, हार्डवेअर घटक किंवा विकास प्रक्रियांशी संबंधित असतात. अशा आडव्या छेदणाऱ्या विषयांची संबंधित बिल्डिंग ब्लॉक्स, हार्डवेअर घटक किंवा विकास प्रक्रियांच्या वर्णनात पुनरावृत्ती करण्याऐवजी केंद्रीय ठिकाणी कळवणे किंवा दस्तऐवजीकृत करणे सोपे असू शकते.

काही संकल्पना प्रणालीच्या सर्व घटकांशी संबंधित असू शकतात, इतर फक्त काहींसाठी संबंधित असू शकतात.

९. आर्किटेक्चरल निर्णय

तर्कासह महत्त्वाचे, खर्चिक, गंभीर, मोठ्या प्रमाणावरील किंवा धोकादायक आर्किटेक्चर निर्णय.

सामग्री

तर्कासह महत्त्वाचे, खर्चिक, मोठ्या प्रमाणावरील किंवा धोकादायक आर्किटेक्चर निर्णय. "निर्णय" म्हणजे दिलेल्या निकषांवर आधारित एक पर्याय निवडणे.

आर्किटेक्चरल निर्णयाचे दस्तऐवजीकरण येथे या केंद्रीय विभागात करावे की त्याऐवजी स्थानिक पातळीवर (उदा. एका बिल्डिंग ब्लॉकच्या व्हाइट बॉक्स साच्यात) करावे हे ठरवण्यासाठी कृपया तुमचा विवेक वापरा. पुनरावृत्त मजकूर टाळा. तुम्ही आधीच तुमच्या आर्किटेक्चरचे सर्वात महत्त्वाचे निर्णय नोंदवलेल्या विभाग ४ चा संदर्भ घ्या.

प्रेरणा

तुमच्या प्रणालीच्या भागधारकांना तुमचे निर्णय समजून घेता आले पाहिजेत आणि त्यांचा मागोवा घेता आला पाहिजे.

स्वरूप

• प्रत्येक महत्त्वाच्या निर्णयासाठी ADR (आर्किटेक्चर निर्णय नोंद)

• महत्त्व आणि परिणामांनुसार क्रमबद्ध यादी किंवा तक्ता किंवा

• प्रत्येक निर्णयासाठी स्वतंत्र विभागांच्या स्वरूपात अधिक तपशीलवार

पार्श्वभूमी (ADR बद्दल)

लहान दस्तऐवजीकरण भाग वाचणे, तयार करणे आणि सांभाळणे सोपे असते. आर्किटेक्चर निर्णयांबाबत, विकास संघ अनेकदा:

• निर्णयाबद्दल जाणून असतात, कारण तो उदा. स्रोत कोडमध्ये दिसतो, पण

• त्या निर्णयामागील प्रेरणा चुकवतात (Nygard 2011 पहा)

म्हणून तुम्ही काही महत्त्वाचे निर्णय त्यांच्या प्रेरणा, तर्कासह दस्तऐवजीकृत केले पाहिजेत

निर्णयांबद्दल आमचा प्रस्ताव

आर्किटेक्चरदृष्ट्या महत्त्वाच्या निर्णयांचा संग्रह ठेवा, म्हणजे जे निर्णय रचना, गुणवत्ता वैशिष्ट्ये, महत्त्वाची (विशेषतः बाह्य) अवलंबित्वे आणि इंटरफेस किंवा बांधणी तंत्रांवर परिणाम करतात (हा प्रस्ताव दिल्याबद्दल Michael Nygard यांचे आभार).

१०. गुणवत्ता आवश्यकता

परिस्थितींच्या स्वरूपात गुणवत्ता आवश्यकता, उच्च-स्तरीय विहंगावलोकनासाठी गुणवत्ता वृक्षासह. सर्वात महत्त्वाची गुणवत्ता उद्दिष्टे विभाग १.२ (गुणवत्ता उद्दिष्टे) मध्ये वर्णन केलेली असावीत.

सामग्री

या विभागात सर्व संबंधित गुणवत्ता आवश्यकता असतात.

यांपैकी सर्वात महत्त्वाच्या आवश्यकता विभाग १.२ (गुणवत्ता उद्दिष्टे) मध्ये आधीच वर्णन केल्या आहेत, म्हणून येथे फक्त त्यांचा संदर्भ दिला पाहिजे. या विभाग १० मध्ये तुम्ही कमी महत्त्वाच्या गुणवत्ता आवश्यकता देखील नोंदवल्या पाहिजेत, ज्या पूर्णपणे साध्य न झाल्यास मोठे धोके निर्माण होणार नाहीत (पण असल्यास छान असतील).

प्रेरणा

गुणवत्ता आवश्यकतांचा आर्किटेक्चरल निर्णयांवर खूप प्रभाव असल्याने, तुमच्या भागधारकांसाठी कोणत्या गुणवत्ता खरोखर महत्त्वाच्या आहेत हे तुम्हाला विशिष्ट आणि मोजता येण्याजोग्या पद्धतीने माहीत असले पाहिजे.

अधिक माहिती

https://quality.arc42.org वर विस्तृत Q42 गुणवत्ता मॉडेल पहा.

१०.१ गुणवत्ता आवश्यकतांचे विहंगावलोकन

सामग्री

गुणवत्ता आवश्यकतांचे विहंगावलोकन किंवा सारांश.

प्रेरणा

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

हे सारांश वर्णन आधीच अचूक, पुरेसे विशिष्ट आणि मोजता येण्याजोगे असल्यास, तुम्ही विभाग १०.२ वगळू शकता.

स्वरूप

एक साधा तक्ता वापरा ज्यात प्रत्येक ओळीत एक वर्ग किंवा विषय आणि गुणवत्ता आवश्यकतेचे संक्षिप्त वर्णन असते. पर्यायाने, या गुणवत्ता आवश्यकता रचण्यासाठी तुम्ही माइंडमॅप वापरू शकता.

साहित्यात, गुणवत्ता गुणधर्म वृक्षाची कल्पनाही वर्णन केली आहे, जी "गुणवत्ता" ही सामान्य संज्ञा मूळ म्हणून ठेवते आणि "गुणवत्ता" या संज्ञेचे वृक्षासारखे परिष्करण वापरते. [Bass+21] ने यासाठी "Quality Attribute Utility Tree" ही संज्ञा आणली.

१०.२ गुणवत्ता परिस्थिती

सामग्री

गुणवत्ता परिस्थिती गुणवत्ता आवश्यकता ठोस बनवतात आणि त्या पूर्ण झाल्या आहेत की नाही (स्वीकृती निकषांच्या अर्थाने) हे ठरवण्यास परवानगी देतात. तुमच्या परिस्थिती विशिष्ट आणि मोजता येण्याजोग्या असल्याची खात्री करा.

दोन प्रकारच्या परिस्थिती विशेषतः उपयुक्त आहेत:

• वापर परिस्थिती (याला अनुप्रयोग परिस्थिती किंवा वापर प्रकरण परिस्थिती असेही म्हणतात) एखाद्या विशिष्ट उद्दीपनाला प्रणालीचा रनटाइम प्रतिसाद वर्णन करतात. यात प्रणालीची कार्यक्षमता किंवा कामगिरी वर्णन करणाऱ्या परिस्थितींचाही समावेश होतो. उदाहरण: प्रणाली वापरकर्त्याच्या विनंतीला एका सेकंदात प्रतिसाद देते.

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

स्वरूप

तपशीलवार परिस्थितींसाठी सामान्य माहितीत पुढील गोष्टींचा समावेश असतो:

संक्षिप्त स्वरूपात (Q42 मॉडेलने पसंत केलेले):

• संदर्भ/पार्श्वभूमी: कोणत्या प्रकारची प्रणाली किंवा घटक, वातावरण किंवा परिस्थिती कोणती?

• स्रोत/उद्दीपन: वर्तन, प्रतिक्रिया किंवा कृती कोण किंवा काय सुरू करते किंवा चालना देते.

• मेट्रिक/स्वीकृती निकष: मोजमाप किंवा मेट्रिकसह प्रतिसाद

परिस्थितींचे दीर्घ स्वरूप (SEI आणि [Bass+21] ने पसंत केलेले) अधिक तपशीलवार आहे आणि त्यात पुढील माहिती समाविष्ट असते:

• परिस्थिती ID: परिस्थितीसाठी अद्वितीय ओळखकर्ता.

• परिस्थितीचे नाव: परिस्थितीसाठी संक्षिप्त, वर्णनात्मक नाव.

• स्रोत: परिस्थिती सुरू करणारी संस्था (वापरकर्ता, प्रणाली किंवा घटना).

• उद्दीपन: प्रणालीने ज्याला सामोरे जाणे आवश्यक आहे ती चालना देणारी घटना किंवा स्थिती.

• वातावरण: ज्या कार्यान्वयन संदर्भात किंवा स्थितीत प्रणालीला उद्दीपनाचा अनुभव येतो.

• आर्टिफॅक्ट: उद्दीपनामुळे प्रभावित होणारे बिल्डिंग-ब्लॉक्स किंवा प्रणालीचे इतर घटक.

• प्रतिसाद: उद्दीपनाला प्रतिक्रिया म्हणून प्रणाली दाखवत असलेला निकाल किंवा वर्तन.

• प्रतिसाद मोजमाप: ज्या निकषाने किंवा मेट्रिकने प्रणालीच्या प्रतिसादाचे मूल्यमापन केले जाते.

हेही पहा

जानेवारी २०२३ पासून, arc42 एक व्यावहारिक गुणवत्ता मॉडेल देते, जे गुणवत्ता आवश्यकतांना #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable अशा हॅशटॅग किंवा लेबलांनी चिन्हांकित करण्याचा प्रस्ताव मांडते.

११. धोके आणि तांत्रिक कर्ज

ज्ञात तांत्रिक धोके किंवा तांत्रिक कर्ज. प्रणालीमध्ये किंवा तिच्याभोवती कोणत्या संभाव्य समस्या आहेत? विकास संघाला कशाबद्दल वाईट वाटते?

सामग्री

ओळखलेल्या तांत्रिक धोक्यांची किंवा तांत्रिक कर्जांची यादी, प्राधान्यानुसार क्रमबद्ध

प्रेरणा

"धोका व्यवस्थापन म्हणजे प्रौढांसाठीचे प्रकल्प व्यवस्थापन" (Tim Lister, Atlantic Systems Guild.)

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

स्वरूप

धोक्यांची आणि/किंवा तांत्रिक कर्जांची यादी, शक्यतो धोके कमी करण्यासाठी, सौम्य करण्यासाठी किंवा टाळण्यासाठी किंवा तांत्रिक कर्ज कमी करण्यासाठी सुचवलेल्या उपायांसह.