2491

EN + हिं Easy

GB What is 'software process improvement' (SPI) and what evidence does literature provide about its ROI?

IN 'सॉफ़्टवेयर प्रक्रिया सुधार' (एसपीआई) क्या है और साहित्य इसके आरओआई के बारे में क्या सबूत प्रदान करता है?

A

SPI is the practice of updating programming languages used in development; ROI is proportional to language modernity एसपीआई विकास में प्रयुक्त प्रोग्रामिंग भाषाओं को अद्यतन करने का अभ्यास है; आरओआई भाषा आधुनिकता के समानुपाती है

B

SPI systematically analyses and modifies development processes to improve quality, predictability, and efficiency; studies (SEI, Brodman & Johnson) show typical ROIs of 3:1 to 9:1 but only when sustained over multiple years एसपीआई गुणवत्ता, पूर्वानुमेयता और दक्षता में सुधार के लिए विकास प्रक्रियाओं का व्यवस्थित रूप से विश्लेषण और संशोधन करता है; अध्ययन (एसईआई, ब्रोडमैन और जॉनसन) सामान्य आरओआई 3:1 से 9:1 दिखाते हैं, लेकिन केवल तभी जब कई वर्षों तक कायम रहे

C

SPI only improves developer productivity; it has no measurable impact on product quality एसपीआई केवल डेवलपर उत्पादकता में सुधार करता है; इसका उत्पाद की गुणवत्ता पर कोई मापने योग्य प्रभाव नहीं पड़ता है

D

SPI ROI can be achieved within the first month of implementation एसपीआई आरओआई कार्यान्वयन के पहले महीने के भीतर हासिल किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SPI (as in CMM/CMMI improvement initiatives) requires sustained investment in training, tools, and cultural change. SEI studies and industry surveys consistently show positive ROI (3:1 to 9:1 over 3-5 years) through defect reduction, shorter cycles, and predictable delivery — but only when organisations commit long-term rather than treating it as a short-term project.

व्याख्या (हिन्दी) एसपीआई (सीएमएम/सीएमएमआई सुधार पहल की तरह) को प्रशिक्षण, उपकरण और सांस्कृतिक परिवर्तन में निरंतर निवेश की आवश्यकता होती है। एसईआई अध्ययन और उद्योग सर्वेक्षण लगातार दोष में कमी, छोटे चक्र और पूर्वानुमानित डिलीवरी के माध्यम से सकारात्मक आरओआई (3-5 वर्षों में 3:1 से 9:1) दिखाते हैं - लेकिन केवल तब जब संगठन इसे अल्पकालिक परियोजना के रूप में मानने के बजाय दीर्घकालिक प्रतिबद्ध होते हैं।

2492

EN + हिं Medium

GB What is the 'DevOps' movement and how does it extend traditional software process models?

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

A

DevOps is a specific programming methodology for cloud-native applications only DevOps केवल क्लाउड-नेटिव अनुप्रयोगों के लिए एक विशिष्ट प्रोग्रामिंग पद्धति है

B

DevOps extends the software lifecycle by unifying development and operations, enabling continuous delivery through automation of build, test, and deployment — breaking the traditional handoff barrier between dev and ops teams DevOps विकास और संचालन को एकीकृत करके सॉफ़्टवेयर जीवनचक्र का विस्तार करता है, निर्माण, परीक्षण और तैनाती के स्वचालन के माध्यम से निरंतर वितरण को सक्षम करता है - देव और ऑप्स टीमों के बीच पारंपरिक हैंडऑफ़ बाधा को तोड़ता है।

C

DevOps replaces software architecture with infrastructure-as-code and requires no design phase DevOps सॉफ़्टवेयर आर्किटेक्चर को इंफ्रास्ट्रक्चर-ए-कोड से बदल देता है और इसके लिए किसी डिज़ाइन चरण की आवश्यकता नहीं होती है

D

DevOps is only applicable to startups; enterprises cannot adopt it due to regulatory requirements DevOps केवल स्टार्टअप्स पर लागू है; नियामक आवश्यकताओं के कारण उद्यम इसे नहीं अपना सकते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) DevOps bridges the development-operations silos that traditional models left intact. By automating the entire pipeline (CI/CD/CD) and fostering shared ownership of production, DevOps enables organisations to deploy multiple times per day rather than quarterly, dramatically accelerating feedback loops and reducing mean time to recover from failures.

