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
571
EN + हिं Easy
GB What is 'value stream mapping' applied to software development and what waste categories does it identify?
IN सॉफ़्टवेयर विकास पर लागू 'वैल्यू स्ट्रीम मैपिंग' क्या है और यह किन अपशिष्ट श्रेणियों की पहचान करती है?
A
Value stream mapping is a UML sequence diagram technique for documenting API interactions वैल्यू स्ट्रीम मैपिंग एपीआई इंटरैक्शन के दस्तावेजीकरण के लिए एक यूएमएल अनुक्रम आरेख तकनीक है
B
Value stream mapping traces the flow of a feature from idea to production, identifying waste in the process — waste categories in software (Poppendieck's lean): partially done work, extra processes, extra features, task switching, waiting, motion (handoffs), defects वैल्यू स्ट्रीम मैपिंग विचार से उत्पादन तक एक सुविधा के प्रवाह का पता लगाती है, प्रक्रिया में अपशिष्ट की पहचान करती है - सॉफ्टवेयर में अपशिष्ट श्रेणियां (पॉपेंडिएक का झुकाव): आंशिक रूप से किया गया कार्य, अतिरिक्त प्रक्रियाएं, अतिरिक्त सुविधाएं, कार्य स्विचिंग, प्रतीक्षा, गति (हैंडऑफ़), दोष
C
Value stream mapping only applies to manufacturing workflows and cannot be used for software वैल्यू स्ट्रीम मैपिंग केवल विनिर्माण वर्कफ़्लो पर लागू होती है और सॉफ़्टवेयर के लिए इसका उपयोग नहीं किया जा सकता है
D
Value stream mapping is identical to a Gantt chart with additional colour coding वैल्यू स्ट्रीम मैपिंग अतिरिक्त रंग कोडिंग के साथ गैंट चार्ट के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Applying VSM to a software feature request reveals hidden waste: 2 days development, 3 days waiting for code review, 1 day review, 2 days waiting for QA, 2 days testing, 5 days waiting for release approval, 1 hour actual deployment. The value-added time is 5 days; total lead time is 15 days — 67% waste. This makes invisible waiting visible, driving improvement focus to cycle time reduction rather than developer productivity.
व्याख्या (हिन्दी) सॉफ़्टवेयर फ़ीचर अनुरोध पर वीएसएम लागू करने से छिपे हुए अपशिष्ट का पता चलता है: 2 दिन का विकास, 3 दिन कोड समीक्षा की प्रतीक्षा, 1 दिन की समीक्षा, 2 दिन क्यूए की प्रतीक्षा, 2 दिन परीक्षण, 5 दिन रिलीज़ अनुमोदन की प्रतीक्षा, 1 घंटा वास्तविक तैनाती। मूल्यवर्धित समय 5 दिन है; कुल लीड टाइम 15 दिन है - 67% बर्बादी। यह अदृश्य प्रतीक्षा को दृश्यमान बनाता है, जिससे डेवलपर उत्पादकता के बजाय चक्र समय में कमी पर सुधार पर ध्यान केंद्रित होता है।
572
EN + हिं Easy
GB What is 'mob programming' and what does research suggest about its quality and productivity trade-offs?
IN 'मॉब प्रोग्रामिंग' क्या है और शोध इसकी गुणवत्ता और उत्पादकता के बीच के अंतर के बारे में क्या सुझाव देता है?
A
Mob programming means a group of developers working independently on the same repository simultaneously मोब प्रोग्रामिंग का अर्थ है डेवलपर्स का एक समूह जो एक ही रिपॉजिटरी पर एक साथ स्वतंत्र रूप से काम करता है
B
Mob programming has the entire team (3-5+ developers) working at one computer simultaneously with rotating 'drivers' — research and practitioner reports suggest: significantly better code quality and knowledge sharing, lower defect rates, faster onboarding, but higher initial cognitive overhead and requires strong facilitation मॉब प्रोग्रामिंग में पूरी टीम (3-5+ डेवलपर्स) एक ही कंप्यूटर पर घूमने वाले 'ड्राइवरों' के साथ काम करती है - अनुसंधान और व्यवसायी रिपोर्ट से पता चलता है: काफी बेहतर कोड गुणवत्ता और ज्ञान साझा करना, कम दोष दर, तेज ऑनबोर्डिंग, लेकिन उच्च प्रारंभिक संज्ञानात्मक ओवरहेड और मजबूत सुविधा की आवश्यकता है
C
Mob programming has been scientifically proved to produce exactly double the defects of pair programming वैज्ञानिक रूप से यह सिद्ध हो चुका है कि मोब प्रोग्रामिंग जोड़ी प्रोग्रामिंग के दोषों को दोगुना कर देती है
D
Mob programming is only practical for teams working on algorithms; UI development requires individual work मॉब प्रोग्रामिंग केवल एल्गोरिदम पर काम करने वाली टीमों के लिए व्यावहारिक है; यूआई विकास के लिए व्यक्तिगत कार्य की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Woody Zuill's reports from Hunter Industries (where mob programming originated) showed: near-zero defects reaching production, eliminated code review bottlenecks, eliminated handoff waste, and dramatically faster knowledge sharing. Academic research is limited but practitioner evidence is compelling. The overhead is real (one keyboard for 5 people) but the communication bandwidth and collective intelligence can exceed the sum of individual work.
व्याख्या (हिन्दी) हंटर इंडस्ट्रीज (जहां मॉब प्रोग्रामिंग की शुरुआत हुई) से वुडी ज़ुइल की रिपोर्ट से पता चला: उत्पादन तक पहुंचने में लगभग शून्य दोष, कोड समीक्षा बाधाओं को समाप्त किया गया, हैंडऑफ अपशिष्ट को समाप्त किया गया, और नाटकीय रूप से तेजी से ज्ञान साझा किया गया। अकादमिक शोध सीमित है लेकिन अभ्यासकर्ता साक्ष्य सम्मोहक है। ओवरहेड वास्तविक है (5 लोगों के लिए एक कीबोर्ड) लेकिन संचार बैंडविड्थ और सामूहिक बुद्धिमत्ता व्यक्तिगत कार्य के योग से अधिक हो सकती है।
573
EN + हिं Medium
GB What is 'the agile iron triangle' inversion and how does it change project delivery management?
IN 'द एजाइल आयरन ट्राइएंगल' व्युत्क्रम क्या है और यह परियोजना वितरण प्रबंधन को कैसे बदलता है?
A
Agile iron triangle eliminates time and cost constraints entirely by using unlimited sprints एजाइल आयरन ट्राइएंगल असीमित स्प्रिंट का उपयोग करके समय और लागत की बाधाओं को पूरी तरह से समाप्त कर देता है
B
Traditional iron triangle fixes scope and varies time/cost; agile inverts this by fixing time (sprint length) and cost (team size) while varying scope — delivery management shifts from schedule tracking (will we finish everything?) to value maximisation (are we delivering the highest value within the fixed cadence?) पारंपरिक लौह त्रिकोण दायरा तय करता है और समय/लागत बदलता रहता है; एजाइल अलग-अलग दायरे में समय (स्प्रिंट लंबाई) और लागत (टीम का आकार) तय करके इसे उलट देता है - वितरण प्रबंधन शेड्यूल ट्रैकिंग (क्या हम सब कुछ खत्म कर देंगे?) से मूल्य अधिकतमकरण (क्या हम निश्चित ताल के भीतर उच्चतम मूल्य प्रदान कर रहे हैं?) में बदल जाता है।
C
Agile iron triangle fixes all three variables simultaneously, eliminating project uncertainty एजाइल आयरन ट्राइएंगल परियोजना की अनिश्चितता को दूर करते हुए सभी तीन चरों को एक साथ ठीक करता है
D
The iron triangle inversion means agile projects never have deadlines or budget constraints लौह त्रिकोण व्युत्क्रम का मतलब है कि चुस्त परियोजनाओं में कभी भी समय सीमा या बजट की कमी नहीं होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traditional PM asks 'how long will it take to build all these features?' (uncertain answer). Agile asks 'what is the most valuable thing we can build in this fixed time with this fixed team?' (always deliverable answer). Sprint commitments are scope commitments for a fixed timebox — the sprint may not complete all planned stories but always ends at its fixed date. This guarantees regular delivery rhythm while preserving scope flexibility.
व्याख्या (हिन्दी) पारंपरिक प्रधानमंत्री पूछते हैं 'इन सभी सुविधाओं को बनाने में कितना समय लगेगा?' (अनिश्चित उत्तर). एजाइल पूछता है 'इस निश्चित टीम के साथ इस निश्चित समय में हम कौन सी सबसे मूल्यवान चीज़ बना सकते हैं?' (हमेशा वितरण योग्य उत्तर)। स्प्रिंट प्रतिबद्धताएँ एक निश्चित टाइमबॉक्स के लिए स्कोप प्रतिबद्धताएँ हैं - स्प्रिंट सभी नियोजित कहानियों को पूरा नहीं कर सकता है लेकिन हमेशा अपनी निश्चित तिथि पर समाप्त होता है। यह स्कोप लचीलेपन को बनाए रखते हुए नियमित डिलीवरी लय की गारंटी देता है।
574
EN + हिं Easy
GB What is the 'product discovery' phase and what is the 'opportunity solution tree' technique?
IN 'उत्पाद खोज' चरण क्या है और 'अवसर समाधान वृक्ष' तकनीक क्या है?
A
Product discovery is a phase where legal requirements for the product are documented उत्पाद खोज एक ऐसा चरण है जहां उत्पाद के लिए कानूनी आवश्यकताओं का दस्तावेजीकरण किया जाता है
B
Product discovery identifies validated customer needs and solutions before engineering commitment; the opportunity solution tree (Teresa Torres) maps: desired outcome → opportunities (customer needs) → solutions → experiments — ensuring solutions are traceable to real customer problems उत्पाद खोज इंजीनियरिंग प्रतिबद्धता से पहले मान्य ग्राहक आवश्यकताओं और समाधानों की पहचान करती है; अवसर समाधान वृक्ष (टेरेसा टोरेस) मानचित्र: वांछित परिणाम → अवसर (ग्राहक की जरूरतें) → समाधान → प्रयोग - यह सुनिश्चित करना कि समाधान वास्तविक ग्राहक समस्याओं के लिए खोजे जा सकें
C
Product discovery is only relevant for brand new products; existing products skip it entirely उत्पाद खोज केवल बिल्कुल नए उत्पादों के लिए प्रासंगिक है; मौजूदा उत्पाद इसे पूरी तरह से छोड़ देते हैं
D
Opportunity solution tree is a project management scheduling tool for tracking feature completion अवसर समाधान वृक्ष सुविधा पूर्णता पर नज़र रखने के लिए एक परियोजना प्रबंधन शेड्यूलिंग उपकरण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Teresa Torres' Opportunity Solution Tree prevents 'solution-first thinking' — jumping to building a feature without proving it addresses a real customer problem. Starting from a measurable desired outcome (increase monthly active users by 20%), mapping customer opportunities (pain points, needs), generating multiple solution options per opportunity, and designing experiments before building — this structure ensures engineering investment is traceable to validated business value.
व्याख्या (हिन्दी) टेरेसा टोरेस का अवसर समाधान वृक्ष 'समाधान-प्रथम सोच' को रोकता है - यह साबित किए बिना कि यह एक वास्तविक ग्राहक समस्या का समाधान करता है, एक सुविधा का निर्माण करना शुरू कर देता है। मापने योग्य वांछित परिणाम से शुरू करना (मासिक सक्रिय उपयोगकर्ताओं में 20% की वृद्धि), ग्राहक के अवसरों (दर्द बिंदु, जरूरतों) का मानचित्रण करना, प्रति अवसर कई समाधान विकल्प उत्पन्न करना, और निर्माण से पहले प्रयोगों को डिजाइन करना - यह संरचना सुनिश्चित करती है कि इंजीनियरिंग निवेश मान्य व्यावसायिक मूल्य के लिए पता लगाने योग्य है।
575
EN + हिं Easy
GB What is the 'INVEST criteria' for user stories and what specific problem does each letter address?
IN उपयोगकर्ता कहानियों के लिए 'निवेश मानदंड' क्या है और प्रत्येक पत्र किस विशिष्ट समस्या का समाधान करता है?
A
INVEST is an acronym for five agile ceremonies: Iteration, Negotiation, Velocity, Estimation, Standup, Testing निवेश पांच त्वरित समारोहों का संक्षिप्त रूप है: पुनरावृत्ति, बातचीत, वेग, अनुमान, स्टैंडअप, परीक्षण
B
INVEST: Independent (can be developed in any order, no story blocking another), Negotiable (details subject to discussion), Valuable (delivers user value), Estimable (team can estimate effort), Small (fits in one sprint), Testable (has clear acceptance criteria) — each criterion addresses a failure mode of poorly written stories निवेश: स्वतंत्र (किसी भी क्रम में विकसित किया जा सकता है, कोई भी कहानी किसी अन्य को अवरुद्ध नहीं करती), परक्राम्य (विवरण चर्चा का विषय), मूल्यवान (उपयोगकर्ता मूल्य प्रदान करता है), अनुमान लगाने योग्य (टीम प्रयास का अनुमान लगा सकती है), छोटा (एक स्प्रिंट में फिट बैठता है), परीक्षण योग्य (स्पष्ट स्वीकृति मानदंड) - प्रत्येक मानदंड खराब लिखी गई कहानियों की विफलता मोड को संबोधित करता है
C
INVEST criteria are only applicable to Scrum; Kanban teams do not use user stories निवेश मानदंड केवल स्क्रम पर लागू होते हैं; कानबन टीमें उपयोगकर्ता कहानियों का उपयोग नहीं करती हैं
D
INVEST was developed by the Scrum Alliance as a replacement for use cases निवेश को स्क्रम अलायंस द्वारा उपयोग के मामलों के प्रतिस्थापन के रूप में विकसित किया गया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Each letter prevents a specific failure: Non-independent stories create scheduling dependencies that disrupt sprint planning. Non-negotiable stories ('build exactly this') prevent creative solutions. Non-valuable stories waste sprint capacity. Non-estimable stories (too vague or unknown) can't be sprint-committed. Too-large stories won't complete in a sprint. Non-testable stories have no done criteria — enabling endless scope debate at sprint end.
व्याख्या (हिन्दी) प्रत्येक अक्षर एक विशिष्ट विफलता को रोकता है: गैर-स्वतंत्र कहानियाँ शेड्यूलिंग निर्भरताएँ बनाती हैं जो स्प्रिंट योजना को बाधित करती हैं। गैर-परक्राम्य कहानियाँ ('बिल्कुल इसे बनाएँ') रचनात्मक समाधानों को रोकती हैं। गैर-मूल्यवान कहानियाँ स्प्रिंट क्षमता को बर्बाद करती हैं। अकल्पनीय कहानियाँ (बहुत अस्पष्ट या अज्ञात) स्प्रिंट-प्रतिबद्ध नहीं की जा सकतीं। बहुत बड़ी कहानियाँ तेजी से पूरी नहीं होंगी। गैर-परीक्षण योग्य कहानियों का कोई मानदंड नहीं है - स्प्रिंट अंत में अंतहीन गुंजाइश बहस को सक्षम करना।
576
EN + हिं Easy
GB What is 'technical feasibility assessment' and when in a project should it occur?
IN 'तकनीकी व्यवहार्यता मूल्यांकन' क्या है और यह किसी परियोजना में कब होना चाहिए?
A
Technical feasibility is assessed only after the full system is designed and before coding begins तकनीकी व्यवहार्यता का आकलन पूर्ण सिस्टम डिज़ाइन होने के बाद और कोडिंग शुरू होने से पहले ही किया जाता है
B
Technical feasibility assesses whether proposed technical approaches can achieve required functionality within constraints (performance, cost, platform) — it should occur early (before significant design investment) and specifically target the highest-uncertainty aspects through prototypes or proof of concepts तकनीकी व्यवहार्यता यह आकलन करती है कि क्या प्रस्तावित तकनीकी दृष्टिकोण बाधाओं (प्रदर्शन, लागत, प्लेटफ़ॉर्म) के भीतर आवश्यक कार्यक्षमता प्राप्त कर सकते हैं - यह जल्दी (महत्वपूर्ण डिजाइन निवेश से पहले) होना चाहिए और विशेष रूप से प्रोटोटाइप या अवधारणाओं के प्रमाण के माध्यम से उच्चतम-अनिश्चितता पहलुओं को लक्षित करना चाहिए।
C
Technical feasibility is always positive if the development team is experienced enough यदि विकास टीम पर्याप्त अनुभवी है तो तकनीकी व्यवहार्यता हमेशा सकारात्मक होती है
D
Technical feasibility assessment is only required for AI and machine learning projects तकनीकी व्यवहार्यता मूल्यांकन केवल एआई और मशीन लर्निंग परियोजनाओं के लिए आवश्यक है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Classic feasibility failure: a team spends 6 months designing a real-time processing system before discovering that the required 1ms latency is impossible with the mandated cloud provider's managed services. Early feasibility prototypes (Spiral model's risk reduction) would have discovered this in week 2. High-risk technical unknowns (unproven algorithms, performance-critical paths, third-party integration points) should be prototyped before any significant architecture commitment.
व्याख्या (हिन्दी) क्लासिक व्यवहार्यता विफलता: एक टीम यह पता लगाने से पहले कि अनिवार्य क्लाउड प्रदाता की प्रबंधित सेवाओं के साथ आवश्यक 1ms विलंबता असंभव है, एक वास्तविक समय प्रसंस्करण प्रणाली को डिजाइन करने में 6 महीने खर्च करती है। प्रारंभिक व्यवहार्यता प्रोटोटाइप (सर्पिल मॉडल के जोखिम में कमी) ने इसे सप्ताह 2 में खोजा होगा। उच्च जोखिम वाले तकनीकी अज्ञात (अप्रमाणित एल्गोरिदम, प्रदर्शन-महत्वपूर्ण पथ, तृतीय-पक्ष एकीकरण बिंदु) को किसी भी महत्वपूर्ण वास्तुकला प्रतिबद्धता से पहले प्रोटोटाइप किया जाना चाहिए।
577
EN + हिं Easy
GB What is the 'minimum viable product' (MVP) concept and what is the most common misapplication of it?
IN 'न्यूनतम व्यवहार्य उत्पाद' (एमवीपी) अवधारणा क्या है और इसका सबसे आम दुरुपयोग क्या है?
A
MVP is the cheapest possible version of a product, built with minimal developer effort एमवीपी किसी उत्पाद का सबसे सस्ता संभव संस्करण है, जिसे न्यूनतम डेवलपर प्रयास के साथ बनाया गया है
B
MVP (Ries) is the version of a new product that allows maximum learning with minimum effort — its purpose is to test a specific business hypothesis; the most common misapplication is treating MVP as 'minimum features for launch' rather than as a learning instrument एमवीपी (रीज़) एक नए उत्पाद का संस्करण है जो न्यूनतम प्रयास के साथ अधिकतम सीखने की अनुमति देता है - इसका उद्देश्य एक विशिष्ट व्यावसायिक परिकल्पना का परीक्षण करना है; सबसे आम गलत प्रयोग एमवीपी को एक शिक्षण उपकरण के बजाय 'लॉन्च के लिए न्यूनतम सुविधाओं' के रूप में मानना ​​है
C
MVP must include all core features of the final product vision to be considered valid वैध माने जाने के लिए एमवीपी में अंतिम उत्पाद दृष्टिकोण की सभी मुख्य विशेषताएं शामिल होनी चाहिए
D
MVP concept was created by Toyota as part of the lean manufacturing methodology एमवीपी अवधारणा टोयोटा द्वारा लीन विनिर्माण पद्धति के हिस्से के रूप में बनाई गई थी
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Eric Ries: an MVP is an experiment to test a hypothesis. Dropbox's first MVP was a demo video (no software) testing 'will people want this?' — 75,000 signups validated the hypothesis before writing a line of code. The misapplication: teams build a 'minimum viable product' of every feature in the roadmap, producing a small but complete product rather than a learning vehicle. The question should be 'what is the cheapest test of our riskiest assumption?'
व्याख्या (हिन्दी) एरिक रीज़: एमवीपी एक परिकल्पना का परीक्षण करने के लिए एक प्रयोग है। ड्रॉपबॉक्स का पहला एमवीपी एक डेमो वीडियो (कोई सॉफ्टवेयर नहीं) परीक्षण था 'क्या लोग इसे चाहेंगे?' - कोड की एक पंक्ति लिखने से पहले 75,000 साइनअप ने परिकल्पना को मान्य किया। गलत अनुप्रयोग: टीमें रोडमैप में प्रत्येक सुविधा का एक 'न्यूनतम व्यवहार्य उत्पाद' बनाती हैं, जो सीखने के साधन के बजाय एक छोटा लेकिन संपूर्ण उत्पाद तैयार करती हैं। प्रश्न यह होना चाहिए कि 'हमारी सबसे जोखिम भरी धारणा का सबसे सस्ता परीक्षण क्या है?'
578
EN + हिं Easy
GB What is 'program management' versus 'project management' in software engineering organisations?
IN सॉफ्टवेयर इंजीनियरिंग संगठनों में 'प्रोग्राम प्रबंधन' बनाम 'प्रोजेक्ट प्रबंधन' क्या है?
A
Program management manages smaller projects; project management manages larger ones कार्यक्रम प्रबंधन छोटी परियोजनाओं का प्रबंधन करता है; परियोजना प्रबंधन बड़े लोगों का प्रबंधन करता है
B
Project management delivers a specific temporary endeavour (one system, one timeframe); program management coordinates multiple related projects to achieve strategic outcomes beyond what any individual project delivers — managing interdependencies, shared resources, and combined benefits realisation परियोजना प्रबंधन एक विशिष्ट अस्थायी प्रयास (एक प्रणाली, एक समय सीमा) प्रदान करता है; कार्यक्रम प्रबंधन किसी भी व्यक्तिगत परियोजना से परे रणनीतिक परिणाम प्राप्त करने के लिए कई संबंधित परियोजनाओं का समन्वय करता है - अन्योन्याश्रयता, साझा संसाधनों और संयुक्त लाभ प्राप्ति का प्रबंधन
C
Both terms are synonymous in modern agile organisations and should be used interchangeably दोनों शब्द आधुनिक चुस्त संगठनों में पर्यायवाची हैं और इनका परस्पर उपयोग किया जाना चाहिए
D
Program management only applies to government defence programmes; commercial software uses project management कार्यक्रम प्रबंधन केवल सरकारी रक्षा कार्यक्रमों पर लागू होता है; व्यावसायिक सॉफ़्टवेयर परियोजना प्रबंधन का उपयोग करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A bank's digital transformation programme might contain 20 projects: core banking migration, mobile app rebuild, API layer, identity platform, analytics platform. Each is a project with its own team and timeline. Programme management coordinates: ensuring the API layer is ready when the mobile app needs it, managing the dependency on the identity platform across multiple projects, and reporting the combined business benefit (cost reduction, customer acquisition) to the executive sponsor.
व्याख्या (हिन्दी) एक बैंक के डिजिटल परिवर्तन कार्यक्रम में 20 परियोजनाएँ शामिल हो सकती हैं: कोर बैंकिंग माइग्रेशन, मोबाइल ऐप पुनर्निर्माण, एपीआई परत, पहचान प्लेटफ़ॉर्म, एनालिटिक्स प्लेटफ़ॉर्म। प्रत्येक अपनी टीम और टाइमलाइन वाला एक प्रोजेक्ट है। कार्यक्रम प्रबंधन समन्वय करता है: यह सुनिश्चित करना कि मोबाइल ऐप की आवश्यकता होने पर एपीआई परत तैयार है, कई परियोजनाओं में पहचान मंच पर निर्भरता का प्रबंधन करना, और कार्यकारी प्रायोजक को संयुक्त व्यावसायिक लाभ (लागत में कमी, ग्राहक अधिग्रहण) की रिपोर्ट करना।
579
EN + हिं Easy
GB What is the 'Kano model' applied to product feature prioritisation and what three feature categories does it define?
IN उत्पाद सुविधा प्राथमिकता पर लागू 'कानो मॉडल' क्या है और यह किन तीन फीचर श्रेणियों को परिभाषित करता है?
A
Kano model categorises features as: cheap, medium cost, and expensive based on implementation effort कानो मॉडल कार्यान्वयन प्रयास के आधार पर सुविधाओं को सस्ते, मध्यम लागत और महंगे के रूप में वर्गीकृत करता है
B
Kano model (Noriaki Kano) categorises features as: Basic needs (absent = dissatisfied, present = neutral — hygiene factors), Performance needs (more = more satisfied, less = less satisfied — stated requirements), and Excitement needs (absent = neutral, present = delighted — unexpected differentiators) कानो मॉडल (नोरियाकी कानो) सुविधाओं को इस प्रकार वर्गीकृत करता है: बुनियादी जरूरतें (अनुपस्थित = असंतुष्ट, वर्तमान = तटस्थ - स्वच्छता कारक), प्रदर्शन की जरूरतें (अधिक = अधिक संतुष्ट, कम = कम संतुष्ट - बताई गई आवश्यकताएं), और उत्साह की जरूरतें (अनुपस्थित = तटस्थ, वर्तमान = प्रसन्न - अप्रत्याशित विभेदक)
C
Kano model applies only to luxury consumer products, not enterprise software कानो मॉडल केवल लक्जरी उपभोक्ता उत्पादों पर लागू होता है, एंटरप्राइज़ सॉफ़्टवेयर पर नहीं
D
Kano model requires quantitative customer surveys with at least 1000 participants to be valid कानो मॉडल को वैध होने के लिए कम से कम 1000 प्रतिभागियों के साथ मात्रात्मक ग्राहक सर्वेक्षण की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kano analysis drives product strategy: basic needs (no crashes, correct data) must be perfect but won't create delight regardless of how good they are. Performance features (faster search) are proportional investments. Excitement features (unexpected delighters like one-click reorder, predictive autocomplete) create disproportionate satisfaction and competitive differentiation. The insight: overinvesting in basic needs beyond 'good enough' is waste; excitement features deliver non-linear satisfaction ROI.
व्याख्या (हिन्दी) कानो विश्लेषण उत्पाद रणनीति को संचालित करता है: बुनियादी जरूरतें (कोई क्रैश नहीं, सही डेटा) सही होनी चाहिए, लेकिन वे कितनी भी अच्छी क्यों न हों, खुशी पैदा नहीं करेंगी। प्रदर्शन सुविधाएँ (तेज़ खोज) आनुपातिक निवेश हैं। उत्साहवर्धक विशेषताएँ (अप्रत्याशित प्रसन्नता जैसे एक-क्लिक पुनः क्रम, भविष्य कहनेवाला स्वत: पूर्ण) असंगत संतुष्टि और प्रतिस्पर्धी भेदभाव पैदा करती हैं। अंतर्दृष्टि: बुनियादी जरूरतों में 'पर्याप्त रूप से अच्छा' से अधिक निवेश करना बर्बादी है; उत्साह सुविधाएँ गैर-रेखीय संतुष्टि ROI प्रदान करती हैं।
580
EN + हिं Easy
GB What is 'definition of ready' (DoR) in Scrum and what investment does a well-defined DoR protect?
IN स्क्रम में 'तैयार की परिभाषा' (डीओआर) क्या है और एक अच्छी तरह से परिभाषित डीओआर किस निवेश की रक्षा करता है?
A
DoR is identical to the Definition of Done but applied at the backlog level DoR, Done की परिभाषा के समान है लेकिन इसे बैकलॉग स्तर पर लागू किया जाता है
B
DoR specifies criteria a backlog item must meet before entering a sprint (clear acceptance criteria, estimated, dependencies resolved, design mockups attached) — protecting the sprint planning investment by ensuring stories are sprint-ready, preventing half-understood stories from consuming sprint planning time डीओआर उन मानदंडों को निर्दिष्ट करता है जिन्हें बैकलॉग आइटम को स्प्रिंट में प्रवेश करने से पहले पूरा करना होगा (स्पष्ट स्वीकृति मानदंड, अनुमान, निर्भरताएं हल, डिजाइन मॉकअप संलग्न) - यह सुनिश्चित करके स्प्रिंट योजना निवेश की रक्षा करना कि कहानियां स्प्रिंट-तैयार हैं, आधी समझी गई कहानियों को स्प्रिंट योजना समय लेने से रोकना
C
DoR is only used in SAFe; standard Scrum Guide does not reference it DoR का उपयोग केवल SAFe में किया जाता है; मानक स्क्रम गाइड इसका संदर्भ नहीं देता है
D
DoR requires all stories to have full technical design documentation before sprint entry DoR को स्प्रिंट प्रविष्टि से पहले सभी कहानियों के लिए पूर्ण तकनीकी डिज़ाइन दस्तावेज़ीकरण की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without DoR, teams begin sprints with stories that turn out to be undefined ('what exactly does the user need to see?'), have unresolved dependencies ('we can't build this until the API team finishes X'), or are too large ('this is actually 3 stories'). These discoveries mid-sprint waste the sprint and create frustration. DoR shifts backlog refinement to before sprint planning, making planning efficient and sprint commitments credible.
व्याख्या (हिन्दी) डीओआर के बिना, टीमें उन कहानियों के साथ दौड़ शुरू करती हैं जो अपरिभाषित होती हैं ('उपयोगकर्ता को वास्तव में क्या देखने की ज़रूरत है?'), जिनकी निर्भरताएं अनसुलझी हैं ('हम इसे तब तक नहीं बना सकते जब तक एपीआई टीम एक्स खत्म नहीं कर लेती'), या बहुत बड़ी हैं ('यह वास्तव में 3 कहानियां हैं')। स्प्रिंट के बीच में ये खोजें स्प्रिंट को बर्बाद कर देती हैं और निराशा पैदा करती हैं। डीओआर ने बैकलॉग शोधन को स्प्रिंट योजना से पहले स्थानांतरित कर दिया है, जिससे योजना कुशल और स्प्रिंट प्रतिबद्धताएं विश्वसनीय हो गई हैं।
581
EN + हिं Medium
GB What is the 'minimal marketable feature' (MMF) concept and how does it differ from an MVP?
IN 'न्यूनतम विपणन योग्य सुविधा' (एमएमएफ) अवधारणा क्या है और यह एमवीपी से कैसे भिन्न है?
A
MMF and MVP are identical concepts from different agile frameworks एमएमएफ और एमवीपी विभिन्न चुस्त ढांचे से समान अवधारणाएं हैं
B
MMF is the smallest feature increment that delivers genuine market value and can be independently released to customers; MVP tests a hypothesis about whether to build; MMF is the smallest unit of buildable value assuming the decision to build has already been made and validated एमएमएफ सबसे छोटी सुविधा वृद्धि है जो वास्तविक बाजार मूल्य प्रदान करती है और ग्राहकों को स्वतंत्र रूप से जारी की जा सकती है; एमवीपी निर्माण करना है या नहीं इसके बारे में एक परिकल्पना का परीक्षण करता है; एमएमएफ निर्माण योग्य मूल्य की सबसे छोटी इकाई है, यह मानते हुए कि निर्माण का निर्णय पहले ही किया जा चुका है और मान्य किया जा चुका है
C
MMF requires a minimum of 10 user stories per feature to qualify as marketable एमएमएफ को विपणन योग्य के रूप में अर्हता प्राप्त करने के लिए प्रति फीचर न्यूनतम 10 उपयोगकर्ता कहानियों की आवश्यकता होती है
D
MMF is a financial metric measuring minimum acceptable revenue per feature release एमएमएफ एक वित्तीय मीट्रिक है जो प्रति फीचर रिलीज न्यूनतम स्वीकार्य राजस्व मापता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) After an MVP validates market fit, MMFs define the delivery increments. Example: validated that users want expense reporting. MMF 1: submit an expense report. MMF 2: approve/reject expense reports. MMF 3: export to accounting system. Each MMF is independently valuable to a user segment — unlike user stories (technical slices), MMFs are business-valuable releases that generate real user value upon deployment.
व्याख्या (हिन्दी) एमवीपी द्वारा बाजार में फिट होने की पुष्टि करने के बाद, एमएमएफ डिलीवरी वृद्धि को परिभाषित करते हैं। उदाहरण: मान्य किया गया कि उपयोगकर्ता व्यय रिपोर्टिंग चाहते हैं। एमएमएफ 1: व्यय रिपोर्ट जमा करें। एमएमएफ 2: व्यय रिपोर्ट को स्वीकृत/अस्वीकार करें। एमएमएफ 3: लेखा प्रणाली में निर्यात। प्रत्येक एमएमएफ उपयोगकर्ता वर्ग के लिए स्वतंत्र रूप से मूल्यवान है - उपयोगकर्ता कहानियों (तकनीकी स्लाइस) के विपरीत, एमएमएफ व्यवसाय-मूल्यवान रिलीज हैं जो तैनाती पर वास्तविक उपयोगकर्ता मूल्य उत्पन्न करते हैं।
582
EN + हिं Easy
GB What is the 'proof of concept' phase in Waterfall and what architectural risk does it specifically mitigate?
IN वॉटरफ़ॉल में 'अवधारणा का प्रमाण' चरण क्या है और यह विशेष रूप से किस वास्तुशिल्प जोखिम को कम करता है?
A
Proof of concept verifies that the team has enough developers to complete the project अवधारणा का प्रमाण यह सत्यापित करता है कि टीम के पास परियोजना को पूरा करने के लिए पर्याप्त डेवलपर्स हैं
B
A PoC is a small-scale technical investigation proving the feasibility of a critical architecture or algorithm before committing to full design — specifically mitigating the risk of discovering architectural infeasibility after expensive design work is completed पीओसी एक छोटे पैमाने की तकनीकी जांच है जो पूर्ण डिजाइन के लिए प्रतिबद्ध होने से पहले एक महत्वपूर्ण वास्तुकला या एल्गोरिदम की व्यवहार्यता साबित करती है - विशेष रूप से महंगे डिजाइन कार्य पूरा होने के बाद वास्तुशिल्प अक्षमता की खोज के जोखिम को कम करती है।
C
Proof of concept phases are only used in research projects, not commercial software development अवधारणा चरणों का प्रमाण केवल अनुसंधान परियोजनाओं में उपयोग किया जाता है, वाणिज्यिक सॉफ्टवेयर विकास में नहीं
D
PoC phases replace the design phase entirely in modified Waterfall models पीओसी चरण पूरी तरह से संशोधित वॉटरफॉल मॉडल में डिजाइन चरण को प्रतिस्थापित करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without PoC, a Waterfall team designs a system assuming a required real-time calculation is achievable at the specified latency, only to discover during implementation that it requires 10x more computation than available. The PoC (taking 2-3 weeks) would have discovered this infeasibility before 6 months of design work was wasted. Boehm's Spiral model formalises this as risk-resolution prototyping in every cycle.
व्याख्या (हिन्दी) पीओसी के बिना, वॉटरफ़ॉल टीम एक सिस्टम डिज़ाइन करती है जिसमें यह माना जाता है कि आवश्यक वास्तविक समय की गणना निर्दिष्ट विलंबता पर प्राप्त की जा सकती है, केवल कार्यान्वयन के दौरान पता चलता है कि इसे उपलब्ध की तुलना में 10 गुना अधिक गणना की आवश्यकता होती है। पीओसी (2-3 सप्ताह का समय लेते हुए) ने 6 महीने का डिज़ाइन कार्य बर्बाद होने से पहले इस अव्यवहार्यता का पता लगा लिया होगा। बोहेम का स्पाइरल मॉडल इसे हर चक्र में जोखिम-रिज़ॉल्यूशन प्रोटोटाइप के रूप में औपचारिक रूप देता है।
583
EN + हिं Medium
GB Why does Waterfall perform well for projects with low requirement volatility but poorly for innovative products?
IN वाटरफॉल कम आवश्यकता वाली अस्थिरता वाली परियोजनाओं के लिए अच्छा प्रदर्शन क्यों करता है लेकिन नवीन उत्पादों के लिए खराब प्रदर्शन करता है?
A
Waterfall performs poorly for all project types because it was designed in 1970 वॉटरफ़ॉल सभी प्रोजेक्ट प्रकारों के लिए ख़राब प्रदर्शन करता है क्योंकि इसे 1970 में डिज़ाइन किया गया था
B
Low volatility projects (replacing a known system, implementing a known algorithm) allow complete upfront specification — Waterfall's assumption holds; innovative products require user feedback to shape requirements, which Waterfall's sequential phases prevent until it's too late to change कम अस्थिरता वाली परियोजनाएं (एक ज्ञात प्रणाली को बदलना, एक ज्ञात एल्गोरिथ्म को लागू करना) पूर्ण अग्रिम विनिर्देशन की अनुमति देती हैं - वॉटरफॉल की धारणा कायम है; नवीन उत्पादों को आवश्यकताओं को आकार देने के लिए उपयोगकर्ता की प्रतिक्रिया की आवश्यकता होती है, जिसे वॉटरफॉल के अनुक्रमिक चरण तब तक रोकते हैं जब तक कि इसे बदलने में बहुत देर न हो जाए
C
Waterfall only performs well for non-software systems like construction and manufacturing वॉटरफ़ॉल केवल निर्माण और विनिर्माण जैसे गैर-सॉफ़्टवेयर सिस्टम के लिए अच्छा प्रदर्शन करता है
D
Innovative products always require more developers, making Waterfall impractical due to coordination overhead नवीन उत्पादों को हमेशा अधिक डेवलपर्स की आवश्यकता होती है, जिससे ओवरहेड समन्वय के कारण वॉटरफॉल अव्यवहारिक हो जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hospital bed management replacement: existing system well-documented, regulations fixed, users' workflow known, integration points defined — Waterfall's sequential phases match this perfectly. Consumer social feature: 'users will engage with X' is a hypothesis, not a known requirement — without iterative user testing, the Waterfall team builds X exhaustively and discovers upon release that users prefer Y. Innovative products require empirical validation that Waterfall's structure precludes.
व्याख्या (हिन्दी) अस्पताल के बिस्तर प्रबंधन प्रतिस्थापन: मौजूदा प्रणाली अच्छी तरह से प्रलेखित है, नियम तय किए गए हैं, उपयोगकर्ताओं के वर्कफ़्लो ज्ञात हैं, एकीकरण बिंदु परिभाषित हैं - झरना के अनुक्रमिक चरण इससे पूरी तरह मेल खाते हैं। उपभोक्ता सामाजिक सुविधा: 'उपयोगकर्ता एक्स के साथ जुड़ेंगे' एक परिकल्पना है, कोई ज्ञात आवश्यकता नहीं - पुनरावृत्त उपयोगकर्ता परीक्षण के बिना, वॉटरफॉल टीम विस्तृत रूप से एक्स का निर्माण करती है और रिलीज होने पर पता चलता है कि उपयोगकर्ता वाई को पसंद करते हैं। इनोवेटिव उत्पादों को अनुभवजन्य सत्यापन की आवश्यकता होती है जो वॉटरफॉल की संरचना को रोकता है।
584
EN + हिं Easy
GB What is 'phase gate review' in Waterfall and what decision outcome can it produce other than approval?
IN वॉटरफॉल में 'फ़ेज़ गेट समीक्षा' क्या है और यह अनुमोदन के अलावा और क्या निर्णय परिणाम दे सकता है?
A
Phase gate reviews can only produce approval or rejection (project cancellation) as outcomes चरण गेट समीक्षाएँ परिणामों के रूप में केवल अनुमोदन या अस्वीकृति (परियोजना रद्दीकरण) उत्पन्न कर सकती हैं
B
Phase gate reviews can produce: approve (proceed to next phase), conditional approval (proceed after addressing specific findings), return (redo current phase with corrections), hold (pause pending external information), or cancel (terminate the project) — multiple outcomes reflect varying risk levels चरण गेट समीक्षाएँ उत्पन्न कर सकती हैं: अनुमोदन (अगले चरण के लिए आगे बढ़ना), सशर्त अनुमोदन (विशिष्ट निष्कर्षों को संबोधित करने के बाद आगे बढ़ना), वापसी (सुधार के साथ वर्तमान चरण को फिर से करना), होल्ड करना (लंबित बाहरी जानकारी को रोकना), या रद्द करना (परियोजना को समाप्त करना) - कई परिणाम अलग-अलग जोखिम स्तरों को दर्शाते हैं
C
Phase gate reviews are informal meetings with no binding authority over project continuation चरण गेट समीक्षाएँ अनौपचारिक बैठकें होती हैं जिनमें परियोजना की निरंतरता पर कोई बाध्यकारी प्राधिकार नहीं होता है
D
Phase gate reviews are only conducted by external auditors, never by internal management चरण गेट समीक्षाएँ केवल बाहरी लेखा परीक्षकों द्वारा आयोजित की जाती हैं, आंतरिक प्रबंधन द्वारा कभी नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Stage-gate process (Cooper) formalises these options. Conditional approval is the most common practical outcome: 'proceed to design, but resolve the ambiguity in requirement 47 and 89 within 2 weeks.' Hold is used when a key external dependency (regulatory approval, API availability from third-party) is pending. Return is used when the phase deliverable is inadequate — common when requirements are missing testable acceptance criteria.
व्याख्या (हिन्दी) स्टेज-गेट प्रक्रिया (कूपर) इन विकल्पों को औपचारिक बनाती है। सशर्त अनुमोदन सबसे आम व्यावहारिक परिणाम है: 'डिजाइन के लिए आगे बढ़ें, लेकिन आवश्यकता 47 और 89 में अस्पष्टता को 2 सप्ताह के भीतर हल करें।' होल्ड का उपयोग तब किया जाता है जब एक प्रमुख बाहरी निर्भरता (नियामक अनुमोदन, तीसरे पक्ष से एपीआई उपलब्धता) लंबित होती है। रिटर्न का उपयोग तब किया जाता है जब वितरण योग्य चरण अपर्याप्त होता है - सामान्य जब आवश्यकताओं में परीक्षण योग्य स्वीकृति मानदंड नहीं होते हैं।
585
EN + हिं Easy
GB What is 'independent verification and validation' (IV&V) in Waterfall projects and what independence benefit does it provide?
IN झरना परियोजनाओं में 'स्वतंत्र सत्यापन और सत्यापन' (IV&V) क्या है और यह क्या स्वतंत्रता लाभ प्रदान करता है?
A
IV&V means the same team that builds the software also tests it IV&V का मतलब है कि जो टीम सॉफ्टवेयर बनाती है वही उसका परीक्षण भी करती है
B
IV&V uses an independent third party to verify (checking the product meets specifications) and validate (checking the product meets user needs) — independence eliminates the conflict of interest where developers are reluctant to report problems in their own work IV&V सत्यापित करने के लिए एक स्वतंत्र तृतीय पक्ष का उपयोग करता है (यह जांचना कि उत्पाद विशिष्टताओं के अनुरूप है) और मान्य करना (यह जांचना कि उत्पाद उपयोगकर्ता की आवश्यकताओं को पूरा करता है) - स्वतंत्रता हितों के टकराव को समाप्त करती है जहां डेवलपर्स अपने काम में समस्याओं की रिपोर्ट करने के लिए अनिच्छुक होते हैं
C
IV&V is only mandated for military projects; commercial projects always use internal testing IV&V केवल सैन्य परियोजनाओं के लिए अनिवार्य है; व्यावसायिक परियोजनाएँ हमेशा आंतरिक परीक्षण का उपयोग करती हैं
D
IV&V doubles the testing cost with no measurable quality benefit over internal testing IV&V आंतरिक परीक्षण की तुलना में कोई मापने योग्य गुणवत्ता लाभ नहीं होने के कारण परीक्षण लागत को दोगुना कर देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) NASA, FAA, FDA, and DOD mandate IV&V for safety-critical systems. The cognitive bias problem: developers who built a system are subject to confirmation bias when testing it — they test the paths they know work, not the ones they're uncertain about. An independent team with no ego investment in the design actively hunts for failures. Research consistently shows IV&V finds a higher proportion of critical defects than internal testing alone.
व्याख्या (हिन्दी) नासा, एफएए, एफडीए और डीओडी सुरक्षा-महत्वपूर्ण प्रणालियों के लिए IV&V को अनिवार्य करते हैं। संज्ञानात्मक पूर्वाग्रह समस्या: जिन डेवलपर्स ने एक सिस्टम बनाया है, वे इसका परीक्षण करते समय पुष्टिकरण पूर्वाग्रह के अधीन होते हैं - वे उन रास्तों का परीक्षण करते हैं जिनके बारे में वे जानते हैं कि वे काम करते हैं, न कि उन रास्तों का परीक्षण करते हैं जिनके बारे में वे अनिश्चित हैं। डिज़ाइन में अहंकार रहित निवेश वाली एक स्वतंत्र टीम सक्रिय रूप से विफलताओं की तलाश करती है। अनुसंधान लगातार दिखाता है कि IV&V में अकेले आंतरिक परीक्षण की तुलना में गंभीर दोषों का अनुपात अधिक पाया गया है।
571–585 of 647