361

EN + हिं Easy

GB What is 'software forensics' and in what maintenance scenarios is it applied?

IN 'सॉफ़्टवेयर फोरेंसिक' क्या है और इसे किस रखरखाव परिदृश्य में लागू किया जाता है?

A

Software forensics is the study of software patent infringement claims in legal disputes सॉफ़्टवेयर फोरेंसिक कानूनी विवादों में सॉफ़्टवेयर पेटेंट उल्लंघन के दावों का अध्ययन है

B

Software forensics applies investigative techniques to analyse software artefacts — applied in: intellectual property disputes (who wrote this code?), security incident response (how was the system breached?), understanding undocumented legacy systems, and malware analysis सॉफ़्टवेयर फोरेंसिक सॉफ़्टवेयर कलाकृतियों का विश्लेषण करने के लिए खोजी तकनीकों को लागू करता है - इसमें लागू किया जाता है: बौद्धिक संपदा विवाद (यह कोड किसने लिखा?), सुरक्षा घटना प्रतिक्रिया (सिस्टम का उल्लंघन कैसे हुआ?), अनिर्दिष्ट विरासत प्रणालियों को समझना, और मैलवेयर विश्लेषण

C

Software forensics is only used by law enforcement and has no application in normal software maintenance सॉफ़्टवेयर फोरेंसिक का उपयोग केवल कानून प्रवर्तन द्वारा किया जाता है और सामान्य सॉफ़्टवेयर रखरखाव में इसका कोई अनुप्रयोग नहीं है

D

Software forensics is identical to code review and the terms are interchangeable सॉफ़्टवेयर फोरेंसिक कोड समीक्षा के समान है और शर्तें विनिमेय हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Software forensics techniques: authorship analysis (stylometry of code to identify authors — used in IP disputes and plagiarism cases), binary analysis (malware reverse engineering), log analysis (security incident timeline reconstruction), and archaeological reconstruction (understanding undocumented legacy systems from their artefacts alone). These skills have grown in importance as code becomes a legal and security asset.

व्याख्या (हिन्दी) सॉफ्टवेयर फोरेंसिक तकनीक: लेखकत्व विश्लेषण (लेखकों की पहचान करने के लिए कोड की स्टाइलोमेट्री - आईपी विवादों और साहित्यिक चोरी के मामलों में उपयोग किया जाता है), बाइनरी विश्लेषण (मैलवेयर रिवर्स इंजीनियरिंग), लॉग विश्लेषण (सुरक्षा घटना समयरेखा पुनर्निर्माण), और पुरातात्विक पुनर्निर्माण (अकेले उनकी कलाकृतियों से अप्रलेखित विरासत प्रणालियों को समझना)। जैसे ही कोड एक कानूनी और सुरक्षा संपत्ति बन गया है, इन कौशलों का महत्व बढ़ गया है।

362

EN + हिं Easy

GB What is 'technical obsolescence' and what three strategic responses are available to organisations facing it?

IN 'तकनीकी अप्रचलन' क्या है और इसका सामना करने वाले संगठनों के लिए कौन सी तीन रणनीतिक प्रतिक्रियाएँ उपलब्ध हैं?

A

Technical obsolescence is when a software system is no longer needed by its users तकनीकी अप्रचलन तब होता है जब किसी सॉफ़्टवेयर सिस्टम की उसके उपयोगकर्ताओं को आवश्यकता नहीं रह जाती है

B

Technical obsolescence occurs when a system's technology stack (OS, language, framework) reaches EOL with no vendor support — responses: 1) wrapping (add API layer, extend lifespan), 2) migration (port to modern platform), 3) replacement (rewrite or buy replacement system) तकनीकी अप्रचलन तब होता है जब किसी सिस्टम का प्रौद्योगिकी स्टैक (ओएस, भाषा, ढांचा) बिना किसी विक्रेता समर्थन के ईओएल तक पहुंच जाता है - प्रतिक्रियाएं: 1) रैपिंग (एपीआई परत जोड़ें, जीवनकाल बढ़ाएं), 2) माइग्रेशन (आधुनिक प्लेटफॉर्म पर पोर्ट), 3) प्रतिस्थापन (प्रतिस्थापन सिस्टम को फिर से लिखें या खरीदें)

C

Technical obsolescence always requires immediate system replacement — no other response is viable तकनीकी अप्रचलन के लिए हमेशा तत्काल सिस्टम प्रतिस्थापन की आवश्यकता होती है - कोई अन्य प्रतिक्रिया व्यवहार्य नहीं है

D

