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
256
EN + हिं Medium
GB What is the key difference between structural (white-box) and behavioural (black-box) testing?
IN संरचनात्मक (व्हाइट-बॉक्स) और व्यवहारिक (ब्लैक-बॉक्स) परीक्षण के बीच मुख्य अंतर क्या है?
A
Both provide complete coverage when used independently स्वतंत्र रूप से उपयोग किए जाने पर दोनों पूर्ण कवरेज प्रदान करते हैं
B
White-box tests based on code structure cannot detect missing functionality; black-box tests cannot ensure structural paths are exercised; both alone are insufficient White-box tests based on code structure cannot detect missing functionality; black-box tests cannot ensure structural paths are exercised; अकेले दोनों अपर्याप्त हैं
C
White-box testing is superior for all categories of defects व्हाइट-बॉक्स परीक्षण सभी श्रेणियों के दोषों के लिए बेहतर है
D
Black-box testing requires access to source code ब्लैक-बॉक्स परीक्षण के लिए स्रोत कोड तक पहुंच की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) White-box testing achieves code coverage but cannot detect requirements never implemented — you can have 100% branch coverage and still miss critical user functions. Black-box drives from specifications but may never exercise rare code paths. Effective testing combines both.
व्याख्या (हिन्दी) व्हाइट-बॉक्स परीक्षण कोड कवरेज प्राप्त करता है लेकिन कभी लागू नहीं की गई आवश्यकताओं का पता नहीं लगा सकता है - आपके पास 100% शाखा कवरेज हो सकता है और फिर भी महत्वपूर्ण उपयोगकर्ता फ़ंक्शन छूट सकते हैं। ब्लैक-बॉक्स विशिष्टताओं से संचालित होता है लेकिन कभी भी दुर्लभ कोड पथों का प्रयोग नहीं कर सकता है। प्रभावी परीक्षण दोनों को जोड़ता है।
257
EN + हिं Hard
GB What does 'mutation testing' evaluate that conventional coverage metrics cannot?
IN 'म्यूटेशन परीक्षण' क्या मूल्यांकन करता है जो पारंपरिक कवरेज मेट्रिक्स नहीं कर सकता?
A
Performance impact of code changes under production load उत्पादन भार के तहत कोड परिवर्तन का प्रदर्शन प्रभाव
B
Quality and sensitivity of the test suite by introducing deliberate faults (mutations) and measuring whether tests detect them — a suite with high coverage but weak assertions will fail to kill many mutants जानबूझकर दोष (उत्परिवर्तन) पेश करके परीक्षण सूट की गुणवत्ता और संवेदनशीलता और यह मापना कि क्या परीक्षण उनका पता लगाते हैं - उच्च कवरेज वाला एक सूट लेकिन कमजोर दावे कई म्यूटेंट को मारने में विफल होंगे
C
How well the system handles concurrent user sessions सिस्टम समवर्ती उपयोगकर्ता सत्रों को कितनी अच्छी तरह संभालता है
D
Replaces integration testing by simulating broken API endpoints टूटे हुए एपीआई एंडपॉइंट का अनुकरण करके एकीकरण परीक्षण को प्रतिस्थापित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Code coverage measures whether code was executed, not whether tests would detect if that code were wrong. Mutation testing introduces small syntactic faults and checks if the test suite fails. The mutation score reveals whether tests are truly sensitive to defects.
व्याख्या (हिन्दी) कोड कवरेज यह मापता है कि कोड निष्पादित किया गया था या नहीं, न कि परीक्षण यह पता लगाएगा कि क्या वह कोड गलत था। उत्परिवर्तन परीक्षण छोटे वाक्यात्मक दोषों का परिचय देता है और जाँच करता है कि क्या परीक्षण सूट विफल हो जाता है। उत्परिवर्तन स्कोर से पता चलता है कि परीक्षण वास्तव में दोषों के प्रति संवेदनशील हैं या नहीं।
258
EN + हिं Medium
GB What specific condition causes 'pesticide paradox' in a test suite and how is it remedied?
IN कौन सी विशिष्ट स्थिति परीक्षण सूट में 'कीटनाशक विरोधाभास' का कारण बनती है और इसका निवारण कैसे किया जाता है?
A
Running too many tests simultaneously on a multi-core machine मल्टी-कोर मशीन पर एक साथ बहुत सारे परीक्षण चलाना
B
The same set of tests run repeatedly stops finding new defects because surviving code has been adapted to pass those specific tests — remedied by regularly reviewing and augmenting the test suite बार-बार चलाए जाने वाले परीक्षणों का एक ही सेट नए दोष ढूंढना बंद कर देता है क्योंकि जीवित कोड को उन विशिष्ट परीक्षणों को पास करने के लिए अनुकूलित किया गया है - नियमित रूप से परीक्षण सूट की समीक्षा और संवर्द्धन करके इसका समाधान किया जाता है।
C
Only occurs in systems using TDD केवल टीडीडी का उपयोग करने वाले सिस्टम में होता है
D
Refers to chemical pesticides near server room AC units सर्वर रूम एसी इकाइयों के पास रासायनिक कीटनाशकों को संदर्भित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Myers' 7 Testing Principles includes pesticide paradox: tests become ineffective as bugs they targeted are fixed and remaining bugs require different approaches. Test suites must evolve — adding new tests, varying data, and using exploratory/fuzz testing.
व्याख्या (हिन्दी) मायर्स के 7 परीक्षण सिद्धांतों में कीटनाशक विरोधाभास शामिल है: परीक्षण अप्रभावी हो जाते हैं क्योंकि उनके द्वारा लक्षित बग ठीक हो जाते हैं और शेष बग के लिए अलग-अलग दृष्टिकोण की आवश्यकता होती है। परीक्षण सुइट्स विकसित होने चाहिए - नए परीक्षण जोड़ना, डेटा बदलना और खोजपूर्ण/फ़ज़ परीक्षण का उपयोग करना।
259
EN + हिं Easy
GB What does 'boundary value analysis' test that equivalence partitioning may miss?
IN 'सीमा मूल्य विश्लेषण' क्या परीक्षण करता है कि तुल्यता विभाजन छूट सकता है?
A
System response time at peak load conditions चरम लोड स्थितियों में सिस्टम प्रतिक्रिया समय
B
Values at the edges of equivalence partitions (exact boundary, one below, one above) because defects cluster at boundaries due to common off-by-one errors समतुल्य विभाजन के किनारों पर मान (सटीक सीमा, एक नीचे, एक ऊपर) क्योंकि सामान्य ऑफ-बाय-वन त्रुटियों के कारण दोष सीमाओं पर एकत्रित होते हैं
C
Boundaries between different software modules during integration एकीकरण के दौरान विभिन्न सॉफ्टवेयर मॉड्यूल के बीच की सीमाएँ
D
Only applicable when number of inputs is exactly two केवल तभी लागू होता है जब इनपुट की संख्या बिल्कुल दो हो
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Empirical evidence shows programmers frequently make mistakes at condition boundaries: 'if (x < 10)' vs 'if (x <= 10)' is a classic off-by-one. BVA supplements equivalence partitioning with boundary values — for range 1-100: test 0, 1, 2, 99, 100, 101.
व्याख्या (हिन्दी) अनुभवजन्य साक्ष्य से पता चलता है कि प्रोग्रामर अक्सर स्थिति सीमाओं पर गलतियाँ करते हैं: 'if (x <10)' बनाम 'if (x
260
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.
व्याख्या (हिन्दी) टीडीडी का प्राथमिक डिज़ाइन लाभ परीक्षण योग्यता को बाध्य करना है। यदि आप इसे लागू करने से पहले कार्यक्षमता के लिए परीक्षण नहीं लिख सकते हैं, तो संभवतः डिज़ाइन गलत है। टीडीडी वास्तविक समय डिज़ाइन फीडबैक के रूप में कार्य करता है, जो स्वाभाविक रूप से डिकॉउल्ड इंजेक्टेबल सिंगल-जिम्मेदारी कोड का उत्पादन करता है।
261
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.
व्याख्या (हिन्दी) अल्फा परीक्षण बीटा से पहले होता है: नियंत्रित परिस्थितियों में घर में किया जाता है जहां परीक्षक उपयोगकर्ता के व्यवहार का निरीक्षण कर सकते हैं और विस्तृत लॉग एकत्र कर सकते हैं। बीटा परीक्षण उत्पाद को वास्तविक वातावरण में वास्तविक उपयोगकर्ताओं के सामने उजागर करता है - हार्डवेयर/ओएस कॉन्फ़िगरेशन समस्याओं और वास्तविक दुनिया के किनारे के मामलों को उजागर करता है।
262
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.
व्याख्या (हिन्दी) कचरा संग्रहण उन वस्तुओं को एकत्रित करता है जिनका कोई पहुंच योग्य संदर्भ नहीं है। 'लॉजिकल लीक' का मतलब है कि एप्लिकेशन के पास ऐसा संदर्भ है जिसकी उसे आवश्यकता नहीं है। उत्कृष्ट उदाहरण: ईवेंट हैंडलर को लंबे समय तक मौजूद ऑब्जेक्ट में हटाए बिना जोड़ने से सब्सक्राइबर प्रकाशक के जीवनकाल तक जीवित रहता है।
263
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 पथ होते हैं, जिससे पूर्ण अन्वेषण असंभव हो जाता है।
264
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.
व्याख्या (हिन्दी) दौड़ की स्थितियाँ गैर-नियतात्मक व्यवहार प्रदर्शित करती हैं क्योंकि निष्पादन क्रम ओएस शेड्यूलिंग, सीपीयू गति और मेमोरी पैटर्न पर निर्भर करता है - सभी परिवर्तनशील। वे प्रति मिलियन निष्पादन में एक बार हो सकते हैं, जब डिबगर समय बदलता है तो गायब हो जाते हैं, और केवल उत्पादन भार के तहत प्रकट होते हैं। थ्रेडसैनिटाइज़र जैसे उपकरण यंत्रीकृत निष्पादन के माध्यम से दौड़ का पता लगाते हैं।
265
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) सॉफ़्टवेयर की उम्र बढ़ने को संबोधित करता है - लंबे समय से चल रहे सिस्टम में संसाधन लीक और आंतरिक विखंडन का क्रमिक संचय। विफलता होने से पहले नियोजित रखरखाव विंडो के दौरान सिस्टम को समय-समय पर पुनरारंभ किया जाता है।
266
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.
व्याख्या (हिन्दी) लीगेसी सिस्टम (सोमरविले) कई समस्याओं को एक साथ जोड़ता है: जनजातीय ज्ञान सेवानिवृत्त डेवलपर्स के पास चला जाता है, दस्तावेज़ीकरण अप्रचलित या अनुपस्थित है, प्रौद्योगिकियां असमर्थित हैं, गहरे युग्मन का मतलब है कि कोई भी बदलाव कुछ अप्रत्याशित को तोड़ सकता है। फिर भी ये प्रणालियाँ अक्सर मिशन-महत्वपूर्ण ऑपरेशन चलाती हैं।
267
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) डिज़ाइन की उम्र बढ़ना - रिफैक्टरिंग और वास्तुशिल्प नवीनीकरण द्वारा संबोधित खराब रखरखाव निर्णयों से संरचनात्मक क्षय।
268
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.
व्याख्या (हिन्दी) विकास के दौरान डिज़ाइन शॉर्टकट से तकनीकी ऋण उत्पन्न होता है। रखरखाव ऋण रिहाई के बाद जमा होता है: सुरक्षा पैच लागू नहीं किए गए, निर्भरता उन्नयन स्थगित कर दिया गया, ज्ञात बग ठीक नहीं किए गए। जैसे-जैसे समय बीतता है, लागत बढ़ती है - अप्रकाशित कमजोरियों का फायदा उठाया जाता है, छोड़े गए उन्नयन अनुकूलता संकट पैदा करते हैं।
269
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% समझ से आता है। डेवलपर्स कोड को लिखने से कहीं अधिक पढ़ते हैं। ख़राब नामकरण, अनुपस्थित टिप्पणियाँ, और डिज़ाइन तर्क का कोई दस्तावेज़ीकरण नहीं होने से रखरखाव करने वालों को किसी भी बदलाव से पहले रिवर्स-इंजीनियर इरादे के लिए मजबूर होना पड़ता है। यही कारण है कि कोडिंग मानकों ने लंबे समय तक चलने वाले सिस्टम में आरओआई को बढ़ा दिया है।
270
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 (परिभाषित) का मतलब है कि संगठन के पास प्रति प्रोजेक्ट तैयार की गई एक प्रलेखित मानक प्रक्रिया है - जो केवल व्यक्तिगत परियोजनाओं के भीतर ही नहीं, बल्कि पूरे संगठन में लगातार इंजीनियरिंग प्रथाओं को सक्षम करती है।
256–270 of 647