2611

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 (प्रबंधित) से अलग है जो प्रक्रियाओं को नियंत्रित करने के लिए माप का उपयोग करता है लेकिन अभी तक उन्हें व्यवस्थित रूप से सुधार नहीं करता है।

2612

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.

व्याख्या (हिन्दी) क्लासिक उदाहरण: एलओसी को उत्पादकता लक्ष्य के रूप में उपयोग करना → डेवलपर्स वर्बोज़ कोड लिखते हैं। गुणवत्ता लक्ष्य के रूप में दोष गणना का उपयोग करना → डेवलपर्स बग दर्ज करना बंद कर देते हैं या उन्हें सुविधाओं के रूप में चिह्नित करते हैं। गुणवत्ता लक्ष्य के रूप में परीक्षण कवरेज का उपयोग करना → डेवलपर्स बिना किसी दावे के परीक्षण लिखते हैं। मीट्रिक गुणवत्ता के लिए एक प्रॉक्सी मापता है; एक बार जब यह लक्ष्य बन जाता है, तो लोग प्रॉक्सी को अनुकूलित करते हैं जबकि अंतर्निहित गुणवत्ता खराब हो सकती है।

2613

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.

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

2614

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 (पूरी तरह से स्वचालित, औपचारिक विनिर्देश सत्यापित)। अमेज़ॅन का मामला विशेष रूप से सम्मोहक है: टीएलए+ ने वितरित प्रोटोकॉल में सूक्ष्म समवर्ती बग पाए जो परीक्षण में संभवतः कभी नहीं मिलेंगे, जिससे लाखों उपयोगकर्ताओं को प्रभावित करने वाले आउटेज को रोका जा सके।

2615

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। शुरुआत में एकल-बिंदु अनुमान देना बेईमानी है - इसका तात्पर्य झूठी सटीकता है। सीमाओं और चौड़ाई का संचार हितधारकों को अंतर्निहित अनिश्चितता के बारे में सिखाता है और असंभव कार्यक्रमों के प्रति समय से पहले प्रतिबद्धता को रोकता है।

2616

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 प्रयोज्यता अनुमान इन सिद्धांतों को संचालित करते हैं। रिकॉल पर पहचान: ड्रॉपडाउन मेनू बनाम कमांड-लाइन इंटरफेस - उपयोगकर्ता कमांड को याद रखने के बजाय विकल्पों को पहचानते हैं। प्रतिक्रिया: एक लोडिंग स्पिनर स्वीकार करता है कि सिस्टम को क्लिक प्राप्त हुआ है। त्रुटि निवारण: 'क्या आप वाकई हटाना चाहते हैं?' अपरिवर्तनीय त्रुटियों को रोकता है। संज्ञानात्मक मनोविज्ञान अनुसंधान पर आधारित ये सिद्धांत, यूआई प्रभावशीलता की भविष्यवाणी और व्याख्या करते हैं।

2617

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 की संगठनात्मक सीमाओं का अनुसरण करती थीं। व्युत्क्रम कॉनवे पैंतरेबाज़ी (टीम टोपोलॉजीज़, स्केल्टन और पेस): वांछित वास्तुकला से मेल खाने के लिए टीमों को डिज़ाइन करें - एक माइक्रोसर्विसेज लक्ष्य वास्तुकला के लिए स्ट्रीम-संरेखित टीमों की आवश्यकता होती है जो अंत-से-अंत तक सेवाओं की मालिक होती हैं, कार्यात्मक साइलो (डीबीए टीम, नेटवर्क टीम) की नहीं।

2618

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 अनुरूप कोड का उपयोग करना चाहिए)।

2619

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 की जगह) महत्वपूर्ण है क्योंकि यह सिस्टम की गुणवत्ता गुणों को उपयोगकर्ता के अनुभव से अलग करता है। एक प्रणाली में उत्कृष्ट आंतरिक रखरखाव (उत्पाद की गुणवत्ता) हो सकती है, लेकिन संदर्भ में खराब उपयोगिता (उपयोग में गुणवत्ता) - दोनों आयाम मायने रखते हैं। दो-मॉडल दृष्टिकोण यह सुनिश्चित करता है कि गुणवत्ता का मूल्यांकन तकनीकी और उपयोगकर्ता-केंद्रित दोनों दृष्टिकोणों से किया जाए।