Technical obsolescence is solved automatically by containerisation technologies like Docker तकनीकी अप्रचलन को डॉकर जैसी कंटेनरीकरण प्रौद्योगिकियों द्वारा स्वचालित रूप से हल किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Wrapping: expose a REST API over a legacy COBOL system — the internals stay unchanged but modern consumers can integrate. Migration: port .NET Framework 4.5 to .NET 6 — same language, major platform modernisation. Replacement: the mainframe is strategically replaced with a cloud-native system over 5 years using strangler fig. Each has different cost, risk, and timeline profiles — the choice depends on business value of the system, available skills, and risk tolerance.

व्याख्या (हिन्दी) रैपिंग: एक पुराने COBOL सिस्टम पर REST API को उजागर करें - आंतरिक अपरिवर्तित रहते हैं लेकिन आधुनिक उपभोक्ता एकीकृत कर सकते हैं। माइग्रेशन: पोर्ट .NET फ्रेमवर्क 4.5 से .NET 6 - समान भाषा, प्रमुख प्लेटफ़ॉर्म आधुनिकीकरण। प्रतिस्थापन: स्ट्रैंगलर अंजीर का उपयोग करके 5 वर्षों में मेनफ्रेम को रणनीतिक रूप से क्लाउड-नेटिव सिस्टम से बदल दिया गया है। प्रत्येक की अलग-अलग लागत, जोखिम और समयरेखा प्रोफ़ाइल होती है - चुनाव सिस्टम के व्यावसायिक मूल्य, उपलब्ध कौशल और जोखिम सहनशीलता पर निर्भर करता है।

363

EN + हिं Medium

GB What is 'software composition analysis' (SCA) and why is it a critical maintenance practice for modern applications?

IN 'सॉफ़्टवेयर संरचना विश्लेषण' (एससीए) क्या है और यह आधुनिक अनुप्रयोगों के लिए एक महत्वपूर्ण रखरखाव अभ्यास क्यों है?

A

SCA analyses whether the software meets its functional requirements after each deployment एससीए विश्लेषण करता है कि सॉफ्टवेयर प्रत्येक तैनाती के बाद अपनी कार्यात्मक आवश्यकताओं को पूरा करता है या नहीं

B

SCA inventories all third-party open-source dependencies and checks them against vulnerability databases (CVE/NVD) — critical because modern applications are 80%+ open-source code, meaning unpatched dependencies are the primary attack vector (Log4Shell, Spring4Shell) एससीए सभी तृतीय-पक्ष ओपन-सोर्स निर्भरताओं की सूची बनाता है और उन्हें भेद्यता डेटाबेस (सीवीई/एनवीडी) के विरुद्ध जांचता है - महत्वपूर्ण है क्योंकि आधुनिक एप्लिकेशन 80%+ ओपन-सोर्स कोड हैं, जिसका अर्थ है कि अप्रकाशित निर्भरताएं प्राथमिक आक्रमण वेक्टर हैं (लॉग4शेल, स्प्रिंग4शेल)

C

SCA is only required for applications that directly handle financial transactions एससीए केवल उन अनुप्रयोगों के लिए आवश्यक है जो सीधे वित्तीय लेनदेन को संभालते हैं

D

SCA is fully replaced by unit testing and code coverage analysis in modern DevSecOps pipelines आधुनिक DevSecOps पाइपलाइनों में SCA को पूरी तरह से यूनिट परीक्षण और कोड कवरेज विश्लेषण द्वारा प्रतिस्थापित किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Log4Shell (Dec 2021, CVSS 10.0) affected virtually every Java application using Log4j 2.x. Organisations without SCA had no inventory of where Log4j was used — they couldn't even identify which systems were vulnerable. SCA tools (Snyk, OWASP Dependency-Check, GitHub Dependabot) automate this: scan manifests and binaries, cross-reference CVE databases, block builds with critical vulnerabilities, and generate alerts when new CVEs are published for used libraries.

व्याख्या (हिन्दी) Log4Shell (दिसंबर 2021, CVSS 10.0) ने Log4j 2.x का उपयोग करने वाले लगभग हर जावा एप्लिकेशन को प्रभावित किया। SCA के बिना संगठनों के पास इस बात की कोई सूची नहीं थी कि Log4j का उपयोग कहाँ किया गया था - वे यह भी नहीं पहचान सके कि कौन से सिस्टम असुरक्षित थे। एससीए उपकरण (स्निक, ओडब्ल्यूएएसपी डिपेंडेंसी-चेक, गिटहब डिपेंडेबोट) इसे स्वचालित करते हैं: मैनिफ़ेस्ट और बायनेरिज़ को स्कैन करें, क्रॉस-रेफरेंस सीवीई डेटाबेस, महत्वपूर्ण कमजोरियों के साथ ब्लॉक ब्लॉक करें, और प्रयुक्त पुस्तकालयों के लिए नए सीवीई प्रकाशित होने पर अलर्ट उत्पन्न करें।

364

EN + हिं Medium

GB What is 'maintenance release planning' and how does it balance corrective, adaptive, and perfective work?

IN 'रखरखाव रिलीज योजना' क्या है और यह सुधारात्मक, अनुकूली और पूर्ण कार्य को कैसे संतुलित करती है?

A

Maintenance release planning always prioritises corrective work over all other maintenance types रखरखाव रिलीज़ योजना हमेशा अन्य सभी प्रकार के रखरखाव की तुलना में सुधारात्मक कार्य को प्राथमिकता देती है

B

Maintenance release planning allocates capacity across maintenance types based on business priorities: critical defects addressed immediately; adaptive work driven by external deadlines (OS upgrades, regulation changes); perfective work in regular releases; the allocation ratio reflects risk tolerance and strategic investment decisions रखरखाव रिलीज योजना व्यावसायिक प्राथमिकताओं के आधार पर रखरखाव के प्रकारों में क्षमता आवंटित करती है: महत्वपूर्ण दोषों को तुरंत संबोधित किया जाता है; बाहरी समय सीमा (ओएस अपग्रेड, विनियमन परिवर्तन) द्वारा संचालित अनुकूली कार्य; नियमित रिलीज़ में उत्तम कार्य; आवंटन अनुपात जोखिम सहनशीलता और रणनीतिक निवेश निर्णयों को दर्शाता है

C

Maintenance release planning eliminates the need for a product backlog by using a maintenance-specific process रखरखाव रिलीज़ योजना रखरखाव-विशिष्ट प्रक्रिया का उपयोग करके उत्पाद बैकलॉग की आवश्यकता को समाप्त कर देती है

D

All maintenance types must be planned in equal proportions to maintain system health सिस्टम के स्वास्थ्य को बनाए रखने के लिए सभी प्रकार के रखरखाव की समान अनुपात में योजना बनाई जानी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A typical enterprise allocation: ~20% emergency corrective (P1/P2 bugs addressed within SLA), ~25% adaptive (compliance, infrastructure updates, third-party API changes), ~55% perfective (new features, performance improvements, UX refinements). This shifts when: a security vulnerability demands immediate corrective focus; a major OS EOL drives adaptive work; or strategic product initiatives demand more perfective capacity.

व्याख्या (हिन्दी) एक विशिष्ट उद्यम आवंटन: ~20% आपातकालीन सुधारात्मक (एसएलए के भीतर पी1/पी2 बग का समाधान), ~25% अनुकूली (अनुपालन, बुनियादी ढाँचा अपडेट, तृतीय-पक्ष एपीआई परिवर्तन), ~55% पूर्ण (नई सुविधाएँ, प्रदर्शन सुधार, यूएक्स परिशोधन)। यह तब बदलता है जब: सुरक्षा भेद्यता तत्काल सुधारात्मक फोकस की मांग करती है; एक प्रमुख OS EOL अनुकूली कार्य को संचालित करता है; या रणनीतिक उत्पाद पहल के लिए अधिक उत्तम क्षमता की आवश्यकता होती है।

365

EN + हिं Easy

GB What is 'architecture erosion' and what governance mechanism can slow or reverse it?

IN 'वास्तुकला क्षरण' क्या है और कौन सा शासन तंत्र इसे धीमा या उलट सकता है?

A

Architecture erosion occurs when the system runs out of available disk space on production servers आर्किटेक्चर क्षरण तब होता है जब सिस्टम उत्पादन सर्वर पर उपलब्ध डिस्क स्थान से बाहर हो जाता है

B

Architecture erosion occurs when implemented code progressively diverges from intended architecture due to expedient fixes and shortcut implementations — slowed by Architecture Decision Records (ADRs), automated architectural fitness functions, and regular architecture review sessions आर्किटेक्चर क्षरण तब होता है जब कार्यान्वित कोड समीचीन सुधारों और शॉर्टकट कार्यान्वयन के कारण इच्छित आर्किटेक्चर से क्रमिक रूप से अलग हो जाता है - आर्किटेक्चर डिसीजन रिकॉर्ड्स (एडीआर), स्वचालित आर्किटेक्चरल फिटनेस फ़ंक्शंस और नियमित आर्किटेक्चर समीक्षा सत्रों द्वारा धीमा हो जाता है।

C

Architecture erosion is natural and unavoidable; no governance mechanism can address it वास्तुकला का क्षरण प्राकृतिक और अपरिहार्य है; कोई भी शासन तंत्र इसका समाधान नहीं कर सकता

