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 को बनाकर, टीम डेटा स्थानांतरण के प्रवेश और निकास बिंदुओं को पहचान सकती है। यह पुराने और नए सिस्टम के बीच पुल को डिज़ाइन करने में मदद करता है। यह सुनिश्चित करता है कि संक्रमण के दौरान कोई डेटा नहीं खो जाता है और नए सिस्टम डेटा का सही तरीके से प्रबंधन करता है।
एजाइल विकास में डेटा फ्लो आरेखों के एकीकरण का उद्देश्य भारी दस्तावेजीकरण में वापस जाना नहीं है। यह आर्किटेक्चर की स्पष्ट समझ बनाए रखने और चरणबद्ध परिवर्तन को स्वीकार करने के बारे में है। जब डीएफडी को एक स्थिर आवश्यकता के बजाय एक जीवंत, विकसित होते उपकरण के रूप में उपयोग किया जाता है, तो यह संचार में सुधार करता है, जोखिम को कम करता है और डिलीवर की गई सॉफ्टवेयर की गुणवत्ता में सुधार करता है।
इस प्रथा को अपनाने वाली टीमें पाती हैं कि डेटा प्रबंधन से जुड़ा उनका तकनीकी ऋण कम हो जाता है। वे डेटा समस्याओं के निराकरण में कम समय बिताते हैं और फीचर बनाने में अधिक समय बिताते हैं। महत्वपूर्ण बात संतुलन है। जब आरेख मूल्य जोड़ते हैं, तब उन्हें बनाएं। जब सिस्टम में परिवर्तन होता है, तो उन्हें अपडेट करें। और हमेशा अंतिम लक्ष्य को ध्यान में रखें: एक सिस्टम जो सही और कुशलता से काम करे।