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
2596
EN + हिं Easy
GB What is 'impact analysis' in software change management and what artefacts does it require?
IN सॉफ़्टवेयर परिवर्तन प्रबंधन में 'प्रभाव विश्लेषण' क्या है और इसके लिए किन कलाकृतियों की आवश्यकता है?
A
Impact analysis measures the financial cost of a software defect after production deployment प्रभाव विश्लेषण उत्पादन परिनियोजन के बाद सॉफ़्टवेयर दोष की वित्तीय लागत को मापता है
B
Impact analysis determines which system components, tests, documents, and dependent systems will be affected by a proposed change — requiring: design documentation, traceability matrices, dependency maps, and test coverage data to accurately scope change effects प्रभाव विश्लेषण यह निर्धारित करता है कि कौन से सिस्टम घटक, परीक्षण, दस्तावेज़ और आश्रित सिस्टम प्रस्तावित परिवर्तन से प्रभावित होंगे - आवश्यकता है: डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिसेस, निर्भरता मानचित्र, और परिवर्तन प्रभावों को सटीक रूप से लागू करने के लिए कवरेज डेटा का परीक्षण करें।
C
Impact analysis is only required for changes that touch the database schema प्रभाव विश्लेषण केवल उन परिवर्तनों के लिए आवश्यक है जो डेटाबेस स्कीमा को छूते हैं
D
Modern refactoring tools perform impact analysis automatically, eliminating the need for documentation आधुनिक रीफैक्टरिंग उपकरण स्वचालित रूप से प्रभाव विश्लेषण करते हैं, जिससे दस्तावेज़ीकरण की आवश्यकता समाप्त हो जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Impact analysis prevents scope blindness: changing a function signature without knowing it's called by 47 modules leads to cascading compile errors. Thorough impact analysis answers: which tests must be updated? Which documents are now inaccurate? Which downstream systems consume this API? Which data migrations are needed? Without artefacts (design docs, traceability matrices), impact analysis degrades to guesswork.
व्याख्या (हिन्दी) प्रभाव विश्लेषण स्कोप ब्लाइंडनेस को रोकता है: किसी फ़ंक्शन हस्ताक्षर को 47 मॉड्यूल द्वारा कॉल किए जाने के बिना बदलने से कैस्केडिंग संकलन त्रुटियां होती हैं। संपूर्ण प्रभाव विश्लेषण उत्तर: कौन से परीक्षण अद्यतन किए जाने चाहिए? अब कौन से दस्तावेज़ ग़लत हैं? कौन से डाउनस्ट्रीम सिस्टम इस एपीआई का उपभोग करते हैं? कौन से डेटा माइग्रेशन की आवश्यकता है? कलाकृतियों (डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिक्स) के बिना, प्रभाव विश्लेषण अनुमान लगाने में कम हो जाता है।
2597
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.
व्याख्या (हिन्दी) सॉफ्टवेयर फोरेंसिक तकनीक: लेखकत्व विश्लेषण (लेखकों की पहचान करने के लिए कोड की स्टाइलोमेट्री - आईपी विवादों और साहित्यिक चोरी के मामलों में उपयोग किया जाता है), बाइनरी विश्लेषण (मैलवेयर रिवर्स इंजीनियरिंग), लॉग विश्लेषण (सुरक्षा घटना समयरेखा पुनर्निर्माण), और पुरातात्विक पुनर्निर्माण (अकेले उनकी कलाकृतियों से अप्रलेखित विरासत प्रणालियों को समझना)। जैसे ही कोड एक कानूनी और सुरक्षा संपत्ति बन गया है, इन कौशलों का महत्व बढ़ गया है।
2598
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 नीति गैर-अनुपालक कॉन्फ़िगरेशन के लिए लगातार स्कैन करते हैं।
2599
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 वर्षों में मेनफ्रेम को रणनीतिक रूप से क्लाउड-नेटिव सिस्टम से बदल दिया गया है। प्रत्येक की अलग-अलग लागत, जोखिम और समयरेखा प्रोफ़ाइल होती है - चुनाव सिस्टम के व्यावसायिक मूल्य, उपलब्ध कौशल और जोखिम सहनशीलता पर निर्भर करता है।
2600
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 का उपयोग कहाँ किया गया था - वे यह भी नहीं पहचान सके कि कौन से सिस्टम असुरक्षित थे। एससीए उपकरण (स्निक, ओडब्ल्यूएएसपी डिपेंडेंसी-चेक, गिटहब डिपेंडेबोट) इसे स्वचालित करते हैं: मैनिफ़ेस्ट और बायनेरिज़ को स्कैन करें, क्रॉस-रेफरेंस सीवीई डेटाबेस, महत्वपूर्ण कमजोरियों के साथ ब्लॉक ब्लॉक करें, और प्रयुक्त पुस्तकालयों के लिए नए सीवीई प्रकाशित होने पर अलर्ट उत्पन्न करें।
2601
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 अनुकूली कार्य को संचालित करता है; या रणनीतिक उत्पाद पहल के लिए अधिक उत्तम क्षमता की आवश्यकता होती है।
2602
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.
व्याख्या (हिन्दी) नील फोर्ड की 'विकासवादी आर्किटेक्चर' अवधारणा इसे संबोधित करती है: आर्किटेक्चरल फिटनेस फ़ंक्शंस (वास्तुशिल्प गुणों की जांच करने वाले स्वचालित परीक्षण - कोई पैकेज निर्भरता चक्र, कोई क्रॉस-लेयर कॉल, प्रतिक्रिया समय सीमा नहीं) सीआई में चलते हैं और आर्किटेक्चर का उल्लंघन करने वाले विफल बिल्ड होते हैं। एडीआर दस्तावेज करते हैं कि निर्णय क्यों लिए गए - 'शॉर्टकट' सुधारों को रोकना जो पहले से तय किए गए पैटर्न को फिर से प्रस्तुत करते हैं। नियमित वास्तुकला काटा टीम को एकजुट रखता है।
2603
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 देखें' जैसी टिप्पणियाँ) संदर्भ को सुरक्षित रखता है; क्रॉस-ट्रेनिंग यह सुनिश्चित करती है कि किसी एक व्यक्ति के पास महत्वपूर्ण ज्ञान न हो।
2604
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 वर्षों तक बनाए रखा जाना चाहिए)। समयपूर्व सेवानिवृत्ति उपयोगकर्ताओं को कार्यक्षमता से वंचित कर देती है; विलंबित सेवानिवृत्ति शून्य-मूल्य प्रणालियों पर रखरखाव बजट बर्बाद करती है।
2605
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, कोई कोड परिवर्तन नहीं, त्वरित लेकिन क्लाउड-नेटिव लाभ नहीं; रिप्लेटफ़ॉर्म - प्रबंधित सेवाओं का उपयोग करें (स्व-प्रबंधित डीबी के बजाय आरडीएस), मामूली कोड परिवर्तन; रिफैक्टर - क्लाउड-नेटिव के लिए रीडिज़ाइन (कंटेनराइज़, ऑटो-स्केलिंग जोड़ें)। प्रत्येक बढ़ते निवेश और बढ़ते दीर्घकालिक लाभ का प्रतिनिधित्व करता है। अधिकांश संगठन गति के लिए रीहोस्टिंग से शुरुआत करते हैं, फिर व्यावसायिक मामले के अनुसार रीप्लेटफ़ॉर्म/रिफ़ेक्टर करते हैं।
2606
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% उपलब्धता होती है। आधुनिक डेवऑप्स एमटीटीआर पर केंद्रित है: स्वचालित रोलबैक, सर्किट ब्रेकर, स्वास्थ्य जांच और शून्य-डाउनटाइम तैनाती।
2607
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 प्रणाली को माइक्रोसर्विसेज आर्किटेक्चर में पुन: इंजीनियरिंग करने में इसके व्यावसायिक तर्क को रिवर्स इंजीनियरिंग, सेवाओं में पुनर्गठन और आधुनिक कोड को आगे बढ़ाने वाली इंजीनियरिंग शामिल है - रिफैक्टरिंग से कहीं आगे।
2608
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% दोष होते हैं, और वही फ़ाइलें समय के साथ और अधिक दोष जमा करती हैं। टूटी खिड़कियों का प्रभाव: खराब कोड देखकर डेवलपर्स यह निष्कर्ष निकालते हैं कि 'हम यहां इसी तरह काम करते हैं' और कम सावधानी बरतते हैं। बॉय स्काउट नियम प्रत्यक्ष प्रति-अभ्यास है: कोड को जितना आपने पाया था उससे बेहतर छोड़ें, जिससे देखभाल का एक दृश्यमान मानक तैयार हो सके।
2609
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% ओवरहेड जोड़ती हैं। यह डिज़ाइन गुणवत्ता में निवेश के आरओआई की मात्रा निर्धारित करता है - सिस्टम के जीवनकाल में कम रखरखाव लागत अग्रिम डिज़ाइन निवेश से अधिक है।
2610
EN + हिं Medium
GB What is 'software quality assurance' (SQA) and how does it differ from software testing?
IN 'सॉफ़्टवेयर गुणवत्ता आश्वासन' (SQA) क्या है और यह सॉफ़्टवेयर परीक्षण से किस प्रकार भिन्न है?
A
SQA and software testing are synonymous terms describing the same activity SQA और सॉफ़्टवेयर परीक्षण एक ही गतिविधि का वर्णन करने वाले पर्यायवाची शब्द हैं
B
SQA is a systematic, planned set of actions ensuring the software development process is followed correctly; testing is a subset of SQA that verifies the product — SQA audits the process, testing evaluates the product एसक्यूए कार्यों का एक व्यवस्थित, नियोजित सेट है जो यह सुनिश्चित करता है कि सॉफ्टवेयर विकास प्रक्रिया का सही ढंग से पालन किया जाए; परीक्षण SQA का एक उपसमूह है जो उत्पाद का सत्यापन करता है - SQA प्रक्रिया का ऑडिट करता है, परीक्षण उत्पाद का मूल्यांकन करता है
C
SQA only applies to the final product release; testing applies throughout development SQA केवल अंतिम उत्पाद रिलीज़ पर लागू होता है; परीक्षण पूरे विकास में लागू होता है
D
SQA is performed by an external auditing agency; testing by the internal development team SQA एक बाहरी ऑडिटिंग एजेंसी द्वारा किया जाता है; आंतरिक विकास टीम द्वारा परीक्षण
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SQA (IEEE 730) encompasses process adherence: are reviews being conducted? Are standards followed? Are change management procedures applied? Testing is product-focused: does this build pass its test suite? SQA would catch 'the team skipped design reviews' — a process defect. Testing would catch 'this function returns wrong results' — a product defect. Both are needed.
व्याख्या (हिन्दी) SQA (IEEE 730) में प्रक्रिया का पालन शामिल है: क्या समीक्षाएँ की जा रही हैं? क्या मानकों का पालन किया जाता है? क्या परिवर्तन प्रबंधन प्रक्रियाएँ लागू की गई हैं? परीक्षण उत्पाद-केंद्रित है: क्या यह बिल्ड अपना परीक्षण सूट पास करता है? SQA 'टीम द्वारा डिज़ाइन समीक्षाएँ छोड़े जाने' को पकड़ लेगा - एक प्रक्रिया दोष। परीक्षण से पता चलेगा कि 'यह फ़ंक्शन गलत परिणाम देता है' - एक उत्पाद दोष। दोनों की जरूरत है.
2596–2610 of 2726