एसडीएलसी में वृद्धिशील मॉडल: उपयोग, लाभ और हानि

वृद्धिशील मॉडल क्या है?

इंक्रीमेंटल मॉडल सॉफ्टवेयर विकास की एक प्रक्रिया है जहाँ आवश्यकताओं को सॉफ्टवेयर विकास चक्र के कई स्टैंडअलोन मॉड्यूल में विभाजित किया जाता है। इंक्रीमेंटल विकास विश्लेषण डिजाइन, कार्यान्वयन, परीक्षण/सत्यापन, रखरखाव से चरणों में किया जाता है।

SDLC में वृद्धिशील मॉडल

प्रत्येक पुनरावृति निम्न से होकर गुजरती है आवश्यकताएँ, डिज़ाइन, कोडिंग और परीक्षण चरणऔर सिस्टम का प्रत्येक आगामी रिलीज पिछले रिलीज में फ़ंक्शन जोड़ता है जब तक कि सभी डिज़ाइन की गई कार्यक्षमता को लागू नहीं किया जाता है।

SDLC में वृद्धिशील मॉडल

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

वृद्धिशील मॉड्यूल की विशेषताओं में शामिल हैं

  • सिस्टम विकास को कई लघु विकास परियोजनाओं में विभाजित किया गया है
  • अंतिम कुल प्रणाली का निर्माण करने के लिए आंशिक प्रणालियों का क्रमिक रूप से निर्माण किया जाता है
  • सर्वोच्च प्राथमिकता वाली आवश्यकता को पहले निपटाया जाता है
  • एक बार आवश्यकता विकसित हो जाने पर, उस वेतन वृद्धि की आवश्यकता स्थिर हो जाती है
वृद्धिशील चरण वृद्धिशील चरणों में की गई गतिविधियाँ
आवश्यकता विश्लेषण
  • सॉफ्टवेयर की आवश्यकता और विनिर्देश एकत्र किए जाते हैं
डिज़ाइन
  • इस चरण के दौरान कुछ उच्च-स्तरीय फ़ंक्शन डिज़ाइन किए गए हैं
Code
  • इस चरण के दौरान सॉफ्टवेयर की कोडिंग की जाती है
टेस्ट
  • एक बार सिस्टम स्थापित हो जाने के बाद, यह परीक्षण चरण से गुजरता है

वृद्धिशील मॉडल का उपयोग कब करें?

  • सिस्टम की आवश्यकताओं को स्पष्ट रूप से समझा गया है
  • जब किसी उत्पाद को शीघ्र जारी करने की मांग उठती है
  • . सॉफ्टवेयर इंजीनियरिंग टीम बहुत कुशल या प्रशिक्षित नहीं है
  • जब उच्च जोखिम वाली विशेषताएं और लक्ष्य शामिल हों
  • ऐसी कार्यप्रणाली वेब एप्लिकेशन और उत्पाद आधारित कंपनियों के लिए अधिक उपयोग में है

वृद्धिशील मॉडल के लाभ और नुकसान

फायदे नुकसान
सॉफ्टवेयर जीवन चक्र के दौरान सॉफ्टवेयर शीघ्रता से तैयार किया जाएगा इसके लिए एक अच्छी योजना और डिजाइन की आवश्यकता होती है
यह लचीला है और आवश्यकताओं और दायरे को बदलना कम खर्चीला है सिस्टम आर्किटेक्चर के कारण समस्याएँ उत्पन्न हो सकती हैं, जैसे कि संपूर्ण सॉफ़्टवेयर जीवनचक्र के लिए सभी आवश्यकताओं को पहले से एकत्रित नहीं किया गया हो
विकास के विभिन्न चरणों में परिवर्तन किए जा सकते हैं प्रत्येक पुनरावृत्ति चरण कठोर है और एक दूसरे को ओवरलैप नहीं करता है
यह मॉडल अन्य की तुलना में कम खर्चीला है एक इकाई में किसी समस्या को ठीक करने के लिए सभी इकाइयों में सुधार की आवश्यकता होती है और इसमें बहुत समय लगता है
एक ग्राहक प्रत्येक इमारत पर प्रतिक्रिया दे सकता है
त्रुटियों की पहचान करना आसान है

इस पोस्ट को संक्षेप में इस प्रकार लिखें: