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
2221
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.
व्याख्या (हिन्दी) कचरा संग्रहण उन वस्तुओं को एकत्रित करता है जिनका कोई पहुंच योग्य संदर्भ नहीं है। 'लॉजिकल लीक' का मतलब है कि एप्लिकेशन के पास ऐसा संदर्भ है जिसकी उसे आवश्यकता नहीं है। उत्कृष्ट उदाहरण: ईवेंट हैंडलर को लंबे समय तक मौजूद ऑब्जेक्ट में हटाए बिना जोड़ने से सब्सक्राइबर प्रकाशक के जीवनकाल तक जीवित रहता है।
2222
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 पथ होते हैं, जिससे पूर्ण अन्वेषण असंभव हो जाता है।
2223
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.
व्याख्या (हिन्दी) दौड़ की स्थितियाँ गैर-नियतात्मक व्यवहार प्रदर्शित करती हैं क्योंकि निष्पादन क्रम ओएस शेड्यूलिंग, सीपीयू गति और मेमोरी पैटर्न पर निर्भर करता है - सभी परिवर्तनशील। वे प्रति मिलियन निष्पादन में एक बार हो सकते हैं, जब डिबगर समय बदलता है तो गायब हो जाते हैं, और केवल उत्पादन भार के तहत प्रकट होते हैं। थ्रेडसैनिटाइज़र जैसे उपकरण यंत्रीकृत निष्पादन के माध्यम से दौड़ का पता लगाते हैं।
2224
EN + हिं Medium
GB What distinguishes corrective, adaptive, and perfective maintenance?
IN सुधारात्मक, अनुकूली और उत्तम रखरखाव में क्या अंतर है?
A
Corrective by customers; adaptive and perfective by vendor ग्राहकों द्वारा सुधारात्मक; विक्रेता द्वारा अनुकूली और परिपूर्ण
B
Corrective fixes defects; adaptive modifies for changed environments (new OS, hardware, laws); perfective enhances functionality or performance beyond original requirements सुधारात्मक दोषों को ठीक करता है; बदले हुए परिवेश के लिए अनुकूली संशोधन (नया ओएस, हार्डवेयर, कानून); परफेक्टिव मूल आवश्यकताओं से परे कार्यक्षमता या प्रदर्शन को बढ़ाता है
C
All three types refer to different stages of the same bug-fixing process सभी तीन प्रकार एक ही बग-फिक्सिंग प्रक्रिया के विभिन्न चरणों को संदर्भित करते हैं
D
Corrective addresses security; adaptive performance; perfective usability सुधारात्मक पते सुरक्षा; अनुकूली प्रदर्शन; उत्तम प्रयोज्यता
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Swanson (1976) classified maintenance into: Corrective (debugging), Adaptive (modifying for environmental changes), Perfective (improvements). Studies show perfective maintenance consumes most effort (50-60%), followed by adaptive (20-25%), then corrective (15-20%).
व्याख्या (हिन्दी) स्वानसन (1976) ने रखरखाव को इसमें वर्गीकृत किया: सुधारात्मक (डीबगिंग), अनुकूली (पर्यावरणीय परिवर्तनों के लिए संशोधन), परफेक्ट (सुधार)। अध्ययनों से पता चलता है कि उत्तम रखरखाव में सबसे अधिक प्रयास (50-60%) लगता है, उसके बाद अनुकूली (20-25%), फिर सुधारात्मक (15-20%) होता है।
2225
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) सॉफ़्टवेयर की उम्र बढ़ने को संबोधित करता है - लंबे समय से चल रहे सिस्टम में संसाधन लीक और आंतरिक विखंडन का क्रमिक संचय। विफलता होने से पहले नियोजित रखरखाव विंडो के दौरान सिस्टम को समय-समय पर पुनरारंभ किया जाता है।
2226
EN + हिं Easy
GB What is the 'ripple effect' in software maintenance and what design practices minimise it?
IN सॉफ़्टवेयर रखरखाव में 'रिपल इफ़ेक्ट' क्या है और कौन सी डिज़ाइन प्रथाएँ इसे कम करती हैं?
A
Positive spread of a bug fix across multiple related modules अनेक संबंधित मॉड्यूलों में बग फिक्स का सकारात्मक प्रसार
B
Unintended propagation of changes where modifying one component requires changes in dependent components; minimised by low coupling, information hiding, stable interfaces, and encapsulation परिवर्तनों का अनपेक्षित प्रसार जहां एक घटक को संशोधित करने के लिए आश्रित घटकों में परिवर्तन की आवश्यकता होती है; कम युग्मन, सूचना छिपाना, स्थिर इंटरफ़ेस और एनकैप्सुलेशन द्वारा न्यूनतम किया गया
C
Describes how performance improvements automatically improve all modules वर्णन करता है कि कैसे प्रदर्शन सुधार स्वचालित रूप से सभी मॉड्यूल में सुधार करता है
D
Only occurs during corrective maintenance केवल सुधारात्मक रखरखाव के दौरान होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) High coupling causes ripple effects: changing a module's interface forces changes in all dependent modules. Good design practices (Parnas' information hiding, stable abstract interfaces, DIP) create barriers preventing internal changes from leaking outward.
व्याख्या (हिन्दी) उच्च युग्मन तरंग प्रभाव का कारण बनता है: मॉड्यूल के इंटरफ़ेस को बदलने से सभी निर्भर मॉड्यूल में परिवर्तन होता है। अच्छी डिज़ाइन प्रथाएँ (परनास की जानकारी छिपाना, स्थिर अमूर्त इंटरफ़ेस, डीआईपी) आंतरिक परिवर्तनों को बाहर की ओर लीक होने से रोकने वाली बाधाएँ पैदा करती हैं।
2227
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.
व्याख्या (हिन्दी) लीगेसी सिस्टम (सोमरविले) कई समस्याओं को एक साथ जोड़ता है: जनजातीय ज्ञान सेवानिवृत्त डेवलपर्स के पास चला जाता है, दस्तावेज़ीकरण अप्रचलित या अनुपस्थित है, प्रौद्योगिकियां असमर्थित हैं, गहरे युग्मन का मतलब है कि कोई भी बदलाव कुछ अप्रत्याशित को तोड़ सकता है। फिर भी ये प्रणालियाँ अक्सर मिशन-महत्वपूर्ण ऑपरेशन चलाती हैं।
2228
EN + हिं Easy
GB What is 'reverse engineering' in software maintenance and in what situation is it unavoidable?
IN सॉफ़्टवेयर रखरखाव में 'रिवर्स इंजीनियरिंग' क्या है और यह किस स्थिति में अपरिहार्य है?
A
Converting high-level source code to machine code for performance प्रदर्शन के लिए उच्च-स्तरीय स्रोत कोड को मशीन कोड में परिवर्तित करना
B
Extracting higher-level abstractions from existing code when documentation is missing — unavoidable when maintaining legacy systems where only source code or compiled binaries survive without specifications दस्तावेज़ अनुपलब्ध होने पर मौजूदा कोड से उच्च-स्तरीय सार निकालना - विरासत प्रणालियों को बनाए रखते समय अपरिहार्य है जहां केवल स्रोत कोड या संकलित बायनेरिज़ विनिर्देशों के बिना जीवित रहते हैं
C
Only legal when the original software vendor gives explicit written permission केवल तभी कानूनी जब मूल सॉफ़्टवेयर विक्रेता स्पष्ट लिखित अनुमति देता है
D
Automatically reconstructs lost requirement documents from test results परीक्षण परिणामों से खोए हुए आवश्यक दस्तावेज़ों को स्वचालित रूप से पुन: निर्मित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Reverse engineering (Chikofsky and Cross) recovers design artefacts from code: structure, data models, and behaviour. It's unavoidable for legacy systems where the only surviving artefact is source code or executable — common when companies acquire old systems or maintain decades-old government software.
व्याख्या (हिन्दी) रिवर्स इंजीनियरिंग (चिकोफ़्स्की और क्रॉस) कोड से डिज़ाइन कलाकृतियों को पुनर्प्राप्त करता है: संरचना, डेटा मॉडल और व्यवहार। यह उन विरासत प्रणालियों के लिए अपरिहार्य है जहां एकमात्र जीवित कलाकृति स्रोत कोड या निष्पादन योग्य है - यह तब आम है जब कंपनियां पुरानी प्रणालियों का अधिग्रहण करती हैं या दशकों पुराने सरकारी सॉफ्टवेयर का रखरखाव करती हैं।
2229
EN + हिं Easy
GB In software maintenance, what is 'refactoring' and what distinguishes it from feature development?
IN सॉफ़्टवेयर रखरखाव में, 'रिफैक्टरिंग' क्या है और इसे फीचर डेवलपमेंट से क्या अलग किया गया है?
A
Adds new features while simultaneously improving code structure कोड संरचना में सुधार करते हुए नई सुविधाएँ जोड़ता है
B
Restructures existing code to improve internal quality without changing observable external behaviour — the key constraint is that functionality must remain identical before and after अवलोकन योग्य बाहरी व्यवहार को बदले बिना आंतरिक गुणवत्ता में सुधार करने के लिए मौजूदा कोड का पुनर्गठन करता है - मुख्य बाधा यह है कि कार्यक्षमता पहले और बाद में समान रहनी चाहिए
C
Only possible when system has 100% automated test coverage यह तभी संभव है जब सिस्टम में 100% स्वचालित परीक्षण कवरेज हो
D
Refactoring and rewriting are the same; choice depends only on scale रीफैक्टरिंग और रीराइटिंग समान हैं; चुनाव केवल पैमाने पर निर्भर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fowler's refactoring definition emphasises behaviour preservation: 'a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour.' Automated tests verify behaviour is preserved throughout.
व्याख्या (हिन्दी) फाउलर की रिफैक्टरिंग परिभाषा व्यवहार संरक्षण पर जोर देती है: 'सॉफ्टवेयर की आंतरिक संरचना में किया गया बदलाव, जिससे इसे समझना आसान हो और इसके अवलोकन योग्य व्यवहार को बदले बिना संशोधित करना सस्ता हो।' स्वचालित परीक्षण सत्यापित करते हैं कि व्यवहार संपूर्ण रूप से संरक्षित है।
2230
EN + हिं Easy
GB What is the 'Strangler Fig' pattern in software maintenance and what problem does it solve?
IN सॉफ़्टवेयर रखरखाव में 'स्ट्रैंगलर फ़िग' पैटर्न क्या है और यह किस समस्या का समाधान करता है?
A
Removes unused legacy features incrementally to reduce system size सिस्टम आकार को कम करने के लिए अप्रयुक्त विरासत सुविधाओं को धीरे-धीरे हटाता है
B
Incrementally replaces a legacy system by routing new functionality to a new system while the old system continues running — solving the problem of 'big bang' replacement requiring everything ready before switching पुरानी प्रणाली चालू रहने के दौरान नई कार्यक्षमता को नई प्रणाली में रूट करके एक विरासत प्रणाली को क्रमिक रूप से बदल देता है - 'बिग बैंग' प्रतिस्थापन की समस्या को हल करने के लिए स्विच करने से पहले सब कुछ तैयार करना आवश्यक है
C
A testing technique for gradually increasing test coverage of legacy code लीगेसी कोड के परीक्षण कवरेज को धीरे-धीरे बढ़ाने के लिए एक परीक्षण तकनीक
D
A database migration strategy copying data between systems overnight एक डेटाबेस माइग्रेशन रणनीति जो रातों-रात सिस्टम के बीच डेटा कॉपी करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Named after the strangler fig tree that grows around and replaces its host, this pattern avoids the risk of complete cutover. The new system intercepts requests, handling those it can and passing others to the legacy system. Over time, more paths migrate until the legacy system can be decommissioned.
व्याख्या (हिन्दी) इसका नाम स्ट्रैंगलर अंजीर के पेड़ के नाम पर रखा गया है जो चारों ओर उगता है और अपने मेजबान की जगह लेता है, यह पैटर्न पूरी तरह से कटओवर के जोखिम से बचाता है। नई प्रणाली अनुरोधों को रोकती है, उन अनुरोधों को संभालती है जो वह कर सकती है और दूसरों को विरासत प्रणाली में भेजती है। समय के साथ, अधिक पथ तब तक स्थानांतरित हो जाते हैं जब तक कि विरासत प्रणाली को निष्क्रिय नहीं किया जा सकता।
2231
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) डिज़ाइन की उम्र बढ़ना - रिफैक्टरिंग और वास्तुशिल्प नवीनीकरण द्वारा संबोधित खराब रखरखाव निर्णयों से संरचनात्मक क्षय।
2232
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.
व्याख्या (हिन्दी) विकास के दौरान डिज़ाइन शॉर्टकट से तकनीकी ऋण उत्पन्न होता है। रखरखाव ऋण रिहाई के बाद जमा होता है: सुरक्षा पैच लागू नहीं किए गए, निर्भरता उन्नयन स्थगित कर दिया गया, ज्ञात बग ठीक नहीं किए गए। जैसे-जैसे समय बीतता है, लागत बढ़ती है - अप्रकाशित कमजोरियों का फायदा उठाया जाता है, छोड़े गए उन्नयन अनुकूलता संकट पैदा करते हैं।
2233
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% समझ से आता है। डेवलपर्स कोड को लिखने से कहीं अधिक पढ़ते हैं। ख़राब नामकरण, अनुपस्थित टिप्पणियाँ, और डिज़ाइन तर्क का कोई दस्तावेज़ीकरण नहीं होने से रखरखाव करने वालों को किसी भी बदलाव से पहले रिवर्स-इंजीनियर इरादे के लिए मजबूर होना पड़ता है। यही कारण है कि कोडिंग मानकों ने लंबे समय तक चलने वाले सिस्टम में आरओआई को बढ़ा दिया है।
2234
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 (परिभाषित) का मतलब है कि संगठन के पास प्रति प्रोजेक्ट तैयार की गई एक प्रलेखित मानक प्रक्रिया है - जो केवल व्यक्तिगत परियोजनाओं के भीतर ही नहीं, बल्कि पूरे संगठन में लगातार इंजीनियरिंग प्रथाओं को सक्षम करती है।
2235
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 चैनल) बढ़ाए जाते हैं, जिससे कोई लाभ दिखने से पहले अस्थायी रूप से उत्पादकता कम हो जाती है।
2221–2235 of 2726