226

EN + हिं Medium

GB What is 'risk-based prioritisation' in the Spiral model and how does it differ from value-based prioritisation in Agile?

IN स्पाइरल मॉडल में 'जोखिम-आधारित प्राथमिकता' क्या है और यह एजाइल में मूल्य-आधारित प्राथमिकता से कैसे भिन्न है?

A

Both are identical; the difference is only in terminology between the two frameworks दोनों एक जैसे हैं; दोनों ढाँचों के बीच अंतर केवल शब्दावली में है

B

Spiral prioritises features and work items by their risk reduction value — resolving highest-risk unknowns first regardless of business value; Agile prioritises by customer value — delivering highest-value features first regardless of technical risk स्पाइरल सुविधाओं और कार्य वस्तुओं को उनके जोखिम कम करने के मूल्य के आधार पर प्राथमिकता देता है - व्यावसायिक मूल्य की परवाह किए बिना सबसे पहले उच्चतम जोखिम वाले अज्ञात को हल करना; एजाइल ग्राहक मूल्य को प्राथमिकता देता है - तकनीकी जोखिम की परवाह किए बिना सबसे पहले उच्चतम-मूल्य वाली सुविधाएँ प्रदान करना

C

Spiral prioritisation is done by customers; Agile prioritisation by technical architects सर्पिल प्राथमिकता ग्राहकों द्वारा की जाती है; तकनीकी वास्तुकारों द्वारा त्वरित प्राथमिकता

D

Risk-based prioritisation always produces lower customer satisfaction than value-based prioritisation जोखिम-आधारित प्राथमिकता हमेशा मूल्य-आधारित प्राथमिकता की तुलना में कम ग्राहक संतुष्टि पैदा करती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This distinction creates interesting tension: Spiral might spend early cycles on low-value but high-risk technical components (proving feasibility of a critical algorithm) before any user-visible features exist. Agile would prioritise high-value user stories first. For research-intensive or technically uncertain projects, Spiral's approach prevents investing in polish before proving the core is technically viable.

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

227

EN + हिं Medium

GB In the Spiral model, what role does 'competitive analysis' play in the first spiral cycle for a commercial product?

IN स्पाइरल मॉडल में, किसी व्यावसायिक उत्पाद के लिए पहले स्पाइरल चक्र में 'प्रतिस्पर्धी विश्लेषण' क्या भूमिका निभाता है?

A

Competitive analysis is not part of the Spiral model; it belongs to marketing प्रतिस्पर्धी विश्लेषण स्पाइरल मॉडल का हिस्सा नहीं है; यह विपणन से संबंधित है

B

In the first cycle's objective-setting and risk-identification quadrant, competitive analysis identifies business risks (will the product differentiate from competitors?) and informs the system's operational concept — ensuring the product addresses a real market need before technical investment पहले चक्र के उद्देश्य-निर्धारण और जोखिम-पहचान चतुर्थांश में, प्रतिस्पर्धी विश्लेषण व्यावसायिक जोखिमों की पहचान करता है (क्या उत्पाद प्रतिस्पर्धियों से अलग होगा?) और सिस्टम की परिचालन अवधारणा को सूचित करता है - यह सुनिश्चित करना कि उत्पाद तकनीकी निवेश से पहले वास्तविक बाजार की जरूरत को पूरा करता है

C

Competitive analysis occurs only in the final Spiral cycle before product launch प्रतिस्पर्धी विश्लेषण केवल उत्पाद लॉन्च से पहले अंतिम सर्पिल चक्र में होता है

D

Competitive analysis in Spiral is performed by the customer, not the development team स्पाइरल में प्रतिस्पर्धी विश्लेषण ग्राहक द्वारा किया जाता है, विकास टीम द्वारा नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Business risk is as critical as technical risk in commercial software. Spiral's broad risk scope explicitly includes market risks: will users adopt it? Does a competing product already solve this problem better? Including competitive analysis in early cycle risk identification prevents technically successful projects that fail commercially — a common and expensive failure mode.

