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
2506
EN + हिं Medium
GB What was the key historical lesson learned from the US DoD's use of Waterfall (MIL-STD-2167) for defence software?
IN रक्षा सॉफ्टवेयर के लिए यूएस DoD द्वारा वॉटरफॉल (MIL-STD-2167) के उपयोग से क्या महत्वपूर्ण ऐतिहासिक सबक सीखा गया?
A
Waterfall was proven to be the optimal process for all defence systems and remains mandatory today झरना सभी रक्षा प्रणालियों के लिए सर्वोत्तम प्रक्रिया साबित हुई है और आज भी अनिवार्य है
B
DoD found that rigid document-driven Waterfall produced systems that were late, over budget, and often failed to meet operational needs — leading to replacement with iterative methods (MIL-STD-498, then DoD's adoption of agile) DoD ने पाया कि कठोर दस्तावेज़-संचालित वॉटरफ़ॉल ने ऐसी प्रणालियाँ तैयार कीं जो देर से, बजट से अधिक थीं, और अक्सर परिचालन आवश्यकताओं को पूरा करने में विफल रहीं - जिसके कारण पुनरावृत्त तरीकों (MIL-STD-498, फिर DoD द्वारा एजाइल को अपनाना) को प्रतिस्थापित किया गया।
C
The lesson was that more documentation was needed; subsequent standards doubled mandatory document count सबक यह था कि अधिक दस्तावेज़ीकरण की आवश्यकता थी; बाद के मानकों ने अनिवार्य दस्तावेज़ संख्या दोगुनी कर दी
D
DoD found Waterfall perfect for software but unsuitable for hardware development DoD ने वॉटरफॉल को सॉफ़्टवेयर के लिए तो उपयुक्त पाया लेकिन हार्डवेयर विकास के लिए अनुपयुक्त पाया
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A 1994 GAO report found that of $37B spent on defence software, vast amounts were delivered but unusable, used as-is but significantly modified, or abandoned. This failure drove DoD to replace MIL-STD-2167 with more flexible standards and eventually embrace iterative/agile approaches. This case study became the canonical argument against rigid Waterfall for complex systems.
व्याख्या (हिन्दी) 1994 की जीएओ रिपोर्ट में पाया गया कि रक्षा सॉफ्टवेयर पर खर्च किए गए 37 अरब डॉलर में से बड़ी मात्रा में वितरित किए गए लेकिन अनुपयोगी थे, वैसे ही उपयोग किए गए लेकिन महत्वपूर्ण रूप से संशोधित किए गए, या छोड़ दिए गए। इस विफलता ने DoD को MIL-STD-2167 को अधिक लचीले मानकों से बदलने के लिए प्रेरित किया और अंततः पुनरावृत्त/चतुर तरीकों को अपनाया। यह केस अध्ययन जटिल प्रणालियों के लिए कठोर झरने के विरुद्ध विहित तर्क बन गया।
2507
EN + हिं Medium
GB How does the Spiral model address 'unknown unknowns' (risks that have not yet been identified)?
IN स्पाइरल मॉडल 'अज्ञात अज्ञात' (जो जोखिम अभी तक पहचाने नहीं गए हैं) को कैसे संबोधित करता है?
A
By requiring the team to list all possible risks in a master risk register before starting शुरू करने से पहले टीम को सभी संभावित जोखिमों को एक मास्टर जोखिम रजिस्टर में सूचीबद्ध करने की आवश्यकता होती है
B
By repeating risk identification at every cycle — earlier unknowns may become known as the project progresses and domain understanding deepens, allowing them to be addressed before they become crises हर चक्र में जोखिम की पहचान को दोहराने से - परियोजना की प्रगति और डोमेन की समझ गहरी होने पर पहले के अज्ञात ज्ञात हो सकते हैं, जिससे उन्हें संकट बनने से पहले ही संबोधित किया जा सकता है।
C
The Spiral model does not address unknown unknowns; only known risks are handled स्पाइरल मॉडल अज्ञात अज्ञात को संबोधित नहीं करता है; केवल ज्ञात जोखिमों को ही संभाला जाता है
D
Unknown unknowns are handled by the project sponsor who maintains a separate risk fund अज्ञात अज्ञात को परियोजना प्रायोजक द्वारा नियंत्रित किया जाता है जो एक अलग जोखिम कोष रखता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) While no process eliminates unknown unknowns, Spiral's iterative risk identification (each cycle starts fresh with 'what are the objectives and risks now?') gives them the opportunity to surface as the team learns more. Prototypes and early deliveries often reveal previously unknown constraints from user feedback — something Waterfall cannot do until late in the project.
व्याख्या (हिन्दी) जबकि कोई भी प्रक्रिया अज्ञात अज्ञात को खत्म नहीं करती है, स्पाइरल की पुनरावृत्त जोखिम पहचान (प्रत्येक चक्र 'अब उद्देश्य और जोखिम क्या हैं?' के साथ नए सिरे से शुरू होता है) उन्हें सामने आने का मौका देता है क्योंकि टीम अधिक सीखती है। प्रोटोटाइप और शुरुआती डिलीवरी अक्सर उपयोगकर्ता प्रतिक्रिया से पहले की अज्ञात बाधाओं को प्रकट करती हैं - कुछ ऐसा जो वॉटरफॉल परियोजना के अंत तक नहीं कर सकता है।
2508
EN + हिं Easy
GB What is the relationship between the Spiral model and risk management in terms of project investment decisions?
IN परियोजना निवेश निर्णयों के संदर्भ में स्पाइरल मॉडल और जोखिम प्रबंधन के बीच क्या संबंध है?
A
The Spiral model requires full project investment upfront before any risk analysis is performed किसी भी जोखिम विश्लेषण के प्रदर्शन से पहले स्पाइरल मॉडल को पूर्ण परियोजना निवेश की आवश्यकता होती है
B
Each Spiral cycle represents a deliberate investment decision — stakeholders review risk status before committing to the next cycle, allowing early termination if the risk-adjusted value of continuation is negative प्रत्येक सर्पिल चक्र एक जानबूझकर किए गए निवेश निर्णय का प्रतिनिधित्व करता है - हितधारक अगले चक्र के लिए प्रतिबद्ध होने से पहले जोखिम की स्थिति की समीक्षा करते हैं, यदि निरंतरता का जोखिम-समायोजित मूल्य नकारात्मक है तो शीघ्र समाप्ति की अनुमति दी जाती है।
C
Investment decisions in Spiral are made by developers, not business stakeholders स्पाइरल में निवेश के निर्णय डेवलपर्स द्वारा लिए जाते हैं, न कि व्यावसायिक हितधारकों द्वारा
D
The Spiral model does not consider financial investment; it only focuses on technical risk स्पाइरल मॉडल वित्तीय निवेश पर विचार नहीं करता है; यह केवल तकनीकी जोखिम पर केंद्रित है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Spiral's real-options thinking treats each cycle as an option to invest further. If risk analysis after cycle 1 shows the project is viable, exercise the option and fund cycle 2. If not, abandon before larger investment. This is economically rational — matching investment commitment to knowledge level — unlike Waterfall's 100% upfront commitment.
व्याख्या (हिन्दी) स्पाइरल की वास्तविक-विकल्प सोच प्रत्येक चक्र को आगे निवेश करने के विकल्प के रूप में मानती है। यदि चक्र 1 के बाद जोखिम विश्लेषण से पता चलता है कि परियोजना व्यवहार्य है, तो विकल्प और फंड चक्र 2 का प्रयोग करें। यदि नहीं, तो बड़े निवेश से पहले छोड़ दें। यह आर्थिक रूप से तर्कसंगत है - ज्ञान स्तर के अनुरूप निवेश प्रतिबद्धता - वॉटरफॉल की 100% अग्रिम प्रतिबद्धता के विपरीत।
2509
EN + हिं Easy
GB In a Spiral project for a missile guidance system, during cycle 2 the prototype demonstrates that the required navigation accuracy cannot be achieved with current sensor technology. What is the correct Spiral response?
IN मिसाइल मार्गदर्शन प्रणाली के लिए एक सर्पिल परियोजना में, चक्र 2 के दौरान प्रोटोटाइप दर्शाता है कि वर्तमान सेंसर तकनीक के साथ आवश्यक नेविगेशन सटीकता प्राप्त नहीं की जा सकती है। सही सर्पिल प्रतिक्रिया क्या है?
A
Continue to cycle 3 with the current sensors and reduce requirements to match capability वर्तमान सेंसर के साथ चक्र 3 जारी रखें और क्षमता से मेल खाने के लिए आवश्यकताओं को कम करें
B
The risk finding should halt further development investment until the sensor technology gap is resolved through: sourcing better sensors, redesigning the algorithm to work with available accuracy, or revising the system requirements with stakeholders जब तक सेंसर प्रौद्योगिकी अंतर का समाधान नहीं हो जाता, तब तक जोखिम का पता लगाने के लिए आगे के विकास निवेश को रोक देना चाहिए: बेहतर सेंसर की सोर्सिंग, उपलब्ध सटीकता के साथ काम करने के लिए एल्गोरिदम को फिर से डिजाइन करना, या हितधारकों के साथ सिस्टम आवश्यकताओं को संशोधित करना।
C
Report the technical failure to management and continue development on schedule regardless प्रबंधन को तकनीकी विफलता की रिपोर्ट करें और इसकी परवाह किए बिना निर्धारित समय पर विकास जारी रखें
D
Spiral methodology does not apply to hardware-dependent systems like guidance systems सर्पिल कार्यप्रणाली मार्गदर्शन प्रणालियों जैसे हार्डवेयर-निर्भर प्रणालियों पर लागू नहीं होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Cycle 2's prototype has performed its function: it has identified a critical technical risk early when it is cheapest to address. Continuing to invest in a system with a known fatal technical constraint would be exactly the waste the Spiral model is designed to prevent. The risk resolution options (better sensors, algorithm redesign, requirements relaxation) are all legitimate Spiral responses.
व्याख्या (हिन्दी) साइकिल 2 के प्रोटोटाइप ने अपना कार्य पूरा कर लिया है: इसने एक गंभीर तकनीकी जोखिम की पहचान पहले ही कर ली है, जबकि इसका समाधान करना सबसे सस्ता है। एक ज्ञात घातक तकनीकी बाधा वाले सिस्टम में निवेश जारी रखना ठीक वैसी ही बर्बादी होगी जिसे रोकने के लिए स्पाइरल मॉडल डिज़ाइन किया गया है। जोखिम समाधान विकल्प (बेहतर सेंसर, एल्गोरिदम रीडिज़ाइन, आवश्यकताओं में छूट) सभी वैध सर्पिल प्रतिक्रियाएँ हैं।
2510
EN + हिं Easy
GB What is the 'win-win' extension to the Spiral model and what negotiation problem does it address?
IN स्पाइरल मॉडल का 'जीत-जीत' विस्तार क्या है और यह किस बातचीत की समस्या का समाधान करता है?
A
Win-win extension adds financial incentive bonuses for teams that complete cycles ahead of schedule विन-विन एक्सटेंशन उन टीमों के लिए वित्तीय प्रोत्साहन बोनस जोड़ता है जो निर्धारित समय से पहले चक्र पूरा करते हैं
B
Win-win Spiral adds a stakeholder negotiation activity at each cycle's start — addressing the problem that different stakeholders have conflicting objectives, ensuring all parties agree on conditions of satisfaction before proceeding विन-विन स्पाइरल प्रत्येक चक्र की शुरुआत में एक हितधारक बातचीत गतिविधि जोड़ता है - इस समस्या का समाधान करते हुए कि विभिन्न हितधारकों के परस्पर विरोधी उद्देश्य हैं, यह सुनिश्चित करना कि सभी पक्ष आगे बढ़ने से पहले संतुष्टि की शर्तों पर सहमत हों
C
Win-win extension replaces risk analysis with stakeholder surveys in each cycle विन-विन एक्सटेंशन प्रत्येक चक्र में हितधारक सर्वेक्षण के साथ जोखिम विश्लेषण को प्रतिस्थापित करता है
D
Win-win Spiral was developed by Cockburn as an alternative to Boehm's original model विन-विन स्पाइरल को कॉकबर्न द्वारा बोहेम के मूल मॉडल के विकल्प के रूप में विकसित किया गया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm's Win-Win Spiral (1998) adds a systematic stakeholder negotiation quadrant: identify each stakeholder's 'win conditions', identify conflicts, negotiate to a mutually satisfactory agreement before proceeding. This addresses the failure mode where developers build what the spec says but not what stakeholders actually needed — because stakeholder objectives were never explicitly elicited and reconciled.
व्याख्या (हिन्दी) बोहेम का विन-विन स्पाइरल (1998) एक व्यवस्थित हितधारक वार्ता चतुर्थांश जोड़ता है: प्रत्येक हितधारक की 'जीत की स्थिति' की पहचान करें, संघर्षों की पहचान करें, आगे बढ़ने से पहले पारस्परिक रूप से संतोषजनक समझौते पर बातचीत करें। यह विफलता मोड को संबोधित करता है जहां डेवलपर्स वह बनाते हैं जो विनिर्देश कहता है लेकिन वह नहीं जो हितधारकों को वास्तव में चाहिए - क्योंकि हितधारक उद्देश्यों को कभी भी स्पष्ट रूप से प्राप्त नहीं किया गया था और उनका समाधान नहीं किया गया था।
2511
EN + हिं Medium
GB What distinguishes 'technical risk' from 'project risk' in Spiral model risk analysis?
IN स्पाइरल मॉडल जोखिम विश्लेषण में 'तकनीकी जोखिम' को 'प्रोजेक्ट जोखिम' से क्या अलग करता है?
A
Technical risks are identified by developers; project risks by project managers डेवलपर्स द्वारा तकनीकी जोखिमों की पहचान की जाती है; परियोजना प्रबंधकों द्वारा परियोजना जोखिम
B
Technical risks concern feasibility (can we build it with available technology?); project risks concern management factors (schedule, cost, staffing, dependencies) — both categories must be analysed in each Spiral cycle तकनीकी जोखिम व्यवहार्यता से संबंधित हैं (क्या हम इसे उपलब्ध तकनीक से बना सकते हैं?); परियोजना जोखिम चिंता प्रबंधन कारक (अनुसूची, लागत, स्टाफिंग, निर्भरता) - प्रत्येक सर्पिल चक्र में दोनों श्रेणियों का विश्लेषण किया जाना चाहिए
C
Technical risks are only relevant in cycle 1; project risks only in cycle 4 तकनीकी जोखिम केवल चक्र 1 में प्रासंगिक हैं; परियोजना जोखिम केवल चक्र 4 में हैं
D
Technical risks are always higher than project risks in software development सॉफ़्टवेयर विकास में तकनीकी जोखिम हमेशा परियोजना जोखिमों से अधिक होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Spiral risk analysis must cover both dimensions. Technical risks: can the performance requirements be met? Does the required algorithm exist? Can the architecture scale? Project risks: is the team size adequate? Is the schedule realistic? Are key dependencies controllable? Addressing only technical risk while ignoring staffing or schedule risk leads to projects that are technically feasible but managerially undeliverable.
व्याख्या (हिन्दी) सर्पिल जोखिम विश्लेषण में दोनों आयामों को शामिल किया जाना चाहिए। तकनीकी जोखिम: क्या प्रदर्शन आवश्यकताओं को पूरा किया जा सकता है? क्या आवश्यक एल्गोरिदम मौजूद है? क्या वास्तुकला का पैमाना हो सकता है? परियोजना जोखिम: क्या टीम का आकार पर्याप्त है? क्या शेड्यूल यथार्थवादी है? क्या प्रमुख निर्भरताएँ नियंत्रणीय हैं? स्टाफिंग या शेड्यूल जोखिम को नजरअंदाज करते हुए केवल तकनीकी जोखिम को संबोधित करने से ऐसी परियोजनाएं बनती हैं जो तकनीकी रूप से व्यवहार्य हैं लेकिन प्रबंधकीय रूप से अविश्वसनीय हैं।
2512
EN + हिं Easy
GB What is the 'spiral within a spiral' concept when applying the Spiral model to subsystem development?
IN सबसिस्टम विकास के लिए स्पाइरल मॉडल को लागू करते समय 'सर्पिल के भीतर सर्पिल' अवधारणा क्या है?
A
Each developer independently runs their own mini-spiral for their assigned modules प्रत्येक डेवलपर स्वतंत्र रूप से अपने निर्दिष्ट मॉड्यूल के लिए अपना स्वयं का मिनी-सर्पिल चलाता है
B
The overall system development follows a Spiral, and each major subsystem may independently use its own Spiral within the context of the system-level spiral — allowing subsystem-specific risk management while aligning to system milestones समग्र सिस्टम विकास एक स्पाइरल का अनुसरण करता है, और प्रत्येक प्रमुख सबसिस्टम स्वतंत्र रूप से सिस्टम-स्तरीय स्पाइरल के संदर्भ में अपने स्वयं के स्पाइरल का उपयोग कर सकता है - सिस्टम मील के पत्थर के साथ संरेखित करते हुए सबसिस्टम-विशिष्ट जोखिम प्रबंधन की अनुमति देता है।
C
Spiral within a spiral is a theoretical concept with no practical implementation सर्पिल के भीतर सर्पिल एक सैद्धांतिक अवधारणा है जिसका कोई व्यावहारिक कार्यान्वयन नहीं है
D
Using nested spirals violates Boehm's original model and invalidates risk assessments नेस्टेड स्पाइरल का उपयोग बोहेम के मूल मॉडल का उल्लंघन करता है और जोखिम आकलन को अमान्य कर देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Large systems (defence, aerospace) decompose into subsystems each with their own risk profiles. The system-level Spiral sets milestones; each subsystem runs its own Spiral calibrated to its specific risks — a navigation subsystem may need more cycles to resolve sensor accuracy risks than the power management subsystem needs. Anchor point milestones synchronise subsystem spirals at the system level.
व्याख्या (हिन्दी) बड़ी प्रणालियाँ (रक्षा, एयरोस्पेस) अपने स्वयं के जोखिम प्रोफाइल के साथ उपप्रणालियों में विघटित हो जाती हैं। सिस्टम-स्तरीय स्पाइरल मील के पत्थर निर्धारित करता है; प्रत्येक सबसिस्टम अपने विशिष्ट जोखिमों के अनुसार कैलिब्रेटेड अपना स्वयं का सर्पिल चलाता है - एक नेविगेशन सबसिस्टम को पावर प्रबंधन सबसिस्टम की जरूरतों की तुलना में सेंसर सटीकता जोखिमों को हल करने के लिए अधिक चक्रों की आवश्यकता हो सकती है। एंकर बिंदु मील के पत्थर सिस्टम स्तर पर सबसिस्टम सर्पिल को सिंक्रनाइज़ करते हैं।
2513
EN + हिं Medium
GB Why is the Spiral model considered unsuitable for 'cost-constrained' or 'schedule-constrained' contracts?
IN स्पाइरल मॉडल को 'लागत-बाधित' या 'अनुसूची-बाधित' अनुबंधों के लिए अनुपयुक्त क्यों माना जाता है?
A
Spiral model contracts always exceed their cost estimates due to the risk analysis overhead जोखिम विश्लेषण ओवरहेड के कारण सर्पिल मॉडल अनुबंध हमेशा अपने लागत अनुमान से अधिक होते हैं
B
The variable number of Spiral cycles makes firm fixed-price commitments difficult — the total cost and duration are not determinable upfront because the number of risk-resolution cycles needed cannot be predicted with confidence सर्पिल चक्रों की परिवर्तनीय संख्या फर्म की निश्चित-मूल्य प्रतिबद्धताओं को कठिन बनाती है - कुल लागत और अवधि पहले से निर्धारित नहीं की जा सकती क्योंकि आवश्यक जोखिम-समाधान चक्रों की संख्या का विश्वास के साथ अनुमान नहीं लगाया जा सकता है
C
Spiral model is unsuitable because it requires expensive third-party risk consultants for each cycle सर्पिल मॉडल अनुपयुक्त है क्योंकि इसमें प्रत्येक चक्र के लिए महंगे तृतीय-पक्ष जोखिम सलाहकारों की आवश्यकता होती है
D
Spiral model contracts violate standard commercial contracting law in most jurisdictions सर्पिल मॉडल अनुबंध अधिकांश न्यायालयों में मानक वाणिज्यिक अनुबंध कानून का उल्लंघन करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Government and commercial fixed-price contracts require upfront agreement on deliverables, cost, and schedule. Spiral's strength (adjusting scope and duration based on evolving risk) becomes a contracting weakness — you cannot sign a fixed-price contract when the total work scope is not yet defined. This is why Spiral is most commonly used for cost-reimbursable or time-and-materials contracts.
व्याख्या (हिन्दी) सरकारी और वाणिज्यिक निश्चित-मूल्य अनुबंधों के लिए डिलिवरेबल्स, लागत और शेड्यूल पर अग्रिम समझौते की आवश्यकता होती है। स्पाइरल की ताकत (बढ़ते जोखिम के आधार पर दायरे और अवधि को समायोजित करना) एक अनुबंध की कमजोरी बन जाती है - जब कुल कार्य दायरा अभी तक परिभाषित नहीं किया गया है तो आप एक निश्चित मूल्य अनुबंध पर हस्ताक्षर नहीं कर सकते हैं। यही कारण है कि स्पाइरल का उपयोग आमतौर पर लागत-प्रतिपूर्ति योग्य या समय-और-सामग्री अनुबंधों के लिए किया जाता है।
2514
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.
व्याख्या (हिन्दी) यह अंतर दिलचस्प तनाव पैदा करता है: स्पाइरल किसी भी उपयोगकर्ता-दृश्यमान सुविधाओं के अस्तित्व में आने से पहले कम मूल्य वाले लेकिन उच्च जोखिम वाले तकनीकी घटकों (एक महत्वपूर्ण एल्गोरिदम की व्यवहार्यता साबित करने) पर प्रारंभिक चक्र खर्च कर सकता है। एजाइल पहले उच्च-मूल्य वाली उपयोगकर्ता कहानियों को प्राथमिकता देगा। अनुसंधान-गहन या तकनीकी रूप से अनिश्चित परियोजनाओं के लिए, स्पाइरल का दृष्टिकोण कोर को तकनीकी रूप से व्यवहार्य साबित करने से पहले पॉलिश में निवेश करने से रोकता है।
2515
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.
व्याख्या (हिन्दी) व्यावसायिक जोखिम उतना ही महत्वपूर्ण है जितना व्यावसायिक सॉफ्टवेयर में तकनीकी जोखिम। स्पाइरल के व्यापक जोखिम दायरे में स्पष्ट रूप से बाजार जोखिम शामिल हैं: क्या उपयोगकर्ता इसे अपनाएंगे? क्या कोई प्रतिस्पर्धी उत्पाद पहले से ही इस समस्या को बेहतर ढंग से हल कर सकता है? प्रारंभिक चक्र जोखिम पहचान में प्रतिस्पर्धी विश्लेषण शामिल करने से तकनीकी रूप से सफल परियोजनाएं जो व्यावसायिक रूप से विफल हो जाती हैं, उन्हें रोकती है - एक सामान्य और महंगी विफलता मोड।
2516
EN + हिं Easy
GB What is the 'anchor point milestone' LCA (Life Cycle Architecture) in the Win-Win Spiral and what must it demonstrate?
IN विन-विन स्पाइरल में 'एंकर प्वाइंट मील का पत्थर' एलसीए (जीवन चक्र वास्तुकला) क्या है और इसे क्या प्रदर्शित करना चाहिए?
A
LCA demonstrates that the software code passes all unit tests with 100% coverage एलसीए दर्शाता है कि सॉफ्टवेयर कोड 100% कवरेज के साथ सभी यूनिट परीक्षणों को पास करता है
B
LCA must demonstrate that the architecture is stable enough to support the full system, that all top architectural risks have been resolved, and that the construction phase can proceed without fundamental architectural rework एलसीए को यह प्रदर्शित करना होगा कि वास्तुकला पूरी प्रणाली का समर्थन करने के लिए पर्याप्त रूप से स्थिर है, कि सभी शीर्ष वास्तुशिल्प जोखिमों का समाधान हो गया है, और निर्माण चरण मौलिक वास्तुशिल्प पुनर्निर्माण के बिना आगे बढ़ सकता है
C
LCA is achieved when all UML diagrams have been reviewed and approved by the customer एलसीए तब प्राप्त होता है जब ग्राहक द्वारा सभी यूएमएल आरेखों की समीक्षा और अनुमोदन किया गया हो
D
LCA requires all hardware components to be physically available and tested एलसीए को सभी हार्डवेयर घटकों को भौतिक रूप से उपलब्ध और परीक्षण करने की आवश्यकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) LCA (equivalent to UP's Elaboration milestone) is the critical Spiral gate before major construction investment. It requires: an architectural prototype showing key risks are resolved, a credible cost/schedule estimate for remaining work, stakeholder agreement to proceed, and elimination of fundamental uncertainties that would require architectural redesign in construction.
व्याख्या (हिन्दी) एलसीए (यूपी के विस्तार मील के पत्थर के बराबर) प्रमुख निर्माण निवेश से पहले महत्वपूर्ण सर्पिल द्वार है। इसके लिए आवश्यक है: प्रमुख जोखिमों को हल करने वाला एक वास्तुशिल्प प्रोटोटाइप, शेष कार्य के लिए एक विश्वसनीय लागत/अनुसूची अनुमान, आगे बढ़ने के लिए हितधारक समझौता, और मूलभूत अनिश्चितताओं का उन्मूलन जिसके लिए निर्माण में वास्तुशिल्प पुन: डिज़ाइन की आवश्यकता होगी।
2517
EN + हिं Medium
GB What is the 'planning game' in XP and how does it distribute planning responsibility?
IN XP में 'प्लानिंग गेम' क्या है और यह प्लानिंग जिम्मेदारी कैसे वितरित करता है?
A
The planning game is a tool for estimating story points using poker cards exclusively प्लानिंग गेम विशेष रूप से पोकर कार्ड का उपयोग करके कहानी के बिंदुओं का अनुमान लगाने का एक उपकरण है
B
The planning game splits responsibility: business decides scope and priority (story selection, release dates); technology decides estimates and technical approach (how long, how to implement) — neither can override the other's domain नियोजन का खेल जिम्मेदारी को विभाजित करता है: व्यवसाय दायरा और प्राथमिकता तय करता है (कहानी का चयन, रिलीज की तारीखें); प्रौद्योगिकी अनुमान और तकनीकी दृष्टिकोण (कब तक, कैसे लागू करना है) तय करती है - कोई भी दूसरे के डोमेन को ओवरराइड नहीं कर सकता है
C
In XP, project managers alone conduct the planning game without developer input एक्सपी में, प्रोजेक्ट मैनेजर अकेले ही डेवलपर इनपुट के बिना प्लानिंग गेम संचालित करते हैं
D
The planning game replaces all other ceremonies in XP, making retrospectives and reviews unnecessary नियोजन गेम XP में अन्य सभी समारोहों को प्रतिस्थापित कर देता है, जिससे पूर्वव्यापी और समीक्षाएँ अनावश्यक हो जाती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) XP's planning game separates concerns: business stakeholders have authority over WHAT gets built (scope, priority, release date) and technology team has authority over HOW LONG it takes and HOW it's implemented. Neither party can dictate in the other's domain — business cannot set estimates; technology cannot set business priority. This mutual constraint prevents both gold plating and unrealistic scheduling.
व्याख्या (हिन्दी) एक्सपी का नियोजन गेम चिंताओं को अलग करता है: व्यावसायिक हितधारकों के पास इस बात पर अधिकार होता है कि क्या बनाया जाता है (दायरा, प्राथमिकता, रिलीज की तारीख) और प्रौद्योगिकी टीम के पास कितना समय लगता है और इसे कैसे लागू किया जाता है, इस पर अधिकार है। कोई भी पक्ष दूसरे के क्षेत्र में आदेश नहीं दे सकता - व्यवसाय अनुमान निर्धारित नहीं कर सकता; प्रौद्योगिकी व्यावसायिक प्राथमिकता निर्धारित नहीं कर सकती। यह पारस्परिक बाधा सोना चढ़ाना और अवास्तविक शेड्यूलिंग दोनों को रोकती है।
2518
EN + हिं Medium
GB What is 'test-first programming' in XP and how does it differ from the broader TDD practice?
IN एक्सपी में 'टेस्ट-फर्स्ट प्रोग्रामिंग' क्या है और यह व्यापक टीडीडी अभ्यास से कैसे भिन्न है?
A
Test-first programming writes tests after code in XP; TDD writes tests before code टेस्ट-फर्स्ट प्रोग्रामिंग XP में कोड के बाद टेस्ट लिखती है; टीडीडी कोड से पहले परीक्षण लिखता है
B
Test-first programming in XP applies at unit level within the context of frequent release, refactoring, and customer collaboration; TDD is a more general design technique applicable across any development context regardless of other XP practices एक्सपी में टेस्ट-फर्स्ट प्रोग्रामिंग लगातार रिलीज, रीफैक्टरिंग और ग्राहक सहयोग के संदर्भ में यूनिट स्तर पर लागू होती है; टीडीडी एक अधिक सामान्य डिजाइन तकनीक है जो अन्य एक्सपी प्रथाओं की परवाह किए बिना किसी भी विकास संदर्भ में लागू होती है
C
Both terms are exactly synonymous with no distinction in practice or scope दोनों शब्द बिल्कुल पर्यायवाची हैं और व्यवहार या दायरे में कोई अंतर नहीं है
D
Test-first programming only applies to acceptance tests; TDD only to unit tests टेस्ट-फर्स्ट प्रोग्रामिंग केवल स्वीकृति परीक्षणों पर लागू होती है; केवल इकाई परीक्षणों के लिए टीडीडी
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) While functionally similar, test-first in XP is embedded within XP's ecosystem: it works in conjunction with pair programming (both developers see the test fail together), continuous integration (tests run every few hours), and on-site customer (acceptance tests defined with customer). TDD as popularised by Kent Beck and later Robert Martin is a general practice independent of any particular methodology's social practices.
व्याख्या (हिन्दी) कार्यात्मक रूप से समान होते हुए भी, एक्सपी में टेस्ट-फर्स्ट एक्सपी के पारिस्थितिकी तंत्र के भीतर एम्बेडेड है: यह जोड़ी प्रोग्रामिंग (दोनों डेवलपर्स एक साथ परीक्षण विफल देखते हैं), निरंतर एकीकरण (हर कुछ घंटों में परीक्षण चलाते हैं), और ऑन-साइट ग्राहक (ग्राहक के साथ परिभाषित स्वीकृति परीक्षण) के साथ मिलकर काम करता है। केंट बेक और बाद में रॉबर्ट मार्टिन द्वारा लोकप्रिय टीडीडी किसी विशेष पद्धति की सामाजिक प्रथाओं से स्वतंत्र एक सामान्य अभ्यास है।
2519
EN + हिं Easy
GB What is 'collective code ownership' in XP and what risk does it introduce that must be managed?
IN XP में 'सामूहिक कोड स्वामित्व' क्या है और यह कौन सा जोखिम उत्पन्न करता है जिसे प्रबंधित किया जाना चाहिए?
A
Collective code ownership means all developers must approve every code change by committee vote सामूहिक कोड स्वामित्व का अर्थ है कि सभी डेवलपर्स को समिति के वोट द्वारा प्रत्येक कोड परिवर्तन को मंजूरी देनी होगी
B
Collective code ownership means any developer can improve any code at any time without permission; it introduces the risk of uncoordinated changes causing integration conflicts — managed through CI, test suites, and coding standards सामूहिक कोड स्वामित्व का अर्थ है कि कोई भी डेवलपर बिना अनुमति के किसी भी समय किसी भी कोड में सुधार कर सकता है; यह एकीकरण संघर्षों के कारण असंगठित परिवर्तनों के जोखिम का परिचय देता है - सीआई, परीक्षण सूट और कोडिंग मानकों के माध्यम से प्रबंधित किया जाता है
C
Collective code ownership requires all code to be attributed to no individual developer for legal reasons सामूहिक कोड स्वामित्व के लिए कानूनी कारणों से सभी कोड का श्रेय किसी व्यक्तिगत डेवलपर को नहीं दिया जाना आवश्यक है
D
Collective ownership only applies to test code; production code retains individual ownership सामूहिक स्वामित्व केवल परीक्षण कोड पर लागू होता है; उत्पादन कोड व्यक्तिगत स्वामित्व बरकरार रखता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Collective ownership eliminates knowledge silos and bus-factor risks — any developer can fix any bug in any module. The risks (style inconsistency, conflicting refactors) are mitigated by: automated tests that catch regressions immediately, CI that detects integration conflicts within hours, shared coding standards that maintain style consistency, and frequent integration that keeps branches short-lived.
व्याख्या (हिन्दी) सामूहिक स्वामित्व ज्ञान साइलो और बस-कारक जोखिमों को समाप्त करता है - कोई भी डेवलपर किसी भी मॉड्यूल में किसी भी बग को ठीक कर सकता है। जोखिम (शैली असंगतता, विरोधाभासी रिफैक्टर) को कम किया जाता है: स्वचालित परीक्षण जो प्रतिगमन को तुरंत पकड़ते हैं, सीआई जो घंटों के भीतर एकीकरण संघर्ष का पता लगाता है, साझा कोडिंग मानक जो शैली स्थिरता बनाए रखते हैं, और लगातार एकीकरण जो शाखाओं को अल्पकालिक रखता है।
2520
EN + हिं Easy
GB What is the 'sustainable pace' (formerly 40-hour week) practice in XP and what empirical evidence supports it?
IN एक्सपी में 'टिकाऊ गति' (पूर्व में 40 घंटे का सप्ताह) अभ्यास क्या है और कौन से अनुभवजन्य साक्ष्य इसका समर्थन करते हैं?
A
Sustainable pace means developers must work exactly 40 hours per week, no more, no less सतत गति का मतलब है कि डेवलपर्स को प्रति सप्ताह ठीक 40 घंटे काम करना होगा, न अधिक, न कम
B
Sustainable pace means working at a pace that can be maintained indefinitely — empirical evidence shows that sustained overtime increases defect rates (fatigue reduces judgment), destroys team morale, and rarely recovers schedule because defect rework consumes the gained time सतत गति का मतलब ऐसी गति से काम करना है जिसे अनिश्चित काल तक बनाए रखा जा सकता है - अनुभवजन्य साक्ष्य से पता चलता है कि निरंतर ओवरटाइम से दोष दर बढ़ जाती है (थकान निर्णय को कम कर देती है), टीम के मनोबल को नष्ट कर देती है, और शायद ही कभी शेड्यूल ठीक हो पाता है क्योंकि दोष पुनर्कार्य में प्राप्त समय की खपत होती है
C
Sustainable pace was removed from XP2 (second edition) and is no longer considered an XP practice सतत गति को XP2 (दूसरे संस्करण) से हटा दिया गया था और अब इसे XP अभ्यास नहीं माना जाता है
D
Sustainable pace only applies to junior developers; senior developers are exempt from this constraint सतत गति केवल कनिष्ठ डेवलपर्स पर लागू होती है; वरिष्ठ डेवलपर्स को इस बाधा से छूट है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Research on programmer productivity (DeMarco and Lister, 'Peopleware'; Scrum's empirical data) consistently shows diminishing returns from extended overtime. Fatigue impairs the complex problem-solving that programming requires. XP's sustainable pace recognises that a rested team consistently produces more value per week than an exhausted team working 60+ hours — even measured in lines of code, let alone quality.
व्याख्या (हिन्दी) प्रोग्रामर उत्पादकता पर शोध (डेमार्को और लिस्टर, 'पीपुलवेयर'; स्क्रम का अनुभवजन्य डेटा) लगातार विस्तारित ओवरटाइम से घटते रिटर्न को दर्शाता है। थकान प्रोग्रामिंग के लिए आवश्यक जटिल समस्या-समाधान को बाधित करती है। एक्सपी की टिकाऊ गति यह मानती है कि एक आराम करने वाली टीम लगातार 60+ घंटे काम करने वाली एक थकी हुई टीम की तुलना में प्रति सप्ताह अधिक मूल्य पैदा करती है - यहां तक ​​कि कोड की पंक्तियों में भी मापा जाता है, गुणवत्ता की तो बात ही छोड़ दें।
2506–2520 of 2726