About software engineer in hindi support change, spiral model and waterfall model in hindi सॉफ्टवेयर इंजीनियर के बारे में हिंदी में परिवर्तन, सर्पिल मॉडल और झरना मॉडल का समर्थन करें हिंदी में!

 विवरण:-

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

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

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

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

वॉटरफ़ॉल मॉडल

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

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

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

• आवश्यकता दस्तावेज़

• प्रोजेक्ट योजना

• डिज़ाइन दस्तावेज़ (वास्तुकला, सिस्टम, विस्तृत)

• परीक्षण योजना और परीक्षण रिपोर्ट

• अंतिम कोड

• सॉफ़्टवेयर मैनुअल (जैसे, उपयोगकर्ता, इंस्टॉलेशन, आदि)

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

वाटरफॉल मॉडल, हालांकि व्यापक रूप से उपयोग किया जाता है, इसमें कुछ मजबूत सीमाएँ हैं।

कुछ प्रमुख सीमाएँ हैं:

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

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

3. यह "बिग बैंग" दृष्टिकोण का अनुसरण करता है - पूरा सॉफ़्टवेयर अंत में एक ही बार में वितरित किया जाता है। इसमें भारी जोखिम शामिल हैं, क्योंकि उपयोगकर्ता को अंत तक पता नहीं होता कि उन्हें क्या मिल रहा है। इसके अलावा, यदि परियोजना के बीच में पैसे खत्म हो जाते हैं, तो कोई सॉफ़्टवेयर नहीं होगा। यानी, इसमें "सब कुछ या कुछ भी नहीं" मूल्य प्रस्ताव है।

4. यह एक दस्तावेज़-संचालित प्रक्रिया है जिसके लिए प्रत्येक चरण के अंत में औपचारिक दस्तावेज़ों की आवश्यकता होती है।

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

सर्पिल मॉडल

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

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

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

 दृष्टिकोण अब व्यापक रूप से उपयोग किया जाता है।