software development life cycle models
Life Cycle Model( जीवन चक्र मॉडल)
एक सॉफ्टवेयर जीवन चक्र मॉडल (जिसे प्रक्रिया मॉडल भी कहा जाता है) एक वर्णनात्मक और आरेखीय है सॉफ्टवेयर जीवन चक्र का प्रतिनिधित्व। एक जीवन चक्र मॉडल आवश्यक सभी गतिविधियों का प्रतिनिधित्व करता है एक सॉफ्टवेयर उत्पाद को उसके जीवन चक्र चरणों के माध्यम से पारगमन करने के लिए। यह ऑर्डर को भी कैप्चर करता है जिसमें ये गतिविधियां की जानी हैं। दूसरे शब्दों में, एक जीवन चक्र मॉडल अलग-अलग मैप करता है एक सॉफ्टवेयर उत्पाद की शुरुआत से सेवानिवृत्ति तक की गई गतिविधियाँ। अलग जीवन चक्र मॉडल बुनियादी विकास गतिविधियों को चरणों में अलग-अलग तरीकों से मैप कर सकते हैं। इस प्रकार, कोई बात नहीं किस जीवन चक्र मॉडल का पालन किया जाता है, बुनियादी गतिविधियों को सभी जीवन चक्र मॉडल में शामिल किया जाता है हालांकि गतिविधियों को विभिन्न जीवन चक्र मॉडल में अलग-अलग क्रम में किया जा सकता है। दौरान जीवन चक्र की किसी भी अवस्था में, एक से अधिक गतिविधियाँ भी की जा सकती हैं।
THE NEED FOR A SOFTWARE LIFE CYCLE MODEL(सॉफ़्टवेयर जीवन चक्र मॉडल की आवश्यकता)
विकास दल को विशेष परियोजना के लिए एक उपयुक्त जीवन चक्र मॉडल की पहचान करनी चाहिए और फिर उसका पालन करें। एक विशेष जीवन चक्र मॉडल का उपयोग किए बिना एक सॉफ्टवेयर का विकास उत्पाद व्यवस्थित और अनुशासित तरीके से नहीं होगा। जब एक सॉफ्टवेयर उत्पाद हो रहा है एक टीम द्वारा विकसित किया गया है, टीम के सदस्यों के बीच कब और कब के बारे में स्पष्ट समझ होनी चाहिए क्या करें। अन्यथा यह अराजकता और परियोजना की विफलता का कारण बनेगा। इस समस्या को चित्रित किया जा सकता है एक उदाहरण का उपयोग करके। मान लीजिए एक सॉफ्टवेयर विकास समस्या कई भागों में विभाजित है और भागों को टीम के सदस्यों को सौंपा गया है। तब से, मान लीजिए कि टीम के सदस्य हैं उन्हें सौंपे गए भागों को किसी भी तरह से विकसित करने की स्वतंत्रता की अनुमति दी। यह है संभव है कि एक सदस्य अपने हिस्से के लिए कोड लिखना शुरू कर दे, दूसरा तय कर सकता है पहले परीक्षण दस्तावेज तैयार करें, और कुछ अन्य इंजीनियर डिजाइन चरण के साथ शुरू कर सकते हैं उसे सौंपे गए हिस्से। यह परियोजना की विफलता के लिए एकदम सही व्यंजनों में से एक होगा। एक सॉफ्टवेयर जीवन चक्र मॉडल प्रत्येक चरण के लिए प्रवेश और निकास मानदंड को परिभाषित करता है। एक चरण तभी शुरू हो सकता है जब इसकी चरण-प्रवेश मानदंड संतुष्ट हैं। तो सॉफ्टवेयर जीवन चक्र के बिना प्रवेश और निकास मॉडल किसी चरण के मानदंड को पहचाना नहीं जा सकता। सॉफ्टवेयर जीवन चक्र मॉडल के बिना यह मुश्किल हो जाता है सॉफ्टवेयर परियोजना प्रबंधकों के लिए परियोजना की प्रगति की निगरानी के लिए।
Different software life cycle models(विभिन्न सॉफ्टवेयर जीवन चक्र मॉडल )
अब तक कई जीवन चक्र मॉडल प्रस्तावित किए गए हैं। उनमें से प्रत्येक के कुछ फायदे भी हैं कुछ कमियाँ। कुछ महत्वपूर्ण और आमतौर पर इस्तेमाल किए जाने वाले जीवन चक्र मॉडल इस प्रकार हैं:
- Classical Waterfall Model
- Iterative Waterfall Model
- Prototyping Model
- Evolutionary Model
- Spiral Model
1.CLASSICAL WATERFALL MODEL
सॉफ्टवेयर विकसित करने के लिए शास्त्रीय जलप्रपात मॉडल सहज रूप से सबसे स्पष्ट तरीका है। यद्यपि शास्त्रीय झरना मॉडल सुरुचिपूर्ण और सहज ज्ञान युक्त है, यह एक व्यावहारिक मॉडल नहीं है समझ में आता है कि इसका उपयोग वास्तविक सॉफ्टवेयर विकास परियोजनाओं में नहीं किया जा सकता है। इस प्रकार, यह मॉडल हो सकता है सॉफ्टवेयर विकसित करने का एक सैद्धांतिक तरीका माना जाता है। लेकिन अन्य सभी जीवन चक्र मॉडल हैं अनिवार्य रूप से शास्त्रीय जलप्रपात मॉडल से लिया गया है। तो, दूसरे की सराहना करने में सक्षम होने के लिए जीवन चक्र मॉडल शास्त्रीय जलप्रपात मॉडल सीखना आवश्यक है। शास्त्रीय झरना मॉडल चित्र में दिखाए अनुसार जीवन चक्र को निम्न चरणों में विभाजित करता है:
Feasibility study:-
व्यवहार्यता अध्ययन का मुख्य उद्देश्य यह निर्धारित करना है कि क्या यह होगा उत्पाद विकसित करने के लिए वित्तीय और तकनीकी रूप से व्यवहार्य।
- सबसे पहले प्रोजेक्ट मैनेजर या टीम लीडर यह समझने की कोशिश करते हैं कि क्या है क्लाइंट साइड पर जाकर किया जाना आवश्यक है। वे विभिन्न इनपुट डेटा का अध्ययन करते हैं सिस्टम और आउटपुट डेटा सिस्टम द्वारा उत्पादित किया जाना है। वे अध्ययन करते हैं कि किस प्रकार की प्रसंस्करण इन आंकड़ों पर किए जाने की आवश्यकता है और वे इस पर विभिन्न बाधाओं को देखते हैं प्रणाली का व्यवहार
- समस्या की समग्र समझ होने के बाद वे अलग-अलग जांच करते हैं समाधान जो संभव हैं। फिर वे किस तरह के संदर्भ में प्रत्येक समाधान की जांच करते हैं आवश्यक संसाधनों की, विकास की लागत क्या होगी और क्या होगी प्रत्येक समाधान के लिए विकास का समय।
- इस विश्लेषण के आधार पर वे सबसे अच्छा समाधान चुनते हैं और निर्धारित करते हैं कि समाधान है या नहीं आर्थिक और तकनीकी रूप से संभव है। वे जांचते हैं कि ग्राहक का बजट पूरा होगा या नहीं उत्पाद की लागत और क्या उनके पास इस क्षेत्र में पर्याप्त तकनीकी विशेषज्ञता है विकास।
Requirements analysis and specification:-
आवश्यकताओं के विश्लेषण का उद्देश्य और विनिर्देश चरण ग्राहक की सटीक आवश्यकताओं और दस्तावेज़ को समझना है उन्हें ठीक से। इस चरण में दो अलग-अलग गतिविधियाँ शामिल हैं,
- Requirements gathering and analysis( आवश्यकताओं को इकट्ठा करना और विश्लेषण)
- Requirements specification(आवश्यक मापदंड)
आवश्यकताओं को एकत्रित करने की गतिविधि का लक्ष्य सभी प्रासंगिक जानकारी एकत्र करना है विकसित किए जाने वाले उत्पाद के बारे में ग्राहक। यह ग्राहक को स्पष्ट रूप से समझने के लिए किया जाता है आवश्यकताएं ताकि अपूर्णता और विसंगतियां दूर हो जाएं।
आवश्यकताओं को एकत्रित करने की गतिविधि का लक्ष्य सभी प्रासंगिक जानकारी एकत्र करना है विकसित किए जाने वाले उत्पाद के बारे में ग्राहक। यह ग्राहक को स्पष्ट रूप से समझने के लिए किया जाता है आवश्यकताएं ताकि अपूर्णता और विसंगतियां दूर हो जाएं। उत्पाद के संबंध में सभी प्रासंगिक डेटा एकत्र करके आवश्यकताओं का विश्लेषण गतिविधि शुरू की जाती है उत्पाद के उपयोगकर्ताओं से और ग्राहक से साक्षात्कार के माध्यम से विकसित किया जाना है और चर्चाएँ। उदाहरण के लिए, एक व्यापार लेखा सॉफ्टवेयर की आवश्यकताओं का विश्लेषण करने के लिए एक संगठन द्वारा आवश्यक, विश्लेषक संगठन के सभी लेखाकारों का साक्षात्कार कर सकता है उनकी आवश्यकताओं का पता लगाएं। ऐसे उपयोगकर्ताओं के समूह से एकत्र किए गए डेटा में आमतौर पर शामिल होता है कई विरोधाभास और अस्पष्टताएं, चूंकि प्रत्येक उपयोगकर्ता के पास आमतौर पर केवल एक आंशिक और होता है सिस्टम का अधूरा दृश्य। इसलिए सभी अस्पष्टताओं की पहचान करना आवश्यक है और आवश्यकताओं में विरोधाभास और उन्हें आगे की चर्चाओं के माध्यम से हल करें ग्राहक। आखिरकार सभी अस्पष्टताओं, विसंगतियों और अपूर्णता को सुलझा लिया गया है और सभी आवश्यकताओं को ठीक से समझा गया है, आवश्यकताओं की विशिष्टता गतिविधि शुरू हो सकती है। दौरान इस गतिविधि में, उपयोगकर्ता की आवश्यकताओं को व्यवस्थित रूप से एक सॉफ़्टवेयर आवश्यकताएँ में व्यवस्थित किया जाता है विशिष्टता (एसआरएस) दस्तावेज़। आवश्यकताओं के दौरान पहचाने गए ग्राहक की आवश्यकताएं एकत्रीकरण और विश्लेषण गतिविधि को एसआरएस दस्तावेज़ में व्यवस्थित किया जाता है। के महत्वपूर्ण घटक यह दस्तावेज़ कार्यात्मक आवश्यकताएं, गैर-कार्यात्मक आवश्यकताएं और लक्ष्य हैं कार्यान्वयन।
Design:-
डिजाइन चरण का लक्ष्य एसआरएस में निर्दिष्ट आवश्यकताओं को बदलना है दस्तावेज़ को एक संरचना में जो कुछ प्रोग्रामिंग भाषा में कार्यान्वयन के लिए उपयुक्त है। में तकनीकी शब्दों में, डिज़ाइन चरण के दौरान सॉफ़्टवेयर आर्किटेक्चर SRS से लिया गया है दस्तावेज़। दो अलग-अलग दृष्टिकोण उपलब्ध हैं: पारंपरिक डिजाइन दृष्टिकोण और वस्तु-उन्मुख डिजाइन दृष्टिकोण।
Traditional design approach-
पारंपरिक डिजाइन में दो अलग-अलग गतिविधियां होती हैं; पहला आवश्यकताओं के विनिर्देशों का एक संरचित विश्लेषण किया जाता है जहां विस्तृत समस्या की संरचना की जांच की जाती है। इसके बाद एक संरचित डिजाइन गतिविधि होती है। संरचित डिजाइन के दौरान, संरचित विश्लेषण के परिणाम में परिवर्तित हो जाते हैं सॉफ्टवेर डिज़ाइनObject-oriented design approach:-
इस तकनीक में, विभिन्न वस्तुएं जो घटित होती हैं समस्या डोमेन और समाधान डोमेन पहले पहचाने जाते हैं, और अलग इन वस्तुओं के बीच मौजूद संबंधों की पहचान की जाती है। वस्तु संरचना आगे है विस्तृत डिजाइन प्राप्त करने के लिए परिष्कृत।
Coding and unit testing
कोडिंग चरण का उद्देश्य (जिसे कभी-कभी सॉफ्टवेयर विकास का कार्यान्वयन चरण) सॉफ्टवेयर डिजाइन को स्रोत में बदलना है कोड। डिजाइन के प्रत्येक घटक को प्रोग्राम मॉड्यूल के रूप में कार्यान्वित किया जाता है। का अंतिम उत्पाद यह चरण प्रोग्राम मॉड्यूल का एक सेट है जिसे व्यक्तिगत रूप से परीक्षण किया गया है। इस चरण के दौरान, प्रत्येक मॉड्यूल सभी व्यक्तिगत मॉड्यूल के सही काम को निर्धारित करने के लिए परीक्षण किया गया है। उसमें शामिल है प्रत्येक मॉड्यूल का अलगाव में परीक्षण करना क्योंकि यह पहचानी गई त्रुटियों को डीबग करने का सबसे प्रभावी तरीका है यह अवस्था।
Integration and system testing
एक बार उनके पास विभिन्न मॉड्यूल का एकीकरण किया जाता है कोडित और इकाई परीक्षण किया गया। एकीकरण और सिस्टम परीक्षण चरण के दौरान, मॉड्यूल हैं योजनाबद्ध तरीके से एकीकृत किया गया है। सॉफ्टवेयर उत्पाद बनाने वाले विभिन्न मॉड्यूल लगभग हैं एक शॉट में कभी एकीकृत नहीं हुआ। एकीकरण सामान्य रूप से कई में वृद्धिशील रूप से किया जाता है कदम। प्रत्येक एकीकरण चरण के दौरान, आंशिक रूप से एकीकृत प्रणाली का परीक्षण किया जाता है और इसका एक सेट होता है पहले से नियोजित मॉड्यूल इसमें जोड़े जाते हैं। अंत में, जब सभी मॉड्यूल सफलतापूर्वक हो गए हैं एकीकृत और परीक्षण किया गया, सिस्टम परीक्षण किया जाता है। सिस्टम परीक्षण का लक्ष्य यह सुनिश्चित करना है विकसित प्रणाली एसआरएस दस्तावेज़ में निर्धारित अपनी आवश्यकताओं के अनुरूप है। सिस्टम परीक्षण आमतौर पर तीन अलग-अलग प्रकार की परीक्षण गतिविधियाँ होती हैं:
- α – testing: It is the system testing performed by the development team.
- β –testing: It is the system testing performed by a friendly set of customers.
- Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.
सिस्टम टेस्टिंग आमतौर पर सिस्टम टेस्ट प्लान के अनुसार योजनाबद्ध तरीके से किया जाता है दस्तावेज़। सिस्टम परीक्षण योजना उन सभी परीक्षण-संबंधी गतिविधियों की पहचान करती है जिन्हें निष्पादित किया जाना चाहिए परीक्षण के कार्यक्रम को निर्दिष्ट करता है, और संसाधन आवंटित करता है। यह सभी परीक्षण मामलों को भी सूचीबद्ध करता है और प्रत्येक परीक्षण मामले के लिए अपेक्षित आउटपुट।
- उत्पाद विकास चरण के दौरान खोजी गई त्रुटियों को सुधारना। ये है सुधारात्मक रखरखाव कहा जाता है।
- प्रणाली के कार्यान्वयन में सुधार, और की कार्यक्षमता में वृद्धि ग्राहकों की आवश्यकताओं के अनुसार प्रणाली। इसे संपूर्ण रखरखाव कहा जाता है।
- नए वातावरण में काम करने के लिए सॉफ्टवेयर को पोर्ट करना। उदाहरण के लिए, पोर्टिंग हो सकती है सॉफ़्टवेयर को नए कंप्यूटर प्लेटफ़ॉर्म पर या नए ऑपरेटिंग के साथ काम करने के लिए आवश्यक है व्यवस्था। इसे अनुकूली रखरखाव कहा जाता है।
Good article
ReplyDelete