अनुकूली एस / डब्ल्यू विकास - त्वरित गाइड

चंचल क्या है?

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

सॉफ्टवेयर विकास में, "फुर्तीली" शब्द का अर्थ "परिवर्तन करने के लिए प्रतिक्रिया करने की क्षमता - आवश्यकताओं, प्रौद्योगिकी और लोगों से परिवर्तन" करने के लिए किया जाता है।

चंचल मेनिफेस्टो

एजाइल मेनिफेस्टो को 2001 में सॉफ्टवेयर डेवलपर्स की एक टीम द्वारा प्रकाशित किया गया था, जिसमें विकास की टीम के महत्व पर प्रकाश डाला गया, बदलती आवश्यकताओं और ग्राहक भागीदारी को शामिल किया गया।

चंचल घोषणापत्र है -

हम सॉफ्टवेयर के विकास के बेहतर तरीकों को उजागर कर रहे हैं और इसे करने में दूसरों की मदद कर रहे हैं। इस काम के माध्यम से, हम मूल्य पर आए हैं -

• व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत।
• व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर।
• अनुबंध बातचीत पर ग्राहक सहयोग।
• एक योजना के बाद बदलने के लिए प्रतिक्रिया।

यही है, जबकि दाईं ओर की वस्तुओं में मूल्य है, हम बाईं ओर की वस्तुओं को अधिक महत्व देते हैं।

चपलता के लक्षण

चपलता के लक्षण निम्नलिखित हैं -

• एजाइल सॉफ्टवेयर डेवलपमेंट में चपलता मल्टी-डिसिप्लिन, क्रॉस-फंक्शनल टीमों के साथ पूरी टीम की संस्कृति पर ध्यान केंद्रित करती है जो सशक्त और आत्मनिर्भर होती हैं।

• इसने जिम्मेदारी और जवाबदेही को बढ़ावा दिया।

• प्रभावी संचार और निरंतर सहयोग की सुविधा देता है।

• पूरी टीम दृष्टिकोण देरी से बचने और समय का इंतजार करती है।

• बार-बार और निरंतर प्रसव त्वरित प्रतिक्रिया सुनिश्चित करते हैं जो बदले में टीम को आवश्यकताओं के साथ संरेखित करने में सक्षम बनाते हैं।

• सहयोग कार्यान्वयन, दोष को ठीक करने और परिवर्तनों को समायोजित करने में विभिन्न दृष्टिकोणों को समय पर संयोजित करने की सुविधा प्रदान करता है।

• प्रगति निरंतर, स्थायी, और पूर्वानुमेयता है जो पारदर्शिता पर जोर देती है।

चंचल तरीके

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

इस ट्यूटोरियल में, हम फुर्तीली कार्यप्रणाली सीखेंगे - Adaptive Software Development।

अनुकूली सॉफ्टवेयर डेवलपमेंट क्या है?

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

जिम हाईस्मिथ ने 2000 में एडाप्टिव सॉफ्टवेयर डेवलपमेंट पर एक किताब प्रकाशित की। हाईस्मिथ के शब्दों में -

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

एक सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल (एसडीएलसी) मॉडल एक ढांचा है जो एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट के प्रत्येक चरण में की गई गतिविधियों का वर्णन करता है।

एक सॉफ्टवेयर डेवलपमेंट लाइफ साइकल में, गतिविधियों को पाँच चरणों में किया जाता है -

• Requirements Gathering- विकसित किए जाने वाले सॉफ़्टवेयर के लिए आवश्यकताएँ एकत्रित की जाती हैं। ये आवश्यकताएं उस भाषा में होंगी जिसे ग्राहक / उपयोगकर्ता द्वारा समझा जाता है। डोमेन विशिष्ट शब्दावली की सिफारिश की जाती है।

• Analysis - एकत्रित आवश्यकताओं को कार्यान्वयन के दृष्टिकोण से विश्लेषण किया जाता है और सॉफ्टवेयर विनिर्देशों को कार्यात्मक आवश्यकताओं और गैर-कार्यात्मक आवश्यकताओं दोनों को कवर करने के लिए लिखा जाता है।

• Design - इस चरण में विकास के लिए चुनी गई प्रौद्योगिकी के आधार पर सॉफ्टवेयर आर्किटेक्चर और कार्यान्वयन बारीकियों का आगमन शामिल है।

• Construction - इस चरण में, कोड विकसित, इकाई परीक्षण, एकीकृत, एकीकरण परीक्षण और निर्माण का उत्पादन किया जाता है।

• Testing- इस चरण में निर्मित सॉफ्टवेयर का कार्यात्मक परीक्षण किया जाता है। इसमें गैर-कार्यात्मक आवश्यकताओं का परीक्षण भी शामिल है।

इन गतिविधियों को करने के लिए दो दृष्टिकोण हैं -

• Prescriptive - एसडीएलसी मॉडल जो आपको फ्रेमवर्क द्वारा परिभाषित गतिविधियों को निर्धारित तरीके से करने के तरीके प्रदान करेगा।

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

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

जब आप अपनी परियोजना के लिए एक SDLC मॉडल चुनते हैं, तो आपको समझने की आवश्यकता है -

• आपका संगठन संदर्भ
• आपकी प्रौद्योगिकी संदर्भ
• आपकी टीम रचना
• आपका ग्राहक संदर्भ

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

निम्नलिखित अनुभागों में, आप सबसे अधिक प्रचलित SDLC मॉडल को समझेंगे जो उद्योग भर में सॉफ्टवेयर विकास परियोजनाओं के निष्पादन के दौरान विकसित हुए हैं। आपको उनमें से प्रत्येक की ताकत और कमजोरियों का भी पता चल जाएगा और वे किस संदर्भ में उपयुक्त हैं।

वाटरफॉल मॉडल एक क्लासिक एसडीएलसी मॉडल है जो व्यापक रूप से जाना जाता है, समझा जाता है और आमतौर पर उपयोग किया जाता है। यह रॉयस द्वारा 1970 में शुरू किया गया था और अभी भी उद्योग भर के विभिन्न संगठनों में सॉफ्टवेयर विकास के लिए एक आम दृष्टिकोण के रूप में पालन किया जा रहा है।

वॉटरफॉल मॉडल में, प्रत्येक जीवनचक्र चरण केवल पहले के जीवन चक्र चरण पूरा होने के बाद ही शुरू हो सकता है। इस प्रकार, यह एक रैखिक मॉडल है जिसमें कोई प्रतिक्रिया नहीं होती है।

झरना मॉडल - ताकत

झरना मॉडल की ताकत हैं -

• समझने में आसान, उपयोग करने में आसान।
• अनुभवहीन विकास टीम को संरचना प्रदान करता है।
• मील के पत्थर अच्छी तरह से समझ में आ रहे हैं।
• आवश्यकताओं की स्थिरता निर्धारित करता है।
• प्रबंधन नियंत्रण (योजना, निगरानी, ​​रिपोर्टिंग) के लिए आदर्श।
• अच्छी तरह से काम करता है जब गुणवत्ता लागत या अनुसूची से अधिक महत्वपूर्ण है।

झरना मॉडल - कमजोरियाँ

जलप्रपात मॉडल की कमजोरियां या नुकसान हैं -

• आदर्शीकृत - यह वास्तविकता से अच्छी तरह मेल नहीं खाता है।

• अवास्तविक - परियोजना में जल्दी आवश्यकताओं की अपेक्षा नहीं कर सकता।

• खोजपूर्ण विकास की पुनरावृत्ति प्रकृति को प्रतिबिंबित नहीं करता है जो अधिक सामान्य है।

• बदलाव करना मुश्किल और महंगा।

• सॉफ्टवेयर केवल परियोजना के अंत में दिया जाता है। इसके कारण -

  • गंभीर दोषों की खोज में देरी।

  • अप्रचलित आवश्यकताओं की डिलीवरी की संभावना।

