2641

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 में खोजा होगा। उच्च जोखिम वाले तकनीकी अज्ञात (अप्रमाणित एल्गोरिदम, प्रदर्शन-महत्वपूर्ण पथ, तृतीय-पक्ष एकीकरण बिंदु) को किसी भी महत्वपूर्ण वास्तुकला प्रतिबद्धता से पहले प्रोटोटाइप किया जाना चाहिए।

2642

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 साइनअप ने परिकल्पना को मान्य किया। गलत अनुप्रयोग: टीमें रोडमैप में प्रत्येक सुविधा का एक 'न्यूनतम व्यवहार्य उत्पाद' बनाती हैं, जो सीखने के साधन के बजाय एक छोटा लेकिन संपूर्ण उत्पाद तैयार करती हैं। प्रश्न यह होना चाहिए कि 'हमारी सबसे जोखिम भरी धारणा का सबसे सस्ता परीक्षण क्या है?'

2643

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 परियोजनाएँ शामिल हो सकती हैं: कोर बैंकिंग माइग्रेशन, मोबाइल ऐप पुनर्निर्माण, एपीआई परत, पहचान प्लेटफ़ॉर्म, एनालिटिक्स प्लेटफ़ॉर्म। प्रत्येक अपनी टीम और टाइमलाइन वाला एक प्रोजेक्ट है। कार्यक्रम प्रबंधन समन्वय करता है: यह सुनिश्चित करना कि मोबाइल ऐप की आवश्यकता होने पर एपीआई परत तैयार है, कई परियोजनाओं में पहचान मंच पर निर्भरता का प्रबंधन करना, और कार्यकारी प्रायोजक को संयुक्त व्यावसायिक लाभ (लागत में कमी, ग्राहक अधिग्रहण) की रिपोर्ट करना।

2644

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 प्रदान करती हैं।

2645

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 कहानियां हैं')। स्प्रिंट के बीच में ये खोजें स्प्रिंट को बर्बाद कर देती हैं और निराशा पैदा करती हैं। डीओआर ने बैकलॉग शोधन को स्प्रिंट योजना से पहले स्थानांतरित कर दिया है, जिससे योजना कुशल और स्प्रिंट प्रतिबद्धताएं विश्वसनीय हो गई हैं।

2646

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: लेखा प्रणाली में निर्यात। प्रत्येक एमएमएफ उपयोगकर्ता वर्ग के लिए स्वतंत्र रूप से मूल्यवान है - उपयोगकर्ता कहानियों (तकनीकी स्लाइस) के विपरीत, एमएमएफ व्यवसाय-मूल्यवान रिलीज हैं जो तैनाती पर वास्तविक उपयोगकर्ता मूल्य उत्पन्न करते हैं।

2647

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 महीने का डिज़ाइन कार्य बर्बाद होने से पहले इस अव्यवहार्यता का पता लगा लिया होगा। बोहेम का स्पाइरल मॉडल इसे हर चक्र में जोखिम-रिज़ॉल्यूशन प्रोटोटाइप के रूप में औपचारिक रूप देता है।

2648

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.

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

2649

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 सप्ताह के भीतर हल करें।' होल्ड का उपयोग तब किया जाता है जब एक प्रमुख बाहरी निर्भरता (नियामक अनुमोदन, तीसरे पक्ष से एपीआई उपलब्धता) लंबित होती है। रिटर्न का उपयोग तब किया जाता है जब वितरण योग्य चरण अपर्याप्त होता है - सामान्य जब आवश्यकताओं में परीक्षण योग्य स्वीकृति मानदंड नहीं होते हैं।

2650

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 में अकेले आंतरिक परीक्षण की तुलना में गंभीर दोषों का अनुपात अधिक पाया गया है।

2651

EN + हिं Easy

GB What is 'software baseline' in Waterfall configuration management and what are the three standard baselines?

IN वॉटरफॉल कॉन्फ़िगरेशन प्रबंधन में 'सॉफ़्टवेयर बेसलाइन' क्या है और तीन मानक बेसलाइन क्या हैं?