2620

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 की आवश्यकता को समाप्त करना और व्यवस्थित कार्यक्रम सत्यापन को सक्षम करना।

2621

EN + हिं Easy

GB What is 'software reuse' and what three levels at which it can be practised?

IN 'सॉफ़्टवेयर पुन: उपयोग' क्या है और किन तीन स्तरों पर इसका अभ्यास किया जा सकता है?

A

Software reuse only refers to copying code from Stack Overflow into projects सॉफ़्टवेयर का पुन: उपयोग केवल स्टैक ओवरफ़्लो से प्रोजेक्ट में कोड कॉपी करने को संदर्भित करता है

B

Software reuse leverages existing software artefacts to build new systems — practised at three levels: component level (reusing libraries/APIs), architectural level (reusing patterns and frameworks), and product line level (systematic reuse of a family of systems' shared assets) सॉफ़्टवेयर का पुन: उपयोग नए सिस्टम बनाने के लिए मौजूदा सॉफ़्टवेयर कलाकृतियों का लाभ उठाता है - तीन स्तरों पर अभ्यास किया जाता है: घटक स्तर (लाइब्रेरी/एपीआई का पुन: उपयोग), वास्तुशिल्प स्तर (पैटर्न और फ्रेमवर्क का पुन: उपयोग), और उत्पाद लाइन स्तर (सिस्टम की साझा संपत्तियों के परिवार का व्यवस्थित पुन: उपयोग)

C

Software reuse is only possible when both systems use the same programming language सॉफ़्टवेयर का पुन: उपयोग तभी संभव है जब दोनों प्रणालियाँ समान प्रोग्रामिंग भाषा का उपयोग करें

D

Software reuse always introduces security risks and should be avoided in production systems सॉफ़्टवेयर का पुन: उपयोग हमेशा सुरक्षा जोखिम उत्पन्न करता है और उत्पादन प्रणालियों में इससे बचना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Reuse levels have different ROI profiles: component reuse (npm packages, Maven JARs) — immediate, cheap, but limited to available functionality; architectural reuse (Spring, Django, Rails) — framework controls flow, developer fills in domain logic; product line reuse — highest investment, highest return for families of related products (Bosch power tool firmware, Philips medical devices).

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

2622

EN + हिं Easy

GB What is 'software process maturity' and why do immature processes produce unpredictable outcomes even with skilled developers?

IN 'सॉफ़्टवेयर प्रक्रिया परिपक्वता' क्या है और अपरिपक्व प्रक्रियाएँ कुशल डेवलपर्स के साथ भी अप्रत्याशित परिणाम क्यों उत्पन्न करती हैं?

A

Immature processes produce unpredictable outcomes because they rely on outdated programming languages अपरिपक्व प्रक्रियाएं अप्रत्याशित परिणाम उत्पन्न करती हैं क्योंकि वे पुरानी प्रोग्रामिंग भाषाओं पर निर्भर होती हैं

B

Immature processes are ad-hoc and person-dependent — outcomes depend entirely on individual heroics rather than systematic practices; when key people leave or are unavailable, the process breaks down, creating unpredictable results even with competent individual developers अपरिपक्व प्रक्रियाएं तदर्थ और व्यक्ति-निर्भर होती हैं - परिणाम व्यवस्थित प्रथाओं के बजाय पूरी तरह से व्यक्तिगत वीरता पर निर्भर होते हैं; जब प्रमुख लोग चले जाते हैं या अनुपलब्ध होते हैं, तो प्रक्रिया टूट जाती है, जिससे सक्षम व्यक्तिगत डेवलपर्स के साथ भी अप्रत्याशित परिणाम उत्पन्न होते हैं

C

Immature processes only affect large projects; small projects with skilled developers always succeed अपरिपक्व प्रक्रियाएँ केवल बड़ी परियोजनाओं को प्रभावित करती हैं; कुशल डेवलपर्स के साथ छोटी परियोजनाएँ हमेशा सफल होती हैं

D

Process maturity is irrelevant if all developers hold advanced computer science degrees यदि सभी डेवलपर्स के पास उन्नत कंप्यूटर विज्ञान की डिग्री है तो प्रक्रिया परिपक्वता अप्रासंगिक है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) CMM's insight: outcome quality should be a property of the process, not dependent on specific individuals. An immature organisation might deliver excellent projects when hero developers are present and fail when they're absent — there's no repeatable mechanism. A mature process delivers consistent results regardless of which competent individual executes it. This is why CMM improvement is fundamentally about institutionalising good practices.

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