व्याख्या (हिन्दी) व्यावसायिक जोखिम उतना ही महत्वपूर्ण है जितना व्यावसायिक सॉफ्टवेयर में तकनीकी जोखिम। स्पाइरल के व्यापक जोखिम दायरे में स्पष्ट रूप से बाजार जोखिम शामिल हैं: क्या उपयोगकर्ता इसे अपनाएंगे? क्या कोई प्रतिस्पर्धी उत्पाद पहले से ही इस समस्या को बेहतर ढंग से हल कर सकता है? प्रारंभिक चक्र जोखिम पहचान में प्रतिस्पर्धी विश्लेषण शामिल करने से तकनीकी रूप से सफल परियोजनाएं जो व्यावसायिक रूप से विफल हो जाती हैं, उन्हें रोकती है - एक सामान्य और महंगी विफलता मोड।

228

EN + हिं Medium

GB How does the Spiral model handle the transition from research phase to development phase in an R&D project?

IN स्पाइरल मॉडल किसी अनुसंधान एवं विकास परियोजना में अनुसंधान चरण से विकास चरण तक संक्रमण को कैसे संभालता है?

A

Spiral model does not support R&D projects; it is only for commercial software स्पाइरल मॉडल अनुसंधान एवं विकास परियोजनाओं का समर्थन नहीं करता है; यह केवल व्यावसायिक सॉफ़्टवेयर के लिए है

B

In R&D projects, early Spiral cycles focus on feasibility research (evaluating alternative approaches, building proof-of-concepts) with small teams and low investment; as risks resolve and feasibility is proven, later cycles scale up the team and investment for full development आर एंड डी परियोजनाओं में, प्रारंभिक सर्पिल चक्र छोटी टीमों और कम निवेश के साथ व्यवहार्यता अनुसंधान (वैकल्पिक दृष्टिकोण का मूल्यांकन, अवधारणाओं के प्रमाण का निर्माण) पर ध्यान केंद्रित करते हैं; जैसे-जैसे जोखिम हल होते हैं और व्यवहार्यता सिद्ध होती है, बाद के चक्रों में पूर्ण विकास के लिए टीम और निवेश को बढ़ाया जाता है

C

Spiral model requires R&D and development to occur simultaneously in all cycles सर्पिल मॉडल के लिए सभी चक्रों में एक साथ अनुसंधान एवं विकास और विकास की आवश्यकता होती है

D

The transition is decided by an external review board, not by the Spiral process itself परिवर्तन का निर्णय बाहरी समीक्षा बोर्ड द्वारा किया जाता है, न कि स्पाइरल प्रक्रिया द्वारा

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This graduated investment is one of the Spiral model's most important economic properties. Early cycles answer 'can we do this at all?' with minimal investment. Positive answers justify increasing investment in subsequent cycles. This mirrors venture capital's staged funding model — seed → Series A → Series B — where each round represents a de-risked commitment rather than full upfront investment in an unproven concept.

व्याख्या (हिन्दी) यह स्नातक निवेश स्पाइरल मॉडल की सबसे महत्वपूर्ण आर्थिक संपत्तियों में से एक है। प्रारंभिक चक्र उत्तर देते हैं 'क्या हम ऐसा बिल्कुल कर सकते हैं?' न्यूनतम निवेश के साथ. सकारात्मक उत्तर आगामी चक्रों में निवेश बढ़ाने को उचित ठहराते हैं। यह उद्यम पूंजी के चरणबद्ध फंडिंग मॉडल - बीज → श्रृंखला ए → श्रृंखला बी - को प्रतिबिंबित करता है, जहां प्रत्येक दौर एक अप्रमाणित अवधारणा में पूर्ण अग्रिम निवेश के बजाय जोखिम रहित प्रतिबद्धता का प्रतिनिधित्व करता है।

229

EN + हिं Easy

GB What is the 'software architecture baseline' in Spiral model terms and what does it enable?

IN स्पाइरल मॉडल के संदर्भ में 'सॉफ्टवेयर आर्किटेक्चर बेसलाइन' क्या है और यह क्या सक्षम बनाता है?

