Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2656
EN + हिं Easy
GB What is 'configuration management plan' (CMP) in Waterfall and what four activities must it describe?
IN वॉटरफॉल में 'कॉन्फ़िगरेशन प्रबंधन योजना' (सीएमपी) क्या है और इसमें किन चार गतिविधियों का वर्णन होना चाहिए?
A
CMP describes only the version numbering scheme for the software product सीएमपी सॉफ्टवेयर उत्पाद के लिए केवल संस्करण क्रमांकन योजना का वर्णन करता है
B
CMP describes how configuration management will be practised: Configuration identification (what items are under CM), Configuration control (how changes are proposed, evaluated, approved), Status accounting (recording and reporting of CM information), and Configuration audits (verifying CM records match actual items) सीएमपी वर्णन करता है कि कॉन्फ़िगरेशन प्रबंधन का अभ्यास कैसे किया जाएगा: कॉन्फ़िगरेशन पहचान (सीएम के अंतर्गत कौन से आइटम हैं), कॉन्फ़िगरेशन नियंत्रण (कैसे परिवर्तन प्रस्तावित, मूल्यांकन, अनुमोदित किए जाते हैं), स्थिति लेखांकन (सीएम जानकारी की रिकॉर्डिंग और रिपोर्टिंग), और कॉन्फ़िगरेशन ऑडिट (सीएम रिकॉर्ड का सत्यापन वास्तविक आइटम से मेल खाता है)
C
CMP is optional documentation in Waterfall; it is only mandatory for contracts over $10M वॉटरफॉल में सीएमपी वैकल्पिक दस्तावेज है; यह केवल $10 मिलियन से अधिक के अनुबंधों के लिए अनिवार्य है
D
CMP is identical to the project management plan and covers all aspects of project delivery सीएमपी परियोजना प्रबंधन योजना के समान है और परियोजना वितरण के सभी पहलुओं को शामिल करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IEEE Std 828 specifies exactly these four activities. Configuration identification: assign unique identifiers to all controlled artefacts (SRS v2.1, Design Spec v3.0). Control: change requests go through CCB before any baseline is modified. Status accounting: the CM database tracks every version, change reason, and approver. Audits: functional audit verifies the product satisfies requirements; physical audit verifies delivered items match documentation.
व्याख्या (हिन्दी) आईईईई कक्षा 828 बिल्कुल इन चार गतिविधियों को निर्दिष्ट करती है। कॉन्फ़िगरेशन पहचान: सभी नियंत्रित कलाकृतियों (एसआरएस v2.1, डिज़ाइन स्पेक v3.0) के लिए विशिष्ट पहचानकर्ता निर्दिष्ट करें। नियंत्रण: किसी भी आधार रेखा को संशोधित करने से पहले परिवर्तन अनुरोध सीसीबी से गुजरते हैं। स्थिति लेखांकन: सीएम डेटाबेस हर संस्करण, परिवर्तन कारण और अनुमोदनकर्ता को ट्रैक करता है। ऑडिट: कार्यात्मक ऑडिट सत्यापित करता है कि उत्पाद आवश्यकताओं को पूरा करता है; भौतिक ऑडिट सत्यापित करता है कि वितरित वस्तुएँ दस्तावेज़ीकरण से मेल खाती हैं।
2657
EN + हिं Easy
GB What is 'schedule risk' specific to Waterfall projects and what monitoring metric best detects it early?
IN वॉटरफ़ॉल परियोजनाओं के लिए विशिष्ट 'शेड्यूल जोखिम' क्या है और कौन सी निगरानी मीट्रिक इसका सबसे पहले पता लगा लेती है?
A
Schedule risk in Waterfall is caused only by developer illness and absence वॉटरफ़ॉल में शेड्यूल जोखिम केवल डेवलपर की बीमारी और अनुपस्थिति के कारण होता है
B
Waterfall's most significant schedule risk is 'the first 90% takes 90% of the time; the last 10% takes the other 90%' — monitored by tracking planned vs actual milestone completion, design review findings (unresolved issues), and dependency completion status rather than subjective percent-complete estimates झरने का सबसे महत्वपूर्ण शेड्यूल जोखिम यह है कि 'पहले 90% में 90% समय लगता है; अंतिम 10% अन्य 90% लेता है' - व्यक्तिपरक प्रतिशत-पूर्ण अनुमानों के बजाय योजनाबद्ध बनाम वास्तविक मील का पत्थर पूरा होने, डिज़ाइन समीक्षा निष्कर्ष (अनसुलझे मुद्दे), और निर्भरता पूर्णता स्थिति पर नज़र रखने के द्वारा निगरानी की जाती है
C
Schedule risk in Waterfall is best monitored by daily developer standups वॉटरफॉल में शेड्यूल जोखिम की निगरानी दैनिक डेवलपर स्टैंडअप द्वारा सबसे अच्छी तरह की जाती है
D
Waterfall has no schedule risk because phase durations are fixed at project initiation झरने का कोई शेड्यूल जोखिम नहीं है क्योंकि चरण की अवधि परियोजना की शुरुआत में तय की जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The '90-90 rule' (Hofstadter's Law variation) reflects that integration and late-discovered issues consume disproportionate time. Objective leading indicators: 'How many open issues from the last review are unresolved?' and 'How many dependencies are behind schedule?' are better predictors than 'We're 70% done' (which developers say from 30% through to 95% of projects). Tracking open issues trends reveals whether the project is converging or diverging.
व्याख्या (हिन्दी) '90-90 नियम' (हॉफस्टैटर का कानून भिन्नता) दर्शाता है कि एकीकरण और देर से खोजे गए मुद्दों में अनुपातहीन समय लगता है। वस्तुनिष्ठ अग्रणी संकेतक: 'पिछली समीक्षा के कितने खुले मुद्दे अनसुलझे हैं?' और 'कितनी निर्भरताएँ निर्धारित समय से पीछे हैं?' 'हम 70% काम पूरा कर चुके हैं' (डेवलपर्स का कहना है कि 30% से लेकर 95% तक परियोजनाएं पूरी हो चुकी हैं) की तुलना में बेहतर भविष्यवक्ता हैं। खुले मुद्दों के रुझानों पर नज़र रखने से पता चलता है कि परियोजना अभिसरण कर रही है या विचलन कर रही है।
2658
EN + हिं Medium
GB What makes Waterfall particularly suited for 'fixed-price fixed-scope' government contracts?
IN वॉटरफ़ॉल को 'निश्चित-मूल्य निश्चित-क्षेत्र' सरकारी अनुबंधों के लिए विशेष रूप से उपयुक्त क्या बनाता है?
A
Government contracts require Waterfall by law in all jurisdictions सरकारी अनुबंधों के लिए सभी न्यायक्षेत्रों में कानून द्वारा वॉटरफॉल की आवश्यकता होती है
B
Waterfall's upfront specification of complete requirements enables precise cost and schedule estimation before contract award — the contractual obligation (deliver X by date Y for $Z) maps directly to Waterfall's sequential phases with measurable phase-exit deliverables that can be contractually defined वॉटरफ़ॉल की संपूर्ण आवश्यकताओं का अग्रिम विनिर्देश अनुबंध पुरस्कार से पहले सटीक लागत और शेड्यूल अनुमान को सक्षम बनाता है - संविदात्मक दायित्व ($Z के लिए दिनांक Y द्वारा X वितरित करना) मापने योग्य चरण-निकास डिलिवरेबल्स के साथ सीधे वॉटरफ़ॉल के अनुक्रमिक चरणों को मैप करता है जिसे अनुबंधात्मक रूप से परिभाषित किया जा सकता है
C
Government contracts only use Waterfall because government employees lack agile training सरकारी अनुबंध केवल वॉटरफॉल का उपयोग करते हैं क्योंकि सरकारी कर्मचारियों के पास चुस्त प्रशिक्षण का अभाव है
D
Fixed-price contracts always produce better software than time-and-materials regardless of methodology कार्यप्रणाली की परवाह किए बिना निश्चित मूल्य अनुबंध हमेशा समय और सामग्री की तुलना में बेहतर सॉफ्टवेयर का उत्पादन करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Procurement law in many jurisdictions (FAR in the US) requires competition on a fixed specification to ensure fairness. Waterfall aligns: define requirements (Statement of Work), solicit bids (RFP), award to best value, execute sequentially, deliver. The contractual milestones (CDRLs — Contract Data Requirements Lists) map to Waterfall deliverables. Agile's variable scope makes this competitive procurement difficult, though modern contracting is evolving to accommodate iterative approaches.
व्याख्या (हिन्दी) कई न्यायालयों में खरीद कानून (यूएस में एफएआर) में निष्पक्षता सुनिश्चित करने के लिए एक निश्चित विनिर्देश पर प्रतिस्पर्धा की आवश्यकता होती है। झरना संरेखित करता है: आवश्यकताओं को परिभाषित करें (कार्य का विवरण), बोलियां मांगें (आरएफपी), सर्वोत्तम मूल्य के लिए पुरस्कार, क्रमिक रूप से निष्पादित करें, वितरित करें। संविदात्मक मील के पत्थर (सीडीआरएल - अनुबंध डेटा आवश्यकताएँ सूचियाँ) वॉटरफॉल डिलिवरेबल्स के लिए मैप करते हैं। एजाइल का परिवर्तनशील दायरा इस प्रतिस्पर्धी खरीद को कठिन बना देता है, हालांकि आधुनिक अनुबंध पुनरावृत्त दृष्टिकोण को समायोजित करने के लिए विकसित हो रहा है।
2659
EN + हिं Easy
GB What is 'technical review' in Waterfall and what three types serve different quality purposes?
IN वॉटरफॉल में 'तकनीकी समीक्षा' क्या है और कौन से तीन प्रकार विभिन्न गुणवत्ता उद्देश्यों को पूरा करते हैं?
A
All technical reviews in Waterfall have identical structure and purpose वॉटरफॉल में सभी तकनीकी समीक्षाओं की संरचना और उद्देश्य समान हैं
B
Technical reviews come in three types: Management review (project status, resource allocation), Technical review (evaluating technical implementation against specifications), and Audit (verifying process compliance, configuration records) — each serves a different quality assurance function तकनीकी समीक्षाएँ तीन प्रकार की होती हैं: प्रबंधन समीक्षा (परियोजना की स्थिति, संसाधन आवंटन), तकनीकी समीक्षा (विनिर्देशों के विरुद्ध तकनीकी कार्यान्वयन का मूल्यांकन), और ऑडिट (प्रक्रिया अनुपालन, कॉन्फ़िगरेशन रिकॉर्ड का सत्यापन) - प्रत्येक एक अलग गुणवत्ता आश्वासन कार्य करता है
C
Technical reviews are only conducted at project completion to evaluate the final product तकनीकी समीक्षाएँ केवल अंतिम उत्पाद का मूल्यांकन करने के लिए परियोजना के पूरा होने पर आयोजित की जाती हैं
D
Only external consultants can conduct valid technical reviews; internal reviews are always biased केवल बाहरी सलाहकार ही वैध तकनीकी समीक्षा कर सकते हैं; आंतरिक समीक्षाएँ हमेशा पक्षपातपूर्ण होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IEEE 1028 (Software Reviews and Audits) defines these types. Management reviews: 'are we on schedule? do we have enough resources?' Technical reviews: 'does this design correctly implement requirement 47? is this API design consistent with the architecture?' Audits: 'did the team follow the change management procedure? do the configuration records match what was delivered?' Each uses different participants, criteria, and produces different types of findings.
व्याख्या (हिन्दी) आईईईई 1028 (सॉफ्टवेयर समीक्षाएं और ऑडिट) इन प्रकारों को परिभाषित करता है। प्रबंधन समीक्षाएँ: 'क्या हम समय पर हैं? क्या हमारे पास पर्याप्त संसाधन हैं?' तकनीकी समीक्षाएँ: 'क्या यह डिज़ाइन आवश्यकता 47 को सही ढंग से लागू करता है? क्या यह एपीआई डिज़ाइन वास्तुकला के अनुरूप है?' ऑडिट: 'क्या टीम ने परिवर्तन प्रबंधन प्रक्रिया का पालन किया? क्या कॉन्फ़िगरेशन रिकॉर्ड जो वितरित किया गया था उससे मेल खाता है?' प्रत्येक अलग-अलग प्रतिभागियों, मानदंडों का उपयोग करता है और विभिन्न प्रकार के निष्कर्ष निकालता है।
2660
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.
व्याख्या (हिन्दी) यह स्नातक निवेश स्पाइरल मॉडल की सबसे महत्वपूर्ण आर्थिक संपत्तियों में से एक है। प्रारंभिक चक्र उत्तर देते हैं 'क्या हम ऐसा बिल्कुल कर सकते हैं?' न्यूनतम निवेश के साथ. सकारात्मक उत्तर आगामी चक्रों में निवेश बढ़ाने को उचित ठहराते हैं। यह उद्यम पूंजी के चरणबद्ध फंडिंग मॉडल - बीज → श्रृंखला ए → श्रृंखला बी - को प्रतिबिंबित करता है, जहां प्रत्येक दौर एक अप्रमाणित अवधारणा में पूर्ण अग्रिम निवेश के बजाय जोखिम रहित प्रतिबद्धता का प्रतिनिधित्व करता है।
2661
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.
व्याख्या (हिन्दी) एक स्थिर वास्तुकला के बिना, विभिन्न उपप्रणालियों का निर्माण करने वाली टीमें असंगत डिजाइन निर्णय ले सकती हैं जो केवल एकीकरण पर सामने आती हैं - वॉटरफॉल का 'एकीकरण नरक'। स्पाइरल के एलसीए मील के पत्थर को यह प्रदर्शित करने की आवश्यकता है (एक आर्किटेक्चरल प्रोटोटाइप के माध्यम से) कि प्रमुख तकनीकी जोखिम हल हो गए हैं और आर्किटेक्चर पूर्ण कार्यक्षमता का समर्थन कर सकता है। एलसीए के बाद ही एक बड़ी निर्माण टीम को नियुक्त करना सुरक्षित है, क्योंकि नींव सिद्ध है।
2662
EN + हिं Medium
GB What is the difference between 'spiral cycle objectives' and 'milestone objectives' in Boehm's model?
IN बोहेम के मॉडल में 'सर्पिल चक्र उद्देश्यों' और 'मील का पत्थर उद्देश्यों' के बीच क्या अंतर है?
A
Both terms refer to identical objectives; Boehm uses them interchangeably दोनों शब्द समान उद्देश्यों को संदर्भित करते हैं; बोहेम इनका परस्पर उपयोग करता है
B
Cycle objectives define what the current cycle aims to accomplish (e.g., 'prove the real-time processing algorithm meets latency requirements'); milestone objectives define the strategic gates for the overall project (LCO, LCA, IOC) that multiple cycles collectively work toward चक्र उद्देश्य परिभाषित करते हैं कि वर्तमान चक्र का लक्ष्य क्या हासिल करना है (उदाहरण के लिए, 'साबित करें कि वास्तविक समय प्रसंस्करण एल्गोरिदम विलंबता आवश्यकताओं को पूरा करता है'); मील के पत्थर के उद्देश्य समग्र परियोजना (एलसीओ, एलसीए, आईओसी) के लिए रणनीतिक द्वार को परिभाषित करते हैं जिसके लिए कई चक्र सामूहिक रूप से काम करते हैं
C
Milestone objectives are set by customers; cycle objectives are set by developers independently मील के पत्थर के उद्देश्य ग्राहकों द्वारा निर्धारित किए जाते हैं; चक्र उद्देश्य डेवलपर्स द्वारा स्वतंत्र रूप से निर्धारित किए जाते हैं
D
Cycle objectives change every cycle; milestone objectives are fixed at project initiation चक्र के उद्देश्य हर चक्र में बदलते हैं; परियोजना की शुरुआत में मील के पत्थर के उद्देश्य तय किए जाते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Spiral model operates at two temporal scales: individual cycles (typically weeks to months) with specific risk-resolution objectives, and the strategic arc of LCO→LCA→IOC milestones spanning the project's lifetime. A cycle might focus on 'build and test the search algorithm prototype', contributing toward the LCA milestone's goal of 'validate that all high-risk technical unknowns are resolved'. Both levels need explicit objectives and outcomes.
व्याख्या (हिन्दी) स्पाइरल मॉडल दो अस्थायी पैमानों पर काम करता है: विशिष्ट जोखिम-समाधान उद्देश्यों के साथ व्यक्तिगत चक्र (आमतौर पर सप्ताह से महीने तक), और परियोजना के जीवनकाल में फैले एलसीओ → एलसीए → आईओसी मील के पत्थर का रणनीतिक आर्क। एक चक्र 'खोज एल्गोरिदम प्रोटोटाइप का निर्माण और परीक्षण' पर ध्यान केंद्रित कर सकता है, जो एलसीए मील के पत्थर के लक्ष्य 'मान्य करें कि सभी उच्च जोखिम वाले तकनीकी अज्ञात हल हो गए हैं' की दिशा में योगदान दे रहा है। दोनों स्तरों पर स्पष्ट उद्देश्यों और परिणामों की आवश्यकता है।
2663
EN + हिं Easy
GB What is 'technical risk management plan' in Spiral and what content should it include?
IN स्पाइरल में 'तकनीकी जोखिम प्रबंधन योजना' क्या है और इसमें कौन सी सामग्री शामिल होनी चाहिए?
A
Technical risk management plan is identical to the project risk register used in all methodologies तकनीकी जोखिम प्रबंधन योजना सभी पद्धतियों में प्रयुक्त परियोजना जोखिम रजिस्टर के समान है
B
Technical risk management plan documents: identified technical risks with probability and impact, risk reduction actions and prototypes planned, risk thresholds (when risk becomes unacceptable), monitoring indicators, and contingency plans — updated at the start of each Spiral cycle तकनीकी जोखिम प्रबंधन योजना दस्तावेज़: संभाव्यता और प्रभाव के साथ पहचाने गए तकनीकी जोखिम, जोखिम में कमी के कार्य और योजनाबद्ध प्रोटोटाइप, जोखिम सीमाएँ (जब जोखिम अस्वीकार्य हो जाता है), निगरानी संकेतक और आकस्मिक योजनाएँ - प्रत्येक सर्पिल चक्र की शुरुआत में अपडेट की जाती हैं
C
Technical risk management plan only lists risks; it does not include risk reduction strategies तकनीकी जोखिम प्रबंधन योजना केवल जोखिमों को सूचीबद्ध करती है; इसमें जोखिम कम करने की रणनीतियाँ शामिल नहीं हैं
D
Technical risk management plan is produced once at project start and never updated तकनीकी जोखिम प्रबंधन योजना परियोजना शुरू होने पर एक बार तैयार की जाती है और कभी अद्यतन नहीं की जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Effective risk management requires more than listing risks: for each risk, specify the trigger (what observation would indicate the risk is materialising), the mitigation action (what prototype or analysis reduces the risk), the risk threshold (at what probability×impact level does the project need to pivot or cancel), and the responsible owner. Updating at each cycle ensures newly discovered risks are managed before they become crises.
व्याख्या (हिन्दी) प्रभावी जोखिम प्रबंधन के लिए जोखिमों को सूचीबद्ध करने से अधिक की आवश्यकता होती है: प्रत्येक जोखिम के लिए, ट्रिगर निर्दिष्ट करें (कौन सा अवलोकन यह संकेत देगा कि जोखिम भौतिक हो रहा है), शमन कार्रवाई (कौन सा प्रोटोटाइप या विश्लेषण जोखिम को कम करता है), जोखिम सीमा (किस संभावना × प्रभाव स्तर पर परियोजना को मोड़ने या रद्द करने की आवश्यकता है), और जिम्मेदार मालिक। प्रत्येक चक्र में अद्यतन करने से यह सुनिश्चित होता है कि नए खोजे गए जोखिमों को संकट बनने से पहले प्रबंधित किया जाता है।
2664
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.
व्याख्या (हिन्दी) स्पाइरल का जोखिम-संचालित प्रोटोटाइप लक्षित है: 'हम नहीं जानते कि हमारा एन्क्रिप्शन एल्गोरिदम विलंबता आवश्यकता को पूरा करता है या नहीं' → केवल एन्क्रिप्शन मॉड्यूल का एक प्रदर्शन प्रोटोटाइप बनाएं। 'हमें नहीं पता कि वितरित सर्वसम्मति एल्गोरिथ्म सही है या नहीं' → एक औपचारिक मॉडल बनाएं। आरएडी की आवश्यकता-संचालित प्रोटोटाइप उपयोगकर्ता-सामना करने योग्य है: 'ग्राहक को दिखाएं कि वर्कफ़्लो कैसा दिखता है' → यथार्थवादी डेटा के साथ यूआई मॉकअप बनाएं। स्पाइरल का प्रोटोटाइप उपयोगकर्ताओं के लिए अदृश्य हो सकता है; आरएडी का प्रोटोटाइप स्पष्ट रूप से ग्राहक-सामना करने वाला है।
2665
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.
व्याख्या (हिन्दी) निर्णय सिद्धांत सर्पिल पर लागू होता है: प्रत्येक चक्र के जोखिम विश्लेषण पर, अपेक्षित मौद्रिक मूल्य (ईएमवी = सफलता की संभावना × सफल होने पर मूल्य - विफलता की संभावना × विफलता की लागत) की गणना करें। नकारात्मक ईएमवी के साथ तकनीकी रूप से सुरुचिपूर्ण लेकिन उच्च जोखिम वाली परियोजना को रद्द कर दिया जाना चाहिए, भले ही सफल परिदृश्य आकर्षक हों। इससे प्रत्येक चक्र में 'जारी रखने या रद्द करने' का निर्णय विशुद्ध रूप से तकनीकी के बजाय स्पष्ट रूप से आर्थिक हो जाता है।
2666
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.
व्याख्या (हिन्दी) वी-मॉडल बेसिक वॉटरफॉल की तुलना में एक परीक्षण सुधार है - यह सुनिश्चित करता है कि परीक्षण योजना जल्दी हो और परीक्षण सभी विकास चरणों को कवर करता है। लेकिन वी-मॉडल अभी भी स्थिर आवश्यकताओं और तकनीकी व्यवहार्यता को मानता है। स्पाइरल का अद्वितीय योगदान: स्पष्ट रूप से पूछना 'क्या हमें इसे बिल्कुल बनाना चाहिए?' और 'क्या हम तकनीकी रूप से इसे बना सकते हैं?' आगे निवेश करने से पहले प्रत्येक चक्र पर। देर से पता चलने पर ये अपस्ट्रीम जोखिम सबसे महंगे होते हैं।
2667
EN + हिं Medium
GB What is 'incremental risk reduction' as Spiral cycles accumulate and how does this affect project velocity?
IN सर्पिल चक्रों के जमा होने पर 'वृद्धिशील जोखिम में कमी' क्या है और यह परियोजना वेग को कैसे प्रभावित करता है?
A
Project velocity increases in each Spiral cycle as risk reduction adds work overhead प्रत्येक सर्पिल चक्र में परियोजना का वेग बढ़ जाता है क्योंकि जोखिम कम होने से कार्य में अतिरिक्त वृद्धि हो जाती है
B
As successive cycles resolve risks, remaining work becomes more certain and manageable — early cycles are exploratory and slow (high uncertainty); later cycles become more efficient as the architecture stabilises, requirements are validated, and teams can focus on productive construction without risk interruptions जैसे-जैसे क्रमिक चक्र जोखिमों का समाधान करते हैं, शेष कार्य अधिक निश्चित और प्रबंधनीय हो जाते हैं - प्रारंभिक चक्र खोजपूर्ण और धीमे (उच्च अनिश्चितता) होते हैं; बाद के चक्र अधिक कुशल हो जाते हैं क्योंकि वास्तुकला स्थिर हो जाती है, आवश्यकताएं मान्य हो जाती हैं, और टीमें बिना किसी जोखिम के उत्पादक निर्माण पर ध्यान केंद्रित कर सकती हैं
C
Spiral model velocity is constant across all cycles by design डिज़ाइन के अनुसार सर्पिल मॉडल वेग सभी चक्रों में स्थिर रहता है
D
Velocity always decreases in later Spiral cycles due to accumulated system complexity संचित प्रणाली जटिलता के कारण बाद के सर्पिल चक्रों में वेग हमेशा कम हो जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) This pattern explains why Spiral projects front-load risk reduction investment: early cycles may seem slow (research, prototypes, few deliverables) but they de-risk subsequent cycles. Once the LCA milestone is passed (architecture validated), construction velocity accelerates because developers work with clear specifications, stable APIs, and proven architectural patterns rather than discovering design problems mid-implementation.
व्याख्या (हिन्दी) यह पैटर्न बताता है कि क्यों स्पाइरल प्रोजेक्ट फ्रंट-लोड जोखिम कम करने वाला निवेश करता है: शुरुआती चक्र धीमे लग सकते हैं (अनुसंधान, प्रोटोटाइप, कुछ डिलिवरेबल्स) लेकिन वे बाद के चक्रों को जोखिम से मुक्त करते हैं। एक बार जब एलसीए मील का पत्थर पार हो जाता है (वास्तुकला मान्य), निर्माण वेग तेज हो जाता है क्योंकि डेवलपर्स कार्यान्वयन के बीच में डिजाइन समस्याओं की खोज करने के बजाय स्पष्ट विनिर्देशों, स्थिर एपीआई और सिद्ध वास्तुशिल्प पैटर्न के साथ काम करते हैं।
2668
EN + हिं Easy
GB What is 'risk-driven testing' as opposed to 'requirements-driven testing' in Spiral projects?
IN सर्पिल परियोजनाओं में 'आवश्यकताओं-संचालित परीक्षण' के विपरीत 'जोखिम-संचालित परीक्षण' क्या है?
A
Risk-driven testing tests only the riskiest requirements; requirements-driven tests everything equally जोखिम-संचालित परीक्षण केवल सबसे जोखिम भरी आवश्यकताओं का परीक्षण करता है; आवश्यकताओं-संचालित हर चीज़ का समान रूप से परीक्षण करता है
B
Risk-driven testing allocates testing effort proportional to the probability and impact of failure in each area — high-risk components (safety-critical, performance-critical, complex algorithms) receive disproportionately more testing than low-risk CRUD operations; requirements-driven testing covers all requirements equally regardless of risk जोखिम-संचालित परीक्षण प्रत्येक क्षेत्र में विफलता की संभावना और प्रभाव के अनुपात में परीक्षण प्रयास आवंटित करता है - उच्च जोखिम वाले घटक (सुरक्षा-महत्वपूर्ण, प्रदर्शन-महत्वपूर्ण, जटिल एल्गोरिदम) कम जोखिम वाले सीआरयूडी संचालन की तुलना में असंगत रूप से अधिक परीक्षण प्राप्त करते हैं; आवश्यकताओं-संचालित परीक्षण जोखिम की परवाह किए बिना सभी आवश्यकताओं को समान रूप से कवर करता है
C
Both testing approaches produce identical defect detection rates with the same effort दोनों परीक्षण दृष्टिकोण समान प्रयास से समान दोष पता लगाने की दर उत्पन्न करते हैं
D
Risk-driven testing was invented for Agile projects and is incompatible with the Spiral model जोखिम-संचालित परीक्षण का आविष्कार एजाइल परियोजनाओं के लिए किया गया था और यह स्पाइरल मॉडल के साथ असंगत है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Risk-based testing (van Veenendaal) applies the 80/20 principle: 20% of system components typically cause 80% of failures. Testing all components equally wastes testing effort on low-risk areas while under-testing high-risk ones. Risk analysis identifies: new/changed components (higher defect density), integration points (historical failure source), performance-critical paths, and safety-critical functions — these receive the concentrated testing investment.
व्याख्या (हिन्दी) जोखिम-आधारित परीक्षण (वैन वीनेंडाल) 80/20 सिद्धांत लागू करता है: 20% सिस्टम घटक आमतौर पर 80% विफलताओं का कारण बनते हैं। सभी घटकों का समान रूप से परीक्षण करने से कम जोखिम वाले क्षेत्रों पर परीक्षण प्रयास बर्बाद हो जाता है जबकि उच्च जोखिम वाले क्षेत्रों पर कम परीक्षण किया जाता है। जोखिम विश्लेषण पहचानता है: नए/परिवर्तित घटक (उच्च दोष घनत्व), एकीकरण बिंदु (ऐतिहासिक विफलता स्रोत), प्रदर्शन-महत्वपूर्ण पथ, और सुरक्षा-महत्वपूर्ण कार्य - ये केंद्रित परीक्षण निवेश प्राप्त करते हैं।
2669
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.
व्याख्या (हिन्दी) यह अनुशासन स्पाइरल की जोखिम प्रबंधन अखंडता को बनाए रखता है। कार्यान्वयन के दौरान 'उपयोगकर्ताओं को भी एक्स की आवश्यकता है' की खोज करने वाला एक डेवलपर यदि तुरंत पीछा किया जाता है तो चक्र पटरी से उतर जाएगा - एक्स के पास कोई जोखिम विश्लेषण, डिज़ाइन या अनुमान नहीं है। इसे अगले चक्र के लिए रिकॉर्ड करना सुनिश्चित करता है: एक्स को उचित जोखिम विश्लेषण मिलता है, वर्तमान चक्र अपने प्रतिबद्ध उद्देश्यों को पूरा करता है, और एक्स की प्राथमिकता को अन्य बैकलॉग आइटमों के मुकाबले तौला जाता है। यह एजाइल के स्प्रिंट बैकलॉग सुरक्षा नियम के समान है।
2670
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.
व्याख्या (हिन्दी) वास्तुशिल्प स्थिरता से पहले समवर्ती इंजीनियरिंग खतरनाक है: यदि सबसिस्टम ए के इंटरफेस मध्य-डिज़ाइन बदलते हैं, तो उन इंटरफेस के आधार पर अन्य सभी सबसिस्टम को समवर्ती रूप से अपना काम फिर से करना होगा। यही कारण है कि स्पाइरल का एलसीए मील का पत्थर (वास्तुकला मान्य) समवर्ती निर्माण के लिए पूर्व शर्त है। एलसीए के बाद, स्थिर आर्किटेक्चर निश्चित इंटरफेस प्रदान करता है जो समानांतर टीमों को एकीकरण जोखिम के बिना स्वतंत्र रूप से सबसिस्टम विकसित करने की अनुमति देता है।
2656–2670 of 2726