2623

EN + हिं Medium

GB What is the difference between 'product quality' and 'process quality' in software engineering?

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

A

Product quality and process quality always correlate perfectly — good process always produces good products उत्पाद की गुणवत्ता और प्रक्रिया की गुणवत्ता हमेशा पूरी तरह से संबंधित होती है - अच्छी प्रक्रिया हमेशा अच्छे उत्पाद बनाती है

B

Product quality measures attributes of the delivered software (correctness, reliability, usability); process quality measures how well the development process is executed (adherence to standards, predictability, defect removal efficiency) — high process quality tends to yield high product quality but is not guaranteed उत्पाद की गुणवत्ता वितरित सॉफ़्टवेयर की विशेषताओं (शुद्धता, विश्वसनीयता, प्रयोज्यता) को मापती है; प्रक्रिया गुणवत्ता मापती है कि विकास प्रक्रिया कितनी अच्छी तरह निष्पादित की गई है (मानकों का पालन, पूर्वानुमेयता, दोष हटाने की दक्षता) - उच्च प्रक्रिया गुणवत्ता उच्च उत्पाद गुणवत्ता प्रदान करती है लेकिन इसकी गारंटी नहीं है

C

Process quality is more important than product quality in all software engineering contexts सभी सॉफ्टवेयर इंजीनियरिंग संदर्भों में उत्पाद की गुणवत्ता की तुलना में प्रक्रिया की गुणवत्ता अधिक महत्वपूर्ण है

D

Product quality is only measurable after deployment; process quality is only measurable during development उत्पाद की गुणवत्ता केवल तैनाती के बाद ही मापी जा सकती है; प्रक्रिया की गुणवत्ता केवल विकास के दौरान मापी जा सकती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The relationship is probabilistic, not deterministic: a good process increases the probability of good products. However, a well-executed bad design can produce a poor product. Conversely, exceptional individual talent can produce good products from a poor process — temporarily. Long-term consistency requires process quality as the foundation, with product quality metrics providing feedback on whether process improvements are working.

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

2624

EN + हिं Easy

GB What is the 'ISO/IEC 12207' standard and what lifecycle framework does it define?

IN 'आईएसओ/आईईसी 12207' मानक क्या है और यह किस जीवनचक्र ढांचे को परिभाषित करता है?

A

ISO 12207 defines the programming language standard for software developed in safety-critical domains ISO 12207 सुरक्षा-महत्वपूर्ण डोमेन में विकसित सॉफ़्टवेयर के लिए प्रोग्रामिंग भाषा मानक को परिभाषित करता है

B

ISO/IEC 12207 defines a comprehensive set of software lifecycle processes (acquisition, supply, development, operation, maintenance, support, organisational) providing a common framework for organisations to specify and implement software processes आईएसओ/आईईसी 12207 सॉफ्टवेयर जीवनचक्र प्रक्रियाओं (अधिग्रहण, आपूर्ति, विकास, संचालन, रखरखाव, समर्थन, संगठनात्मक) के एक व्यापक सेट को परिभाषित करता है जो संगठनों को सॉफ्टवेयर प्रक्रियाओं को निर्दिष्ट और कार्यान्वित करने के लिए एक सामान्य ढांचा प्रदान करता है।

C