A

A software baseline is a performance benchmark measured at project completion सॉफ़्टवेयर बेसलाइन एक प्रदर्शन बेंचमार्क है जिसे प्रोजेक्ट पूरा होने पर मापा जाता है

B

A software baseline is a formally reviewed and approved configuration item serving as a reference for future development — the three standard baselines: Functional Baseline (approved system requirements), Allocated Baseline (approved design specifications), Product Baseline (approved product at delivery) एक सॉफ़्टवेयर बेसलाइन एक औपचारिक रूप से समीक्षा की गई और अनुमोदित कॉन्फ़िगरेशन आइटम है जो भविष्य के विकास के लिए एक संदर्भ के रूप में कार्य करती है - तीन मानक बेसलाइन: कार्यात्मक बेसलाइन (अनुमोदित सिस्टम आवश्यकताएँ), आवंटित बेसलाइन (अनुमोदित डिज़ाइन विनिर्देश), उत्पाद बेसलाइन (डिलीवरी पर अनुमोदित उत्पाद)

C

Baseline refers only to the initial codebase commit before any development begins बेसलाइन किसी भी विकास के शुरू होने से पहले केवल प्रारंभिक कोडबेस प्रतिबद्धता को संदर्भित करता है

D

All three baselines are established simultaneously at project initiation before development begins विकास शुरू होने से पहले परियोजना की शुरुआत में सभी तीन आधार रेखाएं एक साथ स्थापित की जाती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) IEEE/ANSI configuration management standard defines these baselines as control points: Functional baseline (post-SRR/requirements review) — changes require formal impact analysis; Allocated baseline (post-PDR/design review) — design is controlled; Product baseline (post-acceptance) — the delivered system. Between baselines, informal change is possible; once a baseline is established, formal change control governs all subsequent changes.

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

2652

EN + हिं Easy

GB In Waterfall projects, what is the 'system requirements review' (SRR) and what exit criteria should it enforce?

IN वॉटरफ़ॉल परियोजनाओं में, 'सिस्टम आवश्यकताओं की समीक्षा' (एसआरआर) क्या है और इसे कौन से निकास मानदंड लागू करने चाहिए?

A

SRR is an informal meeting where stakeholders casually discuss project progress एसआरआर एक अनौपचारिक बैठक है जहां हितधारक परियोजना की प्रगति पर आकस्मिक रूप से चर्चा करते हैं

B

SRR is a formal review assessing whether system requirements are complete, consistent, and testable — exit criteria: all requirements have unique IDs, are individually testable, no internal contradictions exist, regulatory requirements are traceable, and customer has formally accepted the SRS एसआरआर एक औपचारिक समीक्षा है जो यह आकलन करती है कि सिस्टम आवश्यकताएँ पूर्ण, सुसंगत और परीक्षण योग्य हैं या नहीं - निकास मानदंड: सभी आवश्यकताओं में अद्वितीय आईडी हैं, व्यक्तिगत रूप से परीक्षण योग्य हैं, कोई आंतरिक विरोधाभास मौजूद नहीं है, नियामक आवश्यकताओं का पता लगाया जा सकता है, और ग्राहक ने औपचारिक रूप से एसआरएस स्वीकार कर लिया है

C

SRR exit criteria only require manager signature; no technical verification is needed एसआरआर निकास मानदंड के लिए केवल प्रबंधक के हस्ताक्षर की आवश्यकता होती है; किसी तकनीकी सत्यापन की आवश्यकता नहीं है

D

SRR is conducted only for systems with hardware components; pure software projects skip it एसआरआर केवल हार्डवेयर घटकों वाले सिस्टम के लिए आयोजित किया जाता है; शुद्ध सॉफ्टवेयर प्रोजेक्ट इसे छोड़ देते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SRR exit criteria are the quality gate for the most expensive defect prevention opportunity. Untestable requirements ('system shall be user-friendly') passing SRR will persist through design and implementation, only becoming problems during acceptance testing. 'Formally accepted by customer' is critical — the SRS serves as the contractual basis for later acceptance testing; customer signature creates alignment on what 'done' means.

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