D

Architecture erosion only occurs in monolithic architectures; microservices are immune to it वास्तुकला का क्षरण केवल अखंड वास्तुकला में होता है; माइक्रोसर्विसेज इससे प्रतिरक्षित हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Neal Ford's 'evolutionary architecture' concept addresses this: architectural fitness functions (automated tests checking architectural properties — no package dependency cycles, no cross-layer calls, response time thresholds) run in CI and fail builds that violate architecture. ADRs document why decisions were made — preventing 'shortcut' fixes that reintroduce patterns previously decided against. Regular architecture katas keep the team aligned.

व्याख्या (हिन्दी) नील फोर्ड की 'विकासवादी आर्किटेक्चर' अवधारणा इसे संबोधित करती है: आर्किटेक्चरल फिटनेस फ़ंक्शंस (वास्तुशिल्प गुणों की जांच करने वाले स्वचालित परीक्षण - कोई पैकेज निर्भरता चक्र, कोई क्रॉस-लेयर कॉल, प्रतिक्रिया समय सीमा नहीं) सीआई में चलते हैं और आर्किटेक्चर का उल्लंघन करने वाले विफल बिल्ड होते हैं। एडीआर दस्तावेज करते हैं कि निर्णय क्यों लिए गए - 'शॉर्टकट' सुधारों को रोकना जो पहले से तय किए गए पैटर्न को फिर से प्रस्तुत करते हैं। नियमित वास्तुकला काटा टीम को एकजुट रखता है।

366

EN + हिं Easy

GB What is 'software retirement' and what criteria should trigger a formal retirement decision?

IN 'सॉफ़्टवेयर सेवानिवृत्ति' क्या है और औपचारिक सेवानिवृत्ति निर्णय के लिए किन मानदंडों को गति देनी चाहिए?

A

Software retirement is triggered automatically when support contract expires समर्थन अनुबंध समाप्त होने पर सॉफ़्टवेयर सेवानिवृत्ति स्वचालित रूप से चालू हो जाती है

B

Software retirement decommissions a system and migrates its functions — criteria: maintenance cost exceeds business value delivered, replacement system has achieved equivalent functionality, user migration is complete, and data archival/legal retention requirements are satisfied सॉफ़्टवेयर रिटायरमेंट एक सिस्टम को निष्क्रिय कर देता है और उसके कार्यों को माइग्रेट कर देता है - मानदंड: रखरखाव लागत वितरित व्यावसायिक मूल्य से अधिक है, प्रतिस्थापन प्रणाली ने समतुल्य कार्यक्षमता हासिल कर ली है, उपयोगकर्ता माइग्रेशन पूरा हो गया है, और डेटा अभिलेखीय/कानूनी प्रतिधारण आवश्यकताएं पूरी हो गई हैं

C

Software retirement requires unanimous agreement from all stakeholders before proceeding सॉफ़्टवेयर सेवानिवृत्ति के लिए आगे बढ़ने से पहले सभी हितधारकों से सर्वसम्मत सहमति की आवश्यकता होती है

D

A system should be retired as soon as a newer technology becomes available in the market जैसे ही कोई नई तकनीक बाजार में उपलब्ध हो जाए, सिस्टम को बंद कर देना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Retirement decisions weigh: total cost of ownership (is it cheaper to maintain than replace/retire?), risk profile (is the system a security liability?), user adoption of replacement (have all users migrated?), legal requirements (some data must be retained for 7-10 years even after retirement). Premature retirement leaves users without functionality; delayed retirement wastes maintenance budget on zero-value systems.

व्याख्या (हिन्दी) सेवानिवृत्ति के निर्णयों का वजन होता है: स्वामित्व की कुल लागत (क्या इसे प्रतिस्थापित/सेवानिवृत्त करने की तुलना में बनाए रखना सस्ता है?), जोखिम प्रोफ़ाइल (क्या सिस्टम एक सुरक्षा दायित्व है?), उपयोगकर्ता द्वारा प्रतिस्थापन को अपनाना (क्या सभी उपयोगकर्ता स्थानांतरित हो गए हैं?), कानूनी आवश्यकताएं (कुछ डेटा को सेवानिवृत्ति के बाद भी 7-10 वर्षों तक बनाए रखा जाना चाहिए)। समयपूर्व सेवानिवृत्ति उपयोगकर्ताओं को कार्यक्षमता से वंचित कर देती है; विलंबित सेवानिवृत्ति शून्य-मूल्य प्रणालियों पर रखरखाव बजट बर्बाद करती है।

367

EN + हिं Easy

GB What is 'legacy modernisation' and what distinguishes 'rehosting', 'replatforming', and 'refactoring' strategies?

