सॉफ़्टवेयर विकास का वॉटरफ़ॉल जीवन चक्र

वॉटरफ़ॉल मॉडल सॉफ़्टवेयर विकास जीवन चक्र का एक पारंपरिक, लोकप्रिय और रैखिक तरीका है। इसमें चरणों का क्रम और हर चरण का स्पष्ट लक्ष्य तय होता है। जैसे पानी ढलान पर नीचे की ओर बहता है, वैसे ही यह सख़्त मॉडल पीछे लौटे बिना आगे बढ़ता है।

वॉटरफ़ॉल का तरीका सख़्त है और बदलाव की गुंजाइश कम देता है। परीक्षण को अलग चरण माना जाता है, विकास के साथ लगातार चलने वाला काम नहीं। इसलिए यह मॉडल विकास के शुरुआती दौर में दोष ढूँढने की गुंजाइश नहीं देता।

आरेख को पूरे आकार में खोलें ↗

सॉफ़्टवेयर विकास का वॉटरफ़ॉल जीवन चक्र

चरण इस क्रम में चलते हैं:

1. आवश्यकताएँ जुटाना। ग्राहक की ज़रूरतें दर्ज करें और आवश्यक दस्तावेज़ तैयार करें।
2. सिस्टम डिज़ाइन। आवश्यकताओं के आधार पर सिस्टम की संरचना और उसकी हार्डवेयर व सॉफ़्टवेयर संबंधी ज़रूरतें तय करें।
3. कार्यान्वयन। डिज़ाइन के आधार पर कोड लिखना शुरू करें। प्रोग्राम को छोटी, स्वतंत्र यूनिटों में बाँटें। हर यूनिट को उसके विनिर्देशों के अनुसार जाँचें, फिर उन्हें जोड़कर पूरा सिस्टम बनाएँ।
4. एकीकरण परीक्षण। जाँची हुई यूनिटों को जोड़ें और दोष ढूँढने के लिए पूरे सिस्टम का परीक्षण करें।
5. परिनियोजन। एकीकरण परीक्षण में मिले दोष ठीक करें, फिर दोबारा जाँचकर पुष्टि करें कि वे दूर हो गए हैं। इसके बाद सिस्टम बाज़ार में जारी करने और ग्राहक के परिवेश में परिनियोजित करने के लिए तैयार होता है।
6. रखरखाव। सुपुर्दगी के बाद सामने आए दोषों और समस्याओं को हल करने के लिए पैच या नए संस्करण जारी करें।

चरण एक के बाद एक आगे बढ़ते हैं। अगला चरण तभी शुरू होता है जब पिछला चरण सफलतापूर्वक पूरा हो चुका हो।

जब आवश्यकताएँ स्पष्ट हों, उत्पाद स्थिर हो और हर चरण के लिए पर्याप्त संसाधन हों, तब वॉटरफ़ॉल अपनाएँ। व्यवहार में इसे छोटे और आसानी से सँभाले जा सकने वाले प्रोजेक्ट तक सीमित रखें। आवश्यकताओं में मध्यम या अधिक जोखिम हो तो इससे बचें।

आवश्यकताओं का विनिर्देशन और विश्लेषण

सॉफ़्टवेयर विकास इस बात पर निर्भर करता है कि आवश्यकताओं को कितनी अच्छी तरह समझकर दस्तावेज़ में दर्ज किया गया है। उनकी पहचान और दस्तावेज़ीकरण को आवश्यकताओं का विनिर्देशन और विश्लेषण कहते हैं।

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

आरेख को पूरे आकार में खोलें ↗

उपयोगकर्ता आवश्यकताओं का विनिर्देश

कंपनी के निर्धारित प्रारूप का उपयोग करें, जैसे Word दस्तावेज़, फ़्लोचार्ट या आरेख। इससे ग्राहक की अपेक्षाओं का विस्तृत रिकॉर्ड बनता है और टीम उन्हें सही ढंग से समझ पाती है। ग्राहक की आवश्यकताओं को पूरा न करने वाली हर चीज़ दोष है। गलत आवश्यकताएँ दर्ज करने से प्रोजेक्ट शुरू से ही गलत दिशा में चला जाता है।

