एसडीएलसी - त्वरित गाइड
सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल (SDLC) सॉफ्टवेयर उद्योग द्वारा उच्च गुणवत्ता वाले सॉफ्टवेयर्स को डिजाइन, विकसित और परीक्षण करने के लिए उपयोग की जाने वाली प्रक्रिया है। SDLC का उद्देश्य एक उच्च-गुणवत्ता वाला सॉफ़्टवेयर तैयार करना है जो ग्राहकों की अपेक्षाओं को पूरा करता है, समय और लागत अनुमानों को पूरा करता है।
एसडीएलसी सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल का संक्षिप्त नाम है।
इसे सॉफ्टवेयर डेवलपमेंट प्रोसेस भी कहा जाता है।
एसडीएलसी सॉफ्टवेयर विकास प्रक्रिया में प्रत्येक चरण में किए जाने वाले एक कार्य को परिभाषित करने वाला ढांचा है।
ISO / IEC 12207 सॉफ्टवेयर जीवन-चक्र प्रक्रियाओं के लिए एक अंतरराष्ट्रीय मानक है। यह मानक है कि सॉफ्टवेयर को विकसित करने और बनाए रखने के लिए आवश्यक सभी कार्यों को परिभाषित करता है।
एसडीएलसी क्या है?
एसडीएलसी एक सॉफ्टवेयर परियोजना के लिए एक प्रक्रिया है, एक सॉफ्टवेयर संगठन के भीतर। इसमें एक विस्तृत योजना का वर्णन है कि विशिष्ट सॉफ़्टवेयर को कैसे विकसित किया जाए, बनाए रखा जाए, प्रतिस्थापित किया जाए या बदल दिया जाए या बढ़ाया जाए। जीवन चक्र सॉफ्टवेयर की गुणवत्ता और समग्र विकास प्रक्रिया में सुधार के लिए एक पद्धति को परिभाषित करता है।
निम्नलिखित आंकड़ा एक ठेठ एसडीएलसी के विभिन्न चरणों का एक चित्रमय प्रतिनिधित्व है।
एक विशिष्ट सॉफ्टवेयर डेवलपमेंट लाइफ साइकल में निम्न चरण होते हैं -
स्टेज 1: योजना और आवश्यकता विश्लेषण
एसडीएलसी में आवश्यकता विश्लेषण सबसे महत्वपूर्ण और मौलिक चरण है। यह टीम के वरिष्ठ सदस्यों द्वारा ग्राहक, बिक्री विभाग, बाजार सर्वेक्षण और उद्योग में डोमेन विशेषज्ञों के इनपुट के साथ किया जाता है। इस जानकारी का उपयोग तब बुनियादी परियोजना दृष्टिकोण की योजना बनाने और आर्थिक, परिचालन और तकनीकी क्षेत्रों में उत्पाद व्यवहार्यता अध्ययन करने के लिए किया जाता है।
गुणवत्ता आश्वासन आवश्यकताओं और योजना से जुड़े जोखिमों की पहचान की योजना भी योजना के चरण में की जाती है। तकनीकी व्यवहार्यता अध्ययन का परिणाम विभिन्न तकनीकी दृष्टिकोणों को परिभाषित करना है जो न्यूनतम जोखिमों के साथ परियोजना को सफलतापूर्वक लागू करने के लिए अनुसरण किया जा सकता है।
स्टेज 2: आवश्यकताओं को परिभाषित करना
एक बार जब आवश्यकता विश्लेषण किया जाता है, तो अगला कदम उत्पाद की आवश्यकताओं को स्पष्ट रूप से परिभाषित करना और उन्हें ग्राहक या बाजार विश्लेषकों से अनुमोदित कराना होता है। यह एक के माध्यम से किया जाता हैSRS (Software Requirement Specification) दस्तावेज जो परियोजना के जीवन चक्र के दौरान डिजाइन और विकसित करने के लिए सभी उत्पाद आवश्यकताओं से युक्त होता है।
स्टेज 3: प्रोडक्ट आर्किटेक्चर को डिजाइन करना
एसआरएस उत्पाद वास्तुकारों के लिए संदर्भ है कि उत्पाद को विकसित करने के लिए सबसे अच्छी वास्तुकला के साथ बाहर आना चाहिए। एसआरएस में निर्दिष्ट आवश्यकताओं के आधार पर, उत्पाद वास्तुकला के लिए आमतौर पर एक से अधिक डिजाइन दृष्टिकोण प्रस्तावित और एक डीडीएस - डिजाइन दस्तावेज़ संशोधन में प्रलेखित होते हैं।
इस DDS की समीक्षा सभी महत्वपूर्ण हितधारकों द्वारा की जाती है और जोखिम मूल्यांकन, उत्पाद की मजबूती, डिज़ाइन प्रतिरूपता, बजट और समय की कमी के रूप में विभिन्न मापदंडों के आधार पर, उत्पाद के लिए सर्वश्रेष्ठ डिज़ाइन दृष्टिकोण का चयन किया जाता है।
एक डिजाइन दृष्टिकोण स्पष्ट रूप से बाहरी और तीसरे पक्ष के मॉड्यूल (यदि हो तो) के साथ अपने संचार और डेटा प्रवाह प्रतिनिधित्व के साथ उत्पाद के सभी वास्तुशिल्प मॉड्यूल को परिभाषित करता है। प्रस्तावित आर्किटेक्चर के सभी मॉड्यूल के आंतरिक डिजाइन को स्पष्ट रूप से डीडीएस में विवरण के न्यूनतम के साथ परिभाषित किया जाना चाहिए।
स्टेज 4: उत्पाद का निर्माण या विकास
एसडीएलसी के इस चरण में वास्तविक विकास शुरू होता है और उत्पाद बनाया जाता है। इस चरण के दौरान प्रोग्रामिंग कोड DDS के अनुसार उत्पन्न होता है। यदि डिजाइन एक विस्तृत और संगठित तरीके से किया जाता है, तो कोड पीढ़ी को बहुत परेशानी के बिना पूरा किया जा सकता है।
डेवलपर्स को अपने संगठन द्वारा परिभाषित कोडिंग दिशानिर्देशों का पालन करना चाहिए और कोड उत्पन्न करने के लिए कंपाइलर, दुभाषिए, डिबगर आदि जैसे प्रोग्रामिंग टूल का उपयोग किया जाता है। विभिन्न उच्च स्तरीय प्रोग्रामिंग भाषाओं जैसे C, C ++, पास्कल, जावा और PHP का उपयोग कोडिंग के लिए किया जाता है। प्रोग्रामिंग भाषा का विकास सॉफ्टवेयर के प्रकार के संबंध में किया जाता है।
चरण 5: उत्पाद का परीक्षण
यह चरण आमतौर पर आधुनिक एसडीएलसी मॉडल के रूप में सभी चरणों का एक सबसेट है, परीक्षण गतिविधियां ज्यादातर एसडीएलसी के सभी चरणों में शामिल होती हैं। हालाँकि, यह चरण उस उत्पाद के परीक्षण के चरण को संदर्भित करता है, जहाँ उत्पाद दोषों की रिपोर्ट, पता लगाया और तय किया जाता है, जब तक कि उत्पाद SRS में परिभाषित गुणवत्ता मानकों तक नहीं पहुँच जाता।
चरण 6: बाजार और रखरखाव में तैनाती
एक बार उत्पाद का परीक्षण करने और इसे तैनात करने के लिए तैयार होने के बाद इसे उचित बाजार में औपचारिक रूप से जारी किया जाता है। कभी-कभी उत्पाद परिनियोजन उस संगठन की व्यावसायिक रणनीति के अनुसार चरणों में होता है। उत्पाद को पहले एक सीमित खंड में जारी किया जा सकता है और वास्तविक व्यावसायिक वातावरण (UAT- उपयोगकर्ता स्वीकृति परीक्षण) में परीक्षण किया जा सकता है।
फिर फीडबैक के आधार पर, उत्पाद को जारी किया जा सकता है क्योंकि यह लक्षित बाजार क्षेत्र में सुझाए गए संवर्द्धन के साथ है। उत्पाद को बाजार में जारी किए जाने के बाद, इसका रखरखाव मौजूदा ग्राहक आधार के लिए किया जाता है।
SDLC मॉडल
वहाँ विभिन्न सॉफ्टवेयर विकास जीवन चक्र मॉडल परिभाषित और डिज़ाइन किए गए हैं जो सॉफ़्टवेयर विकास प्रक्रिया के दौरान अनुसरण किए जाते हैं। इन मॉडलों को सॉफ्टवेयर डेवलपमेंट प्रोसेस मॉडल के रूप में भी जाना जाता है। "प्रत्येक प्रक्रिया मॉडल सॉफ्टवेयर विकास की प्रक्रिया में सफलता सुनिश्चित करने के लिए अपने प्रकार के लिए अद्वितीय कदमों की एक श्रृंखला का अनुसरण करता है।
उद्योग में निम्नलिखित सबसे महत्वपूर्ण और लोकप्रिय SDLC मॉडल हैं -
- झरना मॉडल
- Iterative मॉडल
- सर्पिल मॉडल
- V-Model
- बिग बैंग मॉडल
अन्य संबंधित कार्यप्रणाली हैं एजाइल मॉडल, आरएडी मॉडल, रैपिड एप्लिकेशन डेवलपमेंट और प्रोटोटाइप मॉडल।
वाटरफॉल मॉडल पेश किया जाने वाला पहला प्रोसेस मॉडल था। यह भी एक के रूप में जाना जाता हैlinear-sequential life cycle model। यह समझना और उपयोग करना बहुत सरल है। एक जलप्रपात के मॉडल में, प्रत्येक चरण को अगले चरण शुरू होने से पहले पूरा किया जाना चाहिए और चरणों में कोई अतिव्यापी नहीं है।
वाटरफॉल मॉडल सबसे शुरुआती एसडीएलसी दृष्टिकोण है जिसका उपयोग सॉफ्टवेयर विकास के लिए किया गया था।
झरना मॉडल एक रैखिक अनुक्रमिक प्रवाह में सॉफ्टवेयर विकास प्रक्रिया को दिखाता है। इसका मतलब यह है कि विकास प्रक्रिया में कोई भी चरण केवल तभी शुरू होता है जब पिछला चरण पूरा होता है। इस झरने के मॉडल में, चरण ओवरलैप नहीं होते हैं।
झरना मॉडल - डिजाइन
प्रोजेक्ट की सफलता सुनिश्चित करने के लिए सॉफ्टवेयर इंजीनियरिंग में व्यापक रूप से एसडीएलसी मॉडल का उपयोग किया गया। "द वॉटरफॉल" दृष्टिकोण में, सॉफ्टवेयर विकास की पूरी प्रक्रिया को अलग-अलग चरणों में विभाजित किया गया है। इस वाटरफॉल मॉडल में, आमतौर पर, एक चरण का परिणाम क्रमिक रूप से अगले चरण के इनपुट के रूप में कार्य करता है।
निम्नलिखित चित्रण झरना मॉडल के विभिन्न चरणों का प्रतिनिधित्व करता है।
झरना मॉडल में अनुक्रमिक चरण हैं -
Requirement Gathering and analysis - विकसित की जाने वाली प्रणाली की सभी संभावित आवश्यकताओं को इस चरण में कैप्चर किया जाता है और एक आवश्यकता विनिर्देश दस्तावेज में दर्ज किया जाता है।
System Design- इस चरण में पहले चरण से आवश्यक विनिर्देशों का अध्ययन किया जाता है और सिस्टम डिज़ाइन तैयार किया जाता है। यह सिस्टम डिज़ाइन हार्डवेयर और सिस्टम आवश्यकताओं को निर्दिष्ट करने में मदद करता है और समग्र सिस्टम आर्किटेक्चर को परिभाषित करने में मदद करता है।
Implementation- सिस्टम डिज़ाइन से इनपुट के साथ, सिस्टम को पहले छोटे कार्यक्रमों में विकसित किया जाता है, जिन्हें यूनिट्स कहा जाता है, जो अगले चरण में एकीकृत होते हैं। प्रत्येक इकाई को उसकी कार्यक्षमता के लिए विकसित और परीक्षण किया जाता है, जिसे इकाई परीक्षण कहा जाता है।
Integration and Testing- कार्यान्वयन चरण में विकसित सभी इकाइयां प्रत्येक इकाई के परीक्षण के बाद एक प्रणाली में एकीकृत होती हैं। किसी भी दोष और असफलता के लिए पूरे एकीकरण के बाद परीक्षण किया जाता है।
Deployment of system- एक बार कार्यात्मक और गैर-कार्यात्मक परीक्षण किया जाता है; उत्पाद ग्राहक के वातावरण में तैनात किया जाता है या बाजार में जारी किया जाता है।
Maintenance- कुछ मुद्दे हैं जो क्लाइंट वातावरण में आते हैं। उन मुद्दों को ठीक करने के लिए, पैच जारी किए जाते हैं। उत्पाद को बढ़ाने के लिए कुछ बेहतर संस्करण भी जारी किए गए हैं। ग्राहक वातावरण में इन परिवर्तनों को वितरित करने के लिए रखरखाव किया जाता है।
इन सभी चरणों को एक दूसरे से कैस्केड किया जाता है जिसमें प्रगति को चरणों के माध्यम से लगातार नीचे की ओर (झरने की तरह) बहते हुए देखा जाता है। अगले चरण को पहले चरण के लिए निर्धारित लक्ष्यों के प्राप्त होने के बाद ही शुरू किया जाता है और इसे बंद कर दिया जाता है, इसलिए इसका नाम "वाटरफॉल मॉडल" है। इस मॉडल में, चरण ओवरलैप नहीं होते हैं।
झरना मॉडल - अनुप्रयोग
विकसित प्रत्येक सॉफ्टवेयर अलग है और आंतरिक और बाहरी कारकों के आधार पर एक उपयुक्त एसडीएलसी दृष्टिकोण की आवश्यकता होती है। कुछ परिस्थितियां जहां जलप्रपात मॉडल का उपयोग सबसे उपयुक्त है -
आवश्यकताएँ बहुत अच्छी तरह से प्रलेखित, स्पष्ट और निश्चित हैं।
उत्पाद की परिभाषा स्थिर है।
प्रौद्योगिकी समझी जाती है और गतिशील नहीं है।
कोई अस्पष्ट आवश्यकताएं नहीं हैं।
उत्पाद का समर्थन करने के लिए आवश्यक विशेषज्ञता वाले पर्याप्त संसाधन उपलब्ध हैं।
प्रोजेक्ट छोटा है।
झरना मॉडल - लाभ
जलप्रपात विकास के लाभ यह है कि यह विभागीयकरण और नियंत्रण की अनुमति देता है। एक शेड्यूल को विकास के प्रत्येक चरण के लिए समय सीमा के साथ सेट किया जा सकता है और एक उत्पाद एक-एक करके विकास प्रक्रिया मॉडल चरणों के माध्यम से आगे बढ़ सकता है।
विकास डिजाइन, कार्यान्वयन, परीक्षण, स्थापना, समस्या निवारण के माध्यम से अवधारणा से चलता है, और संचालन और रखरखाव पर समाप्त होता है। विकास का प्रत्येक चरण सख्त क्रम में आगे बढ़ता है।
जलप्रपात मॉडल के कुछ प्रमुख लाभ इस प्रकार हैं -
सरल और समझने में आसान और उपयोग
मॉडल की कठोरता के कारण प्रबंधन करना आसान है। प्रत्येक चरण में विशिष्ट डिलिवरेबल्स और एक समीक्षा प्रक्रिया होती है।
चरणों को संसाधित और एक समय में पूरा किया जाता है।
छोटी परियोजनाओं के लिए अच्छी तरह से काम करता है जहां आवश्यकताओं को बहुत अच्छी तरह से समझा जाता है।
स्पष्ट रूप से परिभाषित चरणों।
अच्छी तरह से समझा मील के पत्थर।
कार्यों की व्यवस्था करना आसान है।
प्रक्रिया और परिणाम अच्छी तरह से प्रलेखित हैं।
झरना मॉडल - नुकसान
झरना विकास का नुकसान यह है कि यह बहुत अधिक प्रतिबिंब या संशोधन की अनुमति नहीं देता है। एक बार जब कोई एप्लिकेशन परीक्षण के चरण में होता है, तो अवधारणा चरण में अच्छी तरह से प्रलेखित या सोचा गया था कि वापस जाना और कुछ बदलना बहुत मुश्किल है।
जलप्रपात मॉडल के प्रमुख नुकसान इस प्रकार हैं -
जीवन चक्र के दौरान देर तक कोई भी कार्यशील सॉफ्टवेयर तैयार नहीं किया जाता है।
उच्च मात्रा में जोखिम और अनिश्चितता।
जटिल और वस्तु-उन्मुख परियोजनाओं के लिए एक अच्छा मॉडल नहीं है।
लंबी और चालू परियोजनाओं के लिए खराब मॉडल।
उन परियोजनाओं के लिए उपयुक्त नहीं है जहां आवश्यकताओं को बदलने के एक मध्यम से उच्च जोखिम में हैं। इसलिए, इस प्रक्रिया के मॉडल के साथ जोखिम और अनिश्चितता अधिक है।
चरणों के भीतर प्रगति को मापना मुश्किल है।
बदलती आवश्यकताओं को समायोजित नहीं कर सकते।
जीवन चक्र के दौरान गुंजाइश का समायोजन एक परियोजना को समाप्त कर सकता है।
एकीकरण "बिग-बैंग" के रूप में किया जाता है, बहुत अंत में, जो किसी भी तकनीकी या व्यावसायिक अड़चन या चुनौतियों की पहचान करने की अनुमति नहीं देता है।
Iterative मॉडल में, पुनरावृत्त प्रक्रिया सॉफ़्टवेयर आवश्यकताओं के एक छोटे से सेट के सरल कार्यान्वयन के साथ शुरू होती है और जब तक कि पूरी प्रणाली लागू नहीं होती है और तैनात होने के लिए तैयार होती है, तब तक यह क्रमिक रूप से विकसित संस्करणों को बढ़ाती है।
एक पुनरावृत्त जीवन चक्र मॉडल आवश्यकताओं के पूर्ण विनिर्देश के साथ शुरू करने का प्रयास नहीं करता है। इसके बजाय, सॉफ़्टवेयर के केवल भाग को निर्दिष्ट और कार्यान्वित करके विकास शुरू होता है, जिसे फिर आगे की आवश्यकताओं की पहचान करने के लिए समीक्षा की जाती है। यह प्रक्रिया तब दोहराई जाती है, जो मॉडल के प्रत्येक पुनरावृत्ति के अंत में सॉफ़्टवेयर के एक नए संस्करण का निर्माण करती है।
Iterative मॉडल - डिज़ाइन
Iterative प्रक्रिया सॉफ्टवेयर आवश्यकताओं के सबसेट के एक सरल कार्यान्वयन के साथ शुरू होती है और जब तक पूरा सिस्टम लागू नहीं होता है, तब तक यह लगातार बढ़ते संस्करणों को बढ़ाता है। प्रत्येक पुनरावृत्ति पर, डिज़ाइन संशोधन किए जाते हैं और नई कार्यात्मक क्षमताएं जोड़ी जाती हैं। इस पद्धति के पीछे मूल विचार एक चक्र (पुनरावृत्ति) के माध्यम से और एक समय (वृद्धिशील) में छोटे भागों में एक प्रणाली विकसित करना है।
निम्नलिखित उदाहरण Iterative और Incremental मॉडल का प्रतिनिधित्व है -
Iterative और Incremental डेवलपमेंट, iterative design या iterative method और incremental build model दोनों का संयोजन है। "सॉफ़्टवेयर विकास के दौरान, एक ही समय में सॉफ़्टवेयर विकास चक्र का एक से अधिक चलना प्रगति पर हो सकता है।" इस प्रक्रिया को "विकासवादी अधिग्रहण" या "वृद्धिशील निर्माण" दृष्टिकोण के रूप में वर्णित किया जा सकता है।
इस वृद्धिशील मॉडल में, पूरी आवश्यकता को विभिन्न बिल्ड में विभाजित किया गया है। प्रत्येक पुनरावृत्ति के दौरान, विकास मॉड्यूल आवश्यकताओं, डिजाइन, कार्यान्वयन और परीक्षण चरणों से गुजरता है। मॉड्यूल के प्रत्येक बाद के रिलीज पिछले रिलीज के लिए फ़ंक्शन जोड़ता है। जब तक आवश्यकता के अनुसार पूरा सिस्टम तैयार नहीं हो जाता तब तक प्रक्रिया जारी रहती है।
पुनरावृत्त सॉफ्टवेयर विकास जीवनचक्र के सफल उपयोग की कुंजी आवश्यकताओं की कठोर मान्यता है, और मॉडल के प्रत्येक चक्र के भीतर उन आवश्यकताओं के खिलाफ सॉफ्टवेयर के प्रत्येक संस्करण का सत्यापन और परीक्षण। जैसा कि सॉफ्टवेयर लगातार चक्रों के माध्यम से विकसित होता है, सॉफ्टवेयर के प्रत्येक संस्करण को सत्यापित करने के लिए परीक्षणों को दोहराया और बढ़ाया जाना चाहिए।
Iterative मॉडल - आवेदन
अन्य एसडीएलसी मॉडल की तरह, Iterative और वृद्धिशील विकास सॉफ्टवेयर उद्योग में कुछ विशिष्ट अनुप्रयोग हैं। इस मॉडल का उपयोग अक्सर निम्न परिदृश्यों में किया जाता है -
पूर्ण प्रणाली की आवश्यकताओं को स्पष्ट रूप से परिभाषित और समझा जाता है।
प्रमुख आवश्यकताओं को परिभाषित किया जाना चाहिए; हालाँकि, कुछ कार्यशीलता या अनुरोधित संवर्द्धन समय के साथ विकसित हो सकते हैं।
बाजार की बाधा का समय है।
एक नई तकनीक का उपयोग किया जा रहा है और परियोजना पर काम करते समय विकास टीम द्वारा सीखा जा रहा है।
आवश्यक कौशल सेट वाले संसाधन उपलब्ध नहीं हैं और विशिष्ट पुनरावृत्तियों के लिए अनुबंध के आधार पर उपयोग किए जाने की योजना है।
कुछ उच्च जोखिम वाली विशेषताएं और लक्ष्य हैं जो भविष्य में बदल सकते हैं।
Iterative मॉडल - पेशेवरों और विपक्ष
इस मॉडल का लाभ यह है कि विकास के एक बहुत ही प्रारंभिक चरण में सिस्टम का एक कामकाजी मॉडल है, जो कार्यात्मक या डिज़ाइन दोषों को ढूंढना आसान बनाता है। विकास के प्रारंभिक चरण में मुद्दों को खोजना सीमित बजट में सुधारात्मक उपाय करने में सक्षम बनाता है।
इस एसडीएलसी मॉडल के साथ नुकसान यह है कि यह केवल बड़े और भारी सॉफ्टवेयर विकास परियोजनाओं पर लागू होता है। ऐसा इसलिए है क्योंकि एक छोटे से सॉफ्टवेयर सिस्टम को आगे छोटे सर्विसिंग इन्क्रीमेंट्स / मॉड्यूल में तोड़ना मुश्किल है।
Iterative और Incremental SDLC Model के फायदे इस प्रकार हैं -
कुछ कामकाजी कार्यक्षमता को जीवन चक्र में जल्दी और जल्दी विकसित किया जा सकता है।
परिणाम जल्दी और समय-समय पर प्राप्त होते हैं।
समानांतर विकास की योजना बनाई जा सकती है।
प्रगति को मापा जा सकता है।
गुंजाइश / आवश्यकताओं को बदलने के लिए कम खर्चीला।
छोटे पुनरावृत्ति के दौरान परीक्षण और डिबगिंग आसान है।
जोखिम की पहचान और हल के दौरान हल किया जाता है; और प्रत्येक पुनरावृत्ति एक आसानी से प्रबंधित मील का पत्थर है।
जोखिम प्रबंधन में आसान - उच्च जोखिम वाला हिस्सा पहले किया जाता है।
हर वेतन वृद्धि के साथ परिचालन उत्पाद दिया जाता है।
प्रत्येक वेतन वृद्धि से पहचाने गए मुद्दों, चुनौतियों और जोखिमों को अगले वेतन वृद्धि के लिए उपयोग / लागू किया जा सकता है।
जोखिम विश्लेषण बेहतर है।
यह बदलती आवश्यकताओं का समर्थन करता है।
प्रारंभिक परिचालन समय कम है।
बड़ी और मिशन-महत्वपूर्ण परियोजनाओं के लिए बेहतर अनुकूल।
जीवन चक्र के दौरान, सॉफ्टवेयर का निर्माण जल्दी किया जाता है जो ग्राहक मूल्यांकन और प्रतिक्रिया की सुविधा देता है।
Iterative और Incremental SDLC मॉडल के नुकसान इस प्रकार हैं -
अधिक संसाधनों की आवश्यकता हो सकती है।
हालांकि परिवर्तन की लागत कम है, लेकिन यह बदलती आवश्यकताओं के लिए बहुत उपयुक्त नहीं है।
अधिक प्रबंधन ध्यान देने की आवश्यकता है।
सिस्टम आर्किटेक्चर या डिज़ाइन के मुद्दे उत्पन्न हो सकते हैं क्योंकि पूरे जीवन चक्र की शुरुआत में सभी आवश्यकताओं को इकट्ठा नहीं किया जाता है।
वेतन वृद्धि को पूर्ण प्रणाली की परिभाषा की आवश्यकता हो सकती है।
छोटी परियोजनाओं के लिए उपयुक्त नहीं है।
प्रबंधन की जटिलता अधिक है।
परियोजना का अंत ज्ञात नहीं हो सकता है जो एक जोखिम है।
जोखिम विश्लेषण के लिए अत्यधिक कुशल संसाधनों की आवश्यकता होती है।
प्रोजेक्ट्स की प्रगति जोखिम विश्लेषण चरण पर अत्यधिक निर्भर है।
सर्पिल मॉडल झरना मॉडल के व्यवस्थित, नियंत्रित पहलुओं के साथ पुनरावृत्ति विकास के विचार को जोड़ता है। यह सर्पिल मॉडल पुनरावृत्ति विकास प्रक्रिया मॉडल और अनुक्रमिक रैखिक विकास मॉडल अर्थात झरना मॉडल का एक संयोजन है जो जोखिम विश्लेषण पर बहुत अधिक जोर देता है। यह सर्पिल के चारों ओर प्रत्येक पुनरावृत्ति के माध्यम से उत्पाद के वृद्धिशील रिलीज या वृद्धिशील शोधन की अनुमति देता है।
सर्पिल मॉडल - डिजाइन
सर्पिल मॉडल के चार चरण होते हैं। एक सॉफ्टवेयर प्रोजेक्ट बार-बार स्पैरल्स नामक पुनरावृत्तियों में इन चरणों से गुजरता है।
पहचान
यह चरण आधारभूत सर्पिल में व्यावसायिक आवश्यकताओं को इकट्ठा करने के साथ शुरू होता है। उत्पाद के परिपक्व होने के बाद के सर्पिलों में, सिस्टम आवश्यकताओं, सबसिस्टम आवश्यकताओं और इकाई आवश्यकताओं की पहचान इस चरण में की जाती है।
इस चरण में ग्राहक और सिस्टम विश्लेषक के बीच निरंतर संचार द्वारा सिस्टम की आवश्यकताओं को समझना भी शामिल है। सर्पिल के अंत में, उत्पाद को चिह्नित बाजार में तैनात किया जाता है।
डिज़ाइन
डिजाइन चरण बेसलाइन सर्पिल में वैचारिक डिजाइन के साथ शुरू होता है और इसमें वास्तुशिल्प डिजाइन, मॉड्यूल के तार्किक डिजाइन, भौतिक उत्पाद डिजाइन और बाद के सर्पिल में अंतिम डिजाइन शामिल होता है।
निर्माण या निर्माण
निर्माण चरण में प्रत्येक सर्पिल में वास्तविक सॉफ्टवेयर उत्पाद का उत्पादन होता है। बेसलाइन सर्पिल में, जब उत्पाद के बारे में सिर्फ सोचा जाता है और डिजाइन विकसित किया जा रहा है तो ग्राहक प्रतिक्रिया प्राप्त करने के लिए इस चरण में एक POC (अवधारणा का सबूत) विकसित किया जाता है।
फिर आवश्यकताओं और डिजाइन विवरण पर उच्च स्पष्टता के साथ बाद के सर्पिलों में सॉफ्टवेयर के एक कामकाजी मॉडल का निर्माण किया जाता है जिसे संस्करण संख्या के साथ निर्मित किया जाता है। ये बिल्ड ग्राहक के पास प्रतिक्रिया के लिए भेजे जाते हैं।
मूल्यांकन और जोखिम विश्लेषण
जोखिम विश्लेषण में तकनीकी संभाव्यता और प्रबंधन जोखिमों की पहचान करना, आकलन करना और निगरानी करना शामिल है, जैसे कि शेड्यूल स्लिपेज और कॉस्ट ओवररन। बिल्ड का परीक्षण करने के बाद, पहले पुनरावृत्ति के अंत में, ग्राहक सॉफ़्टवेयर का मूल्यांकन करता है और प्रतिक्रिया प्रदान करता है।
निम्नलिखित उदाहरण सर्पिल मॉडल का प्रतिनिधित्व है, प्रत्येक चरण में गतिविधियों को सूचीबद्ध करता है।
ग्राहक मूल्यांकन के आधार पर, सॉफ्टवेयर विकास प्रक्रिया अगली पुनरावृत्ति में प्रवेश करती है और बाद में ग्राहक द्वारा सुझाई गई प्रतिक्रिया को लागू करने के लिए रैखिक दृष्टिकोण का अनुसरण करती है। सर्पिल के साथ पुनरावृत्तियों की प्रक्रिया सॉफ्टवेयर के पूरे जीवन में जारी है।
सर्पिल मॉडल अनुप्रयोग
सर्पिल मॉडल का उपयोग सॉफ्टवेयर उद्योग में व्यापक रूप से किया जाता है क्योंकि यह किसी भी उत्पाद की प्राकृतिक विकास प्रक्रिया के साथ तालमेल करता है, अर्थात परिपक्वता के साथ सीखना जिसमें ग्राहक के साथ-साथ विकास फर्मों के लिए न्यूनतम जोखिम शामिल होता है।
निम्नलिखित बिंदु एक सर्पिल मॉडल के विशिष्ट उपयोगों की व्याख्या करते हैं -
जब एक बजट बाधा होती है और जोखिम मूल्यांकन महत्वपूर्ण होता है।
मध्यम से उच्च जोखिम वाली परियोजनाओं के लिए।
समय के साथ आवश्यकताओं में बदलाव के रूप में आर्थिक प्राथमिकताओं में संभावित परिवर्तन के कारण दीर्घकालिक परियोजना प्रतिबद्धता।
ग्राहक उनकी आवश्यकताओं के बारे में सुनिश्चित नहीं है, जो आमतौर पर मामला है।
आवश्यकताएँ जटिल हैं और स्पष्टता प्राप्त करने के लिए मूल्यांकन की आवश्यकता है।
नई उत्पाद लाइन जिसे ग्राहकों की पर्याप्त प्रतिक्रिया प्राप्त करने के लिए चरणों में जारी किया जाना चाहिए।
विकास चक्र के दौरान उत्पाद में महत्वपूर्ण परिवर्तन अपेक्षित हैं।
सर्पिल मॉडल - पेशेवरों और विपक्ष
सर्पिल जीवनचक्र मॉडल का लाभ यह है कि यह उत्पाद के तत्वों को जोड़ने की अनुमति देता है, जब वे उपलब्ध या ज्ञात हो जाते हैं। यह आश्वासन देता है कि पिछली आवश्यकताओं और डिजाइन के साथ कोई संघर्ष नहीं है।
यह विधि उन दृष्टिकोणों के अनुरूप है जिनमें एकाधिक सॉफ़्टवेयर बिल्ड और रिलीज़ होते हैं जो रखरखाव गतिविधि को एक व्यवस्थित परिवर्तन करने की अनुमति देता है। इस पद्धति का एक और सकारात्मक पहलू यह है कि सर्पिल मॉडल प्रणाली के विकास के प्रयास में एक प्रारंभिक उपयोगकर्ता की भागीदारी को मजबूर करता है।
दूसरी तरफ, ऐसे उत्पादों को पूरा करने के लिए बहुत सख्त प्रबंधन होता है और अनिश्चित लूप में सर्पिल को चलाने का जोखिम होता है। इसलिए, परिवर्तन का अनुशासन और परिवर्तन अनुरोधों को लेने के लिए उत्पाद को सफलतापूर्वक विकसित करने और तैनात करने के लिए बहुत महत्वपूर्ण है।
सर्पिल एसडीएलसी मॉडल के फायदे इस प्रकार हैं -
बदलती आवश्यकताओं को समायोजित किया जा सकता है।
प्रोटोटाइप के व्यापक उपयोग की अनुमति देता है।
आवश्यकताओं को अधिक सटीक रूप से कैप्चर किया जा सकता है।
उपयोगकर्ता सिस्टम को जल्दी देखते हैं।
विकास को छोटे भागों में विभाजित किया जा सकता है और जोखिम भरे भागों को पहले विकसित किया जा सकता है जो बेहतर जोखिम प्रबंधन में मदद करता है।
सर्पिल एसडीएलसी मॉडल के नुकसान इस प्रकार हैं -
प्रबंधन अधिक जटिल है।
परियोजना का अंत जल्दी ज्ञात नहीं हो सकता है।
छोटी या कम जोखिम वाली परियोजनाओं के लिए उपयुक्त नहीं है और छोटी परियोजनाओं के लिए महंगी हो सकती है।
प्रक्रिया जटिल है
सर्पिल अनिश्चित काल तक चल सकता है।
बड़ी संख्या में मध्यवर्ती चरणों में अत्यधिक प्रलेखन की आवश्यकता होती है।
वी-मॉडल एक एसडीएलसी मॉडल है जहां प्रक्रियाओं का निष्पादन वी-आकार में क्रमबद्ध तरीके से होता है। इसे के रूप में भी जाना जाता हैVerification and Validation model।
वी-मॉडल झरना मॉडल का एक विस्तार है और प्रत्येक संबंधित विकास चरण के लिए परीक्षण चरण के सहयोग पर आधारित है। इसका मतलब यह है कि विकास चक्र में हर एक चरण के लिए, सीधे जुड़ा हुआ परीक्षण चरण होता है। यह एक उच्च-अनुशासित मॉडल है और अगला चरण पिछले चरण के पूरा होने के बाद ही शुरू होता है।
वी-मॉडल - डिज़ाइन
वी-मॉडल के तहत, विकास चरण के संबंधित परीक्षण चरण को समानांतर में योजनाबद्ध किया गया है। तो, 'V' के एक तरफ वेरिफिकेशन चरण हैं और दूसरी तरफ Validation चरणों हैं। कोडिंग चरण वी-मॉडल के दोनों किनारों से जुड़ता है।
निम्नलिखित चित्रण एसडीएलसी के वी-मॉडल में विभिन्न चरणों को दर्शाते हैं।
वी-मॉडल - सत्यापन चरण
वी-मॉडल में कई सत्यापन चरण हैं, इनमें से प्रत्येक को नीचे विस्तार से बताया गया है।
व्यावसायिक आवश्यकता विश्लेषण
यह विकास चक्र का पहला चरण है जहां उत्पाद की आवश्यकताओं को ग्राहक के दृष्टिकोण से समझा जाता है। इस चरण में ग्राहक के साथ उसकी अपेक्षाओं और सटीक आवश्यकता को समझने के लिए विस्तृत संचार शामिल है। यह एक बहुत ही महत्वपूर्ण गतिविधि है और इसे अच्छी तरह से प्रबंधित करने की आवश्यकता है, क्योंकि अधिकांश ग्राहक इस बारे में निश्चित नहीं हैं कि उन्हें वास्तव में क्या चाहिए। acceptance test design planning इस स्तर पर किया जाता है क्योंकि व्यावसायिक आवश्यकताओं को स्वीकृति परीक्षण के लिए एक इनपुट के रूप में उपयोग किया जा सकता है।
प्रणाली की रूपरेखा
एक बार जब आपके पास स्पष्ट और विस्तृत उत्पाद आवश्यकताएं होती हैं, तो यह पूरी प्रणाली को डिजाइन करने का समय है। सिस्टम डिज़ाइन में विकास के तहत उत्पाद के लिए संपूर्ण हार्डवेयर और संचार सेटअप की समझ और विवरण होगा। सिस्टम टेस्ट प्लान सिस्टम डिजाइन के आधार पर विकसित किया जाता है। पहले चरण में ऐसा करने से वास्तविक परीक्षण निष्पादन के लिए अधिक समय निकल जाता है।
वास्तुशिल्प डिजाइन
इस चरण में वास्तुकला संबंधी विशिष्टताओं को समझा और डिजाइन किया गया है। आमतौर पर एक से अधिक तकनीकी दृष्टिकोण प्रस्तावित होते हैं और तकनीकी और वित्तीय व्यवहार्यता के आधार पर अंतिम निर्णय लिया जाता है। अलग-अलग कार्यक्षमता लेने वाले मॉड्यूल में आगे सिस्टम डिज़ाइन टूट गया है। यह भी कहा जाता हैHigh Level Design (HLD)।
आंतरिक मॉड्यूल और बाहरी दुनिया (अन्य सिस्टम) के बीच डेटा ट्रांसफर और संचार इस चरण में स्पष्ट रूप से समझा और परिभाषित किया गया है। इस जानकारी के साथ, एकीकरण परीक्षण को इस चरण के दौरान डिज़ाइन और प्रलेखित किया जा सकता है।
मॉड्यूल डिजाइन
इस चरण में, सभी सिस्टम मॉड्यूल के लिए विस्तृत आंतरिक डिज़ाइन निर्दिष्ट किया गया है Low Level Design (LLD)। यह महत्वपूर्ण है कि डिजाइन सिस्टम आर्किटेक्चर में अन्य मॉड्यूल और अन्य बाहरी सिस्टम के साथ संगत है। इकाई परीक्षण किसी भी विकास प्रक्रिया का एक अनिवार्य हिस्सा हैं और बहुत प्रारंभिक चरण में अधिकतम दोष और त्रुटियों को खत्म करने में मदद करता है। इन यूनिट परीक्षणों को आंतरिक मॉड्यूल डिजाइनों के आधार पर इस स्तर पर डिज़ाइन किया जा सकता है।
कोडिंग चरण
डिज़ाइन चरण में डिज़ाइन किए गए सिस्टम मॉड्यूल का वास्तविक कोडिंग कोडिंग चरण में लिया जाता है। सबसे उपयुक्त प्रोग्रामिंग भाषा का निर्णय सिस्टम और वास्तु संबंधी आवश्यकताओं के आधार पर किया जाता है।
कोडिंग दिशानिर्देशों और मानकों के आधार पर कोडिंग की जाती है। कोड कई कोड समीक्षाओं के माध्यम से जाता है और अंतिम निर्माण से पहले रिपॉजिटरी में जांचने से पहले सर्वश्रेष्ठ प्रदर्शन के लिए अनुकूलित किया जाता है।
मान्यता चरण
एक वी-मॉडल में विभिन्न मान्यता चरणों के बारे में नीचे विस्तार से बताया गया है।
इकाई का परीक्षण
मॉड्यूल डिजाइन चरण में डिज़ाइन किए गए यूनिट परीक्षण इस सत्यापन चरण के दौरान कोड पर निष्पादित किए जाते हैं। यूनिट परीक्षण कोड स्तर पर परीक्षण है और एक प्रारंभिक चरण में कीड़े को खत्म करने में मदद करता है, हालांकि सभी दोषों को इकाई परीक्षण द्वारा उजागर नहीं किया जा सकता है।
एकीकरण जांच
एकीकरण परीक्षण वास्तुकला डिजाइन चरण के साथ जुड़ा हुआ है। सिस्टम के भीतर आंतरिक मॉड्यूल के सह-अस्तित्व और संचार का परीक्षण करने के लिए एकीकरण परीक्षण किए जाते हैं।
सिस्टम परीक्षण
सिस्टम परीक्षण सीधे सिस्टम डिजाइन चरण के साथ जुड़ा हुआ है। सिस्टम परीक्षण बाहरी सिस्टम के साथ विकास के तहत पूरे सिस्टम की कार्यक्षमता और सिस्टम के संचार की जांच करते हैं। इस प्रणाली के परीक्षण निष्पादन के दौरान अधिकांश सॉफ्टवेयर और हार्डवेयर संगतता मुद्दों को उजागर किया जा सकता है।
स्वीकृति परीक्षण
स्वीकृति परीक्षण व्यवसाय की आवश्यकता विश्लेषण चरण से जुड़ा है और इसमें उपयोगकर्ता पर्यावरण में उत्पाद का परीक्षण शामिल है। स्वीकृति परीक्षण उपयोगकर्ता वातावरण में उपलब्ध अन्य प्रणालियों के साथ संगतता मुद्दों को उजागर करते हैं। यह वास्तविक उपयोगकर्ता वातावरण में लोड और प्रदर्शन दोष जैसे गैर-कार्यात्मक मुद्दों को भी बताता है।
V- मॉडल ─ आवेदन
V- मॉडल एप्लिकेशन वाटरफॉल मॉडल के लगभग समान है, क्योंकि दोनों मॉडल अनुक्रमिक प्रकार के हैं। परियोजना शुरू होने से पहले आवश्यकताएँ बहुत स्पष्ट होनी चाहिए, क्योंकि आमतौर पर वापस जाना और बदलाव करना महंगा है। यह मॉडल चिकित्सा विकास क्षेत्र में उपयोग किया जाता है, क्योंकि यह कड़ाई से एक अनुशासित डोमेन है।
वी-मॉडल एप्लिकेशन का उपयोग करने के लिए निम्नलिखित संकेत कुछ सबसे उपयुक्त परिदृश्य हैं।
आवश्यकताओं को अच्छी तरह से परिभाषित किया गया है, स्पष्ट रूप से प्रलेखित और तय किया गया है।
उत्पाद की परिभाषा स्थिर है।
प्रौद्योगिकी गतिशील नहीं है और परियोजना टीम द्वारा अच्छी तरह से समझा जाता है।
अस्पष्ट या अपरिभाषित आवश्यकताएं नहीं हैं।
प्रोजेक्ट छोटा है।
वी-मॉडल - पेशेवरों और विपक्ष
वी-मॉडल विधि का लाभ यह है कि इसे समझना और लागू करना बहुत आसान है। इस मॉडल की सादगी भी इसे प्रबंधित करना आसान बनाती है। नुकसान यह है कि मॉडल परिवर्तनों के लिए लचीला नहीं है और बस मामले में आवश्यकता परिवर्तन है, जो आज की गतिशील दुनिया में बहुत आम है, परिवर्तन करना बहुत महंगा हो जाता है।
वी-मॉडल विधि के फायदे इस प्रकार हैं -
यह एक उच्च-अनुशासित मॉडल है और चरणों को एक बार में पूरा किया जाता है।
छोटी परियोजनाओं के लिए अच्छी तरह से काम करता है जहां आवश्यकताओं को बहुत अच्छी तरह से समझा जाता है।
सरल और समझने में आसान और उपयोग।
मॉडल की कठोरता के कारण प्रबंधन करना आसान है। प्रत्येक चरण में विशिष्ट डिलिवरेबल्स और एक समीक्षा प्रक्रिया होती है।
V- मॉडल विधि के नुकसान इस प्रकार हैं -
उच्च जोखिम और अनिश्चितता।
जटिल और वस्तु-उन्मुख परियोजनाओं के लिए एक अच्छा मॉडल नहीं है।
लंबी और चालू परियोजनाओं के लिए खराब मॉडल।
उन परियोजनाओं के लिए उपयुक्त नहीं है जहां आवश्यकताओं को बदलने के एक मध्यम से उच्च जोखिम में हैं।
एक बार जब कोई एप्लिकेशन परीक्षण चरण में होता है, तो वापस जाना और कार्यक्षमता बदलना मुश्किल होता है।
जीवन चक्र के दौरान देर तक कोई भी कार्यशील सॉफ्टवेयर तैयार नहीं किया जाता है।
बिग बैंग मॉडल एक एसडीएलसी मॉडल है जहां हम किसी विशिष्ट प्रक्रिया का पालन नहीं करते हैं। विकास केवल आवश्यक धन और प्रयासों के साथ इनपुट के रूप में शुरू होता है, और आउटपुट विकसित सॉफ्टवेयर है जो ग्राहक की आवश्यकता के अनुसार हो सकता है या नहीं। यह बिग बैंग मॉडल किसी प्रक्रिया / प्रक्रिया का पालन नहीं करता है और इसके लिए बहुत कम योजना की आवश्यकता होती है। यहां तक कि ग्राहक भी निश्चित नहीं है कि वह वास्तव में क्या चाहता है और आवश्यकताओं को बहुत विश्लेषण के बिना मक्खी पर लागू किया जाता है।
आमतौर पर इस मॉडल का पालन छोटी परियोजनाओं के लिए किया जाता है जहां विकास दल बहुत छोटे होते हैं।
बिग बैंग मॉडल Bang डिजाइन और अनुप्रयोग
बिग बैंग मॉडल में सॉफ्टवेयर विकास और कोडिंग में सभी संभावित संसाधनों पर ध्यान केंद्रित करना शामिल है, जिसमें बहुत कम या कोई योजना नहीं है। आवश्यकताओं को समझा और लागू किया जाता है जैसे वे आते हैं। किसी भी परिवर्तन की आवश्यकता हो सकती है या पूरा सॉफ्टवेयर सुधारने की आवश्यकता नहीं हो सकती है।
यह मॉडल एक या दो डेवलपर्स के साथ मिलकर काम करने वाली छोटी परियोजनाओं के लिए आदर्श है और शैक्षणिक या अभ्यास परियोजनाओं के लिए भी उपयोगी है। यह उत्पाद के लिए एक आदर्श मॉडल है जहां आवश्यकताओं को अच्छी तरह से समझा नहीं जाता है और अंतिम रिलीज की तारीख नहीं दी जाती है।
बिग बैंग मॉडल - पेशेवरों और विपक्ष
इस बिग बैंग मॉडल का लाभ यह है कि यह बहुत सरल है और इसके लिए बहुत कम या कोई योजना नहीं है। प्रबंधन में आसान और कोई औपचारिक प्रक्रिया की आवश्यकता नहीं है।
हालांकि, बिग बैंग मॉडल एक बहुत ही उच्च जोखिम वाला मॉडल है और आवश्यकताओं में बदलाव या गलतफहमी आवश्यकताओं को भी परियोजना के पूर्ण उलट या स्क्रैपिंग का कारण हो सकता है। यह न्यूनतम जोखिम वाले दोहराव या छोटी परियोजनाओं के लिए आदर्श है।
बिग बैंग मॉडल के फायदे इस प्रकार हैं -
यह एक बहुत ही सरल मॉडल है
कम या कोई योजना की आवश्यकता नहीं है
प्रबंधन में आसान
बहुत कम संसाधनों की आवश्यकता है
डेवलपर्स को लचीलापन देता है
यह नए कामर्स या छात्रों के लिए एक अच्छी शिक्षा सहायता है।
बिग बैंग मॉडल के नुकसान इस प्रकार हैं -
बहुत उच्च जोखिम और अनिश्चितता।
जटिल और वस्तु-उन्मुख परियोजनाओं के लिए एक अच्छा मॉडल नहीं है।
लंबी और चालू परियोजनाओं के लिए खराब मॉडल।
आवश्यकताओं को गलत समझा जाता है तो बहुत महंगा हो सकता है।
एजाइल एसडीएलसी मॉडल कार्यशील सॉफ्टवेयर उत्पाद के तेजी से वितरण द्वारा प्रक्रिया अनुकूलनशीलता और ग्राहक संतुष्टि पर ध्यान देने के साथ पुनरावृत्त और वृद्धिशील प्रक्रिया मॉडल का एक संयोजन है। चंचल तरीके उत्पाद को छोटे वृद्धिशील बिल्ड में तोड़ते हैं। इन बिल्डरों को पुनरावृत्तियों में प्रदान किया गया है। प्रत्येक पुनरावृत्ति आमतौर पर लगभग एक से तीन सप्ताह तक रहती है। प्रत्येक पुनरावृत्ति में विभिन्न क्षेत्रों पर एक साथ काम करने वाली क्रॉस फंक्शनल टीमें शामिल हैं -
- Planning
- आवश्यकताओं के विश्लेषण
- Design
- Coding
- यूनिट परीक्षण और
- स्वीकृति परीक्षण।
पुनरावृत्ति के अंत में, एक कार्यशील उत्पाद ग्राहक और महत्वपूर्ण हितधारकों को प्रदर्शित किया जाता है।
चंचल क्या है?
चंचल मॉडल का मानना है कि हर परियोजना को अलग तरीके से संभालने की जरूरत है और मौजूदा तरीकों को परियोजना की आवश्यकताओं के अनुरूप सबसे अच्छा करने की आवश्यकता है। एजाइल में, रिलीज़ के लिए विशिष्ट सुविधाएं देने के लिए कार्यों को टाइम बॉक्स (छोटे समय के फ्रेम) में विभाजित किया जाता है।
Iterative दृष्टिकोण लिया जाता है और प्रत्येक पुनरावृत्ति के बाद काम करने वाले सॉफ्टवेयर का निर्माण किया जाता है। प्रत्येक बिल्ड सुविधाओं के मामले में वृद्धिशील है; अंतिम बिल्ड ग्राहक द्वारा आवश्यक सभी सुविधाओं को रखता है।
यहाँ चंचल मॉडल का चित्रमय चित्रण है -
चंचल विचार प्रक्रिया सॉफ्टवेयर विकास में जल्दी शुरू हो गई थी और अपने लचीलेपन और अनुकूलनशीलता के कारण समय के साथ लोकप्रिय होने लगी थी।
सबसे लोकप्रिय चुस्त तरीकों में तर्कसंगत एकीकृत प्रक्रिया (1994), स्क्रैम (1995), क्रिस्टल क्लियर, एक्सट्रीम प्रोग्रामिंग (1996), अनुकूली सॉफ्टवेयर डेवलपमेंट, फ़ीचर ड्रिवेन डेवलपमेंट, और डायनामिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम) (1995) शामिल हैं। इन्हें अब सामूहिक रूप से संदर्भित किया जाता हैAgile Methodologies, एजिले मेनिफेस्टो 2001 में प्रकाशित हुआ था।
चंचल घोषणापत्र सिद्धांत निम्नलिखित हैं -
Individuals and interactions - फुर्तीली विकास में, आत्म-संगठन और प्रेरणा महत्वपूर्ण हैं, क्योंकि सह-स्थान और जोड़ी प्रोग्रामिंग जैसी बातचीत हैं।
Working software - डेमो वर्किंग सॉफ्टवेयर को ग्राहकों के साथ उनकी आवश्यकताओं को समझने के लिए संचार का सबसे अच्छा साधन माना जाता है, बजाय इसके कि केवल दस्तावेज के आधार पर।
Customer collaboration - चूंकि विभिन्न कारकों के कारण परियोजना की शुरुआत में आवश्यकताओं को पूरी तरह से इकट्ठा नहीं किया जा सकता है, उचित उत्पाद आवश्यकताओं को प्राप्त करने के लिए निरंतर ग्राहक सहभागिता बहुत महत्वपूर्ण है।
Responding to change - चंचल विकास परिवर्तन और निरंतर विकास के लिए त्वरित प्रतिक्रियाओं पर केंद्रित है।
चंचल बनाम पारंपरिक एसडीएलसी मॉडल
चंचलता पर आधारित है adaptive software development methods, जबकि पारंपरिक एसडीएलसी मॉडल जैसे झरना मॉडल एक भविष्य कहनेवाला दृष्टिकोण पर आधारित है। पारंपरिक एसडीएलसी मॉडल में भविष्यवाणिय दल आमतौर पर विस्तृत योजना के साथ काम करते हैं और अगले कुछ महीनों में या उत्पाद जीवन चक्र के दौरान दिए जाने वाले सटीक कार्यों और सुविधाओं का पूरा पूर्वानुमान रखते हैं।
भविष्यवाणी के तरीके पूरी तरह से पर निर्भर करते हैं requirement analysis and planningचक्र की शुरुआत में किया। शामिल किए जाने वाले किसी भी परिवर्तन को सख्त बदलाव नियंत्रण प्रबंधन और प्राथमिकता के माध्यम से जाना जाता है।
चंचल एक का उपयोग करता है adaptive approachजहाँ कोई विस्तृत योजना नहीं है और भविष्य में कार्यों पर स्पष्टता है कि किन विशेषताओं को विकसित करने की आवश्यकता है। वहाँ सुविधा संचालित विकास है और टीम गतिशील रूप से बदलती उत्पाद आवश्यकताओं के लिए अनुकूल है। उत्पाद को बहुत बार परीक्षण किया जाता है, रिलीज पुनरावृत्तियों के माध्यम से भविष्य में किसी भी बड़ी असफलता के जोखिम को कम करता है।
Customer Interactionइस चंचल कार्यप्रणाली की रीढ़ है, और न्यूनतम प्रलेखन के साथ खुला संचार चंचल विकास पर्यावरण की विशिष्ट विशेषताएं हैं। फुर्तीली टीमें एक दूसरे के साथ घनिष्ठ सहयोग में काम करती हैं और अक्सर एक ही भौगोलिक स्थिति में स्थित होती हैं।
चंचल मॉडल - पेशेवरों और विपक्ष
हाल ही में सॉफ्टवेयर की दुनिया में चंचल तरीकों को व्यापक रूप से स्वीकार किया जा रहा है। हालांकि, यह विधि हमेशा सभी उत्पादों के लिए उपयुक्त नहीं हो सकती है। यहां एजाइल मॉडल के कुछ पेशेवरों और विपक्ष हैं।
एजाइल मॉडल के फायदे इस प्रकार हैं -
सॉफ्टवेयर विकास के लिए एक बहुत यथार्थवादी दृष्टिकोण है।
टीम वर्क और क्रॉस ट्रेनिंग को बढ़ावा देता है।
कार्यक्षमता को तेजी से विकसित और प्रदर्शित किया जा सकता है।
संसाधन की आवश्यकताएं न्यूनतम हैं।
निश्चित या बदलती आवश्यकताओं के लिए उपयुक्त है
शुरुआती आंशिक कार्य समाधानों को वितरित करता है।
पर्यावरण के लिए अच्छा मॉडल जो लगातार बदलता रहता है।
न्यूनतम नियम, प्रलेखन आसानी से नियोजित।
एक समग्र नियोजित संदर्भ में समवर्ती विकास और वितरण को सक्षम करता है।
कम या कोई योजना की आवश्यकता नहीं है।
प्रबंधन में आसान।
डेवलपर्स को लचीलापन देता है।
एजाइल मॉडल के नुकसान इस प्रकार हैं -
जटिल निर्भरता से निपटने के लिए उपयुक्त नहीं है।
स्थिरता, स्थिरता और व्यापकता का अधिक जोखिम।
एक समग्र योजना, एक फुर्तीले नेता और चुस्त पीएम अभ्यास एक जरूरी है जिसके बिना यह काम नहीं करेगा।
सख्त वितरण प्रबंधन कार्यक्षेत्र, समयबद्धता को पूरा करने के लिए कार्यकुशलता, सुपुर्दगी और समायोजन को निर्धारित करता है।
ग्राहक संपर्क पर बहुत अधिक निर्भर करता है, इसलिए यदि ग्राहक स्पष्ट नहीं है, तो टीम को गलत दिशा में चलाया जा सकता है।
वहाँ एक बहुत ही उच्च व्यक्तिगत निर्भरता है, क्योंकि न्यूनतम दस्तावेज उत्पन्न होता है।
नई टीम के सदस्यों को प्रौद्योगिकी का हस्तांतरण प्रलेखन की कमी के कारण काफी चुनौतीपूर्ण हो सकता है।
RAD (Rapid Application Development)मॉडल प्रोटोटाइपिंग और पुनरावृत्त विकास पर आधारित है जिसमें कोई विशिष्ट योजना शामिल नहीं है। सॉफ्टवेयर लिखने की प्रक्रिया में उत्पाद को विकसित करने के लिए आवश्यक योजना शामिल है।
रैपिड एप्लिकेशन डेवलपमेंट कार्यशालाओं या फ़ोकस समूहों के माध्यम से ग्राहकों की आवश्यकताओं को इकट्ठा करने पर केंद्रित है, पुनरावृत्त अवधारणा का उपयोग करके ग्राहक द्वारा प्रोटोटाइप का प्रारंभिक परीक्षण, मौजूदा प्रोटोटाइप (घटकों) का पुन: उपयोग, निरंतर एकीकरण और तेजी से वितरण।
राड क्या है?
रैपिड एप्लिकेशन डेवलपमेंट एक सॉफ्टवेयर डेवलपमेंट मेथोडोलॉजी है जो रैपिड प्रोटोटाइप के पक्ष में न्यूनतम नियोजन का उपयोग करता है। एक प्रोटोटाइप एक कामकाजी मॉडल है जो कार्यात्मक रूप से उत्पाद के एक घटक के बराबर है।
आरएडी मॉडल में, कार्यात्मक मॉड्यूल को प्रोटोटाइप के रूप में समानांतर में विकसित किया जाता है और तेजी से उत्पाद वितरण के लिए पूर्ण उत्पाद बनाने के लिए एकीकृत किया जाता है। चूंकि कोई विस्तृत प्रीप्लेनिंग नहीं है, इसलिए विकास प्रक्रिया के भीतर परिवर्तनों को शामिल करना आसान हो जाता है।
आरएडी परियोजनाएं पुनरावृत्त और वृद्धिशील मॉडल का पालन करती हैं और इसमें छोटे दल होते हैं जिनमें डेवलपर्स, डोमेन विशेषज्ञ, ग्राहक प्रतिनिधि और उनके घटक या प्रोटोटाइप पर उत्तरोत्तर काम करने वाले अन्य आईटी संसाधन शामिल होते हैं।
इस मॉडल के सफल होने के लिए सबसे महत्वपूर्ण पहलू यह सुनिश्चित करना है कि विकसित किए गए प्रोटोटाइप पुन: प्रयोज्य हैं।
राड मॉडल डिजाइन
रेड मॉडल लघु, पुनरावृत्त विकास चक्रों की श्रृंखला में विश्लेषण, डिजाइन, निर्माण और परीक्षण वितरित करता है।
राड मॉडल के विभिन्न चरण निम्नलिखित हैं -
बिजनेस मॉडलिंग
विकास के तहत उत्पाद के लिए व्यवसाय मॉडल को सूचना के प्रवाह और विभिन्न व्यावसायिक चैनलों के बीच सूचना के वितरण के संदर्भ में डिज़ाइन किया गया है। व्यवसाय के लिए महत्वपूर्ण जानकारी प्राप्त करने के लिए, यह कैसे प्राप्त किया जा सकता है, कैसे और कब संसाधित की गई जानकारी है और जानकारी के सफल प्रवाह को चलाने वाले कारक क्या हैं, इसके बारे में जानने के लिए एक संपूर्ण व्यावसायिक विश्लेषण किया जाता है।
डेटा मॉडलिंग
बिजनेस मॉडलिंग चरण में एकत्र की गई जानकारी की समीक्षा की जाती है और व्यापार के लिए महत्वपूर्ण डेटा ऑब्जेक्ट के सेट बनाने के लिए विश्लेषण किया जाता है। सभी डेटा सेट की विशेषताओं को पहचाना और परिभाषित किया गया है। इन डेटा ऑब्जेक्ट्स के बीच का संबंध व्यवसाय मॉडल की प्रासंगिकता में विस्तार से स्थापित और परिभाषित किया गया है।
प्रक्रिया मॉडलिंग
डेटा मॉडलिंग चरण में परिभाषित डेटा ऑब्जेक्ट सेट को व्यवसाय मॉडल के अनुसार विशिष्ट व्यावसायिक उद्देश्यों को प्राप्त करने के लिए आवश्यक व्यावसायिक सूचना प्रवाह को स्थापित करने के लिए परिवर्तित किया जाता है। डेटा ऑब्जेक्ट सेट में किसी भी परिवर्तन या वृद्धि के लिए प्रक्रिया मॉडल इस चरण में परिभाषित किया गया है। डेटा ऑब्जेक्ट को जोड़ने, हटाने, पुनर्प्राप्त करने या संशोधित करने के लिए प्रक्रिया विवरण दिए गए हैं।
अनुप्रयोग पीढ़ी
वास्तविक प्रणाली को बनाया गया है और प्रक्रिया और डेटा मॉडल को वास्तविक प्रोटोटाइप में बदलने के लिए स्वचालन उपकरणों का उपयोग करके कोडिंग की जाती है।
परीक्षण और कारोबार
आरएडी मॉडल में समग्र परीक्षण समय कम हो जाता है क्योंकि प्रोटोटाइप को हर पुनरावृत्ति के दौरान स्वतंत्र रूप से परीक्षण किया जाता है। हालांकि, सभी घटकों के बीच डेटा प्रवाह और इंटरफेस को पूरी तरह से परीक्षण कवरेज के साथ अच्छी तरह से जांचने की आवश्यकता है। चूंकि अधिकांश प्रोग्रामिंग घटकों का परीक्षण पहले ही किया जा चुका है, इसलिए यह किसी भी प्रमुख मुद्दों के जोखिम को कम करता है।
निम्नलिखित उदाहरण राड मॉडल के बारे में विस्तार से बताते हैं।
राड मॉडल बनाम पारंपरिक एसडीएलसी
पारंपरिक एसडीएलसी आवश्यकता विश्लेषण और कोडिंग शुरू होने से पहले एकत्रित होने पर अधिक जोर देने के साथ एक कठोर प्रक्रिया मॉडल का पालन करता है। यह परियोजना शुरू होने से पहले आवश्यकताओं पर हस्ताक्षर करने के लिए ग्राहक पर दबाव डालता है और ग्राहक को उत्पाद की अनुभूति नहीं होती है क्योंकि लंबे समय तक कोई कार्य निर्माण उपलब्ध नहीं है।
सॉफ्टवेयर को देखने के लिए ग्राहक को कुछ परिवर्तनों की आवश्यकता हो सकती है। हालांकि, परिवर्तन प्रक्रिया काफी कठोर है और पारंपरिक एसडीएलसी में उत्पाद में बड़े बदलावों को शामिल करना संभव नहीं है।
आरएडी मॉडल ग्राहक को काम करने वाले मॉडल के पुनरावृत्त और वृद्धिशील वितरण पर केंद्रित है। यह उत्पाद के पूर्ण विकास चक्र के दौरान ग्राहक और ग्राहक की भागीदारी के लिए तेजी से वितरण के परिणामस्वरूप वास्तविक उपयोगकर्ता आवश्यकताओं के साथ गैर-अनुरूपता के जोखिम को कम करता है।
राड मॉडल - अनुप्रयोग
रेड मॉडल को उन परियोजनाओं के लिए सफलतापूर्वक लागू किया जा सकता है जिनमें स्पष्ट रूप से संशोधन संभव है। यदि परियोजना मॉड्यूल में नहीं तोड़ी जा सकती है, तो RAD विफल हो सकता है।
निम्नलिखित संकेत उन विशिष्ट परिदृश्यों का वर्णन करते हैं जहां आरएडी का उपयोग किया जा सकता है -
राड का उपयोग केवल तब किया जाना चाहिए जब एक प्रणाली को वृद्धिशील तरीके से वितरित करने के लिए संशोधित किया जा सकता है।
यदि मॉडलिंग के लिए डिजाइनरों की अधिक उपलब्धता है तो इसका उपयोग किया जाना चाहिए।
इसका उपयोग केवल तभी किया जाना चाहिए जब बजट स्वचालित कोड जनरेटिंग टूल के उपयोग की अनुमति देता है।
राड एसडीएलसी मॉडल को केवल तभी चुना जाना चाहिए जब डोमेन विशेषज्ञ प्रासंगिक व्यावसायिक ज्ञान के साथ उपलब्ध हों।
उपयोग किया जाना चाहिए जहां परियोजना के दौरान आवश्यकताओं में परिवर्तन होता है और 2-3 महीनों के छोटे पुनरावृत्तियों में ग्राहक को प्रस्तुत करना होता है।
राड मॉडल - पेशेवरों और विपक्ष
राड मॉडल तेजी से वितरण को सक्षम करता है क्योंकि यह घटकों के पुन: प्रयोज्य और समानांतर विकास के कारण समग्र विकास समय को कम करता है। राड तभी अच्छा काम करता है जब उच्च कुशल इंजीनियर उपलब्ध हों और ग्राहक निर्धारित समय सीमा में लक्षित प्रोटोटाइप प्राप्त करने के लिए भी प्रतिबद्ध हो। अगर दोनों तरफ प्रतिबद्धता की कमी है तो मॉडल विफल हो सकता है।
राड मॉडल के फायदे इस प्रकार हैं -
बदलती आवश्यकताओं को समायोजित किया जा सकता है।
प्रगति को मापा जा सकता है।
शक्तिशाली आरएडी उपकरणों के उपयोग के साथ Iteration का समय कम हो सकता है।
थोड़े समय में कम लोगों के साथ उत्पादकता।
विकास का समय कम कर दिया।
घटकों की पुन: प्रयोज्यता बढ़ाता है।
त्वरित प्रारंभिक समीक्षाएं होती हैं।
ग्राहकों की प्रतिक्रिया को प्रोत्साहित करता है।
बहुत शुरुआत से एकीकरण एकीकरण मुद्दों का एक बहुत हल करती है।
राड मॉडल के नुकसान इस प्रकार हैं -
व्यावसायिक आवश्यकताओं की पहचान के लिए तकनीकी रूप से मजबूत टीम के सदस्यों पर निर्भरता।
केवल सिस्टम जिसे मॉड्यूलर किया जा सकता है वह आरएडी का उपयोग करके बनाया जा सकता है।
अत्यधिक कुशल डेवलपर्स / डिजाइनरों की आवश्यकता है।
मॉडलिंग कौशल पर अत्यधिक निर्भरता।
मॉडलिंग और स्वचालित कोड पीढ़ी की लागत के रूप में सस्ती परियोजनाओं के लिए अनुपयुक्त बहुत अधिक है।
प्रबंधन की जटिलता अधिक है।
उन प्रणालियों के लिए उपयुक्त है जो घटक आधारित और स्केलेबल हैं।
पूरे जीवन चक्र में उपयोगकर्ता की भागीदारी की आवश्यकता है।
छोटे विकास के समय की आवश्यकता वाले प्रोजेक्ट के लिए उपयुक्त है।
सॉफ़्टवेयर प्रोटोटाइप सॉफ़्टवेयर अनुप्रयोग प्रोटोटाइप के निर्माण को संदर्भित करता है जो विकास के तहत उत्पाद की कार्यक्षमता को प्रदर्शित करता है, लेकिन वास्तव में मूल सॉफ़्टवेयर के सटीक तर्क को पकड़ नहीं सकता है।
सॉफ्टवेयर प्रोटोटाइप एक सॉफ्टवेयर विकास मॉडल के रूप में बहुत लोकप्रिय हो रहा है, क्योंकि यह विकास के प्रारंभिक चरण में ग्राहकों की आवश्यकताओं को समझने में सक्षम बनाता है। यह ग्राहक से मूल्यवान प्रतिक्रिया प्राप्त करने में मदद करता है और सॉफ्टवेयर डिजाइनरों और डेवलपर्स को यह समझने में मदद करता है कि विकास के तहत उत्पाद से वास्तव में क्या उम्मीद की जाती है।
सॉफ्टवेयर प्रोटोटाइप क्या है?
प्रोटोटाइप कुछ सीमित कार्यक्षमता के साथ सॉफ्टवेयर का एक कामकाजी मॉडल है। प्रोटोटाइप हमेशा वास्तविक सॉफ़्टवेयर एप्लिकेशन में उपयोग किए जाने वाले सटीक तर्क को नहीं रखता है और प्रयास अनुमान के तहत विचार किए जाने के लिए एक अतिरिक्त प्रयास है।
प्रोटोटाइप का उपयोग उपयोगकर्ताओं को डेवलपर प्रस्तावों का मूल्यांकन करने और कार्यान्वयन से पहले उन्हें आज़माने के लिए किया जाता है। यह उन आवश्यकताओं को समझने में भी मदद करता है जो उपयोगकर्ता विशिष्ट हैं और उत्पाद डिजाइन के दौरान डेवलपर द्वारा विचार नहीं किया जा सकता है।
सॉफ़्टवेयर प्रोटोटाइप को डिज़ाइन करने के लिए समझाया गया स्टेप वाइज दृष्टिकोण निम्नलिखित है।
मूल आवश्यकता की पहचान
इस कदम में विशेष रूप से उपयोगकर्ता इंटरफ़ेस के संदर्भ में बहुत मूल उत्पाद आवश्यकताओं को समझना शामिल है। आंतरिक डिजाइन और प्रदर्शन और सुरक्षा जैसे बाहरी पहलुओं के अधिक जटिल विवरणों को इस स्तर पर अनदेखा किया जा सकता है।
प्रारंभिक प्रोटोटाइप का विकास करना
इस चरण में प्रारंभिक प्रोटोटाइप विकसित किया जाता है, जहां बहुत ही बुनियादी आवश्यकताओं को प्रदर्शित किया जाता है और उपयोगकर्ता इंटरफेस प्रदान किए जाते हैं। हो सकता है कि ये सुविधाएँ विकसित वास्तविक सॉफ़्टवेयर में आंतरिक रूप से ठीक उसी तरह से काम न करें। जबकि, विकसित स्वरूप में ग्राहक को समान रूप देने और महसूस करने के लिए वर्कअराउंड का उपयोग किया जाता है।
प्रोटोटाइप की समीक्षा
तब विकसित किए गए प्रोटोटाइप को ग्राहक और परियोजना के अन्य महत्वपूर्ण हितधारकों के सामने प्रस्तुत किया जाता है। प्रतिक्रिया को एक संगठित तरीके से एकत्र किया जाता है और विकास के तहत उत्पाद में और वृद्धि के लिए उपयोग किया जाता है।
प्रोटोटाइप को संशोधित और उन्नत करें
इस चरण के दौरान प्रतिक्रिया और समीक्षा टिप्पणियों पर चर्चा की जाती है और कुछ बातचीत ग्राहक के साथ होती हैं जैसे - समय और बजट की कमी और वास्तविक कार्यान्वयन की तकनीकी व्यवहार्यता। स्वीकार किए गए परिवर्तनों को फिर से विकसित किए गए नए प्रोटोटाइप में शामिल किया गया है और ग्राहक की अपेक्षाओं को पूरा करने तक यह चक्र दोहराता है।
प्रोटोटाइप में क्षैतिज या ऊर्ध्वाधर आयाम हो सकते हैं। एक क्षैतिज प्रोटोटाइप उत्पाद के लिए उपयोगकर्ता इंटरफ़ेस प्रदर्शित करता है और आंतरिक कार्यों पर ध्यान केंद्रित किए बिना पूरे सिस्टम का एक व्यापक दृश्य देता है। दूसरी तरफ एक ऊर्ध्वाधर प्रोटोटाइप उत्पाद में एक विशिष्ट फ़ंक्शन या उप प्रणाली का एक विस्तृत विस्तार है।
दोनों क्षैतिज और ऊर्ध्वाधर प्रोटोटाइप का उद्देश्य अलग है। उपयोगकर्ता इंटरफ़ेस स्तर और व्यावसायिक आवश्यकताओं के बारे में अधिक जानकारी प्राप्त करने के लिए क्षैतिज प्रोटोटाइप का उपयोग किया जाता है। यह भी बाजार में व्यापार पाने के लिए बिक्री डेमो में प्रस्तुत किया जा सकता है। ऊर्ध्वाधर प्रोटोटाइप प्रकृति में तकनीकी हैं और उप प्रणालियों के सटीक कामकाज का विवरण प्राप्त करने के लिए उपयोग किया जाता है। उदाहरण के लिए, डेटाबेस की आवश्यकताएं, दिए गए उप सिस्टम में इंटरैक्शन और डेटा प्रोसेसिंग लोड।
सॉफ्टवेयर प्रोटोटाइप - प्रकार
उद्योग में विभिन्न प्रकार के सॉफ़्टवेयर प्रोटोटाइप का उपयोग किया जाता है। निम्नलिखित प्रमुख सॉफ्टवेयर प्रोटोटाइप प्रकार व्यापक रूप से उपयोग किए जाते हैं -
थ्रोवावे / रैपिड प्रोटोटाइप
थ्रोवावे प्रोटोटाइपिंग को रैपिड या क्लोज एंडेड प्रोटोटाइपिंग भी कहा जाता है। इस प्रकार का प्रोटोटाइप एक प्रोटोटाइप बनाने के लिए न्यूनतम आवश्यकता विश्लेषण के साथ बहुत कम प्रयासों का उपयोग करता है। एक बार वास्तविक आवश्यकताओं को समझने के बाद, प्रोटोटाइप को छोड़ दिया जाता है और वास्तविक सिस्टम को उपयोगकर्ता की आवश्यकताओं की बहुत स्पष्ट समझ के साथ विकसित किया जाता है।
विकासवादी प्रोटोटाइप
विकासवादी प्रोटोटाइप को ब्रेडबोर्ड प्रोटोटाइप भी कहा जाता है जो शुरुआत में न्यूनतम कार्यक्षमता के साथ वास्तविक कार्यात्मक प्रोटोटाइप बनाने पर आधारित है। विकसित किए गए प्रोटोटाइप भविष्य के प्रोटोटाइप का दिल बनाते हैं, जिसके ऊपर पूरी प्रणाली का निर्माण किया जाता है। विकासवादी प्रोटोटाइप का उपयोग करके, अच्छी तरह से समझी जाने वाली आवश्यकताओं को प्रोटोटाइप में शामिल किया जाता है और आवश्यकताओं को तब जोड़ा जाता है जब उन्हें समझा जाता है।
वृद्धिशील प्रोटोटाइप
वृद्धिशील प्रोटोटाइप विभिन्न उप-प्रणालियों के कई कार्यात्मक प्रोटोटाइप के निर्माण को संदर्भित करता है और फिर एक संपूर्ण प्रणाली बनाने के लिए सभी उपलब्ध प्रोटोटाइप को एकीकृत करता है।
चरम प्रोटोटाइप
वेब विकास डोमेन में चरम प्रोटोटाइप का उपयोग किया जाता है। इसमें तीन क्रमिक चरण होते हैं। सबसे पहले, सभी मौजूदा पृष्ठों के साथ एक मूल प्रोटोटाइप HTML प्रारूप में प्रस्तुत किया गया है। फिर एक प्रोटोटाइप सेवाओं की परत का उपयोग करके डेटा प्रोसेसिंग को सिम्युलेटेड किया जाता है। अंत में, सेवाओं को अंतिम प्रोटोटाइप में लागू और एकीकृत किया जाता है। इस प्रक्रिया को चरम प्रोटोटाइप कहा जाता है जिसका उपयोग प्रक्रिया के दूसरे चरण पर ध्यान आकर्षित करने के लिए किया जाता है, जहां वास्तविक सेवाओं के संबंध में पूरी तरह कार्यात्मक यूआई बहुत कम विकसित होता है।
सॉफ्टवेयर प्रोटोटाइप - अनुप्रयोग
सॉफ्टवेयर प्रोटोटाइप सिस्टम के विकास में सबसे उपयोगी है जिसमें ऑनलाइन सिस्टम जैसे उच्च स्तर के उपयोगकर्ता इंटरैक्शन होते हैं। जिन प्रणालियों को उपयोगकर्ताओं को फ़ॉर्म भरने या डेटा को संसाधित करने से पहले विभिन्न स्क्रीन के माध्यम से जाने की आवश्यकता होती है, वे वास्तविक सॉफ़्टवेयर विकसित होने से पहले ही सटीक रूप देने और महसूस करने के लिए बहुत प्रभावी ढंग से प्रोटोटाइप का उपयोग कर सकते हैं।
सॉफ्टवेयर जिसमें बहुत अधिक डेटा प्रोसेसिंग शामिल है और अधिकांश कार्यक्षमता बहुत कम उपयोगकर्ता इंटरफ़ेस के साथ आंतरिक है आमतौर पर प्रोटोटाइप से लाभ नहीं होता है। इस तरह की परियोजनाओं में प्रोटोटाइप विकास एक अतिरिक्त ओवरहेड हो सकता है और अतिरिक्त प्रयासों की बहुत आवश्यकता हो सकती है।
सॉफ्टवेयर प्रोटोटाइप - पेशेवरों और विपक्ष
सॉफ़्टवेयर प्रोटोटाइप का उपयोग विशिष्ट मामलों में किया जाता है और निर्णय को बहुत सावधानी से लिया जाना चाहिए ताकि प्रोटोटाइप के निर्माण में खर्च किए गए प्रयासों को विकसित किए गए अंतिम सॉफ़्टवेयर में काफी मूल्य मिल जाए। मॉडल का अपना नियम और विपक्ष है जो निम्नानुसार चर्चा करता है।
प्रोटोटाइपिंग मॉडल के फायदे इस प्रकार हैं -
इसके कार्यान्वयन से पहले ही उत्पाद में उपयोगकर्ता की भागीदारी बढ़ जाती है।
चूंकि सिस्टम का एक कार्यशील मॉडल प्रदर्शित किया जाता है, इसलिए उपयोगकर्ता सिस्टम के विकसित होने की बेहतर समझ प्राप्त करते हैं।
समय और लागत कम कर देता है क्योंकि दोष बहुत पहले पता लगाया जा सकता है।
त्वरित उपयोगकर्ता प्रतिक्रिया बेहतर समाधान के लिए उपलब्ध है।
गुम कार्यक्षमता को आसानी से पहचाना जा सकता है।
भ्रमित या कठिन कार्यों की पहचान की जा सकती है।
प्रोटोटाइपिंग मॉडल के नुकसान इस प्रकार हैं -
प्रोटोटाइप पर बहुत अधिक निर्भरता के कारण अपर्याप्त आवश्यकता विश्लेषण का जोखिम।
उपयोगकर्ता प्रोटोटाइप और वास्तविक सिस्टम में भ्रमित हो सकते हैं।
व्यावहारिक रूप से, यह कार्यप्रणाली प्रणाली की जटिलता को बढ़ा सकती है क्योंकि मूल योजनाओं से परे प्रणाली का दायरा बढ़ सकता है।
डेवलपर्स मौजूदा प्रोटोटाइप को फिर से उपयोग करने की कोशिश कर सकते हैं, वास्तविक प्रणाली के निर्माण के लिए, तब भी जब यह तकनीकी रूप से संभव नहीं है।
प्रोटोटाइप के निर्माण में निवेश किया गया प्रयास बहुत अधिक हो सकता है अगर इसकी सही निगरानी न की जाए।