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
556
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, रेल्स) - फ्रेमवर्क प्रवाह को नियंत्रित करता है, डेवलपर डोमेन तर्क भरता है; उत्पाद श्रृंखला का पुन: उपयोग - उच्चतम निवेश, संबंधित उत्पादों के परिवारों के लिए उच्चतम रिटर्न (बॉश पावर टूल फ़र्मवेयर, फिलिप्स मेडिकल डिवाइस)।
557
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.
व्याख्या (हिन्दी) सीएमएम की अंतर्दृष्टि: परिणाम की गुणवत्ता प्रक्रिया की संपत्ति होनी चाहिए, न कि विशिष्ट व्यक्तियों पर निर्भर। एक अपरिपक्व संगठन उत्कृष्ट परियोजनाएं दे सकता है जब हीरो डेवलपर्स मौजूद हों और जब वे अनुपस्थित हों तो विफल हो जाएं - कोई दोहराने योग्य तंत्र नहीं है। एक परिपक्व प्रक्रिया लगातार परिणाम देती है, भले ही कोई भी सक्षम व्यक्ति इसे क्रियान्वित करता हो। यही कारण है कि सीएमएम सुधार मूल रूप से अच्छी प्रथाओं को संस्थागत बनाने के बारे में है।
558
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.
व्याख्या (हिन्दी) संबंध संभाव्य है, नियतिवादी नहीं: एक अच्छी प्रक्रिया अच्छे उत्पादों की संभावना बढ़ाती है। हालाँकि, एक अच्छी तरह से निष्पादित ख़राब डिज़ाइन ख़राब उत्पाद का उत्पादन कर सकता है। इसके विपरीत, असाधारण व्यक्तिगत प्रतिभा एक खराब प्रक्रिया से अस्थायी रूप से अच्छे उत्पाद तैयार कर सकती है। दीर्घकालिक स्थिरता के लिए नींव के रूप में प्रक्रिया की गुणवत्ता की आवश्यकता होती है, उत्पाद गुणवत्ता मेट्रिक्स इस पर प्रतिक्रिया प्रदान करते हैं कि प्रक्रिया में सुधार काम कर रहे हैं या नहीं।
559
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 के रूप में अद्यतन) सॉफ्टवेयर जीवनचक्र प्रक्रियाओं के लिए अंतरराष्ट्रीय मानक है। यह परिभाषित करता है कि कौन सी प्रक्रियाएँ मौजूद हैं, प्रत्येक में कौन सी गतिविधियाँ शामिल हैं, और उनके बीच संबंध हैं - बिना यह बताए कि उन्हें कैसे कार्यान्वित किया जाता है। संगठन इसे अपनी प्रक्रिया कवरेज की जांच करने के लिए एक संदर्भ के रूप में और अधिग्रहणकर्ताओं और आपूर्तिकर्ताओं के बीच अनुबंधों के लिए एक सामान्य शब्दावली के रूप में उपयोग करते हैं।
560
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).
व्याख्या (हिन्दी) असफल-सुरक्षित बनाम असफल-सुरक्षित संघर्ष: एक सुरक्षा द्वार का इलेक्ट्रॉनिक लॉक विफल हो रहा है (असफल-सुरक्षित, ताकि लोग फंस न जाएं) बनाम असफल लॉक (असफल-सुरक्षित, ताकि घुसपैठिए प्रवेश न कर सकें)। इनमें से कोई भी सार्वभौमिक रूप से सही नहीं है - यह इस पर निर्भर करता है कि किस विफलता का परिणाम बदतर है। अस्पताल प्रणालियों में यह तनाव है: फेल-सेफ बिजली की विफलता के दौरान बंद दवाओं को जारी कर सकता है (उन रोगियों के लिए सुरक्षित जिन्हें उनकी आवश्यकता है); फेल-सिक्योर उन्हें लॉक रखेगा (चोरी को रोकता है लेकिन मरीजों को खतरे में डाल सकता है)।
561
EN + हिं Easy
GB What is 'software architecture documentation' and what does the 4+1 view model address?
IN 'सॉफ़्टवेयर आर्किटेक्चर दस्तावेज़ीकरण' क्या है और 4+1 व्यू मॉडल का पता क्या है?
A
4+1 view model creates four backup copies of the architecture document plus one master copy 4+1 व्यू मॉडल आर्किटेक्चर दस्तावेज़ की चार बैकअप प्रतियां और एक मास्टर कॉपी बनाता है
B
Kruchten's 4+1 view model documents architecture from five stakeholder perspectives: Logical (classes, components), Process (concurrency, threads), Development (source organisation, build), Physical (deployment, servers), + Use cases (scenarios tying the four views together) क्रुचटेन का 4+1 दृश्य मॉडल पांच हितधारक दृष्टिकोणों से वास्तुकला का दस्तावेजीकरण करता है: तार्किक (वर्ग, घटक), प्रक्रिया (समवर्ती, धागे), विकास (स्रोत संगठन, निर्माण), भौतिक (तैनाती, सर्वर), + उपयोग के मामले (चार विचारों को एक साथ जोड़ने वाले परिदृश्य)
C
4+1 model is only used for documenting database schemas, not software architecture 4+1 मॉडल का उपयोग केवल डेटाबेस स्कीमा के दस्तावेज़ीकरण के लिए किया जाता है, सॉफ़्टवेयर आर्किटेक्चर के लिए नहीं
D
4+1 view model requires all five views to be simultaneously maintained at the same level of detail 4+1 दृश्य मॉडल के लिए सभी पांच दृश्यों को एक साथ विवरण के समान स्तर पर बनाए रखने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Different stakeholders need different architectural views: end users need the logical view (what the system does); developers need the development view (how to organise code); system integrators need the physical view (where things run); QA needs the process view (concurrency behaviour). Use cases tie all four together as concrete cross-cutting scenarios. The 4+1 model prevents documentation that serves only one audience while leaving others without necessary information.
व्याख्या (हिन्दी) विभिन्न हितधारकों को अलग-अलग वास्तुशिल्प विचारों की आवश्यकता होती है: अंतिम उपयोगकर्ताओं को तार्किक दृष्टिकोण की आवश्यकता होती है (सिस्टम क्या करता है); डेवलपर्स को विकास दृश्य की आवश्यकता है (कोड को कैसे व्यवस्थित करें); सिस्टम इंटीग्रेटर्स को भौतिक दृश्य (जहां चीजें चलती हैं) की आवश्यकता होती है; QA को प्रक्रिया दृश्य (समवर्ती व्यवहार) की आवश्यकता है। उपयोग के मामले इन चारों को ठोस क्रॉस-कटिंग परिदृश्यों के रूप में एक साथ जोड़ते हैं। 4+1 मॉडल उन दस्तावेज़ों को रोकता है जो केवल एक दर्शक को सेवा प्रदान करते हैं जबकि अन्य को आवश्यक जानकारी के बिना छोड़ देते हैं।
562
EN + हिं Easy
GB What is 'software cost estimation' and why do most software projects consistently underestimate?
IN 'सॉफ़्टवेयर लागत अनुमान' क्या है और अधिकांश सॉफ़्टवेयर परियोजनाएँ लगातार कम क्यों आंकी जाती हैं?
A
Software projects underestimate because developers deliberately lie to management about effort सॉफ़्टवेयर प्रोजेक्ट को कम आंका जाता है क्योंकि डेवलपर जानबूझकर प्रयास के बारे में प्रबंधन से झूठ बोलते हैं
B
Cost estimation predicts effort, schedule, and resources needed; underestimation is driven by: optimism bias (planning fallacy), omitting activities (testing, documentation, meetings), unclear requirements at estimation time, political pressure to win contracts, and the cone of uncertainty being ignored लागत का अनुमान प्रयास, कार्यक्रम और आवश्यक संसाधनों की भविष्यवाणी करता है; कम आकलन इसके द्वारा प्रेरित होता है: आशावाद पूर्वाग्रह (योजना की भ्रांति), गतिविधियों को छोड़ना (परीक्षण, दस्तावेज़ीकरण, बैठकें), अनुमान के समय अस्पष्ट आवश्यकताएं, अनुबंध जीतने के लिए राजनीतिक दबाव, और अनिश्चितता के शंकु को नजरअंदाज किया जाना
C
Underestimation only occurs in government projects due to bureaucratic planning processes नौकरशाही नियोजन प्रक्रियाओं के कारण केवल सरकारी परियोजनाओं में कम आकलन होता है
D
Software estimation is inherently impossible and all estimates are equally unreliable सॉफ़्टवेयर अनुमान स्वाभाविक रूप से असंभव है और सभी अनुमान समान रूप से अविश्वसनीय हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kahneman's planning fallacy (optimism bias) is empirically documented: people systematically underestimate completion time while being accurate about others' similar tasks. Software-specific causes: requirements are incomplete at estimation time, integration and testing effort is systematically underestimated, non-development work (meetings, reviews, documentation) is forgotten. CHAOS Report data (Standish Group) consistently shows ~50% of projects overrun their original estimates.
व्याख्या (हिन्दी) काह्नमैन की नियोजन भ्रांति (आशावाद पूर्वाग्रह) अनुभवजन्य रूप से प्रलेखित है: लोग व्यवस्थित रूप से दूसरों के समान कार्यों के बारे में सटीक होते हुए भी समापन समय को कम आंकते हैं। सॉफ़्टवेयर-विशिष्ट कारण: अनुमान के समय आवश्यकताएँ अधूरी हैं, एकीकरण और परीक्षण प्रयास को व्यवस्थित रूप से कम करके आंका गया है, गैर-विकास कार्य (बैठकें, समीक्षाएँ, दस्तावेज़ीकरण) को भुला दिया गया है। कैओस रिपोर्ट डेटा (स्टैंडिश ग्रुप) लगातार दिखाता है कि ~50% परियोजनाएं अपने मूल अनुमान से आगे निकल गई हैं।
563
EN + हिं Easy
GB What is 'agile scaling challenge' and what specific problems arise when applying Scrum to a 200-developer programme?
IN 'एजाइल स्केलिंग चैलेंज' क्या है और 200-डेवलपर प्रोग्राम में स्क्रम लागू करते समय कौन सी विशिष्ट समस्याएं उत्पन्न होती हैं?
A
Agile scaling challenges are only technical; organisational factors are irrelevant at scale तीव्र स्केलिंग चुनौतियाँ केवल तकनीकी हैं; संगठनात्मक कारक बड़े पैमाने पर अप्रासंगिक हैं
B
Scrum at 200+ developers faces: dependency management across 20+ teams, synchronisation overhead (Scrum of Scrums coordination), architectural alignment (preventing Conway's Law fragmentation), release coordination (all teams must be shippable simultaneously), and cultural resistance from middle management whose roles are disrupted 200+ डेवलपर्स पर स्क्रम का सामना: 20+ टीमों में निर्भरता प्रबंधन, सिंक्रनाइज़ेशन ओवरहेड (स्क्रम्स समन्वय का स्क्रम), वास्तुशिल्प संरेखण (कॉनवे के कानून विखंडन को रोकना), रिलीज समन्वय (सभी टीमों को एक साथ शिप करने योग्य होना चाहिए), और मध्य प्रबंधन से सांस्कृतिक प्रतिरोध जिनकी भूमिकाएं बाधित हैं
C
Scrum scales perfectly to any team size without modification as long as sprints remain 2 weeks जब तक स्प्रिंट 2 सप्ताह तक रहता है तब तक स्क्रम बिना किसी संशोधन के किसी भी टीम के आकार के लिए पूरी तरह से स्केल करता है
D
200-developer programmes always use Waterfall; Agile is only for teams under 20 people 200-डेवलपर प्रोग्राम हमेशा वॉटरफॉल का उपयोग करते हैं; एजाइल केवल 20 लोगों से कम उम्र की टीमों के लिए है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SAFe, LeSS, Nexus, and Scrum@Scale all address these scaling problems differently. The core challenges: inter-team dependencies create sprint impediments that individual teams cannot resolve; architectural decisions made by one team cascade to others; 'done' for the programme requires all teams ready to ship simultaneously; middle management roles (project managers, functional managers) become redundant in agile, creating resistance that must be managed explicitly.
व्याख्या (हिन्दी) SAFe, LeSS, Nexus, और Scrum@Scale सभी इन स्केलिंग समस्याओं को अलग-अलग तरीके से संबोधित करते हैं। मुख्य चुनौतियाँ: अंतर-टीम निर्भरता स्प्रिंट बाधाएँ पैदा करती है जिन्हें व्यक्तिगत टीमें हल नहीं कर सकती हैं; एक टीम द्वारा लिए गए वास्तुशिल्प निर्णय दूसरों पर प्रभाव डालते हैं; कार्यक्रम के लिए 'पूरा' करने के लिए सभी टीमों को एक साथ शिप करने के लिए तैयार होना आवश्यक है; मध्य प्रबंधन भूमिकाएँ (परियोजना प्रबंधक, कार्यात्मक प्रबंधक) फुर्तीलेपन में अनावश्यक हो जाती हैं, जिससे प्रतिरोध पैदा होता है जिसे स्पष्ट रूप से प्रबंधित किया जाना चाहिए।
564
EN + हिं Easy
GB What is 'hybrid process model' and when is it more appropriate than a pure agile or pure plan-driven approach?
IN 'हाइब्रिड प्रक्रिया मॉडल' क्या है और यह कब शुद्ध चुस्त या शुद्ध योजना-संचालित दृष्टिकोण से अधिक उपयुक्त है?
A
Hybrid models are always inferior to pure approaches because they lack clear methodology हाइब्रिड मॉडल हमेशा शुद्ध दृष्टिकोण से कमतर होते हैं क्योंकि उनमें स्पष्ट कार्यप्रणाली का अभाव होता है
B
Hybrid models combine elements from different process models tailored to specific project characteristics — appropriate when part of the system has stable requirements (use plan-driven phases for architecture/safety-critical components) while other parts have volatile requirements (use agile for UI/features) हाइब्रिड मॉडल विशिष्ट परियोजना विशेषताओं के अनुरूप विभिन्न प्रक्रिया मॉडल से तत्वों को जोड़ते हैं - उपयुक्त जब सिस्टम के हिस्से में स्थिर आवश्यकताएं होती हैं (आर्किटेक्चर/सुरक्षा-महत्वपूर्ण घटकों के लिए योजना-संचालित चरणों का उपयोग करें) जबकि अन्य भागों में अस्थिर आवश्यकताएं होती हैं (यूआई/सुविधाओं के लिए एजाइल का उपयोग करें)
C
Hybrid models are only used in organisations that cannot commit to a single methodology हाइब्रिड मॉडल का उपयोग केवल उन संगठनों में किया जाता है जो किसी एक पद्धति के लिए प्रतिबद्ध नहीं हो सकते
D
Hybrid models require separate teams for each methodology component, doubling staffing costs हाइब्रिड मॉडल में प्रत्येक कार्यप्रणाली घटक के लिए अलग-अलग टीमों की आवश्यकता होती है, जिससे स्टाफिंग लागत दोगुनी हो जाती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Real-world example: a medical device project uses formal methods and Waterfall for safety-critical embedded firmware (regulatory requirement), while the companion mobile app uses Scrum for its evolving user experience. Forcing one methodology on both produces worse outcomes — Waterfall applied to UI creates irrelevant designs; Agile applied to firmware creates unacceptable regulatory risk.
व्याख्या (हिन्दी) वास्तविक दुनिया का उदाहरण: एक चिकित्सा उपकरण परियोजना सुरक्षा-महत्वपूर्ण एम्बेडेड फर्मवेयर (नियामक आवश्यकता) के लिए औपचारिक तरीकों और वॉटरफॉल का उपयोग करती है, जबकि साथी मोबाइल ऐप अपने विकसित उपयोगकर्ता अनुभव के लिए स्क्रम का उपयोग करता है। दोनों पर एक पद्धति को लागू करने से खराब परिणाम उत्पन्न होते हैं - यूआई पर लागू वॉटरफॉल अप्रासंगिक डिजाइन बनाता है; फर्मवेयर पर लागू एजाइल अस्वीकार्य नियामक जोखिम पैदा करता है।
565
EN + हिं Medium
GB What is the 'executable specification' approach and how does it change the role of requirements documents?
IN 'निष्पादन योग्य विशिष्टता' दृष्टिकोण क्या है और यह आवश्यकता दस्तावेजों की भूमिका को कैसे बदलता है?
A
Executable specifications are UML class diagrams that generate database schemas निष्पादन योग्य विनिर्देश यूएमएल वर्ग आरेख हैं जो डेटाबेस स्कीमा उत्पन्न करते हैं
B
Executable specifications express requirements as runnable tests (BDD scenarios, acceptance tests) — changing the role of requirements documents from static text to living documentation that is simultaneously a specification, a test suite, and proof of implementation correctness निष्पादन योग्य विनिर्देश आवश्यकताओं को चलाने योग्य परीक्षणों (बीडीडी परिदृश्यों, स्वीकृति परीक्षणों) के रूप में व्यक्त करते हैं - आवश्यकताओं के दस्तावेज़ों की भूमिका को स्थिर पाठ से जीवित दस्तावेज़ में बदलना जो एक साथ एक विनिर्देश, एक परीक्षण सूट और कार्यान्वयन शुद्धता का प्रमाण है
C
Executable specifications replace all software development — no additional coding is needed निष्पादन योग्य विनिर्देश सभी सॉफ़्टवेयर विकास को प्रतिस्थापित करते हैं - किसी अतिरिक्त कोडिंग की आवश्यकता नहीं है
D
Executable specifications are only valid in functional programming languages like Haskell निष्पादन योग्य विनिर्देश केवल हास्केल जैसी कार्यात्मक प्रोग्रामिंग भाषाओं में मान्य हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Tools like Cucumber (Ruby/Java), Behave (Python), and SpecFlow (C#) enable Given-When-Then scenarios to be simultaneously: business-readable requirements, automated acceptance tests, and regression safeguards. When requirements change, the failing tests immediately signal which implementation needs updating — eliminating the traditional disconnect between requirements documents and implementation.
व्याख्या (हिन्दी) ककड़ी (रूबी/जावा), बिहेव (पायथन), और स्पेकफ्लो (सी#) जैसे उपकरण दिए गए-जब-तब परिदृश्यों को एक साथ सक्षम करते हैं: व्यवसाय-पठनीय आवश्यकताएं, स्वचालित स्वीकृति परीक्षण और प्रतिगमन सुरक्षा उपाय। जब आवश्यकताएं बदलती हैं, तो असफल परीक्षण तुरंत संकेत देते हैं कि किस कार्यान्वयन को अद्यतन करने की आवश्यकता है - आवश्यकताओं के दस्तावेजों और कार्यान्वयन के बीच पारंपरिक डिस्कनेक्ट को समाप्त करना।
566
EN + हिं Easy
GB What is the 'dual-track agile' development model and what problem does it address?
IN 'डुअल-ट्रैक एजाइल' विकास मॉडल क्या है और यह किस समस्या का समाधान करता है?
A
Dual-track agile runs two separate agile teams on the same product simultaneously डुअल-ट्रैक एजाइल एक ही उत्पाद पर दो अलग-अलग एजाइल टीमों को एक साथ चलाता है
B
Dual-track agile runs a discovery track (UX research, prototyping, user testing to validate ideas) parallel to a delivery track (engineering sprints building validated features) — addressing the problem of building features without validating they're the right features to build डुअल-ट्रैक एजाइल एक डिलीवरी ट्रैक के समानांतर एक डिस्कवरी ट्रैक (यूएक्स रिसर्च, प्रोटोटाइपिंग, विचारों को मान्य करने के लिए उपयोगकर्ता परीक्षण) चलाता है (इंजीनियरिंग स्प्रिंट मान्य सुविधाओं का निर्माण करता है) - सत्यापन किए बिना सुविधाओं के निर्माण की समस्या का समाधान करना कि वे निर्माण के लिए सही विशेषताएं हैं
C
Dual-track agile is identical to SAFe's Program Increment planning model डुअल-ट्रैक एजाइल SAFe के प्रोग्राम इंक्रीमेंट प्लानिंग मॉडल के समान है
D
Dual-track agile doubles the cost of development and is only viable for well-funded startups डुअल-ट्रैक एजाइल विकास की लागत को दोगुना कर देता है और यह केवल अच्छी तरह से वित्त पोषित स्टार्टअप के लिए व्यवहार्य है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without discovery, teams build based on assumptions about what users need — leading to technically correct but user-rejected features. Dual-track (Jeff Gothelf, Josh Seiden) ensures the discovery track stays 1-2 sprints ahead of delivery, validating feature ideas through lightweight user research before committing engineering resources to build them. This prevents the most expensive failure mode: building the wrong product.
व्याख्या (हिन्दी) खोज के बिना, टीमें इस धारणा के आधार पर निर्माण करती हैं कि उपयोगकर्ताओं को क्या चाहिए - तकनीकी रूप से सही लेकिन उपयोगकर्ता द्वारा अस्वीकृत सुविधाओं के लिए अग्रणी। डुअल-ट्रैक (जेफ़ गोथेल्फ़, जोश सेडेन) यह सुनिश्चित करता है कि डिस्कवरी ट्रैक डिलीवरी से 1-2 स्प्रिंट आगे रहे, उन्हें बनाने के लिए इंजीनियरिंग संसाधनों को प्रतिबद्ध करने से पहले हल्के उपयोगकर्ता अनुसंधान के माध्यम से फीचर विचारों को मान्य किया जाए। यह सबसे महंगी विफलता मोड को रोकता है: गलत उत्पाद का निर्माण।
567
EN + हिं Medium
GB What is 'evolutionary prototyping' and how does it differ from 'throwaway prototyping'?
IN 'विकासवादी प्रोटोटाइप' क्या है और यह 'थ्रोअवे प्रोटोटाइप' से कैसे भिन्न है?
A
Evolutionary prototyping uses more advanced tools than throwaway prototyping विकासवादी प्रोटोटाइप थ्रोअवे प्रोटोटाइप की तुलना में अधिक उन्नत उपकरणों का उपयोग करता है
B
Evolutionary prototyping builds a prototype with the intention of continuously evolving it into the final system; throwaway prototyping builds a quick-and-dirty prototype solely to elicit requirements, then discards it and rebuilds properly — evolutionary carries architectural risk if not carefully managed विकासवादी प्रोटोटाइप एक प्रोटोटाइप को अंतिम प्रणाली में लगातार विकसित करने के इरादे से बनाता है; थ्रोअवे प्रोटोटाइप पूरी तरह से आवश्यकताओं को पूरा करने के लिए एक त्वरित और गंदा प्रोटोटाइप बनाता है, फिर इसे त्याग देता है और ठीक से पुनर्निर्माण करता है - यदि सावधानी से प्रबंधित नहीं किया जाता है तो विकासवादी वास्तुशिल्प जोखिम उठाता है
C
Both types produce identical system quality outcomes; the choice is purely about timeline preferences दोनों प्रकार समान सिस्टम गुणवत्ता परिणाम उत्पन्न करते हैं; चुनाव पूरी तरह से समयरेखा प्राथमिकताओं के बारे में है
D
Throwaway prototyping is illegal in safety-critical systems; evolutionary prototyping is always required सुरक्षा-महत्वपूर्ण प्रणालियों में थ्रोअवे प्रोटोटाइपिंग अवैध है; विकासवादी प्रोटोटाइप की हमेशा आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Evolutionary prototyping risk: the prototype is built quickly with expedient shortcuts; if it 'works well enough', pressure mounts to ship it. The result is a production system built on throwaway-quality foundations. Managing this requires discipline: treat the evolving prototype as production code from the start, applying refactoring and quality practices. Throwaway prototyping avoids this risk by explicitly committing to discarding the prototype.
व्याख्या (हिन्दी) विकासवादी प्रोटोटाइप जोखिम: प्रोटोटाइप समीचीन शॉर्टकट के साथ शीघ्रता से बनाया जाता है; यदि यह 'पर्याप्त रूप से अच्छा काम करता है', तो इसे शिप करने का दबाव बढ़ जाता है। परिणाम एक ऐसी उत्पादन प्रणाली है जो सस्ती गुणवत्ता की बुनियाद पर बनी है। इसे प्रबंधित करने के लिए अनुशासन की आवश्यकता होती है: विकसित प्रोटोटाइप को शुरू से ही उत्पादन कोड के रूप में मानें, रिफैक्टरिंग और गुणवत्ता प्रथाओं को लागू करें। थ्रोअवे प्रोटोटाइप स्पष्ट रूप से प्रोटोटाइप को त्यागने के लिए प्रतिबद्ध होकर इस जोखिम से बचाता है।
568
EN + हिं Easy
GB What is the 'agile manifesto's fourth value' ('customer collaboration over contract negotiation') and what contractual mechanism supports it?
IN 'एजाइल मेनिफेस्टो का चौथा मूल्य' ('अनुबंध वार्ता पर ग्राहक सहयोग') क्या है और कौन सा अनुबंध तंत्र इसका समर्थन करता है?
A
The fourth value eliminates all contracts between customers and development organisations चौथा मान ग्राहकों और विकास संगठनों के बीच सभी अनुबंधों को समाप्त कर देता है
B
The value prioritises ongoing customer collaboration over rigid contract terms — supported by time-and-materials or outcome-based contracts that allow scope to evolve, rather than fixed-price fixed-scope contracts that make change adversarial मूल्य कठोर अनुबंध शर्तों पर चल रहे ग्राहक सहयोग को प्राथमिकता देता है - समय-और-सामग्री या परिणाम-आधारित अनुबंधों द्वारा समर्थित जो निश्चित-मूल्य निश्चित-स्कोप अनुबंधों के बजाय गुंजाइश विकसित करने की अनुमति देता है जो परिवर्तन को प्रतिकूल बनाता है
C
The fourth value requires customers to be employed directly by the development company चौथे मूल्य के लिए ग्राहकों को विकास कंपनी द्वारा सीधे नियोजित किया जाना आवश्यक है
D
Customer collaboration is only possible in co-located teams; remote teams cannot practise this value ग्राहक सहयोग केवल सह-स्थित टीमों में ही संभव है; दूरस्थ टीमें इस मान का अभ्यास नहीं कर सकतीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fixed-price fixed-scope contracts make every requirement change a legal dispute between customer and supplier — incentivising adversarial relationships. Time-and-materials contracts align interests: both parties benefit from getting the right product built efficiently. Outcome-based contracts take this further: payment tied to business outcomes (revenue generated, cost saved) rather than deliverables, fully aligning development with business success.
व्याख्या (हिन्दी) निश्चित-मूल्य निश्चित-स्कोप अनुबंध प्रत्येक आवश्यकता को ग्राहक और आपूर्तिकर्ता के बीच कानूनी विवाद में बदल देते हैं - प्रतिकूल संबंधों को प्रोत्साहित करते हैं। समय-और-सामग्री अनुबंध हितों को संरेखित करते हैं: सही उत्पाद को कुशलतापूर्वक निर्मित करने से दोनों पक्षों को लाभ होता है। परिणाम-आधारित अनुबंध इसे और आगे ले जाते हैं: भुगतान डिलिवरेबल्स के बजाय व्यावसायिक परिणामों (उत्पन्न राजस्व, लागत बचत) से जुड़ा होता है, जो विकास को व्यावसायिक सफलता के साथ पूरी तरह से संरेखित करता है।
569
EN + हिं Medium
GB What is the 'safe-to-fail experiment' concept in complex adaptive systems and how does it apply to software product development?
IN जटिल अनुकूली प्रणालियों में 'सुरक्षित-से-असफल प्रयोग' की अवधारणा क्या है और यह सॉफ्टवेयर उत्पाद विकास पर कैसे लागू होती है?
A
Safe-to-fail experiments guarantee product success by eliminating all risks before launch सुरक्षित-से-असफल प्रयोग लॉन्च से पहले सभी जोखिमों को समाप्त करके उत्पाद की सफलता की गारंटी देते हैं
B
Safe-to-fail experiments are small, low-cost probes designed so that failure provides learning rather than catastrophe — applied to software by running multiple small A/B tests or MVP variants simultaneously rather than betting everything on a single large release सुरक्षित-से-असफल प्रयोग छोटे, कम लागत वाले जांच होते हैं ताकि विफलता आपदा के बजाय सीख प्रदान कर सके - एक ही बड़ी रिलीज पर सब कुछ दांव पर लगाने के बजाय एक साथ कई छोटे ए/बी परीक्षण या एमवीपी वेरिएंट चलाकर सॉफ्टवेयर पर लागू किया जाता है।
C
Safe-to-fail experiments are only applicable to scientific research, not commercial software सुरक्षित-से-असफल प्रयोग केवल वैज्ञानिक अनुसंधान पर लागू होते हैं, व्यावसायिक सॉफ़्टवेयर पर नहीं
D
Safe-to-fail experiments require a minimum of 6 months to produce statistically valid results सुरक्षित-से-असफल प्रयोगों को सांख्यिकीय रूप से मान्य परिणाम देने के लिए कम से कम 6 महीने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Cynefin's Complex domain (Snowden): probe-sense-respond replaces plan-execute-monitor. Amazon's 'two-pizza teams' running simultaneous experiments embody this: launch multiple small feature tests, amplify what works, dampen what doesn't. The failed experiments cost little individually but provide learning that guides the amplified investment. This contrasts with traditional 'plan everything upfront' which makes a single large failure catastrophic.
व्याख्या (हिन्दी) सिनेफिन का कॉम्प्लेक्स डोमेन (स्नोडेन): जांच-समझ-प्रतिक्रिया योजना-निष्पादन-मॉनिटर की जगह लेता है। अमेज़ॅन की 'टू-पिज्जा टीमें' एक साथ चल रहे प्रयोगों में इसे शामिल करती हैं: कई छोटे फीचर परीक्षण लॉन्च करें, जो काम करता है उसे बढ़ाएं, जो काम नहीं करता है उसे कम करें। असफल प्रयोगों की लागत व्यक्तिगत रूप से बहुत कम होती है लेकिन यह ऐसी सीख प्रदान करती है जो बढ़े हुए निवेश का मार्गदर्शन करती है। यह पारंपरिक 'हर चीज़ पहले से योजना बनाएं' के विपरीत है जो एक बड़ी विफलता को विनाशकारी बना देती है।
570
EN + हिं Easy
GB What is 'continuous delivery' versus 'continuous deployment' and what organisational capability distinguishes teams that achieve them?
IN 'निरंतर वितरण' बनाम 'निरंतर तैनाती' क्या है और कौन सी संगठनात्मक क्षमता उन्हें हासिल करने वाली टीमों को अलग करती है?
A
Continuous delivery and deployment are synonymous; the terms are used interchangeably निरंतर वितरण और तैनाती पर्यायवाची हैं; शब्दों का प्रयोग परस्पर उपयोग किया जाता है
B
Continuous delivery ensures every commit is releasable (deployable on demand by business decision); continuous deployment automatically releases every passing commit to production without human approval — distinguished by organisational capability: trust in automated testing, deployment automation, monitoring, and cultural acceptance of frequent small releases निरंतर डिलीवरी यह सुनिश्चित करती है कि प्रत्येक प्रतिबद्धता रिलीज़ करने योग्य है (व्यावसायिक निर्णय द्वारा मांग पर तैनाती योग्य); निरंतर तैनाती मानव अनुमोदन के बिना उत्पादन के लिए प्रत्येक गुजरने वाली प्रतिबद्धता को स्वचालित रूप से जारी करती है - संगठनात्मक क्षमता द्वारा प्रतिष्ठित: स्वचालित परीक्षण, तैनाती स्वचालन, निगरानी और लगातार छोटी रिलीज की सांस्कृतिक स्वीकृति में विश्वास
C
Continuous deployment is always preferable to continuous delivery for all organisations सभी संगठनों के लिए निरंतर वितरण की तुलना में निरंतर तैनाती हमेशा बेहतर होती है
D
Both practices require dedicated hardware separate from production for safety दोनों प्रथाओं को सुरक्षा के लिए उत्पादन से अलग समर्पित हार्डवेयर की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Netflix and Amazon practice continuous deployment (thousands of deploys per day). Many enterprises practice continuous delivery — they CAN deploy anytime but choose deployment windows for business reasons (avoid Friday deploys, coordinate with marketing). The capability prerequisite: deployment pipeline (build → test → stage → prod) must be automated, fast (<30 mins end-to-end), and reliable enough to trust without manual verification at each stage.
व्याख्या (हिन्दी) नेटफ्लिक्स और अमेज़ॅन निरंतर तैनाती (प्रति दिन हजारों तैनाती) का अभ्यास करते हैं। कई उद्यम निरंतर डिलीवरी का अभ्यास करते हैं - वे किसी भी समय तैनाती कर सकते हैं लेकिन व्यावसायिक कारणों से तैनाती विंडो चुनते हैं (शुक्रवार की तैनाती से बचें, विपणन के साथ समन्वय करें)। क्षमता पूर्वावश्यकता: परिनियोजन पाइपलाइन (निर्माण → परीक्षण → चरण → उत्पादन) स्वचालित, तेज़ होनी चाहिए (
556–570 of 647