• महत्वपूर्ण प्रबंधन ओवरहेड, जो छोटी टीमों और परियोजनाओं के लिए महंगा हो सकता है।

• हर चरण में अनुभवी संसाधनों की आवश्यकता होती है - विश्लेषकों, डिजाइनरों, डेवलपर्स, परीक्षकों।

• विकास पूरा होने के बाद ही परीक्षण शुरू होता है और परीक्षक पहले के किसी भी चरण में शामिल नहीं होते हैं।

• क्रॉस-फ़ंक्शनल टीमों के विशेषज्ञता को साझा नहीं किया जाता है क्योंकि प्रत्येक चरण को साइलो में निष्पादित किया जाता है।

कब उपयोग करें झरना मॉडल?

आप झरना मॉडल का उपयोग कर सकते हैं यदि -

• आवश्यकताएँ बहुत अच्छी तरह से जानी जाती हैं।

• उत्पाद की परिभाषा स्थिर है।

• प्रौद्योगिकी अच्छी तरह से समझा जाता है।

• किसी मौजूदा उत्पाद का नया संस्करण।

• एक मौजूदा उत्पाद को एक नए प्लेटफॉर्म पर पोर्ट करना।

• संरचित क्रॉस-फ़ंक्शनल टीमों के साथ बड़ा संगठन।

• संचार चैनल संगठन के भीतर और ग्राहक के साथ भी अच्छी तरह से स्थापित हैं।

विकासवादी प्रोटोटाइप मॉडल

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

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

विकासवादी प्रोटोटाइप मॉडल - ताकत

एक विकासवादी प्रोटोटाइप मॉडल की ताकत या फायदे हैं -

• ग्राहक / अंतिम उपयोगकर्ता सिस्टम आवश्यकताओं की कल्पना कर सकते हैं क्योंकि वे प्रोटोटाइप को देख रहे हैं।

• डेवलपर्स ग्राहकों से सीखते हैं और इसलिए डोमेन या उत्पादन वातावरण के बारे में कोई अस्पष्टता नहीं रखते हैं।

• लचीला डिजाइन और विकास की अनुमति देता है।

• प्रोटोटाइप के साथ सहभागिता अतिरिक्त रूप से आवश्यक कार्यक्षमता के बारे में जागरूकता को बढ़ाती है।

• अप्रत्याशित आवश्यकताओं और आवश्यकताओं में परिवर्तन को आसानी से समायोजित किया जाता है।

• प्रगति के स्थिर और दृश्यमान लक्षण उत्पन्न होते हैं।

• एक सटीक और बनाए रखने योग्य अंत-उत्पाद का वितरण।

विकासवादी प्रोटोटाइप मॉडल - कमजोरियाँ

विकासवादी प्रोटोटाइप मॉडल की कमजोरियां या नुकसान इस प्रकार हैं -

• कोड-एंड-फिक्स विकास में संरचित विकास को छोड़ने की प्रवृत्ति, हालांकि यह मॉडल द्वारा निर्धारित नहीं है।

• इस मॉडल को त्वरित और गंदे तरीकों के लिए खराब प्रतिष्ठा मिली।

• कुल मिलाकर स्थिरता की संभवतः अनदेखी की जा सकती है।

• ग्राहक संभवतः अंतिम के रूप में प्रोटोटाइप की डिलीवरी के लिए पूछ सकते हैं, डेवलपर्स को अंतिम चरण यानी अंत-उत्पाद के मानकीकरण को निष्पादित करने का अवसर नहीं देते हैं।

• परियोजना हमेशा (निरंतर गुंजाइश रेंगने के साथ) जारी रह सकती है और प्रबंधन इसकी सराहना नहीं कर सकता है।

विकासवादी प्रोटोटाइप मॉडल का उपयोग कब करें?

आप इवोल्यूशनरी प्रोटोटाइप मॉडल का उपयोग कर सकते हैं -

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

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

गर्भाशय वृद्धिशील मॉडल - ताकत

Iterative Incremental मॉडल के फायदे या ताकत हैं -

• आप पहले प्राथमिकताएं विकसित कर सकते हैं।

• प्रारंभिक उत्पाद वितरण तेज है।

• ग्राहकों को महत्वपूर्ण कार्यक्षमता जल्दी मिलती है।

• प्रारंभिक वितरण लागत को कम करता है।

• प्रत्येक रिलीज़ एक उत्पाद वृद्धि है, जिससे ग्राहक के पास हर समय काम करने वाला उत्पाद होगा।

• ग्राहक प्रत्येक उत्पाद वृद्धि के लिए प्रतिक्रिया दे सकता है, इस प्रकार विकास के अंत में आश्चर्य से बच सकता है।

• आवश्यकताओं में परिवर्तन को आसानी से समायोजित किया जा सकता है।

Iterative Incremental Model - कमजोरियाँ

Iterative Incremental मॉडल के नुकसान हैं -

• पुनरावृत्तियों के प्रभावी नियोजन की आवश्यकता है।

• बाद में परिवर्तनों के लिए आवश्यक कार्यक्षमता और प्रावधान को शामिल करने के लिए कुशल डिजाइन की आवश्यकता होती है।

• वेतन वृद्धि की परिभाषा के लिए एक पूर्ण और पूरी तरह कार्यात्मक प्रणाली की प्रारंभिक परिभाषा की आवश्यकता है।

• अच्छी तरह से परिभाषित मॉड्यूल इंटरफेस की आवश्यकता होती है, क्योंकि कुछ को विकसित होने से बहुत पहले विकसित किया जाता है।

• पूर्ण प्रणाली की कुल लागत कम नहीं है।

Iterative Incremental Model का उपयोग कब करें?

Iterative Incremental मॉडल का उपयोग कब किया जा सकता है -

• अधिकांश आवश्यकताओं को सामने वाले के रूप में जाना जाता है लेकिन समय के साथ विकसित होने की उम्मीद की जाती है।

• आवश्यकताओं को प्राथमिकता दी जाती है।

• मूल कार्यक्षमता को तेजी से वितरित करने की आवश्यकता है।

• एक परियोजना के विकास की लंबी अवधि है।

• एक प्रोजेक्ट में नई तकनीक है।

• डोमेन टीम के लिए नया है।

रैपिड एप्लीकेशन डेवलपमेंट (आरएडी) मॉडल के निम्नलिखित चरण हैं -

• Requirements Planning phase - आवश्यकताओं की योजना के चरण में, संरचित तरीके से व्यावसायिक समस्याओं पर चर्चा करने के लिए aworkshop का संचालन किया जाना चाहिए।

• User Description phase - उपयोगकर्ता विवरण चरण में, उपयोगकर्ताओं से जानकारी कैप्चर करने के लिए स्वचालित टूल का उपयोग किया जाता है।

• Construction phase निर्माण चरण में, उत्पादकता उपकरण, जैसे कि कोड जनरेटर, स्क्रीन जनरेटर, आदि का उपयोग "डोन तक" किया जाता है।

• Cut Over phase - कट ओवर चरण में, सिस्टम की स्थापना, उपयोगकर्ता स्वीकृति परीक्षण और उपयोगकर्ता प्रशिक्षण किया जाता है।

रैपिड एप्लिकेशन डेवलपमेंट मॉडल - ताकत

रैपिड एप्लिकेशन डेवलपमेंट मॉडल के फायदे या ताकत इस प्रकार हैं -

• कम टीम के सदस्यों के साथ चक्र के समय में सुधार और उत्पादकता में सुधार का मतलब होगा कम लागत।

• पूरे चक्र में ग्राहक की भागीदारी ग्राहक संतुष्टि और व्यावसायिक मूल्य प्राप्त नहीं करने के जोखिम को कम करती है।

• फ़ोकस उस कोड में ले जाता है जो आप-सी-सी-व-क्या-आप-प्राप्त मोड (WYSIWYG) में होता है। यह इस बात पर स्पष्टता लाता है कि जो बनाया जा रहा है वह सही बात है।

