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

विषय - सूची:

Anonim

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

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

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

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

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

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

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

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

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

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