IN 'विरासत आधुनिकीकरण' क्या है और 'रीहोस्टिंग', 'रीप्लेटफॉर्मिंग' और 'रीफैक्टरिंग' रणनीतियों में क्या अंतर है?

A

All three strategies require complete rewriting of the system in a modern programming language सभी तीन रणनीतियों के लिए आधुनिक प्रोग्रामिंग भाषा में सिस्टम के पूर्ण पुनर्लेखन की आवश्यकता होती है

B

Rehosting ('lift and shift') moves to new infrastructure without code changes; replatforming makes minimal code changes to leverage cloud capabilities; refactoring restructures code for maintainability while preserving functionality — cost/risk increases in that order, as does modernisation value रीहोस्टिंग ('लिफ्ट और शिफ्ट') कोड परिवर्तन के बिना नए बुनियादी ढांचे में ले जाती है; क्लाउड क्षमताओं का लाभ उठाने के लिए रीप्लेटफ़ॉर्मिंग न्यूनतम कोड परिवर्तन करता है; कार्यक्षमता को संरक्षित करते हुए रखरखाव के लिए रीफैक्टरिंग कोड को पुनर्गठित करता है - उसी क्रम में लागत/जोखिम बढ़ता है, जैसा कि आधुनिकीकरण मूल्य में होता है

C

Rehosting is always preferred because it is cheapest and provides maximum modernisation value रीहोस्टिंग को हमेशा प्राथमिकता दी जाती है क्योंकि यह सबसे सस्ता है और अधिकतम आधुनिकीकरण मूल्य प्रदान करता है

D

All legacy modernisation strategies require a complete system shutdown during the migration period सभी विरासती आधुनिकीकरण रणनीतियों के लिए प्रवासन अवधि के दौरान पूर्ण सिस्टम शटडाउन की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Gartner's 5Rs (now 7Rs) of cloud migration: Rehost — VM to cloud VM, no code changes, quick but misses cloud-native benefits; Replatform — use managed services (RDS instead of self-managed DB), minor code changes; Refactor — redesign for cloud-native (containerise, add auto-scaling). Each represents increasing investment and increasing long-term benefit. Most organisations start with rehosting for speed, then replatform/refactor as the business case justifies.

व्याख्या (हिन्दी) क्लाउड माइग्रेशन के लिए गार्टनर के 5Rs (अब 7Rs): रीहोस्ट - VM से क्लाउड VM, कोई कोड परिवर्तन नहीं, त्वरित लेकिन क्लाउड-नेटिव लाभ नहीं; रिप्लेटफ़ॉर्म - प्रबंधित सेवाओं का उपयोग करें (स्व-प्रबंधित डीबी के बजाय आरडीएस), मामूली कोड परिवर्तन; रिफैक्टर - क्लाउड-नेटिव के लिए रीडिज़ाइन (कंटेनराइज़, ऑटो-स्केलिंग जोड़ें)। प्रत्येक बढ़ते निवेश और बढ़ते दीर्घकालिक लाभ का प्रतिनिधित्व करता है। अधिकांश संगठन गति के लिए रीहोस्टिंग से शुरुआत करते हैं, फिर व्यावसायिक मामले के अनुसार रीप्लेटफ़ॉर्म/रिफ़ेक्टर करते हैं।

368

EN + हिं Easy

GB What is 'mean time to repair' (MTTR) versus 'mean time between failures' (MTBF) and which metric matters most for high-availability systems?

IN 'मरम्मत का औसत समय' (MTTR) बनाम 'विफलताओं के बीच का औसत समय' (MTBF) क्या है और उच्च-उपलब्धता प्रणालियों के लिए कौन सा मीट्रिक सबसे अधिक मायने रखता है?

A

MTBF measures repair speed; MTTR measures failure frequency — both are equally important एमटीबीएफ मरम्मत की गति को मापता है; एमटीटीआर विफलता की आवृत्ति को मापता है - दोनों समान रूप से महत्वपूर्ण हैं

B

MTBF is the average time between failures (reliability measure); MTTR is the average time to restore service after failure (recovery measure) — for high-availability systems, minimising MTTR often provides more availability improvement than reducing MTBF, as modern systems accept failures as inevitable एमटीबीएफ विफलताओं (विश्वसनीयता माप) के बीच का औसत समय है; एमटीटीआर विफलता (पुनर्प्राप्ति उपाय) के बाद सेवा को बहाल करने का औसत समय है - उच्च उपलब्धता प्रणालियों के लिए, एमटीटीआर को कम करने से अक्सर एमटीबीएफ को कम करने की तुलना में अधिक उपलब्धता में सुधार होता है, क्योंकि आधुनिक सिस्टम विफलताओं को अपरिहार्य मानते हैं