A

Architecture baseline is the first version of code committed to source control आर्किटेक्चर बेसलाइन स्रोत नियंत्रण के लिए प्रतिबद्ध कोड का पहला संस्करण है

B

The architecture baseline (corresponding to LCA milestone) is the point where architecture is stable and validated — it enables reliable cost/schedule estimation for remaining construction, concurrent development by multiple teams, and confident contractual commitments about deliverables आर्किटेक्चर बेसलाइन (एलसीए मील के पत्थर के अनुरूप) वह बिंदु है जहां आर्किटेक्चर स्थिर और मान्य है - यह शेष निर्माण के लिए विश्वसनीय लागत/शेड्यूल अनुमान, कई टीमों द्वारा समवर्ती विकास और डिलिवरेबल्स के बारे में भरोसेमंद संविदात्मक प्रतिबद्धताओं को सक्षम बनाता है।

C

Architecture baseline is only established after 80% of code is written आर्किटेक्चर बेसलाइन 80% कोड लिखे जाने के बाद ही स्थापित होती है

D

Architecture baseline means the architecture will never change for the rest of the project आर्किटेक्चर बेसलाइन का मतलब है कि प्रोजेक्ट के बाकी हिस्से के लिए आर्किटेक्चर कभी नहीं बदलेगा

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without a stable architecture, teams building different subsystems may make incompatible design decisions that only surface at integration — Waterfall's 'integration hell'. The Spiral's LCA milestone requires demonstrating (through an architectural prototype) that the key technical risks are resolved and the architecture can support full functionality. Only after LCA is it safe to staff up a large construction team, because the foundation is proven.

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

230

EN + हिं Easy

GB In the Spiral model, what is a 'prototype' specifically designed to resolve versus what prototypes are built for in RAD?

IN स्पाइरल मॉडल में, 'प्रोटोटाइप' क्या है जिसे विशेष रूप से हल करने के लिए डिज़ाइन किया गया है बनाम आरएडी में प्रोटोटाइप किसके लिए बनाए गए हैं?

A

Both Spiral and RAD use prototypes for identical purposes; the methodologies only differ in team size स्पाइरल और आरएडी दोनों समान उद्देश्यों के लिए प्रोटोटाइप का उपयोग करते हैं; कार्यप्रणाली केवल टीम के आकार में भिन्न होती है

B

Spiral prototypes specifically resolve identified risk items (technical feasibility, performance, integration complexity) — the prototype's purpose is determined by the risk it must resolve; RAD prototypes are UI/workflow demonstrations built to elicit and validate user requirements सर्पिल प्रोटोटाइप विशेष रूप से पहचाने गए जोखिम आइटम (तकनीकी व्यवहार्यता, प्रदर्शन, एकीकरण जटिलता) को हल करते हैं - प्रोटोटाइप का उद्देश्य उस जोखिम से निर्धारित होता है जिसे इसे हल करना होगा; आरएडी प्रोटोटाइप यूआई/वर्कफ़्लो प्रदर्शन हैं जो उपयोगकर्ता की आवश्यकताओं को समझने और मान्य करने के लिए बनाए गए हैं

C

Spiral prototypes are always throwaway; RAD prototypes always evolve into the final system सर्पिल प्रोटोटाइप हमेशा फेंक दिए जाते हैं; आरएडी प्रोटोटाइप हमेशा अंतिम प्रणाली में विकसित होते हैं

D

RAD uses formal mathematical prototypes; Spiral uses only working code prototypes आरएडी औपचारिक गणितीय प्रोटोटाइप का उपयोग करता है; स्पाइरल केवल कार्यशील कोड प्रोटोटाइप का उपयोग करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Spiral's risk-driven prototyping is targeted: 'we don't know if our encryption algorithm meets the latency requirement' → build a performance prototype of just the encryption module. 'We don't know if the distributed consensus algorithm is correct' → build a formal model. RAD's requirement-driven prototyping is user-facing: 'show the customer what the workflow looks like' → build a UI mockup with realistic data. Spiral's prototype might be invisible to users; RAD's prototype is explicitly customer-facing.

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