व्याख्या (हिन्दी) DevOps उन विकास-संचालन साइलो को पाटता है जिन्हें पारंपरिक मॉडल बरकरार रखते हैं। संपूर्ण पाइपलाइन (सीआई/सीडी/सीडी) को स्वचालित करके और उत्पादन के साझा स्वामित्व को बढ़ावा देकर, डेवऑप्स संगठनों को त्रैमासिक के बजाय प्रति दिन कई बार तैनात करने में सक्षम बनाता है, नाटकीय रूप से फीडबैक लूप में तेजी लाता है और विफलताओं से उबरने के लिए औसत समय को कम करता है।

2493

EN + हिं Easy

GB What is 'feature-driven development' (FDD) and what distinguishes it from XP in project planning?

IN 'फ़ीचर-संचालित विकास' (FDD) क्या है और प्रोजेक्ट प्लानिंग में इसे XP से क्या अलग करता है?

A

FDD focuses on UI features only; XP focuses on backend services FDD केवल UI सुविधाओं पर केंद्रित है; XP बैकएंड सेवाओं पर केंद्रित है

B

FDD plans and delivers based on a feature list derived upfront from domain modelling; XP is customer-driven with features emerging through ongoing collaboration. FDD provides more predictability for large teams; XP more flexibility एफडीडी डोमेन मॉडलिंग से प्राप्त फीचर सूची के आधार पर योजना और वितरण करता है; XP ग्राहक-संचालित है और चल रहे सहयोग के माध्यम से उभरती हुई सुविधाएँ हैं। एफडीडी बड़ी टीमों के लिए अधिक पूर्वानुमानशीलता प्रदान करता है; XP अधिक लचीलापन

C

FDD and XP are identical; the difference is only in ceremony names एफडीडी और एक्सपी समान हैं; अंतर केवल समारोह के नामों में है

D

FDD uses pair programming throughout; XP prohibits pair programming FDD पूरे युग में जोड़ी प्रोग्रामिंग का उपयोग करता है; XP जोड़ी प्रोग्रामिंग को प्रतिबंधित करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) FDD (Palmer and Felsing) begins with five initial activities: develop overall model, build feature list, plan by feature, design by feature, build by feature. The upfront feature list provides a project map that large teams can coordinate around. XP's planning game is more dynamic — no upfront feature list, stories emerge through customer collaboration sprint by sprint.

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

2494

EN + हिं Easy

GB What is 'disciplined agile delivery' (DAD) and what is its primary value proposition over pure Scrum?

IN 'अनुशासित एजाइल डिलीवरी' (डीएडी) क्या है और शुद्ध स्क्रम की तुलना में इसका प्राथमिक मूल्य प्रस्ताव क्या है?

A

DAD is a stricter version of Scrum that adds mandatory documentation requirements डीएडी स्क्रम का एक सख्त संस्करण है जो अनिवार्य दस्तावेज़ीकरण आवश्यकताओं को जोड़ता है

B

DAD is a hybrid process framework that provides choice and pragmatism — it acknowledges that different situations need different approaches and provides a toolkit of agile and lean strategies rather than prescribing one method डीएडी एक हाइब्रिड प्रक्रिया ढांचा है जो विकल्प और व्यावहारिकता प्रदान करता है - यह स्वीकार करता है कि विभिन्न स्थितियों के लिए अलग-अलग दृष्टिकोण की आवश्यकता होती है और एक विधि निर्धारित करने के बजाय चुस्त और दुबली रणनीतियों का टूलकिट प्रदान करता है।

C

DAD is only suitable for government and defence software projects डीएडी केवल सरकारी और रक्षा सॉफ्टवेयर परियोजनाओं के लिए उपयुक्त है

D

DAD replaces the Product Owner role with an Enterprise Architect DAD उत्पाद स्वामी की भूमिका को एंटरप्राइज आर्किटेक्ट से बदल देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) DAD (Scott Ambler, IBM) recognises that Scrum's minimalism ('start here') leaves too many gaps for enterprise projects. DAD offers a 'choose your WoW' (Way of Working) philosophy: it maps decision points to multiple options (Scrum, Kanban, SAFe, lean, traditional) and guides teams to select the right approach for their context rather than mandating one.

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

2495

EN + हिं Easy

