406

EN + हिं Medium

GB In XP, what is the purpose of pair programming and what does research indicate about its productivity impact?

IN एक्सपी में, जोड़ी प्रोग्रामिंग का उद्देश्य क्या है और अनुसंधान इसके उत्पादकता प्रभाव के बारे में क्या संकेत देता है?

A

Doubles productivity by having two developers work independently in parallel दो डेवलपर्स के समानांतर में स्वतंत्र रूप से काम करने से उत्पादकता दोगुनी हो जाती है

B

Two developers share one workstation — driver writes, navigator reviews real-time; research shows 15% overhead but significantly fewer defects, reducing total project cost दो डेवलपर्स एक वर्कस्टेशन साझा करते हैं - ड्राइवर लिखता है, नेविगेटर वास्तविक समय में समीक्षा करता है; शोध से पता चलता है कि 15% ओवरहेड है लेकिन काफी कम दोष हैं, जिससे कुल परियोजना लागत कम हो गई है

C

Requires two developers to independently implement same feature and choose the better one एक ही सुविधा को स्वतंत्र रूप से लागू करने और बेहतर को चुनने के लिए दो डेवलपर्स की आवश्यकता होती है

D

Only used for debugging; normal development is always solo in XP केवल डिबगिंग के लिए उपयोग किया जाता है; XP में सामान्य विकास हमेशा एकल होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Pair programming (Williams et al.) shows approximately 15% time overhead but 15–50% fewer defects. Since defect repair is the largest cost driver, the net economics are typically positive — with additional benefits of knowledge sharing and reduced bus factor.

व्याख्या (हिन्दी) जोड़ी प्रोग्रामिंग (विलियम्स एट अल.) लगभग 15% समय ओवरहेड लेकिन 15-50% कम दोष दिखाता है। चूंकि दोष की मरम्मत सबसे बड़ी लागत चालक है, इसलिए शुद्ध अर्थशास्त्र आम तौर पर सकारात्मक है - ज्ञान साझा करने के अतिरिक्त लाभ और कम बस कारक के साथ।

407

EN + हिं Medium

GB What is the 'Last Responsible Moment' principle in Lean Software Development and why is it valuable?

IN लीन सॉफ्टवेयर डेवलपमेंट में 'लास्ट रिस्पॉन्सिबल मोमेंट' सिद्धांत क्या है और यह मूल्यवान क्यों है?

A

The latest moment to escalate a project risk to senior management वरिष्ठ प्रबंधन के लिए परियोजना जोखिम बढ़ाने का नवीनतम क्षण

B

Delaying irreversible decisions until maximum information is available, keeping options open — reducing the cost of wrong decisions made prematurely on insufficient information अधिकतम जानकारी उपलब्ध होने तक अपरिवर्तनीय निर्णयों में देरी करना, विकल्प खुले रखना - अपर्याप्त जानकारी पर समय से पहले लिए गए गलत निर्णयों की लागत को कम करना

C

The deadline after which project must be cancelled regardless of completion वह समय सीमा जिसके बाद परियोजना पूरी होने की परवाह किए बिना रद्द कर दी जानी चाहिए

D

The final sprint where all remaining backlog items must be completed अंतिम स्प्रिंट जहां सभी शेष बैकलॉग आइटम को पूरा किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Last Responsible Moment (Poppendieck) recognises that premature decisions made under uncertainty incur high error costs. By deliberately keeping options open and deciding only when the decision must be made, teams make better decisions with more data.

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

408

EN + हिं Easy

GB What is 'requirements creep' and what process practice most effectively controls it?

IN 'रिक्वायरमेंट्स क्रीप' क्या है और कौन सी प्रक्रिया अभ्यास इसे सबसे प्रभावी ढंग से नियंत्रित करती है?

A

Developers adding features without customer approval; controlled by daily standups डेवलपर्स ग्राहक की मंजूरी के बिना सुविधाएँ जोड़ रहे हैं; दैनिक स्टैंडअप द्वारा नियंत्रित

B

Uncontrolled addition of requirements after baseline without corresponding scope/budget/schedule adjustment; controlled through formal change control with impact analysis संबंधित दायरे/बजट/अनुसूची समायोजन के बिना बेसलाइन के बाद आवश्यकताओं का अनियंत्रित जोड़; प्रभाव विश्लेषण के साथ औपचारिक परिवर्तन नियंत्रण के माध्यम से नियंत्रित