उपयोगकर्ता आवश्यकताओं का विनिर्देश

यह गैर-तकनीकी दस्तावेज़ उपयोगकर्ता की अपेक्षाएँ और व्यावसायिक ज़रूरतें बताता है। इसे अंतिम उपयोगकर्ता लिखते हैं, और इसकी आवश्यकताएँ उपयोगकर्ता स्वीकृति परीक्षण के दौरान जाँची जाती हैं। यह दस्तावेज़ आवश्यकताओं से जुड़े आगे के काम और सिस्टम डिज़ाइन की बुनियाद है।

सॉफ़्टवेयर आवश्यकताओं का विनिर्देश

सॉफ़्टवेयर आवश्यकताओं का विनिर्देश (SRS) बताता है कि उपयोगकर्ता सॉफ़्टवेयर से कैसे काम करने की अपेक्षा करता है। इसके उद्देश्य हैं:

• सॉफ़्टवेयर की विस्तृत कार्यक्षमता पर ग्राहक और आपूर्तिकर्ता की सहमति दर्ज करना।
• सॉफ़्टवेयर डिज़ाइन के लिए आधार देना।
• स्पष्ट आवश्यकताओं से विकास और परीक्षण आसान बनाना।
• काम की समय-सारणी बनाने और लागत का अनुमान लगाने में सहायता करना।
• सत्यापन और उपयुक्तता की पुष्टि के लिए आधार देना।

आरेख को पूरे आकार में खोलें ↗

सॉफ़्टवेयर आवश्यकताओं का विनिर्देश

सॉफ़्टवेयर डिज़ाइन

सॉफ़्टवेयर डिज़ाइन के दो स्तर होते हैं:

• उच्च स्तरीय सॉफ़्टवेयर डिज़ाइन
• विस्तृत सॉफ़्टवेयर डिज़ाइन

आरेख को पूरे आकार में खोलें ↗

सॉफ़्टवेयर डिज़ाइन

उच्च स्तरीय सॉफ़्टवेयर डिज़ाइन

उच्च स्तरीय डिज़ाइन (HLD) डेटाबेस डिज़ाइन और कार्यात्मक संरचना का वर्णन करता है। यह डेवलपर का मार्गदर्शन करता है और डिज़ाइन किस तरह आगे बढ़ेगा, इस बारे में सवालों के जवाब देता है। HLD तैयार करने के लिए पहले स्पष्ट SRS चाहिए।

विस्तृत सॉफ़्टवेयर डिज़ाइन

विस्तृत डिज़ाइन या निम्न स्तरीय डिज़ाइन (LLD) में HLD को छोटे हिस्सों में बाँटा जाता है। प्रोग्राम का विनिर्देश बनाने वाले तर्क को इसमें दर्ज किया जाता है। यह सिस्टम की विस्तृत जानकारी देता है और इसके लिए HLD तैयार होना ज़रूरी है।

सॉफ़्टवेयर डिज़ाइन के तरीके

डिज़ाइन के लिए इनमें से कोई एक तरीका अपनाया जा सकता है:

• ऊपर से नीचे का डिज़ाइन
• नीचे से ऊपर का डिज़ाइन

ऊपर से नीचे का डिज़ाइन तरीका

ऊपर से नीचे के डिज़ाइन में पहले पूरे सिस्टम की रूपरेखा बनती है। उपप्रणालियों का विवरण बाद में तय होता है। हर उपप्रणाली को क्रमशः और विस्तार से परिभाषित करें, जब तक आप बुनियादी घटकों तक न पहुँच जाएँ।

नीचे से ऊपर का डिज़ाइन तरीका

नीचे से ऊपर का डिज़ाइन पूरी तरह परिभाषित बुनियादी घटकों से शुरू होता है। उन्हें जोड़कर उपप्रणालियाँ बनाएँ, फिर उपप्रणालियों को जोड़कर पूरा सिस्टम तैयार करें। इसे ऐसे समझें जैसे आप एक बीज बोते हैं और वह धीरे-धीरे पेड़ बनता है।