• व्यवसाय, डेटा और प्रक्रियाओं के बारे में जानकारी प्राप्त करने के लिए मॉडलिंग अवधारणाओं का उपयोग करता है।

रैपिड एप्लीकेशन डेवलपमेंट मॉडल - कमजोरियाँ

रैपिड एप्लिकेशन डेवलपमेंट मॉडल के नुकसान या ताकत इस प्रकार हैं -

• त्वरित विकास प्रक्रिया को उपयोगकर्ता को त्वरित प्रतिक्रिया देनी होगी।

• कभी भी बंद होने का जोखिम नहीं।

• विरासत प्रणालियों के साथ उपयोग करना मुश्किल है।

• डेवलपर्स और ग्राहकों को संक्षिप्त समय सीमा में तेजी से आग की गतिविधियों के लिए प्रतिबद्ध होना चाहिए।

रैपिड एप्लिकेशन डेवलपमेंट मॉडल का उपयोग कब करें?

रैपिड एप्लिकेशन डेवलपमेंट मॉडल का उपयोग कब किया जा सकता है -

• उपयोगकर्ता पूरे जीवन चक्र में शामिल हो सकता है।
• प्रोजेक्ट समय-समय पर हो सकता है।
• वेतन वृद्धि में कार्यक्षमता प्रदान की जा सकती है।

हालांकि रैपिड एप्लिकेशन डेवलपमेंट मॉडल की खूबियों की सराहना की जाती है, लेकिन इसे उद्योग में इस्तेमाल किया जाता है।

सर्पिल मॉडल जोखिम विश्लेषण और राड प्रोटोटाइप को झरना मॉडल में जोड़ता है। प्रत्येक चक्र में झरने के मॉडल के समान चरणों का क्रम शामिल है।

सर्पिल मॉडल में चार चतुर्भुज होते हैं। आइए हम उनके बारे में विस्तार से चर्चा करें।

चतुर्थांश 1 - उद्देश्यों, विकल्पों और बाधाओं को निर्धारित करें

• Objectives - कार्यक्षमता, प्रदर्शन, हार्डवेयर / सॉफ्टवेयर इंटरफ़ेस, महत्वपूर्ण सफलता कारक, आदि।

• Alternatives - निर्माण, पुन: उपयोग, खरीद, उप-अनुबंध, आदि।

• Constraints - लागत, अनुसूची, इंटरफ़ेस, आदि।

चतुर्थांश 2 - विकल्पों का मूल्यांकन करें, जोखिमों की पहचान करें और हल करें

• निर्धारित उद्देश्यों और बाधाओं के सापेक्ष विकल्प का अध्ययन करें।

• अनुभव की कमी, नई तकनीक, तंग कार्यक्रम आदि जैसे जोखिमों की पहचान करें।

• परियोजना पर उनके प्रभाव का मूल्यांकन करने वाले जोखिमों का समाधान करें, आवश्यक शमन और आकस्मिक योजनाओं की पहचान करें और उन्हें लागू करें। जोखिमों पर हमेशा नजर रखने की जरूरत है।

क्वाड्रेंट 3 - अगले स्तर के उत्पाद का विकास करना

विशिष्ट गतिविधियों में शामिल हैं -

• एक डिज़ाइन बनाएँ
• डिजाइन की समीक्षा करें
• कोड विकसित करें
• कोड का निरीक्षण करें
• परीक्षण उत्पाद

चतुर्थांश 4 - अगले चरण की योजना

विशिष्ट गतिविधियों में शामिल हैं -

• प्रोजेक्ट प्लान विकसित करें
• कॉन्फ़िगरेशन प्रबंधन योजना विकसित करें
• एक परीक्षण योजना विकसित करें
• एक स्थापना योजना विकसित करें

सर्पिल मॉडल - ताकत

सर्पिल विधि के फायदे या ताकत हैं -

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

सर्पिल मॉडल - कमजोरियाँ

सर्पिल विधि के नुकसान या कमजोरियां हैं -

• उद्देश्यों को परिभाषित करना कठिन हो सकता है, सत्यापन योग्य मील के पत्थर जो अगले पुनरावृत्ति के माध्यम से आगे बढ़ने के लिए तत्परता का संकेत देते हैं।

• योजना बनाने, उद्देश्यों को रीसेट करने, जोखिम विश्लेषण और प्रोटोटाइप बनाने में समय व्यतीत हो सकता है।

• जोखिम के मूल्यांकन के लिए बिताया गया समय छोटी या कम जोखिम वाली परियोजनाओं के लिए बहुत बड़ा हो सकता है।

• नई टीम के सदस्यों के लिए सर्पिल मॉडल समझना जटिल है।

• जोखिम मूल्यांकन विशेषज्ञता की आवश्यकता है।

• सर्पिल अनिश्चित काल तक जारी रह सकता है।

• गैर-विकास चरण गतिविधियों के दौरान डेवलपर्स को आश्वस्त किया जाना चाहिए।

सर्पिल मॉडल का उपयोग कब करें?

सर्पिल मॉडल का उपयोग कब किया जा सकता है -

• एक प्रोटोटाइप का निर्माण उपयुक्त है।
• जोखिम मूल्यांकन महत्वपूर्ण है।
• एक परियोजना मध्यम से उच्च जोखिम वाली है।
• उपयोगकर्ता अपनी आवश्यकताओं के बारे में अनिश्चित हैं।
• आवश्यकताएँ जटिल हैं।
• उत्पाद-लाइन नई है।
• अन्वेषण के दौरान महत्वपूर्ण परिवर्तन अपेक्षित हैं।
• संभावित व्यावसायिक परिवर्तनों के कारण दीर्घकालिक परियोजना प्रतिबद्धता नासमझी।

एजाइल मेथड्स एजाइल मेनिफेस्टो पर आधारित हैं और प्रकृति में अनुकूली हैं। चंचल तरीके सुनिश्चित करते हैं -

• दल का सहयोग।
• ग्राहक सहयोग
• लगातार और निरंतर संचार।
• परिवर्तन का जवाब।
• एक काम उत्पाद की तत्परता।

कई फुर्तीली विधियां अस्तित्व में आईं, समय-समय पर पुनरावृत्तियों के साथ पुनरावृत्ति और वृद्धिशील विकास को बढ़ावा देती हैं। हालांकि चुस्त तरीके अनुकूल हैं, विशिष्ट विधि के नियम पारित नहीं हो सकते हैं और इसलिए अनुशासित कार्यान्वयन की आवश्यकता है।

चंचल तरीके - ताकत

चंचल विधि के फायदे या ताकत हैं -

• जल्दी और लगातार रिलीज।
• बदलती आवश्यकताओं का आवास।
• ग्राहक और डेवलपर्स के बीच दैनिक संचार।
• प्रेरित व्यक्तियों के आसपास निर्मित परियोजनाएं।
• स्वयं सेवी दल।
• सादगी, जो तुरंत आवश्यक है उस पर ध्यान केंद्रित करना।
• भविष्य के लिए कोई इमारत नहीं या कोड को अधिक करना।
• प्रभावशीलता में सुधार के लिए व्यवहार को समायोजित करने के लिए नियमित प्रतिबिंब।

चंचल विधियाँ - कमजोरियाँ

सर्पिल विधि के नुकसान या कमजोरियां हैं -

• ग्राहक की उपलब्धता संभव नहीं है।

• विधियों के नियमों का पालन करने के लिए टीमों का अनुभव किया जाना चाहिए।

• कार्यक्षमता में शीघ्रता से निर्णय लेने के लिए उचित नियोजन की आवश्यकता होती है जिसे पुनरावृति में देने की आवश्यकता होती है।

• टीम में अनुमान कौशल और बातचीत कौशल होने की उम्मीद है।

