586

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.

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

587

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.

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

588

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.

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

589

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.

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

590

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 महीने देर से हैं।'

591

EN + हिं Easy

GB What is 'configuration management plan' (CMP) in Waterfall and what four activities must it describe?

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

A

CMP describes only the version numbering scheme for the software product सीएमपी सॉफ्टवेयर उत्पाद के लिए केवल संस्करण क्रमांकन योजना का वर्णन करता है

B

CMP describes how configuration management will be practised: Configuration identification (what items are under CM), Configuration control (how changes are proposed, evaluated, approved), Status accounting (recording and reporting of CM information), and Configuration audits (verifying CM records match actual items) सीएमपी वर्णन करता है कि कॉन्फ़िगरेशन प्रबंधन का अभ्यास कैसे किया जाएगा: कॉन्फ़िगरेशन पहचान (सीएम के अंतर्गत कौन से आइटम हैं), कॉन्फ़िगरेशन नियंत्रण (कैसे परिवर्तन प्रस्तावित, मूल्यांकन, अनुमोदित किए जाते हैं), स्थिति लेखांकन (सीएम जानकारी की रिकॉर्डिंग और रिपोर्टिंग), और कॉन्फ़िगरेशन ऑडिट (सीएम रिकॉर्ड का सत्यापन वास्तविक आइटम से मेल खाता है)

C

CMP is optional documentation in Waterfall; it is only mandatory for contracts over $10M वॉटरफॉल में सीएमपी वैकल्पिक दस्तावेज है; यह केवल $10 मिलियन से अधिक के अनुबंधों के लिए अनिवार्य है

D

CMP is identical to the project management plan and covers all aspects of project delivery सीएमपी परियोजना प्रबंधन योजना के समान है और परियोजना वितरण के सभी पहलुओं को शामिल करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) IEEE Std 828 specifies exactly these four activities. Configuration identification: assign unique identifiers to all controlled artefacts (SRS v2.1, Design Spec v3.0). Control: change requests go through CCB before any baseline is modified. Status accounting: the CM database tracks every version, change reason, and approver. Audits: functional audit verifies the product satisfies requirements; physical audit verifies delivered items match documentation.

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

592

EN + हिं Easy

GB What is 'schedule risk' specific to Waterfall projects and what monitoring metric best detects it early?

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

A

Schedule risk in Waterfall is caused only by developer illness and absence वॉटरफ़ॉल में शेड्यूल जोखिम केवल डेवलपर की बीमारी और अनुपस्थिति के कारण होता है

B

Waterfall's most significant schedule risk is 'the first 90% takes 90% of the time; the last 10% takes the other 90%' — monitored by tracking planned vs actual milestone completion, design review findings (unresolved issues), and dependency completion status rather than subjective percent-complete estimates झरने का सबसे महत्वपूर्ण शेड्यूल जोखिम यह है कि 'पहले 90% में 90% समय लगता है; अंतिम 10% अन्य 90% लेता है' - व्यक्तिपरक प्रतिशत-पूर्ण अनुमानों के बजाय योजनाबद्ध बनाम वास्तविक मील का पत्थर पूरा होने, डिज़ाइन समीक्षा निष्कर्ष (अनसुलझे मुद्दे), और निर्भरता पूर्णता स्थिति पर नज़र रखने के द्वारा निगरानी की जाती है

C

Schedule risk in Waterfall is best monitored by daily developer standups वॉटरफॉल में शेड्यूल जोखिम की निगरानी दैनिक डेवलपर स्टैंडअप द्वारा सबसे अच्छी तरह की जाती है

D