C

Process of gradually making requirements more specific during elaboration विस्तार के दौरान आवश्यकताओं को धीरे-धीरे और अधिक विशिष्ट बनाने की प्रक्रिया

D

Inevitable and uncontrollable in any software project किसी भी सॉफ्टवेयर प्रोजेक्ट में अपरिहार्य और अनियंत्रित

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Requirements creep accumulates when stakeholders request changes informally after scope is agreed. Formal change control — requiring impact analysis on schedule, cost, and quality for every proposed change before approval — provides visibility and forces trade-off decisions.

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

409

EN + हिं Medium

GB What is the 'viewpoint-oriented' approach in requirements engineering and why is it valuable?

IN आवश्यकता इंजीनियरिंग में 'दृष्टिकोण-उन्मुख' दृष्टिकोण क्या है और यह मूल्यवान क्यों है?

A

All requirements must be written from the end user's perspective only सभी आवश्यकताओं को केवल अंतिम उपयोगकर्ता के दृष्टिकोण से लिखा जाना चाहिए

B

It structures requirements elicitation around multiple distinct stakeholder perspectives, helping discover conflicts and requirements invisible from any single viewpoint यह कई अलग-अलग हितधारक दृष्टिकोणों के इर्द-गिर्द आवश्यकताओं की संरचना करता है, जिससे किसी एक दृष्टिकोण से अदृश्य संघर्षों और आवश्यकताओं को खोजने में मदद मिलती है

C

Only applicable to multi-tenant cloud systems केवल बहु-किरायेदार क्लाउड सिस्टम पर लागू

D

Requires each team member to write separate requirements documents independently प्रत्येक टीम सदस्य को स्वतंत्र रूप से अलग-अलग आवश्यकता दस्तावेज़ लिखने की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Different stakeholders (users, administrators, regulators) have different and sometimes conflicting views. Viewpoint-oriented methods systematically capture each perspective, then explicitly reconcile conflicts — better surfaced during elicitation than during testing.

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

410

EN + हिं Easy

GB What is 'prototyping' as a requirements elicitation technique and what is its primary risk?

IN आवश्यकताओं को पूरा करने की तकनीक के रूप में 'प्रोटोटाइपिंग' क्या है और इसका प्राथमिक जोखिम क्या है?

A

Creating a detailed architectural design before writing code; risk is over-specification कोड लिखने से पहले एक विस्तृत वास्तुशिल्प डिज़ाइन बनाना; जोखिम अति-विशिष्टता है

B

Building a partial/simulated version to elicit requirements through user interaction; primary risk is stakeholders mistaking the prototype for the final system and resisting necessary rework उपयोगकर्ता इंटरैक्शन के माध्यम से आवश्यकताओं को पूरा करने के लिए आंशिक/सिम्युलेटेड संस्करण का निर्माण; प्राथमिक जोखिम यह है कि हितधारक प्रोटोटाइप को अंतिम प्रणाली समझ लेते हैं और आवश्यक पुनर्कार्य का विरोध करते हैं

C

Always the cheapest requirements technique and should be used in all projects हमेशा सबसे सस्ती आवश्यकताओं वाली तकनीक और सभी परियोजनाओं में इसका उपयोग किया जाना चाहिए

D

Replaces requirements documentation entirely in modern development आधुनिक विकास में आवश्यकताओं के दस्तावेज़ीकरण को पूरी तरह से बदल देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Prototyping is powerful for eliciting tacit requirements users can't articulate verbally. The critical risk (Sommerville's 'prototype as final system') is that stakeholders see working UI and assume the system is nearly done, pressuring the team to release the technically inadequate prototype.

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

411

EN + हिं Medium

GB What distinguishes 'elicitation' from 'analysis' in requirements engineering?

IN आवश्यकता इंजीनियरिंग में 'एलिसिटेशन' को 'विश्लेषण' से क्या अलग करता है?

A

Elicitation is done by customers; analysis by developers उद्दीपन ग्राहकों द्वारा किया जाता है; डेवलपर्स द्वारा विश्लेषण