• टीम में प्रभावी संचार कौशल होना चाहिए।

• नई टीमें खुद को व्यवस्थित करने में सक्षम नहीं हो सकती हैं।

• समय-समय पर पुनरावृत्तियों को विकसित करने और वितरित करने के लिए अनुशासन की आवश्यकता होती है।

• डिजाइन को सरल और बनाए रखने की आवश्यकता है, इस प्रकार प्रभावी डिजाइन कौशल की आवश्यकता होती है।

चंचल विधियों का उपयोग कब करें?

चंचल विधियों का उपयोग तब किया जा सकता है जब -

• आवेदन समय महत्वपूर्ण है।

• दायरा सीमित है और कम औपचारिक है (बड़ी परियोजनाओं के लिए चुस्त तरीकों को बढ़ाया जा रहा है, कुछ चुस्त तरीकों के लिए कुछ एक्सटेंशन के साथ)।

• संगठन अनुशासित तरीके से काम करता है।

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

इन मुद्दों को संबोधित करने के लिए अनुकूली सॉफ्टवेयर डेवलपमेंट (एएसडी) विकसित हुआ है। यह उत्पाद के विकास को प्रबंधित करने की क्षमता को बढ़ाने के लिए प्रबंधन के दृष्टिकोण से सबसे महत्वपूर्ण कारक के रूप में उभरने पर केंद्रित है।

जिम हाईस्मिथ के शब्दों में, "एडाप्टिव सॉफ्टवेयर डेवलपमेंट फ्रेमवर्क पारंपरिक सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी, कंसल्टिंग, प्रैक्टिस और रैपिड एप्लीकेशन डेवलपमेंट (आरएडी) तकनीकों के बारे में अनुभव और उनके उत्पाद विकास के प्रबंधन पर उच्च-प्रौद्योगिकी सॉफ्टवेयर कंपनियों के साथ काम करने के वर्षों के अनुभव पर आधारित है। प्रथाओं "।

वॉटरफॉल मॉडल को लीनियरिटी और प्रेडिक्टिबिलिटी द्वारा विशेषता माना जाता है, जिसमें मीगर फीडबैक होता है। इसे एक अनुक्रम के रूप में देखा जा सकता हैPlan → Build → Implement।

सर्पिल मॉडल जैसे इवोल्यूशनरी लाइफसाइकल मॉडल ने एडेप्टिव एक के लिए नियतात्मक दृष्टिकोण को स्थानांतरित कर दिया Plan → Build → Revise Cycles।

हालांकि, चिकित्सकों की मानसिकता दीर्घकालिक भविष्यवाणियों के साथ अल्पकालिक भविष्यवाणियों की ओर मुड़ने के लिए निर्धारक बनी रही। आरएडी जैसे विकासवादी जीवनचक्र मॉडल के अभ्यास कम नियतात्मक पाए जाते हैं।

अनुकूली जीवन चक्र

एडेप्टिव मॉडल एक अलग दृष्टिकोण से बनाया गया है। हालांकि विकासवादी मॉडल की तरह चक्रीय, चरण के नाम तेजी से जटिल प्रणालियों की अप्रत्याशित प्रकृति को दर्शाते हैं।

अनुकूली विकास दो प्रमुख तरीकों से अपनी विकासवादी विरासत से आगे बढ़ता है -

• यह स्पष्ट रूप से उद्भव के साथ नियतिवाद की जगह लेता है।

• यह जीवन चक्र में बदलाव से आगे बढ़कर प्रबंधन शैली में गहरा बदलाव लाता है।

अनुकूली सॉफ्टवेयर विकास जीवनचक्र में तीन चरण हैं -

• Speculate - अटकलें नियत शब्द योजना, उत्पाद विनिर्देशों की योजना या परियोजना प्रबंधन कार्यों की योजना की जगह लेती हैं।

• Collaborate - सहयोग के बीच एक संतुलन ड्राइंग का प्रतिनिधित्व करता है

  • पारंपरिक परियोजना प्रबंधन की समझ में प्रबंधन, और

  • उद्भव के लिए आवश्यक सहयोगात्मक वातावरण बनाना और उसे बनाए रखना।

सहयोगात्मक गतिविधियाँ पर्यावरण में परिवर्तनों की गति को ध्यान में रखते हुए उत्पादों का निर्माण करती हैं।

• Learn - जानें कि दोनों, डेवलपर्स और ग्राहकों को, अगले की दिशा जानने के लिए प्रत्येक विकास चक्र के परिणामों का उपयोग करने के लिए।

इस अध्याय में, हम Adaptive Software Development की विभिन्न अवधारणाओं को समझेंगे।

कॉम्प्लेक्स एडेप्टिव सिस्टम्स (सीएएस) सिद्धांत

सांता फ़े संस्थान में ब्रायन आर्थर और उनके सहयोगियों ने भौतिकी, जीव विज्ञान, विकास और अर्थशास्त्र की समझ में क्रांतिकारी बदलाव के लिए कॉम्प्लेक्स एडेप्टिव सिस्टम्स (सीएएस) सिद्धांत का उपयोग किया।

ब्रायन आर्थर ने मुख्यधारा के अर्थशास्त्रियों को समझाने की कोशिश के दो दशकों से अधिक समय के लिए यह निष्कर्ष निकाला कि घटते हुए रिटर्न, संतुलन और नियतात्मक गतिशीलता की मौलिक धारणाओं पर हावी उनका दृष्टिकोण, वास्तविकता को समझने के लिए पर्याप्त नहीं था। नई दुनिया बढ़ती कारण, अस्थिरता और कारण और प्रभाव को निर्धारित करने में असमर्थता में से एक है।

व्यवहार, शैली और संस्कृति में दोनों दुनिया अलग-अलग हैं। वे कहते हैं -

• विभिन्न प्रबंधन तकनीकों
• अलग-अलग रणनीतियाँ
• अलग समझ

जटिल सॉफ्टवेयर विकास

सॉफ्टवेयर एप्लिकेशन के दायरे में विस्फोट होने के साथ, यहां तक ​​कि सॉफ्टवेयर विकास संगठन भी इसी तरह के विरोधाभासों का उल्लेख कर रहे हैं जैसा कि ऊपर उल्लेख किया गया है।

• एक विश्व का निर्धारण नियतात्मक विकास द्वारा किया जाता है, जो प्रबंधन प्रथाओं से प्राप्त होता है जो स्थिरता और पूर्वानुमान की मूल बातों से निहित होता है (जिसका अर्थ है आर्थर की शर्तों में रिटर्न कम होना)

• दूसरी दुनिया का प्रतिनिधित्व उद्योगों द्वारा घटते-बढ़ते रिटर्न वातावरण से हो रहा है, जो अप्रत्याशित, अशुभ और तेज है।

इस दूसरी दुनिया के मुद्दों को संबोधित करने के लिए, जिग हाईस्मिथ ने एक ढांचा, अनुकूली सॉफ्टवेयर विकास की पेशकश की जो कि निर्धारक सॉफ्टवेयर विकास से अलग है।

अनुकूली सॉफ्टवेयर डेवलपमेंट जटिल प्रणालियों को संबोधित करने पर केंद्रित है -

• विकास जीवन चक्र के लिए अनुकूली सॉफ्टवेयर डेवलपमेंट।

• अनुकूली प्रबंधन तकनीकों पारंपरिक परियोजना प्रबंधन प्रथाओं से एक अलग मानसिकता के लिए बुला।

इस ट्यूटोरियल में, आप इन दोनों कार्यान्वयनों को समझ सकते हैं।

अनुकूली सॉफ्टवेयर डेवलपमेंट (एएसडी) दो दृष्टिकोणों पर आधारित है -

• इस अध्याय के पहले खंड में दिए गए, कॉम्प्लेक्स एडेप्टिव सिस्टम्स (CAS) सिद्धांत पर आधारित वैचारिक परिप्रेक्ष्य।