231

EN + हिं Medium

GB What is 'risk-adjusted return' in Spiral model economics and how does it guide investment decisions?

IN स्पाइरल मॉडल अर्थशास्त्र में 'जोखिम-समायोजित रिटर्न' क्या है और यह निवेश निर्णयों को कैसे निर्देशित करता है?

A

Risk-adjusted return only applies to financial software products, not general applications जोखिम-समायोजित रिटर्न केवल वित्तीय सॉफ्टवेयर उत्पादों पर लागू होता है, सामान्य अनुप्रयोगों पर नहीं

B

Risk-adjusted return accounts for the probability of project success: if a project has $10M expected value but 30% probability of technical failure, the risk-adjusted return is $7M — this guides Spiral decisions by making low-probability-of-success projects less attractive even if their upside is large जोखिम-समायोजित रिटर्न परियोजना की सफलता की संभावना को ध्यान में रखता है: यदि किसी परियोजना का अपेक्षित मूल्य $10M है लेकिन तकनीकी विफलता की 30% संभावना है, तो जोखिम-समायोजित रिटर्न $7M है - यह सफलता की कम संभावना वाली परियोजनाओं को कम आकर्षक बनाकर सर्पिल निर्णयों का मार्गदर्शन करता है, भले ही उनका उल्टा बड़ा हो

C

Spiral model does not consider financial returns; it only focuses on technical risk reduction स्पाइरल मॉडल वित्तीय रिटर्न पर विचार नहीं करता है; यह केवल तकनीकी जोखिम में कमी पर ध्यान केंद्रित करता है

D

Risk-adjusted return always justifies continuing a Spiral project if any positive return exists यदि कोई सकारात्मक रिटर्न मौजूद है तो जोखिम-समायोजित रिटर्न हमेशा स्पाइरल प्रोजेक्ट को जारी रखने को उचित ठहराता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Decision theory applied to Spiral: at each cycle's risk analysis, compute Expected Monetary Value (EMV = probability of success × value if successful - probability of failure × cost of failure). A technically elegant but high-risk project with negative EMV should be cancelled even if successful scenarios are attractive. This makes the 'continue or cancel' decision at each cycle explicitly economic rather than purely technical.

व्याख्या (हिन्दी) निर्णय सिद्धांत सर्पिल पर लागू होता है: प्रत्येक चक्र के जोखिम विश्लेषण पर, अपेक्षित मौद्रिक मूल्य (ईएमवी = सफलता की संभावना × सफल होने पर मूल्य - विफलता की संभावना × विफलता की लागत) की गणना करें। नकारात्मक ईएमवी के साथ तकनीकी रूप से सुरुचिपूर्ण लेकिन उच्च जोखिम वाली परियोजना को रद्द कर दिया जाना चाहिए, भले ही सफल परिदृश्य आकर्षक हों। इससे प्रत्येक चक्र में 'जारी रखने या रद्द करने' का निर्णय विशुद्ध रूप से तकनीकी के बजाय स्पष्ट रूप से आर्थिक हो जाता है।

232

EN + हिं Medium

GB What specific types of risk does the Spiral model address that the V-model cannot?

IN स्पाइरल मॉडल किस विशिष्ट प्रकार के जोखिम को संबोधित करता है जिसे वी-मॉडल नहीं कर सकता?

A

Spiral addresses unit testing risks; V-model cannot handle module-level testing सर्पिल इकाई परीक्षण जोखिमों को संबोधित करता है; वी-मॉडल मॉड्यूल-स्तरीय परीक्षण को संभाल नहीं सकता है

B

Spiral explicitly addresses: business viability risks (is the product worth building?), requirement volatility risks (will requirements change?), and technology feasibility risks (can we build it?) — V-model assumes these are resolved upfront and only addresses product verification/validation risks स्पाइरल स्पष्ट रूप से संबोधित करता है: व्यावसायिक व्यवहार्यता जोखिम (क्या उत्पाद निर्माण के लायक है?), आवश्यकता अस्थिरता जोखिम (क्या आवश्यकताएं बदल जाएंगी?), और प्रौद्योगिकी व्यवहार्यता जोखिम (क्या हम इसे बना सकते हैं?) - वी-मॉडल मानता है कि इन्हें पहले ही हल कर लिया गया है और केवल उत्पाद सत्यापन/सत्यापन जोखिमों को संबोधित करता है