B

Elicitation discovers and gathers requirements from stakeholders; analysis studies them for consistency, completeness, and resolves conflicts among elicited requirements एलीसिटेशन हितधारकों से आवश्यकताओं की खोज करता है और उन्हें एकत्र करता है; विश्लेषण निरंतरता, पूर्णता के लिए उनका अध्ययन करता है और उत्पन्न आवश्यकताओं के बीच टकराव का समाधान करता है

C

Elicitation only uses interviews; analysis only uses formal specification languages एलीसिटेशन केवल साक्षात्कार का उपयोग करता है; विश्लेषण केवल औपचारिक विनिर्देश भाषाओं का उपयोग करता है

D

Analysis precedes elicitation in the requirements process आवश्यकताओं की प्रक्रिया में विश्लेषण से पहले विश्लेषण किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Elicitation focuses on discovering what stakeholders need through interviews, workshops, observation. Analysis takes raw discovered requirements and studies them for internal consistency (no contradictions), completeness, and feasibility. Requirements from different stakeholders often conflict and analysis is where those conflicts are resolved.

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

412

EN + हिं Easy

GB In IEEE 830, what does the 'verifiability' property of a good requirement mean?

IN आईईईई 830 में, एक अच्छी आवश्यकता की 'सत्यापनीयता' संपत्ति का क्या मतलब है?

A

Requirement has been verified by at least two senior stakeholders आवश्यकता को कम से कम दो वरिष्ठ हितधारकों द्वारा सत्यापित किया गया है

B

A cost-effective test, inspection, demonstration, or analysis method must exist that can confirm whether the requirement has been met एक लागत प्रभावी परीक्षण, निरीक्षण, प्रदर्शन या विश्लेषण विधि मौजूद होनी चाहिए जो पुष्टि कर सके कि आवश्यकता पूरी हो गई है या नहीं

C

Requirement source has been identified and documented आवश्यकता स्रोत की पहचान और दस्तावेजीकरण किया गया है

D

Requirement can be traced to a business objective in the project charter आवश्यकता का पता प्रोजेक्ट चार्टर में व्यावसायिक उद्देश्य से लगाया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) IEEE 830 requires verifiability: a requirement must be stated so that a finite cost-effective procedure exists to check that the system satisfies it. 'User-friendly' is not verifiable; 'new users complete registration in under 3 minutes on first attempt' is verifiable through usability testing.

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

413

EN + हिं Easy

GB What is the 'gold plating' problem in requirements engineering and from which side does it typically originate?

IN आवश्यकताओं की इंजीनियरिंग में 'गोल्ड प्लेटिंग' समस्या क्या है और यह आमतौर पर किस तरफ से उत्पन्न होती है?

A

Customers demanding premium features outside budget ग्राहक बजट से बाहर प्रीमियम सुविधाओं की मांग कर रहे हैं

B

Developers adding unrequested features believing they improve the product — wasting effort on features customers may never use डेवलपर्स बिना अनुरोध वाली सुविधाएँ जोड़ रहे हैं, यह विश्वास करते हुए कि वे उत्पाद को बेहतर बनाते हैं - उन सुविधाओं पर प्रयास बर्बाद कर रहे हैं जिनका ग्राहक कभी उपयोग नहीं कर सकते हैं

C

Excessive requirements documentation adding cost without clarity अत्यधिक आवश्यकताओं वाला दस्तावेज़ स्पष्टता के बिना लागत जोड़ता है

D

A financial software engineering term for transaction security layers लेनदेन सुरक्षा परतों के लिए एक वित्तीय सॉफ्टवेयर इंजीनियरिंग शब्द

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Gold plating occurs when developers add features beyond what was requested, typically out of enthusiasm. While well-intentioned, it wastes resources, introduces unplanned testing requirements, and can complicate the interface.

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

414

EN + हिं Medium

GB What is 'requirements traceability' and why is it particularly important in safety-critical systems?

IN 'आवश्यकताओं का पता लगाने की क्षमता' क्या है और यह सुरक्षा-महत्वपूर्ण प्रणालियों में विशेष रूप से महत्वपूर्ण क्यों है?

A