• पर आधारित व्यावहारिक परिप्रेक्ष्य

  • निर्धारक सॉफ्टवेयर विकास के तरीकों के साथ अनुभव के वर्ष।

  • परामर्श, अभ्यास, और रैपिड एप्लीकेशन डेवलपमेंट (आरएडी) तकनीकों के बारे में लिखना; और उनके उत्पाद विकास के प्रबंधन पर उच्च-प्रौद्योगिकी सॉफ्टवेयर कंपनियों के साथ काम करना।

इस अध्याय में, आप एडाप्टिव सॉफ्टवेयर डेवलपमेंट के वैचारिक परिप्रेक्ष्य को समझेंगे।

कॉम्प्लेक्स एडेप्टिव सिस्टम्स (सीएएस) अवधारणाओं

कॉम्प्लेक्स एडेप्टिव सिस्टम्स (CAS) सिद्धांत की कई अवधारणाएं हैं। अनुकूली सॉफ्टवेयर विकास इन अवधारणाओं में से दो पर आधारित है -

• Emergence
• Complexity

उद्भव

जटिल सॉफ्टवेयर उत्पाद-विकास परियोजनाओं में, परिणाम स्वाभाविक रूप से अप्रत्याशित होते हैं। हालांकि, सफल उत्पाद हर समय ऐसे वातावरण से निकलते हैं।

यह इमर्जेशन द्वारा हो सकता है, जैसा कि कॉम्प्लेक्स एडेप्टिव सिस्टम्स (सीएएस) सिद्धांत में चित्रित किया गया है। इसे एक साधारण उदाहरण से समझा जा सकता है, पक्षियों का व्यवहार।

जब आप पक्षियों के झुंड का निरीक्षण करते हैं, तो आप नोटिस करते हैं कि -

• प्रत्येक पक्षी करने की कोशिश करता है

  • अन्य पक्षियों सहित पर्यावरण में अन्य वस्तुओं से न्यूनतम दूरी बनाए रखें।

  • इसके पड़ोस में पक्षियों के साथ वेग का मिलान करें।

  • अपने पड़ोस में पक्षियों के द्रव्यमान के कथित केंद्र की ओर बढ़ें।

• समूह के लिए व्यवहार के कोई नियम नहीं हैं। एकमात्र नियम व्यक्तिगत पक्षियों के व्यवहार के बारे में हैं।

• हालांकि, पक्षियों के झुंड में एक उभरता हुआ व्यवहार मौजूद है। जब त्रुटिपूर्ण पक्षी पकड़ने के लिए दौड़ते हैं, तो झुंड दूसरी ओर बाधाओं और सुधारों के आसपास फूट जाता है।

यह एडेप्टिव डेवलपमेंट में सबसे कठिन मानसिक मॉडल परिवर्तनों की आवश्यकता को दर्शाता है - उस व्यक्तिगत स्वतंत्रता को प्रबंधित करने और व्यवस्थित करने के तरीकों से जो कि एक रचनात्मक नया क्रम सहज आत्मसंघर्ष से अप्रत्याशित रूप से उभरता है।

विकास के अलावा, उद्भव प्रबंधन के दृष्टिकोण से भी सबसे महत्वपूर्ण अवधारणा है।

जटिलता

सॉफ्टवेयर विकास के संदर्भ में, जटिलता के बारे में है -

• डेवलपर्स, ग्राहकों, विक्रेताओं, प्रतियोगियों और स्टॉकहोल्डर्स, उनकी संख्या और उनकी गति जैसी टीम के व्यक्ति।

• आकार और तकनीकी जटिलता।

अनुकूली सॉफ्टवेयर विकास प्रथाओं

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

आप इस ट्यूटोरियल में अध्याय, अनुकूली सॉफ्टवेयर डेवलपमेंट प्रैक्टिस में सभी प्रथाओं का विवरण पा सकते हैं।

गुणवत्ता

एक जटिल वातावरण में, "पहली बार सही करें" की पुरानी-पुरानी प्रथा काम नहीं करती है क्योंकि आप यह अनुमान नहीं लगा सकते कि शुरुआत में क्या सही है। सही मूल्य का उत्पादन करने के लिए आपके पास एक उद्देश्य होना चाहिए। हालांकि, जटिल वातावरण में, मान (घटक, प्रदर्शन, दोष स्तर), शेड्यूल और संसाधनों जैसे मूल्य घटकों के संयोजन और क्रमपरिवर्तन इतने विशाल हैं कि कभी भी एक इष्टतम मूल्य नहीं हो सकता है। इसलिए, प्रतिस्पर्धी बाजार में सर्वोत्तम मूल्य देने के लिए ध्यान केंद्रित करना है।

राड प्रैक्टिस

राड प्रथाओं में आम तौर पर निम्नलिखित का एक संयोजन शामिल होता है -

• विकासवादी जीवनचक्र
• ग्राहक फोकस समूह, JAD सत्र, तकनीकी समीक्षा
• टाइम-बॉक्सिंग प्रोजेक्ट मैनेजमेंट
• सतत सॉफ्टवेयर इंजीनियरिंग
• युद्ध कक्षों के साथ समर्पित टीमें

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

राड प्रथाओं और Microsoft प्रक्रिया दोनों कार्रवाई में अनुकूली विकास के उदाहरण हैं। उन्हें एक लेबल (यानी, अनुकूली विकास) देते हुए और यह महसूस करते हुए कि वैज्ञानिक ज्ञान का एक बढ़ता हुआ शरीर है (यानी, कैस सिद्धांत) बताते हैं कि वे क्यों काम करते हैं। यह इन प्रथाओं के अधिक व्यापक उपयोग के लिए एक आधार प्रदान करना चाहिए।

एडाप्टिव सॉफ्टवेयर डेवलपमेंट आरएडी प्रथाओं से विकसित हुआ है। इन प्रथाओं में टीम के पहलुओं को भी जोड़ा गया। न्यूज़ीलैंड से कनाडा तक की कंपनियों ने कई प्रकार के प्रोजेक्ट और उत्पाद प्रकारों के लिए, अनुकूली सॉफ़्टवेयर डेवलपमेंट का उपयोग किया है।

जिम हाईस्मिथ ने 2000 में एडाप्टिव सॉफ्टवेयर डेवलपमेंट प्रकाशित किया।

अनुकूली सॉफ्टवेयर डेवलपमेंट प्रैक्टिस परिवर्तन को समायोजित करने की क्षमता प्रदान करते हैं और थोड़ा योजना और सीखने के साथ विकसित होने वाले उत्पादों के साथ अशांत वातावरण में अनुकूल होते हैं।

एएसडी जीवन चक्र के चरण

एडेप्टिव सॉफ्टवेयर डेवलपमेंट इवोल्यूशनरी मॉडल की तरह चक्रीय है, जिसमें चरण नाम जटिल सिस्टम में अप्रत्याशितता को दर्शाते हैं। अनुकूली विकास जीवन चक्र के चरण हैं -

• Speculate
• Collaborate
• Learn

ये तीन चरण अनुकूली सॉफ्टवेयर विकास की गतिशील प्रकृति को दर्शाते हैं। अनुकूलन विकास स्पष्ट रूप से उद्भव के साथ नियतिवाद को प्रतिस्थापित करता है। यह जीवन चक्र में एक मात्र परिवर्तन से प्रबंधन शैली में एक गहरे बदलाव से परे चला जाता है। एडेप्टिव सॉफ्टवेयर डेवलपमेंट में डायनामिक स्पेकुलेट-कोलैबोरेट-लर्न लाइफसाइकल है।

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

कल्पना करना

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

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

सहयोग

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

सहयोग के लिए परिणाम प्राप्त करने, ज्ञान साझा करने या निर्णय लेने के लिए संयुक्त रूप से काम करने की क्षमता की आवश्यकता होगी।

