सर्पिल मॉडल

सर्पिल मॉडल (बोहेम, 1988)। इस व्यापक रूप से प्रसारित आरेख में अतिसरलीकरण के कारण कई गलतफहमियाँ उत्पन्न होती हैं (इस आरेख में कुछ त्रुटियाँ हैं)।^[1]

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

इतिहास

इस मॉडल का वर्णन सबसे पहले बैरी बोहम ने अपने 1986 के पेपर, ए स्पाइरल मॉडल ऑफ सॉफ्टवेयर डेवलपमेंट एंड एन्हांसमेंट में किया था।^[2] 1988 में बोहेम ने इसी तरह का एक पेपर प्रकाशित किया^[3] व्यापक दर्शकों के लिए. ये पेपर एक आरेख प्रस्तुत करते हैं जिसे सर्पिल मॉडल पर चर्चा करने वाले कई बाद के प्रकाशनों में पुन: प्रस्तुत किया गया है।

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

[R]isk-driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.^[3]

बाद के प्रकाशनों में,^[1]बोहेम सर्पिल मॉडल को एक प्रक्रिया मॉडल जनरेटर के रूप में वर्णित करता है, जहां किसी परियोजना के जोखिमों के आधार पर विकल्प परियोजना के लिए एक उपयुक्त प्रक्रिया मॉडल उत्पन्न करते हैं। इस प्रकार, वृद्धिशील, झरना, प्रोटोटाइप और अन्य प्रक्रिया मॉडल सर्पिल मॉडल के विशेष मामले हैं जो कुछ परियोजनाओं के जोखिम पैटर्न में फिट होते हैं।

बोहेम मूल सर्पिल मॉडल आरेख में अतिसरलीकरण से उत्पन्न होने वाली कई गलतफहमियों की भी पहचान करता है। उनका कहना है कि इन गलतफहमियों में सबसे खतरनाक ये हैं:

कि सर्पिल केवल झरने की वृद्धि का एक क्रम है;
कि सभी परियोजना गतिविधियाँ एक ही सर्पिल अनुक्रम का पालन करें;
आरेख में प्रत्येक गतिविधि को दिखाए गए क्रम में किया जाना चाहिए।

हालाँकि ये ग़लतफ़हमियाँ कुछ परियोजनाओं के जोखिम पैटर्न में फिट हो सकती हैं, लेकिन अधिकांश परियोजनाओं के लिए ये सच नहीं हैं।

राष्ट्रीय अनुसंधान परिषद की एक रिपोर्ट में^[4] इस मॉडल को मानव उपयोगकर्ताओं से संबंधित जोखिमों को शामिल करने के लिए विस्तारित किया गया था।

उन्हें खतरनाक सर्पिल हमशक्लों से बेहतर ढंग से अलग करने के लिए, बोहेम ने सर्पिल मॉडल के सभी प्रामाणिक अनुप्रयोगों के लिए सामान्य छह विशेषताओं को सूचीबद्ध किया है।^{[citation needed]}

सर्पिल मॉडल के छह अपरिवर्तनीय

सर्पिल मॉडल के प्रामाणिक अनुप्रयोग उन चक्रों द्वारा संचालित होते हैं जो हमेशा छह विशेषताओं को प्रदर्शित करते हैं। बोहेम प्रत्येक को एक खतरनाक सर्पिल जैसे दिखने वाले उदाहरण के साथ चित्रित करता है जो अपरिवर्तनीय का उल्लंघन करता है।^[1]

कलाकृतियों को समवर्ती रूप से परिभाषित करें

किसी परियोजना के लिए प्रमुख कलाकृतियों को क्रमिक रूप से परिभाषित करने से अक्सर एक ऐसी प्रणाली विकसित करने की संभावना बढ़ जाती है जो हितधारक की जीत की शर्तों (उद्देश्यों और बाधाओं) को पूरा करती है।

यह अपरिवर्तनीय "खतरनाक सर्पिल दिखने वाली" प्रक्रियाओं को बाहर करता है जो सेटिंग्स में वृद्धिशील झरना पास के अनुक्रम का उपयोग करते हैं जहां झरना मॉडल की अंतर्निहित धारणाएं लागू नहीं होती हैं। बोहेम इन धारणाओं को इस प्रकार सूचीबद्ध करता है:

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

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