Ability to track who requested each requirement and their contact information यह ट्रैक करने की क्षमता कि प्रत्येक आवश्यकता और उनकी संपर्क जानकारी का अनुरोध किसने किया

B

Documented relationship linking requirements to design, code, and tests — enabling impact analysis and verification that all requirements are implemented; critical in safety systems for certification compliance डिज़ाइन, कोड और परीक्षणों से आवश्यकताओं को जोड़ने वाला दस्तावेज़ीकृत संबंध - प्रभाव विश्लेषण और सत्यापन को सक्षम करना कि सभी आवश्यकताएं लागू की गई हैं; प्रमाणीकरण अनुपालन के लिए सुरक्षा प्रणालियों में महत्वपूर्ण

C

Version control strategy for managing multiple branches of requirements documents आवश्यकता दस्तावेज़ों की अनेक शाखाओं के प्रबंधन के लिए संस्करण नियंत्रण रणनीति

D

Only applies to hardware requirements केवल हार्डवेयर आवश्यकताओं पर लागू होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Traceability matrices link requirements to design decisions, implementation, and test cases bidirectionally. In safety-critical systems, regulators require proof every safety requirement has been implemented and tested — traceability is the evidence.

व्याख्या (हिन्दी) ट्रैसेबिलिटी मैट्रिक्स आवश्यकताओं को डिजाइन निर्णयों, कार्यान्वयन और परीक्षण मामलों से द्विदिश रूप से जोड़ता है। सुरक्षा-महत्वपूर्ण प्रणालियों में, नियामकों को प्रमाण की आवश्यकता होती है कि प्रत्येक सुरक्षा आवश्यकता को लागू किया गया है और परीक्षण किया गया है - पता लगाने की क्षमता इसका प्रमाण है।

415

EN + हिं Easy

GB What is the 'requirements baseline' and what governance rules typically apply to it?

IN 'आवश्यकताओं की आधार रेखा' क्या है और इस पर आमतौर पर कौन से शासन नियम लागू होते हैं?

A

A preliminary draft of requirements used only for initial cost estimation आवश्यकताओं का प्रारंभिक मसौदा केवल प्रारंभिक लागत अनुमान के लिए उपयोग किया जाता है

B

A formally approved version of the requirements document serving as the agreed reference; changes require formal change control — impact assessment, CCB approval, and version management सहमत संदर्भ के रूप में कार्य करने वाले आवश्यकता दस्तावेज़ का औपचारिक रूप से अनुमोदित संस्करण; परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है - प्रभाव मूल्यांकन, सीसीबी अनुमोदन और संस्करण प्रबंधन

C

Automatically updated whenever a developer commits code जब भी कोई डेवलपर कोड करता है तो स्वचालित रूप से अपडेट हो जाता है

D

Produced by the testing team after system testing is complete सिस्टम परीक्षण पूरा होने के बाद परीक्षण टीम द्वारा उत्पादित किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A requirements baseline establishes a controlled reference. Once baselined, requirements are under configuration management — changes cannot be made informally. A Change Control Board evaluates impact on cost, schedule, and quality, approving or rejecting proposed changes.

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

416

EN + हिं Easy

GB What does the Dependency Inversion Principle (DIP) state and what design problem does it solve?

IN निर्भरता व्युत्क्रम सिद्धांत (डीआईपी) क्या बताता है और यह किस डिज़ाइन समस्या का समाधान करता है?

A

All class dependencies should be injected through constructors rather than setters सभी वर्ग निर्भरताओं को सेटर्स के बजाय कंस्ट्रक्टर्स के माध्यम से इंजेक्ट किया जाना चाहिए

B

High-level modules should not depend on low-level modules; both should depend on abstractions — solving the problem where changing a low-level component forces changes throughout the system उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए; दोनों को अमूर्तता पर निर्भर होना चाहिए - उस समस्या को हल करना जहां निम्न-स्तरीय घटक को बदलने से पूरे सिस्टम में परिवर्तन होता है

C

All software dependencies must be managed by a centralised dependency registry सभी सॉफ़्टवेयर निर्भरताएँ एक केंद्रीकृत निर्भरता रजिस्ट्री द्वारा प्रबंधित की जानी चाहिए

D