परियोजना प्रबंधन के संदर्भ में सहयोग, पारंपरिक प्रबंधन तकनीकों के प्रबंधन और उद्भव के लिए आवश्यक सहयोगात्मक वातावरण बनाने और बनाए रखने के बीच एक संतुलन को चित्रित करता है।

सीखना

परियोजना की सफलता के लिए जीवनचक्र का हिस्सा जानें महत्वपूर्ण है। टीम को अपने ज्ञान को लगातार बढ़ाना है, जैसे कि प्रथाओं का उपयोग करते हुए -

• तकनीकी समीक्षा
• प्रोजेक्ट रेट्रोस्पेक्टिव्स
• ग्राहक फोकस समूह

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

• उत्पाद परिवर्तन के बारे में

• उत्पादों को कैसे विकसित किया जा रहा है, इस बारे में अंतर्निहित धारणाओं में अधिक मौलिक परिवर्तन

पुनरावृत्तियों को छोटा करने की आवश्यकता है, ताकि टीम बड़ी गलतियों के बजाय छोटे से सीख सके।

अटकलें - सहयोग करें - एक चक्र के रूप में जानें

जैसा कि आप ऊपर दिए गए स्पेकुलेट-कोलाबरेट-लर्न चक्र से निरीक्षण करते हैं, यह स्पष्ट है कि तीन चरण अरेखीय और ओवरलैप हैं।

हम एक अनुकूली ढांचे से निम्नलिखित का पालन करते हैं।

• सीखना के बिना सहयोग करना या बिना सहयोग के सीखना मुश्किल है।

• लर्निंग के बिना अटकलें लगाना या बिना सट्टा सीखना मुश्किल है।

• बिना विस्तार के अटकलें लगाना या बिना अटकल के सहयोग करना मुश्किल है।

अनुकूली सॉफ्टवेयर विकास जीवनचक्र की छह बुनियादी विशेषताएं हैं -

• मिशन केंद्रित है
• सुविधा आधारित
• Iterative
• Time-boxed
• जोखिम चालित
• सहिष्णु बदलो

इस अध्याय में, आप Adaptive Software Development की इन छह विशेषताओं को समझेंगे।

मिशन केंद्रित

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

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

फ़ीचर आधारित

अनुकूली सॉफ्टवेयर डेवलपमेंट लाइफसाइकल एप्लीकेशन फीचर्स पर आधारित है न कि कार्यों पर। विशेषताएं कार्यक्षमता हैं जो ग्राहक की प्राथमिकताओं के आधार पर एक पुनरावृत्ति के दौरान विकसित की जाती हैं।

जब ग्राहक प्रतिक्रिया प्रदान करते हैं तो सुविधाएँ कई पुनरावृत्तियों पर विकसित हो सकती हैं।

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

चलने का

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

समय-बॉक्सिंग

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

एडाप्टिव सॉफ्टवेयर डेवलपमेंट में, टाइम-बॉक्सिंग को आवश्यक के रूप में कठिन ट्रेडऑफ निर्णयों पर ध्यान केंद्रित करने और मजबूर करने के लिए एक दिशा के रूप में माना जाता है। अनिश्चित वातावरण में, जिसमें परिवर्तन दर अधिक होती है, कार्य को पूरा करने के लिए समय-समय पर कार्य करने की आवश्यकता होती है जैसे कि एक टाइमबॉक्स।

जोखिम पर ही आधारित

अनुकूली सॉफ्टवेयर डेवलपमेंट में, महत्वपूर्ण जोखिमों की पहचान और मूल्यांकन करके पुनरावृत्तियों को संचालित किया जाता है।

बदलें सहिष्णु

अनुकूली सॉफ्टवेयर डेवलपमेंट परिवर्तन-सहिष्णु है, परिवर्तन को प्रतिस्पर्धी लाभ को शामिल करने की क्षमता के रूप में देखता है, लेकिन विकास के लिए समस्या के रूप में नहीं।

अनुकूली सॉफ्टवेयर डेवलपमेंट प्रथाओं को निरंतर अनुकूलन में एक विश्वास द्वारा संचालित किया जाता है, जीवनचक्र को मानक के रूप में निरंतर परिवर्तन को स्वीकार करने के लिए सुसज्जित है।

अनुकूली सॉफ्टवेयर विकास जीवनचक्र समर्पित है -

• लगातार सीखना
• अभिविन्यास बदलें
• Re-evaluation
• अनिश्चित भविष्य में झांकना
• डेवलपर्स, प्रबंधन और ग्राहकों के बीच गहन सहयोग

अनुकूली एसडीएलसी

अनुकूली सॉफ्टवेयर डेवलपमेंट, RAD को सॉफ्टवेयर इंजीनियरिंग के सर्वोत्तम प्रथाओं के साथ जोड़ती है, जैसे -

• परियोजना का प्रारम्भ।
• अनुकूली चक्र योजना।
• समवर्ती घटक इंजीनियरिंग।
• गुणवत्ता की समीक्षा।
• अंतिम क्यूए और रिलीज।

अनुकूली सॉफ्टवेयर विकास प्रथाओं को निम्नानुसार चित्रित किया जा सकता है -

जैसा कि ऊपर वर्णित है, अनुकूली सॉफ्टवेयर डेवलपमेंट प्रथाओं को तीन चरणों में फैलाया जाता है -

• अटकलें - पहल और योजना

  • परियोजना का प्रारम्भ

  • पूरे प्रोजेक्ट के लिए टाइम-बॉक्स की स्थापना

  • पुनरावृत्तियों की संख्या पर निर्णय लें और प्रत्येक को एक टाइम-बॉक्स असाइन करें

  • प्रत्येक पुनरावृत्तियों के लिए एक थीम या उद्देश्य विकसित करें

  • प्रत्येक पुनरावृत्ति को सुविधाएँ निर्दिष्ट करें

• Collaborate - समवर्ती सुविधा विकास

  • वितरित टीमों के लिए सहयोग

  • छोटी परियोजनाओं के लिए सहयोग

  • बड़ी परियोजनाओं के लिए सहयोग

• Learn - गुणवत्ता की समीक्षा

  • ग्राहक के दृष्टिकोण से परिणाम की गुणवत्ता

  • तकनीकी दृष्टिकोण से परिणाम की गुणवत्ता

  • वितरण टीम के कामकाज और अभ्यास टीम के सदस्य उपयोग कर रहे हैं

  • परियोजना की स्थिति

अटकलें - पहल और योजना

अनुकूली सॉफ्टवेयर डेवलपमेंट में, सट्टा चरण की दो गतिविधियाँ हैं -

• Initiation
• Planning

सट्टा में पांच प्रथाएं हैं जिन्हें दीक्षा और नियोजन चरण के दौरान दोहराव से निष्पादित किया जा सकता है। वे हैं -

• परियोजना का प्रारम्भ
• पूरे प्रोजेक्ट के लिए टाइम-बॉक्स की स्थापना
• पुनरावृत्तियों की संख्या पर निर्णय लें और प्रत्येक को एक टाइम-बॉक्स असाइन करें
• प्रत्येक पुनरावृत्तियों के लिए एक थीम या उद्देश्य विकसित करें
• प्रत्येक पुनरावृत्ति को सुविधाएँ निर्दिष्ट करें

परियोजना का प्रारम्भ

परियोजना की पहल में शामिल हैं -

• परियोजना के मिशन और उद्देश्यों को निर्धारित करना
• अड़चन समझना
• परियोजना संगठन की स्थापना
• आवश्यकताओं की पहचान और रूपरेखा
• प्रारंभिक आकार और गुंजाइश का अनुमान लगाना
• प्रमुख परियोजना जोखिमों की पहचान करना

