Visual Paradigm Desktop | 
Visual Paradigm Online
एजाइल विकास को अक्सर गति, लचीलापन और न्यूनतम दस्तावेज़ीकरण के साथ जोड़ा जाता है। डेटा फ्लो डायग्राम (DFDs), दूसरी ओर, एक पारंपरिक सिस्टम मॉडलिंग तकनीक है जो इतिहास में संरचित, योजना-आधारित वातावरणों में विकसित हुई है। पहली नज़र में, इन दोनों दृष्टिकोणों को एक दूसरे के विरोधी लग सकते हैं। हालांकि, सही तरीके से लागू किए जाने पर, DFDs एजाइल ढांचे के भीतर अमूर्त आवश्यकताओं और वास्तविक सिस्टम आर्किटेक्चर के बीच एक महत्वपूर्ण पुल के रूप में कार्य करते हैं। यह मार्गदर्शिका यह जांचती है कि डेटा के आंदोलन को दृश्याकरण कैसे आवर्धित विकास को समर्थन देता है बिना स्पष्टता या नियंत्रण के नुकसान के।
एक जानकारी के स्रोत, उसके परिवर्तन और अंतिम स्थान को समझना मजबूत सॉफ्टवेयर बनाने के लिए आवश्यक है। चाहे आप माइक्रोसर्विस आर्किटेक्चर डिज़ाइन कर रहे हों या एक मोनोलिथिक एप्लिकेशन को फिर से बना रहे हों, डेटा फ्लो के सिद्धांत एक जैसे रहते हैं। हम व्यावहारिक अनुप्रयोगों, एकीकरण रणनीतियों और DFDs के द्वारा स्प्रिंट साइकिल में लाए जाने वाले विशिष्ट मूल्य का अध्ययन करेंगे।
एक डेटा फ्लो डायग्राम एक सूचना प्रणाली के माध्यम से डेटा के प्रवाह का आलेखीय प्रतिनिधित्व है। फ्लोचार्ट के विपरीत जो नियंत्रण तर्क और निर्णय बिंदुओं को दर्शाता है, DFD डेटा पर ध्यान केंद्रित करता है। यह डेटा के बाहरी स्रोत से शुरू होकर प्रक्रियाओं के माध्यम से, डेटा स्टोर में जाने और अंततः एक बाहरी गंतव्य तक पहुंचने के प्रवाह को नक्शा बनाता है।
एजाइल परिदृश्य में, ये आरेख स्थिर नक्शे नहीं हैं। वे उत्पाद के साथ विकसित होने वाले जीवंत अभिलेख हैं। DFD के मुख्य घटक निम्नलिखित हैं:
जब डेवलपर और प्रोडक्ट ओनर DFD को देखते हैं, तो वे प्रणाली के “क्या” को देखते हैं, न कि “कैसे” को। यह अंतर महत्वपूर्ण है। यह टीम को यह सत्यापित करने की अनुमति देता है कि कोड लिखने से पहले सभी आवश्यक डेटा को ध्यान में रखा गया है।
एजाइल टीमों में एक सामान्य संदेह यह है कि आरेख बनाने के लिए अतिरिक्त लागत होती है। एजाइल मैनिफेस्टो कार्यात्मक सॉफ्टवेयर को व्यापक दस्तावेज़ीकरण से अधिक महत्व देता है। हालांकि, इसका अर्थ यह नहीं है कि दस्तावेज़ीकरण बेकार है। इसका अर्थ है कि दस्तावेज़ीकरण उपयोगी होना चाहिए और अनावश्यक बाधाएं नहीं बनानी चाहिए।
यदि DFDs को एक गेटकीपिंग तंत्र के रूप में लिया जाए, तो वे एक बाधा बन सकते हैं। इसके बजाय, उन्हें संचार उपकरण के रूप में लिया जाना चाहिए। एजाइल वर्कफ्लो में DFDs को बनाए रखने के मुख्य तर्क नीचे दिए गए हैं:
लक्ष्य पूर्ण आरेख बनाना नहीं है जो हफ्तों तक बनाने में लगे। लक्ष्य इतनी स्पष्टता बनाना है जो पुनरावृत्ति को कम करे। एक त्वरित व्हाइटबोर्ड ड्राइंग जिसे बाद में सुधारा जाए, अक्सर कभी अद्यतन नहीं किए जाने वाले पॉलिश किए गए दस्तावेज़ से अधिक मूल्यवान होता है।
एजाइल स्प्रिंट में सिस्टम मॉडलिंग को एकीकृत करने के लिए अनुशासन की आवश्यकता होती है। आरेखों को सही समय पर और सही विवरण के स्तर पर बनाया जाना चाहिए। नीचे दिए गए विवरण में DFDs को मानक एजाइल समारोहों में कैसे फिट किया जाता है, इसका विश्लेषण दिया गया है।
सुधारणा के दौरान, टीम एपिक्स को कहानियों में तोड़ती है। यह एक उच्च स्तर के DFD को तैयार करने का आदर्श समय है। यह टीम को डेटा हस्तांतरण के संदर्भ में एपिक्स के दायरे को समझने में मदद करता है। यदि एक एपिक में एक पुराने सिस्टम से नए डैशबोर्ड में ग्राहक डेटा हस्तांतरित करने का लक्ष्य है, तो DFD आवश्यक रूपांतरण चरणों को उजागर करता है।
जब स्प्रिंट बैकलॉग तय हो जाता है, तो टीम गहराई से जांच कर सकती है। जटिल कहानियों के लिए, एक स्तर 1 या स्तर 2 DFD बनाया जा सकता है। इससे यह सुनिश्चित होता है कि कहानी के लिए नियुक्त डेवलपर्स डेटा निर्भरताओं को समझते हैं। इससे बचा जाता है कि कोई डेवलपर एक एंडपॉइंट बनाए जो डेटा के एक ऐसे फॉर्मेट में अपेक्षा करे जिसे नीचे की प्रक्रिया संभाल नहीं सकती है।
हालांकि हर दिन डायग्राम बनाने की आवश्यकता नहीं होती है, लेकिन ब्लॉकर अक्सर डेटा अखंडता से संबंधित होते हैं। यदि कोई डेवलपर इंडेक्स के अभाव या अनुमति समस्याओं के कारण फंस गया है, तो DFD को संदर्भित करने से अपेक्षित स्थिति और वास्तविक स्थिति के बीच स्पष्टता आती है।
एक स्प्रिंट के बाद, टीम को यह जांचना चाहिए कि क्या DFDs अभी भी लागू कोड के अनुरूप हैं। यदि आर्किटेक्चर विचलित हो गया है, तो डायग्राम को अद्यतन करना चाहिए। इस अभ्यास से दस्तावेज़ीकरण भविष्य के स्प्रिंट्स के लिए संबंधित और विश्वसनीय बना रहता है।
हर फीचर के लिए हर डेटा लेनदेन में गहराई से जाने की आवश्यकता नहीं होती है। विभिन्न स्तरों के DFD विकास चक्र के भीतर अलग-अलग उद्देश्यों के लिए काम करते हैं। सही स्तर का उपयोग न तो अपर्याप्त विवरण और न ही अत्यधिक डिज़ाइन को रोकता है।
| स्तर | फोकस | कब उपयोग करें | सामान्य दर्शक |
|---|---|---|---|
| संदर्भ आरेख | सिस्टम सीमा और बाहरी अंतरक्रियाएं। | प्रोजेक्ट प्रारंभ या उच्च स्तर की योजना। | हितधारक, आर्किटेक्ट्स |
| स्तर 0 (उच्च स्तर) | सिस्टम के भीतर प्रमुख प्रक्रियाएं। | सिस्टम डिज़ाइन चरण या प्रमुख फीचर योजना। | टीम लीड्स, सीनियर डेवलपर्स |
| स्तर 1 (मध्यम स्तर) | प्रमुख प्रक्रियाओं का विभाजन। | जटिल फीचर्स के लिए स्प्रिंट योजना। | डेवलपर्स, एक्वा |
| स्तर 2 (विस्तृत) | विशिष्ट डेटा रूपांतरण। | जटिल तर्क या एकीकरण बिंदुओं के लिए कोडिंग चरण। | व्यक्तिगत डेवलपर्स |
एजाइल टीमों के लिए सामान्य बात है कि वे संदर्भ आरेख से शुरुआत करती हैं और केवल तब तक स्तर 1 या 2 तक गहराई से जाती हैं जब एक विशिष्ट फीचर इसकी आवश्यकता महसूस करता है। इस समय पर मॉडलिंग दृष्टिकोण सुनिश्चित करता है कि विस्तार के वे विवरण नष्ट नहीं होते जो अगले इटरेशन में बदल सकते हैं।
एजाइल में डीएफडी के सबसे उपयोगी अनुप्रयोगों में से एक उन्हें सीधे उपयोगकर्ता कहानियों में मैप करना है। उपयोगकर्ता कहानियाँ उपयोगकर्ता के दृष्टिकोण से कार्यक्षमता का वर्णन करती हैं (उदाहरण के लिए, “एक उपयोगकर्ता के रूप में, मैं अपना प्रोफ़ाइल अपडेट करना चाहता हूँ”)। डीएफडी उस कार्यक्षमता के पीछे के डेटा यांत्रिकी का वर्णन करते हैं।
“भुगतान प्रक्रिया” के बारे में एक कहानी पर विचार करें। एक उपयोगकर्ता कहानी सफलता की स्थिति पर ध्यान केंद्रित करती है। डीएफडी पैसे के डेटा के यात्रा पर ध्यान केंद्रित करता है। उन्हें जोड़कर, टीम सुनिश्चित करती है कि कार्यात्मक आवश्यकता तकनीकी वास्तविकता द्वारा समर्थित है।
यहाँ मैपिंग कैसे काम करती है:
यह मैपिंग स्वीकृति मानदंड बनाने में मदद करती है। यदि डीएफडी किसी “लेनदेन लॉग” भंडार में प्रवाह दिखाता है, तो स्वीकृति मानदंड में यह सत्यापित करने का निर्देश शामिल होना चाहिए कि लॉग प्रविष्टि सफलतापूर्वक बनाई गई है। इससे आरेख और परीक्षण मामलों के बीच ट्रेसेबिलिटी लिंक बनता है।
आधुनिक एप्लिकेशन अक्सर जटिल डेटा संरचनाओं, नेस्टेड ऑब्जेक्ट्स और असिंक्रोनस प्रोसेसिंग के साथ काम करते हैं। पारंपरिक डीएफडी बिना संशोधन के असिंक्रोनस क्यू या इवेंट-ड्राइवन आर्किटेक्चर को दृश्यमान बनाने में कठिनाई महसूस कर सकते हैं। एजाइल संदर्भ में, नोटेशन को सिस्टम की वास्तविकता के अनुरूप अनुकूलित करना महत्वपूर्ण है।
इवेंट-ड्राइवन सिस्टम के लिए, डेटा प्रवाह को घटनाओं के रूप में देखा जा सकता है जो प्रक्रियाओं को ट्रिगर करती हैं। क्यू का उपयोग करते समय, डेटा भंडार संदेश ब्रोकर का प्रतिनिधित्व करता है। एपीआई का उपयोग करते समय, डेटा प्रवाह रिक्वेस्ट/रिस्पॉन्स साइकिल का प्रतिनिधित्व करता है। मूल सिद्धांत वही रहता है: जानकारी का अनुसरण करें।
माइक्रोसर्विसेज के साथ काम करते समय, डीएफडी को क्रॉस-सर्विस संचार दिखाने के लिए विस्तारित किया जा सकता है। यह लेटेंसी और विफलता बिंदुओं को समझने के लिए महत्वपूर्ण है। यदि सर्विस ए सर्विस बी को डेटा भेजती है, तो डीएफडी उस निर्भरता को स्पष्ट करती है। मोनोलिथ में, यह निर्भरता तब तक अदृश्य रह सकती है जब तक कि यह प्रदर्शन समस्या नहीं उत्पन्न करती है।
डीएफडी चर्चा को बढ़ावा देने में निपुण हैं। वे भाषा-अनाड़ी हैं जितना कि व्यापार विश्लेषक और डेवलपर्स एक ही सामग्री पर बिना भ्रम के चर्चा कर सकते हैं। हालांकि, इसके लिए आरेख को उपलब्ध और पठनीय होना आवश्यक है।
सहयोगात्मक आरेखण के लिए सर्वोत्तम प्रथाएँ निम्नलिखित हैं:
जब एक आरेख रिपॉजिटरी में स्टोर किया जाता है, तो वह निरंतर एकीकरण पाइपलाइन का हिस्सा बन जाता है। स्वचालित जांच यह सत्यापित कर सकती है कि आरेख निश्चित संदर्भों में डिप्लॉय किए गए कॉन्फ़िगरेशन के साथ मेल खाता है, हालांकि यह उन्नत उपयोग है।
सर्वोत्तम इच्छाओं के साथ भी, टीमें DFDs का गलत उपयोग कर सकती हैं। इन त्रुटियों को जल्दी से पहचानने से समय और प्रयास बचता है।
टीमें कभी-कभी आरेख को सुंदर बनाने में बहुत समय बर्बाद कर देती हैं। एजाइल में, एक खास खाका एक आदर्श दस्तावेज से बेहतर है। स्पष्टता पर ध्यान केंद्रित करें, न कि बाहरी दिखावट पर। यदि एक डेवलपर एक खाके से प्रवाह को समझ सकता है, तो यह पर्याप्त है।
प्रक्रियाओं पर ध्यान केंद्रित करना आसान है और डेटा के स्थान को भूल जाना आसान है। यदि कोई प्रक्रिया एक स्टोर में लिखती है जिसे कोई अन्य प्रक्रिया नहीं पढ़ती है, तो वह बेकार का भार है। यदि कोई प्रक्रिया एक स्टोर से पढ़ती है जिसे कभी अपडेट नहीं किया जाता है, तो डेटा अद्यतन नहीं है। डेटा स्टोर की नियमित समीक्षा सुनिश्चित करती है कि आरेख सही रहे।
हर चर के लिए आरेख पर एक रेखा की आवश्यकता नहीं होती है। उच्च मूल्य वाले डेटा प्रवाह पर ध्यान केंद्रित करें। यदि किसी सिस्टम में एक सेटिंग है जो बहुत दुर्लभ बार बदलती है, तो उसके लिए विस्तृत प्रवाह रेखा की आवश्यकता नहीं हो सकती है। अत्यधिक मॉडलिंग शोर में बदल जाती है और आरेख को बनाए रखना मुश्किल बना देती है।
जब कोड में बदलाव आता है, तो DFD को अपडेट करने के लिए कौन जिम्मेदार है? यदि कोई इसके मालिक नहीं है, तो यह तेजी से अप्रचलित हो जाता है। इस आरेख के मालिकाना हक को टीम लीड या उस विशिष्ट क्षेत्र के आर्किटेक्ट को सौंपें।
आप कैसे जानेंगे कि DFDs का उपयोग एजाइल टीम को वास्तव में मदद कर रहा है? समय के साथ इन संकेतकों को देखें:
यदि इन मापदंडों में सुधार होता है, तो मॉडलिंग में निवेश उचित है। यदि ऐसा नहीं होता है, तो टीम को आरेखों की विस्तृतता या अपडेट की आवृत्ति की पुनर्समीक्षा करनी चाहिए।
बहुत से उद्योगों में डेटा के संबंध में नियम होते हैं। वित्तीय डेटा, स्वास्थ्य रिकॉर्ड और व्यक्तिगत जानकारी के संग्रह और हस्तांतरण के संबंध में कड़ी आवश्यकताएं होती हैं। DFDs का उपयोग सुसंगतता ऑडिट के लिए विशेष रूप से उपयोगी है।
एक DFD स्पष्ट रूप से दिखाता है कि संवेदनशील डेटा सिस्टम में कहाँ प्रवेश करता है, इसे कैसे एन्क्रिप्ट किया जाता है, इसे कहाँ संग्रहीत किया जाता है, और यह कहाँ से बाहर निकलता है। इस दृश्यता की आवश्यकता है:
संवेदनशील डेटा के साथ एक एजाइल स्प्रिंट के दौरान, कोड को मर्ज करने से पहले DFD की सुरक्षा टीम द्वारा समीक्षा की जानी चाहिए। इससे सुरक्षा को विकास जीवनचक्र में शामिल किया जाता है बिना इसे धीमा किए।
बहुत से एजाइल टीमें पुराने सिस्टम के आधुनिकीकरण पर काम करती हैं। इसमें अक्सर पुराने कार्यों को नए APIs के साथ लपेटना या डेटा को नए प्लेटफॉर्म पर स्थानांतरित करना शामिल होता है। DFDs इस संदर्भ में अनमूल्य हैं क्योंकि वे पुराने कोड के ‘काले बॉक्स’ को दस्तावेजीकृत करते हैं।
पुराने सिस्टम के DFD बनाकर, टीम डेटा स्थानांतरण के प्रवेश और निकास बिंदुओं को पहचान सकती है। इससे पुराने और नए सिस्टम के बीच पुल डिज़ाइन करने में मदद मिलती है। यह सुनिश्चित करता है कि संक्रमण के दौरान कोई डेटा नहीं खो जाता है और नए सिस्टम डेटा का सही तरीके से प्रबंधन करता है।
एजाइल विकास में डेटा फ्लो आरेखों के एकीकरण का उद्देश्य भारी दस्तावेजीकरण में वापस जाना नहीं है। यह आर्किटेक्चर की स्पष्ट समझ बनाए रखने और चरणबद्ध परिवर्तन को स्वीकार करने के बारे में है। जब इन्हें स्थिर आवश्यकता के बजाय जीवंत, विकसित होते उपकरण के रूप में उपयोग किया जाता है, तो DFDs संचार को बढ़ाते हैं, जोखिम को कम करते हैं और डिलीवर किए गए सॉफ्टवेयर की गुणवत्ता में सुधार करते हैं।
वे टीमें जो इस प्रथा को अपनाती हैं, उन्हें पता चलता है कि डेटा प्रबंधन से जुड़ा उनका तकनीकी ऋण कम हो जाता है। वे डेटा समस्याओं के निराकरण में कम समय बिताती हैं और फीचर बनाने में अधिक समय बिताती हैं। मुख्य बात संतुलन है। जब आरेख मूल्य जोड़ते हैं, तब उन्हें बनाएं। जब सिस्टम में परिवर्तन होता है, तो उन्हें अपडेट करें। और हमेशा अंतिम लक्ष्य को ध्यान में रखें: एक सिस्टम जो सही और कुशलता से काम करे।