ISO 12207 is identical to CMMI and both standards are maintained by the same organisation आईएसओ 12207 सीएमएमआई के समान है और दोनों मानकों का रखरखाव एक ही संगठन द्वारा किया जाता है

D

ISO 12207 only applies to government defence contracts; commercial software is exempt आईएसओ 12207 केवल सरकारी रक्षा अनुबंधों पर लागू होता है; व्यावसायिक सॉफ़्टवेयर को छूट है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) ISO/IEC 12207 (first published 1995, updated 2017 as ISO/IEC/IEEE 12207) is the international standard for software lifecycle processes. It defines what processes exist, what activities each contains, and the relationships between them — without mandating how they are implemented. Organisations use it as a reference to check their process coverage and as a common vocabulary for contracts between acquirers and suppliers.

व्याख्या (हिन्दी) आईएसओ/आईईसी 12207 (पहली बार 1995 में प्रकाशित, 2017 को आईएसओ/आईईसी/आईईईई 12207 के रूप में अद्यतन) सॉफ्टवेयर जीवनचक्र प्रक्रियाओं के लिए अंतरराष्ट्रीय मानक है। यह परिभाषित करता है कि कौन सी प्रक्रियाएँ मौजूद हैं, प्रत्येक में कौन सी गतिविधियाँ शामिल हैं, और उनके बीच संबंध हैं - बिना यह बताए कि उन्हें कैसे कार्यान्वित किया जाता है। संगठन इसे अपनी प्रक्रिया कवरेज की जांच करने के लिए एक संदर्भ के रूप में और अधिग्रहणकर्ताओं और आपूर्तिकर्ताओं के बीच अनुबंधों के लिए एक सामान्य शब्दावली के रूप में उपयोग करते हैं।

2625

EN + हिं Medium

GB What is 'fault tolerance' in software and what is the difference between 'fail-safe' and 'fail-secure' designs?

IN सॉफ़्टवेयर में 'दोष सहनशीलता' क्या है और 'असफल-सुरक्षित' और 'असफल-सुरक्षित' डिज़ाइन के बीच क्या अंतर है?

A

Fault tolerance means the software has no bugs and can therefore never fail दोष सहनशीलता का अर्थ है कि सॉफ़्टवेयर में कोई बग नहीं है और इसलिए वह कभी विफल नहीं हो सकता

B

Fault tolerance continues operation despite faults; fail-safe defaults to a safe state on failure (fire door opens when power fails — safe for occupants); fail-secure defaults to a secure state on failure (electronic lock locks when power fails — secure against intruders) — these may conflict in some systems दोषों के बावजूद दोष सहनशीलता का संचालन जारी रहता है; विफलता पर सुरक्षित स्थिति में विफल-सुरक्षित डिफ़ॉल्ट (बिजली विफल होने पर अग्नि द्वार खुलता है - रहने वालों के लिए सुरक्षित); विफलता पर सुरक्षित स्थिति में विफल-सुरक्षित डिफ़ॉल्ट (बिजली विफल होने पर इलेक्ट्रॉनिक लॉक लॉक हो जाता है - घुसपैठियों के खिलाफ सुरक्षित) - ये कुछ प्रणालियों में संघर्ष कर सकते हैं

C

Fail-safe and fail-secure are synonymous terms describing the same design pattern फेल-सेफ और फेल-सिक्योर समान डिजाइन पैटर्न का वर्णन करने वाले पर्यायवाची शब्द हैं

D

Fault tolerance only applies to hardware systems; software either works or fails completely दोष सहनशीलता केवल हार्डवेयर सिस्टम पर लागू होती है; सॉफ़्टवेयर या तो काम करता है या पूरी तरह से विफल हो जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The fail-safe vs fail-secure conflict: a security door's electronic lock failing open (fail-safe, so people aren't trapped) vs failing locked (fail-secure, so intruders can't enter). Neither is universally correct — it depends on which failure consequence is worse. Hospital systems have this tension: fail-safe might release locked medications during power failure (safe for patients who need them); fail-secure would keep them locked (prevents theft but may endanger patients).

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

Software Engineering — MCQ Practice