Inheritance is prohibited; composition required instead विरासत निषिद्ध है; इसके बजाय रचना की आवश्यकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) DIP inverts the traditional dependency flow. Business logic depending on a database interface (abstraction) rather than the database directly means changing the database doesn't break business logic. This decouples layers and makes components independently replaceable.

व्याख्या (हिन्दी) डीआईपी पारंपरिक निर्भरता प्रवाह को उलट देता है। व्यावसायिक तर्क डेटाबेस के बजाय डेटाबेस इंटरफ़ेस (अमूर्त) पर निर्भर करता है, इसका सीधा मतलब है कि डेटाबेस को बदलने से व्यावसायिक तर्क नहीं टूटता है। यह परतों को अलग करता है और घटकों को स्वतंत्र रूप से बदलने योग्य बनाता है।

417

EN + हिं Easy

GB What is the 'Law of Demeter' and what coupling problem does it address?

IN 'डेमेटर का नियम' क्या है और यह किस युग्मन समस्या का समाधान करता है?

A

Each class must have at most ten methods प्रत्येक कक्षा में अधिकतम दस विधियाँ होनी चाहिए

B

A method should only call methods of its own class, its parameters, objects it creates, or direct components — preventing 'train wreck' chaining that creates hidden long-range coupling एक विधि को केवल अपने स्वयं के वर्ग, उसके मापदंडों, उसके द्वारा बनाई गई वस्तुओं, या प्रत्यक्ष घटकों के तरीकों को कॉल करना चाहिए - 'ट्रेन मलबे' श्रृंखला को रोकना जो छिपी हुई लंबी दूरी की युग्मन बनाता है

C

Global variables are prohibited in object-oriented programs ऑब्जेक्ट-ओरिएंटेड प्रोग्राम में वैश्विक चर निषिद्ध हैं

D

All class attributes must be private with public getters and setters सभी वर्ग विशेषताएँ सार्वजनिक गेटर्स और सेटर्स के साथ निजी होनी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Train wreck code like customer.getWallet().getCurrency().getSymbol() makes the caller dependent on the entire object graph's internal structure. The Law of Demeter limits coupling by requiring objects to communicate only with immediate neighbours, enforcing encapsulation.

व्याख्या (हिन्दी) ट्रेन व्रेक कोड जैसे customer.getWallet().getCurrency().getSymbol() कॉलर को संपूर्ण ऑब्जेक्ट ग्राफ़ की आंतरिक संरचना पर निर्भर बनाता है। डेमेटर का नियम वस्तुओं को केवल निकटतम पड़ोसियों के साथ संचार करने की आवश्यकता के द्वारा युग्मन को सीमित करता है, जिससे एनकैप्सुलेशन लागू होता है।

418

EN + हिं Medium

GB What distinguishes a 'layered architecture' from a 'hexagonal (ports and adapters) architecture'?

IN 'स्तरित आर्किटेक्चर' को 'हेक्सागोनल (पोर्ट और एडाप्टर) आर्किटेक्चर' से क्या अलग करता है?

A

Layered is for web applications; hexagonal is for desktop applications लेयर्ड वेब अनुप्रयोगों के लिए है; हेक्सागोनल डेस्कटॉप अनुप्रयोगों के लिए है

B

Layered enforces directional dependency flow (UI→Business→Data); hexagonal puts business logic at the centre with all external concerns as interchangeable adapters connecting through ports स्तरित दिशात्मक निर्भरता प्रवाह को लागू करता है (यूआई→व्यवसाय→डेटा); हेक्सागोनल बंदरगाहों के माध्यम से जुड़ने वाले विनिमेय एडेप्टर के रूप में सभी बाहरी चिंताओं के साथ व्यावसायिक तर्क को केंद्र में रखता है

C

Hexagonal has exactly six layers; layered can have any number हेक्सागोनल में ठीक छह परतें होती हैं; स्तरित में कोई भी संख्या हो सकती है

D

Both are identical; hexagonal is a newer name for layered दोनों एक जैसे हैं; हेक्सागोनल लेयर्ड का नया नाम है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In layered architecture, business logic depends on the database — making database changes ripple upward. Alistair Cockburn's Hexagonal architecture isolates the domain model at the core; all I/O are adapters the domain doesn't depend on, enabling full testability without infrastructure.

