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
301
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.
व्याख्या (हिन्दी) कार्यात्मक रूप से समान होते हुए भी, एक्सपी में टेस्ट-फर्स्ट एक्सपी के पारिस्थितिकी तंत्र के भीतर एम्बेडेड है: यह जोड़ी प्रोग्रामिंग (दोनों डेवलपर्स एक साथ परीक्षण विफल देखते हैं), निरंतर एकीकरण (हर कुछ घंटों में परीक्षण चलाते हैं), और ऑन-साइट ग्राहक (ग्राहक के साथ परिभाषित स्वीकृति परीक्षण) के साथ मिलकर काम करता है। केंट बेक और बाद में रॉबर्ट मार्टिन द्वारा लोकप्रिय टीडीडी किसी विशेष पद्धति की सामाजिक प्रथाओं से स्वतंत्र एक सामान्य अभ्यास है।
302
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.
व्याख्या (हिन्दी) सामूहिक स्वामित्व ज्ञान साइलो और बस-कारक जोखिमों को समाप्त करता है - कोई भी डेवलपर किसी भी मॉड्यूल में किसी भी बग को ठीक कर सकता है। जोखिम (शैली असंगतता, विरोधाभासी रिफैक्टर) को कम किया जाता है: स्वचालित परीक्षण जो प्रतिगमन को तुरंत पकड़ते हैं, सीआई जो घंटों के भीतर एकीकरण संघर्ष का पता लगाता है, साझा कोडिंग मानक जो शैली स्थिरता बनाए रखते हैं, और लगातार एकीकरण जो शाखाओं को अल्पकालिक रखता है।
303
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+ घंटे काम करने वाली एक थकी हुई टीम की तुलना में प्रति सप्ताह अधिक मूल्य पैदा करती है - यहां तक ​​कि कोड की पंक्तियों में भी मापा जाता है, गुणवत्ता की तो बात ही छोड़ दें।
304
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.
व्याख्या (हिन्दी) जबकि टीडीडी डेवलपर-लिखित इकाई परीक्षणों के माध्यम से डिजाइन को संचालित करता है, एटीडीडी निष्पादन योग्य परीक्षणों के रूप में व्यक्त ग्राहक-लिखित स्वीकृति मानदंडों के माध्यम से विकास को संचालित करता है। ककड़ी, फिटनेस और स्पेकफ्लो जैसे उपकरण व्यवसाय-पठनीय परीक्षण सक्षम करते हैं। एटीडीडी संचार अंतराल को बंद करता है: ग्राहक 'दिया-कब-तब' परिदृश्य निर्दिष्ट करते हैं; डेवलपर्स उन परिदृश्यों के बीतने तक कार्यान्वयन करते हैं - व्यावसायिक इरादे और तकनीकी कार्यान्वयन के बीच संरेखण सुनिश्चित करते हैं।
305
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.
व्याख्या (हिन्दी) क्लासिक चुस्त विफलता: बीए एक कहानी लिखता है, डेवलपर अपनी व्याख्या बनाता है, परीक्षक उनकी व्याख्या के आधार पर परीक्षण लिखते हैं - तीन अलग-अलग समझ एकीकरण तक चुपचाप अलग हो जाती हैं। तीन अमीगोस (उदाहरण द्वारा विशिष्टता, गोज्को एडज़िक) में स्प्रिंट से पहले सभी तीन भूमिकाएं लेखक के ठोस उदाहरण हैं, जो साझा समझ और ठोस स्वीकृति मानदंड बनाते हैं, जिससे सभी तीन पक्ष सहमत होते हैं और एक ही आवश्यकता का प्रतिनिधित्व करते हैं।
306
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) बनाया कि डेवलपर्स को यह जानने के लिए संघर्ष करना पड़ता है कि क्या परीक्षण करना है और परीक्षण अक्सर इरादे को प्रतिबिंबित नहीं करते हैं। बीडीडी परिदृश्य (दी गई [संदर्भ], जब [क्रिया], तब [परिणाम]) हैं: गैर-डेवलपर्स द्वारा पढ़ने योग्य, जीवित दस्तावेज़ के रूप में कार्य करते हैं, सीधे व्यावसायिक आवश्यकताओं का पता लगाते हैं, और जब स्वचालित होते हैं (ककड़ी, व्यवहार) निष्पादन योग्य विनिर्देश प्रदान करते हैं।
307
EN + हिं Easy
GB What is 'technical spike' in agile development and when should it be used?
IN त्वरित विकास में 'तकनीकी स्पाइक' क्या है और इसका उपयोग कब किया जाना चाहिए?
A
A technical spike is an emergency debugging session for production incidents तकनीकी स्पाइक उत्पादन घटनाओं के लिए एक आपातकालीन डिबगिंग सत्र है
B
A technical spike is a time-boxed research or proof-of-concept effort used when a team faces significant technical uncertainty — the spike produces knowledge (not shippable product) that enables accurate estimation and informed design decisions तकनीकी स्पाइक एक समय-आधारित अनुसंधान या प्रूफ-ऑफ-कॉन्सेप्ट प्रयास है जिसका उपयोग तब किया जाता है जब एक टीम को महत्वपूर्ण तकनीकी अनिश्चितता का सामना करना पड़ता है - स्पाइक ज्ञान उत्पन्न करता है (शिप करने योग्य उत्पाद नहीं) जो सटीक अनुमान और सूचित डिजाइन निर्णयों को सक्षम बनाता है।
C
Technical spikes are only used when team members disagree about technology choices तकनीकी स्पाइक्स का उपयोग केवल तभी किया जाता है जब टीम के सदस्य प्रौद्योगिकी विकल्पों के बारे में असहमत हों
D
A technical spike is a sprint dedicated entirely to bug fixing and technical debt reduction तकनीकी स्पाइक एक स्प्रिंट है जो पूरी तरह से बग फिक्सिंग और तकनीकी ऋण कटौती के लिए समर्पित है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) When a story has uncertain technical feasibility (e.g., 'can our system integrate with vendor X's new API?'), estimating it is impossible without investigation. A spike — say, 2 days timebox — produces a working prototype answering the key question. The spike itself is never shipped; it produces knowledge that informs the actual story implementation estimate and design approach.
व्याख्या (हिन्दी) जब किसी कहानी में अनिश्चित तकनीकी व्यवहार्यता होती है (उदाहरण के लिए, 'क्या हमारा सिस्टम विक्रेता एक्स के नए एपीआई के साथ एकीकृत हो सकता है?'), तो जांच के बिना इसका अनुमान लगाना असंभव है। एक स्पाइक - मान लीजिए, 2 दिन का टाइमबॉक्स - मुख्य प्रश्न का उत्तर देने वाला एक कार्यशील प्रोटोटाइप तैयार करता है। स्पाइक स्वयं कभी भी शिप नहीं किया जाता है; यह ज्ञान पैदा करता है जो वास्तविक कहानी कार्यान्वयन अनुमान और डिजाइन दृष्टिकोण को सूचित करता है।
308
EN + हिं Easy
GB What is 'story mapping' in agile and what planning problem does it solve that a flat backlog creates?
IN एजाइल में 'स्टोरी मैपिंग' क्या है और यह किस योजना समस्या का समाधान करता है जो एक फ्लैट बैकलॉग बनाता है?
A
Story mapping is a technique for estimating story point values through collaborative card sorting स्टोरी मैपिंग सहयोगी कार्ड सॉर्टिंग के माध्यम से कहानी बिंदु मूल्यों का अनुमान लगाने की एक तकनीक है
B
Story mapping arranges stories in a two-dimensional grid (horizontal: user journey steps; vertical: priority/detail) — solving the flat backlog's problem of losing the narrative and context of how features relate to user goals स्टोरी मैपिंग कहानियों को दो-आयामी ग्रिड (क्षैतिज: उपयोगकर्ता यात्रा चरण; लंबवत: प्राथमिकता/विस्तार) में व्यवस्थित करती है - कथा और संदर्भ को खोने की फ्लैट बैकलॉग की समस्या को हल करना कि विशेषताएं उपयोगकर्ता के लक्ष्यों से कैसे संबंधित हैं
C
Story mapping is only used during retrospectives to categorise completed stories पूरी कहानियों को वर्गीकृत करने के लिए स्टोरी मैपिंग का उपयोग केवल पूर्वव्यापी के दौरान किया जाता है
D
Story mapping replaces the Product Backlog entirely in SAFe framework स्टोरी मैपिंग पूरी तरह से SAFe फ्रेमवर्क में उत्पाद बैकलॉग को प्रतिस्थापित कर देती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Jeff Patton's User Story Mapping addresses a common agile failure: a flat prioritised backlog loses the 'why' and 'how users flow through the system'. The map's backbone (top row) shows the user journey; rows below slice the backbone into deliverable increments. This reveals which slices deliver a walking skeleton vs. which add depth — enabling release planning that delivers coherent user value rather than disconnected feature fragments.
व्याख्या (हिन्दी) जेफ़ पैटन की उपयोगकर्ता स्टोरी मैपिंग एक सामान्य त्वरित विफलता को संबोधित करती है: एक फ्लैट प्राथमिकता वाला बैकलॉग 'क्यों' और 'उपयोगकर्ता सिस्टम के माध्यम से कैसे प्रवाहित होते हैं' को खो देता है। मानचित्र की रीढ़ (शीर्ष पंक्ति) उपयोगकर्ता की यात्रा दिखाती है; नीचे दी गई पंक्तियाँ रीढ़ की हड्डी को वितरण योग्य वेतन वृद्धि में काटती हैं। इससे पता चलता है कि कौन से स्लाइस एक चलने वाला कंकाल प्रदान करते हैं बनाम जो गहराई जोड़ते हैं - रिलीज योजना को सक्षम करते हैं जो डिस्कनेक्ट किए गए फीचर टुकड़ों के बजाय सुसंगत उपयोगकर्ता मूल्य प्रदान करता है।
309
EN + हिं Medium
GB What is the 'Cynefin framework' and how does it inform process model selection in software projects?
IN 'साइनफिन फ्रेमवर्क' क्या है और यह सॉफ्टवेयर परियोजनाओं में प्रक्रिया मॉडल चयन को कैसे सूचित करता है?
A
Cynefin is a risk management tool developed by Boehm for the Spiral model सिनेफ़िन स्पाइरल मॉडल के लिए बोहेम द्वारा विकसित एक जोखिम प्रबंधन उपकरण है
B
Cynefin (Snowden) categorises problems as Obvious, Complicated, Complex, or Chaotic — guiding process selection: Waterfall suits Obvious/Complicated domains (best practices exist); Agile suits Complex domains (practices emerge through experimentation); chaotic domains require immediate action सिनेफिन (स्नोडेन) समस्याओं को स्पष्ट, जटिल, जटिल या अराजक के रूप में वर्गीकृत करता है - मार्गदर्शक प्रक्रिया चयन: झरना स्पष्ट/जटिल डोमेन के लिए उपयुक्त है (सर्वोत्तम अभ्यास मौजूद हैं); एजाइल जटिल डोमेन के लिए उपयुक्त है (प्रयोग प्रयोग के माध्यम से उभरते हैं); अराजक डोमेन पर तत्काल कार्रवाई की आवश्यकता है
C
Cynefin framework mandates that all software projects must use Agile regardless of domain type सिनेफिन फ्रेमवर्क का आदेश है कि सभी सॉफ्टवेयर प्रोजेक्टों को डोमेन प्रकार की परवाह किए बिना एजाइल का उपयोग करना चाहिए
D
Cynefin is a database design framework unrelated to software process models सिनेफ़िन एक डेटाबेस डिज़ाइन फ़्रेमवर्क है जो सॉफ़्टवेयर प्रक्रिया मॉडल से असंबंधित है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Cynefin provides a theoretical basis for process model selection. Complicated problems (aircraft navigation algorithms) have knowable solutions requiring expert analysis — plan-driven works. Complex problems (social network features, ML products) have emergent solutions knowable only through experimentation — agile works. Applying Waterfall to complex domains creates expensive failures; applying Agile to complicated safety-critical systems creates dangerous ones.
व्याख्या (हिन्दी) सिनेफ़िन प्रक्रिया मॉडल चयन के लिए एक सैद्धांतिक आधार प्रदान करता है। जटिल समस्याओं (विमान नेविगेशन एल्गोरिदम) में जानने योग्य समाधान होते हैं जिनके लिए विशेषज्ञ विश्लेषण की आवश्यकता होती है - योजना-संचालित कार्य। जटिल समस्याओं (सोशल नेटवर्क सुविधाएँ, एमएल उत्पाद) के उभरते समाधान केवल प्रयोग - चुस्त कार्यों के माध्यम से ही जाने जा सकते हैं। जटिल डोमेन पर वॉटरफ़ॉल लागू करने से महंगी विफलताएँ उत्पन्न होती हैं; जटिल सुरक्षा-महत्वपूर्ण प्रणालियों में एजाइल को लागू करने से खतरनाक प्रणालियाँ बनती हैं।
310
EN + हिं Easy
GB What is the 'requirements prioritisation' technique MoSCoW and what critical risk does ignoring it introduce?
IN 'आवश्यकताओं को प्राथमिकता देने' की तकनीक MoSCoW क्या है और इसे अनदेखा करने से कौन सा गंभीर जोखिम उत्पन्न होता है?
A
MoSCoW is a database query language for requirements management tools MoSCoW आवश्यकता प्रबंधन टूल के लिए एक डेटाबेस क्वेरी भाषा है
B
MoSCoW classifies requirements as Must-have, Should-have, Could-have, and Won't-have this time; ignoring it risks delivering complete features of low importance while must-have requirements remain unfinished at delivery MoSCoW इस बार आवश्यकताओं को अवश्य होना चाहिए, होना चाहिए, हो सकता है और नहीं होगा के रूप में वर्गीकृत करता है; इसे अनदेखा करने से कम महत्व की संपूर्ण सुविधाएँ प्रदान करने का जोखिम होता है जबकि डिलीवरी के समय आवश्यक आवश्यकताएँ अधूरी रह जाती हैं
C
MoSCoW is only applicable to government procurement projects with regulatory requirements MoSCoW केवल नियामक आवश्यकताओं वाली सरकारी खरीद परियोजनाओं पर लागू है
D
MoSCoW eliminates the need for requirements elicitation by using stakeholder votes MoSCoW हितधारक वोटों का उपयोग करके आवश्यकताओं को प्राप्त करने की आवश्यकता को समाप्त करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) MoSCoW (Dai Clegg, DSDM) is critical for timeboxed delivery. Without prioritisation, teams treat all requirements equally and risk spending 80% of effort on 20% of the value. Must-haves define the product's minimum viable set; everything else can drop if time runs out. Projects that don't use MoSCoW often deliver everything but the essential features last — meeting contractual scope but failing operationally.
व्याख्या (हिन्दी) MoSCoW (दाई क्लेग, DSDM) समयबद्ध डिलीवरी के लिए महत्वपूर्ण है। प्राथमिकता के बिना, टीमें सभी आवश्यकताओं को समान रूप से मानती हैं और मूल्य के 20% पर 80% प्रयास खर्च करने का जोखिम उठाती हैं। उत्पाद के न्यूनतम व्यवहार्य सेट को परिभाषित करना आवश्यक है; यदि समय समाप्त हो गया तो बाकी सब कुछ गिर सकता है। जो परियोजनाएँ MoSCoW का उपयोग नहीं करती हैं वे अक्सर आवश्यक सुविधाओं को छोड़कर सब कुछ प्रदान करती हैं - संविदात्मक दायरे को पूरा करना लेकिन परिचालन में विफल होना।
311
EN + हिं Easy
GB What is the 'Volere requirements shell' and what categories of information does it capture for each requirement?
IN 'वोलेरे रिक्वायरमेंट शेल' क्या है और यह प्रत्येक आवश्यकता के लिए किस श्रेणी की जानकारी प्राप्त करता है?
A
Volere shell is a UML diagram template for drawing use case diagrams वोलेरे शेल उपयोग केस आरेख बनाने के लिए एक यूएमएल आरेख टेम्पलेट है
B
Volere shell is a template for documenting individual requirements capturing: requirement number, description, rationale, originator, fit criterion, customer satisfaction/dissatisfaction, conflicts, priority, history, and supporting material वोलेरे शेल व्यक्तिगत आवश्यकताओं को दर्ज करने के लिए एक टेम्पलेट है: आवश्यकता संख्या, विवरण, तर्क, प्रवर्तक, फिट मानदंड, ग्राहक संतुष्टि/असंतोष, संघर्ष, प्राथमिकता, इतिहास और सहायक सामग्री।
C
Volere shell is a UX design pattern for capturing user interface requirements वोलेरे शेल यूजर इंटरफ़ेस आवश्यकताओं को कैप्चर करने के लिए एक यूएक्स डिज़ाइन पैटर्न है
D
Volere shell is an automated requirements extraction tool for legacy codebases वोलेरे शेल लीगेसी कोडबेस के लिए एक स्वचालित आवश्यकता निष्कर्षण उपकरण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robertson and Robertson's Volere Requirements Shell provides a systematic checklist ensuring every requirement is fully specified: fit criterion (verifiable measure of satisfaction), customer satisfaction/dissatisfaction ratings (motivating the requirement's importance), originator, conflicts, and history. It prevents thin requirements that say what without saying why or how to verify.
व्याख्या (हिन्दी) Robertson and Robertson's Volere Requirements Shell provides a systematic checklist ensuring every requirement is fully specified: fit criterion (verifiable measure of satisfaction), customer satisfaction/dissatisfaction ratings (motivating the requirement's importance), originator, conflicts, and history. यह उन पतली आवश्यकताओं को रोकता है जो यह बताए बिना कि क्यों या कैसे सत्यापित करें, क्या कहती हैं।
312
EN + हिं Easy
GB What is 'contextual inquiry' as a requirements elicitation technique and what unique insights does it produce?
IN आवश्यकताओं को प्राप्त करने की तकनीक के रूप में 'प्रासंगिक पूछताछ' क्या है और यह कौन सी अनूठी अंतर्दृष्टि उत्पन्न करती है?
A
Contextual inquiry is a technique where users complete online surveys about their software preferences प्रासंगिक पूछताछ एक ऐसी तकनीक है जहां उपयोगकर्ता अपनी सॉफ़्टवेयर प्राथमिकताओं के बारे में ऑनलाइन सर्वेक्षण पूरा करते हैं
B
Contextual inquiry involves observing users in their actual work environment while they perform real tasks — revealing workarounds, informal processes, environmental constraints, and tacit knowledge that users would never articulate in interviews प्रासंगिक जांच में उपयोगकर्ताओं को वास्तविक कार्य करते समय उनके वास्तविक कार्य वातावरण में देखना शामिल है - कामकाज, अनौपचारिक प्रक्रियाओं, पर्यावरणीय बाधाओं और मौन ज्ञान को प्रकट करना, जिसे उपयोगकर्ता कभी भी साक्षात्कार में व्यक्त नहीं करेंगे।
C
Contextual inquiry is a formal requirements review process involving only technical stakeholders प्रासंगिक जांच एक औपचारिक आवश्यकता समीक्षा प्रक्रिया है जिसमें केवल तकनीकी हितधारक शामिल होते हैं
D
Contextual inquiry is equivalent to a focus group and produces the same type of insights प्रासंगिक पूछताछ एक फोकस समूह के बराबर है और उसी प्रकार की अंतर्दृष्टि उत्पन्न करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Contextual inquiry (Beyer and Holtzblatt) is based on the principle that people do not reliably describe how they actually work — they describe how they think they work or how they're supposed to work. Observation reveals: undocumented workarounds (existing systems can't do X so users maintain a spreadsheet), environmental constraints (noisy floor, multiple screens), and task flows very different from what IT documented.
व्याख्या (हिन्दी) प्रासंगिक जांच (बेयर और होल्ट्ज़ब्लैट) इस सिद्धांत पर आधारित है कि लोग विश्वसनीय रूप से यह नहीं बताते हैं कि वे वास्तव में कैसे काम करते हैं - वे वर्णन करते हैं कि वे कैसे सोचते हैं कि वे काम करते हैं या उन्हें कैसे काम करना चाहिए। अवलोकन से पता चलता है: अनिर्दिष्ट वर्कअराउंड (मौजूदा सिस्टम एक्स नहीं कर सकते हैं ताकि उपयोगकर्ता एक स्प्रेडशीट बनाए रखें), पर्यावरणीय बाधाएं (शोर फर्श, एकाधिक स्क्रीन), और कार्य प्रवाह आईटी द्वारा दस्तावेज से बहुत अलग है।
313
EN + हिं Easy
GB What is 'impact mapping' in requirements and product planning and what cascading relationship does it model?
IN आवश्यकताओं और उत्पाद योजना में 'प्रभाव मानचित्रण' क्या है और यह किस व्यापक संबंध का मॉडल तैयार करता है?
A
Impact mapping is a technique for measuring the financial impact of software defects इम्पैक्ट मैपिंग सॉफ्टवेयर दोषों के वित्तीय प्रभाव को मापने की एक तकनीक है
B
Impact mapping models the causal chain: WHY (business goal) → WHO (actors) → HOW (impacts on actors) → WHAT (deliverables/features) — preventing feature factories that deliver functionality disconnected from business outcomes प्रभाव मानचित्रण कारण श्रृंखला को मॉडल करता है: क्यों (व्यावसायिक लक्ष्य) → कौन (अभिनेता) → कैसे (अभिनेताओं पर प्रभाव) → क्या (डिलीवरेबल्स/फीचर्स) - व्यावसायिक परिणामों से अलग कार्यक्षमता प्रदान करने वाली फीचर फैक्ट्रियों को रोकना
C
Impact mapping is only used in marketing departments to measure advertising campaign effectiveness विज्ञापन अभियान की प्रभावशीलता को मापने के लिए प्रभाव मानचित्रण का उपयोग केवल विपणन विभागों में किया जाता है
D
Impact mapping replaces the product backlog by generating stories automatically from business goals प्रभाव मानचित्रण व्यावसायिक लक्ष्यों से स्वचालित रूप से कहानियाँ उत्पन्न करके उत्पाद बैकलॉग को प्रतिस्थापित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gojko Adzic's impact mapping prevents the common failure of teams that deliver everything they were asked for but fail to achieve business goals. By requiring explicit causal links (this feature changes actor X's behaviour in way Y which achieves goal Z), impact mapping exposes features whose causal chain is weak — enabling ROI-based scope prioritisation.
व्याख्या (हिन्दी) गोज्को एडज़िक का प्रभाव मानचित्रण उन टीमों की सामान्य विफलता को रोकता है जो उनसे मांगी गई हर चीज़ प्रदान करती हैं लेकिन व्यावसायिक लक्ष्यों को प्राप्त करने में विफल रहती हैं। स्पष्ट कारण लिंक की आवश्यकता के द्वारा (यह सुविधा अभिनेता
314
EN + हिं Easy
GB What is the 'requirements inspection' process and what specific defect types does it target beyond what peer reviews find?
IN 'आवश्यकताओं के निरीक्षण' की प्रक्रिया क्या है और यह सहकर्मी समीक्षाओं से परे किस विशिष्ट दोष प्रकार को लक्षित करती है?
A
Requirements inspection only verifies that requirements are written in the mandated document format आवश्यकताएँ निरीक्षण केवल यह सत्यापित करता है कि आवश्यकताएँ अनिवार्य दस्तावेज़ प्रारूप में लिखी गई हैं
B
Requirements inspection applies Fagan-style checklists targeting requirements-specific defects: ambiguity (multiple interpretations), incompleteness (missing states/conditions), inconsistency (contradicting requirements), unverifiability (no testable criterion), and infeasibility आवश्यकताओं का निरीक्षण आवश्यकताओं-विशिष्ट दोषों को लक्षित करने वाली फगन-शैली चेकलिस्ट को लागू करता है: अस्पष्टता (एकाधिक व्याख्याएं), अपूर्णता (अनुपलब्ध राज्य/शर्तें), असंगतता (विरोधाभासी आवश्यकताएं), असत्यापनीयता (कोई परीक्षण योग्य मानदंड नहीं), और अव्यवहार्यता
C
Requirements inspection is identical to a requirements review; the terms are fully interchangeable आवश्यकताओं का निरीक्षण आवश्यकताओं की समीक्षा के समान है; शर्तें पूरी तरह से विनिमेय हैं
D
Requirements inspection can only be performed by external auditors, not internal team members आवश्यकताओं का निरीक्षण केवल बाहरी लेखा परीक्षकों द्वारा किया जा सकता है, आंतरिक टीम के सदस्यों द्वारा नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Requirements inspections use domain-specific checklists beyond what informal reviews catch. Ambiguity: 'the system shall respond quickly' — quickly meaning what? Incompleteness: what happens when input is null? Inconsistency: requirement 23 says X, requirement 47 says not-X. These are systematic defects invisible to the author but visible to trained inspectors examining against a checklist.
व्याख्या (हिन्दी) आवश्यकताएँ निरीक्षण अनौपचारिक समीक्षाओं से परे डोमेन-विशिष्ट चेकलिस्ट का उपयोग करते हैं। अस्पष्टता: 'सिस्टम तुरंत प्रतिक्रिया देगा' - त्वरित अर्थ क्या? अपूर्णता: क्या होता है जब इनपुट शून्य होता है? असंगति: आवश्यकता 23 कहती है एक्स, आवश्यकता 47 कहती है नॉट-एक्स। ये व्यवस्थित दोष हैं जो लेखक के लिए अदृश्य हैं लेकिन चेकलिस्ट के अनुसार जांच करने वाले प्रशिक्षित निरीक्षकों को दिखाई देते हैं।
315
EN + हिं Easy
GB What is the 'quality function deployment' (QFD) technique in requirements engineering and what does the 'house of quality' represent?
IN रिक्वायरमेंट इंजीनियरिंग में 'क्वालिटी फंक्शन डिप्लॉयमेंट' (क्यूएफडी) तकनीक क्या है और 'हाउस ऑफ क्वालिटी' क्या दर्शाती है?
A
QFD is a software testing technique ensuring quality attributes are defined before implementation क्यूएफडी एक सॉफ्टवेयर परीक्षण तकनीक है जो यह सुनिश्चित करती है कि कार्यान्वयन से पहले गुणवत्ता विशेषताओं को परिभाषित किया जाए
B
QFD (from manufacturing, applied to software) translates customer requirements (WHATs) into technical design characteristics (HOWs) via a correlation matrix — the 'house of quality' is this matrix showing which technical parameters satisfy which customer needs and their interactions क्यूएफडी (विनिर्माण से लेकर, सॉफ्टवेयर तक लागू) एक सहसंबंध मैट्रिक्स के माध्यम से ग्राहक आवश्यकताओं (डब्ल्यूएचएटीएस) को तकनीकी डिजाइन विशेषताओं (एचओडब्ल्यू) में अनुवादित करता है - 'गुणवत्ता का घर' यह मैट्रिक्स दिखाता है कि कौन से तकनीकी पैरामीटर ग्राहक की जरूरतों और उनकी बातचीत को पूरा करते हैं
C
QFD is a project management tool for tracking requirements completion percentages QFD आवश्यकताओं के पूरा होने के प्रतिशत पर नज़र रखने के लिए एक परियोजना प्रबंधन उपकरण है
D
QFD is only applicable to hardware product design, not software requirements QFD केवल हार्डवेयर उत्पाद डिज़ाइन पर लागू होता है, सॉफ़्टवेयर आवश्यकताओं पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) QFD's house of quality maps customer 'voices' (requirements) to engineering characteristics, showing relative importance weights, correlations between requirements, competing product benchmarks, and target values. Applied to software, it systematically connects user needs to design decisions, preventing designs that satisfy internal technical metrics while failing user needs — a common disconnect in software.
व्याख्या (हिन्दी) क्यूएफडी का हाउस ऑफ क्वालिटी ग्राहकों की आवाजों (आवश्यकताओं) को इंजीनियरिंग विशेषताओं के अनुसार मैप करता है, सापेक्ष महत्व के वजन, आवश्यकताओं के बीच संबंध, प्रतिस्पर्धी उत्पाद बेंचमार्क और लक्ष्य मूल्यों को दर्शाता है। सॉफ़्टवेयर पर लागू, यह डिज़ाइन निर्णयों के लिए उपयोगकर्ता की ज़रूरतों को व्यवस्थित रूप से जोड़ता है, ऐसे डिज़ाइनों को रोकता है जो उपयोगकर्ता की ज़रूरतों को विफल करते हुए आंतरिक तकनीकी मैट्रिक्स को पूरा करते हैं - सॉफ़्टवेयर में एक सामान्य डिस्कनेक्ट।
301–315 of 647