C

V-model addresses more risk types than Spiral because it has more defined phases वी-मॉडल स्पाइरल की तुलना में अधिक जोखिम प्रकारों को संबोधित करता है क्योंकि इसमें अधिक परिभाषित चरण होते हैं

D

Both models address identical risk types; the difference is only in documentation overhead दोनों मॉडल समान जोखिम प्रकारों को संबोधित करते हैं; अंतर केवल दस्तावेज़ीकरण ओवरहेड में है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) V-model is a testing improvement over basic Waterfall — it ensures test planning happens early and testing covers all development phases. But V-model still assumes stable requirements and technical feasibility. Spiral's unique contribution: explicitly asking 'should we be building this at all?' and 'can we technically build this?' at each cycle before committing further investment. These upstream risks are the most expensive when discovered late.

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

233

EN + हिं Medium

GB How does the Spiral model handle 'requirements discovery' that occurs during implementation cycles?

IN सर्पिल मॉडल कार्यान्वयन चक्रों के दौरान होने वाली 'आवश्यकताओं की खोज' को कैसे संभालता है?

A

Spiral model prohibits requirement changes during implementation to maintain architectural stability सर्पिल मॉडल वास्तुशिल्प स्थिरता बनाए रखने के लिए कार्यान्वयन के दौरान आवश्यकता परिवर्तन पर रोक लगाता है

B

New requirements discovered during implementation are recorded as potential scope for future cycles rather than disrupting the current cycle — the cycle's objective is maintained; new requirements go through risk analysis in the next cycle to determine priority and feasibility कार्यान्वयन के दौरान खोजी गई नई आवश्यकताओं को वर्तमान चक्र को बाधित करने के बजाय भविष्य के चक्रों के लिए संभावित दायरे के रूप में दर्ज किया जाता है - चक्र का उद्देश्य बनाए रखा जाता है; प्राथमिकता और व्यवहार्यता निर्धारित करने के लिए नई आवश्यकताओं को अगले चक्र में जोखिम विश्लेषण से गुजरना पड़ता है

C

All discovered requirements must be immediately implemented before the current cycle completes वर्तमान चक्र पूरा होने से पहले सभी खोजी गई आवश्यकताओं को तुरंत लागू किया जाना चाहिए

D

Requirements discovered during implementation invalidate all previous cycles' work कार्यान्वयन के दौरान खोजी गई आवश्यकताएँ पिछले सभी चक्रों के कार्यों को अमान्य कर देती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This discipline maintains the Spiral's risk management integrity. A developer discovering 'users also need X' during implementation would derail the cycle if immediately pursued — X has no risk analysis, design, or estimate. Recording it for the next cycle ensures: X gets proper risk analysis, the current cycle delivers its committed objectives, and X's priority is weighed against other backlog items. This is similar to agile's sprint backlog protection rule.

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

234

EN + हिं Medium

GB What is the 'concurrent engineering' approach and how does it relate to Spiral model risk management?

IN 'समवर्ती इंजीनियरिंग' दृष्टिकोण क्या है और यह सर्पिल मॉडल जोखिम प्रबंधन से कैसे संबंधित है?

A

Concurrent engineering and Spiral model are incompatible approaches that cannot be combined समवर्ती इंजीनियरिंग और सर्पिल मॉडल असंगत दृष्टिकोण हैं जिन्हें जोड़ा नहीं जा सकता है

B