2653

EN + हिं Easy

GB What is 'requirements traceability matrix' (RTM) maintenance during Waterfall implementation and why does it degrade?

IN वॉटरफ़ॉल कार्यान्वयन के दौरान 'आवश्यकताएँ ट्रैसेबिलिटी मैट्रिक्स' (आरटीएम) रखरखाव क्या है और यह ख़राब क्यों होता है?

A

RTM maintenance is fully automated by modern ALM tools and requires no manual effort आरटीएम रखरखाव आधुनिक एएलएम उपकरणों द्वारा पूरी तरह से स्वचालित है और इसके लिए किसी मैन्युअल प्रयास की आवश्यकता नहीं है

B

RTM maintenance tracks which requirements are implemented by which code modules and tested by which test cases throughout implementation — it degrades when: code changes are not reflected in RTM updates, scope changes occur without updating traces, and maintenance is deprioritised under schedule pressure आरटीएम रखरखाव ट्रैक करता है कि किन आवश्यकताओं को किस कोड मॉड्यूल द्वारा कार्यान्वित किया जाता है और पूरे कार्यान्वयन के दौरान किन परीक्षण मामलों द्वारा परीक्षण किया जाता है - यह तब खराब हो जाता है जब: कोड परिवर्तन आरटीएम अपडेट में प्रतिबिंबित नहीं होते हैं, स्कोप परिवर्तन ट्रेस को अपडेट किए बिना होते हैं, और शेड्यूल दबाव के तहत रखरखाव को प्राथमिकता नहीं दी जाती है

C

RTM only needs to be updated at project completion, not during ongoing development आरटीएम को केवल परियोजना के पूरा होने पर अद्यतन करने की आवश्यकता है, चल रहे विकास के दौरान नहीं

D

RTM degradation only occurs in projects using manually managed spreadsheets आरटीएम गिरावट केवल मैन्युअल रूप से प्रबंधित स्प्रेडशीट का उपयोग करने वाली परियोजनाओं में होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) RTM maintenance requires discipline that deteriorates under schedule pressure. Teams skip updates when 'just a small code change' seems not worth the overhead. Over months, the RTM diverges from reality. At system testing, the stale RTM incorrectly reports full requirement coverage — giving false confidence. This is why safety-critical projects (medical, aerospace) mandate regular RTM audits and make maintainer accountability explicit.

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

2654

EN + हिं Medium

GB What is the 'build and fix' model and why is it sometimes considered a degenerate case of Waterfall?

IN 'बिल्ड एंड फिक्स' मॉडल क्या है और इसे कभी-कभी वाटरफॉल का विकृत मामला क्यों माना जाता है?

A

Build and fix is an advanced iterative model used only for prototyping बिल्ड एंड फिक्स एक उन्नत पुनरावृत्त मॉडल है जिसका उपयोग केवल प्रोटोटाइप के लिए किया जाता है

B

Build and fix skips planning and specification — developers code until something works, then fix problems as they appear; it's a degenerate Waterfall because it omits the analysis and design phases that give Waterfall its structure, producing the ad-hoc development the software crisis highlighted स्किप प्लानिंग और स्पेसिफिकेशन बनाएं और ठीक करें - डेवलपर्स कुछ काम करने तक कोड करते हैं, फिर समस्याएं दिखाई देने पर उन्हें ठीक करते हैं; यह एक पतित झरना है क्योंकि यह उस विश्लेषण और डिजाइन चरणों को छोड़ देता है जो झरने को इसकी संरचना प्रदान करता है, जिससे सॉफ्टवेयर संकट पर प्रकाश डाला गया तदर्थ विकास होता है।

C

Build and fix model is scientifically proven to produce the highest quality code for small projects बिल्ड और फिक्स मॉडल वैज्ञानिक रूप से छोटी परियोजनाओं के लिए उच्चतम गुणवत्ता वाले कोड का उत्पादन करने के लिए सिद्ध है

