10.2: सिस्टम डेवलपमेंट लाइफ साइकिल (SDLC) मॉडल
- Page ID
- 169500
सिस्टम डेवलपमेंट लाइफ साइकिल (SDLC) मॉडल
SDLC को पहली बार 1960 के दशक में मेनफ्रेम पर चल रहे कॉर्पोरेट सिस्टम से जुड़ी बड़ी परियोजनाओं के प्रबंधन के लिए विकसित किया गया था। यह एक बहुत ही संरचित प्रक्रिया है जिसे तकनीकी, व्यवसाय, सहायक पेशेवरों सहित कई लोगों के प्रयासों के साथ बड़ी परियोजनाओं का प्रबंधन करने के लिए डिज़ाइन किया गया है। इन परियोजनाओं का निर्माण अक्सर महंगा होता है, और संगठन पर इनका बड़ा प्रभाव पड़ता है। एक असफल परियोजना या किसी गलत परियोजना को निधि देने के लिए गलत व्यावसायिक निर्णय किसी संगठन के लिए एक व्यवसाय या वित्तीय तबाही हो सकती है।
SDLC एक मॉडल है जो योजना, विश्लेषण, डिजाइन, कार्यान्वयन, रखरखाव के लिए चरणों के एक सेट की प्रक्रिया को परिभाषित करता है। अध्याय 1 में चर्चा की गई है कि एक सूचना प्रणाली (IS) में हार्डवेयर, सॉफ़्टवेयर, डेटाबेस, नेटवर्किंग, प्रोसेस और लोग शामिल हैं। SDLC का उपयोग अक्सर IS प्रोजेक्ट को प्रबंधित करने के लिए किया जाता है जिसमें एक, कुछ, या IS के सभी तत्व शामिल हो सकते हैं। आइए SDLC के पांच चरणों में से प्रत्येक के माध्यम से चलते हैं जैसा कि चित्र 10.1 में दर्शाया गया है:
- प्लानिंग। इस चरण में, किसी ऐसे व्यक्ति द्वारा अनुरोध शुरू किया जाता है जो इस विचार के प्रायोजक के रूप में कार्य करता है। अनुरोध की योग्यता और व्यवहार्यता का प्रारंभिक मूल्यांकन करने के लिए एक छोटी टीम को इकट्ठा किया जाता है। इस चरण के उद्देश्य हैं:
- यह निर्धारित करने के लिए कि अनुरोध कंपनी की रणनीति या व्यावसायिक लक्ष्यों के साथ कैसे फिट बैठता है।
- व्यवहार्यता विश्लेषण करने के लिए, जिसमें तकनीकी व्यवहार्यता का विश्लेषण शामिल है (क्या इसे बनाना संभव है?) , आर्थिक व्यवहार्यता (क्या हम ऐसा कर सकते हैं?) , और कानूनी व्यवहार्यता (क्या हमें ऐसा करने की अनुमति है?)।
- अनुरोध के लिए जाने/नहीं जाने की सिफारिश करने के लिए। यदि यह सही है, तो प्रबंधन को मंजूरी देने के लिए एक अवधारणा प्रस्ताव भी तैयार किया जाता है।
- विश्लेषण। एक बार अवधारणा प्रस्ताव स्वीकृत हो जाने के बाद, परियोजना को एक नई परियोजना टीम (पिछले चरण सहित) के साथ औपचारिक रूप दिया जाता है। अवधारणा प्रस्ताव को शुरुआती बिंदु के रूप में उपयोग करते हुए, नई प्रणाली की विशिष्ट आवश्यकताओं को निर्धारित करने के लिए परियोजना के सदस्य विभिन्न हितधारक समूहों के साथ काम करते हैं। इस चरण में कोई प्रोग्रामिंग या विकास नहीं किया गया है। इस चरण के उद्देश्य हैं:
- प्रमुख हितधारकों को पहचानें और उनका साक्षात्कार करें।
- दस्तावेज़ कुंजी प्रक्रियाएँ
- डेटा आवश्यकताओं का विकास करें
- इस चरण के परिणामस्वरूप सिस्टम-आवश्यकताएं दस्तावेज़ तैयार करने के लिए। इसमें सिस्टम का डिज़ाइन शुरू करने का विवरण है।
- डिज़ाइन। एक बार सिस्टम की आवश्यकताएं स्वीकृत हो जाने के बाद, अधिक सदस्यों को लाने के लिए टीम को फिर से कॉन्फ़िगर किया जा सकता है। इस चरण का उद्देश्य प्रोजेक्ट टीम के लिए पिछले चरण में बनाए गए सिस्टम आवश्यकताओं के दस्तावेज़ को लेना और सिस्टम के लिए आवश्यक विशिष्ट तकनीकी विवरण विकसित करना है। इसके उद्देश्य हैं:
- व्यावसायिक आवश्यकताओं को विशिष्ट तकनीकी आवश्यकता में अनुवाद करें
- उपयोगकर्ता इंटरफ़ेस, डेटाबेस, डेटा इनपुट और आउटपुट और रिपोर्ट डिज़ाइन करें
- इस चरण के परिणामस्वरूप सिस्टम-डिज़ाइन दस्तावेज़ तैयार करें। इस दस्तावेज़ में वह सब कुछ होगा जो प्रोग्रामर को सिस्टम बनाने के लिए आवश्यक होगा।
- कार्यान्वयन। एक बार सिस्टम डिज़ाइन स्वीकृत हो जाने के बाद, सॉफ़्टवेयर कोड अंततः प्रोग्रामिंग चरण में लिखा जाता है, और हार्डवेयर जैसे अन्य तत्वों के लिए विकास का प्रयास भी होता है। इसका उद्देश्य प्रारंभिक कार्य प्रणाली बनाना है। इसके उद्देश्य हैं:
- सॉफ़्टवेयर कोड और अन्य IS घटकों का विकास करें। सिस्टम- डिज़ाइन दस्तावेज़ को एक गाइड के रूप में उपयोग करते हुए, डेवलपर्स सभी IS प्रोजेक्ट घटकों को कोड या विकसित करना शुरू करते हैं।
- संरचित परीक्षणों की एक श्रृंखला के माध्यम से कार्य प्रणाली का परीक्षण करें जैसे:
- पहला यूनिट टेस्ट है, जो त्रुटियों या बग के लिए कोड के अलग-अलग हिस्सों का परीक्षण करता है।
- अगला एक सिस्टम टेस्ट है, जहां सिस्टम के विभिन्न घटकों का परीक्षण किया जाता है ताकि यह सुनिश्चित हो सके कि वे एक साथ ठीक से काम करें।
- अंत में, उपयोगकर्ता-स्वीकृति परीक्षण उन लोगों को अनुमति देता है जो सिस्टम का परीक्षण करने के लिए सॉफ़्टवेयर का उपयोग करेंगे ताकि यह सुनिश्चित हो सके कि यह उनके मानकों को पूरा करता है।
- परीक्षण के दौरान मिली किसी भी बग, त्रुटियों या समस्याओं को हल करने के लिए फिर से किसी भी सुधार का परीक्षण करें।
- यूज़र को प्रशिक्षित करें
- दस्तावेज़ प्रदान करें
- किसी भी पिछली प्रणाली से नए सिस्टम में आवश्यक रूपांतरण करें।
- परिणामस्वरूप, प्रारंभिक कार्य प्रणाली का निर्माण करें जो विश्लेषण चरण में निर्धारित आवश्यकताओं और डिजाइन चरण में विकसित डिज़ाइन को पूरा करती है।
- रख-रखाव। कार्यान्वयन का चरण पूरा होने के बाद यह चरण होता है। इस चरण में, सिस्टम में एक संरचित सहायता प्रक्रिया होनी चाहिए:
- बग रिपोर्ट करें
- बग फिक्स को परिनियोजित करें
- नई सुविधाओं के लिए अनुरोध स्वीकार करें
- लागू किए जाने वाले रिपोर्ट किए गए बग या अनुरोधित सुविधाओं की प्राथमिकताओं का मूल्यांकन करें
- सिस्टम अपडेट जारी करने और बैकअप करने के लिए एक अनुमानित और नियमित शेड्यूल को पहचानें।
- डेटा और ऐसी किसी भी चीज़ का निपटान करें जिसकी अब आवश्यकता नहीं है
संगठन अपनी आवश्यकताओं को पूरा करने के लिए इन चरणों को जोड़ या उप-विभाजित कर सकते हैं। उदाहरण के लिए, एक चरण, योजना के बजाय, एक संगठन दो चरणों का चयन कर सकता है: आरंभ, संकल्पना; या कार्यान्वयन को दो चरणों में विभाजित करना: कार्यान्वयन और परीक्षण।
वाटरफाल मॉडल
एक विशिष्ट एसडीएलसी-आधारित मॉडल वाटरफॉल मॉडल है, और नाम को अक्सर एसडीएलसी के समान माना जाता है। इसका उपयोग पाँच चरणों के साथ चित्र 10.2 में दर्शाए गए सॉफ़्टवेयर परियोजनाओं को प्रबंधित करने के लिए किया जाता है: आवश्यकताएँ, डिज़ाइन, कार्यान्वयन, सत्यापन और रखरखाव। यह मॉडल इस बात पर जोर देता है कि अगले चरण के शुरू होने से पहले प्रत्येक चरण को पूरा किया जाना चाहिए (इसलिए इसका नाम वाटरफॉल है)। उदाहरण के लिए, कार्यान्वयन चरण शुरू होने के बाद आवश्यकताओं में बदलाव की अनुमति नहीं है, या परिवर्तन की प्रक्रिया में बदलाव की मांग की जानी चाहिए और उसे मंजूरी दी जानी चाहिए। उन्हें परियोजना को आवश्यकता चरण से फिर से शुरू करने की आवश्यकता हो सकती है क्योंकि नई आवश्यकताओं को मंजूरी देने की आवश्यकता होती है, जिसके कारण कार्यान्वयन चरण शुरू होने से पहले डिज़ाइन को संशोधित किया जा सकता है।
वाटरफॉल मॉडल की कठोर संरचना की काफी कठोर होने और टीमों को पिछले चरणों में वापस जाने से बचने के लिए जोखिम से बचने के लिए आलोचना की गई है। हालाँकि, ऐसी संरचना के लाभ भी हैं। SDLC और वॉटरफॉल के कुछ फायदे और नुकसान इस प्रकार हैं:
एसडीएलसी और वाटरफॉल के फायदे और नुकसान
|
फ़ायदे |
कमियां |
|
जोखिमों की संख्या को कम करने के लिए परिवर्तनों को नियंत्रित करने और ट्रैक करने की मजबूत प्रक्रिया परियोजना को अनजाने में पटरी से उतार सकती है। |
सब कुछ रिकॉर्ड करने के लिए समय निकालें, जिससे शेड्यूल में अतिरिक्त लागत और समय लगता है। |
|
मानक और पारदर्शी प्रक्रियाएं बड़ी टीमों के प्रबंधन में मदद करती हैं। |
बैठकों में भाग लेने, अनुमोदन प्राप्त करने आदि में बहुत अधिक समय व्यतीत होता है, जिससे शेड्यूल में अतिरिक्त लागत और समय लगता है। |
|
दस्तावेज़ीकरण कर्मियों को खोने के जोखिम को कम करता है, लोगों को परियोजना में जोड़ना आसान होता है। |
कुछ सदस्य लिखने में समय बिताना पसंद नहीं करते हैं, जिससे किसी प्रोजेक्ट को पूरा करने के लिए अतिरिक्त समय की आवश्यकता होती है। |
|
प्रोजेक्ट पूरा होने के बाद भी जब भी त्रुटियां पाई जाती हैं, तो सिस्टम में किसी समस्या का पता लगाना आसान होता है। |
परिवर्तनों या ग्राहकों की प्रतिक्रिया को शामिल करना मुश्किल है क्योंकि परियोजना को एक या अधिक पिछले चरणों में वापस जाना पड़ता है, जिससे टीमें जोखिम से मुक्त हो जाती हैं। |
इन आलोचनाओं को दूर करने के लिए समय के साथ अन्य मॉडल विकसित किए जाते हैं। हम दो अन्य मॉडलों पर चर्चा करेंगे: रैपिड एप्लीकेशन डेवलपमेंट और एजाइल, एसडीएलसी के अलग-अलग तरीकों के रूप में।
रैपिड एप्लीकेशन डेवलपमेंट (RAD)
रैपिड एप्लिकेशन डेवलपमेंट (RAD) एक सॉफ्टवेयर डेवलपमेंट (या सिस्टम-डेवलपमेंट) कार्यप्रणाली है जो निरंतर आधार पर परिवर्तनों की योजना बनाने और शामिल करने पर कम ध्यान केंद्रित करती है। RAD सॉफ्टवेयर या सिस्टम के काम करने वाले मॉडल को जल्दी से बनाने, उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने और काम करने वाले मॉडल को अपडेट करने पर ध्यान केंद्रित करता है। विकास के कई पुनरावृत्तियों के बाद, एक अंतिम संस्करण विकसित और कार्यान्वित किया जाता है। आइए RAD मॉडल में चार चरणों के माध्यम से चलते हैं जैसा कि चित्र 10.3 में दर्शाया गया है।
- आवश्यकताएँ योजना। यह चरण SDLC की योजना, विश्लेषण और डिजाइन चरणों के समान है।
- यूज़र डिज़ाइन। इस चरण में, उपयोगकर्ता के प्रतिनिधि सिस्टम के डिज़ाइन को इंटरैक्टिव रूप से बनाने के लिए सिस्टम विश्लेषकों, डिज़ाइनरों और प्रोग्रामर्स के साथ काम करते हैं। इन सभी हितधारकों के साथ काम करने की एक तकनीक संयुक्त अनुप्रयोग विकास (JAD) सत्र है। JAD सत्र उन सभी प्रासंगिक उपयोगकर्ताओं को मिलता है जो सिस्टम के डिज़ाइन के बारे में एक संरचित चर्चा करने के लिए डेवलपर्स सहित विभिन्न दृष्टिकोणों, अन्य प्रमुख हितधारकों से सिस्टम के साथ बातचीत करते हैं। इसका उद्देश्य उपयोगकर्ताओं के लिए काम करने वाले मॉडल को समझना और अपनाना है और डेवलपर्स को यह समझने के लिए है कि सकारात्मक उपयोगकर्ता अनुभव प्रदान करने के लिए सिस्टम को उपयोगकर्ता के दृष्टिकोण से कैसे काम करने की आवश्यकता है।
- कंस्ट्रक्शन। निर्माण चरण में, कार्य SDLC के कार्यान्वयन चरण के समान हैं। डेवलपर्स अपनी प्रतिक्रिया को शामिल करने के लिए उपयोगकर्ताओं के साथ बातचीत करना जारी रखते हैं क्योंकि वे विकसित किए जा रहे काम करने वाले मॉडल के साथ बातचीत करते हैं। यह एक इंटरैक्टिव प्रक्रिया है, और बदलाव किए जा सकते हैं क्योंकि डेवलपर्स प्रोग्राम पर काम कर रहे हैं। जब तक उत्पाद का स्वीकार्य संस्करण विकसित नहीं हो जाता, तब तक इस चरण को उपयोगकर्ता डिज़ाइन चरण के साथ समानांतर रूप से निष्पादित किया जाता है।
- कटओवर। यह चरण SDLC कार्यान्वयन चरण के कुछ कार्यों के समान है। सिस्टम लाइव हो जाता है या पूरी तरह से तैनात होता है। नई प्रणाली का उपयोग करने के लिए पिछली स्थिति से स्थानांतरित करने के लिए आवश्यक सभी चरण यहां पूरे किए गए हैं।
SDLC या वाटरफॉल मॉडल की तुलना में, RAD कार्यप्रणाली बहुत अधिक संकुचित है। SDLC के कई चरण संयुक्त हैं, और फोकस उपयोगकर्ता की भागीदारी और पुनरावृत्ति पर है। यह कार्यप्रणाली छोटी परियोजनाओं के लिए बेहतर है और उपयोगकर्ताओं को पूरी प्रक्रिया के दौरान प्रतिक्रिया प्रदान करने की क्षमता देने का अतिरिक्त लाभ है। SDLC को अधिक दस्तावेज़ीकरण और विस्तार पर ध्यान देने की आवश्यकता है और यह बड़ी, संसाधन-गहन परियोजनाओं के लिए उपयुक्त है। आरएडी उन परियोजनाओं के लिए बेहतर है जो कम संसाधन-गहन हैं और उन्हें जल्दी से विकसित करने की आवश्यकता है। RAD के कुछ फायदे और नुकसान इस प्रकार हैं:
RAD के फायदे और नुकसान
|
फ़ायदे |
कमियां |
|
उपयोगकर्ताओं के साथ बातचीत करने की आवृत्ति के कारण गुणवत्ता बढ़ाएं |
उन सुविधाओं के कमजोर कार्यान्वयन के जोखिम जो उपयोगकर्ताओं को दिखाई नहीं देते हैं, जैसे कि सुरक्षा |
|
तैयार उत्पाद को स्वीकार करने से उपयोगकर्ताओं के इनकार के जोखिम को कम करें |
उपयोगकर्ताओं की समस्याओं को हल करने के लिए एक कार्यशील संस्करण के तेज़ टर्न-अराउंड के कारण सिस्टम में बदलाव पर नियंत्रण का अभाव। |
|
विकास के दौरान आश्चर्य से बचने के लिए, वास्तविक समय में यूज़र के अपडेट के रूप में समय-समय पर, ऑन-बजट पूरा होने की संभावनाओं में सुधार करें। |
डिज़ाइन का अभाव क्योंकि सिस्टम में बदलाव किए जा रहे हैं, अनजाने में सिस्टम के अन्य हिस्सों को प्रभावित कर सकते हैं। |
|
डेवलपर्स/विशेषज्ञों और उपयोगकर्ताओं के बीच बातचीत का समय बढ़ाएं |
डेवलपर्स के रूप में दुर्लभ संसाधन जुड़े हुए हैं, जो अन्य परियोजनाओं को धीमा कर सकते हैं। |
|
छोटे से मध्यम आकार की प्रोजेक्ट टीमों के लिए सबसे उपयुक्त |
बड़ी टीमों को स्केल करना मुश्किल है |
चंचल विकास के तरीके
एजाइल मेथोडोलॉजी कार्यप्रणाली का एक समूह है जो गुणवत्ता और विस्तार पर ध्यान केंद्रित करते हुए वृद्धिशील परिवर्तनों का उपयोग करता है। प्रत्येक वेतन वृद्धि एक निर्दिष्ट अवधि (जिसे टाइम बॉक्स कहा जाता है) में जारी की जाती है, जिससे विशेष उद्देश्यों के साथ एक नियमित रिलीज़ शेड्यूल तैयार किया जाता है। जबकि RAD से एक अलग कार्यप्रणाली माना जाता है, वे कुछ समान सिद्धांतों को साझा करते हैं: पुनरावृत्त विकास, उपयोगकर्ता सहभागिता और परिवर्तनशीलता। चुस्त कार्यप्रणाली “एजाइल मेनिफेस्टो” पर आधारित होती है, जिसे पहली बार 2001 में रिलीज़ किया गया था।
चुस्त तरीकों की विशेषताओं में शामिल हैं:
- छोटी क्रॉस-फंक्शनल टीमें जिनमें डेवलपमेंट-टीम के सदस्य और उपयोगकर्ता शामिल हैं;
- परियोजना की वर्तमान स्थिति पर चर्चा करने के लिए दैनिक स्थिति बैठकें;
- प्रत्येक परिवर्तन को पूरा करने के लिए लघु समय-सीमा में वृद्धि (दिन से एक या दो सप्ताह तक); तथा
- प्रत्येक पुनरावृत्ति के अंत में, हितधारकों को प्रदर्शित करने के लिए एक कार्यशील परियोजना पूरी हो जाती है।
संक्षेप में, एजाइल दृष्टिकोण उन कार्यों पर उच्च मूल्य डालता है जो बातचीत को बढ़ावा देते हैं, लगातार काम करने वाले संस्करण, ग्राहक/उपयोगकर्ता सहयोग का निर्माण करते हैं, और परिवर्तन के लिए त्वरित प्रतिक्रिया और प्रक्रियाओं और दस्तावेज़ीकरण पर कम जोर देते हैं। चुस्त कार्यप्रणाली का लक्ष्य गुणवत्ता वाले उत्पाद को सुनिश्चित करते हुए एक पुनरावृत्त दृष्टिकोण का लचीलापन प्रदान करना है।
ऐसे कई मॉडल हैं जो एजाइल मेथोडोलॉजी का उपयोग करके बनाए गए हैं। ऐसा ही एक उदाहरण स्क्रम डेवलपमेंट मॉडल है।
स्क्रम डेवलपमेंट मॉडल
यह मॉडल उन छोटी टीमों के लिए उपयुक्त है, जो निश्चित समय के इंटरैक्शन के भीतर सुविधाओं का एक सेट तैयार करने के लिए काम करती हैं, जैसे कि दो से चार सप्ताह, जिसे स्प्रिंट कहा जाता है। आइए स्क्रम मॉडल के चार प्रमुख तत्वों के माध्यम से चलते हैं जैसा कि चित्र 10.4 में दर्शाया गया है।
चित्र 10.4। स्क्रम प्रोजेक्ट प्रबंधन विधि। लेकवर्क्स द्वारा की गई छवि को CC BY-SA 4.0 लाइसेंस प्राप्त है
- उत्पाद बैकलॉग। यह किए जाने वाले काम की एक विस्तृत ब्रेकडाउन सूची है। सभी कार्यों को जोखिम, निर्भरता, मिशन-क्रिटिकल आदि मानदंडों के आधार पर प्राथमिकता दी जाती है, डेवलपर्स अपने स्वयं के कार्यों का चयन करते हैं और काम पूरा करने के लिए स्वयं को व्यवस्थित करते हैं।
- स्प्रिंट बैकलॉग। यह अगले स्प्रिंट में किए जाने वाले काम की एक सूची है।
- स्प्रिंट। यह एक निश्चित समय है, जैसे कि 1-दिन, 2-सप्ताह या 4-सप्ताह, जैसा कि टीम द्वारा सहमति व्यक्त की गई है। दैनिक प्रगति मीटिंग को दैनिक स्क्रम कहा जाता है, आमतौर पर एक स्क्रम मास्टर द्वारा सुगम की जाने वाली 10-15 मिनट की एक छोटी बैठक, जिसकी भूमिका टीम के लिए बाधाओं को दूर करना है।
- सॉफ्टवेयर ई की कार्य वृद्धि। यह एक कार्यशील संस्करण है जो स्प्रिंट के अंत में ब्रेकडाउन सूचियों के साथ वृद्धिशील रूप से बनाया गया है।
लीन मेथोडोलॉजी
एक आखिरी कार्यप्रणाली जिस पर हम चर्चा करेंगे, वह है एरिक रीस द्वारा बिजनेस बेस्टसेलर द लीन स्टार्टअप से ली गई एक अपेक्षाकृत नई अवधारणा।
यह कार्यप्रणाली एक प्रारंभिक विचार लेने और न्यूनतम व्यवहार्य उत्पाद (MVP) विकसित करने पर केंद्रित है। MVP एक कार्यशील सॉफ़्टवेयर एप्लिकेशन है जिसमें प्रोजेक्ट के पीछे के विचार को प्रदर्शित करने के लिए पर्याप्त कार्यक्षमता है। एक बार एमवीपी विकसित हो जाने के बाद, यह संभावित उपयोगकर्ताओं को समीक्षा के लिए दिया जाता है। MVP पर प्रतिक्रिया दो रूपों में उत्पन्न होती है: (1) उपयोगकर्ताओं के साथ प्रत्यक्ष अवलोकन और चर्चा, और (2) सॉफ़्टवेयर से ही एकत्र किए गए उपयोग के आंकड़े। फीडबैक के इन दो रूपों का उपयोग करते हुए, टीम यह निर्धारित करती है कि उन्हें एक ही दिशा में जारी रखना चाहिए या प्रोजेक्ट के मूल विचार पर पुनर्विचार करना चाहिए, कार्यों को बदलना चाहिए, या एक नया एमवीपी बनाना चाहिए। रणनीति में इस बदलाव को एक धुरी कहा जाता है। एमवीपी के कई पुनरावृत्तियां विकसित की जाती हैं, जिसमें फीडबैक के आधार पर हर बार नए फ़ंक्शन जोड़े जाते हैं, जब तक कि अंतिम उत्पाद पूरा नहीं हो जाता।
लीन मेथोडोलॉजी और अन्य तरीकों के बीच सबसे बड़ा अंतर यह है कि प्रोजेक्ट लॉन्च होने पर सिस्टम की आवश्यकताओं का पूरा सेट अज्ञात है। जैसे-जैसे परियोजना की प्रत्येक पुनरावृत्ति जारी होती है, एकत्रित आंकड़ों और प्रतिक्रिया का उपयोग आवश्यकताओं को निर्धारित करने के लिए किया जाता है। लीन मेथोडोलॉजी एक उद्यमी वातावरण में सबसे अच्छा काम करती है जहां एक कंपनी यह निर्धारित करने में रुचि रखती है कि सॉफ्टवेयर एप्लिकेशन के लिए उनका विचार विकसित करने लायक है या नहीं।
सन्दर्भ:
एजाइल सॉफ्टवेयर डेवलपमेंट के लिए मेनिफेस्टो (2001)। 10 दिसंबर, 2020 को http://agilemanifesto.org/ से लिया गया
द लीन स्टार्टअप। 9 दिसंबर, 2020 को http://theleanstartup.com/ से लिया गया