Waterfall has no schedule risk because phase durations are fixed at project initiation झरने का कोई शेड्यूल जोखिम नहीं है क्योंकि चरण की अवधि परियोजना की शुरुआत में तय की जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The '90-90 rule' (Hofstadter's Law variation) reflects that integration and late-discovered issues consume disproportionate time. Objective leading indicators: 'How many open issues from the last review are unresolved?' and 'How many dependencies are behind schedule?' are better predictors than 'We're 70% done' (which developers say from 30% through to 95% of projects). Tracking open issues trends reveals whether the project is converging or diverging.

व्याख्या (हिन्दी) '90-90 नियम' (हॉफस्टैटर का कानून भिन्नता) दर्शाता है कि एकीकरण और देर से खोजे गए मुद्दों में अनुपातहीन समय लगता है। वस्तुनिष्ठ अग्रणी संकेतक: 'पिछली समीक्षा के कितने खुले मुद्दे अनसुलझे हैं?' और 'कितनी निर्भरताएँ निर्धारित समय से पीछे हैं?' 'हम 70% काम पूरा कर चुके हैं' (डेवलपर्स का कहना है कि 30% से लेकर 95% तक परियोजनाएं पूरी हो चुकी हैं) की तुलना में बेहतर भविष्यवक्ता हैं। खुले मुद्दों के रुझानों पर नज़र रखने से पता चलता है कि परियोजना अभिसरण कर रही है या विचलन कर रही है।

593

EN + हिं Medium

GB What makes Waterfall particularly suited for 'fixed-price fixed-scope' government contracts?

IN वॉटरफ़ॉल को 'निश्चित-मूल्य निश्चित-क्षेत्र' सरकारी अनुबंधों के लिए विशेष रूप से उपयुक्त क्या बनाता है?

A

Government contracts require Waterfall by law in all jurisdictions सरकारी अनुबंधों के लिए सभी न्यायक्षेत्रों में कानून द्वारा वॉटरफॉल की आवश्यकता होती है

B

Waterfall's upfront specification of complete requirements enables precise cost and schedule estimation before contract award — the contractual obligation (deliver X by date Y for $Z) maps directly to Waterfall's sequential phases with measurable phase-exit deliverables that can be contractually defined वॉटरफ़ॉल की संपूर्ण आवश्यकताओं का अग्रिम विनिर्देश अनुबंध पुरस्कार से पहले सटीक लागत और शेड्यूल अनुमान को सक्षम बनाता है - संविदात्मक दायित्व ($Z के लिए दिनांक Y द्वारा X वितरित करना) मापने योग्य चरण-निकास डिलिवरेबल्स के साथ सीधे वॉटरफ़ॉल के अनुक्रमिक चरणों को मैप करता है जिसे अनुबंधात्मक रूप से परिभाषित किया जा सकता है

C

Government contracts only use Waterfall because government employees lack agile training सरकारी अनुबंध केवल वॉटरफॉल का उपयोग करते हैं क्योंकि सरकारी कर्मचारियों के पास चुस्त प्रशिक्षण का अभाव है

D

Fixed-price contracts always produce better software than time-and-materials regardless of methodology कार्यप्रणाली की परवाह किए बिना निश्चित मूल्य अनुबंध हमेशा समय और सामग्री की तुलना में बेहतर सॉफ्टवेयर का उत्पादन करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Procurement law in many jurisdictions (FAR in the US) requires competition on a fixed specification to ensure fairness. Waterfall aligns: define requirements (Statement of Work), solicit bids (RFP), award to best value, execute sequentially, deliver. The contractual milestones (CDRLs — Contract Data Requirements Lists) map to Waterfall deliverables. Agile's variable scope makes this competitive procurement difficult, though modern contracting is evolving to accommodate iterative approaches.

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

594

EN + हिं Easy

GB What is 'technical review' in Waterfall and what three types serve different quality purposes?

IN वॉटरफॉल में 'तकनीकी समीक्षा' क्या है और कौन से तीन प्रकार विभिन्न गुणवत्ता उद्देश्यों को पूरा करते हैं?

A

All technical reviews in Waterfall have identical structure and purpose वॉटरफॉल में सभी तकनीकी समीक्षाओं की संरचना और उद्देश्य समान हैं

B

Technical reviews come in three types: Management review (project status, resource allocation), Technical review (evaluating technical implementation against specifications), and Audit (verifying process compliance, configuration records) — each serves a different quality assurance function तकनीकी समीक्षाएँ तीन प्रकार की होती हैं: प्रबंधन समीक्षा (परियोजना की स्थिति, संसाधन आवंटन), तकनीकी समीक्षा (विनिर्देशों के विरुद्ध तकनीकी कार्यान्वयन का मूल्यांकन), और ऑडिट (प्रक्रिया अनुपालन, कॉन्फ़िगरेशन रिकॉर्ड का सत्यापन) - प्रत्येक एक अलग गुणवत्ता आश्वासन कार्य करता है

C

Technical reviews are only conducted at project completion to evaluate the final product तकनीकी समीक्षाएँ केवल अंतिम उत्पाद का मूल्यांकन करने के लिए परियोजना के पूरा होने पर आयोजित की जाती हैं

D

Only external consultants can conduct valid technical reviews; internal reviews are always biased केवल बाहरी सलाहकार ही वैध तकनीकी समीक्षा कर सकते हैं; आंतरिक समीक्षाएँ हमेशा पक्षपातपूर्ण होती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) IEEE 1028 (Software Reviews and Audits) defines these types. Management reviews: 'are we on schedule? do we have enough resources?' Technical reviews: 'does this design correctly implement requirement 47? is this API design consistent with the architecture?' Audits: 'did the team follow the change management procedure? do the configuration records match what was delivered?' Each uses different participants, criteria, and produces different types of findings.