GB What is 'model-driven engineering' (MDE) and what fundamental assumption underlies it?

IN 'मॉडल-संचालित इंजीनियरिंग' (एमडीई) क्या है और कौन सी मौलिक धारणा इसका आधार है?

A

MDE generates project management schedules automatically from software requirements एमडीई सॉफ्टवेयर आवश्यकताओं से स्वचालित रूप से परियोजना प्रबंधन कार्यक्रम तैयार करता है

B

MDE creates software from formal models (platform-independent and platform-specific) using automated transformation — assuming models are more productive than code as the primary engineering artefact एमडीई स्वचालित परिवर्तन का उपयोग करके औपचारिक मॉडल (प्लेटफ़ॉर्म-स्वतंत्र और प्लेटफ़ॉर्म-विशिष्ट) से सॉफ़्टवेयर बनाता है - यह मानते हुए कि प्राथमिक इंजीनियरिंग आर्टिफैक्ट के रूप में मॉडल कोड की तुलना में अधिक उत्पादक हैं

C

MDE is only used for embedded real-time systems where code generation is mandatory एमडीई का उपयोग केवल एम्बेडेड रीयल-टाइम सिस्टम के लिए किया जाता है जहां कोड जनरेशन अनिवार्य है

D

MDE replaces testing entirely by using formal verification of the models एमडीई मॉडलों के औपचारिक सत्यापन का उपयोग करके परीक्षण को पूरी तरह से बदल देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) MDE (OMG's MDA framework) uses Platform-Independent Models (PIMs) transformed by automated tools into Platform-Specific Models (PSMs) and eventually executable code. The assumption: raising abstraction level increases productivity. OMG's MDA, Microsoft's DSL Tools, and Siemens' Mendix all embody this philosophy with varying degrees of success.

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

2496

EN + हिं Medium

GB What is 'continuous experimentation' in modern software engineering and how does it relate to the scientific method?

IN आधुनिक सॉफ्टवेयर इंजीनियरिंग में 'निरंतर प्रयोग' क्या है और यह वैज्ञानिक पद्धति से कैसे संबंधित है?

A

Continuous experimentation is running automated tests continuously in a CI/CD pipeline सतत प्रयोग एक सीआई/सीडी पाइपलाइन में लगातार स्वचालित परीक्षण चला रहा है

B

Continuous experimentation applies the scientific method to product development: forming hypotheses about user behaviour, running controlled A/B tests in production, measuring outcomes, and making data-driven decisions rather than opinion-driven ones निरंतर प्रयोग उत्पाद विकास के लिए वैज्ञानिक पद्धति को लागू करता है: उपयोगकर्ता के व्यवहार के बारे में परिकल्पना बनाना, उत्पादन में नियंत्रित ए/बी परीक्षण चलाना, परिणामों को मापना, और राय-संचालित के बजाय डेटा-संचालित निर्णय लेना।

C

Continuous experimentation is only possible after a product has at least one million active users किसी उत्पाद के कम से कम दस लाख सक्रिय उपयोगकर्ता होने के बाद ही निरंतर प्रयोग संभव है

D

Continuous experimentation requires dedicated hardware separate from production infrastructure निरंतर प्रयोग के लिए उत्पादन बुनियादी ढांचे से अलग समर्पित हार्डवेयर की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Companies like Microsoft, Netflix, and Amazon run thousands of simultaneous A/B experiments on production traffic. Each experiment tests a specific hypothesis (e.g., 'changing button colour increases conversion') with a control group and treatment group, measuring key metrics. Data replaces HiPPO (Highest Paid Person's Opinion) as the decision driver — a fundamental shift from traditional development.

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

2497

EN + हिं Medium

GB In a Waterfall project, what is the specific purpose of the 'System Requirements Analysis' phase?

IN वॉटरफ़ॉल परियोजना में, 'सिस्टम आवश्यकताएँ विश्लेषण' चरण का विशिष्ट उद्देश्य क्या है?

A

To write the actual source code for the system modules सिस्टम मॉड्यूल के लिए वास्तविक स्रोत कोड लिखना

B

To analyse and document what the system must do from a user/stakeholder perspective — producing an SRS that serves as the contract between customer and developer उपयोगकर्ता/हितधारक परिप्रेक्ष्य से सिस्टम को क्या करना चाहिए इसका विश्लेषण और दस्तावेजीकरण करना - एक एसआरएस तैयार करना जो ग्राहक और डेवलपर के बीच अनुबंध के रूप में कार्य करता है

C

To evaluate competing software vendors and select the best implementation platform प्रतिस्पर्धी सॉफ़्टवेयर विक्रेताओं का मूल्यांकन करना और सर्वोत्तम कार्यान्वयन प्लेटफ़ॉर्म का चयन करना

D

To create the project schedule and allocate budget to individual developers प्रोजेक्ट शेड्यूल बनाना और व्यक्तिगत डेवलपर्स को बजट आवंटित करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) System Requirements Analysis transforms vague stakeholder needs into precise, documented requirements in a Software Requirements Specification (SRS). The SRS serves as the contractual foundation for all subsequent phases — changes require formal change control, and downstream teams (design, test) derive their work from it.

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

2498

EN + हिं Easy

GB What is 'phase containment' in a Waterfall project and why does it reduce overall cost?

IN झरना परियोजना में 'चरण रोकथाम' क्या है और यह समग्र लागत को कम क्यों करता है?

A

Phase containment means keeping all project phases within the originally planned budget चरण नियंत्रण का अर्थ है सभी परियोजना चरणों को मूल रूप से नियोजित बजट के भीतर रखना

B

Phase containment means detecting and fixing defects within the phase that introduces them rather than allowing them to propagate to downstream phases where fix cost multiplies चरण रोकथाम का मतलब उस चरण के भीतर दोषों का पता लगाना और उन्हें ठीक करना है जो उन्हें डाउनस्ट्रीम चरणों में फैलने की अनुमति देने के बजाय उन्हें पेश करते हैं जहां फिक्स लागत कई गुना बढ़ जाती है।

C

Phase containment is a schedule management technique preventing phase overlap चरण रोकथाम एक शेड्यूल प्रबंधन तकनीक है जो चरण ओवरलैप को रोकती है

D

Phase containment means each phase must be fully documented before proceeding to the next चरण रोकथाम का अर्थ है कि अगले चरण पर जाने से पहले प्रत्येक चरण को पूरी तरह से प्रलेखित किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's cost-of-change curve shows defects are cheapest when found in the phase that creates them. A requirements error detected in requirements review costs 1x to fix; detected in design costs 3-6x; in implementation 10x; in testing 40-100x; in maintenance 100-200x. Phase containment through reviews maximises early detection.

व्याख्या (हिन्दी) बोहेम के परिवर्तन की लागत वक्र से पता चलता है कि दोष तब सबसे सस्ते होते हैं जब वे उस चरण में पाए जाते हैं जो उन्हें बनाता है। आवश्यकताओं की समीक्षा में पाई गई आवश्यकताओं की त्रुटि को ठीक करने में 1x लागत आती है; डिज़ाइन लागत में 3-6x का पता चला; कार्यान्वयन में 10x; परीक्षण में 40-100x; रखरखाव में 100-200x. समीक्षाओं के माध्यम से चरणबद्ध नियंत्रण प्रारंभिक पहचान को अधिकतम करता है।

2499

EN + हिं Medium

GB Why is the 'big bang integration' testing approach particularly dangerous in Waterfall projects?

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

A

Big bang integration requires specialised tools that are expensive to license बिग बैंग एकीकरण के लिए विशेष उपकरणों की आवश्यकता होती है जिनका लाइसेंस लेना महंगा होता है

B

Big bang integration combines all modules simultaneously at the end of development — when multiple simultaneous interface failures occur, isolating and diagnosing individual faults becomes extremely difficult because interactions mask individual defects बिग बैंग एकीकरण विकास के अंत में सभी मॉड्यूल को एक साथ जोड़ता है - जब एक साथ कई इंटरफ़ेस विफलताएं होती हैं, तो व्यक्तिगत दोषों को अलग करना और उनका निदान करना बेहद मुश्किल हो जाता है क्योंकि इंटरैक्शन व्यक्तिगत दोषों को छुपाता है

C

Big bang integration is only dangerous for systems with more than 50 modules बिग बैंग एकीकरण केवल 50 से अधिक मॉड्यूल वाले सिस्टम के लिए खतरनाक है

D

Big bang integration violates Waterfall methodology rules and should never be used with Waterfall बिग बैंग एकीकरण वाटरफॉल पद्धति नियमों का उल्लंघन करता है और इसे वाटरफॉल के साथ कभी भी उपयोग नहीं किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) When you integrate everything at once, any failure has n*(n-1)/2 potential interaction causes. Incremental integration (top-down, bottom-up, sandwich) adds one component at a time — any new failure is almost certainly caused by the most recently added component, dramatically simplifying fault isolation.