D

Build and fix and iterative development are equivalent terms describing the same development practice निर्माण और सुधार तथा पुनरावृत्तीय विकास समान विकास अभ्यास का वर्णन करने वाले समतुल्य शब्द हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Build and fix is the 'natural' way novice programmers develop: code something, test it manually, fix what doesn't work, repeat. It produces unmaintainable code because: no design means no modularity; fixing one bug often breaks another; no tests mean regressions are undetected. Barry Boehm identified it as the baseline from which all structured process models improve. It remains common in small scripts, research code, and time-pressured hobbyist projects.

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

2655

EN + हिं Easy

GB What is 'software cost tracking' during Waterfall execution and what is 'earned value management' (EVM)?

IN वॉटरफ़ॉल निष्पादन के दौरान 'सॉफ़्टवेयर लागत ट्रैकिंग' क्या है और 'अर्जित मूल्य प्रबंधन' (ईवीएम) क्या है?

A

EVM is a technique for estimating future salaries of software developers ईवीएम सॉफ्टवेयर डेवलपर्स के भविष्य के वेतन का अनुमान लगाने की एक तकनीक है

B

EVM integrates scope, schedule, and cost — key metrics: Planned Value (budgeted work), Earned Value (value of work completed), Actual Cost (money spent); Schedule Variance = EV-PV; Cost Variance = EV-AC — enabling objective project health assessment rather than subjective 'percent complete' estimates ईवीएम कार्यक्षेत्र, शेड्यूल और लागत को एकीकृत करता है - प्रमुख मेट्रिक्स: नियोजित मूल्य (बजटीय कार्य), अर्जित मूल्य (पूर्ण कार्य का मूल्य), वास्तविक लागत (खर्च किया गया धन); शेड्यूल वेरिएंस = ईवी-पीवी; लागत भिन्नता = ईवी-एसी - व्यक्तिपरक 'पूर्ण प्रतिशत' अनुमानों के बजाय वस्तुनिष्ठ परियोजना स्वास्थ्य मूल्यांकन को सक्षम करना

C

EVM is only used in construction projects; software projects use story points for tracking ईवीएम का उपयोग केवल निर्माण परियोजनाओं में किया जाता है; सॉफ़्टवेयर प्रोजेक्ट ट्रैकिंग के लिए कहानी बिंदुओं का उपयोग करते हैं

D

EVM requires the project budget to be fixed; it cannot be used in projects with variable funding ईवीएम के लिए परियोजना बजट तय करना आवश्यक है; इसका उपयोग वेरिएबल फंडिंग वाली परियोजनाओं में नहीं किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) EVM's power is detecting problems early: if after 3 months of a 12-month project, Planned Value = $300K (should have spent), Earned Value = $200K (worth of work done), Actual Cost = $350K — then Schedule Performance Index = 0.67 (33% behind schedule) and Cost Performance Index = 0.57 (spending $1.75 for every $1 of value). These objective metrics trigger corrective action before 'we think we're on track' becomes 'we're 6 months late.'

व्याख्या (हिन्दी) ईवीएम की शक्ति समस्याओं का शीघ्र पता लगा रही है: यदि 12-महीने की परियोजना के 3 महीने के बाद, नियोजित मूल्य = $300K (खर्च किया जाना चाहिए), अर्जित मूल्य = $200K (किए गए कार्य के लायक), वास्तविक लागत = $350K - तो शेड्यूल प्रदर्शन सूचकांक = 0.67 (निर्धारित समय से 33%) और लागत प्रदर्शन सूचकांक = 0.57 (मूल्य के प्रत्येक $1 के लिए $1.75 खर्च करना)। ये वस्तुनिष्ठ मेट्रिक्स सुधारात्मक कार्रवाई को ट्रिगर करते हैं इससे पहले कि 'हमें लगता है कि हम ट्रैक पर हैं' 'हम 6 महीने देर से हैं।'

Software Engineering — MCQ Practice