व्याख्या (हिन्दी) आईईईई 1028 (सॉफ्टवेयर समीक्षाएं और ऑडिट) इन प्रकारों को परिभाषित करता है। प्रबंधन समीक्षाएँ: 'क्या हम समय पर हैं? क्या हमारे पास पर्याप्त संसाधन हैं?' तकनीकी समीक्षाएँ: 'क्या यह डिज़ाइन आवश्यकता 47 को सही ढंग से लागू करता है? क्या यह एपीआई डिज़ाइन वास्तुकला के अनुरूप है?' ऑडिट: 'क्या टीम ने परिवर्तन प्रबंधन प्रक्रिया का पालन किया? क्या कॉन्फ़िगरेशन रिकॉर्ड जो वितरित किया गया था उससे मेल खाता है?' प्रत्येक अलग-अलग प्रतिभागियों, मानदंडों का उपयोग करता है और विभिन्न प्रकार के निष्कर्ष निकालता है।

595

EN + हिं Medium

GB What is the difference between 'spiral cycle objectives' and 'milestone objectives' in Boehm's model?

IN बोहेम के मॉडल में 'सर्पिल चक्र उद्देश्यों' और 'मील का पत्थर उद्देश्यों' के बीच क्या अंतर है?

A

Both terms refer to identical objectives; Boehm uses them interchangeably दोनों शब्द समान उद्देश्यों को संदर्भित करते हैं; बोहेम इनका परस्पर उपयोग करता है

B

Cycle objectives define what the current cycle aims to accomplish (e.g., 'prove the real-time processing algorithm meets latency requirements'); milestone objectives define the strategic gates for the overall project (LCO, LCA, IOC) that multiple cycles collectively work toward चक्र उद्देश्य परिभाषित करते हैं कि वर्तमान चक्र का लक्ष्य क्या हासिल करना है (उदाहरण के लिए, 'साबित करें कि वास्तविक समय प्रसंस्करण एल्गोरिदम विलंबता आवश्यकताओं को पूरा करता है'); मील के पत्थर के उद्देश्य समग्र परियोजना (एलसीओ, एलसीए, आईओसी) के लिए रणनीतिक द्वार को परिभाषित करते हैं जिसके लिए कई चक्र सामूहिक रूप से काम करते हैं

C

Milestone objectives are set by customers; cycle objectives are set by developers independently मील के पत्थर के उद्देश्य ग्राहकों द्वारा निर्धारित किए जाते हैं; चक्र उद्देश्य डेवलपर्स द्वारा स्वतंत्र रूप से निर्धारित किए जाते हैं

D