व्याख्या (हिन्दी) जब आप सब कुछ एक साथ एकीकृत करते हैं, तो किसी भी विफलता में n*(n-1)/2 संभावित इंटरैक्शन कारण होते हैं। वृद्धिशील एकीकरण (ऊपर से नीचे, नीचे से ऊपर, सैंडविच) एक समय में एक घटक जोड़ता है - कोई भी नई विफलता लगभग निश्चित रूप से सबसे हाल ही में जोड़े गए घटक के कारण होती है, जो गलती अलगाव को नाटकीय रूप से सरल बनाती है।

2500

EN + हिं Medium

GB What is the 'modified waterfall' and how does it address the original model's rigid sequential constraint?

IN 'संशोधित झरना' क्या है और यह मूल मॉडल की कठोर अनुक्रमिक बाधा को कैसे संबोधित करता है?

A

Modified Waterfall allows developers to skip phases they consider unnecessary संशोधित झरना डेवलपर्स को उन चरणों को छोड़ने की अनुमति देता है जिन्हें वे अनावश्यक मानते हैं

B

Modified Waterfall allows controlled feedback loops between adjacent phases — if design reveals a requirements gap, requirements can be revisited without restarting the entire project संशोधित झरना आसन्न चरणों के बीच नियंत्रित फीडबैक लूप की अनुमति देता है - यदि डिज़ाइन आवश्यकताओं के अंतर को प्रकट करता है, तो संपूर्ण परियोजना को पुनरारंभ किए बिना आवश्यकताओं पर दोबारा गौर किया जा सकता है

