Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
436
EN + हिं Easy
GB What is the core principle behind TDD and what design benefit does it provide beyond defect reduction?
IN टीडीडी के पीछे मूल सिद्धांत क्या है और यह दोष कम करने के अलावा क्या डिज़ाइन लाभ प्रदान करता है?
A
Tests written by QA after development to verify functionality कार्यक्षमता को सत्यापित करने के लिए विकास के बाद क्यूए द्वारा लिखे गए परीक्षण
B
TDD's Red-Green-Refactor cycle writes tests before code; beyond defect reduction it forces testable design (high cohesion, low coupling, DI) because untestable code cannot pass tests written before implementation टीडीडी का रेड-ग्रीन-रिफैक्टर चक्र कोड से पहले परीक्षण लिखता है; दोष कम करने से परे यह परीक्षण योग्य डिज़ाइन (उच्च सामंजस्य, कम युग्मन, डीआई) को मजबूर करता है क्योंकि अप्राप्य कोड कार्यान्वयन से पहले लिखे गए परीक्षणों को पास नहीं कर सकता है
C
Only beneficial for unit tests; no value for integration or system testing केवल इकाई परीक्षणों के लिए फायदेमंद; एकीकरण या सिस्टम परीक्षण के लिए कोई मूल्य नहीं
D
Guarantees zero defects if all tests pass before deployment यदि तैनाती से पहले सभी परीक्षण पास हो जाते हैं तो शून्य दोष की गारंटी देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) TDD's primary design benefit is forcing testability. If you cannot write a test for functionality before implementing it, the design is likely wrong. TDD acts as real-time design feedback, naturally producing decoupled injectable single-responsibility code.
व्याख्या (हिन्दी) टीडीडी का प्राथमिक डिज़ाइन लाभ परीक्षण योग्यता को बाध्य करना है। यदि आप इसे लागू करने से पहले कार्यक्षमता के लिए परीक्षण नहीं लिख सकते हैं, तो संभवतः डिज़ाइन गलत है। टीडीडी वास्तविक समय डिज़ाइन फीडबैक के रूप में कार्य करता है, जो स्वाभाविक रूप से डिकॉउल्ड इंजेक्टेबल सिंगल-जिम्मेदारी कोड का उत्पादन करता है।
437
EN + हिं Medium
GB What distinguishes 'alpha testing' from 'beta testing' and in what order do they occur?
IN 'अल्फा परीक्षण' को 'बीटा परीक्षण' से क्या अलग करता है और वे किस क्रम में होते हैं?
A
Beta testing occurs first with internal users; alpha testing follows with external users बीटा परीक्षण सबसे पहले आंतरिक उपयोगकर्ताओं के साथ होता है; अल्फा परीक्षण बाहरी उपयोगकर्ताओं के साथ होता है
B
Alpha testing is conducted at the developer's site by internal users in a controlled environment before beta; beta testing is then by selected external users in their real-world environments अल्फा परीक्षण बीटा से पहले नियंत्रित वातावरण में आंतरिक उपयोगकर्ताओं द्वारा डेवलपर की साइट पर आयोजित किया जाता है; बीटा परीक्षण तब चयनित बाहरी उपयोगकर्ताओं द्वारा उनके वास्तविक दुनिया के वातावरण में किया जाता है
C
Alpha and beta testing are conducted simultaneously अल्फा और बीटा परीक्षण एक साथ आयोजित किए जाते हैं
D
Alpha is automated; beta is always manual अल्फ़ा स्वचालित है; बीटा हमेशा मैन्युअल होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Alpha testing precedes beta: done in-house under controlled conditions where testers can observe user behaviour and collect detailed logs. Beta testing exposes the product to real users in real environments — uncovering hardware/OS configuration issues and real-world edge cases.
व्याख्या (हिन्दी) अल्फा परीक्षण बीटा से पहले होता है: नियंत्रित परिस्थितियों में घर में किया जाता है जहां परीक्षक उपयोगकर्ता के व्यवहार का निरीक्षण कर सकते हैं और विस्तृत लॉग एकत्र कर सकते हैं। बीटा परीक्षण उत्पाद को वास्तविक वातावरण में वास्तविक उपयोगकर्ताओं के सामने उजागर करता है - हार्डवेयर/ओएस कॉन्फ़िगरेशन समस्याओं और वास्तविक दुनिया के किनारे के मामलों को उजागर करता है।
438
EN + हिं
GB What is a 'memory leak' in a managed language like Java and why is it still possible despite garbage collection?
IN जावा जैसी प्रबंधित भाषा में 'मेमोरी लीक' क्या है और कचरा संग्रहण के बावजूद यह अभी भी क्यों संभव है?
A
Memory leaks cannot occur in managed languages प्रबंधित भाषाओं में मेमोरी लीक नहीं हो सकती
B
A logical memory leak occurs when objects are still referenced (preventing GC) but no longer needed — common causes: static collections holding objects, event handlers not unregistered, and caches without eviction policies एक तार्किक मेमोरी रिसाव तब होता है जब ऑब्जेक्ट अभी भी संदर्भित होते हैं (जीसी को रोकते हैं) लेकिन अब इसकी आवश्यकता नहीं है - सामान्य कारण: ऑब्जेक्ट रखने वाले स्थिर संग्रह, अपंजीकृत नहीं होने वाले ईवेंट हैंडलर, और निष्कासन नीतियों के बिना कैश
C
Only occur when using native interop calls (P/Invoke, JNI) केवल देशी इंटरऑप कॉल (पी/इनवोक, जेएनआई) का उपयोग करते समय होता है
D
Modern JVMs completely eliminate all forms of memory leaks आधुनिक जेवीएम सभी प्रकार की मेमोरी लीक को पूरी तरह से समाप्त कर देते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Garbage collection collects objects with no reachable references. A 'logical leak' means the application holds a reference it doesn't need. Classic example: adding event handlers to a long-lived object without removing them keeps the subscriber alive for the publisher's lifetime.
व्याख्या (हिन्दी) कचरा संग्रहण उन वस्तुओं को एकत्रित करता है जिनका कोई पहुंच योग्य संदर्भ नहीं है। 'लॉजिकल लीक' का मतलब है कि एप्लिकेशन के पास ऐसा संदर्भ है जिसकी उसे आवश्यकता नहीं है। उत्कृष्ट उदाहरण: ईवेंट हैंडलर को लंबे समय तक मौजूद ऑब्जेक्ट में हटाए बिना जोड़ने से सब्सक्राइबर प्रकाशक के जीवनकाल तक जीवित रहता है।
439
EN + हिं Easy
GB What is 'symbolic execution' in program analysis and what are its scalability limitations?
IN प्रोग्राम विश्लेषण में 'प्रतीकात्मक निष्पादन' क्या है और इसकी स्केलेबिलिटी सीमाएँ क्या हैं?
A
Developers draw flowcharts instead of executing code डेवलपर्स कोड निष्पादित करने के बजाय फ़्लोचार्ट बनाते हैं
B
Running a program with symbolic rather than concrete inputs, tracking path conditions — enabling automatic test case generation and bug finding; limited by path explosion (exponential path count as branches grow) and constraint solving complexity ठोस इनपुट के बजाय प्रतीकात्मक के साथ एक प्रोग्राम चलाना, पथ स्थितियों पर नज़र रखना - स्वचालित परीक्षण केस पीढ़ी और बग ढूंढने को सक्षम करना; पथ विस्फोट (शाखाओं के बढ़ने पर घातीय पथ गणना) और बाधा समाधान जटिलता द्वारा सीमित
C
Manually tracing code with pencil and paper to find logic errors तार्किक त्रुटियों को खोजने के लिए पेंसिल और कागज से कोड को मैन्युअल रूप से ट्रेस करना
D
Only works for programs without loops or recursive calls केवल लूप या पुनरावर्ती कॉल के बिना प्रोग्राम के लिए काम करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Symbolic execution represents inputs as symbols and uses SMT solvers to determine which inputs trigger which paths. It can generate inputs exercising specific paths or prove safety properties. The path explosion problem: a program with n independent branches has 2^n paths, making full exploration infeasible.
व्याख्या (हिन्दी) प्रतीकात्मक निष्पादन इनपुट को प्रतीकों के रूप में दर्शाता है और यह निर्धारित करने के लिए एसएमटी सॉल्वर का उपयोग करता है कि कौन सा इनपुट किस पथ को ट्रिगर करता है। यह विशिष्ट पथों का उपयोग करते हुए इनपुट उत्पन्न कर सकता है या सुरक्षा गुणों को साबित कर सकता है। पथ विस्फोट समस्या: n स्वतंत्र शाखाओं वाले एक प्रोग्राम में 2^n पथ होते हैं, जिससे पूर्ण अन्वेषण असंभव हो जाता है।
440
EN + हिं Easy
GB What is a 'race condition' and what property makes concurrent programs particularly hard to debug?
IN 'रेस कंडीशन' क्या है और कौन सी संपत्ति समवर्ती कार्यक्रमों को डीबग करना विशेष रूप से कठिन बनाती है?
A
Program runs faster than the test suite can check results प्रोग्राम परीक्षण सूट से अधिक तेजी से परिणाम की जांच कर सकता है
B
Correctness depends on relative timing of concurrent operations; non-determinism makes them hard to debug because failure may not occur on every execution, disappears under debugging, and manifests only under specific load patterns शुद्धता समवर्ती संचालन के सापेक्ष समय पर निर्भर करती है; गैर-नियतिवाद उन्हें डिबग करना कठिन बना देता है क्योंकि प्रत्येक निष्पादन पर विफलता नहीं हो सकती है, डिबगिंग के तहत गायब हो जाती है, और केवल विशिष्ट लोड पैटर्न के तहत प्रकट होती है
C
Only occur in C programming language threading library केवल C प्रोग्रामिंग भाषा थ्रेडिंग लाइब्रेरी में होती है
D
Always produce predictable reproducible failures easy to identify हमेशा पूर्वानुमेय प्रतिलिपि प्रस्तुत करने योग्य विफलताओं को पहचानना आसान होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Race conditions exhibit non-deterministic behaviour because execution order depends on OS scheduling, CPU speed, and memory patterns — all variable. They may occur once per million executions, disappear when a debugger changes timing, and manifest only under production load. Tools like ThreadSanitizer detect races through instrumented execution.
व्याख्या (हिन्दी) दौड़ की स्थितियाँ गैर-नियतात्मक व्यवहार प्रदर्शित करती हैं क्योंकि निष्पादन क्रम ओएस शेड्यूलिंग, सीपीयू गति और मेमोरी पैटर्न पर निर्भर करता है - सभी परिवर्तनशील। वे प्रति मिलियन निष्पादन में एक बार हो सकते हैं, जब डिबगर समय बदलता है तो गायब हो जाते हैं, और केवल उत्पादन भार के तहत प्रकट होते हैं। थ्रेडसैनिटाइज़र जैसे उपकरण यंत्रीकृत निष्पादन के माध्यम से दौड़ का पता लगाते हैं।
441
EN + हिं Easy
GB What is 'software rejuvenation' and when is it used as a maintenance strategy?
IN 'सॉफ़्टवेयर कायाकल्प' क्या है और इसे रखरखाव रणनीति के रूप में कब उपयोग किया जाता है?
A
Rewriting the system in a new programming language to improve performance प्रदर्शन को बेहतर बनाने के लिए सिस्टम को एक नई प्रोग्रामिंग भाषा में फिर से लिखना
B
A proactive fault management technique that periodically restarts, cleans, or reinitialises software to prevent accumulation of internal state degradation before failure occurs एक सक्रिय दोष प्रबंधन तकनीक जो विफलता होने से पहले आंतरिक स्थिति में गिरावट के संचय को रोकने के लिए सॉफ़्टवेयर को समय-समय पर पुनरारंभ, साफ़ या पुन: प्रारंभ करती है
C
Updating the user interface design to modern aesthetics उपयोगकर्ता इंटरफ़ेस डिज़ाइन को आधुनिक सौंदर्यशास्त्र के अनुसार अद्यतन करना
D
Only applicable to real-time embedded systems केवल रीयल-टाइम एंबेडेड सिस्टम पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Software rejuvenation (Huang et al., 1995) addresses software aging — gradual accumulation of resource leaks and internal fragmentation in long-running systems. Systems are periodically restarted during planned maintenance windows before failure occurs.
व्याख्या (हिन्दी) सॉफ़्टवेयर कायाकल्प (हुआंग एट अल., 1995) सॉफ़्टवेयर की उम्र बढ़ने को संबोधित करता है - लंबे समय से चल रहे सिस्टम में संसाधन लीक और आंतरिक विखंडन का क्रमिक संचय। विफलता होने से पहले नियोजित रखरखाव विंडो के दौरान सिस्टम को समय-समय पर पुनरारंभ किया जाता है।
442
EN + हिं Medium
GB What makes 'legacy system' maintenance uniquely challenging compared to maintaining modern software?
IN आधुनिक सॉफ़्टवेयर के रखरखाव की तुलना में 'विरासत प्रणाली' के रखरखाव को विशिष्ट रूप से चुनौतीपूर्ण क्या बनाता है?
A
Legacy systems are always written in COBOL, which modern developers refuse to learn लीगेसी सिस्टम हमेशा COBOL में लिखे जाते हैं, जिसे आधुनिक डेवलपर्स सीखने से इनकार करते हैं
B
Multiple compounding challenges: missing documentation, loss of developers' tacit knowledge, obsolete technologies, accumulated technical debt, tightly coupled architecture, and business criticality limiting testing windows एकाधिक मिश्रित चुनौतियाँ: गुम दस्तावेज, डेवलपर्स के मौन ज्ञान की हानि, अप्रचलित प्रौद्योगिकियाँ, संचित तकनीकी ऋण, कसकर युग्मित वास्तुकला, और परीक्षण विंडो को सीमित करने वाली व्यावसायिक गंभीरता
C
Only challenging because they run on outdated hardware that cannot be replaced केवल इसलिए चुनौतीपूर्ण है क्योंकि वे पुराने हार्डवेयर पर चलते हैं जिन्हें बदला नहीं जा सकता
D
Simpler because requirements have been stable for years सरल इसलिए क्योंकि आवश्यकताएँ वर्षों से स्थिर हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Legacy systems (Sommerville) compound multiple problems simultaneously: tribal knowledge leaves with retiring developers, documentation is obsolete or absent, technologies unsupported, deep coupling means any change might break something unexpected. Yet these systems often run mission-critical operations.
व्याख्या (हिन्दी) लीगेसी सिस्टम (सोमरविले) कई समस्याओं को एक साथ जोड़ता है: जनजातीय ज्ञान सेवानिवृत्त डेवलपर्स के पास चला जाता है, दस्तावेज़ीकरण अप्रचलित या अनुपस्थित है, प्रौद्योगिकियां असमर्थित हैं, गहरे युग्मन का मतलब है कि कोई भी बदलाव कुछ अप्रत्याशित को तोड़ सकता है। फिर भी ये प्रणालियाँ अक्सर मिशन-महत्वपूर्ण ऑपरेशन चलाती हैं।
443
EN + हिं Medium
GB What does the 'software aging' phenomenon describe and what are its two primary manifestations?
IN 'सॉफ़्टवेयर एजिंग' घटना क्या वर्णन करती है और इसकी दो प्राथमिक अभिव्यक्तियाँ क्या हैं?
A
Software losing market share to newer competitors सॉफ़्टवेयर नए प्रतिस्पर्धियों के हाथों बाज़ार हिस्सेदारी खो रहा है
B
Software quality degrading over time due to: 1) accumulation of internal failures (memory leaks, resource fragmentation) and 2) structural degradation (accumulated technical debt making future changes harder) समय के साथ सॉफ़्टवेयर गुणवत्ता में गिरावट के कारण: 1) आंतरिक विफलताओं का संचय (मेमोरी लीक, संसाधन विखंडन) और 2) संरचनात्मक गिरावट (संचित तकनीकी ऋण भविष्य में बदलाव को कठिन बना रहा है)
C
Only affects software written more than 20 years ago केवल 20 वर्ष से अधिक पहले लिखे गए सॉफ़्टवेयर को प्रभावित करता है
D
Synonym for software deprecation when vendor stops support जब विक्रेता समर्थन बंद कर देता है तो सॉफ़्टवेयर अवनति का पर्यायवाची
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Parnas (1994) identified two types of software aging: 1) Runtime aging — resource leaks in long-running processes addressed by rejuvenation (restart); 2) Design aging — structural decay from poor maintenance decisions addressed by refactoring and architectural renovation.
व्याख्या (हिन्दी) पार्नास (1994) ने दो प्रकार के सॉफ़्टवेयर एजिंग की पहचान की: 1) रनटाइम एजिंग - कायाकल्प (पुनरारंभ) द्वारा संबोधित लंबे समय से चल रही प्रक्रियाओं में संसाधन लीक; 2) डिज़ाइन की उम्र बढ़ना - रिफैक्टरिंग और वास्तुशिल्प नवीनीकरण द्वारा संबोधित खराब रखरखाव निर्णयों से संरचनात्मक क्षय।
444
EN + हिं Medium
GB What is 'maintenance debt' and how does it differ from 'technical debt'?
IN 'भरण-पोषण ऋण' क्या है और यह 'तकनीकी ऋण' से किस प्रकार भिन्न है?
A
Maintenance debt and technical debt are the same with different names रखरखाव ऋण और तकनीकी ऋण अलग-अलग नामों से एक ही हैं
B
Technical debt refers to suboptimal original design decisions; maintenance debt accumulates through deferred maintenance activities — known fixes, updates, improvements postponed and becoming increasingly expensive as dependencies change तकनीकी ऋण का तात्पर्य उप-इष्टतम मूल डिज़ाइन निर्णयों से है; रखरखाव ऋण स्थगित रखरखाव गतिविधियों के माध्यम से जमा होता है - ज्ञात सुधार, अद्यतन, सुधार स्थगित हो जाते हैं और निर्भरता बदलने के साथ-साथ महंगे होते जाते हैं
C
Only applies to financial software systems due to regulatory requirements नियामक आवश्यकताओं के कारण यह केवल वित्तीय सॉफ्टवेयर सिस्टम पर लागू होता है
D
Disappears when software is migrated to cloud infrastructure जब सॉफ़्टवेयर को क्लाउड इंफ्रास्ट्रक्चर में स्थानांतरित किया जाता है तो गायब हो जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Technical debt arises from design shortcuts during development. Maintenance debt accumulates post-release: security patches not applied, dependency upgrades deferred, known bugs not fixed. As time passes, the cost grows — unpatched vulnerabilities become exploited, skipped upgrades create compatibility crises.
व्याख्या (हिन्दी) विकास के दौरान डिज़ाइन शॉर्टकट से तकनीकी ऋण उत्पन्न होता है। रखरखाव ऋण रिहाई के बाद जमा होता है: सुरक्षा पैच लागू नहीं किए गए, निर्भरता उन्नयन स्थगित कर दिया गया, ज्ञात बग ठीक नहीं किए गए। जैसे-जैसे समय बीतता है, लागत बढ़ती है - अप्रकाशित कमजोरियों का फायदा उठाया जाता है, छोड़े गए उन्नयन अनुकूलता संकट पैदा करते हैं।
445
EN + हिं Easy
GB What is 'program comprehension' in maintenance and why does it consume the majority of maintenance effort?
IN रखरखाव में 'प्रोग्राम कॉम्प्रिहेंशन' क्या है और यह अधिकांश रखरखाव प्रयास का उपभोग क्यों करता है?
A
Formal documentation process preceding any code change किसी भी कोड परिवर्तन से पहले औपचारिक दस्तावेज़ीकरण प्रक्रिया
B
The cognitive process of understanding existing code well enough to modify it safely; consumes 50-60% of maintenance effort because code was not written to be understood — names are ambiguous, logic implicit, and decision rationale absent मौजूदा कोड को इतनी अच्छी तरह समझने की संज्ञानात्मक प्रक्रिया कि उसे सुरक्षित रूप से संशोधित किया जा सके; रखरखाव प्रयास का 50-60% खर्च होता है क्योंकि कोड को समझने के लिए नहीं लिखा गया था - नाम अस्पष्ट हैं, तर्क अंतर्निहित हैं, और निर्णय तर्क अनुपस्थित हैं
C
Only necessary for code written more than five years ago केवल पाँच वर्ष से अधिक पहले लिखे गए कोड के लिए आवश्यक है
D
Converting natural language requirements into formal specifications प्राकृतिक भाषा आवश्यकताओं को औपचारिक विशिष्टताओं में परिवर्तित करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Erlikh (2000) found comprehension accounts for approximately 50% of maintenance cost. Developers read code far more than they write it. Poor naming, absent comments, and no documentation of design rationale force maintainers to reverse-engineer intent before any change. This is why coding standards have outsized ROI in long-lived systems.
व्याख्या (हिन्दी) एर्लिख (2000) ने पाया कि रखरखाव लागत का लगभग 50% समझ से आता है। डेवलपर्स कोड को लिखने से कहीं अधिक पढ़ते हैं। ख़राब नामकरण, अनुपस्थित टिप्पणियाँ, और डिज़ाइन तर्क का कोई दस्तावेज़ीकरण नहीं होने से रखरखाव करने वालों को किसी भी बदलाव से पहले रिवर्स-इंजीनियर इरादे के लिए मजबूर होना पड़ता है। यही कारण है कि कोडिंग मानकों ने लंबे समय तक चलने वाले सिस्टम में आरओआई को बढ़ा दिया है।
446
EN + हिं Medium
GB What is 'software process capability' and how does CMM level 3 differ from level 2?
IN 'सॉफ़्टवेयर प्रक्रिया क्षमता' क्या है और सीएमएम स्तर 3, स्तर 2 से किस प्रकार भिन्न है?
A
Level 3 has more developers than level 2 लेवल 3 में लेवल 2 की तुलना में अधिक डेवलपर हैं
B
At level 2 processes are project-specific and repeatable; at level 3 processes are organisation-wide, standardised, and defined — enabling consistent performance across all projects स्तर 2 पर प्रक्रियाएँ परियोजना-विशिष्ट और दोहराने योग्य हैं; स्तर 3 पर प्रक्रियाएं संगठन-व्यापी, मानकीकृत और परिभाषित हैं - सभी परियोजनाओं में लगातार प्रदर्शन को सक्षम करना
C
Level 3 requires automated testing tools; level 2 only requires manual testing स्तर 3 के लिए स्वचालित परीक्षण उपकरणों की आवश्यकता होती है; लेवल 2 के लिए केवल मैन्युअल परीक्षण की आवश्यकता है
D
CMM levels 2 and 3 are identical; only the assessment cost differs सीएमएम स्तर 2 और 3 समान हैं; केवल मूल्यांकन लागत भिन्न है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CMM Level 2 (Repeatable) means basic project management is in place and similar projects can repeat past successes. Level 3 (Defined) means the organisation has a documented standard process tailored per project — enabling consistent engineering practices across the entire organisation, not just within individual projects.
व्याख्या (हिन्दी) सीएमएम लेवल 2 (दोहराने योग्य) का मतलब है कि बुनियादी परियोजना प्रबंधन मौजूद है और इसी तरह की परियोजनाएं पिछली सफलताओं को दोहरा सकती हैं। लेवल 3 (परिभाषित) का मतलब है कि संगठन के पास प्रति प्रोजेक्ट तैयार की गई एक प्रलेखित मानक प्रक्रिया है - जो केवल व्यक्तिगत परियोजनाओं के भीतर ही नहीं, बल्कि पूरे संगठन में लगातार इंजीनियरिंग प्रथाओं को सक्षम करती है।
447
EN + हिं Easy
GB What is the 'Mythical Man-Month' principle and what does it imply for adding developers to a late project?
IN 'मिथिकल मैन-मंथ' सिद्धांत क्या है और देर से आने वाले प्रोजेक्ट में डेवलपर्स को जोड़ने के लिए इसका क्या मतलब है?
A
Adding developers always speeds up a late project proportionally डेवलपर्स को जोड़ने से हमेशा विलंबित प्रोजेक्ट में आनुपातिक रूप से गति आती है
B
Adding manpower to a late software project makes it later — because new developers require training time from existing developers and increase communication overhead देर से आने वाले सॉफ़्टवेयर प्रोजेक्ट में जनशक्ति जोड़ने से यह बाद में बनता है - क्योंकि नए डेवलपर्स को मौजूदा डेवलपर्स से प्रशिक्षण समय की आवश्यकता होती है और संचार ओवरहेड में वृद्धि होती है
C
Adding developers only helps if the new hires are senior engineers डेवलपर्स को जोड़ने से केवल तभी मदद मिलती है जब नए कर्मचारी वरिष्ठ इंजीनियर हों
D
The Mythical Man-Month applies only to projects over 100 developers मिथिकल मैन-मंथ केवल 100 से अधिक डेवलपर्स की परियोजनाओं पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Brooks' Law: 'Adding manpower to a late software project makes it later.' New team members require ramp-up time, divert existing developers to train them, and increase communication channels (n*(n-1)/2 channels for n people), temporarily reducing productivity before any benefit is seen.
व्याख्या (हिन्दी) ब्रूक्स का नियम: 'किसी सॉफ़्टवेयर प्रोजेक्ट में जनशक्ति जोड़ने से वह बाद में बन जाता है।' नई टीम के सदस्यों को रैंप-अप समय की आवश्यकता होती है, मौजूदा डेवलपर्स को उन्हें प्रशिक्षित करने के लिए डायवर्ट किया जाता है, और संचार चैनल (n लोगों के लिए n*(n-1)/2 चैनल) बढ़ाए जाते हैं, जिससे कोई लाभ दिखने से पहले अस्थायी रूप से उत्पादकता कम हो जाती है।
448
EN + हिं Medium
GB What distinguishes 'incremental delivery' from 'iterative development' in software process models?
IN सॉफ़्टवेयर प्रक्रिया मॉडल में 'वृद्धिशील वितरण' को 'पुनरावृत्त विकास' से क्या अलग करता है?
A
Incremental delivery uses sprints; iterative development uses phases वृद्धिशील डिलीवरी स्प्रिंट का उपयोग करती है; पुनरावृत्तीय विकास चरणों का उपयोग करता है
B
Incremental delivery adds functionality in planned chunks without revisiting prior increments; iterative development repeatedly refines the entire system through cycles, improving quality with each iteration वृद्धिशील वितरण पूर्व वेतन वृद्धि पर दोबारा गौर किए बिना नियोजित भागों में कार्यक्षमता जोड़ता है; पुनरावृत्त विकास बार-बार चक्रों के माध्यम से संपूर्ण प्रणाली को परिष्कृत करता है, प्रत्येक पुनरावृत्ति के साथ गुणवत्ता में सुधार करता है
C
Both are identical concepts used interchangeably in agile contexts दोनों समान अवधारणाएँ हैं जिनका उपयोग त्वरित संदर्भों में परस्पर उपयोग किया जाता है
D
Iterative delivery always produces better quality than incremental delivery पुनरावर्ती डिलीवरी हमेशा वृद्धिशील डिलीवरी की तुलना में बेहतर गुणवत्ता उत्पन्न करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Incremental development adds new features to a stable base; each increment is a mini-waterfall adding a slice. Iterative development starts with a rough version of the whole system and progressively improves it. Agile methods often combine both — incrementally adding features while iteratively refining existing ones.
व्याख्या (हिन्दी) वृद्धिशील विकास एक स्थिर आधार में नई सुविधाएँ जोड़ता है; प्रत्येक वृद्धि एक टुकड़ा जोड़ने वाला एक छोटा झरना है। पुनरावृत्तीय विकास पूरे सिस्टम के किसी न किसी संस्करण से शुरू होता है और धीरे-धीरे इसमें सुधार करता है। चंचल तरीके अक्सर दोनों को जोड़ते हैं - मौजूदा सुविधाओं को पुनरावृत्तीय रूप से परिष्कृत करते हुए वृद्धिशील रूप से सुविधाएँ जोड़ते हैं।
449
EN + हिं Easy
GB What is a 'software product line' and what is its primary engineering advantage?
IN 'सॉफ़्टवेयर उत्पाद लाइन' क्या है और इसका प्राथमिक इंजीनियरिंग लाभ क्या है?
A
A sequence of software versions released annually प्रतिवर्ष जारी किए जाने वाले सॉफ़्टवेयर संस्करणों का एक क्रम
B
A family of related systems that share a common, managed set of features satisfying specific market needs — enabling systematic reuse of architecture, components, and assets across multiple products संबंधित प्रणालियों का एक परिवार जो विशिष्ट बाज़ार आवश्यकताओं को पूरा करने वाली सुविधाओं का एक सामान्य, प्रबंधित सेट साझा करता है - कई उत्पादों में वास्तुकला, घटकों और संपत्तियों के व्यवस्थित पुन: उपयोग को सक्षम बनाता है।
C
A collection of open-source libraries used by a single organisation किसी एकल संगठन द्वारा उपयोग किए जाने वाले ओपन-सोर्स पुस्तकालयों का संग्रह
D
A software testing methodology that validates multiple product variants simultaneously एक सॉफ़्टवेयर परीक्षण पद्धति जो एक साथ कई उत्पाद प्रकारों को मान्य करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Software Product Lines (Clements and Northrop) create competitive advantage through systematic reuse: instead of building each product from scratch, organisations invest in a core asset base (architecture, reusable components, processes) shared across a family of products, reducing cost and time-to-market for each product variant.
व्याख्या (हिन्दी) सॉफ़्टवेयर उत्पाद श्रृंखलाएँ (क्लेमेंट्स और नॉर्थ्रॉप) व्यवस्थित पुन: उपयोग के माध्यम से प्रतिस्पर्धात्मक लाभ पैदा करती हैं: प्रत्येक उत्पाद को खरोंच से बनाने के बजाय, संगठन उत्पादों के एक परिवार में साझा किए गए मुख्य परिसंपत्ति आधार (वास्तुकला, पुन: प्रयोज्य घटकों, प्रक्रियाओं) में निवेश करते हैं, जिससे प्रत्येक उत्पाद प्रकार के लिए लागत और समय-समय पर बाजार में कमी आती है।
450
EN + हिं Medium
GB In software engineering, what is the fundamental difference between 'reliability' and 'availability'?
IN सॉफ्टवेयर इंजीनियरिंग में, 'विश्वसनीयता' और 'उपलब्धता' के बीच मूलभूत अंतर क्या है?
A
Reliability measures user satisfaction; availability measures system speed विश्वसनीयता उपयोगकर्ता की संतुष्टि को मापती है; उपलब्धता सिस्टम की गति को मापती है
B
Reliability is the probability the system will perform its required function without failure for a specified time period; availability is the proportion of time the system is operational and accessible when needed विश्वसनीयता वह संभावना है जो सिस्टम एक निर्दिष्ट समय अवधि के लिए विफलता के बिना अपना आवश्यक कार्य करेगा; उपलब्धता उस समय का अनुपात है जब सिस्टम चालू रहता है और जरूरत पड़ने पर पहुंच योग्य होता है
C
Both terms are synonymous and used interchangeably in SLAs दोनों शब्द पर्यायवाची हैं और एसएलए में परस्पर उपयोग किए जाते हैं
D
Reliability applies to hardware; availability applies to software systems विश्वसनीयता हार्डवेयर पर लागू होती है; उपलब्धता सॉफ़्टवेयर सिस्टम पर लागू होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A system can be highly reliable (rarely fails) but have low availability (takes long to restart after rare failures). Conversely, a system with frequent short failures can still have high availability. Reliability is about failure frequency; availability accounts for both failure frequency and recovery time: Availability = MTTF / (MTTF + MTTR).
व्याख्या (हिन्दी) एक सिस्टम अत्यधिक विश्वसनीय हो सकता है (शायद ही कभी विफल होता है) लेकिन इसकी उपलब्धता कम होती है (दुर्लभ विफलताओं के बाद पुनरारंभ होने में लंबा समय लगता है)। इसके विपरीत, बार-बार छोटी विफलताओं वाली प्रणाली में अभी भी उच्च उपलब्धता हो सकती है। विश्वसनीयता विफलता की आवृत्ति के बारे में है; उपलब्धता विफलता की आवृत्ति और पुनर्प्राप्ति समय दोनों को ध्यान में रखती है: उपलब्धता = एमटीटीएफ / (एमटीटीएफ + एमटीटीआर)।
436–450 of 647