Cycle objectives change every cycle; milestone objectives are fixed at project initiation चक्र के उद्देश्य हर चक्र में बदलते हैं; परियोजना की शुरुआत में मील के पत्थर के उद्देश्य तय किए जाते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Spiral model operates at two temporal scales: individual cycles (typically weeks to months) with specific risk-resolution objectives, and the strategic arc of LCO→LCA→IOC milestones spanning the project's lifetime. A cycle might focus on 'build and test the search algorithm prototype', contributing toward the LCA milestone's goal of 'validate that all high-risk technical unknowns are resolved'. Both levels need explicit objectives and outcomes.

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

596

EN + हिं Easy

GB What is 'technical risk management plan' in Spiral and what content should it include?

IN स्पाइरल में 'तकनीकी जोखिम प्रबंधन योजना' क्या है और इसमें कौन सी सामग्री शामिल होनी चाहिए?

A

Technical risk management plan is identical to the project risk register used in all methodologies तकनीकी जोखिम प्रबंधन योजना सभी पद्धतियों में प्रयुक्त परियोजना जोखिम रजिस्टर के समान है

B

Technical risk management plan documents: identified technical risks with probability and impact, risk reduction actions and prototypes planned, risk thresholds (when risk becomes unacceptable), monitoring indicators, and contingency plans — updated at the start of each Spiral cycle तकनीकी जोखिम प्रबंधन योजना दस्तावेज़: संभाव्यता और प्रभाव के साथ पहचाने गए तकनीकी जोखिम, जोखिम में कमी के कार्य और योजनाबद्ध प्रोटोटाइप, जोखिम सीमाएँ (जब जोखिम अस्वीकार्य हो जाता है), निगरानी संकेतक और आकस्मिक योजनाएँ - प्रत्येक सर्पिल चक्र की शुरुआत में अपडेट की जाती हैं

C

Technical risk management plan only lists risks; it does not include risk reduction strategies तकनीकी जोखिम प्रबंधन योजना केवल जोखिमों को सूचीबद्ध करती है; इसमें जोखिम कम करने की रणनीतियाँ शामिल नहीं हैं

D

Technical risk management plan is produced once at project start and never updated तकनीकी जोखिम प्रबंधन योजना परियोजना शुरू होने पर एक बार तैयार की जाती है और कभी अद्यतन नहीं की जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Effective risk management requires more than listing risks: for each risk, specify the trigger (what observation would indicate the risk is materialising), the mitigation action (what prototype or analysis reduces the risk), the risk threshold (at what probability×impact level does the project need to pivot or cancel), and the responsible owner. Updating at each cycle ensures newly discovered risks are managed before they become crises.

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

597

EN + हिं Medium

GB What is 'incremental risk reduction' as Spiral cycles accumulate and how does this affect project velocity?

IN सर्पिल चक्रों के जमा होने पर 'वृद्धिशील जोखिम में कमी' क्या है और यह परियोजना वेग को कैसे प्रभावित करता है?

A

Project velocity increases in each Spiral cycle as risk reduction adds work overhead प्रत्येक सर्पिल चक्र में परियोजना का वेग बढ़ जाता है क्योंकि जोखिम कम होने से कार्य में अतिरिक्त वृद्धि हो जाती है

B

As successive cycles resolve risks, remaining work becomes more certain and manageable — early cycles are exploratory and slow (high uncertainty); later cycles become more efficient as the architecture stabilises, requirements are validated, and teams can focus on productive construction without risk interruptions जैसे-जैसे क्रमिक चक्र जोखिमों का समाधान करते हैं, शेष कार्य अधिक निश्चित और प्रबंधनीय हो जाते हैं - प्रारंभिक चक्र खोजपूर्ण और धीमे (उच्च अनिश्चितता) होते हैं; बाद के चक्र अधिक कुशल हो जाते हैं क्योंकि वास्तुकला स्थिर हो जाती है, आवश्यकताएं मान्य हो जाती हैं, और टीमें बिना किसी जोखिम के उत्पादक निर्माण पर ध्यान केंद्रित कर सकती हैं

C

Spiral model velocity is constant across all cycles by design डिज़ाइन के अनुसार सर्पिल मॉडल वेग सभी चक्रों में स्थिर रहता है

