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
211
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 का चौथा रखरखाव प्रकार, बाद में जोड़ा गया) विफलताओं का कारण बनने से पहले ज्ञात रखरखाव जोखिमों को संबोधित करता है: स्पेगेटी कोड का पुनर्गठन, अप्रचलित निर्भरता को अपडेट करना, उच्च जोखिम वाले मॉड्यूल में परीक्षण कवरेज में सुधार करना। परफेक्ट रखरखाव नई सुविधाओं या प्रदर्शन में सुधार के लिए उपयोगकर्ता के अनुरोधों का जवाब देता है। निवारक सक्रिय आंतरिक गुणवत्ता निवेश है; परफेक्ट प्रतिक्रियाशील बाह्य मूल्य वितरण है।
212
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.
व्याख्या (हिन्दी) रिलीज प्रबंधन तात्कालिकता और दायरे के आधार पर अंतर करता है। हॉटफ़िक्स: उत्पादन कम है या गंभीर रूप से ख़राब है - घंटों में तैनात करें, केवल महत्वपूर्ण पथ का परीक्षण करें, जोखिम स्वीकार किया गया है। पैच: नियमित दोष संग्रहण - साप्ताहिक/मासिक ताल, पूर्ण प्रतिगमन सुइट। लघु: नियोजित सुविधा परिवर्धन - पूर्ण परीक्षण चक्र, रिलीज़ नोट्स, एपीआई उपभोक्ताओं के लिए माइग्रेशन गाइड। सिमेंटिक वर्जनिंग इन भेदों को MAJOR.MINOR.PATCH के रूप में एन्कोड करता है।
213
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) ने विरासती सिस्टम को असमर्थित दुभाषियों के साथ चलाया। ईओएल योजना के लिए आवश्यक है: उपयोगकर्ताओं के लिए अग्रिम सूचना, माइग्रेशन गाइड, ओवरलैप अवधि जहां पुराने और नए संस्करण सह-अस्तित्व में हैं, और पुराने संस्करण के समर्थन की समाप्ति। ईओएल सॉफ़्टवेयर का उपभोग करने वाले संगठनों को ईओएल तिथियों से पहले माइग्रेशन की योजना बनानी चाहिए, उसके बाद नहीं।
214
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 नीति गैर-अनुपालक कॉन्फ़िगरेशन के लिए लगातार स्कैन करते हैं।
215
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 देखें' जैसी टिप्पणियाँ) संदर्भ को सुरक्षित रखता है; क्रॉस-ट्रेनिंग यह सुनिश्चित करती है कि किसी एक व्यक्ति के पास महत्वपूर्ण ज्ञान न हो।
216
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% दोष होते हैं, और वही फ़ाइलें समय के साथ और अधिक दोष जमा करती हैं। टूटी खिड़कियों का प्रभाव: खराब कोड देखकर डेवलपर्स यह निष्कर्ष निकालते हैं कि 'हम यहां इसी तरह काम करते हैं' और कम सावधानी बरतते हैं। बॉय स्काउट नियम प्रत्यक्ष प्रति-अभ्यास है: कोड को जितना आपने पाया था उससे बेहतर छोड़ें, जिससे देखभाल का एक दृश्यमान मानक तैयार हो सके।
217
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% ओवरहेड जोड़ती हैं। यह डिज़ाइन गुणवत्ता में निवेश के आरओआई की मात्रा निर्धारित करता है - सिस्टम के जीवनकाल में कम रखरखाव लागत अग्रिम डिज़ाइन निवेश से अधिक है।
211–217 of 217