C

MTBF is the only metric that matters; systems with long MTBF always have high availability एमटीबीएफ एकमात्र मीट्रिक है जो मायने रखती है; लंबे एमटीबीएफ वाले सिस्टम में हमेशा उच्च उपलब्धता होती है

D

MTTR only applies to hardware components; software systems use different metrics एमटीटीआर केवल हार्डवेयर घटकों पर लागू होता है; सॉफ़्टवेयर सिस्टम विभिन्न मेट्रिक्स का उपयोग करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Availability = MTBF / (MTBF + MTTR). Netflix's chaos engineering philosophy: accept that failures will happen (don't rely solely on MTBF); invest in fast recovery (MTTR). A system that fails every 24 hours but recovers in 1 second has 99.999% availability. A system that fails every 1000 hours but takes 10 minutes to recover has 99.98% availability. Modern DevOps focuses on MTTR: automated rollbacks, circuit breakers, health checks, and zero-downtime deployments.

व्याख्या (हिन्दी) उपलब्धता = एमटीबीएफ / (एमटीबीएफ + एमटीटीआर)। नेटफ्लिक्स की अराजकता इंजीनियरिंग दर्शन: स्वीकार करें कि विफलताएं होंगी (केवल एमटीबीएफ पर भरोसा न करें); तेजी से रिकवरी (एमटीटीआर) में निवेश करें। एक प्रणाली जो हर 24 घंटे में विफल हो जाती है लेकिन 1 सेकंड में ठीक हो जाती है उसकी 99.999% उपलब्धता होती है। एक सिस्टम जो हर 1000 घंटे में विफल हो जाता है लेकिन ठीक होने में 10 मिनट लेता है उसकी 99.98% उपलब्धता होती है। आधुनिक डेवऑप्स एमटीटीआर पर केंद्रित है: स्वचालित रोलबैक, सर्किट ब्रेकर, स्वास्थ्य जांच और शून्य-डाउनटाइम तैनाती।

369

EN + हिं Medium

GB What is 'software re-engineering' and how does it differ from plain refactoring?

IN 'सॉफ़्टवेयर री-इंजीनियरिंग' क्या है और यह सादे रीफैक्टरिंग से किस प्रकार भिन्न है?

A

Software re-engineering is identical to refactoring; the terms are used interchangeably सॉफ़्टवेयर री-इंजीनियरिंग रीफैक्टरिंग के समान है; शब्दों का प्रयोग परस्पर उपयोग किया जाता है

B

Re-engineering examines and alters an existing system to reconstruct it in a new form at a higher level of abstraction — it includes reverse engineering (understanding existing system), restructuring, and forward engineering, often transforming the system's architecture, not just code quality री-इंजीनियरिंग एक मौजूदा सिस्टम की जांच करती है और उसे अमूर्तता के उच्च स्तर पर एक नए रूप में पुनर्निर्माण करने के लिए बदल देती है - इसमें रिवर्स इंजीनियरिंग (मौजूदा सिस्टम को समझना), पुनर्गठन और फॉरवर्ड इंजीनियरिंग शामिल है, जो अक्सर सिस्टम की वास्तुकला को बदल देती है, न कि केवल कोड गुणवत्ता को।

C

Re-engineering requires complete system shutdown and data migration before work can begin री-इंजीनियरिंग के लिए काम शुरू होने से पहले पूर्ण सिस्टम शटडाउन और डेटा माइग्रेशन की आवश्यकता होती है

D