C

Modified Waterfall merges design and implementation into a single concurrent phase संशोधित झरना डिजाइन और कार्यान्वयन को एक समवर्ती चरण में विलय कर देता है

D

Modified Waterfall replaced Royce's original model and is what all Waterfall textbooks describe संशोधित वॉटरफ़ॉल ने रॉयस के मूल मॉडल को प्रतिस्थापित कर दिया और सभी वॉटरफ़ॉल पाठ्यपुस्तकों में इसका वर्णन किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Royce's original 1970 paper already recommended feedback loops between adjacent phases. The 'modified Waterfall' formalises this: phases are still largely sequential, but controlled iteration back to the previous phase is permitted when discoveries require it — preventing the catastrophic cost of full restarts while maintaining the structured progression.

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

2501

EN + हिं Easy

GB In Waterfall, what is the 'integration testing' phase specifically designed to verify?

IN वॉटरफॉल में, 'एकीकरण परीक्षण' चरण विशेष रूप से सत्यापित करने के लिए क्या डिज़ाइन किया गया है?

A

That individual modules correctly implement their specified algorithms वह व्यक्तिगत मॉड्यूल अपने निर्दिष्ट एल्गोरिदम को सही ढंग से लागू करते हैं

B

That independently developed and unit-tested modules work correctly together when combined — specifically verifying interfaces, data exchange contracts, and interactions between integrated components स्वतंत्र रूप से विकसित और यूनिट-परीक्षणित मॉड्यूल संयुक्त होने पर एक साथ सही ढंग से काम करते हैं - विशेष रूप से इंटरफेस, डेटा एक्सचेंज अनुबंध और एकीकृत घटकों के बीच इंटरैक्शन की पुष्टि करते हुए

C

That the complete integrated system meets all user acceptance criteria यह कि संपूर्ण एकीकृत प्रणाली सभी उपयोगकर्ता स्वीकृति मानदंडों को पूरा करती है

D

That the production deployment environment matches the development environment specifications यह कि उत्पादन परिनियोजन परिवेश विकास परिवेश विनिर्देशों से मेल खाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Unit testing verifies individual modules in isolation. Integration testing verifies that the interfaces and interactions between modules work correctly — data passed between them is correctly interpreted, API contracts are honoured, and shared resources are properly managed. System testing then verifies the fully integrated system against requirements.

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

2502

EN + हिं Medium