व्याख्या (हिन्दी) स्तरित वास्तुकला में, व्यावसायिक तर्क डेटाबेस पर निर्भर करता है - जिससे डेटाबेस परिवर्तन ऊपर की ओर बढ़ते हैं। एलिस्टेयर कॉकबर्न की हेक्सागोनल वास्तुकला डोमेन मॉडल को मूल रूप से अलग करती है; सभी I/O एडेप्टर हैं जिन पर डोमेन निर्भर नहीं है, जो बुनियादी ढांचे के बिना पूर्ण परीक्षण योग्यता को सक्षम करते हैं।

419

EN + हिं Medium

GB What does 'Design by Contract' (DbC) entail and how does it differ from defensive programming?

IN 'डिज़ाइन बाय कॉन्ट्रैक्ट' (DbC) में क्या शामिल है और यह रक्षात्मक प्रोग्रामिंग से कैसे भिन्न है?

A

DbC is a legal framework for software licensing डीबीसी सॉफ्टवेयर लाइसेंसिंग के लिए एक कानूनी ढांचा है

B

DbC specifies formal preconditions, postconditions, and invariants — callers meet preconditions; method guarantees postconditions. Defensive programming checks all inputs regardless of responsibility, adding redundancy डीबीसी औपचारिक पूर्वशर्तें, पश्चशर्तें और अपरिवर्तनीयताएं निर्दिष्ट करता है - कॉल करने वाले पूर्वशर्तों को पूरा करते हैं; विधि पोस्टकंडिशन की गारंटी देती है। रक्षात्मक प्रोग्रामिंग जिम्मेदारी की परवाह किए बिना, अतिरेक जोड़ते हुए सभी इनपुट की जाँच करती है

C

DbC contracts are written by lawyers; defensive programming by developers डीबीसी अनुबंध वकीलों द्वारा लिखे जाते हैं; डेवलपर्स द्वारा रक्षात्मक प्रोग्रामिंग

D

Both are equivalent approaches with different terminology दोनों अलग-अलग शब्दावली के साथ समान दृष्टिकोण हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Bertrand Meyer's DbC creates a formal agreement: preconditions (caller's responsibility), postconditions (method's guarantee), invariants (always-true properties). DbC places blame clearly. Defensive programming checks everything everywhere — safer across trust boundaries but adds overhead and ambiguity.

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

420

EN + हिं Easy

GB What is the 'God Object' anti-pattern and what refactoring approach addresses it?

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

A

A highly reusable class handling all common utilities; should be kept and extended सभी सामान्य उपयोगिताओं को संभालने वाला एक अत्यधिक पुन: प्रयोज्य वर्ग; रखा जाना चाहिए और बढ़ाया जाना चाहिए

B

A class that knows too much or does too much — violating SRP and creating a hub of dependencies; addressed by extracting classes and redistributing responsibilities according to cohesion एक वर्ग जो बहुत अधिक जानता है या बहुत अधिक करता है - एसआरपी का उल्लंघन करता है और निर्भरता का केंद्र बनाता है; सामंजस्य के अनुसार वर्गों को निकालकर और जिम्मेदारियों को पुनर्वितरित करके संबोधित किया गया

C

The main entry point class of any application किसी भी एप्लिकेशन का मुख्य प्रवेश बिंदु वर्ग

D

Only a problem in procedural programming, not OOP केवल प्रक्रियात्मक प्रोग्रामिंग में एक समस्या है, OOP नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) God Objects accumulate as developers add functionality to an existing central class. Eventually it becomes monolithic and coupled to everything. Refactoring uses Extract Class to pull cohesive groups of responsibilities into dedicated classes.

व्याख्या (हिन्दी) जैसे ही डेवलपर्स मौजूदा केंद्रीय वर्ग में कार्यक्षमता जोड़ते हैं, गॉड ऑब्जेक्ट जमा हो जाते हैं। अंततः यह अखंड हो जाता है और हर चीज़ से जुड़ जाता है। रिफैक्टरिंग जिम्मेदारियों के एकजुट समूहों को समर्पित कक्षाओं में खींचने के लिए एक्सट्रैक्ट क्लास का उपयोग करता है।

Software Engineering — MCQ Practice