D

Velocity always decreases in later Spiral cycles due to accumulated system complexity संचित प्रणाली जटिलता के कारण बाद के सर्पिल चक्रों में वेग हमेशा कम हो जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This pattern explains why Spiral projects front-load risk reduction investment: early cycles may seem slow (research, prototypes, few deliverables) but they de-risk subsequent cycles. Once the LCA milestone is passed (architecture validated), construction velocity accelerates because developers work with clear specifications, stable APIs, and proven architectural patterns rather than discovering design problems mid-implementation.

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

598

EN + हिं Easy

GB What is 'risk-driven testing' as opposed to 'requirements-driven testing' in Spiral projects?

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

A

Risk-driven testing tests only the riskiest requirements; requirements-driven tests everything equally जोखिम-संचालित परीक्षण केवल सबसे जोखिम भरी आवश्यकताओं का परीक्षण करता है; आवश्यकताओं-संचालित हर चीज़ का समान रूप से परीक्षण करता है

B

Risk-driven testing allocates testing effort proportional to the probability and impact of failure in each area — high-risk components (safety-critical, performance-critical, complex algorithms) receive disproportionately more testing than low-risk CRUD operations; requirements-driven testing covers all requirements equally regardless of risk जोखिम-संचालित परीक्षण प्रत्येक क्षेत्र में विफलता की संभावना और प्रभाव के अनुपात में परीक्षण प्रयास आवंटित करता है - उच्च जोखिम वाले घटक (सुरक्षा-महत्वपूर्ण, प्रदर्शन-महत्वपूर्ण, जटिल एल्गोरिदम) कम जोखिम वाले सीआरयूडी संचालन की तुलना में असंगत रूप से अधिक परीक्षण प्राप्त करते हैं; आवश्यकताओं-संचालित परीक्षण जोखिम की परवाह किए बिना सभी आवश्यकताओं को समान रूप से कवर करता है

C

Both testing approaches produce identical defect detection rates with the same effort दोनों परीक्षण दृष्टिकोण समान प्रयास से समान दोष पता लगाने की दर उत्पन्न करते हैं

D

Risk-driven testing was invented for Agile projects and is incompatible with the Spiral model जोखिम-संचालित परीक्षण का आविष्कार एजाइल परियोजनाओं के लिए किया गया था और यह स्पाइरल मॉडल के साथ असंगत है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Risk-based testing (van Veenendaal) applies the 80/20 principle: 20% of system components typically cause 80% of failures. Testing all components equally wastes testing effort on low-risk areas while under-testing high-risk ones. Risk analysis identifies: new/changed components (higher defect density), integration points (historical failure source), performance-critical paths, and safety-critical functions — these receive the concentrated testing investment.

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

599

EN + हिं Easy

GB What is 'Scrumfall' (or 'Scrum-but') anti-pattern and what root cause typically produces it?

IN 'स्क्रमफ़ॉल' (या 'स्क्रम-बट') विरोधी पैटर्न क्या है और कौन सा मूल कारण आम तौर पर इसे उत्पन्न करता है?

A

Scrumfall is a certified Scrum variant officially endorsed by the Scrum Alliance स्क्रमफ़ॉल एक प्रमाणित स्क्रम संस्करण है जो आधिकारिक तौर पर स्क्रम एलायंस द्वारा समर्थित है

B

Scrumfall describes organisations using Scrum terminology (sprints, standups) while retaining Waterfall's underlying structure (big upfront design, phase gates, no real iteration) — typically caused by organisational resistance to genuine agile transformation, where teams adopt ceremonies without changing fundamental practices स्क्रमफ़ॉल, वॉटरफ़ॉल की अंतर्निहित संरचना (बड़े अपफ्रंट डिज़ाइन, चरण द्वार, कोई वास्तविक पुनरावृत्ति नहीं) को बनाए रखते हुए स्क्रम शब्दावली (स्प्रिंट, स्टैंडअप) का उपयोग करने वाले संगठनों का वर्णन करता है - आमतौर पर वास्तविक चुस्त परिवर्तन के लिए संगठनात्मक प्रतिरोध के कारण होता है, जहां टीमें मौलिक प्रथाओं को बदले बिना समारोह अपनाती हैं