Concurrent engineering overlaps development phases (design and implementation proceed simultaneously across subsystems) to reduce total calendar time — it relates to Spiral by requiring resolved architecture risks first (LCA milestone), after which concurrent construction of validated subsystems is safe समवर्ती इंजीनियरिंग कुल कैलेंडर समय को कम करने के लिए विकास चरणों (उपप्रणालियों में डिजाइन और कार्यान्वयन एक साथ आगे बढ़ता है) को ओवरलैप करती है - यह पहले हल किए गए आर्किटेक्चर जोखिमों (एलसीए मील का पत्थर) की आवश्यकता के द्वारा सर्पिल से संबंधित है, जिसके बाद मान्य उपप्रणालियों का समवर्ती निर्माण सुरक्षित है

C

Concurrent engineering is only possible in Agile projects with multiple parallel sprint teams समवर्ती इंजीनियरिंग केवल कई समानांतर स्प्रिंट टीमों के साथ एजाइल परियोजनाओं में ही संभव है

D

Concurrent engineering eliminates the need for integration testing by ensuring subsystems cannot conflict समवर्ती इंजीनियरिंग यह सुनिश्चित करके एकीकरण परीक्षण की आवश्यकता को समाप्त कर देती है कि उपप्रणालियाँ संघर्ष न कर सकें

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Concurrent engineering is dangerous before architectural stability: if subsystem A's interfaces change mid-design, all other subsystems concurrently depending on those interfaces must redo their work. This is why Spiral's LCA milestone (architecture validated) is the prerequisite for concurrent construction. After LCA, the stable architecture provides the fixed interfaces that allow parallel teams to develop subsystems independently without integration risk.

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

235

EN + हिं Easy

GB What is 'Spiral model cost estimation' and why does it differ fundamentally from Waterfall cost estimation?

IN 'सर्पिल मॉडल लागत अनुमान' क्या है और यह झरना लागत अनुमान से मौलिक रूप से भिन्न क्यों है?

A

Both models use identical cost estimation approaches; the methodology does not affect estimation accuracy दोनों मॉडल समान लागत अनुमान दृष्टिकोण का उपयोग करते हैं; कार्यप्रणाली अनुमान सटीकता को प्रभावित नहीं करती है

B

Spiral estimates costs cycle by cycle with increasing accuracy as risks resolve — early cycles have wide estimate ranges (4x uncertainty); by LCA the range narrows to 1.25x; total project cost emerges as a cumulative sum, unlike Waterfall's single upfront estimate that assumes requirements are complete and stable जैसे-जैसे जोखिम हल होते जाते हैं सर्पिल अनुमान लागत चक्र दर चक्र बढ़ती सटीकता के साथ - प्रारंभिक चक्रों में व्यापक अनुमान सीमाएँ (4x अनिश्चितता) होती हैं; एलसीए द्वारा सीमा 1.25x तक सीमित हो जाती है; कुल परियोजना लागत एक संचयी योग के रूप में उभरती है, वॉटरफॉल के एकल अग्रिम अनुमान के विपरीत जो मानता है कि आवश्यकताएं पूर्ण और स्थिर हैं

C

Spiral model cannot produce cost estimates; it only supports time-and-materials contracts सर्पिल मॉडल लागत अनुमान उत्पन्न नहीं कर सकता; यह केवल समय-और-सामग्री अनुबंधों का समर्थन करता है

D

Spiral cost estimation is always more expensive than Waterfall due to risk analysis overhead जोखिम विश्लेषण ओवरहेड के कारण सर्पिल लागत अनुमान हमेशा वॉटरफॉल से अधिक महंगा होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The fundamental difference is honesty about uncertainty. Waterfall produces a single-point estimate at initiation with false precision. Spiral acknowledges the cone of uncertainty: 'early cycle cost is $200K; we estimate 3-5 more cycles but cannot commit to total cost until after LCA.' After LCA: 'total project cost is $2.5M ± 15%.' This progressive commitment model matches the available information, avoiding the classic Waterfall trap of making binding commitments on insufficient knowledge.

