Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
541
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.
व्याख्या (हिन्दी) नील फोर्ड की 'विकासवादी आर्किटेक्चर' अवधारणा इसे संबोधित करती है: आर्किटेक्चरल फिटनेस फ़ंक्शंस (वास्तुशिल्प गुणों की जांच करने वाले स्वचालित परीक्षण - कोई पैकेज निर्भरता चक्र, कोई क्रॉस-लेयर कॉल, प्रतिक्रिया समय सीमा नहीं) सीआई में चलते हैं और आर्किटेक्चर का उल्लंघन करने वाले विफल बिल्ड होते हैं। एडीआर दस्तावेज करते हैं कि निर्णय क्यों लिए गए - 'शॉर्टकट' सुधारों को रोकना जो पहले से तय किए गए पैटर्न को फिर से प्रस्तुत करते हैं। नियमित वास्तुकला काटा टीम को एकजुट रखता है।
542
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 वर्षों तक बनाए रखा जाना चाहिए)। समयपूर्व सेवानिवृत्ति उपयोगकर्ताओं को कार्यक्षमता से वंचित कर देती है; विलंबित सेवानिवृत्ति शून्य-मूल्य प्रणालियों पर रखरखाव बजट बर्बाद करती है।
543
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, कोई कोड परिवर्तन नहीं, त्वरित लेकिन क्लाउड-नेटिव लाभ नहीं; रिप्लेटफ़ॉर्म - प्रबंधित सेवाओं का उपयोग करें (स्व-प्रबंधित डीबी के बजाय आरडीएस), मामूली कोड परिवर्तन; रिफैक्टर - क्लाउड-नेटिव के लिए रीडिज़ाइन (कंटेनराइज़, ऑटो-स्केलिंग जोड़ें)। प्रत्येक बढ़ते निवेश और बढ़ते दीर्घकालिक लाभ का प्रतिनिधित्व करता है। अधिकांश संगठन गति के लिए रीहोस्टिंग से शुरुआत करते हैं, फिर व्यावसायिक मामले के अनुसार रीप्लेटफ़ॉर्म/रिफ़ेक्टर करते हैं।
544
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% उपलब्धता होती है। आधुनिक डेवऑप्स एमटीटीआर पर केंद्रित है: स्वचालित रोलबैक, सर्किट ब्रेकर, स्वास्थ्य जांच और शून्य-डाउनटाइम तैनाती।
545
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 प्रणाली को माइक्रोसर्विसेज आर्किटेक्चर में पुन: इंजीनियरिंग करने में इसके व्यावसायिक तर्क को रिवर्स इंजीनियरिंग, सेवाओं में पुनर्गठन और आधुनिक कोड को आगे बढ़ाने वाली इंजीनियरिंग शामिल है - रिफैक्टरिंग से कहीं आगे।
546
EN + हिं Easy
GB What is the 'capability maturity model' (CMM) and what does reaching level 5 ('Optimising') mean operationally?
IN 'क्षमता परिपक्वता मॉडल' (सीएमएम) क्या है और स्तर 5 ('अनुकूलन') तक पहुंचने का परिचालनात्मक रूप से क्या मतलब है?
A
Level 5 means the organisation has zero defects in all released software लेवल 5 का मतलब है कि संगठन के सभी जारी किए गए सॉफ़्टवेयर में कोई दोष नहीं है
B
CMM describes software process maturity in five levels; Level 5 (Optimising) means the organisation uses quantitative data from its defined processes to drive continuous process improvement — defect prevention through systematic root cause analysis सीएमएम पांच स्तरों में सॉफ्टवेयर प्रक्रिया की परिपक्वता का वर्णन करता है; स्तर 5 (अनुकूलन) का अर्थ है कि संगठन निरंतर प्रक्रिया में सुधार लाने के लिए अपनी परिभाषित प्रक्रियाओं से मात्रात्मक डेटा का उपयोग करता है - व्यवस्थित मूल कारण विश्लेषण के माध्यम से दोष निवारण
C
Level 5 requires the organisation to use formal mathematical proofs for all software स्तर 5 के लिए संगठन को सभी सॉफ़्टवेयर के लिए औपचारिक गणितीय प्रमाणों का उपयोग करने की आवश्यकता होती है
D
CMM Level 5 is only achievable by organisations with more than 10,000 developers सीएमएम स्तर 5 केवल 10,000 से अधिक डेवलपर्स वाले संगठनों द्वारा ही प्राप्त किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CMM Level 5 (Optimising) organisations measure process performance quantitatively and use that data to identify improvement opportunities. They implement defect prevention (analysing root causes of defects to prevent entire classes from recurring) and technology change management (evaluating and adopting new technologies). This is distinct from Level 4 (Managed) which uses measurements to control processes but does not yet systematically improve them.
व्याख्या (हिन्दी) सीएमएम स्तर 5 (अनुकूलन) संगठन प्रक्रिया प्रदर्शन को मात्रात्मक रूप से मापते हैं और सुधार के अवसरों की पहचान करने के लिए उस डेटा का उपयोग करते हैं। वे दोष निवारण (संपूर्ण कक्षाओं को दोबारा होने से रोकने के लिए दोषों के मूल कारणों का विश्लेषण करना) और प्रौद्योगिकी परिवर्तन प्रबंधन (नई प्रौद्योगिकियों का मूल्यांकन और अपनाना) लागू करते हैं। यह स्तर 4 (प्रबंधित) से अलग है जो प्रक्रियाओं को नियंत्रित करने के लिए माप का उपयोग करता है लेकिन अभी तक उन्हें व्यवस्थित रूप से सुधार नहीं करता है।
547
EN + हिं Easy
GB What is 'software metrics' and what is Goodhart's Law's implication for metric-based management?
IN 'सॉफ़्टवेयर मेट्रिक्स' क्या है और मीट्रिक-आधारित प्रबंधन के लिए गुडहार्ट के नियम का निहितार्थ क्या है?
A
Goodhart's Law states that software metrics become more accurate with larger sample sizes गुडहार्ट का नियम कहता है कि बड़े नमूना आकार के साथ सॉफ्टवेयर मेट्रिक्स अधिक सटीक हो जाते हैं
B
Software metrics quantify attributes of software or processes; Goodhart's Law implies that once a metric becomes a management target, it ceases to be a good measure — developers optimise for the metric rather than the underlying quality it was meant to represent सॉफ़्टवेयर मेट्रिक्स सॉफ़्टवेयर या प्रक्रियाओं की विशेषताओं को मापता है; गुडहार्ट के नियम का तात्पर्य है कि एक बार जब कोई मीट्रिक एक प्रबंधन लक्ष्य बन जाता है, तो यह एक अच्छा उपाय नहीं रह जाता है - डेवलपर्स मीट्रिक के लिए अंतर्निहित गुणवत्ता के बजाय अनुकूलन करते हैं जिसका वह प्रतिनिधित्व करना चाहते थे
C
Goodhart's Law only applies to financial metrics and has no relevance to software quality metrics गुडहार्ट का नियम केवल वित्तीय मेट्रिक्स पर लागू होता है और सॉफ़्टवेयर गुणवत्ता मेट्रिक्स से इसकी कोई प्रासंगिकता नहीं है
D
Goodhart's Law supports using more metrics simultaneously to reduce gaming effects गुडहार्ट का नियम गेमिंग प्रभाव को कम करने के लिए एक साथ अधिक मेट्रिक्स का उपयोग करने का समर्थन करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Classic examples: using LOC as a productivity target → developers write verbose code. Using defect count as a quality target → developers stop filing bugs or mark them as features. Using test coverage as a quality target → developers write tests with no assertions. The metric measures a proxy for quality; once it becomes a target, people optimise the proxy while the underlying quality may deteriorate.
व्याख्या (हिन्दी) क्लासिक उदाहरण: एलओसी को उत्पादकता लक्ष्य के रूप में उपयोग करना → डेवलपर्स वर्बोज़ कोड लिखते हैं। गुणवत्ता लक्ष्य के रूप में दोष गणना का उपयोग करना → डेवलपर्स बग दर्ज करना बंद कर देते हैं या उन्हें सुविधाओं के रूप में चिह्नित करते हैं। गुणवत्ता लक्ष्य के रूप में परीक्षण कवरेज का उपयोग करना → डेवलपर्स बिना किसी दावे के परीक्षण लिखते हैं। मीट्रिक गुणवत्ता के लिए एक प्रॉक्सी मापता है; एक बार जब यह लक्ष्य बन जाता है, तो लोग प्रॉक्सी को अनुकूलित करते हैं जबकि अंतर्निहित गुणवत्ता खराब हो सकती है।
548
EN + हिं Easy
GB What is 'software dependability' and what four properties constitute it?
IN 'सॉफ़्टवेयर निर्भरता' क्या है और कौन से चार गुण इसे बनाते हैं?
A
Dependability has two properties: correctness and performance निर्भरता के दो गुण हैं: शुद्धता और प्रदर्शन
B
Software dependability is the degree to which a system can be trusted to deliver its service — constituted by: Availability (ready when needed), Reliability (correct service over time), Safety (no catastrophic consequences on failure), and Security (no unauthorised access or use) सॉफ़्टवेयर निर्भरता वह डिग्री है जिस तक किसी सिस्टम पर अपनी सेवा प्रदान करने के लिए भरोसा किया जा सकता है - इसका गठन: उपलब्धता (जरूरत पड़ने पर तैयार), विश्वसनीयता (समय के साथ सही सेवा), सुरक्षा (विफलता पर कोई विनाशकारी परिणाम नहीं), और सुरक्षा (कोई अनधिकृत पहुंच या उपयोग नहीं)
C
Dependability is synonymous with performance and is measured solely by response time निर्भरता प्रदर्शन का पर्याय है और इसे केवल प्रतिक्रिया समय से मापा जाता है
D
Dependability only applies to real-time systems; batch processing systems have no dependability requirements निर्भरता केवल वास्तविक समय प्रणालियों पर लागू होती है; बैच प्रोसेसिंग सिस्टम में निर्भरता की कोई आवश्यकता नहीं होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Sommerville's dependability framework: Availability (operational when needed — measured as uptime percentage), Reliability (correct service delivered — measured as MTTF), Safety (failure consequences bounded — critical for autonomous vehicles, medical devices), Security (integrity and privacy preserved — critical for all internet-connected systems). These four properties are often in tension and trade-offs must be explicitly managed.
व्याख्या (हिन्दी) सोमरविले की निर्भरता ढांचा: उपलब्धता (जरूरत पड़ने पर परिचालन - अपटाइम प्रतिशत के रूप में मापा जाता है), विश्वसनीयता (सही सेवा प्रदान की गई - एमटीटीएफ के रूप में मापा जाता है), सुरक्षा (विफलता के परिणाम सीमित - स्वायत्त वाहनों, चिकित्सा उपकरणों के लिए महत्वपूर्ण), सुरक्षा (अखंडता और गोपनीयता संरक्षित - सभी इंटरनेट से जुड़े सिस्टम के लिए महत्वपूर्ण)। ये चार संपत्तियां अक्सर तनाव में रहती हैं और व्यापार-बंद को स्पष्ट रूप से प्रबंधित किया जाना चाहिए।
549
EN + हिं Easy
GB What is 'formal methods' in software engineering and for what specific domain are they most justified despite their cost?
IN सॉफ्टवेयर इंजीनियरिंग में 'औपचारिक तरीके' क्या हैं और उनकी लागत के बावजूद वे किस विशिष्ट डोमेन के लिए सबसे अधिक उचित हैं?
A
Formal methods are advanced code review techniques that use multiple reviewers simultaneously औपचारिक विधियाँ उन्नत कोड समीक्षा तकनीकें हैं जो एक साथ कई समीक्षकों का उपयोग करती हैं
B
Formal methods use mathematical notation to specify and verify software properties; they are most justified for safety-critical systems (nuclear reactor control, aircraft fly-by-wire, pacemakers) where the cost of failure in human lives justifies the high upfront mathematical specification cost औपचारिक विधियाँ सॉफ़्टवेयर गुणों को निर्दिष्ट और सत्यापित करने के लिए गणितीय संकेतन का उपयोग करती हैं; वे सुरक्षा-महत्वपूर्ण प्रणालियों (परमाणु रिएक्टर नियंत्रण, विमान फ्लाई-बाय-वायर, पेसमेकर) के लिए सबसे अधिक उचित हैं, जहां मानव जीवन में विफलता की लागत उच्च अग्रिम गणितीय विनिर्देश लागत को उचित ठहराती है।
C
Formal methods are only used in academic research and have no practical industrial applications औपचारिक तरीकों का उपयोग केवल अकादमिक अनुसंधान में किया जाता है और इसका कोई व्यावहारिक औद्योगिक अनुप्रयोग नहीं होता है
D
Formal methods guarantee bug-free software when applied to any software system किसी भी सॉफ़्टवेयर सिस्टम पर लागू होने पर औपचारिक विधियाँ बग-मुक्त सॉफ़्टवेयर की गारंटी देती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Formal methods (Z, VDM, B, TLA+, Coq, Isabelle) have proven ROI in: London ambulance dispatch (safety), Amazon's TLA+ for AWS protocols, Paris metro line 14 (fully automated, formal specification verified). The Amazon case is particularly compelling: TLA+ found subtle concurrency bugs in distributed protocols that testing would likely never find, preventing outages affecting millions of users.
व्याख्या (हिन्दी) औपचारिक तरीकों (जेड, वीडीएम, बी, टीएलए+, कॉक, इसाबेल) ने आरओआई साबित किया है: लंदन एम्बुलेंस प्रेषण (सुरक्षा), एडब्ल्यूएस प्रोटोकॉल के लिए अमेज़ॅन का टीएलए+, पेरिस मेट्रो लाइन 14 (पूरी तरह से स्वचालित, औपचारिक विनिर्देश सत्यापित)। अमेज़ॅन का मामला विशेष रूप से सम्मोहक है: टीएलए+ ने वितरित प्रोटोकॉल में सूक्ष्म समवर्ती बग पाए जो परीक्षण में संभवतः कभी नहीं मिलेंगे, जिससे लाखों उपयोगकर्ताओं को प्रभावित करने वाले आउटेज को रोका जा सके।
550
EN + हिं Easy
GB What is the 'cone of uncertainty' and how should project managers use it during planning?
IN 'अनिश्चितता का शंकु' क्या है और परियोजना प्रबंधकों को योजना के दौरान इसका उपयोग कैसे करना चाहिए?
A
The cone describes how project costs increase as the team grows larger over time शंकु बताता है कि जैसे-जैसे टीम समय के साथ बड़ी होती जाती है, परियोजना की लागत कैसे बढ़ती है
B
The cone shows that early project estimates have inherent uncertainty ranges of 4x — managers should express early estimates as ranges (not single values), track how the range narrows as design proceeds, and avoid making firm commitments before the range has narrowed sufficiently शंकु से पता चलता है कि प्रारंभिक परियोजना अनुमानों में 4x की अंतर्निहित अनिश्चितता सीमाएँ हैं - प्रबंधकों को प्रारंभिक अनुमानों को सीमाओं (एकल मान नहीं) के रूप में व्यक्त करना चाहिए, ट्रैक करें कि डिज़ाइन के आगे बढ़ने पर सीमा कैसे संकीर्ण होती है, और सीमा पर्याप्त रूप से संकीर्ण होने से पहले दृढ़ प्रतिबद्धता बनाने से बचें।
C
The cone of uncertainty only applies to time estimation; cost estimates are always precise from project start अनिश्चितता का शंकु केवल समय अनुमान पर लागू होता है; परियोजना की शुरुआत से लागत अनुमान हमेशा सटीक होते हैं
D
The cone proves that Agile estimation is always more accurate than plan-driven estimation शंकु साबित करता है कि एजाइल अनुमान हमेशा योजना-संचालित अनुमान से अधिक सटीक होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Steve McConnell (Software Estimation) documented the cone: at project inception, estimates can be off by 4x in either direction (0.25x to 4x). At architecture complete, 1.5x-0.7x. At design complete, 1.25x-0.85x. Giving a single-point estimate at inception is dishonest — it implies false precision. Communicating ranges and widths teaches stakeholders about inherent uncertainty and prevents premature commitment to impossible schedules.
व्याख्या (हिन्दी) स्टीव मैककोनेल (सॉफ्टवेयर अनुमान) ने शंकु का दस्तावेजीकरण किया: परियोजना की शुरुआत में, अनुमान किसी भी दिशा में 4x तक कम हो सकते हैं (0.25x से 4x)। आर्किटेक्चर पूर्ण होने पर, 1.5x-0.7x। डिज़ाइन पूर्ण होने पर, 1.25x-0.85x। शुरुआत में एकल-बिंदु अनुमान देना बेईमानी है - इसका तात्पर्य झूठी सटीकता है। सीमाओं और चौड़ाई का संचार हितधारकों को अंतर्निहित अनिश्चितता के बारे में सिखाता है और असंभव कार्यक्रमों के प्रति समय से पहले प्रतिबद्धता को रोकता है।
551
EN + हिं Easy
GB What is 'software ergonomics' and what cognitive principles govern effective human-computer interface design?
IN 'सॉफ़्टवेयर एर्गोनॉमिक्स' क्या है और कौन से संज्ञानात्मक सिद्धांत प्रभावी मानव-कंप्यूटर इंटरफ़ेस डिज़ाइन को नियंत्रित करते हैं?
A
Software ergonomics only refers to physical hardware positioning to prevent repetitive strain injuries सॉफ़्टवेयर एर्गोनॉमिक्स केवल दोहराए जाने वाले तनाव की चोटों को रोकने के लिए भौतिक हार्डवेयर स्थिति को संदर्भित करता है
B
Software ergonomics (HCI) studies how humans interact with software systems; governing principles: recognition over recall (show options rather than requiring memory), feedback (acknowledge every action), error prevention over recovery, consistency, and user control and freedom सॉफ़्टवेयर एर्गोनॉमिक्स (HCI) अध्ययन करता है कि मनुष्य सॉफ़्टवेयर सिस्टम के साथ कैसे इंटरैक्ट करते हैं; शासी सिद्धांत: रिकॉल पर मान्यता (मेमोरी की आवश्यकता के बजाय विकल्प दिखाएं), फीडबैक (हर कार्रवाई को स्वीकार करें), पुनर्प्राप्ति पर त्रुटि की रोकथाम, स्थिरता, और उपयोगकर्ता नियंत्रण और स्वतंत्रता
C
Software ergonomics requires that all interfaces be accessible to users with disabilities only सॉफ़्टवेयर एर्गोनॉमिक्स के लिए आवश्यक है कि सभी इंटरफ़ेस केवल विकलांग उपयोगकर्ताओं के लिए ही सुलभ हों
D
Software ergonomics is only relevant for touch-screen mobile applications, not desktop software सॉफ़्टवेयर एर्गोनॉमिक्स केवल टच-स्क्रीन मोबाइल एप्लिकेशन के लिए प्रासंगिक है, डेस्कटॉप सॉफ़्टवेयर के लिए नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Nielsen's 10 usability heuristics operationalise these principles. Recognition over recall: dropdown menus vs command-line interfaces — users recognise options rather than memorising commands. Feedback: a loading spinner acknowledges the system received the click. Error prevention: 'Are you sure you want to delete?' prevents irreversible errors. These principles, grounded in cognitive psychology research, predict and explain UI effectiveness.
व्याख्या (हिन्दी) नीलसन की 10 प्रयोज्यता अनुमान इन सिद्धांतों को संचालित करते हैं। रिकॉल पर पहचान: ड्रॉपडाउन मेनू बनाम कमांड-लाइन इंटरफेस - उपयोगकर्ता कमांड को याद रखने के बजाय विकल्पों को पहचानते हैं। प्रतिक्रिया: एक लोडिंग स्पिनर स्वीकार करता है कि सिस्टम को क्लिक प्राप्त हुआ है। त्रुटि निवारण: 'क्या आप वाकई हटाना चाहते हैं?' अपरिवर्तनीय त्रुटियों को रोकता है। संज्ञानात्मक मनोविज्ञान अनुसंधान पर आधारित ये सिद्धांत, यूआई प्रभावशीलता की भविष्यवाणी और व्याख्या करते हैं।
552
EN + हिं Easy
GB What is 'Conway's Law' and what does it imply for software architecture team organisation?
IN 'कॉनवे का नियम' क्या है और सॉफ्टवेयर आर्किटेक्चर टीम संगठन के लिए इसका क्या अर्थ है?
A
Conway's Law states that software complexity grows proportionally with team size कॉनवे का नियम कहता है कि सॉफ़्टवेयर जटिलता टीम के आकार के साथ आनुपातिक रूप से बढ़ती है
B
Conway's Law: organisations design systems that mirror their communication structures — it implies that to get the architecture you want, you must first structure your teams to mirror that architecture (the 'inverse Conway manoeuvre') कॉनवे का नियम: संगठन ऐसी प्रणालियाँ डिज़ाइन करते हैं जो उनकी संचार संरचनाओं को प्रतिबिंबित करती हैं - इसका तात्पर्य यह है कि जिस वास्तुकला को आप चाहते हैं उसे प्राप्त करने के लिए, आपको पहले अपनी टीमों को उस वास्तुकला को प्रतिबिंबित करने के लिए तैयार करना होगा ('उलटा कॉनवे पैंतरेबाज़ी')
C
Conway's Law proves that large teams always produce better software than small teams कॉनवे का नियम साबित करता है कि बड़ी टीमें हमेशा छोटी टीमों की तुलना में बेहतर सॉफ्टवेयर तैयार करती हैं
D
Conway's Law only applies to distributed teams across multiple time zones कॉनवे का नियम केवल कई समय क्षेत्रों में वितरित टीमों पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Melvin Conway (1967): 'Organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations.' Microsoft Windows' architectural boundaries historically followed Microsoft's organisational boundaries. The inverse Conway manoeuvre (Team Topologies, Skelton & Pais): design teams to match the desired architecture — a microservices target architecture requires stream-aligned teams that own services end-to-end, not functional silos (DBA team, network team).
व्याख्या (हिन्दी) मेल्विन कॉनवे (1967): 'जो संगठन सिस्टम डिज़ाइन करते हैं वे ऐसे डिज़ाइन तैयार करने के लिए बाध्य होते हैं जो उन संगठनों की संचार संरचनाओं की प्रतियां होते हैं।' Microsoft Windows की वास्तुशिल्प सीमाएँ ऐतिहासिक रूप से Microsoft की संगठनात्मक सीमाओं का अनुसरण करती थीं। व्युत्क्रम कॉनवे पैंतरेबाज़ी (टीम टोपोलॉजीज़, स्केल्टन और पेस): वांछित वास्तुकला से मेल खाने के लिए टीमों को डिज़ाइन करें - एक माइक्रोसर्विसेज लक्ष्य वास्तुकला के लिए स्ट्रीम-संरेखित टीमों की आवश्यकता होती है जो अंत-से-अंत तक सेवाओं की मालिक होती हैं, कार्यात्मक साइलो (डीबीए टीम, नेटवर्क टीम) की नहीं।
553
EN + हिं Easy
GB What is 'FURPS+' in software requirements engineering and what does each letter represent?
IN सॉफ़्टवेयर आवश्यकताएँ इंजीनियरिंग में 'FURPS+' क्या है और प्रत्येक अक्षर क्या दर्शाता है?
A
FURPS+ is a formal UML diagram notation standard FURPS+ एक औपचारिक यूएमएल आरेख संकेतन मानक है
B
FURPS+ (Grady, HP) is a quality model: Functionality (features, capabilities), Usability (human factors, aesthetics), Reliability (frequency of failure, recoverability), Performance (speed, throughput, memory), Supportability (maintainability, testability); + adds constraints (design, implementation, interface, physical) FURPS+ (ग्रैडी, एचपी) एक गुणवत्ता मॉडल है: कार्यक्षमता (विशेषताएं, क्षमताएं), प्रयोज्यता (मानवीय कारक, सौंदर्यशास्त्र), विश्वसनीयता (विफलता की आवृत्ति, पुनर्प्राप्ति), प्रदर्शन (गति, थ्रूपुट, मेमोरी), समर्थनशीलता (रखरखाव, परीक्षणशीलता); + बाधाएँ जोड़ता है (डिज़ाइन, कार्यान्वयन, इंटरफ़ेस, भौतिक)
C
FURPS+ is a software testing framework specifying five mandatory test types FURPS+ एक सॉफ्टवेयर परीक्षण ढांचा है जो पांच अनिवार्य परीक्षण प्रकारों को निर्दिष्ट करता है
D
FURPS+ only applies to hardware-software co-design projects with physical components FURPS+ केवल भौतिक घटकों के साथ हार्डवेयर-सॉफ़्टवेयर सह-डिज़ाइन परियोजनाओं पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) FURPS+ provides a checklist ensuring all quality dimensions are considered during requirements. It prevents common omissions: teams focus on Functionality and forget Supportability (how will this be maintained?). The '+' constraints are often forgotten: physical constraints (must fit in 512KB ROM), interface constraints (must integrate with SAP), and implementation constraints (must use only MISRA-C compliant code).
व्याख्या (हिन्दी) FURPS+ यह सुनिश्चित करने के लिए एक चेकलिस्ट प्रदान करता है कि आवश्यकताओं के दौरान सभी गुणवत्ता आयामों पर विचार किया जाता है। यह सामान्य चूक को रोकता है: टीमें कार्यक्षमता पर ध्यान केंद्रित करती हैं और सपोर्टेबिलिटी को भूल जाती हैं (इसे कैसे बनाए रखा जाएगा?)। '+' बाधाएं अक्सर भूल जाती हैं: भौतिक बाधाएं (512KB ROM में फिट होनी चाहिए), इंटरफ़ेस बाधाएं (SAP के साथ एकीकृत होनी चाहिए), और कार्यान्वयन बाधाएं (केवल MISRA-C अनुरूप कोड का उपयोग करना चाहिए)।
554
EN + हिं Easy
GB What is 'software product quality model' per ISO/IEC 25010 and what two main perspectives does it address?
IN ISO/IEC 25010 के अनुसार 'सॉफ़्टवेयर उत्पाद गुणवत्ता मॉडल' क्या है और यह किन दो मुख्य दृष्टिकोणों को संबोधित करता है?
A
ISO 25010 addresses only internal code quality metrics visible to developers ISO 25010 केवल डेवलपर्स को दिखाई देने वाले आंतरिक कोड गुणवत्ता मेट्रिक्स को संबोधित करता है
B
ISO/IEC 25010 addresses product quality from two perspectives: quality in use (effectiveness, efficiency, satisfaction, freedom from risk, context coverage — how well users achieve goals) and product quality (functional suitability, reliability, performance efficiency, usability, security, maintainability, portability, compatibility) ISO/IEC 25010 उत्पाद की गुणवत्ता को दो दृष्टिकोणों से संबोधित करता है: उपयोग में गुणवत्ता (प्रभावशीलता, दक्षता, संतुष्टि, जोखिम से मुक्ति, संदर्भ कवरेज - उपयोगकर्ता कितनी अच्छी तरह लक्ष्य प्राप्त करते हैं) और उत्पाद की गुणवत्ता (कार्यात्मक उपयुक्तता, विश्वसनीयता, प्रदर्शन दक्षता, प्रयोज्यता, सुरक्षा, रखरखाव, पोर्टेबिलिटी, अनुकूलता)
C
ISO 25010 only applies to web applications and cloud-based software products ISO 25010 केवल वेब एप्लिकेशन और क्लाउड-आधारित सॉफ़्टवेयर उत्पादों पर लागू होता है
D
ISO 25010 replaces all other quality models and is the only internationally recognised standard ISO 25010 अन्य सभी गुणवत्ता मॉडलों को प्रतिस्थापित करता है और यह एकमात्र अंतरराष्ट्रीय स्तर पर मान्यता प्राप्त मानक है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) ISO/IEC 25010 (replacing 9126) is important because it separates the system's quality properties from the user's experience. A system may have excellent internal maintainability (product quality) but poor usability in context (quality in use) — both dimensions matter. The two-model approach ensures quality is evaluated from both technical and user-centric perspectives.
व्याख्या (हिन्दी) आईएसओ/आईईसी 25010 (9126 की जगह) महत्वपूर्ण है क्योंकि यह सिस्टम की गुणवत्ता गुणों को उपयोगकर्ता के अनुभव से अलग करता है। एक प्रणाली में उत्कृष्ट आंतरिक रखरखाव (उत्पाद की गुणवत्ता) हो सकती है, लेकिन संदर्भ में खराब उपयोगिता (उपयोग में गुणवत्ता) - दोनों आयाम मायने रखते हैं। दो-मॉडल दृष्टिकोण यह सुनिश्चित करता है कि गुणवत्ता का मूल्यांकन तकनीकी और उपयोगकर्ता-केंद्रित दोनों दृष्टिकोणों से किया जाए।
555
EN + हिं Medium
GB What is the 'software crisis' of the 1960s origin and how does it relate to structured programming?
IN 1960 के दशक का 'सॉफ़्टवेयर संकट' क्या है और यह संरचित प्रोग्रामिंग से कैसे संबंधित है?
A
The software crisis was caused by hardware being too slow to run software efficiently सॉफ़्टवेयर संकट सॉफ़्टवेयर को कुशलतापूर्वक चलाने के लिए हार्डवेयर के बहुत धीमा होने के कारण हुआ था
B
The software crisis arose from unmanageable complexity in large programs built with unrestricted GOTO statements — structured programming (Dijkstra, Böhm-Jacopini) directly responded by restricting control flow to sequence, selection, and iteration, making programs provably analysable सॉफ़्टवेयर संकट अप्रतिबंधित GOTO कथनों के साथ निर्मित बड़े कार्यक्रमों में असहनीय जटिलता से उत्पन्न हुआ - संरचित प्रोग्रामिंग (डिज्क्स्ट्रा, बोहम-जैकोपिनी) ने नियंत्रण प्रवाह को अनुक्रम, चयन और पुनरावृत्ति तक सीमित करके सीधे प्रतिक्रिया दी, जिससे प्रोग्रामों को विश्लेषण योग्य बना दिया गया।
C
Structured programming was invented before the software crisis as a teaching technique शिक्षण तकनीक के रूप में संरचित प्रोग्रामिंग का आविष्कार सॉफ्टवेयर संकट से पहले किया गया था
D
The software crisis was resolved by increasing computer memory, not by programming methodologies सॉफ़्टवेयर संकट का समाधान प्रोग्रामिंग पद्धतियों से नहीं, बल्कि कंप्यूटर मेमोरी बढ़ाकर किया गया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dijkstra's 1968 'Go To Statement Considered Harmful' letter was a direct response to the software crisis. Programs with arbitrary GOTOs produced spaghetti code impossible to reason about or test systematically. The Böhm-Jacopini theorem proved any computable function can be written with only sequence, selection (if-then-else), and iteration (while) — eliminating the need for GOTO and enabling systematic program verification.
व्याख्या (हिन्दी) डिज्क्स्ट्रा का 1968 का 'हानिकारक माने जाने वाले बयान पर जाएं' पत्र सॉफ्टवेयर संकट का सीधा जवाब था। मनमाने ढंग से GOTOs वाले प्रोग्राम ने स्पेगेटी कोड का उत्पादन किया जिसके बारे में तर्क करना या व्यवस्थित रूप से परीक्षण करना असंभव है। बोहम-जैकोपिनी प्रमेय ने साबित कर दिया कि किसी भी गणना योग्य फ़ंक्शन को केवल अनुक्रम, चयन (यदि-तब-अन्यथा), और पुनरावृत्ति (जबकि) के साथ लिखा जा सकता है - GOTO की आवश्यकता को समाप्त करना और व्यवस्थित कार्यक्रम सत्यापन को सक्षम करना।
541–555 of 647