Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2131
EN + हिं Medium
GB In COCOMO II, what do 'scale factors' primarily represent?
IN COCOMO II में, 'स्केल कारक' मुख्य रूप से क्या दर्शाते हैं?
A
Ratio of actual to estimated lines of code कोड की वास्तविक और अनुमानित पंक्तियों का अनुपात
B
Factors affecting the exponential scaling of effort with project size such as team cohesion and process maturity प्रोजेक्ट आकार के साथ प्रयास की घातीय स्केलिंग को प्रभावित करने वाले कारक जैसे टीम सामंजस्य और प्रक्रिया परिपक्वता
C
Multiplier to convert LOC to function points LOC को फ़ंक्शन पॉइंट में बदलने के लिए गुणक
D
Cost per developer per month प्रति डेवलपर प्रति माह लागत
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) COCOMO II scale factors influence the exponent in the effort equation, controlling how effort scales non-linearly with size. Higher scale factors increase the exponent, making large projects disproportionately more costly.
व्याख्या (हिन्दी) COCOMO II पैमाने के कारक प्रयास समीकरण में घातांक को प्रभावित करते हैं, यह नियंत्रित करते हैं कि प्रयास आकार के साथ गैर-रैखिक रूप से कैसे बढ़ता है। उच्च पैमाने के कारक घातांक को बढ़ाते हैं, जिससे बड़ी परियोजनाएं अनुपातहीन रूप से अधिक महंगी हो जाती हैं।
2132
EN + हिं Easy
GB Which of the following best exemplifies a 'wicked problem' in software engineering?
IN निम्नलिखित में से कौन सॉफ्टवेयर इंजीनियरिंग में 'दुष्ट समस्या' का सबसे अच्छा उदाहरण है?
A
Implementing a well-defined sorting algorithm in a new language एक नई भाषा में एक अच्छी तरह से परिभाषित सॉर्टिंग एल्गोरिदम लागू करना
B
Designing a national healthcare system where requirements are contradictory and no clear solution exists एक ऐसी राष्ट्रीय स्वास्थ्य देखभाल प्रणाली तैयार करना जहां आवश्यकताएं विरोधाभासी हों और कोई स्पष्ट समाधान मौजूद न हो
C
Fixing a null pointer exception in a deployed web application तैनात वेब एप्लिकेशन में एक शून्य सूचक अपवाद को ठीक करना
D
Migrating a database following a documented migration plan दस्तावेज़ीकृत माइग्रेशन योजना के बाद डेटाबेस को माइग्रेट करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Wicked problems (Rittel and Webber) have no definitive formulation, no stopping rule, and solutions that are good-or-bad rather than true/false. Complex sociotechnical systems like national healthcare platforms exemplify this.
व्याख्या (हिन्दी) दुष्ट समस्याओं (रिटेल और वेबर) का कोई निश्चित सूत्रीकरण नहीं है, कोई रोकने का नियम नहीं है, और समाधान सही/गलत के बजाय अच्छे या बुरे हैं। राष्ट्रीय स्वास्थ्य सेवा मंच जैसी जटिल सामाजिक-तकनीकी प्रणालियाँ इसका उदाहरण हैं।
2133
EN + हिं Medium
GB Why can historical analogy cost estimation produce highly inaccurate results?
IN ऐतिहासिक सादृश्य लागत अनुमान अत्यधिक गलत परिणाम क्यों उत्पन्न कर सकता है?
A
Historical projects always use different programming languages ऐतिहासिक परियोजनाएँ हमेशा विभिन्न प्रोग्रामिंग भाषाओं का उपयोग करती हैं
B
Subtle differences in team skill, domain complexity, technology, and organisational context between reference and new project are hard to quantify and often overlooked संदर्भ और नई परियोजना के बीच टीम कौशल, डोमेन जटिलता, प्रौद्योगिकी और संगठनात्मक संदर्भ में सूक्ष्म अंतर को मापना कठिन है और अक्सर इसे अनदेखा कर दिया जाता है।
C
Historical data is never in a compatible format ऐतिहासिक डेटा कभी भी संगत प्रारूप में नहीं होता है
D
Analogy requires at least ten reference projects सादृश्य के लिए कम से कम दस संदर्भ परियोजनाओं की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Analogy-based estimation assumes the new project is sufficiently similar to historical ones. Even seemingly similar projects differ in team experience, culture, technology maturity, and domain nuances — factors difficult to capture quantitatively, leading to systematic bias.
व्याख्या (हिन्दी) सादृश्य-आधारित अनुमान मानता है कि नई परियोजना ऐतिहासिक परियोजनाओं के समान ही है। यहां तक ​​​​कि प्रतीत होता है कि समान परियोजनाएं टीम के अनुभव, संस्कृति, प्रौद्योगिकी परिपक्वता और डोमेन बारीकियों में भिन्न होती हैं - कारकों को मात्रात्मक रूप से पकड़ना मुश्किल होता है, जिससे व्यवस्थित पूर्वाग्रह होता है।
2134
EN + हिं Medium
GB What fundamental problem did the 'software crisis' of the 1960s highlight?
IN 1960 के दशक के 'सॉफ्टवेयर संकट' ने किस मूलभूत समस्या को उजागर किया?
A
Insufficient hardware to run large software systems बड़े सॉफ़्टवेयर सिस्टम को चलाने के लिए अपर्याप्त हार्डवेयर
B
Inability of informal ad-hoc methods to reliably deliver large software on time, within budget, and with acceptable quality बड़े सॉफ़्टवेयर को समय पर, बजट के भीतर और स्वीकार्य गुणवत्ता के साथ विश्वसनीय रूप से वितरित करने में अनौपचारिक तदर्थ तरीकों की असमर्थता
C
Lack of qualified assembly language programmers योग्य असेम्बली भाषा प्रोग्रामरों की कमी
D
High cost of computer time compared to programmer salaries प्रोग्रामर के वेतन की तुलना में कंप्यूटर समय की उच्च लागत
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 1960s software crisis arose because projects regularly overran budgets, missed deadlines, and delivered unreliable products. This drove the 1968 NATO conference and the subsequent discipline of software engineering.
व्याख्या (हिन्दी) 1960 के दशक का सॉफ़्टवेयर संकट इसलिए उत्पन्न हुआ क्योंकि परियोजनाएँ नियमित रूप से बजट से आगे निकल गईं, समय सीमा चूक गईं और अविश्वसनीय उत्पाद वितरित किए गए। इसने 1968 के नाटो सम्मेलन और उसके बाद सॉफ्टवेयर इंजीनियरिंग के अनुशासन को आगे बढ़ाया।
2135
EN + हिं Medium
GB Which process model is most appropriate when requirements are poorly understood and likely to change significantly?
IN जब आवश्यकताओं को कम समझा जाता है और महत्वपूर्ण रूप से बदलने की संभावना होती है तो कौन सा प्रक्रिया मॉडल सबसे उपयुक्त होता है?
A
Waterfall model झरना मॉडल
B
V-model वि मॉडल
C
Evolutionary/Iterative model विकासवादी/पुनरावृत्तीय मॉडल
D
Formal transformation model औपचारिक परिवर्तन मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Evolutionary/iterative models are designed for unstable requirements. They deliver working increments, gather feedback, and refine requirements iteratively. Waterfall and V-model require stable requirements upfront.
व्याख्या (हिन्दी) विकासवादी/पुनरावृत्त मॉडल अस्थिर आवश्यकताओं के लिए डिज़ाइन किए गए हैं। वे कामकाजी वेतन वृद्धि प्रदान करते हैं, फीडबैक एकत्र करते हैं और आवश्यकताओं को क्रमिक रूप से परिष्कृत करते हैं। वॉटरफ़ॉल और वी-मॉडल को पहले से ही स्थिर आवश्यकताओं की आवश्यकता होती है।
2136
EN + हिं Easy
GB What is the core criticism of using Lines of Code (LOC) as a software productivity metric?
IN सॉफ्टवेयर उत्पादकता मीट्रिक के रूप में लाइन्स ऑफ कोड (एलओसी) का उपयोग करने की मुख्य आलोचना क्या है?
A
LOC cannot be counted automatically LOC की गणना स्वचालित रूप से नहीं की जा सकती
B
LOC incentivises verbose redundant code, penalises elegant solutions, varies with language, and counts non-functional code एलओसी वर्बोज़ अनावश्यक कोड को प्रोत्साहित करता है, सुरुचिपूर्ण समाधानों को दंडित करता है, भाषा के साथ बदलता रहता है, और गैर-कार्यात्मक कोड को गिनता है
C
LOC only applies to procedural languages LOC केवल प्रक्रियात्मक भाषाओं पर लागू होती है
D
LOC is not recognised by any international standard एलओसी को किसी भी अंतरराष्ट्रीय मानक द्वारा मान्यता प्राप्त नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) LOC is a poor productivity metric because it rewards code volume over quality. A developer writing 500 elegant tested lines contributes more than one writing 2,000 bloated lines. It also varies across languages and counts blank lines, comments, and boilerplate.
व्याख्या (हिन्दी) LOC एक खराब उत्पादकता मीट्रिक है क्योंकि यह गुणवत्ता की तुलना में कोड वॉल्यूम को अधिक महत्व देता है। 500 सुंदर परीक्षणित पंक्तियाँ लिखने वाला एक डेवलपर 2,000 फूली हुई पंक्तियाँ लिखने से अधिक का योगदान देता है। यह विभिन्न भाषाओं में भी भिन्न होता है और रिक्त पंक्तियों, टिप्पणियों और बॉयलरप्लेट को गिनता है।
2137
EN + हिं Medium
GB In Rapid Application Development (RAD), which condition is MOST critical for successful application?
IN रैपिड एप्लिकेशन डेवलपमेंट (आरएडी) में, सफल एप्लिकेशन के लिए कौन सी स्थिति सबसे महत्वपूर्ण है?
A
Project must use only open-source tools प्रोजेक्ट को केवल ओपन-सोर्स टूल का उपयोग करना चाहिए
B
Active and continuous user involvement throughout the development cycle पूरे विकास चक्र में सक्रिय और निरंतर उपयोगकर्ता भागीदारी
C
Development team must have fewer than five members विकास दल में पाँच से कम सदस्य होने चाहिए
D
System must use only visual programming tools सिस्टम को केवल विज़ुअल प्रोग्रामिंग टूल का उपयोग करना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RAD depends on rapid prototyping and iterative feedback cycles with users. Without active, continuous user participation to review prototypes and clarify requirements, RAD devolves into unguided iteration producing a system that fails to meet actual needs.
व्याख्या (हिन्दी) आरएडी उपयोगकर्ताओं के साथ तेजी से प्रोटोटाइप और पुनरावृत्त प्रतिक्रिया चक्र पर निर्भर करता है। प्रोटोटाइप की समीक्षा करने और आवश्यकताओं को स्पष्ट करने के लिए सक्रिय, निरंतर उपयोगकर्ता भागीदारी के बिना, आरएडी एक ऐसी प्रणाली का निर्माण करने वाले अनिर्देशित पुनरावृत्ति में बदल जाता है जो वास्तविक जरूरतों को पूरा करने में विफल रहता है।
2138
EN + हिं Medium
GB What distinguishes a 'process model' from a 'process' in software engineering?
IN सॉफ़्टवेयर इंजीनियरिंग में 'प्रक्रिया मॉडल' को 'प्रक्रिया' से क्या अलग करता है?
A
A process model is theoretical; a process is the actual enactment of activities in a specific project context एक प्रक्रिया मॉडल सैद्धांतिक है; एक प्रक्रिया एक विशिष्ट परियोजना संदर्भ में गतिविधियों का वास्तविक अधिनियमन है
B
A process model includes budget estimates; a process does not एक प्रक्रिया मॉडल में बजट अनुमान शामिल होते हैं; एक प्रक्रिया नहीं है
C
A process model applies to large projects only एक प्रक्रिया मॉडल केवल बड़ी परियोजनाओं पर लागू होता है
D
A process is defined by management; process model by developers एक प्रक्रिया प्रबंधन द्वारा परिभाषित की जाती है; डेवलपर्स द्वारा प्रक्रिया मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A process model is an abstract generalised framework (Waterfall, Spiral) describing the typical structure of a development approach. A process is the specific instantiation of that model in a real project — tailored and enacted within actual resource and organisational constraints.
व्याख्या (हिन्दी) एक प्रक्रिया मॉडल एक अमूर्त सामान्यीकृत ढांचा (झरना, सर्पिल) है जो विकास दृष्टिकोण की विशिष्ट संरचना का वर्णन करता है। एक प्रक्रिया एक वास्तविक परियोजना में उस मॉडल की विशिष्ट तात्कालिकता है - वास्तविक संसाधन और संगठनात्मक बाधाओं के भीतर तैयार और अधिनियमित।
2139
EN + हिं Medium
GB Which software development model explicitly incorporates risk analysis as a repeating activity in each iteration?
IN कौन सा सॉफ़्टवेयर विकास मॉडल स्पष्ट रूप से प्रत्येक पुनरावृत्ति में दोहराई जाने वाली गतिविधि के रूप में जोखिम विश्लेषण को शामिल करता है?
A
Waterfall model झरना मॉडल
B
Incremental model वृद्धिशील मॉडल
C
Spiral model सर्पिल मॉडल
D
Prototype model प्रोटोटाइप मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Barry Boehm's Spiral model is unique in making risk analysis an explicit quadrant in every iteration. Each spiral pass involves: planning, risk analysis and prototyping, engineering, and customer evaluation — making it ideal for large high-risk projects.
व्याख्या (हिन्दी) बैरी बोहेम का स्पाइरल मॉडल प्रत्येक पुनरावृत्ति में जोखिम विश्लेषण को एक स्पष्ट चतुर्थांश बनाने में अद्वितीय है। प्रत्येक सर्पिल पास में शामिल हैं: योजना, जोखिम विश्लेषण और प्रोटोटाइप, इंजीनियरिंग और ग्राहक मूल्यांकन - जो इसे बड़े उच्च जोखिम वाली परियोजनाओं के लिए आदर्श बनाता है।
2140
EN + हिं Medium
GB In Unified Process (UP), what is the purpose of the 'Elaboration' phase?
IN एकीकृत प्रक्रिया (यूपी) में, 'विस्तार' चरण का उद्देश्य क्या है?
A
To deploy the final system and train users अंतिम प्रणाली को तैनात करना और उपयोगकर्ताओं को प्रशिक्षित करना
B
To establish project scope, eliminate highest-risk elements, define architecture baseline, and refine requirements परियोजना का दायरा स्थापित करने के लिए, उच्चतम जोखिम वाले तत्वों को खत्म करें, वास्तुकला आधार रेखा को परिभाषित करें और आवश्यकताओं को परिष्कृत करें
C
To decompose the system into modules and assign to developers सिस्टम को मॉड्यूल में विघटित करना और डेवलपर्स को सौंपना
D
To collect initial requirements through stakeholder interviews हितधारकों के साक्षात्कार के माध्यम से प्रारंभिक आवश्यकताएँ एकत्र करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In UP's Elaboration phase, the goal is to mitigate the project's top architectural risks by building an architectural prototype, refining and stabilising the use-case model, and establishing a stable baseline for construction.
व्याख्या (हिन्दी) यूपी के विस्तार चरण में, लक्ष्य एक वास्तुशिल्प प्रोटोटाइप का निर्माण, उपयोग-केस मॉडल को परिष्कृत और स्थिर करना और निर्माण के लिए एक स्थिर आधार रेखा स्थापित करके परियोजना के शीर्ष वास्तुशिल्प जोखिमों को कम करना है।
2141
EN + हिं Medium
GB What is 'process tailoring' in software development, and why is it necessary?
IN सॉफ़्टवेयर विकास में 'प्रोसेस टेलरिंग' क्या है और यह क्यों आवश्यक है?
A
Writing custom code libraries to replace standard frameworks मानक फ्रेमवर्क को बदलने के लिए कस्टम कोड लाइब्रेरी लिखना
B
Adapting a standard process model to fit the specific constraints, size, domain, and team characteristics of a particular project किसी विशेष परियोजना की विशिष्ट बाधाओं, आकार, डोमेन और टीम विशेषताओं को फिट करने के लिए एक मानक प्रक्रिया मॉडल को अपनाना
C
Hiring specialised developers for niche technology domains विशिष्ट प्रौद्योगिकी डोमेन के लिए विशेष डेवलपर्स को नियुक्त करना
D
Automatically generating test cases from requirements specifications आवश्यकताओं के विनिर्देशों से स्वचालित रूप से परीक्षण मामले तैयार करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) No single process model suits all projects. Process tailoring adjusts documentation requirements, review gates, iteration length, and tool choices to match the project's risk profile, team size, customer expectations, and regulatory environment.
व्याख्या (हिन्दी) कोई भी एकल प्रक्रिया मॉडल सभी परियोजनाओं के लिए उपयुक्त नहीं है। प्रक्रिया सिलाई परियोजना के जोखिम प्रोफ़ाइल, टीम के आकार, ग्राहकों की अपेक्षाओं और नियामक वातावरण से मेल खाने के लिए दस्तावेज़ीकरण आवश्यकताओं, समीक्षा द्वार, पुनरावृत्ति की लंबाई और उपकरण विकल्पों को समायोजित करती है।
2142
EN + हिं Medium
GB Which metric best captures the 'goodness' of a software process rather than just output quality?
IN कौन सा मीट्रिक केवल आउटपुट गुणवत्ता के बजाय सॉफ़्टवेयर प्रक्रिया की 'अच्छाई' को सबसे अच्छी तरह से पकड़ता है?
A
Defect density of the released product जारी उत्पाद का दोष घनत्व
B
Process capability metrics such as defect removal efficiency and rework percentage across multiple projects प्रक्रिया क्षमता मेट्रिक्स जैसे दोष निवारण दक्षता और कई परियोजनाओं में पुन: कार्य प्रतिशत
C
Customer satisfaction survey scores from final release अंतिम रिलीज़ से ग्राहक संतुष्टि सर्वेक्षण स्कोर
D
Total LOC produced per developer per sprint प्रति स्प्रिंट प्रति डेवलपर द्वारा उत्पादित कुल एलओसी
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Process quality is distinct from product quality. Metrics like defect removal efficiency (DRE) and rework percentage across multiple projects reveal how reliably the process performs — independent of any single project's luck. These are the metrics CMM/CMMI use.
व्याख्या (हिन्दी) प्रक्रिया की गुणवत्ता उत्पाद की गुणवत्ता से भिन्न होती है। दोष निवारण दक्षता (डीआरई) और कई परियोजनाओं में पुनः कार्य प्रतिशत जैसे मेट्रिक्स से पता चलता है कि प्रक्रिया कितनी विश्वसनीय रूप से प्रदर्शन करती है - किसी एक परियोजना की किस्मत से स्वतंत्र। ये मेट्रिक्स सीएमएम/सीएमएमआई उपयोग हैं।
2143
EN + हिं Easy
GB When switching from a plan-driven to an agile process mid-project, what is the most significant risk?
IN परियोजना के मध्य में योजना-चालित से तीव्र प्रक्रिया पर स्विच करते समय, सबसे महत्वपूर्ण जोखिम क्या है?
A
The project will fail because mixed methodologies are IEEE-forbidden परियोजना विफल हो जाएगी क्योंकि मिश्रित पद्धतियाँ IEEE-निषिद्ध हैं
B
Loss of traceability, incomplete documentation, team confusion about roles, and contractual conflicts with fixed-scope agreements ट्रेसेबिलिटी का नुकसान, अधूरा दस्तावेज, भूमिकाओं के बारे में टीम का भ्रम, और निश्चित दायरे वाले समझौतों के साथ संविदात्मक टकराव
C
Developers will refuse to work without additional compensation डेवलपर्स अतिरिक्त मुआवजे के बिना काम करने से इंकार कर देंगे
D
Agile processes require more powerful hardware चुस्त प्रक्रियाओं के लिए अधिक शक्तिशाली हार्डवेयर की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Mid-project process switching disrupts team rhythm, invalidates existing plans and contracts, creates documentation gaps (especially in regulated domains), and leaves roles unclear. Existing deliverables may not align with new process artefacts.
व्याख्या (हिन्दी) मध्य-परियोजना प्रक्रिया स्विचिंग टीम की लय को बाधित करती है, मौजूदा योजनाओं और अनुबंधों को अमान्य कर देती है, दस्तावेज़ीकरण अंतराल पैदा करती है (विशेषकर विनियमित डोमेन में), और भूमिकाएँ अस्पष्ट हो जाती हैं। मौजूदा डिलिवरेबल्स नई प्रक्रिया कलाकृतियों के साथ संरेखित नहीं हो सकते हैं।
2144
EN + हिं Medium
GB Why is discovering requirement errors during the testing phase fundamentally problematic in Waterfall?
IN वाटरफॉल में परीक्षण चरण के दौरान आवश्यकता त्रुटियों की खोज करना मौलिक रूप से समस्याग्रस्त क्यों है?
A
Testing phase has the smallest budget in a Waterfall project झरना परियोजना में परीक्षण चरण का बजट सबसे छोटा होता है
B
Requirement errors in testing necessitate traversing back through design and implementation, causing exponential cost escalation due to Waterfall's sequential nature परीक्षण में आवश्यकता त्रुटियों के कारण डिज़ाइन और कार्यान्वयन के माध्यम से वापस जाना आवश्यक हो जाता है, जिससे वॉटरफॉल की अनुक्रमिक प्रकृति के कारण लागत में तेजी से वृद्धि होती है।
C
Testers are not qualified to evaluate requirement-level defects परीक्षक आवश्यकता-स्तरीय दोषों का मूल्यांकन करने के लिए योग्य नहीं हैं
D
Testing environments are not connected to requirements systems परीक्षण वातावरण आवश्यकता प्रणालियों से जुड़े नहीं हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Waterfall's strict sequential phases mean a late-discovered requirement error invalidates downstream design and implementation work. Boehm showed that defects found in testing cost 100× more to fix than those found during requirements review.
व्याख्या (हिन्दी) वॉटरफ़ॉल के सख्त अनुक्रमिक चरणों का मतलब है कि देर से खोजी गई आवश्यकता त्रुटि डाउनस्ट्रीम डिज़ाइन और कार्यान्वयन कार्य को अमान्य कर देती है। बोहेम ने दिखाया कि परीक्षण में पाए गए दोषों को आवश्यकताओं की समीक्षा के दौरान पाए गए दोषों की तुलना में ठीक करने में 100× अधिक लागत आती है।
2145
EN + हिं Medium
GB Which characteristic of Waterfall makes it well-suited for safety-critical systems like avionics software?
IN वॉटरफॉल की कौन सी विशेषता इसे एवियोनिक्स सॉफ़्टवेयर जैसी सुरक्षा-महत्वपूर्ण प्रणालियों के लिए उपयुक्त बनाती है?
A
Waterfall supports continuous deployment for rapid safety patches झरना तेजी से सुरक्षा पैच के लिए निरंतर तैनाती का समर्थन करता है
B
Its emphasis on comprehensive upfront documentation and phase-gate reviews aligns with regulatory certification requirements like DO-178C व्यापक अग्रिम दस्तावेज़ीकरण और चरण-गेट समीक्षाओं पर इसका जोर डीओ-178सी जैसी नियामक प्रमाणन आवश्यकताओं के अनुरूप है
C
Waterfall allows users to modify requirements during implementation वॉटरफॉल उपयोगकर्ताओं को कार्यान्वयन के दौरान आवश्यकताओं को संशोधित करने की अनुमति देता है
D
Waterfall automatically detects hardware failures during testing परीक्षण के दौरान वॉटरफॉल स्वचालित रूप से हार्डवेयर विफलताओं का पता लगाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Standards like DO-178C (avionics) and IEC 61508 require extensive traceability and formal review/approval gates. Waterfall's phase structure naturally produces this documented trail, which is why safety-critical industries have historically favoured it.
व्याख्या (हिन्दी) DO-178C (एवियोनिक्स) और IEC 61508 जैसे मानकों के लिए व्यापक ट्रैसेबिलिटी और औपचारिक समीक्षा/अनुमोदन द्वार की आवश्यकता होती है। झरने की चरण संरचना स्वाभाविक रूप से इस दस्तावेजी निशान का निर्माण करती है, यही कारण है कि सुरक्षा-महत्वपूर्ण उद्योगों ने ऐतिहासिक रूप से इसका समर्थन किया है।
2131–2145 of 2726