286 Question 286 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. व्याख्या (हिन्दी) एफडीडी (पामर और फेल्सिंग) पांच प्रारंभिक गतिविधियों से शुरू होता है: समग्र मॉडल विकसित करना, फीचर सूची बनाना, फीचर द्वारा योजना बनाना, फीचर द्वारा डिजाइन करना, फीचर द्वारा निर्माण करना। अग्रिम सुविधा सूची एक प्रोजेक्ट मानचित्र प्रदान करती है जिसके साथ बड़ी टीमें समन्वय कर सकती हैं। एक्सपी का नियोजन खेल अधिक गतिशील है - कोई अग्रिम फीचर सूची नहीं, कहानियां ग्राहक सहयोग स्प्रिंट दर स्प्रिंट के माध्यम से उभरती हैं। 🎯 Exam Perspective Software Engineering ("Introduction to Software Engineering" sub-topic) के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे Railway, SSC, Banking और Defence परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What does the 'operational concept' document serve in a... What is the 'anchor point milestone' LCA (Life Cycle Ar... What is 'disciplined agile delivery' (DAD) and what is... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
287 Question 287 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. व्याख्या (हिन्दी) डीएडी (स्कॉट एंबलर, आईबीएम) मानता है कि स्क्रम का अतिसूक्ष्मवाद ('यहां से शुरू करें') उद्यम परियोजनाओं के लिए बहुत सारे अंतराल छोड़ देता है। डीएडी एक 'अपना वाह चुनें' (काम करने का तरीका) दर्शन प्रदान करता है: यह निर्णय बिंदुओं को कई विकल्पों (स्क्रम, कानबन, एसएएफई, लीन, पारंपरिक) पर मैप करता है और टीमों को किसी एक को अनिवार्य करने के बजाय उनके संदर्भ के लिए सही दृष्टिकोण का चयन करने के लिए मार्गदर्शन करता है। 🎯 Exam Perspective यह सवाल Software Engineering ("Introduction to Software Engineering" sub-topic) category का है — difficulty level "Easy", और SSC, Railway, Banking और State PCS के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What is the 'modified waterfall' and how does it addres... What is the 'software development notebook' in a Waterf... What is 'feature-driven development' (FDD) and what dis... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
288 Question 288 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. व्याख्या (हिन्दी) एमडीई (ओएमजी का एमडीए फ्रेमवर्क) स्वचालित टूल द्वारा प्लेटफ़ॉर्म-विशिष्ट मॉडल (पीएसएम) और अंततः निष्पादन योग्य कोड में परिवर्तित प्लेटफ़ॉर्म-स्वतंत्र मॉडल (पीआईएम) का उपयोग करता है। धारणा: अमूर्तता स्तर बढ़ाने से उत्पादकता बढ़ती है। ओएमजी के एमडीए, माइक्रोसॉफ्ट के डीएसएल टूल्स और सीमेंस के मेंडिक्स सभी सफलता की अलग-अलग डिग्री के साथ इस दर्शन को अपनाते हैं। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Introduction to Software Engineering" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Easy"। इस तरह के प्रश्न अक्सर SSC CGL, IBPS, RRB और State-level परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is the 'software development notebook' in a Waterf... What is 'phase containment' in a Waterfall project and... What is the 'planning game' in XP and how does it distr... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
289 Question 289 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 (उच्चतम वेतन पाने वाले व्यक्ति की राय) की जगह लेता है - पारंपरिक विकास से एक मौलिक बदलाव। 🎯 Exam Perspective Software Engineering ("Introduction to Software Engineering" sub-topic) से जुड़ा यह सवाल — difficulty level "Medium" उन students के लिए काम का है जो UPSC, SSC, Banking और Police भर्ती की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions Why is the 'big bang integration' testing approach part... What specific risk does the 'requirements freeze' conce... What is 'phase containment' in a Waterfall project and... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
290 Question 290 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. व्याख्या (हिन्दी) सिस्टम आवश्यकताएँ विश्लेषण अस्पष्ट हितधारक आवश्यकताओं को सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (एसआरएस) में सटीक, दस्तावेज़ीकृत आवश्यकताओं में बदल देता है। एसआरएस बाद के सभी चरणों के लिए संविदात्मक आधार के रूप में कार्य करता है - परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है, और डाउनस्ट्रीम टीमें (डिज़ाइन, परीक्षण) इससे अपना काम प्राप्त करती हैं। 🎯 Exam Perspective Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में Software Engineering ("Introduction to Software Engineering" sub-topic) से सवाल अक्सर पूछे जाते हैं — difficulty level "Medium"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What specific risk does the 'requirements freeze' conce... What is the 'modified waterfall' and how does it addres... What does the 'operational concept' document serve in a... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
291 Question 291 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. समीक्षाओं के माध्यम से चरणबद्ध नियंत्रण प्रारंभिक पहचान को अधिकतम करता है। 🎯 Exam Perspective अगर आप SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं, तो Software Engineering ("Introduction to Software Engineering" sub-topic) का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Easy"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions In a Waterfall project, what is the specific purpose of... What is the 'planning game' in XP and how does it distr... What specific risk does the 'requirements freeze' conce... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
292 Question 292 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 संभावित इंटरैक्शन कारण होते हैं। वृद्धिशील एकीकरण (ऊपर से नीचे, नीचे से ऊपर, सैंडविच) एक समय में एक घटक जोड़ता है - कोई भी नई विफलता लगभग निश्चित रूप से सबसे हाल ही में जोड़े गए घटक के कारण होती है, जो गलती अलगाव को नाटकीय रूप से सरल बनाती है। 🎯 Exam Perspective Software Engineering ("Introduction to Software Engineering" sub-topic) के इस प्रश्न को — difficulty level "Medium" कई प्रतियोगी परीक्षाओं जैसे SSC CGL, IBPS, RRB और State-level परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is 'feature-driven development' (FDD) and what dis... What is the 'anchor point milestone' LCA (Life Cycle Ar... What is the 'planning game' in XP and how does it distr... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
293 Question 293 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 पेपर ने पहले से ही आसन्न चरणों के बीच फीडबैक लूप की सिफारिश की थी। 'संशोधित झरना' इसे औपचारिक रूप देता है: चरण अभी भी काफी हद तक अनुक्रमिक हैं, लेकिन पिछले चरण में नियंत्रित पुनरावृत्ति की अनुमति तब दी जाती है जब खोजों को इसकी आवश्यकता होती है - संरचित प्रगति को बनाए रखते हुए पूर्ण पुनरारंभ की भयावह लागत को रोकना। 🎯 Exam Perspective यह सवाल Software Engineering ("Introduction to Software Engineering" sub-topic) category का है — difficulty level "Medium", और UPSC, SSC, Banking और Police भर्ती के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What was the key historical lesson learned from the US... Why is the 'big bang integration' testing approach part... What is the 'anchor point milestone' LCA (Life Cycle Ar... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
294 Question 294 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-वर्षीय सरकारी प्रणाली उन नियमों के आधार पर आवश्यकताओं को निर्दिष्ट कर सकती है जिन्हें अद्यतन किया गया है, व्यावसायिक प्रक्रियाएं जो बदल गई हैं, या प्रौद्योगिकी धारणाएं जो अब अप्रचलित हैं - वितरित प्रणाली को उपयोग करने से पहले ही अमान्य बना देती है। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Introduction to Software Engineering" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Medium"। इस तरह के प्रश्न अक्सर SSC, Railway, Banking और State PCS जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is the 'anchor point milestone' LCA (Life Cycle Ar... In a Spiral project for a missile guidance system, duri... What is 'feature-driven development' (FDD) and what dis... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
295 Question 295 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. व्याख्या (हिन्दी) सॉफ़्टवेयर डेवलपमेंट नोटबुक (क्लीनरूम और औपचारिक तरीकों के अभ्यास से) निर्णयों के पीछे 'क्यों' का दस्तावेजीकरण करती है - न कि केवल क्या बनाया गया था, बल्कि विकल्पों को अस्वीकार क्यों किया गया था। यह महत्वपूर्ण है क्योंकि डेवलपर्स के जाने पर उनके दिमाग का गुप्त ज्ञान खो जाता है, जिससे पहले से तय किए गए प्रश्नों की दोबारा जांच महंगी पड़ जाती है। 🎯 Exam Perspective Software Engineering ("Introduction to Software Engineering" sub-topic) से जुड़ा यह सवाल — difficulty level "Medium" उन students के लिए काम का है जो SSC CGL, IBPS, RRB और State-level परीक्षाओं की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What is 'phase containment' in a Waterfall project and... What is 'continuous experimentation' in modern software... What is 'feature-driven development' (FDD) and what dis... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
296 Question 296 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) तकनीकी आवश्यकताओं को लिखे जाने से पहले सिस्टम संचालन के बारे में उपयोगकर्ता के दृष्टिकोण को स्थापित करता है। उपयोगकर्ताओं/ऑपरेटरों द्वारा निर्मित, यह वर्णन करता है कि सिस्टम का उपयोग कौन करता है, कैसे, किस वातावरण में और यह किस मिशन का समर्थन करता है - परिचालन वास्तविकता में बाद की तकनीकी आवश्यकताओं को पूरा करता है। 🎯 Exam Perspective UPSC, SSC, Banking और Police भर्ती जैसी परीक्षाओं में Software Engineering ("Introduction to Software Engineering" sub-topic) से सवाल अक्सर पूछे जाते हैं — difficulty level "Easy"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What is 'continuous experimentation' in modern software... Why is the 'big bang integration' testing approach part... What was the key historical lesson learned from the US... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
297 Question 297 EN + हिं Medium GB What was the key historical lesson learned from the US DoD's use of Waterfall (MIL-STD-2167) for defence software? IN रक्षा सॉफ्टवेयर के लिए यूएस DoD द्वारा वॉटरफॉल (MIL-STD-2167) के उपयोग से क्या महत्वपूर्ण ऐतिहासिक सबक सीखा गया? A Waterfall was proven to be the optimal process for all defence systems and remains mandatory today झरना सभी रक्षा प्रणालियों के लिए सर्वोत्तम प्रक्रिया साबित हुई है और आज भी अनिवार्य है B DoD found that rigid document-driven Waterfall produced systems that were late, over budget, and often failed to meet operational needs — leading to replacement with iterative methods (MIL-STD-498, then DoD's adoption of agile) DoD ने पाया कि कठोर दस्तावेज़-संचालित वॉटरफ़ॉल ने ऐसी प्रणालियाँ तैयार कीं जो देर से, बजट से अधिक थीं, और अक्सर परिचालन आवश्यकताओं को पूरा करने में विफल रहीं - जिसके कारण पुनरावृत्त तरीकों (MIL-STD-498, फिर DoD द्वारा एजाइल को अपनाना) को प्रतिस्थापित किया गया। C The lesson was that more documentation was needed; subsequent standards doubled mandatory document count सबक यह था कि अधिक दस्तावेज़ीकरण की आवश्यकता थी; बाद के मानकों ने अनिवार्य दस्तावेज़ संख्या दोगुनी कर दी D DoD found Waterfall perfect for software but unsuitable for hardware development DoD ने वॉटरफॉल को सॉफ़्टवेयर के लिए तो उपयुक्त पाया लेकिन हार्डवेयर विकास के लिए अनुपयुक्त पाया ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) A 1994 GAO report found that of $37B spent on defence software, vast amounts were delivered but unusable, used as-is but significantly modified, or abandoned. This failure drove DoD to replace MIL-STD-2167 with more flexible standards and eventually embrace iterative/agile approaches. This case study became the canonical argument against rigid Waterfall for complex systems. व्याख्या (हिन्दी) 1994 की जीएओ रिपोर्ट में पाया गया कि रक्षा सॉफ्टवेयर पर खर्च किए गए 37 अरब डॉलर में से बड़ी मात्रा में वितरित किए गए लेकिन अनुपयोगी थे, वैसे ही उपयोग किए गए लेकिन महत्वपूर्ण रूप से संशोधित किए गए, या छोड़ दिए गए। इस विफलता ने DoD को MIL-STD-2167 को अधिक लचीले मानकों से बदलने के लिए प्रेरित किया और अंततः पुनरावृत्त/चतुर तरीकों को अपनाया। यह केस अध्ययन जटिल प्रणालियों के लिए कठोर झरने के विरुद्ध विहित तर्क बन गया। 🎯 Exam Perspective अगर आप SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं, तो Software Engineering ("Introduction to Software Engineering" sub-topic) का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Medium"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions What is 'model-driven engineering' (MDE) and what funda... What is the 'software development notebook' in a Waterf... What is 'continuous experimentation' in modern software... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
298 Question 298 EN + हिं Easy GB In a Spiral project for a missile guidance system, during cycle 2 the prototype demonstrates that the required navigation accuracy cannot be achieved with current sensor technology. What is the correct Spiral response? IN मिसाइल मार्गदर्शन प्रणाली के लिए एक सर्पिल परियोजना में, चक्र 2 के दौरान प्रोटोटाइप दर्शाता है कि वर्तमान सेंसर तकनीक के साथ आवश्यक नेविगेशन सटीकता प्राप्त नहीं की जा सकती है। सही सर्पिल प्रतिक्रिया क्या है? A Continue to cycle 3 with the current sensors and reduce requirements to match capability वर्तमान सेंसर के साथ चक्र 3 जारी रखें और क्षमता से मेल खाने के लिए आवश्यकताओं को कम करें B The risk finding should halt further development investment until the sensor technology gap is resolved through: sourcing better sensors, redesigning the algorithm to work with available accuracy, or revising the system requirements with stakeholders जब तक सेंसर प्रौद्योगिकी अंतर का समाधान नहीं हो जाता, तब तक जोखिम का पता लगाने के लिए आगे के विकास निवेश को रोक देना चाहिए: बेहतर सेंसर की सोर्सिंग, उपलब्ध सटीकता के साथ काम करने के लिए एल्गोरिदम को फिर से डिजाइन करना, या हितधारकों के साथ सिस्टम आवश्यकताओं को संशोधित करना। C Report the technical failure to management and continue development on schedule regardless प्रबंधन को तकनीकी विफलता की रिपोर्ट करें और इसकी परवाह किए बिना निर्धारित समय पर विकास जारी रखें D Spiral methodology does not apply to hardware-dependent systems like guidance systems सर्पिल कार्यप्रणाली मार्गदर्शन प्रणालियों जैसे हार्डवेयर-निर्भर प्रणालियों पर लागू नहीं होती है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Cycle 2's prototype has performed its function: it has identified a critical technical risk early when it is cheapest to address. Continuing to invest in a system with a known fatal technical constraint would be exactly the waste the Spiral model is designed to prevent. The risk resolution options (better sensors, algorithm redesign, requirements relaxation) are all legitimate Spiral responses. व्याख्या (हिन्दी) साइकिल 2 के प्रोटोटाइप ने अपना कार्य पूरा कर लिया है: इसने एक गंभीर तकनीकी जोखिम की पहचान पहले ही कर ली है, जबकि इसका समाधान करना सबसे सस्ता है। एक ज्ञात घातक तकनीकी बाधा वाले सिस्टम में निवेश जारी रखना ठीक वैसी ही बर्बादी होगी जिसे रोकने के लिए स्पाइरल मॉडल डिज़ाइन किया गया है। जोखिम समाधान विकल्प (बेहतर सेंसर, एल्गोरिदम रीडिज़ाइन, आवश्यकताओं में छूट) सभी वैध सर्पिल प्रतिक्रियाएँ हैं। 🎯 Exam Perspective Software Engineering ("Introduction to Software Engineering" sub-topic) के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे Railway, SSC, Banking और Defence परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions Why is the 'big bang integration' testing approach part... What specific risk does the 'requirements freeze' conce... What is the 'planning game' in XP and how does it distr... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
299 Question 299 EN + हिं Easy GB What is the 'anchor point milestone' LCA (Life Cycle Architecture) in the Win-Win Spiral and what must it demonstrate? IN विन-विन स्पाइरल में 'एंकर प्वाइंट मील का पत्थर' एलसीए (जीवन चक्र वास्तुकला) क्या है और इसे क्या प्रदर्शित करना चाहिए? A LCA demonstrates that the software code passes all unit tests with 100% coverage एलसीए दर्शाता है कि सॉफ्टवेयर कोड 100% कवरेज के साथ सभी यूनिट परीक्षणों को पास करता है B LCA must demonstrate that the architecture is stable enough to support the full system, that all top architectural risks have been resolved, and that the construction phase can proceed without fundamental architectural rework एलसीए को यह प्रदर्शित करना होगा कि वास्तुकला पूरी प्रणाली का समर्थन करने के लिए पर्याप्त रूप से स्थिर है, कि सभी शीर्ष वास्तुशिल्प जोखिमों का समाधान हो गया है, और निर्माण चरण मौलिक वास्तुशिल्प पुनर्निर्माण के बिना आगे बढ़ सकता है C LCA is achieved when all UML diagrams have been reviewed and approved by the customer एलसीए तब प्राप्त होता है जब ग्राहक द्वारा सभी यूएमएल आरेखों की समीक्षा और अनुमोदन किया गया हो D LCA requires all hardware components to be physically available and tested एलसीए को सभी हार्डवेयर घटकों को भौतिक रूप से उपलब्ध और परीक्षण करने की आवश्यकता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) LCA (equivalent to UP's Elaboration milestone) is the critical Spiral gate before major construction investment. It requires: an architectural prototype showing key risks are resolved, a credible cost/schedule estimate for remaining work, stakeholder agreement to proceed, and elimination of fundamental uncertainties that would require architectural redesign in construction. व्याख्या (हिन्दी) एलसीए (यूपी के विस्तार मील के पत्थर के बराबर) प्रमुख निर्माण निवेश से पहले महत्वपूर्ण सर्पिल द्वार है। इसके लिए आवश्यक है: प्रमुख जोखिमों को हल करने वाला एक वास्तुशिल्प प्रोटोटाइप, शेष कार्य के लिए एक विश्वसनीय लागत/अनुसूची अनुमान, आगे बढ़ने के लिए हितधारक समझौता, और मूलभूत अनिश्चितताओं का उन्मूलन जिसके लिए निर्माण में वास्तुशिल्प पुन: डिज़ाइन की आवश्यकता होगी। 🎯 Exam Perspective यह सवाल Software Engineering ("Introduction to Software Engineering" sub-topic) category का है — difficulty level "Easy", और UPSC, SSC, Banking और Police भर्ती के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What was the key historical lesson learned from the US... What is 'continuous experimentation' in modern software... What is 'feature-driven development' (FDD) and what dis... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)
300 Question 300 EN + हिं Medium GB What is the 'planning game' in XP and how does it distribute planning responsibility? IN XP में 'प्लानिंग गेम' क्या है और यह प्लानिंग जिम्मेदारी कैसे वितरित करता है? A The planning game is a tool for estimating story points using poker cards exclusively प्लानिंग गेम विशेष रूप से पोकर कार्ड का उपयोग करके कहानी के बिंदुओं का अनुमान लगाने का एक उपकरण है B The planning game splits responsibility: business decides scope and priority (story selection, release dates); technology decides estimates and technical approach (how long, how to implement) — neither can override the other's domain नियोजन का खेल जिम्मेदारी को विभाजित करता है: व्यवसाय दायरा और प्राथमिकता तय करता है (कहानी का चयन, रिलीज की तारीखें); प्रौद्योगिकी अनुमान और तकनीकी दृष्टिकोण (कब तक, कैसे लागू करना है) तय करती है - कोई भी दूसरे के डोमेन को ओवरराइड नहीं कर सकता है C In XP, project managers alone conduct the planning game without developer input एक्सपी में, प्रोजेक्ट मैनेजर अकेले ही डेवलपर इनपुट के बिना प्लानिंग गेम संचालित करते हैं D The planning game replaces all other ceremonies in XP, making retrospectives and reviews unnecessary नियोजन गेम XP में अन्य सभी समारोहों को प्रतिस्थापित कर देता है, जिससे पूर्वव्यापी और समीक्षाएँ अनावश्यक हो जाती हैं ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) XP's planning game separates concerns: business stakeholders have authority over WHAT gets built (scope, priority, release date) and technology team has authority over HOW LONG it takes and HOW it's implemented. Neither party can dictate in the other's domain — business cannot set estimates; technology cannot set business priority. This mutual constraint prevents both gold plating and unrealistic scheduling. व्याख्या (हिन्दी) XP's planning game separates concerns: business stakeholders have authority over WHAT gets built (scope, priority, release date) and technology team has authority over HOW LONG it takes and HOW it's implemented. कोई भी पक्ष दूसरे के क्षेत्र में आदेश नहीं दे सकता - व्यवसाय अनुमान निर्धारित नहीं कर सकता; प्रौद्योगिकी व्यावसायिक प्राथमिकता निर्धारित नहीं कर सकती। यह पारस्परिक बाधा सोना चढ़ाना और अवास्तविक शेड्यूलिंग दोनों को रोकती है। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Introduction to Software Engineering" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Medium"। इस तरह के प्रश्न अक्सर Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is the 'modified waterfall' and how does it addres... What is the 'anchor point milestone' LCA (Life Cycle Ar... What specific risk does the 'requirements freeze' conce... 📚 Related Topic Software Development Models (195) Waterfall Model (197) Spiral Model (236)