Software Engineering — MCQ Practice

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

📚 217 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
217 questions
196
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.
व्याख्या (हिन्दी) रिवर्स इंजीनियरिंग (चिकोफ़्स्की और क्रॉस) कोड से डिज़ाइन कलाकृतियों को पुनर्प्राप्त करता है: संरचना, डेटा मॉडल और व्यवहार। यह उन विरासत प्रणालियों के लिए अपरिहार्य है जहां एकमात्र जीवित कलाकृति स्रोत कोड या निष्पादन योग्य है - यह तब आम है जब कंपनियां पुरानी प्रणालियों का अधिग्रहण करती हैं या दशकों पुराने सरकारी सॉफ्टवेयर का रखरखाव करती हैं।
197
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.
व्याख्या (हिन्दी) फाउलर की रिफैक्टरिंग परिभाषा व्यवहार संरक्षण पर जोर देती है: 'सॉफ्टवेयर की आंतरिक संरचना में किया गया बदलाव, जिससे इसे समझना आसान हो और इसके अवलोकन योग्य व्यवहार को बदले बिना संशोधित करना सस्ता हो।' स्वचालित परीक्षण सत्यापित करते हैं कि व्यवहार संपूर्ण रूप से संरक्षित है।
198
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.
व्याख्या (हिन्दी) इसका नाम स्ट्रैंगलर अंजीर के पेड़ के नाम पर रखा गया है जो चारों ओर उगता है और अपने मेजबान की जगह लेता है, यह पैटर्न पूरी तरह से कटओवर के जोखिम से बचाता है। नई प्रणाली अनुरोधों को रोकती है, उन अनुरोधों को संभालती है जो वह कर सकती है और दूसरों को विरासत प्रणाली में भेजती है। समय के साथ, अधिक पथ तब तक स्थानांतरित हो जाते हैं जब तक कि विरासत प्रणाली को निष्क्रिय नहीं किया जा सकता।
199
EN + हिं Medium
GB What is 'preventive maintenance' in software and how does it differ from perfective maintenance?
IN सॉफ़्टवेयर में 'निवारक रखरखाव' क्या है और यह संपूर्ण रखरखाव से किस प्रकार भिन्न है?
A
Preventive maintenance fixes defects; perfective maintenance prevents defects निवारक रखरखाव दोषों को ठीक करता है; उत्तम रखरखाव दोषों को रोकता है
B
Preventive maintenance restructures or refactors code to improve future maintainability (reducing technical debt) before failures occur; perfective maintenance adds new functionality or improves performance in response to user requests विफलताएं होने से पहले भविष्य में रखरखाव (तकनीकी ऋण को कम करना) में सुधार के लिए निवारक रखरखाव पुनर्गठन या रिफैक्टर कोड; संपूर्ण रखरखाव उपयोगकर्ता के अनुरोधों के जवाब में नई कार्यक्षमता जोड़ता है या प्रदर्शन में सुधार करता है
C
Both preventive and perfective maintenance are identical activities with different scheduling निवारक और संपूर्ण रखरखाव दोनों अलग-अलग शेड्यूल के साथ समान गतिविधियाँ हैं
D
Preventive maintenance is only applicable to hardware systems, not software निवारक रखरखाव केवल हार्डवेयर सिस्टम पर लागू होता है, सॉफ़्टवेयर पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Preventive maintenance (ISO 14764's fourth maintenance type, added later) addresses known maintainability risks before they cause failures: restructuring spaghetti code, updating deprecated dependencies, improving test coverage in high-risk modules. Perfective maintenance responds to user requests for new features or performance improvements. Preventive is proactive internal quality investment; perfective is reactive external value delivery.
व्याख्या (हिन्दी) निवारक रखरखाव (आईएसओ 14764 का चौथा रखरखाव प्रकार, बाद में जोड़ा गया) विफलताओं का कारण बनने से पहले ज्ञात रखरखाव जोखिमों को संबोधित करता है: स्पेगेटी कोड का पुनर्गठन, अप्रचलित निर्भरता को अपडेट करना, उच्च जोखिम वाले मॉड्यूल में परीक्षण कवरेज में सुधार करना। परफेक्ट रखरखाव नई सुविधाओं या प्रदर्शन में सुधार के लिए उपयोगकर्ता के अनुरोधों का जवाब देता है। निवारक सक्रिय आंतरिक गुणवत्ता निवेश है; परफेक्ट प्रतिक्रियाशील बाह्य मूल्य वितरण है।
200
EN + हिं Easy
GB What is 'hotfix' versus 'patch release' versus 'minor release' in software maintenance release management?
IN सॉफ़्टवेयर रखरखाव रिलीज़ प्रबंधन में 'हॉटफ़िक्स' बनाम 'पैच रिलीज़' बनाम 'मामूली रिलीज़' क्या है?
A
All three terms describe the same type of release; the choice depends only on marketing preferences तीनों शब्द एक ही प्रकार की रिलीज़ का वर्णन करते हैं; चुनाव केवल विपणन प्राथमिकताओं पर निर्भर करता है
B
Hotfix: emergency fix deployed immediately for critical production issue (bypassing normal release cycle); Patch release: bundled bug fixes following normal testing cycle; Minor release: backward-compatible new features plus bug fixes with full regression testing हॉटफ़िक्स: गंभीर उत्पादन समस्या के लिए तुरंत आपातकालीन फ़िक्स तैनात किया गया (सामान्य रिलीज़ चक्र को दरकिनार करते हुए); पैच रिलीज़: सामान्य परीक्षण चक्र के बाद बंडल बग फिक्स; लघु रिलीज़: पूर्ण प्रतिगमन परीक्षण के साथ बैकवर्ड-संगत नई सुविधाएँ और बग फिक्स
C
Hotfixes are only used for security vulnerabilities; patch releases only for performance issues हॉटफिक्स का उपयोग केवल सुरक्षा कमजोरियों के लिए किया जाता है; पैच केवल प्रदर्शन समस्याओं के लिए रिलीज़ होता है
D
Minor releases always break backward compatibility and require database schema migrations छोटी रिलीज़ हमेशा बैकवर्ड संगतता को तोड़ती है और डेटाबेस स्कीमा माइग्रेशन की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Release management distinguishes by urgency and scope. Hotfix: production is down or critically impaired — deploy in hours, test only the critical path, risk accepted. Patch: regular defect collection — weekly/monthly cadence, full regression suite. Minor: planned feature additions — full test cycle, release notes, migration guides for API consumers. Semantic versioning encodes these distinctions as MAJOR.MINOR.PATCH.
व्याख्या (हिन्दी) रिलीज प्रबंधन तात्कालिकता और दायरे के आधार पर अंतर करता है। हॉटफ़िक्स: उत्पादन कम है या गंभीर रूप से ख़राब है - घंटों में तैनात करें, केवल महत्वपूर्ण पथ का परीक्षण करें, जोखिम स्वीकार किया गया है। पैच: नियमित दोष संग्रहण - साप्ताहिक/मासिक ताल, पूर्ण प्रतिगमन सुइट। Minor: planned feature additions — full test cycle, release notes, migration guides for API consumers. सिमेंटिक वर्जनिंग इन भेदों को MAJOR.MINOR.PATCH के रूप में एन्कोड करता है।
201
EN + हिं Easy
GB What is 'end-of-life' (EOL) planning in software maintenance and what risks does inadequate planning create?
IN सॉफ्टवेयर रखरखाव में 'एंड-ऑफ-लाइफ' (ईओएल) योजना क्या है और अपर्याप्त योजना क्या जोखिम पैदा करती है?
A
EOL planning decides which programming languages to deprecate in the next development cycle ईओएल योजना यह तय करती है कि अगले विकास चक्र में कौन सी प्रोग्रामिंग भाषाओं को अप्रचलित किया जाए
B
EOL planning defines the timeline and process for retiring a software system or version — inadequate planning leaves users on unsupported versions (no security patches), organisations paying maintenance for dead systems, and no migration path — creating compounding security and operational risk ईओएल योजना एक सॉफ्टवेयर सिस्टम या संस्करण को रिटायर करने के लिए समयरेखा और प्रक्रिया को परिभाषित करती है - अपर्याप्त योजना उपयोगकर्ताओं को असमर्थित संस्करणों (कोई सुरक्षा पैच नहीं) पर छोड़ देती है, संगठन मृत सिस्टम के लिए रखरखाव का भुगतान करते हैं, और कोई माइग्रेशन पथ नहीं - जटिल सुरक्षा और परिचालन जोखिम पैदा करता है
C
EOL planning only applies to hardware products; software can always be patched indefinitely ईओएल योजना केवल हार्डवेयर उत्पादों पर लागू होती है; सॉफ़्टवेयर को हमेशा अनिश्चित काल के लिए पैच किया जा सकता है
D
EOL planning is only the vendor's responsibility and requires no action from consuming organisations ईओएल योजना केवल विक्रेता की जिम्मेदारी है और उपभोक्ता संगठनों से किसी कार्रवाई की आवश्यकता नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Windows XP EOL (2014) left millions of systems unpatched — WannaCry ransomware (2017) specifically targeted them. Python 2 EOL (2020) left legacy systems running unsupported interpreters. EOL planning requires: advance notice to users, migration guides, overlap period where old and new versions coexist, and sunset of old version support. Organisations consuming EOL software must plan migrations before EOL dates, not after.
व्याख्या (हिन्दी) Windows XP EOL (2014) ने लाखों सिस्टमों को अप्रकाशित कर दिया - WannaCry रैंसमवेयर (2017) ने विशेष रूप से उन्हें लक्षित किया। पायथन 2 ईओएल (2020) ने विरासती सिस्टम को असमर्थित दुभाषियों के साथ चलाया। ईओएल योजना के लिए आवश्यक है: उपयोगकर्ताओं के लिए अग्रिम सूचना, माइग्रेशन गाइड, ओवरलैप अवधि जहां पुराने और नए संस्करण सह-अस्तित्व में हैं, और पुराने संस्करण के समर्थन की समाप्ति। ईओएल सॉफ़्टवेयर का उपभोग करने वाले संगठनों को ईओएल तिथियों से पहले माइग्रेशन की योजना बनानी चाहिए, उसके बाद नहीं।
202
EN + हिं Easy
GB What is 'configuration drift' in software maintenance and what practice prevents it in cloud environments?
IN सॉफ़्टवेयर रखरखाव में 'कॉन्फ़िगरेशन बहाव' क्या है और क्लाउड वातावरण में कौन सी प्रथा इसे रोकती है?
A
Configuration drift refers to software version numbers diverging across development and production कॉन्फ़िगरेशन ड्रिफ्ट का तात्पर्य विकास और उत्पादन में भिन्न होने वाले सॉफ़्टवेयर संस्करण संख्याओं से है
B
Configuration drift occurs when infrastructure/application configuration diverges from its documented or intended state due to manual changes — prevented by Infrastructure as Code (IaC) with enforced immutable infrastructure and regular compliance scanning कॉन्फ़िगरेशन बहाव तब होता है जब बुनियादी ढांचे/एप्लिकेशन कॉन्फ़िगरेशन मैन्युअल परिवर्तनों के कारण अपने दस्तावेज़ या इच्छित स्थिति से अलग हो जाता है - लागू अपरिवर्तनीय बुनियादी ढांचे और नियमित अनुपालन स्कैनिंग के साथ इंफ्रास्ट्रक्चर एज़ कोड (IaC) द्वारा रोका जाता है
C
Configuration drift only occurs in on-premise systems; cloud environments are immune to it कॉन्फ़िगरेशन बहाव केवल ऑन-प्रिमाइसेस सिस्टम में होता है; बादल का वातावरण इसके प्रति प्रतिरक्षित है
D
Configuration drift is unavoidable and can only be managed by complete system rebuilds quarterly कॉन्फ़िगरेशन बहाव अपरिहार्य है और इसे केवल त्रैमासिक पूर्ण सिस्टम पुनर्निर्माण द्वारा ही प्रबंधित किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Configuration drift: server A has nginx 1.14 (patched manually last year), server B has 1.18, server C has 1.12 — 'what should it be?' is unknown. Security patches may have been missed. IaC (Terraform, Ansible) defines desired state as code; CI/CD applies it consistently. Immutable infrastructure replaces rather than modifies servers, eliminating the possibility of manual drift. AWS Config and Azure Policy continuously scan for non-compliant configurations.
व्याख्या (हिन्दी) कॉन्फ़िगरेशन बहाव: सर्वर A में nginx 1.14 है (पिछले वर्ष मैन्युअल रूप से पैच किया गया), सर्वर B में 1.18 है, सर्वर C में 1.12 है - 'यह क्या होना चाहिए?' अज्ञात है. हो सकता है सुरक्षा पैच छूट गए हों. IaC (टेराफॉर्म, एन्सिबल) वांछित स्थिति को कोड के रूप में परिभाषित करता है; सीआई/सीडी इसे लगातार लागू करता है। अपरिवर्तनीय बुनियादी ढांचा सर्वर को संशोधित करने के बजाय प्रतिस्थापित करता है, जिससे मैन्युअल बहाव की संभावना समाप्त हो जाती है। AWS कॉन्फ़िगरेशन और Azure नीति गैर-अनुपालक कॉन्फ़िगरेशन के लिए लगातार स्कैन करते हैं।
203
EN + हिं Easy
GB What is 'knowledge management' in software maintenance and what creates 'knowledge debt'?
IN सॉफ़्टवेयर रखरखाव में 'ज्ञान प्रबंधन' क्या है और क्या 'ज्ञान ऋण' बनाता है?
A
Knowledge management refers to tracking which developers have read the software documentation ज्ञान प्रबंधन से तात्पर्य यह ट्रैक करना है कि किन डेवलपर्स ने सॉफ़्टवेयर दस्तावेज़ीकरण पढ़ा है
B
Knowledge management in maintenance preserves and distributes understanding of the system — 'knowledge debt' accumulates when: key developers leave without knowledge transfer, documentation is not updated with changes, and tribal knowledge is never externalised into wikis or decision records रखरखाव में ज्ञान प्रबंधन सिस्टम की समझ को संरक्षित और वितरित करता है - 'ज्ञान ऋण' तब जमा होता है जब: प्रमुख डेवलपर्स ज्ञान हस्तांतरण के बिना चले जाते हैं, दस्तावेज़ीकरण परिवर्तनों के साथ अद्यतन नहीं किया जाता है, और जनजातीय ज्ञान को कभी भी विकी या निर्णय रिकॉर्ड में बाह्यीकृत नहीं किया जाता है
C
Knowledge debt is automatically resolved by modern IDEs that extract documentation from code ज्ञान ऋण का समाधान आधुनिक आईडीई द्वारा स्वचालित रूप से किया जाता है जो कोड से दस्तावेज़ निकालते हैं
D
Knowledge management is only important for projects with more than 50 developers ज्ञान प्रबंधन केवल 50 से अधिक डेवलपर्स वाली परियोजनाओं के लिए महत्वपूर्ण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The bus factor problem: if a key developer leaves, how much institutional knowledge leaves with them? Knowledge debt is the gap between documented and undocumented understanding. Mitigations: pair programming distributes knowledge; Architecture Decision Records document why; code archaeology (comments like 'see bug #1234 for why this exists') preserves context; cross-training ensures no single person holds critical knowledge.
व्याख्या (हिन्दी) बस कारक समस्या: यदि कोई प्रमुख डेवलपर छोड़ देता है, तो उसके पास कितना संस्थागत ज्ञान बचेगा? ज्ञान ऋण प्रलेखित और अप्रलेखित समझ के बीच का अंतर है। शमन: जोड़ी प्रोग्रामिंग ज्ञान वितरित करती है; वास्तुकला निर्णय रिकॉर्ड दस्तावेज़ क्यों; कोड पुरातत्व ('यह क्यों मौजूद है इसके लिए बग #1234 देखें' जैसी टिप्पणियाँ) संदर्भ को सुरक्षित रखता है; क्रॉस-ट्रेनिंग यह सुनिश्चित करती है कि किसी एक व्यक्ति के पास महत्वपूर्ण ज्ञान न हो।
204
EN + हिं Easy
GB What is the 'broken windows theory' applied to software maintenance and what evidence supports it?
IN सॉफ़्टवेयर रखरखाव पर लागू 'टूटी हुई विंडोज़ सिद्धांत' क्या है और कौन से साक्ष्य इसका समर्थन करते हैं?
A
Broken windows theory in software means literal UI bugs that appear broken to users should be fixed first सॉफ़्टवेयर में टूटे हुए विंडोज़ सिद्धांत का अर्थ है कि उपयोगकर्ताओं को टूटे हुए दिखाई देने वाले शाब्दिक यूआई बग को पहले ठीक किया जाना चाहिए
B
The broken windows theory (Hunt and Thomas) suggests that visible neglect (bad code, commented-out code, inconsistent style) signals that the codebase has no standards, inviting further neglect — empirically, modules with high existing defect density attract disproportionately more new defects टूटे हुए विंडोज़ सिद्धांत (हंट और थॉमस) से पता चलता है कि दृश्यमान उपेक्षा (खराब कोड, टिप्पणी-आउट कोड, असंगत शैली) संकेत देती है कि कोडबेस में कोई मानक नहीं है, जो आगे की उपेक्षा को आमंत्रित करता है - अनुभवजन्य रूप से, उच्च मौजूदा दोष घनत्व वाले मॉड्यूल असंगत रूप से अधिक नए दोषों को आकर्षित करते हैं
C
Broken windows theory has been empirically disproved and is not considered valid in modern software engineering टूटी हुई विंडोज़ सिद्धांत को अनुभवजन्य रूप से अस्वीकृत कर दिया गया है और इसे आधुनिक सॉफ्टवेयर इंजीनियरिंग में मान्य नहीं माना जाता है
D
Broken windows theory only applies to open-source projects where community standards are absent टूटी विंडोज़ सिद्धांत केवल ओपन-सोर्स परियोजनाओं पर लागू होता है जहां सामुदायिक मानक अनुपस्थित हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Research (Nagappan and Ball at Microsoft, Ostrand et al.) empirically shows defect proneness is heavily concentrated: 20% of files contain 80% of defects, and those same files accumulate more defects over time. The broken windows effect: developers seeing bad code conclude 'this is how we work here' and apply less care. The Boy Scout Rule is the direct counter-practice: leave code better than you found it, creating a visible standard of care.
व्याख्या (हिन्दी) अनुसंधान (माइक्रोसॉफ्ट, ऑस्ट्रैंड एट अल में नागप्पन और बॉल) अनुभवजन्य रूप से दिखाता है कि दोष प्रवणता अत्यधिक केंद्रित है: 20% फ़ाइलों में 80% दोष होते हैं, और वही फ़ाइलें समय के साथ और अधिक दोष जमा करती हैं। टूटी खिड़कियों का प्रभाव: खराब कोड देखकर डेवलपर्स यह निष्कर्ष निकालते हैं कि 'हम यहां इसी तरह काम करते हैं' और कम सावधानी बरतते हैं। बॉय स्काउट नियम प्रत्यक्ष प्रति-अभ्यास है: कोड को जितना आपने पाया था उससे बेहतर छोड़ें, जिससे देखभाल का एक दृश्यमान मानक तैयार हो सके।
205
EN + हिं Easy
GB What is 'software maintenance cost model' and what factor does empirical research identify as the dominant driver?
IN 'सॉफ़्टवेयर रखरखाव लागत मॉडल' क्या है और अनुभवजन्य अनुसंधान किस कारक को प्रमुख चालक के रूप में पहचानता है?
A
Maintenance cost models identify lines of code as the dominant cost driver रखरखाव लागत मॉडल प्रमुख लागत चालक के रूप में कोड की पंक्तियों की पहचान करते हैं
B
Maintenance cost models predict long-term maintenance effort — empirical research (Boehm, Jones, Lehman) consistently identifies the system's structural complexity (cyclomatic complexity, coupling, cohesion) and the quality of design documentation as the dominant maintenance cost drivers रखरखाव लागत मॉडल दीर्घकालिक रखरखाव प्रयास की भविष्यवाणी करते हैं - अनुभवजन्य अनुसंधान (बोहेम, जोन्स, लेहमैन) लगातार सिस्टम की संरचनात्मक जटिलता (साइक्लोमैटिक जटिलता, युग्मन, सामंजस्य) और डिजाइन दस्तावेज़ीकरण की गुणवत्ता को प्रमुख रखरखाव लागत चालकों के रूप में पहचानता है।
C
Maintenance cost is primarily driven by the number of developers on the maintenance team रखरखाव लागत मुख्य रूप से रखरखाव टीम में डेवलपर्स की संख्या से प्रेरित होती है
D
Maintenance cost models are theoretical tools that have never been validated with real project data रखरखाव लागत मॉडल सैद्धांतिक उपकरण हैं जिन्हें वास्तविक परियोजना डेटा के साथ कभी भी मान्य नहीं किया गया है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm's COCOMO maintenance model and Jones' function point-based models both show: structurally complex systems (high coupling, low cohesion, deep inheritance) cost 3-5x more to maintain than well-designed systems of the same size. Undocumented systems add another 30-50% overhead for comprehension. This quantifies the ROI of investing in design quality — lower maintenance cost over the system's lifetime exceeds the upfront design investment.
व्याख्या (हिन्दी) बोहेम के COCOMO रखरखाव मॉडल और जोन्स के फ़ंक्शन पॉइंट-आधारित मॉडल दोनों दिखाते हैं: संरचनात्मक रूप से जटिल सिस्टम (उच्च युग्मन, कम सामंजस्य, गहरी विरासत) को बनाए रखने की लागत समान आकार के अच्छी तरह से डिज़ाइन किए गए सिस्टम की तुलना में 3-5 गुना अधिक है। गैर-दस्तावेजी प्रणालियाँ समझ के लिए अतिरिक्त 30-50% ओवरहेड जोड़ती हैं। यह डिज़ाइन गुणवत्ता में निवेश के आरओआई की मात्रा निर्धारित करता है - सिस्टम के जीवनकाल में कम रखरखाव लागत अग्रिम डिज़ाइन निवेश से अधिक है।
206
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%) होता है।
207
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.
व्याख्या (हिन्दी) उच्च युग्मन तरंग प्रभाव का कारण बनता है: मॉड्यूल के इंटरफ़ेस को बदलने से सभी निर्भर मॉड्यूल में परिवर्तन होता है। अच्छी डिज़ाइन प्रथाएँ (परनास की जानकारी छिपाना, स्थिर अमूर्त इंटरफ़ेस, डीआईपी) आंतरिक परिवर्तनों को बाहर की ओर लीक होने से रोकने वाली बाधाएँ पैदा करती हैं।
208
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.
व्याख्या (हिन्दी) रिवर्स इंजीनियरिंग (चिकोफ़्स्की और क्रॉस) कोड से डिज़ाइन कलाकृतियों को पुनर्प्राप्त करता है: संरचना, डेटा मॉडल और व्यवहार। यह उन विरासत प्रणालियों के लिए अपरिहार्य है जहां एकमात्र जीवित कलाकृति स्रोत कोड या निष्पादन योग्य है - यह तब आम है जब कंपनियां पुरानी प्रणालियों का अधिग्रहण करती हैं या दशकों पुराने सरकारी सॉफ्टवेयर का रखरखाव करती हैं।
209
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.
व्याख्या (हिन्दी) फाउलर की रिफैक्टरिंग परिभाषा व्यवहार संरक्षण पर जोर देती है: 'सॉफ्टवेयर की आंतरिक संरचना में किया गया बदलाव, जिससे इसे समझना आसान हो और इसके अवलोकन योग्य व्यवहार को बदले बिना संशोधित करना सस्ता हो।' स्वचालित परीक्षण सत्यापित करते हैं कि व्यवहार संपूर्ण रूप से संरक्षित है।
210
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.
व्याख्या (हिन्दी) इसका नाम स्ट्रैंगलर अंजीर के पेड़ के नाम पर रखा गया है जो चारों ओर उगता है और अपने मेजबान की जगह लेता है, यह पैटर्न पूरी तरह से कटओवर के जोखिम से बचाता है। नई प्रणाली अनुरोधों को रोकती है, उन अनुरोधों को संभालती है जो वह कर सकती है और दूसरों को विरासत प्रणाली में भेजती है। समय के साथ, अधिक पथ तब तक स्थानांतरित हो जाते हैं जब तक कि विरासत प्रणाली को निष्क्रिय नहीं किया जा सकता।
196–210 of 217