spiral model in software engineering
what is Spiral Model
सॉफ्टवेयर डेवलपमेंट का स्पाइरल मॉडल अंजीर में दिखाया गया है। 4.1। आरेखीय प्रतिनिधित्व यह मॉडल कई लूपों के साथ एक सर्पिल जैसा दिखता है। सर्पिल में लूपों की सही संख्या है निश्चित नहीं। सर्पिल का प्रत्येक लूप सॉफ्टवेयर प्रक्रिया के एक चरण का प्रतिनिधित्व करता है। उदाहरण के लिए, द अंतरतम पाश व्यवहार्यता अध्ययन, आवश्यकताओं के साथ अगले पाश से संबंधित हो सकता है विनिर्देश, डिजाइन के साथ अगला, और इसी तरह। इस मॉडल में प्रत्येक चरण को चार भागों में विभाजित किया गया है सेक्टर (या चतुर्भुज) जैसा कि अंजीर में दिखाया गया है। 4.1। प्रत्येक के दौरान निम्नलिखित गतिविधियां की जाती हैं एक सर्पिल मॉडल(Spiral Model) का चरण।
Spiral Model Picture
First quadrant (Objective Setting)
- पहले चतुर्थांश के दौरान, चरण के उद्देश्यों की पहचान करना आवश्यक है।
- इन उद्देश्यों से जुड़े जोखिमों की जांच करें।
Second Quadrant (Risk Assessment and Reduction)
- प्रत्येक चिन्हित परियोजना जोखिम के लिए एक विस्तृत विश्लेषण किया जाता है।
- जोखिमों को कम करने के लिए कदम उठाए गए हैं। उदाहरण के लिए, यदि कोई जोखिम है कि आवश्यकताएँ अनुपयुक्त हैं, एक प्रोटोटाइप प्रणाली विकसित की जा सकती है
Third Quadrant (Development and Validation)
- पहचान को हल करने के बाद उत्पाद के अगले स्तर को विकसित और मान्य करें जोखिम।
Fourth Quadrant (Review and Planning)
- ग्राहक के साथ अब तक प्राप्त परिणामों की समीक्षा करें और अगले पुनरावृत्ति की योजना बनाएं सर्पिल के आसपास।
- प्रत्येक पुनरावृत्ति के साथ सॉफ्टवेयर का उत्तरोत्तर अधिक पूर्ण संस्करण बनता है सर्पिल के आसपास।
Circumstances to use spiral model( सर्पिल मॉडल का उपयोग करने की परिस्थितियाँ)
सर्पिल मॉडल को मेटा मॉडल कहा जाता है क्योंकि इसमें अन्य सभी जीवन चक्र मॉडल शामिल होते हैं। जोखिम हैंडलिंग स्वाभाविक रूप से इस मॉडल में निर्मित है। सर्पिल मॉडल के विकास के लिए उपयुक्त है तकनीकी रूप से चुनौतीपूर्ण सॉफ्टवेयर उत्पाद जो कई प्रकार के जोखिमों से ग्रस्त हैं। हालाँकि, यह मॉडल अन्य मॉडलों की तुलना में बहुत अधिक जटिल है - यह संभवतः इसके उपयोग को रोकने वाला एक कारक है सामान्य परियोजनाएं
Comparison of different life-cycle models (विभिन्न जीवन-चक्र मॉडलों की तुलना)
शास्त्रीय जलप्रपात मॉडल को मूल मॉडल और अन्य सभी जीवन चक्र के रूप में माना जा सकता है इस मॉडल के अलंकरण के रूप में मॉडल। हालाँकि, शास्त्रीय जलप्रपात मॉडल का उपयोग नहीं किया जा सकता है व्यावहारिक विकास परियोजनाओं में, चूंकि यह मॉडल त्रुटियों को संभालने के लिए किसी तंत्र का समर्थन नहीं करता है किसी भी चरण के दौरान प्रतिबद्ध।
पुनरावृत्त जलप्रपात मॉडल में यह समस्या दूर हो गई है। पुनरावृत्त जलप्रपात मॉडल है शायद अब तक का सबसे व्यापक रूप से इस्तेमाल किया जाने वाला सॉफ्टवेयर विकास मॉडल विकसित हुआ है। यह मॉडल सरल है समझने और उपयोग करने के लिए। हालाँकि यह मॉडल केवल अच्छी तरह से समझी गई समस्याओं के लिए उपयुक्त है; यह है बहुत बड़ी परियोजनाओं और कई जोखिमों के अधीन परियोजनाओं के लिए उपयुक्त नहीं है।
प्रोटोटाइप मॉडल उन परियोजनाओं के लिए उपयुक्त है जिनके लिए या तो उपयोगकर्ता की आवश्यकता होती है या अंतर्निहित तकनीकी पहलुओं को अच्छी तरह से समझा नहीं गया है। यह मॉडल विशेष रूप से लोकप्रिय है परियोजनाओं के उपयोगकर्ता-इंटरफ़ेस भाग का विकास
विकासवादी दृष्टिकोण बड़ी समस्याओं के लिए उपयुक्त है जिन्हें एक सेट में विघटित किया जा सकता है वृद्धिशील विकास और वितरण के लिए मॉड्यूल। यह मॉडल वस्तु उन्मुख विकास परियोजनाओं के लिए भी व्यापक रूप से उपयोग किया जाता है। बेशक, इस मॉडल का उपयोग तभी किया जा सकता है जब वृद्धिशील वितरण हो प्रणाली ग्राहक के लिए स्वीकार्य है
सर्पिल मॉडल को मेटा मॉडल कहा जाता है क्योंकि इसमें अन्य सभी जीवन चक्र मॉडल शामिल होते हैं। जोखिम हैंडलिंग स्वाभाविक रूप से इस मॉडल में निर्मित है। सर्पिल मॉडल के विकास के लिए उपयुक्त है तकनीकी रूप से चुनौतीपूर्ण सॉफ्टवेयर उत्पाद जो कई प्रकार के जोखिमों से ग्रस्त हैं। हालाँकि, यह मॉडल अन्य मॉडलों की तुलना में बहुत अधिक जटिल है - यह संभवतः इसके उपयोग को रोकने वाला एक कारक है सामान्य परियोजनाएं।
विभिन्न सॉफ्टवेयर जीवन चक्र मॉडल की तुलना ग्राहक के दृष्टिकोण से की जा सकती है। प्रारंभ में, विकास टीम में ग्राहकों का विश्वास आमतौर पर उच्च होता है, चाहे कुछ भी हो विकास मॉडल का पालन किया। लंबी विकास प्रक्रिया के दौरान, ग्राहकों का विश्वास सामान्य रूप से बंद हो जाता है, क्योंकि कोई भी कार्यशील उत्पाद तुरंत दिखाई नहीं देता है। डेवलपर्स ग्राहक का जवाब देते हैं तकनीकी भाषा का उपयोग करने वाले प्रश्नों और देरी की घोषणा की जाती है। इससे ग्राहकों में रोष है। दूसरी ओर, एक विकासवादी दृष्टिकोण ग्राहक को कार्य के साथ प्रयोग करने देता है उत्पाद अखंड दृष्टिकोण से बहुत पहले। का एक और महत्वपूर्ण लाभ है वृद्धिशील मॉडल यह है कि यह पूरी तरह से नए के लिए उपयोग किए जाने के ग्राहक के आघात को कम करता है व्यवस्था। वृद्धिशील चरणों के माध्यम से उत्पाद का क्रमिक परिचय समय प्रदान करता है ग्राहक नए उत्पाद को समायोजित करने के लिए। साथ ही, ग्राहक के वित्तीय दृष्टिकोण से, वृद्धिशील विकास के लिए बड़े अग्रिम पूंजी परिव्यय की आवश्यकता नहीं होती है। ग्राहक ऑर्डर कर सकता है वृद्धिशील संस्करणों के रूप में और जब वह उन्हें वहन कर सकता है।
SRS(software requirement specification)in hindi(आवश्यकता विश्लेषण और विशिष्टता)
इससे पहले कि हम अपना सॉफ्टवेयर विकसित करना शुरू करें, हमारे लिए यह समझना और समझना काफी आवश्यक हो जाता है ग्राहक की सटीक आवश्यकता का दस्तावेज। विकास दल के अनुभवी सदस्य इस कार्य को करें। उन्हें सिस्टम एनालिस्ट कहा जाता है।
विश्लेषक सभी सूचनाओं को एकत्रित करके आवश्यकताओं को एकत्र करना और विश्लेषण गतिविधि शुरू करता है ग्राहक से जो सिस्टम की आवश्यकताओं को विकसित करने के लिए इस्तेमाल किया जा सकता है। वह तो उत्पाद की स्पष्ट और गहन समझ प्राप्त करने के लिए एकत्रित जानकारी का विश्लेषण करता है प्रारंभिक से सभी अस्पष्टताओं और विसंगतियों को दूर करने की दृष्टि से विकसित किया जाना चाहिए समस्या की ग्राहक धारणा। परियोजना से संबंधित निम्नलिखित बुनियादी प्रश्न समस्या की अच्छी समझ प्राप्त करने के लिए विश्लेषक द्वारा स्पष्ट रूप से समझा जाना चाहिए
- समस्या क्या है?
- समस्या का समाधान करना क्यों ज़रूरी है?
- समस्या के संभावित समाधान क्या हैं?
- सिस्टम में डेटा इनपुट वास्तव में क्या हैं और डेटा आउटपुट वास्तव में क्या हैं व्यवस्था? /li>
- समस्या का समाधान करते समय संभावित जटिलताएं क्या हो सकती हैं?
- अगर कोई बाहरी सॉफ्टवेयर या हार्डवेयर है जिसकी मदद से विकसित सॉफ्टवेयर को करना है इंटरफ़ेस, तो वास्तव में बाहरी सिस्टम के साथ डेटा इंटरचेंज स्वरूप क्या होगा होना?
विश्लेषक ग्राहक की सटीक आवश्यकताओं को समझने के बाद, वह पहचानने के लिए आगे बढ़ता है और विभिन्न आवश्यकताओं की समस्याओं को हल करें। सबसे महत्वपूर्ण आवश्यकताओं की समस्या है कि विश्लेषक को विसंगतियों, विसंगतियों, और की समस्याओं की पहचान करना और उन्हें समाप्त करना है अधूरापन। जब विश्लेषक किसी भी विसंगतियों, विसंगतियों या अपूर्णता का पता लगाता है एकत्रित आवश्यकताओं, वह अंतिम उपयोगकर्ताओं और ग्राहकों के साथ आगे की चर्चा करके उनका समाधान करता है
Parts of a SRS document in hindi
- The important parts of SRS document are:
सिस्टम की कार्यात्मक आवश्यकताएं सिस्टम की गैर-कार्यात्मक आवश्यकताएं, और कार्यान्वयन के लक्ष्य
Functional requirements:-
कार्यात्मक आवश्यकताएं भाग सिस्टम से आवश्यक कार्यात्मकताओं पर चर्चा करता है। सिस्टम को उच्च स्तरीय कार्यों का एक सेट करने के लिए माना जाता है {f मैं }. का कार्यात्मक दृश्य सिस्टम को अंजीर में दिखाया गया है। 5.1। प्रत्येक समारोह एफ मैं व्यवस्था का परिवर्तन माना जा सकता है इनपुट डेटा का एक सेट (ii) आउटपुट डेटा के संबंधित सेट के लिए (ओ मैं ). उपयोगकर्ता कुछ प्राप्त कर सकता है एक उच्च-स्तरीय फ़ंक्शन का उपयोग करके किया गया सार्थक कार्य।
Nonfunctional requirements:- (गैर-कार्यात्मक आवश्यकताएं)
गैर-कार्यात्मक आवश्यकताएं सिस्टम की विशेषताओं से संबंधित हैं जो नहीं हो सकती हैं कार्यों के रूप में व्यक्त - जैसे सिस्टम की रखरखाव, सिस्टम की पोर्टेबिलिटी, प्रणाली की प्रयोज्यता, आदि
Goals of implementation( कार्यान्वयन के लक्ष्य)
कार्यान्वयन भाग के लक्ष्य विकास के संबंध में कुछ सामान्य सुझावों का दस्तावेजीकरण करते हैं। ये सुझाव डिज़ाइन लक्ष्यों के बीच व्यापार-बंद का मार्गदर्शन करते हैं। कार्यान्वयन अनुभाग के लक्ष्य में आवश्यक हो सकने वाली सिस्टम कार्यात्मकताओं में संशोधन जैसे मुद्दों को दस्तावेज कर सकता है भविष्य, भविष्य में समर्थित होने वाले नए उपकरण, पुन: प्रयोज्य मुद्दे, आदि। ये आइटम हैं जिसे विकासकर्ता विकास के दौरान अपने दिमाग में रख सकते हैं ताकि विकसित प्रणाली कुछ पहलुओं को पूरा कर सकते हैं जिनकी तत्काल आवश्यकता नहीं है।
Identifying functional requirements from a problem description ( समस्या विवरण से कार्यात्मक आवश्यकताओं की पहचान करना)
उच्च-स्तरीय कार्यात्मक आवश्यकताओं को अक्सर या तो अनौपचारिक रूप से पहचानने की आवश्यकता होती है समस्या विवरण दस्तावेज़ या समस्या की वैचारिक समझ से। प्रत्येक उच्च स्तरीय आवश्यकता कुछ सार्थक प्रदर्शन करने के लिए कुछ उपयोगकर्ता द्वारा सिस्टम उपयोग के तरीके की विशेषता बताती है काम का भाग। सिस्टम के कई प्रकार के उपयोगकर्ता और उनकी आवश्यकताएं हो सकती हैं प्रणाली बहुत भिन्न हो सकती है। इसलिए, विभिन्न प्रकार के उपयोगकर्ताओं की पहचान करना अक्सर उपयोगी होता है जो सिस्टम का उपयोग कर सकते हैं और फिर प्रत्येक उपयोगकर्ता के दृष्टिकोण से आवश्यकताओं की पहचान करने का प्रयास कर सकते हैं।
Example;-
पुस्तकालय प्रणाली के मामले पर विचार करें, जहाँ
F1:Search Book function
Input: an author’s name
Output: details of the author’s books and the location of these books in the library
तो फंक्शन सर्च बुक (F1) लेखक का नाम लेता है और इसे पुस्तक विवरण में बदल देता है। कार्यात्मक आवश्यकताएं वास्तव में उच्च-स्तरीय आवश्यकताओं के एक सेट का वर्णन करती हैं, जहां प्रत्येक उच्च-स्तर आवश्यकता उपयोगकर्ता से कुछ डेटा लेती है और आउटपुट के रूप में उपयोगकर्ता को कुछ डेटा प्रदान करती है। भी प्रत्येक उच्च-स्तरीय आवश्यकता में कई अन्य कार्य शामिल हो सकते हैं।
Documenting functional requirements (कार्यात्मक आवश्यकताओं का दस्तावेजीकरण)
कार्यात्मक आवश्यकताओं के दस्तावेजीकरण के लिए, हमें कार्यात्मकताओं के सेट को निर्दिष्ट करने की आवश्यकता है सिस्टम द्वारा समर्थित। उस स्थिति की पहचान करके एक फ़ंक्शन निर्दिष्ट किया जा सकता है जिस पर डेटा है सिस्टम में इनपुट होना, इसका इनपुट डेटा डोमेन, आउटपुट डेटा डोमेन और इसका प्रकार आउटपुट डेटा प्राप्त करने के लिए इनपुट डेटा पर की जाने वाली प्रोसेसिंग। आइए पहले दस्तावेज करने का प्रयास करें एटीएम (स्वचालित टेलर मशीन) प्रणाली का निकासी-नकद कार्य। निकासी-नकद उच्च स्तरीय आवश्यकता है। इसकी कई उप-आवश्यकताएँ हैं जो विभिन्न उपयोगकर्ता के अनुरूप हैं बातचीत। ये अलग-अलग इंटरैक्शन सीक्वेंस अलग-अलग परिदृश्यों को कैप्चर करते हैं।
Example: - Withdraw Cash from ATM(एटीएम से कैश निकालना)
R1: withdraw cash
Description:- निकासी कैश फ़ंक्शन पहले उपयोगकर्ता के खाते के प्रकार को निर्धारित करता है और खाता संख्या जिससे उपयोगकर्ता नकदी निकालना चाहता है। यह बैलेंस चेक करता है निर्धारित करें कि अनुरोधित राशि खाते में उपलब्ध है या नहीं। यदि पर्याप्त संतुलन है उपलब्ध है, यह आवश्यक नकदी का उत्पादन करता है; अन्यथा यह एक त्रुटि संदेश उत्पन्न करता है
R1.1 select withdraw amount option
Input: “withdraw amount” option
Output: user prompted to enter the account type
R1.2: select account type
Input: user option
Output: prompt to enter amount
R1.3: get required amount
Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing(प्रसंस्करण):- पर्याप्त शेष राशि होने पर उपयोगकर्ता के खाते से राशि डेबिट की जाती है उपलब्ध है, अन्यथा एक त्रुटि संदेश प्रदर्शित होता है
Properties of a good SRS document(एक अच्छे SRS दस्तावेज़ के गुण):-
एक अच्छे SRS दस्तावेज़ के महत्वपूर्ण गुण निम्नलिखित हैं:
- Concise(संक्षिप्त):- एसआरएस दस्तावेज़ संक्षिप्त और साथ ही स्पष्ट होना चाहिए, सुसंगत, और पूर्ण। वर्बोज़ और अप्रासंगिक विवरण पठनीयता को कम करते हैं और साथ ही त्रुटि की संभावनाएं बढ़ाएं।
- Structured(संरचित):- यह अच्छी तरह से संरचित होना चाहिए। एक अच्छी तरह से संरचित दस्तावेज़ बनाना आसान है समझें और संशोधित करें। व्यवहार में, SRS दस्तावेज़ में कई संशोधन होते हैं ग्राहकों की आवश्यकताओं का सामना करना। अक्सर, ग्राहकों की आवश्यकताएं एक से अधिक विकसित होती हैं समय की अवधि। इसलिए, SRS दस्तावेज़ में संशोधन को आसान बनाने के लिए, दस्तावेज़ को अच्छी तरह से संरचित करना महत्वपूर्ण है।
- Black-box view(ब्लैक-बॉक्स दृश्य):- इसे केवल निर्दिष्ट करना चाहिए कि सिस्टम को क्या करना चाहिए और क्या नहीं करना चाहिए इन्हें कैसे करना है बताते हुए। इसका मतलब है कि एसआरएस दस्तावेज़ को बाहरी निर्दिष्ट करना चाहिए प्रणाली का व्यवहार और कार्यान्वयन के मुद्दों पर चर्चा नहीं। एसआरएस दस्तावेज़ सिस्टम को ब्लैक बॉक्स के रूप में विकसित करने के लिए देखना चाहिए, और बाहरी रूप से निर्दिष्ट करना चाहिए सिस्टम का दृश्य व्यवहार। इस कारण से, SRS दस्तावेज़ को भी कहा जाता है एक प्रणाली का ब्लैक-बॉक्स विनिर्देश।
- Conceptual integrity(वैचारिक अखंडता):- इसे वैचारिक अखंडता दिखानी चाहिए ताकि पाठक आसानी से कर सके इसे समझ लो।
- Response to undesired events (अवांछित घटनाओं का जवाब):- यह अवांछित के लिए स्वीकार्य प्रतिक्रियाओं की विशेषता होनी चाहिए आयोजन। इन्हें असाधारण स्थितिय(ों के लिए सिस्टम प्रतिक्रिया कहा जाता है।
- (Verifiable(सत्यापन योग्य):- एसआरएस दस्तावेज़ में प्रलेखित सिस्टम की सभी आवश्यकताओं को होना चाहिए सत्यापन योग्य हो। इसका मतलब यह है कि यह निर्धारित करना संभव होना चाहिए कि क्या है या नहीं कार्यान्वयन में आवश्यकताओं को पूरा किया गया है।
Problems without a SRS document ( SRS दस्तावेज़ के बिना समस्याएँ)
एसआरएस दस्तावेज़ विकसित नहीं करने पर किसी संगठन को जिन महत्वपूर्ण समस्याओं का सामना करना पड़ेगा इस प्रकार हैं:
- SRS दस्तावेज़ को विकसित किए बिना, सिस्टम के अनुसार लागू नहीं किया जाएगा ग्राहक की जरूरतों के लिए।
- सॉफ़्टवेयर डेवलपर्स को यह नहीं पता होगा कि वे जो विकसित कर रहे हैं वह वास्तव में क्या है ग्राहक द्वारा
- एसआरएस दस्तावेज़ के बिना, रखरखाव इंजीनियरों के लिए यह बहुत मुश्किल होगा सिस्टम की कार्यक्षमता को समझें।
- उपयोगकर्ता दस्तावेज़ लेखकों के लिए उपयोगकर्ता मैनुअल लिखना बहुत कठिन होगा एसआरएस दस्तावेज़ को ठीक से समझे बिना।
- उस दस्तावेज़ को समझना बहुत मुश्किल होगा।
- उस दस्तावेज़ को संशोधित करना बहुत कठिन होगा।
- उस दस्तावेज़ में वैचारिक सत्यनिष्ठा नहीं दिखाई
- SRS दस्तावेज़ स्पष्ट और असंग हो सकता है
No comments