GB What specific risk does the 'requirements freeze' concept in Waterfall introduce for long-duration projects?

IN वॉटरफॉल में 'आवश्यकताओं को स्थिर' करने की अवधारणा लंबी अवधि की परियोजनाओं के लिए कौन सा विशिष्ट जोखिम पेश करती है?

A

Requirements freeze prevents developers from adding performance improvements during implementation आवश्यकताओं पर रोक डेवलपर्स को कार्यान्वयन के दौरान प्रदर्शन में सुधार जोड़ने से रोकती है

B

In long projects (18+ months), freezing requirements at initiation means the business environment, regulations, and technology may have changed substantially by delivery, producing a system that is obsolete on release day लंबी परियोजनाओं (18+ महीने) में, शुरुआत में आवश्यकताओं को फ्रीज करने का मतलब है कि वितरण के कारण कारोबारी माहौल, नियम और तकनीक काफी हद तक बदल गई होगी, जिससे एक ऐसी प्रणाली तैयार हो जाएगी जो रिलीज के दिन अप्रचलित हो जाएगी।

C

Requirements freeze increases developer productivity by eliminating scope change discussions आवश्यकताएँ फ़्रीज़ स्कोप परिवर्तन चर्चाओं को समाप्त करके डेवलपर उत्पादकता बढ़ाती हैं

D

Requirements freeze only applies to functional requirements; non-functional requirements can be modified freely आवश्यकताओं पर रोक केवल कार्यात्मक आवश्यकताओं पर लागू होती है; गैर-कार्यात्मक आवश्यकताओं को स्वतंत्र रूप से संशोधित किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The longer a Waterfall project, the higher the probability that frozen requirements no longer represent current business needs at delivery. A 3-year government system may specify requirements based on regulations that have since been updated, business processes that have changed, or technology assumptions that are now obsolete — making the delivered system invalid before it's even used.

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

2503

EN + हिं Medium

GB What is the 'software development notebook' in a Waterfall project and why is it considered a quality tool?

IN वॉटरफ़ॉल प्रोजेक्ट में 'सॉफ़्टवेयर डेवलपमेंट नोटबुक' क्या है और इसे एक गुणवत्तापूर्ण उपकरण क्यों माना जाता है?

A

A physical notebook where developers write code before typing it into a computer एक भौतिक नोटबुक जहां डेवलपर्स कंप्यूटर में टाइप करने से पहले कोड लिखते हैं

B

A structured record of all design decisions, rationale, alternatives considered, and open issues maintained throughout development — providing traceability and institutional memory that reduces rework when key developers leave सभी डिज़ाइन निर्णयों, तर्क, विचार किए गए विकल्पों और विकास के दौरान बनाए गए खुले मुद्दों का एक संरचित रिकॉर्ड - ट्रेसबिलिटी और संस्थागत मेमोरी प्रदान करता है जो प्रमुख डेवलपर्स के चले जाने पर पुनर्कार्य को कम करता है

C

A project management document listing all team members and their assigned modules सभी टीम सदस्यों और उनके निर्दिष्ट मॉड्यूल को सूचीबद्ध करने वाला एक परियोजना प्रबंधन दस्तावेज़

D

A notebook mandated by ISO 9001 containing code review findings only आईएसओ 9001 द्वारा अनिवार्य एक नोटबुक जिसमें केवल कोड समीक्षा निष्कर्ष शामिल हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The software development notebook (from cleanroom and formal methods practice) documents the 'why' behind decisions — not just what was built, but why alternatives were rejected. This is critical because the tacit knowledge in developers' heads is lost when they leave, forcing expensive re-investigation of previously settled questions.

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

2504

EN + हिं Easy

GB What does the 'operational concept' document serve in a Waterfall project and who should produce it?

IN वाटरफॉल प्रोजेक्ट में 'ऑपरेशनल कॉन्सेप्ट' दस्तावेज़ क्या काम करता है और इसे किसे तैयार करना चाहिए?

A

It describes the physical hardware infrastructure required to run the software यह सॉफ़्टवेयर चलाने के लिए आवश्यक भौतिक हार्डवेयर अवसंरचना का वर्णन करता है

B