प्रत्येक चक्र में चार बुनियादी गतिविधियाँ निष्पादित करें

यह अपरिवर्तनीय उन चार गतिविधियों की पहचान करता है जो सर्पिल मॉडल के प्रत्येक चक्र में होनी चाहिए:

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

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

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

जोखिम प्रयास का स्तर निर्धारित करता है

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

उदाहरण के लिए, किसी सॉफ़्टवेयर उत्पाद के परीक्षण में अतिरिक्त समय लगाने से अक्सर बाज़ार द्वारा घटिया उत्पाद को अस्वीकार करने के कारण जोखिम कम हो जाता है। हालाँकि, अतिरिक्त परीक्षण समय किसी प्रतिस्पर्धी के बाज़ार में जल्दी प्रवेश के कारण जोखिम बढ़ा सकता है। सर्पिल मॉडल परिप्रेक्ष्य से, परीक्षण तब तक किया जाना चाहिए जब तक कि कुल जोखिम कम न हो जाए, और इससे आगे नहीं।^{[citation needed]}

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

जोखिम विवरण की डिग्री निर्धारित करता है

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

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

एंकर पॉइंट मील के पत्थर का उपयोग करें

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

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

इस अपरिवर्तनीयता का उल्लंघन करने वाले खतरनाक सर्पिल हमशक्लों में विकासवादी और वृद्धिशील प्रक्रियाएं शामिल हैं जो खराब परिभाषित वास्तुकला के साथ समाधान को लागू करने के लिए महत्वपूर्ण संसाधन प्रदान करती हैं।^{[clarification needed]}

तीन एंकर बिंदु मील के पत्थर तर्कसंगत एकीकृत प्रक्रिया (आरयूपी) में आसानी से फिट होते हैं, जिसमें एलसीओ आरयूपी के आरंभ और विस्तार चरणों के बीच की सीमा को चिह्नित करता है, एलसीए विस्तार और निर्माण चरणों के बीच की सीमा को चिह्नित करता है, और आईओसी निर्माण और संक्रमण चरणों के बीच की सीमा को चिह्नित करता है।

सिस्टम और उसके जीवन चक्र पर ध्यान दें

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

संदर्भ

↑ ^1.0 ^1.1 ^1.2 Boehm, B (July 2000). "Spiral Development: Experience, Principles, and Refinements" (PDF). Special Report. Software Engineering Institute. CMU/SEI-2000-SR-008.
↑ Boehm, B (August 1986). "सॉफ्टवेयर विकास और संवर्द्धन का एक सर्पिल मॉडल". ACM SIGSOFT Software Engineering Notes. 11 (4): 14–24. doi:10.1145/12944.12948. S2CID 207165409.
↑ ^3.0 ^3.1 Boehm, B (May 1988). "सॉफ्टवेयर विकास और संवर्द्धन का एक सर्पिल मॉडल" (PDF). IEEE Computer. 21 (5): 61–72. doi:10.1109/2.59. S2CID 1781829. Archived March 6, 2023, at the Wayback Machine
↑ Pew, R.W.; Mavor, A.S., eds. (2007). Human-system integration in the system development process: A new look. Washington, D.C.: National Academy Press. ISBN 978-0-309-10720-4.

[:0-1] 1.0 ^1.1 ^1.2 Boehm, B (July 2000). "Spiral Development: Experience, Principles, and Refinements" (PDF). Special Report. Software Engineering Institute. CMU/SEI-2000-SR-008.

[2] Boehm, B (August 1986). "सॉफ्टवेयर विकास और संवर्द्धन का एक सर्पिल मॉडल". ACM SIGSOFT Software Engineering Notes. 11 (4): 14–24. doi:10.1145/12944.12948. S2CID 207165409.

[:1-3] 3.0 ^3.1 Boehm, B (May 1988). "सॉफ्टवेयर विकास और संवर्द्धन का एक सर्पिल मॉडल" (PDF). IEEE Computer. 21 (5): 61–72. doi:10.1109/2.59. S2CID 1781829. Archived March 6, 2023, at the Wayback Machine

[4] Pew, R.W.; Mavor, A.S., eds. (2007). Human-system integration in the system development process: A new look. Washington, D.C.: National Academy Press. ISBN 978-0-309-10720-4.

[1]

[2]

[3]

[4]