गति के प्रमुख पहलू के रूप में विचार करते हुए, परियोजना आरंभ डेटा को प्रारंभिक JAD सत्र में इकट्ठा किया जाना चाहिए। छोटे से मध्यम आकार की परियोजनाओं के लिए या दो से तीन सप्ताह के बड़े प्रयासों के लिए दो से पांच दिन के प्रयास में पहल को पूरा किया जा सकता है।

जेएडी सत्रों के दौरान, सुविधाओं की पहचान करने और ऑब्जेक्ट, डेटा या अन्य वास्तुशिल्प मॉडल के अवलोकन को स्थापित करने के लिए आवश्यकताओं को पर्याप्त विवरण में इकट्ठा किया जाता है।

संपूर्ण परियोजना के लिए टाइम-बॉक्स की स्थापना

संपूर्ण प्रोजेक्ट के लिए समय-बॉक्स, गुंजाइश, फीचर-सेट आवश्यकताओं, अनुमानों और संसाधन उपलब्धता के आधार पर स्थापित किया जाना चाहिए, जो प्रोजेक्ट आरंभ करने के कार्य से उत्पन्न होता है।

जैसा कि आप जानते हैं, अटकलबाजी अनुमान लगाना नहीं छोड़ती है, लेकिन इसका मतलब सिर्फ यह है कि अनुमान गलत हो सकता है।

Iterations और समय-बॉक्स

संपूर्ण प्रोजेक्ट स्कोप और अनिश्चितता की डिग्री के आधार पर पुनरावृत्तियों की संख्या और व्यक्तिगत पुनरावृत्ति की लंबाई पर निर्णय लें।

एक छोटे से मध्यम आकार के आवेदन के लिए -

• Iterations आमतौर पर चार से आठ सप्ताह से भिन्न होते हैं।
• कुछ परियोजनाएं दो सप्ताह के पुनरावृत्तियों के साथ सबसे अच्छा काम करती हैं।
• कुछ परियोजनाओं को आठ सप्ताह से अधिक की आवश्यकता हो सकती है।

आपके लिए क्या काम करता है, इसके आधार पर समय चुनें। एक बार पुनरावृत्तियों की संख्या और पुनरावृत्तियों में से प्रत्येक की लंबाई पर निर्णय लेने के बाद, पुनरावृत्तियों में से प्रत्येक के लिए एक शेड्यूल असाइन करें।

एक थीम या उद्देश्य विकसित करें

टीम के सदस्यों को प्रत्येक पुनरावृत्ति के लिए एक थीम या उद्देश्य विकसित करना चाहिए। यह स्क्रम में स्प्रिंट गोल के समान है। प्रत्येक पुनरावृत्ति को उन विशेषताओं का एक सेट देना चाहिए जो उत्पाद कार्यक्षमता को प्रदर्शित कर सकते हैं जिससे ग्राहक को समीक्षा और प्रतिक्रिया सक्षम करने के लिए उत्पाद दिखाई दे।

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

सुविधाएँ निर्दिष्ट करें

डेवलपर्स और ग्राहकों को एक साथ प्रत्येक पुनरावृत्ति को सुविधाएँ प्रदान करनी चाहिए। इस सुविधा असाइनमेंट के लिए सबसे महत्वपूर्ण मानदंड यह है कि प्रत्येक पुनरावृत्ति को ग्राहक के लिए पर्याप्त कार्यक्षमता के साथ दृश्यमान सेट प्रदान करना चाहिए।

पुनरावृत्तियों को सुविधाओं के असाइनमेंट के दौरान -

• विकास टीम को फीचर अनुमान, जोखिम और निर्भरता के साथ आना चाहिए और उन्हें ग्राहक को प्रदान करना चाहिए।

• ग्राहकों को विकास टीम द्वारा दी गई जानकारी का उपयोग करके, सुविधा प्राथमिकता पर निर्णय लेना चाहिए।

इस प्रकार पुनरावृत्ति नियोजन सुविधा-आधारित है और डेवलपर्स और ग्राहकों के साथ एक टीम के रूप में किया जाता है। अनुभव से पता चला है कि इस प्रकार की योजना परियोजना प्रबंधक द्वारा कार्य-आधारित योजना की तुलना में परियोजना की बेहतर समझ प्रदान करती है। इसके अलावा, फीचर-आधारित योजना प्रत्येक परियोजना की विशिष्टता को दर्शाती है।

सहयोग Development समवर्ती सुविधा विकास

सहयोग चरण के दौरान, विकास पर ध्यान केंद्रित किया गया है। सहयोग चरण में दो गतिविधियाँ हैं -

• डेवलपमेंट टीम वर्किंग सॉफ्टवेयर का सहयोग और वितरण करती है।

• परियोजना प्रबंधक सहयोग और समवर्ती विकास गतिविधियों की सुविधा प्रदान करते हैं।

सहयोग साझा निर्माण का एक कार्य है जो विकास टीम, ग्राहकों और प्रबंधकों को शामिल करता है। साझा रचना विश्वास और सम्मान से प्रेरित होती है।

टीमों को सहयोग करना चाहिए -

• तकनीकी समस्याएँ
• व्यापार की आवश्यकताओं
• तेजी से निर्णय लेना

अनुकूली सॉफ्टवेयर विकास में सहयोग चरण के लिए प्रासंगिक निम्नलिखित प्रथाएं हैं -

• वितरित टीमों के लिए सहयोग
• छोटी परियोजनाओं के लिए सहयोग
• बड़ी परियोजनाओं के लिए सहयोग

वितरित टीमों के लिए सहयोग

वितरित टीमों से जुड़ी परियोजनाओं में, निम्नलिखित पर विचार किया जाना चाहिए -

• सहयोगी सहयोगियों की भिन्नता
• व्यापक ज्ञान
• लोगों के बातचीत करने का तरीका
• जिस तरह से वे अन्योन्याश्रय प्रबंधन करते हैं

लघु परियोजनाओं के लिए सहयोग

छोटी परियोजनाओं में, जब टीम के सदस्य शारीरिक निकटता में काम कर रहे होते हैं, तो अनौपचारिक हॉलवे चैट और व्हाइटबोर्ड स्क्रिबलिंग के साथ सहयोग को प्रोत्साहित किया जाना चाहिए, क्योंकि यह प्रभावी पाया जाता है।

बड़ी परियोजनाओं के लिए सहयोग

बड़ी परियोजनाओं के लिए अतिरिक्त अभ्यास, सहयोग उपकरण और परियोजना प्रबंधक सहभागिता की आवश्यकता होती है और इसे प्रासंगिक आधार पर व्यवस्थित किया जाना चाहिए।

जानिए - क्वालिटी रिव्यू

अनुकूली सॉफ्टवेयर विकास 'प्रयोग और जानें' की अवधारणा को प्रोत्साहित करता है।

गलतियों और प्रयोग से सीखने के लिए आवश्यक है कि टीम के सदस्य आंशिक रूप से पूर्ण किए गए कोड और कलाकृतियों को जल्दी-जल्दी साझा करें, ताकि -

• ग़लतियाँ खोजो
• उनसे सीखो
• छोटी समस्याओं का पता लगाने से पहले उन्हें कम करें, ताकि वे बड़े हो जाएं

प्रत्येक विकास पुनरावृत्ति के अंत में, सीखने के लिए चार सामान्य श्रेणियां हैं -

• ग्राहक के दृष्टिकोण से परिणाम की गुणवत्ता
• तकनीकी दृष्टिकोण से परिणाम की गुणवत्ता
• प्रसव टीम और प्रथाओं टीम के कामकाज
• परियोजना की स्थिति

ग्राहक के दृष्टिकोण से परिणाम की गुणवत्ता

अनुकूली सॉफ्टवेयर विकास परियोजनाओं में, ग्राहकों से प्रतिक्रिया प्राप्त करना पहली प्राथमिकता है। इसके लिए अनुशंसित अभ्यास एक ग्राहक फ़ोकस समूह है। ये सत्र एप्लिकेशन के एक कामकाजी मॉडल का पता लगाने और ग्राहक परिवर्तन अनुरोधों को रिकॉर्ड करने के लिए डिज़ाइन किए गए हैं।

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

