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