The operational concept describes how the end system will be used in its operational environment — produced by the customer/user representative to ensure the development team understands usage context before writing requirements परिचालन अवधारणा बताती है कि अंतिम प्रणाली का उपयोग उसके परिचालन वातावरण में कैसे किया जाएगा - ग्राहक/उपयोगकर्ता प्रतिनिधि द्वारा निर्मित यह सुनिश्चित करने के लिए कि विकास टीम आवश्यकताओं को लिखने से पहले उपयोग के संदर्भ को समझती है।

C

It is a technical document produced by the lead architect describing deployment topology यह प्रमुख वास्तुकार द्वारा परिनियोजन टोपोलॉजी का वर्णन करने वाला एक तकनीकी दस्तावेज़ है

D

The operational concept is produced by the QA team to define the scope of acceptance testing स्वीकृति परीक्षण के दायरे को परिभाषित करने के लिए क्यूए टीम द्वारा परिचालन अवधारणा तैयार की जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Operational Concept Document (OCD) or ConOps (IEEE 1362) establishes the user's vision of system operation before technical requirements are written. Produced by users/operators, it describes who uses the system, how, in what environment, and what mission it supports — grounding subsequent technical requirements in operational reality.

व्याख्या (हिन्दी) ऑपरेशनल कॉन्सेप्ट डॉक्यूमेंट (ओसीडी) या कॉनऑप्स (आईईईई 1362) तकनीकी आवश्यकताओं को लिखे जाने से पहले सिस्टम संचालन के बारे में उपयोगकर्ता के दृष्टिकोण को स्थापित करता है। उपयोगकर्ताओं/ऑपरेटरों द्वारा निर्मित, यह वर्णन करता है कि सिस्टम का उपयोग कौन करता है, कैसे, किस वातावरण में और यह किस मिशन का समर्थन करता है - परिचालन वास्तविकता में बाद की तकनीकी आवश्यकताओं को पूरा करता है।

2505

EN + हिं Medium

GB What is 'structured walkthrough' in the Waterfall model and how does it differ from a formal inspection?

IN वॉटरफॉल मॉडल में 'स्ट्रक्चर्ड वॉकथ्रू' क्या है और यह औपचारिक निरीक्षण से कैसे भिन्न है?

A

Structured walkthrough is an automated code analysis tool; formal inspection is manual संरचित वॉकथ्रू एक स्वचालित कोड विश्लेषण उपकरण है; औपचारिक निरीक्षण मैनुअल है

B

In a walkthrough, the author leads reviewers through the work product explaining it; in a formal inspection (Fagan), the author is silent while trained inspectors systematically examine the work against checklists — inspections find more defects per hour एक पूर्वाभ्यास में, लेखक समीक्षकों को कार्य उत्पाद के बारे में समझाता है; एक औपचारिक निरीक्षण (फ़गन) में, लेखक चुप रहता है जबकि प्रशिक्षित निरीक्षक व्यवस्थित रूप से चेकलिस्ट के विरुद्ध कार्य की जाँच करते हैं - निरीक्षण में प्रति घंटे अधिक दोष मिलते हैं

C

Structured walkthroughs are only conducted on requirements; formal inspections only on code संरचित वॉकथ्रू केवल आवश्यकताओं पर आयोजित किए जाते हैं; केवल कोड पर औपचारिक निरीक्षण

D

Both techniques are equivalent with no meaningful quality difference between them दोनों तकनीकें समान हैं और उनके बीच कोई सार्थक गुणवत्ता अंतर नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Fagan inspection (IBM, 1976) is a formal defect-removal process: a moderator (not the author) leads a team of trained inspectors who have pre-studied the work product against a defect checklist. The author says nothing during inspection. Research consistently shows Fagan inspections find 60-90% of defects and have ROI of 10:1+ over testing alone.

व्याख्या (हिन्दी) फगन निरीक्षण (आईबीएम, 1976) एक औपचारिक दोष-निवारण प्रक्रिया है: एक मॉडरेटर (लेखक नहीं) प्रशिक्षित निरीक्षकों की एक टीम का नेतृत्व करता है, जिन्होंने दोष जांच सूची के खिलाफ कार्य उत्पाद का पूर्व-अध्ययन किया है। निरीक्षण के दौरान लेखक कुछ नहीं कहता. अनुसंधान लगातार दिखाता है कि फागन निरीक्षणों में 60-90% दोष पाए जाते हैं और अकेले परीक्षण पर 10:1+ का आरओआई होता है।

Software Engineering — MCQ Practice