Re-engineering only applies when moving from one programming language to another री-इंजीनियरिंग केवल एक प्रोग्रामिंग भाषा से दूसरी प्रोग्रामिंग भाषा में जाने पर लागू होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Refactoring improves code quality without changing behaviour or architecture (Fowler's definition). Re-engineering is broader (Chikofsky and Cross): it may change the architecture, platform, or paradigm while preserving functionality. Re-engineering a procedural COBOL system into a microservices architecture involves reverse engineering its business logic, restructuring into services, and forward engineering modern code — far beyond refactoring.

व्याख्या (हिन्दी) रीफैक्टरिंग व्यवहार या वास्तुकला को बदले बिना कोड गुणवत्ता में सुधार करती है (फाउलर की परिभाषा)। री-इंजीनियरिंग व्यापक है (चिकोफ़्स्की और क्रॉस): यह कार्यक्षमता को संरक्षित करते हुए वास्तुकला, मंच या प्रतिमान को बदल सकती है। एक प्रक्रियात्मक COBOL प्रणाली को माइक्रोसर्विसेज आर्किटेक्चर में पुन: इंजीनियरिंग करने में इसके व्यावसायिक तर्क को रिवर्स इंजीनियरिंग, सेवाओं में पुनर्गठन और आधुनिक कोड को आगे बढ़ाने वाली इंजीनियरिंग शामिल है - रिफैक्टरिंग से कहीं आगे।

370

EN + हिं Easy

GB Which of the following best describes 'software entropy' and its long-term impact?

IN निम्नलिखित में से कौन सा 'सॉफ़्टवेयर एन्ट्रॉपी' और इसके दीर्घकालिक प्रभाव का सबसे अच्छा वर्णन करता है?

A

Encrypted sections that reduce performance एन्क्रिप्टेड अनुभाग जो प्रदर्शन को कम करते हैं

B

Gradual code quality degradation due to uncoordinated changes increasing complexity and maintenance cost असंगठित परिवर्तनों के कारण धीरे-धीरे कोड गुणवत्ता में गिरावट से जटिलता और रखरखाव लागत बढ़ रही है

C

Reduction in defects over the software lifecycle सॉफ़्टवेयर जीवनचक्र में दोषों में कमी

D

Efficient use of CPU and memory by the software सॉफ्टवेयर द्वारा सीपीयू और मेमोरी का कुशल उपयोग

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Software entropy (software rot) refers to increasing disorder in a codebase caused by accumulated patches and uncoordinated changes. Over time it raises complexity, making the system harder to maintain and more prone to defects.

व्याख्या (हिन्दी) सॉफ़्टवेयर एन्ट्रॉपी (सॉफ़्टवेयर रोट) संचित पैच और असंगठित परिवर्तनों के कारण कोडबेस में बढ़ती अव्यवस्था को संदर्भित करता है। समय के साथ यह जटिलता बढ़ाता है, जिससे सिस्टम को बनाए रखना कठिन हो जाता है और दोषों की संभावना अधिक हो जाती है।

371

EN + हिं Easy

GB What is the primary distinction between 'validation' and 'verification' in software engineering?

IN सॉफ़्टवेयर इंजीनियरिंग में 'सत्यापन' और 'सत्यापन' के बीच प्राथमिक अंतर क्या है?

A

Validation is by developers; verification is by users सत्यापन डेवलपर्स द्वारा किया जाता है; सत्यापन उपयोगकर्ताओं द्वारा होता है

B

Verification checks the product is built correctly per specs; validation checks the right product is built for user needs सत्यापन यह जांचता है कि उत्पाद विशिष्टताओं के अनुसार सही ढंग से बनाया गया है; सत्यापन यह जाँचता है कि उपयोगकर्ता की ज़रूरतों के लिए सही उत्पाद बनाया गया है

C

Validation is static analysis; verification is dynamic testing सत्यापन स्थैतिक विश्लेषण है; सत्यापन गतिशील परीक्षण है

D

Both terms are synonymous per IEEE standards आईईईई मानकों के अनुसार दोनों शब्द पर्यायवाची हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Verification answers 'Are we building the product right?' by checking conformance to specifications, while validation answers 'Are we building the right product?' by checking actual user needs. Both are essential but address different concerns.

व्याख्या (हिन्दी) सत्यापन उत्तर 'क्या हम उत्पाद सही ढंग से बना रहे हैं?' विशिष्टताओं के अनुरूपता की जाँच करके, जबकि सत्यापन उत्तर देता है 'क्या हम सही उत्पाद बना रहे हैं?' वास्तविक उपयोगकर्ता आवश्यकताओं की जाँच करके। दोनों आवश्यक हैं लेकिन अलग-अलग चिंताओं का समाधान करते हैं।

372

EN + हिं Medium

GB Which factor does NOT directly influence the unadjusted function point count in Function Point Analysis?

IN फ़ंक्शन बिंदु विश्लेषण में कौन सा कारक असमायोजित फ़ंक्शन बिंदु गणना को सीधे प्रभावित नहीं करता है?

A

Number of external inputs बाह्य इनपुट की संख्या

B

Number of internal logical files आंतरिक तार्किक फ़ाइलों की संख्या

C

Number of external outputs बाह्य आउटपुट की संख्या

D

Programming language used for implementation कार्यान्वयन के लिए प्रोग्रामिंग भाषा का उपयोग किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Unadjusted Function Points are derived from five functional components: external inputs, outputs, inquiries, internal logical files, and external interface files. The programming language affects productivity but not the functional size measurement.

व्याख्या (हिन्दी) असमायोजित फ़ंक्शन पॉइंट पांच कार्यात्मक घटकों से प्राप्त होते हैं: बाहरी इनपुट, आउटपुट, पूछताछ, आंतरिक तार्किक फ़ाइलें और बाहरी इंटरफ़ेस फ़ाइलें। प्रोग्रामिंग भाषा उत्पादकता को प्रभावित करती है लेकिन कार्यात्मक आकार माप को नहीं।

373

EN + हिं Easy

GB What does 'technical debt' specifically imply in the context of long-running software projects?

IN लंबे समय से चलने वाली सॉफ़्टवेयर परियोजनाओं के संदर्भ में 'तकनीकी ऋण' का विशेष रूप से क्या अर्थ है?

A

Financial cost of purchasing software licenses सॉफ़्टवेयर लाइसेंस खरीदने की वित्तीय लागत

B

Accumulated suboptimal design decisions for short-term gain that must be refactored at greater future cost अल्पकालिक लाभ के लिए संचित उप-इष्टतम डिजाइन निर्णय जिन्हें भविष्य में अधिक लागत पर दोबारा तैयार किया जाना चाहिए

C

Outstanding unresolved bug reports in the backlog बैकलॉग में बकाया अनसुलझे बग रिपोर्ट

D

Lag between software release and user adoption सॉफ़्टवेयर रिलीज़ और उपयोगकर्ता द्वारा अपनाए जाने के बीच अंतराल

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Technical debt (Ward Cunningham) is the implied cost of rework caused by choosing quick-and-easy solutions over better long-term approaches. Like financial debt, it accrues interest — the longer it is left unaddressed, the more expensive it becomes to fix.

व्याख्या (हिन्दी) तकनीकी ऋण (वार्ड कनिंघम) बेहतर दीर्घकालिक दृष्टिकोण की तुलना में त्वरित और आसान समाधान चुनने के कारण होने वाली पुन: कार्य की निहित लागत है। वित्तीय ऋण की तरह, इस पर ब्याज लगता है - जितना अधिक समय तक इसका समाधान नहीं किया जाता है, इसे ठीक करना उतना ही महंगा हो जाता है।

374

EN + हिं Medium

GB According to Lehman's Law of Continuing Change, what must happen to an E-type program?

IN लेहमैन के सतत परिवर्तन के नियम के अनुसार, ई-प्रकार के कार्यक्रम का क्या होना चाहिए?

A

Its complexity must be actively reduced each release प्रत्येक रिलीज़ में इसकी जटिलता को सक्रिय रूप से कम किया जाना चाहिए

B

It must be continually adapted or it becomes progressively less satisfactory in its real-world environment इसे लगातार अनुकूलित किया जाना चाहिए अन्यथा यह अपने वास्तविक दुनिया के वातावरण में उत्तरोत्तर कम संतोषजनक होता जाएगा

C

Its rate of change is proportional to team size इसके परिवर्तन की दर टीम के आकार के समानुपाती होती है

D

Its functionality grows at a constant rate इसकी कार्यक्षमता निरंतर दर से बढ़ती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Lehman's First Law states that an E-type (embedded) system must be continually adapted to remain satisfactory in its changing operational environment. Failure to adapt causes the system to become increasingly unsatisfactory and eventually obsolete.

व्याख्या (हिन्दी) लेहमैन का पहला कानून कहता है कि एक ई-प्रकार (एम्बेडेड) प्रणाली को अपने बदलते परिचालन वातावरण में संतोषजनक बने रहने के लिए लगातार अनुकूलित किया जाना चाहिए। अनुकूलन में विफलता के कारण प्रणाली तेजी से असंतोषजनक और अंततः अप्रचलित हो जाती है।

375

EN + हिं Medium

GB Which software quality attribute is most directly compromised by high coupling between modules?

IN मॉड्यूल के बीच उच्च युग्मन द्वारा किस सॉफ़्टवेयर गुणवत्ता विशेषता से सबसे अधिक सीधे समझौता किया जाता है?

A

Portability पोर्टेबिलिटी

B

Maintainability रख-रखाव

C

Usability प्रयोज्य

D

Reliability विश्वसनीयता

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) High coupling means modules are tightly dependent on each other's internals, so a change in one requires corresponding changes in others. This directly undermines maintainability because isolated modifications, testing, and replacement of modules become difficult.

व्याख्या (हिन्दी) उच्च युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के अंदरूनी हिस्सों पर मजबूती से निर्भर हैं, इसलिए एक में बदलाव के लिए दूसरों में इसी तरह के बदलाव की आवश्यकता होती है। यह सीधे तौर पर रखरखाव को कमजोर करता है क्योंकि अलग-अलग संशोधन, परीक्षण और मॉड्यूल का प्रतिस्थापन मुश्किल हो जाता है।

Software Engineering — MCQ Practice