व्याख्या (हिन्दी) मूलभूत अंतर अनिश्चितता के बारे में ईमानदारी है। झरना झूठी परिशुद्धता के साथ आरंभ में एकल-बिंदु अनुमान उत्पन्न करता है। स्पाइरल अनिश्चितता के शंकु को स्वीकार करता है: 'प्रारंभिक चक्र लागत $200K है; हम 3-5 और चक्रों का अनुमान लगाते हैं लेकिन एलसीए के बाद तक कुल लागत के लिए प्रतिबद्ध नहीं हो सकते।' एलसीए के बाद: 'कुल परियोजना लागत $2.5 मिलियन ± 15% है।' यह प्रगतिशील प्रतिबद्धता मॉडल उपलब्ध जानकारी से मेल खाता है, अपर्याप्त ज्ञान पर बाध्यकारी प्रतिबद्धता बनाने के क्लासिक वाटरफॉल जाल से बचता है।

236

EN + हिं Medium

GB In the Spiral model, how is 'prototype fidelity' determined for each risk resolution cycle?

IN स्पाइरल मॉडल में, प्रत्येक जोखिम समाधान चक्र के लिए 'प्रोटोटाइप निष्ठा' कैसे निर्धारित की जाती है?

A

All Spiral prototypes must be high-fidelity working implementations by requirement सभी स्पाइरल प्रोटोटाइप आवश्यकता के अनुसार उच्च-निष्ठा वाले कार्य कार्यान्वयन वाले होने चाहिए

B

Prototype fidelity is determined by the minimum fidelity needed to answer the specific risk question — a paper prototype answers 'do users understand this workflow?'; a performance benchmark answers 'can this algorithm meet latency requirements?'; high fidelity is only used when lower fidelity cannot resolve the uncertainty प्रोटोटाइप निष्ठा विशिष्ट जोखिम प्रश्न का उत्तर देने के लिए आवश्यक न्यूनतम निष्ठा द्वारा निर्धारित की जाती है - एक पेपर प्रोटोटाइप उत्तर देता है 'क्या उपयोगकर्ता इस वर्कफ़्लो को समझते हैं?'; एक प्रदर्शन बेंचमार्क उत्तर देता है 'क्या यह एल्गोरिदम विलंबता आवश्यकताओं को पूरा कर सकता है?'; उच्च निष्ठा का उपयोग केवल तभी किया जाता है जब कम निष्ठा अनिश्चितता का समाधान नहीं कर सकती

C

Prototype fidelity must always increase monotonically across Spiral cycles सर्पिल चक्रों में प्रोटोटाइप निष्ठा हमेशा एकरस रूप से बढ़नी चाहिए

D

Fidelity is always determined by the customer's visual expectations, never by technical risk निष्ठा हमेशा ग्राहक की दृश्य अपेक्षाओं से निर्धारित होती है, तकनीकी जोखिम से कभी नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Minimum viable fidelity principle: a paper sketch resolves 'is this the right layout?' without coding. A Wizard of Oz prototype (human simulating AI response) resolves 'will users trust an AI recommendation?' without building the AI. A performance microbenchmark resolves 'can we process 10K transactions/second?' without building the full system. Overbuilding prototypes wastes resources; under-building (too low fidelity to answer the question) produces misleading results.

व्याख्या (हिन्दी) न्यूनतम व्यवहार्य निष्ठा सिद्धांत: एक पेपर स्केच हल करता है 'क्या यह सही लेआउट है?' बिना कोडिंग के. विज़ार्ड ऑफ ओज़ प्रोटोटाइप (मानव अनुकरण एआई प्रतिक्रिया) का समाधान 'क्या उपयोगकर्ता एआई अनुशंसा पर भरोसा करेंगे?' एआई के निर्माण के बिना। एक प्रदर्शन माइक्रोबेंचमार्क यह हल करता है कि 'क्या हम 10K लेनदेन/सेकंड संसाधित कर सकते हैं?' संपूर्ण सिस्टम बनाए बिना. प्रोटोटाइप के अधिक निर्माण से संसाधन बर्बाद होते हैं; अंडर-बिल्डिंग (प्रश्न का उत्तर देने के लिए बहुत कम निष्ठा) भ्रामक परिणाम उत्पन्न करती है।

Software Engineering — MCQ Practice