C

Scrumfall is a hybrid methodology specifically designed for hardware-software co-development स्क्रमफ़ॉल एक हाइब्रिड पद्धति है जिसे विशेष रूप से हार्डवेयर-सॉफ़्टवेयर सह-विकास के लिए डिज़ाइन किया गया है

D

Scrumfall occurs only when Scrum Masters lack proper certification स्क्रमफ़ॉल केवल तभी होता है जब स्क्रम मास्टर्स के पास उचित प्रमाणीकरण का अभाव होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Scrumfall symptoms: sprints exist but requirements are frozen upfront for the entire release; 'sprint review' is a status report rather than genuine stakeholder feedback; the Definition of Done doesn't actually mean shippable. Root cause: management retains command-and-control culture and risk-aversion incompatible with agile's empirical, adaptive philosophy, while mandating 'we're doing Scrum now' without addressing underlying organisational dynamics.

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

600

EN + हिं Easy

GB What is 'velocity-driven planning' fallacy and why does treating velocity as a target rather than a measurement backfire?

IN 'वेग-संचालित योजना' की भ्रांति क्या है और वेग को माप के बजाय एक लक्ष्य के रूप में मानने का परिणाम उल्टा क्यों पड़ता है?

A

Velocity-driven planning fallacy does not exist; velocity targets always improve team performance वेग-चालित योजना संबंधी भ्रांति मौजूद नहीं है; वेग लक्ष्य हमेशा टीम के प्रदर्शन में सुधार करते हैं

B

When management sets velocity targets ('the team must achieve 50 points per sprint'), teams respond by inflating story point estimates rather than delivering more actual value — converting a useful forecasting metric into a gamed number that loses its predictive value (Goodhart's Law in action) जब प्रबंधन वेग लक्ष्य निर्धारित करता है ('टीम को प्रति स्प्रिंट 50 अंक प्राप्त करने चाहिए'), तो टीमें अधिक वास्तविक मूल्य देने के बजाय कहानी बिंदु अनुमानों को बढ़ाकर प्रतिक्रिया देती हैं - एक उपयोगी पूर्वानुमान मीट्रिक को एक गेम संख्या में परिवर्तित करना जो अपना पूर्वानुमानित मूल्य खो देता है (गुडहार्ट का नियम क्रिया में)

C

Velocity targets are always achievable if the team works overtime consistently यदि टीम लगातार ओवरटाइम काम करती है तो वेग लक्ष्य हमेशा प्राप्त किए जा सकते हैं

D

Velocity should always increase every sprint as a measure of team improvement टीम में सुधार के उपाय के रूप में प्रत्येक स्प्रिंट में वेग हमेशा बढ़ना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Velocity is meant to be a forecasting tool derived from historical data, used by the team for its own sprint planning. When it becomes an external performance target, the team's incentive shifts from accurate estimation to estimate inflation — a story that was '3 points' last month becomes '5 points' this month with no actual change in scope. The metric becomes useless for its original purpose: predicting delivery dates.

व्याख्या (हिन्दी) वेलोसिटी का मतलब ऐतिहासिक डेटा से प्राप्त एक पूर्वानुमान उपकरण है, जिसका उपयोग टीम द्वारा अपनी स्प्रिंट योजना के लिए किया जाता है। जब यह एक बाहरी प्रदर्शन लक्ष्य बन जाता है, तो टीम का प्रोत्साहन सटीक अनुमान से मुद्रास्फीति का अनुमान लगाने के लिए स्थानांतरित हो जाता है - एक कहानी जो पिछले महीने '3 अंक' थी, इस महीने '5 अंक' हो जाती है, जिसमें दायरे में कोई वास्तविक बदलाव नहीं होता है। मीट्रिक अपने मूल उद्देश्य के लिए बेकार हो जाता है: डिलीवरी की तारीखों की भविष्यवाणी करना।

Software Engineering — MCQ Practice