Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
466
EN + हिं Medium
GB In a Waterfall project, what is the specific purpose of the 'System Requirements Analysis' phase?
IN वॉटरफ़ॉल परियोजना में, 'सिस्टम आवश्यकताएँ विश्लेषण' चरण का विशिष्ट उद्देश्य क्या है?
A
To write the actual source code for the system modules सिस्टम मॉड्यूल के लिए वास्तविक स्रोत कोड लिखना
B
To analyse and document what the system must do from a user/stakeholder perspective — producing an SRS that serves as the contract between customer and developer उपयोगकर्ता/हितधारक परिप्रेक्ष्य से सिस्टम को क्या करना चाहिए इसका विश्लेषण और दस्तावेजीकरण करना - एक एसआरएस तैयार करना जो ग्राहक और डेवलपर के बीच अनुबंध के रूप में कार्य करता है
C
To evaluate competing software vendors and select the best implementation platform प्रतिस्पर्धी सॉफ़्टवेयर विक्रेताओं का मूल्यांकन करना और सर्वोत्तम कार्यान्वयन प्लेटफ़ॉर्म का चयन करना
D
To create the project schedule and allocate budget to individual developers प्रोजेक्ट शेड्यूल बनाना और व्यक्तिगत डेवलपर्स को बजट आवंटित करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) System Requirements Analysis transforms vague stakeholder needs into precise, documented requirements in a Software Requirements Specification (SRS). The SRS serves as the contractual foundation for all subsequent phases — changes require formal change control, and downstream teams (design, test) derive their work from it.
व्याख्या (हिन्दी) सिस्टम आवश्यकताएँ विश्लेषण अस्पष्ट हितधारक आवश्यकताओं को सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (एसआरएस) में सटीक, दस्तावेज़ीकृत आवश्यकताओं में बदल देता है। एसआरएस बाद के सभी चरणों के लिए संविदात्मक आधार के रूप में कार्य करता है - परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है, और डाउनस्ट्रीम टीमें (डिज़ाइन, परीक्षण) इससे अपना काम प्राप्त करती हैं।
467
EN + हिं Easy
GB What is 'phase containment' in a Waterfall project and why does it reduce overall cost?
IN झरना परियोजना में 'चरण रोकथाम' क्या है और यह समग्र लागत को कम क्यों करता है?
A
Phase containment means keeping all project phases within the originally planned budget चरण नियंत्रण का अर्थ है सभी परियोजना चरणों को मूल रूप से नियोजित बजट के भीतर रखना
B
Phase containment means detecting and fixing defects within the phase that introduces them rather than allowing them to propagate to downstream phases where fix cost multiplies चरण रोकथाम का मतलब उस चरण के भीतर दोषों का पता लगाना और उन्हें ठीक करना है जो उन्हें डाउनस्ट्रीम चरणों में फैलने की अनुमति देने के बजाय उन्हें पेश करते हैं जहां फिक्स लागत कई गुना बढ़ जाती है।
C
Phase containment is a schedule management technique preventing phase overlap चरण रोकथाम एक शेड्यूल प्रबंधन तकनीक है जो चरण ओवरलैप को रोकती है
D
Phase containment means each phase must be fully documented before proceeding to the next चरण रोकथाम का अर्थ है कि अगले चरण पर जाने से पहले प्रत्येक चरण को पूरी तरह से प्रलेखित किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm's cost-of-change curve shows defects are cheapest when found in the phase that creates them. A requirements error detected in requirements review costs 1x to fix; detected in design costs 3-6x; in implementation 10x; in testing 40-100x; in maintenance 100-200x. Phase containment through reviews maximises early detection.
व्याख्या (हिन्दी) बोहेम के परिवर्तन की लागत वक्र से पता चलता है कि दोष तब सबसे सस्ते होते हैं जब वे उस चरण में पाए जाते हैं जो उन्हें बनाता है। आवश्यकताओं की समीक्षा में पाई गई आवश्यकताओं की त्रुटि को ठीक करने में 1x लागत आती है; डिज़ाइन लागत में 3-6x का पता चला; कार्यान्वयन में 10x; परीक्षण में 40-100x; रखरखाव में 100-200x. समीक्षाओं के माध्यम से चरणबद्ध नियंत्रण प्रारंभिक पहचान को अधिकतम करता है।
468
EN + हिं Medium
GB Why is the 'big bang integration' testing approach particularly dangerous in Waterfall projects?
IN वॉटरफ़ॉल परियोजनाओं में 'बिग बैंग इंटीग्रेशन' परीक्षण दृष्टिकोण विशेष रूप से खतरनाक क्यों है?
A
Big bang integration requires specialised tools that are expensive to license बिग बैंग एकीकरण के लिए विशेष उपकरणों की आवश्यकता होती है जिनका लाइसेंस लेना महंगा होता है
B
Big bang integration combines all modules simultaneously at the end of development — when multiple simultaneous interface failures occur, isolating and diagnosing individual faults becomes extremely difficult because interactions mask individual defects बिग बैंग एकीकरण विकास के अंत में सभी मॉड्यूल को एक साथ जोड़ता है - जब एक साथ कई इंटरफ़ेस विफलताएं होती हैं, तो व्यक्तिगत दोषों को अलग करना और उनका निदान करना बेहद मुश्किल हो जाता है क्योंकि इंटरैक्शन व्यक्तिगत दोषों को छुपाता है
C
Big bang integration is only dangerous for systems with more than 50 modules बिग बैंग एकीकरण केवल 50 से अधिक मॉड्यूल वाले सिस्टम के लिए खतरनाक है
D
Big bang integration violates Waterfall methodology rules and should never be used with Waterfall बिग बैंग एकीकरण वाटरफॉल पद्धति नियमों का उल्लंघन करता है और इसे वाटरफॉल के साथ कभी भी उपयोग नहीं किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) When you integrate everything at once, any failure has n*(n-1)/2 potential interaction causes. Incremental integration (top-down, bottom-up, sandwich) adds one component at a time — any new failure is almost certainly caused by the most recently added component, dramatically simplifying fault isolation.
व्याख्या (हिन्दी) जब आप सब कुछ एक साथ एकीकृत करते हैं, तो किसी भी विफलता में n*(n-1)/2 संभावित इंटरैक्शन कारण होते हैं। वृद्धिशील एकीकरण (ऊपर से नीचे, नीचे से ऊपर, सैंडविच) एक समय में एक घटक जोड़ता है - कोई भी नई विफलता लगभग निश्चित रूप से सबसे हाल ही में जोड़े गए घटक के कारण होती है, जो गलती अलगाव को नाटकीय रूप से सरल बनाती है।
469
EN + हिं Medium
GB What is the 'modified waterfall' and how does it address the original model's rigid sequential constraint?
IN 'संशोधित झरना' क्या है और यह मूल मॉडल की कठोर अनुक्रमिक बाधा को कैसे संबोधित करता है?
A
Modified Waterfall allows developers to skip phases they consider unnecessary संशोधित झरना डेवलपर्स को उन चरणों को छोड़ने की अनुमति देता है जिन्हें वे अनावश्यक मानते हैं
B
Modified Waterfall allows controlled feedback loops between adjacent phases — if design reveals a requirements gap, requirements can be revisited without restarting the entire project संशोधित झरना आसन्न चरणों के बीच नियंत्रित फीडबैक लूप की अनुमति देता है - यदि डिज़ाइन आवश्यकताओं के अंतर को प्रकट करता है, तो संपूर्ण परियोजना को पुनरारंभ किए बिना आवश्यकताओं पर दोबारा गौर किया जा सकता है
C
Modified Waterfall merges design and implementation into a single concurrent phase संशोधित झरना डिजाइन और कार्यान्वयन को एक समवर्ती चरण में विलय कर देता है
D
Modified Waterfall replaced Royce's original model and is what all Waterfall textbooks describe संशोधित वॉटरफ़ॉल ने रॉयस के मूल मॉडल को प्रतिस्थापित कर दिया और सभी वॉटरफ़ॉल पाठ्यपुस्तकों में इसका वर्णन किया गया है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Royce's original 1970 paper already recommended feedback loops between adjacent phases. The 'modified Waterfall' formalises this: phases are still largely sequential, but controlled iteration back to the previous phase is permitted when discoveries require it — preventing the catastrophic cost of full restarts while maintaining the structured progression.
व्याख्या (हिन्दी) रॉयस के मूल 1970 पेपर ने पहले से ही आसन्न चरणों के बीच फीडबैक लूप की सिफारिश की थी। 'संशोधित झरना' इसे औपचारिक रूप देता है: चरण अभी भी काफी हद तक अनुक्रमिक हैं, लेकिन पिछले चरण में नियंत्रित पुनरावृत्ति की अनुमति तब दी जाती है जब खोजों को इसकी आवश्यकता होती है - संरचित प्रगति को बनाए रखते हुए पूर्ण पुनरारंभ की भयावह लागत को रोकना।
470
EN + हिं Medium
GB What specific risk does the 'requirements freeze' concept in Waterfall introduce for long-duration projects?
IN वॉटरफॉल में 'आवश्यकताओं को स्थिर' करने की अवधारणा लंबी अवधि की परियोजनाओं के लिए कौन सा विशिष्ट जोखिम पेश करती है?
A
Requirements freeze prevents developers from adding performance improvements during implementation आवश्यकताओं पर रोक डेवलपर्स को कार्यान्वयन के दौरान प्रदर्शन में सुधार जोड़ने से रोकती है
B
In long projects (18+ months), freezing requirements at initiation means the business environment, regulations, and technology may have changed substantially by delivery, producing a system that is obsolete on release day लंबी परियोजनाओं (18+ महीने) में, शुरुआत में आवश्यकताओं को फ्रीज करने का मतलब है कि वितरण के कारण कारोबारी माहौल, नियम और तकनीक काफी हद तक बदल गई होगी, जिससे एक ऐसी प्रणाली तैयार हो जाएगी जो रिलीज के दिन अप्रचलित हो जाएगी।
C
Requirements freeze increases developer productivity by eliminating scope change discussions आवश्यकताएँ फ़्रीज़ स्कोप परिवर्तन चर्चाओं को समाप्त करके डेवलपर उत्पादकता बढ़ाती हैं
D
Requirements freeze only applies to functional requirements; non-functional requirements can be modified freely आवश्यकताओं पर रोक केवल कार्यात्मक आवश्यकताओं पर लागू होती है; गैर-कार्यात्मक आवश्यकताओं को स्वतंत्र रूप से संशोधित किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The longer a Waterfall project, the higher the probability that frozen requirements no longer represent current business needs at delivery. A 3-year government system may specify requirements based on regulations that have since been updated, business processes that have changed, or technology assumptions that are now obsolete — making the delivered system invalid before it's even used.
व्याख्या (हिन्दी) वॉटरफ़ॉल परियोजना जितनी लंबी होगी, इसकी संभावना उतनी ही अधिक होगी कि जमे हुए आवश्यकताएं अब डिलीवरी के समय वर्तमान व्यावसायिक आवश्यकताओं का प्रतिनिधित्व नहीं करती हैं। 3-वर्षीय सरकारी प्रणाली उन नियमों के आधार पर आवश्यकताओं को निर्दिष्ट कर सकती है जिन्हें अद्यतन किया गया है, व्यावसायिक प्रक्रियाएं जो बदल गई हैं, या प्रौद्योगिकी धारणाएं जो अब अप्रचलित हैं - वितरित प्रणाली को उपयोग करने से पहले ही अमान्य बना देती है।
471
EN + हिं Medium
GB What is the 'software development notebook' in a Waterfall project and why is it considered a quality tool?
IN वॉटरफ़ॉल प्रोजेक्ट में 'सॉफ़्टवेयर डेवलपमेंट नोटबुक' क्या है और इसे एक गुणवत्तापूर्ण उपकरण क्यों माना जाता है?
A
A physical notebook where developers write code before typing it into a computer एक भौतिक नोटबुक जहां डेवलपर्स कंप्यूटर में टाइप करने से पहले कोड लिखते हैं
B
A structured record of all design decisions, rationale, alternatives considered, and open issues maintained throughout development — providing traceability and institutional memory that reduces rework when key developers leave सभी डिज़ाइन निर्णयों, तर्क, विचार किए गए विकल्पों और विकास के दौरान बनाए गए खुले मुद्दों का एक संरचित रिकॉर्ड - ट्रेसबिलिटी और संस्थागत मेमोरी प्रदान करता है जो प्रमुख डेवलपर्स के चले जाने पर पुनर्कार्य को कम करता है
C
A project management document listing all team members and their assigned modules सभी टीम सदस्यों और उनके निर्दिष्ट मॉड्यूल को सूचीबद्ध करने वाला एक परियोजना प्रबंधन दस्तावेज़
D
A notebook mandated by ISO 9001 containing code review findings only आईएसओ 9001 द्वारा अनिवार्य एक नोटबुक जिसमें केवल कोड समीक्षा निष्कर्ष शामिल हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The software development notebook (from cleanroom and formal methods practice) documents the 'why' behind decisions — not just what was built, but why alternatives were rejected. This is critical because the tacit knowledge in developers' heads is lost when they leave, forcing expensive re-investigation of previously settled questions.
व्याख्या (हिन्दी) सॉफ़्टवेयर डेवलपमेंट नोटबुक (क्लीनरूम और औपचारिक तरीकों के अभ्यास से) निर्णयों के पीछे 'क्यों' का दस्तावेजीकरण करती है - न कि केवल क्या बनाया गया था, बल्कि विकल्पों को अस्वीकार क्यों किया गया था। यह महत्वपूर्ण है क्योंकि डेवलपर्स के जाने पर उनके दिमाग का गुप्त ज्ञान खो जाता है, जिससे पहले से तय किए गए प्रश्नों की दोबारा जांच महंगी पड़ जाती है।
472
EN + हिं Easy
GB What does the 'operational concept' document serve in a Waterfall project and who should produce it?
IN वाटरफॉल प्रोजेक्ट में 'ऑपरेशनल कॉन्सेप्ट' दस्तावेज़ क्या काम करता है और इसे किसे तैयार करना चाहिए?
A
It describes the physical hardware infrastructure required to run the software यह सॉफ़्टवेयर चलाने के लिए आवश्यक भौतिक हार्डवेयर अवसंरचना का वर्णन करता है
B
The operational concept describes how the end system will be used in its operational environment — produced by the customer/user representative to ensure the development team understands usage context before writing requirements परिचालन अवधारणा बताती है कि अंतिम प्रणाली का उपयोग उसके परिचालन वातावरण में कैसे किया जाएगा - ग्राहक/उपयोगकर्ता प्रतिनिधि द्वारा निर्मित यह सुनिश्चित करने के लिए कि विकास टीम आवश्यकताओं को लिखने से पहले उपयोग के संदर्भ को समझती है।
C
It is a technical document produced by the lead architect describing deployment topology यह प्रमुख वास्तुकार द्वारा परिनियोजन टोपोलॉजी का वर्णन करने वाला एक तकनीकी दस्तावेज़ है
D
The operational concept is produced by the QA team to define the scope of acceptance testing स्वीकृति परीक्षण के दायरे को परिभाषित करने के लिए क्यूए टीम द्वारा परिचालन अवधारणा तैयार की जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Operational Concept Document (OCD) or ConOps (IEEE 1362) establishes the user's vision of system operation before technical requirements are written. Produced by users/operators, it describes who uses the system, how, in what environment, and what mission it supports — grounding subsequent technical requirements in operational reality.
व्याख्या (हिन्दी) ऑपरेशनल कॉन्सेप्ट डॉक्यूमेंट (ओसीडी) या कॉनऑप्स (आईईईई 1362) तकनीकी आवश्यकताओं को लिखे जाने से पहले सिस्टम संचालन के बारे में उपयोगकर्ता के दृष्टिकोण को स्थापित करता है। उपयोगकर्ताओं/ऑपरेटरों द्वारा निर्मित, यह वर्णन करता है कि सिस्टम का उपयोग कौन करता है, कैसे, किस वातावरण में और यह किस मिशन का समर्थन करता है - परिचालन वास्तविकता में बाद की तकनीकी आवश्यकताओं को पूरा करता है।
473
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 को अधिक लचीले मानकों से बदलने के लिए प्रेरित किया और अंततः पुनरावृत्त/चतुर तरीकों को अपनाया। यह केस अध्ययन जटिल प्रणालियों के लिए कठोर झरने के विरुद्ध विहित तर्क बन गया।
474
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 के प्रोटोटाइप ने अपना कार्य पूरा कर लिया है: इसने एक गंभीर तकनीकी जोखिम की पहचान पहले ही कर ली है, जबकि इसका समाधान करना सबसे सस्ता है। एक ज्ञात घातक तकनीकी बाधा वाले सिस्टम में निवेश जारी रखना ठीक वैसी ही बर्बादी होगी जिसे रोकने के लिए स्पाइरल मॉडल डिज़ाइन किया गया है। जोखिम समाधान विकल्प (बेहतर सेंसर, एल्गोरिदम रीडिज़ाइन, आवश्यकताओं में छूट) सभी वैध सर्पिल प्रतिक्रियाएँ हैं।
475
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.
व्याख्या (हिन्दी) एलसीए (यूपी के विस्तार मील के पत्थर के बराबर) प्रमुख निर्माण निवेश से पहले महत्वपूर्ण सर्पिल द्वार है। इसके लिए आवश्यक है: प्रमुख जोखिमों को हल करने वाला एक वास्तुशिल्प प्रोटोटाइप, शेष कार्य के लिए एक विश्वसनीय लागत/अनुसूची अनुमान, आगे बढ़ने के लिए हितधारक समझौता, और मूलभूत अनिश्चितताओं का उन्मूलन जिसके लिए निर्माण में वास्तुशिल्प पुन: डिज़ाइन की आवश्यकता होगी।
476
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.
व्याख्या (हिन्दी) एक्सपी का नियोजन गेम चिंताओं को अलग करता है: व्यावसायिक हितधारकों के पास इस बात पर अधिकार होता है कि क्या बनाया जाता है (दायरा, प्राथमिकता, रिलीज की तारीख) और प्रौद्योगिकी टीम के पास कितना समय लगता है और इसे कैसे लागू किया जाता है, इस पर अधिकार है। कोई भी पक्ष दूसरे के क्षेत्र में आदेश नहीं दे सकता - व्यवसाय अनुमान निर्धारित नहीं कर सकता; प्रौद्योगिकी व्यावसायिक प्राथमिकता निर्धारित नहीं कर सकती। यह पारस्परिक बाधा सोना चढ़ाना और अवास्तविक शेड्यूलिंग दोनों को रोकती है।
477
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.
व्याख्या (हिन्दी) कार्यात्मक रूप से समान होते हुए भी, एक्सपी में टेस्ट-फर्स्ट एक्सपी के पारिस्थितिकी तंत्र के भीतर एम्बेडेड है: यह जोड़ी प्रोग्रामिंग (दोनों डेवलपर्स एक साथ परीक्षण विफल देखते हैं), निरंतर एकीकरण (हर कुछ घंटों में परीक्षण चलाते हैं), और ऑन-साइट ग्राहक (ग्राहक के साथ परिभाषित स्वीकृति परीक्षण) के साथ मिलकर काम करता है। केंट बेक और बाद में रॉबर्ट मार्टिन द्वारा लोकप्रिय टीडीडी किसी विशेष पद्धति की सामाजिक प्रथाओं से स्वतंत्र एक सामान्य अभ्यास है।
478
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.
व्याख्या (हिन्दी) सामूहिक स्वामित्व ज्ञान साइलो और बस-कारक जोखिमों को समाप्त करता है - कोई भी डेवलपर किसी भी मॉड्यूल में किसी भी बग को ठीक कर सकता है। जोखिम (शैली असंगतता, विरोधाभासी रिफैक्टर) को कम किया जाता है: स्वचालित परीक्षण जो प्रतिगमन को तुरंत पकड़ते हैं, सीआई जो घंटों के भीतर एकीकरण संघर्ष का पता लगाता है, साझा कोडिंग मानक जो शैली स्थिरता बनाए रखते हैं, और लगातार एकीकरण जो शाखाओं को अल्पकालिक रखता है।
479
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+ घंटे काम करने वाली एक थकी हुई टीम की तुलना में प्रति सप्ताह अधिक मूल्य पैदा करती है - यहां तक ​​कि कोड की पंक्तियों में भी मापा जाता है, गुणवत्ता की तो बात ही छोड़ दें।
480
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.
व्याख्या (हिन्दी) जबकि टीडीडी डेवलपर-लिखित इकाई परीक्षणों के माध्यम से डिजाइन को संचालित करता है, एटीडीडी निष्पादन योग्य परीक्षणों के रूप में व्यक्त ग्राहक-लिखित स्वीकृति मानदंडों के माध्यम से विकास को संचालित करता है। ककड़ी, फिटनेस और स्पेकफ्लो जैसे उपकरण व्यवसाय-पठनीय परीक्षण सक्षम करते हैं। एटीडीडी संचार अंतराल को बंद करता है: ग्राहक 'दिया-कब-तब' परिदृश्य निर्दिष्ट करते हैं; डेवलपर्स उन परिदृश्यों के बीतने तक कार्यान्वयन करते हैं - व्यावसायिक इरादे और तकनीकी कार्यान्वयन के बीच संरेखण सुनिश्चित करते हैं।
466–480 of 647