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
2266
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 के प्रोटोटाइप ने अपना कार्य पूरा कर लिया है: इसने एक गंभीर तकनीकी जोखिम की पहचान पहले ही कर ली है, जबकि इसका समाधान करना सबसे सस्ता है। एक ज्ञात घातक तकनीकी बाधा वाले सिस्टम में निवेश जारी रखना ठीक वैसी ही बर्बादी होगी जिसे रोकने के लिए स्पाइरल मॉडल डिज़ाइन किया गया है। जोखिम समाधान विकल्प (बेहतर सेंसर, एल्गोरिदम रीडिज़ाइन, आवश्यकताओं में छूट) सभी वैध सर्पिल प्रतिक्रियाएँ हैं।
2267
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) एक व्यवस्थित हितधारक वार्ता चतुर्थांश जोड़ता है: प्रत्येक हितधारक की 'जीत की स्थिति' की पहचान करें, संघर्षों की पहचान करें, आगे बढ़ने से पहले पारस्परिक रूप से संतोषजनक समझौते पर बातचीत करें। यह विफलता मोड को संबोधित करता है जहां डेवलपर्स वह बनाते हैं जो विनिर्देश कहता है लेकिन वह नहीं जो हितधारकों को वास्तव में चाहिए - क्योंकि हितधारक उद्देश्यों को कभी भी स्पष्ट रूप से प्राप्त नहीं किया गया था और उनका समाधान नहीं किया गया था।
2268
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.
व्याख्या (हिन्दी) सर्पिल जोखिम विश्लेषण में दोनों आयामों को शामिल किया जाना चाहिए। तकनीकी जोखिम: क्या प्रदर्शन आवश्यकताओं को पूरा किया जा सकता है? क्या आवश्यक एल्गोरिदम मौजूद है? क्या वास्तुकला का पैमाना हो सकता है? परियोजना जोखिम: क्या टीम का आकार पर्याप्त है? क्या शेड्यूल यथार्थवादी है? क्या प्रमुख निर्भरताएँ नियंत्रणीय हैं? स्टाफिंग या शेड्यूल जोखिम को नजरअंदाज करते हुए केवल तकनीकी जोखिम को संबोधित करने से ऐसी परियोजनाएं बनती हैं जो तकनीकी रूप से व्यवहार्य हैं लेकिन प्रबंधकीय रूप से अविश्वसनीय हैं।
2269
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.
व्याख्या (हिन्दी) बड़ी प्रणालियाँ (रक्षा, एयरोस्पेस) अपने स्वयं के जोखिम प्रोफाइल के साथ उपप्रणालियों में विघटित हो जाती हैं। सिस्टम-स्तरीय स्पाइरल मील के पत्थर निर्धारित करता है; प्रत्येक सबसिस्टम अपने विशिष्ट जोखिमों के अनुसार कैलिब्रेटेड अपना स्वयं का सर्पिल चलाता है - एक नेविगेशन सबसिस्टम को पावर प्रबंधन सबसिस्टम की जरूरतों की तुलना में सेंसर सटीकता जोखिमों को हल करने के लिए अधिक चक्रों की आवश्यकता हो सकती है। एंकर बिंदु मील के पत्थर सिस्टम स्तर पर सबसिस्टम सर्पिल को सिंक्रनाइज़ करते हैं।
2270
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.
व्याख्या (हिन्दी) सरकारी और वाणिज्यिक निश्चित-मूल्य अनुबंधों के लिए डिलिवरेबल्स, लागत और शेड्यूल पर अग्रिम समझौते की आवश्यकता होती है। 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. यही कारण है कि स्पाइरल का उपयोग आमतौर पर लागत-प्रतिपूर्ति योग्य या समय-और-सामग्री अनुबंधों के लिए किया जाता है।
2271
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.
व्याख्या (हिन्दी) यह अंतर दिलचस्प तनाव पैदा करता है: स्पाइरल किसी भी उपयोगकर्ता-दृश्यमान सुविधाओं के अस्तित्व में आने से पहले कम मूल्य वाले लेकिन उच्च जोखिम वाले तकनीकी घटकों (एक महत्वपूर्ण एल्गोरिदम की व्यवहार्यता साबित करने) पर प्रारंभिक चक्र खर्च कर सकता है। एजाइल पहले उच्च-मूल्य वाली उपयोगकर्ता कहानियों को प्राथमिकता देगा। For research-intensive or technically uncertain projects, Spiral's approach prevents investing in polish before proving the core is technically viable.
2272
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.
व्याख्या (हिन्दी) व्यावसायिक जोखिम उतना ही महत्वपूर्ण है जितना व्यावसायिक सॉफ्टवेयर में तकनीकी जोखिम। स्पाइरल के व्यापक जोखिम दायरे में स्पष्ट रूप से बाजार जोखिम शामिल हैं: क्या उपयोगकर्ता इसे अपनाएंगे? क्या कोई प्रतिस्पर्धी उत्पाद पहले से ही इस समस्या को बेहतर ढंग से हल कर सकता है? प्रारंभिक चक्र जोखिम पहचान में प्रतिस्पर्धी विश्लेषण शामिल करने से तकनीकी रूप से सफल परियोजनाएं जो व्यावसायिक रूप से विफल हो जाती हैं, उन्हें रोकती है - एक सामान्य और महंगी विफलता मोड।
2273
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.
व्याख्या (हिन्दी) एलसीए (यूपी के विस्तार मील के पत्थर के बराबर) प्रमुख निर्माण निवेश से पहले महत्वपूर्ण सर्पिल द्वार है। इसके लिए आवश्यक है: प्रमुख जोखिमों को हल करने वाला एक वास्तुशिल्प प्रोटोटाइप, शेष कार्य के लिए एक विश्वसनीय लागत/अनुसूची अनुमान, आगे बढ़ने के लिए हितधारक समझौता, और मूलभूत अनिश्चितताओं का उन्मूलन जिसके लिए निर्माण में वास्तुशिल्प पुन: डिज़ाइन की आवश्यकता होगी।
2274
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.
व्याख्या (हिन्दी) 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. कोई भी पक्ष दूसरे के क्षेत्र में आदेश नहीं दे सकता - व्यवसाय अनुमान निर्धारित नहीं कर सकता; प्रौद्योगिकी व्यावसायिक प्राथमिकता निर्धारित नहीं कर सकती। यह पारस्परिक बाधा सोना चढ़ाना और अवास्तविक शेड्यूलिंग दोनों को रोकती है।
2275
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.
व्याख्या (हिन्दी) कार्यात्मक रूप से समान होते हुए भी, एक्सपी में टेस्ट-फर्स्ट एक्सपी के पारिस्थितिकी तंत्र के भीतर एम्बेडेड है: यह जोड़ी प्रोग्रामिंग (दोनों डेवलपर्स एक साथ परीक्षण विफल देखते हैं), निरंतर एकीकरण (हर कुछ घंटों में परीक्षण चलाते हैं), और ऑन-साइट ग्राहक (ग्राहक के साथ परिभाषित स्वीकृति परीक्षण) के साथ मिलकर काम करता है। केंट बेक और बाद में रॉबर्ट मार्टिन द्वारा लोकप्रिय टीडीडी किसी विशेष पद्धति की सामाजिक प्रथाओं से स्वतंत्र एक सामान्य अभ्यास है।
2276
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.
व्याख्या (हिन्दी) सामूहिक स्वामित्व ज्ञान साइलो और बस-कारक जोखिमों को समाप्त करता है - कोई भी डेवलपर किसी भी मॉड्यूल में किसी भी बग को ठीक कर सकता है। जोखिम (शैली असंगतता, विरोधाभासी रिफैक्टर) को कम किया जाता है: स्वचालित परीक्षण जो प्रतिगमन को तुरंत पकड़ते हैं, सीआई जो घंटों के भीतर एकीकरण संघर्ष का पता लगाता है, साझा कोडिंग मानक जो शैली स्थिरता बनाए रखते हैं, और लगातार एकीकरण जो शाखाओं को अल्पकालिक रखता है।
2277
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+ घंटे काम करने वाली एक थकी हुई टीम की तुलना में प्रति सप्ताह अधिक मूल्य पैदा करती है - यहां तक ​​कि कोड की पंक्तियों में भी मापा जाता है, गुणवत्ता की तो बात ही छोड़ दें।
2278
EN + हिं Medium
GB What is 'acceptance test-driven development' (ATDD) and how does it extend TDD?
IN 'स्वीकृति परीक्षण-संचालित विकास' (एटीडीडी) क्या है और यह टीडीडी का विस्तार कैसे करता है?
A
ATDD is a version of TDD that only uses automated acceptance tests rather than unit tests एटीडीडी टीडीडी का एक संस्करण है जो यूनिट परीक्षणों के बजाय केवल स्वचालित स्वीकृति परीक्षणों का उपयोग करता है
B
ATDD defines acceptance tests collaboratively with customers/stakeholders before development begins — extending TDD by elevating the test boundary to the user-requirement level, ensuring customer-visible behaviour drives implementation rather than developer-assumed unit behaviour एटीडीडी विकास शुरू होने से पहले ग्राहकों/हितधारकों के साथ सहयोगात्मक रूप से स्वीकृति परीक्षणों को परिभाषित करता है - परीक्षण सीमा को उपयोगकर्ता-आवश्यकता स्तर तक बढ़ाकर टीडीडी का विस्तार करता है, यह सुनिश्चित करता है कि डेवलपर-कल्पित इकाई व्यवहार के बजाय ग्राहक-दृश्यमान व्यवहार कार्यान्वयन को आगे बढ़ाता है।
C
ATDD replaces unit testing entirely, eliminating the need for developer-level tests ATDD डेवलपर-स्तरीय परीक्षणों की आवश्यकता को समाप्त करते हुए, यूनिट परीक्षण को पूरी तरह से बदल देता है
D
ATDD is only applicable to web application development, not backend or embedded systems एटीडीडी केवल वेब एप्लिकेशन डेवलपमेंट पर लागू है, बैकएंड या एम्बेडेड सिस्टम पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) While TDD drives design through developer-written unit tests, ATDD drives development through customer-written acceptance criteria expressed as executable tests. Tools like Cucumber, FitNesse, and SpecFlow enable business-readable tests. ATDD closes the communication gap: customers specify 'given-when-then' scenarios; developers implement until those scenarios pass — ensuring alignment between business intent and technical implementation.
व्याख्या (हिन्दी) जबकि टीडीडी डेवलपर-लिखित इकाई परीक्षणों के माध्यम से डिजाइन को संचालित करता है, एटीडीडी निष्पादन योग्य परीक्षणों के रूप में व्यक्त ग्राहक-लिखित स्वीकृति मानदंडों के माध्यम से विकास को संचालित करता है। ककड़ी, फिटनेस और स्पेकफ्लो जैसे उपकरण व्यवसाय-पठनीय परीक्षण सक्षम करते हैं। एटीडीडी संचार अंतराल को बंद करता है: ग्राहक 'दिया-कब-तब' परिदृश्य निर्दिष्ट करते हैं; डेवलपर्स उन परिदृश्यों के बीतने तक कार्यान्वयन करते हैं - व्यावसायिक इरादे और तकनीकी कार्यान्वयन के बीच संरेखण सुनिश्चित करते हैं।
2279
EN + हिं Easy
GB What is the 'three amigos' practice in agile and what communication failure does it prevent?
IN एजाइल में 'थ्री एमिगोस' अभ्यास क्या है और यह किस संचार विफलता को रोकता है?
A
Three amigos refers to the three mandatory Scrum ceremonies: planning, daily standup, and retrospective तीन अमीगोस तीन अनिवार्य स्क्रम समारोहों को संदर्भित करते हैं: योजना, दैनिक स्टैंडअप और पूर्वव्यापी
B
Three amigos brings together a business analyst/product owner, developer, and tester to collaboratively refine a user story before implementation — preventing the costly failure of developers building something different from what the BA specified and different from what the tester expected to verify कार्यान्वयन से पहले एक उपयोगकर्ता कहानी को सहयोगात्मक रूप से परिष्कृत करने के लिए तीन अमीगो एक व्यवसाय विश्लेषक/उत्पाद स्वामी, डेवलपर और परीक्षक को एक साथ लाते हैं - बीए द्वारा निर्दिष्ट और परीक्षक द्वारा सत्यापित करने की अपेक्षा से अलग कुछ बनाने में डेवलपर्स की महंगी विफलता को रोकते हैं।
C
Three amigos is a retrospective technique where three senior team members vote on process improvements थ्री एमिगोस एक पूर्वव्यापी तकनीक है जहां टीम के तीन वरिष्ठ सदस्य प्रक्रिया में सुधार पर मतदान करते हैं
D
The term 'three amigos' only applies to SAFe and has no meaning in Scrum or Kanban 'थ्री एमिगोज़' शब्द केवल SAFe पर लागू होता है और स्क्रम या कानबन में इसका कोई अर्थ नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The classic agile failure: BA writes a story, developer builds their interpretation, tester writes tests based on their interpretation — three different understandings diverge silently until integration. Three amigos (Specification by Example, Gojko Adzic) has all three roles author concrete examples together before a sprint, creating shared understanding and concrete acceptance criteria that all three parties agree represent the same requirement.
व्याख्या (हिन्दी) क्लासिक चुस्त विफलता: बीए एक कहानी लिखता है, डेवलपर अपनी व्याख्या बनाता है, परीक्षक उनकी व्याख्या के आधार पर परीक्षण लिखते हैं - तीन अलग-अलग समझ एकीकरण तक चुपचाप अलग हो जाती हैं। तीन अमीगोस (उदाहरण द्वारा विशिष्टता, गोज्को एडज़िक) में स्प्रिंट से पहले सभी तीन भूमिकाएं लेखक के ठोस उदाहरण हैं, जो साझा समझ और ठोस स्वीकृति मानदंड बनाते हैं, जिससे सभी तीन पक्ष सहमत होते हैं और एक ही आवश्यकता का प्रतिनिधित्व करते हैं।
2280
EN + हिं Easy
GB What is 'behaviour-driven development' (BDD) and what problem with TDD does it address?
IN 'व्यवहार-संचालित विकास' (बीडीडी) क्या है और यह टीडीडी से जुड़ी किस समस्या का समाधान करता है?
A
BDD is a testing framework that automatically generates test cases from user interface screenshots बीडीडी एक परीक्षण ढांचा है जो उपयोगकर्ता इंटरफ़ेस स्क्रीनशॉट से स्वचालित रूप से परीक्षण मामले उत्पन्न करता है
B
BDD reformulates TDD around system behaviour described in business language (Given-When-Then) — addressing TDD's problem that developer-named unit tests (testAddUser, testSaveRecord) don't communicate intent to business stakeholders or serve as living documentation बीडीडी व्यावसायिक भाषा में वर्णित सिस्टम व्यवहार के आसपास टीडीडी का सुधार करता है (दिया-जब-तब) - टीडीडी की समस्या का समाधान करते हुए कि डेवलपर-नामित इकाई परीक्षण (testAddUser, testSaveRecord) व्यावसायिक हितधारकों के इरादे को संप्रेषित नहीं करते हैं या जीवित दस्तावेज़ के रूप में काम नहीं करते हैं
C
BDD is identical to TDD but uses a different assertion library (Jasmine vs JUnit) बीडीडी टीडीडी के समान है लेकिन एक अलग अभिकथन लाइब्रेरी का उपयोग करता है (जैस्मीन बनाम जुनीट)
D
BDD was developed as a replacement for unit testing in Python projects only बीडीडी को केवल पायथन परियोजनाओं में यूनिट परीक्षण के प्रतिस्थापन के रूप में विकसित किया गया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dan North coined BDD (2003) after observing that developers struggled to know what to test and tests often didn't reflect intent. BDD scenarios (Given [context], When [action], Then [outcome]) are: readable by non-developers, serve as living documentation, directly trace to business requirements, and when automated (Cucumber, Behave) provide executable specifications.
व्याख्या (हिन्दी) डैन नॉर्थ ने यह देखने के बाद बीडीडी (2003) बनाया कि डेवलपर्स को यह जानने के लिए संघर्ष करना पड़ता है कि क्या परीक्षण करना है और परीक्षण अक्सर इरादे को प्रतिबिंबित नहीं करते हैं। बीडीडी परिदृश्य (दी गई [संदर्भ], जब [क्रिया], तब [परिणाम]) हैं: गैर-डेवलपर्स द्वारा पढ़ने योग्य, जीवित दस्तावेज़ के रूप में कार्य करते हैं, सीधे व्यावसायिक आवश्यकताओं का पता लगाते हैं, और जब स्वचालित होते हैं (ककड़ी, व्यवहार) निष्पादन योग्य विनिर्देश प्रदान करते हैं।
2266–2280 of 2726