एक तकनीकी परिप्रेक्ष्य से परिणाम की गुणवत्ता

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

अनुकूली सॉफ्टवेयर विकास परियोजनाओं में, टीम को समय-समय पर अपने स्वयं के प्रदर्शन की निगरानी करनी चाहिए। पूर्वव्यापी एक टीम के रूप में, अपने और अपने काम के बारे में जानने के लिए टीमों को प्रोत्साहित करते हैं।

Iteration-end रेट्रोस्पेक्टिव्स समय-समय पर टीम के प्रदर्शन की समीक्षा करते हैं जैसे कि -

• निर्धारित करें कि क्या काम नहीं कर रहा है।
• टीम को और क्या करने की जरूरत है।
• टीम को कम करने की जरूरत है।

परियोजना की स्थिति

परियोजना की स्थिति की समीक्षा आगे काम की योजना बनाने में मदद करती है। अनुकूली सॉफ्टवेयर विकास परियोजनाओं में, परियोजना की स्थिति का निर्धारण सुविधा-आधारित दृष्टिकोण है, कार्य सुविधाओं के परिणामस्वरूप प्रत्येक पूर्णता का अंत पूर्ण विशेषताओं द्वारा चिह्नित किया गया है।

परियोजना की स्थिति की समीक्षा में शामिल होना चाहिए -

• प्रोजेक्ट कहां है?
• परियोजना बनाम योजना कहां है?
• प्रोजेक्ट कहां होना चाहिए?

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

पारंपरिक सॉफ़्टवेयर प्रबंधन का फ़्लोचार्ट नीचे दिखाया गया है।

पारंपरिक सॉफ्टवेयर प्रबंधन को कमांड-कंट्रोल शब्द की विशेषता बताई गई है।

कई संगठन अनुकूलन, दक्षता, पूर्वानुमान, नियंत्रण, कठोरता और प्रक्रिया में सुधार की परंपरा में फंस गए हैं। हालाँकि, उभरती हुई सूचना युग अर्थव्यवस्था के लिए अनुकूलन क्षमता, गति, सहयोग, सुधार, लचीलापन, नवाचार, और शालीनता की आवश्यकता होती है।

हार्वर्ड व्यवसाय की समीक्षा और प्रबंधन पुस्तकें सशक्तिकरण, सहभागिता प्रबंधन, शिक्षण संगठन, मानव-केंद्रित प्रबंधन आदि जैसे शब्द हैं, लेकिन इनमें से किसी को भी आधुनिक संगठनों के प्रबंधन में नहीं लगाया जा रहा है।

अनुकूली सॉफ्टवेयर विकास के संदर्भ में, अंतर बहुत व्यापक है और अन्य क्षेत्रों में सफल साबित हुए अनुकूली प्रबंधन तकनीकों पर विचार करने की आवश्यकता है।

अनुकूली प्रबंधन

अनुकूली प्रबंधन उन वातावरणों में सफल साबित हुआ है, जहां संसाधन प्रबंधकों ने निम्नलिखित लक्ष्यों के साथ, एक टीम के रूप में हितधारकों और वैज्ञानिकों के साथ मिलकर काम किया है -

• यह जानने के लिए कि प्रबंधित प्रणालियाँ मानवीय हस्तक्षेपों का जवाब कैसे देती हैं।

• भविष्य में संसाधन नीतियों और प्रथाओं में सुधार करना।

अनुकूली प्रबंधन के पीछे सिद्धांत यह है कि कई संसाधन प्रबंधन गतिविधियां प्रयोग हैं क्योंकि उनके परिणामों का पहले से अनुमान नहीं लगाया जा सकता है। इन प्रयोगों को तब भविष्य में सुधार के सीखने के अवसरों के रूप में उपयोग किया जाता है।

अनुकूली प्रबंधन का उद्देश्य नई सूचनाओं का सामना करने और विभिन्न हितधारक उद्देश्यों और वरीयताओं की सेटिंग में समय पर प्रतिक्रिया करने की क्षमता को बढ़ाना है। यह हितधारकों को विवादों के लिए प्रोत्साहित करता है और एक व्यवस्थित तरीके से उन पर चर्चा करता है जबकि पर्यावरणीय अनिश्चितताओं की जांच और बेहतर तरीके से समझा जा रहा है।

अनुकूली प्रबंधन हितधारकों, प्रबंधकों और अन्य निर्णय निर्माताओं को ज्ञान की सीमा और अपूर्ण जानकारी पर कार्य करने की आवश्यकता को पहचानने में मदद करता है।

अनुकूली प्रबंधन यह स्पष्ट करके निर्णय लेने में मदद करता है कि -

• फैसले अनंतिम हैं।
• एक प्रबंधन का निर्णय हमेशा सही नहीं होना चाहिए।
• संशोधन अपेक्षित हैं।

दो प्रकार के अनुकूली प्रबंधन दृष्टिकोण हैं -

• निष्क्रिय अनुकूली प्रबंधन।
• सक्रिय अनुकूली प्रबंधन।

निष्क्रिय अनुकूली प्रबंधन

अनुकूली प्रबंधन का उद्देश्य वैज्ञानिक ज्ञान को बढ़ाना है और इस तरह अनिश्चितताओं को कम करना है।

निष्क्रिय अनुकूली प्रबंधन के भीतर, मौजूदा सूचना और समझ के आधार पर कार्रवाई का एक पसंदीदा विकल्प चुना जाता है। प्रबंधन कार्यों के परिणामों की निगरानी की जाती है, और बाद के निर्णय परिणामों के आधार पर समायोजित किए जाते हैं।

यह दृष्टिकोण सीखने और प्रभावी प्रबंधन में योगदान देता है। हालांकि, यह उन परिस्थितियों के लिए वैज्ञानिक और प्रबंधन क्षमताओं को बढ़ाने की क्षमता में सीमित है जो चयनित कार्रवाई के पाठ्यक्रम से परे हैं।

सक्रिय अनुकूली प्रबंधन

एक सक्रिय अनुकूली प्रबंधन दृष्टिकोण प्रबंधन कार्रवाई करने से पहले जानकारी की समीक्षा करता है।

एक मॉडल के बजाय प्रतिस्पर्धा, वैकल्पिक प्रणाली मॉडल की पारिस्थितिकी तंत्र और संबंधित प्रतिक्रियाओं (उदाहरण के लिए जनसांख्यिकीय परिवर्तन; मनोरंजक उपयोग) की एक श्रृंखला विकसित की जाती है। इन वैकल्पिक मॉडलों के मूल्यांकन के आधार पर प्रबंधन विकल्प चुना जाता है।

नेतृत्व-सहयोग प्रबंधन

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

सॉफ्टवेयर विकास में, नेता अक्सर इन जिम्मेदारियों को उठाते हैं। हमें कमांडरों से ज्यादा नेताओं की जरूरत है। नेता सहयोगी होते हैं और टीम के साथ काम करते हैं। अनुकूली विकास में अभ्यास के बाद सहयोगात्मक-नेतृत्व सबसे अधिक मांग है।

नेताओं के निम्नलिखित गुण हैं -

• समझ और दिशा निर्धारित करें।

• प्रभावित लोग इसमें शामिल होते हैं और मार्गदर्शन प्रदान करते हैं।

• टीम को सहयोग, सुविधा और स्थूल प्रबंधन करें।

• दिशा प्रदान करें।

• ऐसे वातावरण बनाएं जहां प्रतिभाशाली लोग अभिनव, रचनात्मक हो सकते हैं, और प्रभावी निर्णय ले सकते हैं।

• समझें कि कभी-कभार उन्हें आज्ञा देने की आवश्यकता होती है, लेकिन यह उनकी प्रमुख शैली नहीं है।