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
271
EN + हिं Easy
GB What is the 'Mythical Man-Month' principle and what does it imply for adding developers to a late project?
IN 'मिथिकल मैन-मंथ' सिद्धांत क्या है और देर से आने वाले प्रोजेक्ट में डेवलपर्स को जोड़ने के लिए इसका क्या मतलब है?
A
Adding developers always speeds up a late project proportionally डेवलपर्स को जोड़ने से हमेशा विलंबित प्रोजेक्ट में आनुपातिक रूप से गति आती है
B
Adding manpower to a late software project makes it later — because new developers require training time from existing developers and increase communication overhead देर से आने वाले सॉफ़्टवेयर प्रोजेक्ट में जनशक्ति जोड़ने से यह बाद में बनता है - क्योंकि नए डेवलपर्स को मौजूदा डेवलपर्स से प्रशिक्षण समय की आवश्यकता होती है और संचार ओवरहेड में वृद्धि होती है
C
Adding developers only helps if the new hires are senior engineers डेवलपर्स को जोड़ने से केवल तभी मदद मिलती है जब नए कर्मचारी वरिष्ठ इंजीनियर हों
D
The Mythical Man-Month applies only to projects over 100 developers मिथिकल मैन-मंथ केवल 100 से अधिक डेवलपर्स की परियोजनाओं पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Brooks' Law: 'Adding manpower to a late software project makes it later.' New team members require ramp-up time, divert existing developers to train them, and increase communication channels (n*(n-1)/2 channels for n people), temporarily reducing productivity before any benefit is seen.
व्याख्या (हिन्दी) ब्रूक्स का नियम: 'किसी सॉफ़्टवेयर प्रोजेक्ट में जनशक्ति जोड़ने से वह बाद में बन जाता है।' नई टीम के सदस्यों को रैंप-अप समय की आवश्यकता होती है, मौजूदा डेवलपर्स को उन्हें प्रशिक्षित करने के लिए डायवर्ट किया जाता है, और संचार चैनल (n लोगों के लिए n*(n-1)/2 चैनल) बढ़ाए जाते हैं, जिससे कोई लाभ दिखने से पहले अस्थायी रूप से उत्पादकता कम हो जाती है।
272
EN + हिं Medium
GB What distinguishes 'incremental delivery' from 'iterative development' in software process models?
IN सॉफ़्टवेयर प्रक्रिया मॉडल में 'वृद्धिशील वितरण' को 'पुनरावृत्त विकास' से क्या अलग करता है?
A
Incremental delivery uses sprints; iterative development uses phases वृद्धिशील डिलीवरी स्प्रिंट का उपयोग करती है; पुनरावृत्तीय विकास चरणों का उपयोग करता है
B
Incremental delivery adds functionality in planned chunks without revisiting prior increments; iterative development repeatedly refines the entire system through cycles, improving quality with each iteration वृद्धिशील वितरण पूर्व वेतन वृद्धि पर दोबारा गौर किए बिना नियोजित भागों में कार्यक्षमता जोड़ता है; पुनरावृत्त विकास बार-बार चक्रों के माध्यम से संपूर्ण प्रणाली को परिष्कृत करता है, प्रत्येक पुनरावृत्ति के साथ गुणवत्ता में सुधार करता है
C
Both are identical concepts used interchangeably in agile contexts दोनों समान अवधारणाएँ हैं जिनका उपयोग त्वरित संदर्भों में परस्पर उपयोग किया जाता है
D
Iterative delivery always produces better quality than incremental delivery पुनरावर्ती डिलीवरी हमेशा वृद्धिशील डिलीवरी की तुलना में बेहतर गुणवत्ता उत्पन्न करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Incremental development adds new features to a stable base; each increment is a mini-waterfall adding a slice. Iterative development starts with a rough version of the whole system and progressively improves it. Agile methods often combine both — incrementally adding features while iteratively refining existing ones.
व्याख्या (हिन्दी) वृद्धिशील विकास एक स्थिर आधार में नई सुविधाएँ जोड़ता है; प्रत्येक वृद्धि एक टुकड़ा जोड़ने वाला एक छोटा झरना है। पुनरावृत्तीय विकास पूरे सिस्टम के किसी न किसी संस्करण से शुरू होता है और धीरे-धीरे इसमें सुधार करता है। चंचल तरीके अक्सर दोनों को जोड़ते हैं - मौजूदा सुविधाओं को पुनरावृत्तीय रूप से परिष्कृत करते हुए वृद्धिशील रूप से सुविधाएँ जोड़ते हैं।
273
EN + हिं Easy
GB What is a 'software product line' and what is its primary engineering advantage?
IN 'सॉफ़्टवेयर उत्पाद लाइन' क्या है और इसका प्राथमिक इंजीनियरिंग लाभ क्या है?
A
A sequence of software versions released annually प्रतिवर्ष जारी किए जाने वाले सॉफ़्टवेयर संस्करणों का एक क्रम
B
A family of related systems that share a common, managed set of features satisfying specific market needs — enabling systematic reuse of architecture, components, and assets across multiple products संबंधित प्रणालियों का एक परिवार जो विशिष्ट बाज़ार आवश्यकताओं को पूरा करने वाली सुविधाओं का एक सामान्य, प्रबंधित सेट साझा करता है - कई उत्पादों में वास्तुकला, घटकों और संपत्तियों के व्यवस्थित पुन: उपयोग को सक्षम बनाता है।
C
A collection of open-source libraries used by a single organisation किसी एकल संगठन द्वारा उपयोग किए जाने वाले ओपन-सोर्स पुस्तकालयों का संग्रह
D
A software testing methodology that validates multiple product variants simultaneously एक सॉफ़्टवेयर परीक्षण पद्धति जो एक साथ कई उत्पाद प्रकारों को मान्य करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Software Product Lines (Clements and Northrop) create competitive advantage through systematic reuse: instead of building each product from scratch, organisations invest in a core asset base (architecture, reusable components, processes) shared across a family of products, reducing cost and time-to-market for each product variant.
व्याख्या (हिन्दी) सॉफ़्टवेयर उत्पाद श्रृंखलाएँ (क्लेमेंट्स और नॉर्थ्रॉप) व्यवस्थित पुन: उपयोग के माध्यम से प्रतिस्पर्धात्मक लाभ पैदा करती हैं: प्रत्येक उत्पाद को खरोंच से बनाने के बजाय, संगठन उत्पादों के एक परिवार में साझा किए गए मुख्य परिसंपत्ति आधार (वास्तुकला, पुन: प्रयोज्य घटकों, प्रक्रियाओं) में निवेश करते हैं, जिससे प्रत्येक उत्पाद प्रकार के लिए लागत और समय-समय पर बाजार में कमी आती है।
274
EN + हिं Medium
GB In software engineering, what is the fundamental difference between 'reliability' and 'availability'?
IN सॉफ्टवेयर इंजीनियरिंग में, 'विश्वसनीयता' और 'उपलब्धता' के बीच मूलभूत अंतर क्या है?
A
Reliability measures user satisfaction; availability measures system speed विश्वसनीयता उपयोगकर्ता की संतुष्टि को मापती है; उपलब्धता सिस्टम की गति को मापती है
B
Reliability is the probability the system will perform its required function without failure for a specified time period; availability is the proportion of time the system is operational and accessible when needed विश्वसनीयता वह संभावना है जो सिस्टम एक निर्दिष्ट समय अवधि के लिए विफलता के बिना अपना आवश्यक कार्य करेगा; उपलब्धता उस समय का अनुपात है जब सिस्टम चालू रहता है और जरूरत पड़ने पर पहुंच योग्य होता है
C
Both terms are synonymous and used interchangeably in SLAs दोनों शब्द पर्यायवाची हैं और एसएलए में परस्पर उपयोग किए जाते हैं
D
Reliability applies to hardware; availability applies to software systems विश्वसनीयता हार्डवेयर पर लागू होती है; उपलब्धता सॉफ़्टवेयर सिस्टम पर लागू होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A system can be highly reliable (rarely fails) but have low availability (takes long to restart after rare failures). Conversely, a system with frequent short failures can still have high availability. Reliability is about failure frequency; availability accounts for both failure frequency and recovery time: Availability = MTTF / (MTTF + MTTR).
व्याख्या (हिन्दी) एक सिस्टम अत्यधिक विश्वसनीय हो सकता है (शायद ही कभी विफल होता है) लेकिन इसकी उपलब्धता कम होती है (दुर्लभ विफलताओं के बाद पुनरारंभ होने में लंबा समय लगता है)। इसके विपरीत, बार-बार छोटी विफलताओं वाली प्रणाली में अभी भी उच्च उपलब्धता हो सकती है। विश्वसनीयता विफलता की आवृत्ति के बारे में है; उपलब्धता विफलता की आवृत्ति और पुनर्प्राप्ति समय दोनों को ध्यान में रखती है: उपलब्धता = एमटीटीएफ / (एमटीटीएफ + एमटीटीआर)।
275
EN + हिं Medium
GB What is the 'software architecture' of a system and why is it distinct from 'design'?
IN किसी सिस्टम का 'सॉफ़्टवेयर आर्किटेक्चर' क्या है और यह 'डिज़ाइन' से अलग क्यों है?
A
Architecture is the physical infrastructure; design is the logical structure वास्तुकला भौतिक बुनियादी ढाँचा है; डिज़ाइन तार्किक संरचना है
B
Architecture describes the high-level structure of a software system — its principal components, their relationships, and the fundamental principles governing their design; design elaborates the internal details of individual components आर्किटेक्चर एक सॉफ्टवेयर सिस्टम की उच्च-स्तरीय संरचना का वर्णन करता है - इसके प्रमुख घटक, उनके रिश्ते, और उनके डिजाइन को नियंत्रित करने वाले मूलभूत सिद्धांत; डिज़ाइन व्यक्तिगत घटकों के आंतरिक विवरण को विस्तृत करता है
C
Architecture and design are identical; the terms differ only by the level of seniority of the person producing them वास्तुकला और डिज़ाइन समान हैं; शर्तें केवल उन्हें बनाने वाले व्यक्ति की वरिष्ठता के स्तर के आधार पर भिन्न होती हैं
D
Architecture only applies to distributed systems; design applies to all systems आर्किटेक्चर केवल वितरित सिस्टम पर लागू होता है; डिज़ाइन सभी प्रणालियों पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Architectural decisions are strategic and costly to change: choice of architectural style (microservices vs monolith), deployment model, inter-system protocols. Design decisions are tactical and local: class structure, algorithm choices, data format within a component. Poor architecture cannot be compensated by good design.
व्याख्या (हिन्दी) वास्तुशिल्प निर्णय रणनीतिक हैं और उन्हें बदलना महंगा है: वास्तुशिल्प शैली का विकल्प (माइक्रोसर्विसेज बनाम मोनोलिथ), परिनियोजन मॉडल, अंतर-सिस्टम प्रोटोकॉल। डिज़ाइन निर्णय सामरिक और स्थानीय होते हैं: वर्ग संरचना, एल्गोरिदम विकल्प, एक घटक के भीतर डेटा प्रारूप। ख़राब वास्तुकला की भरपाई अच्छे डिज़ाइन से नहीं की जा सकती।
276
EN + हिं Easy
GB What is 'non-functional testing' and what makes it fundamentally different from functional testing in scope?
IN 'गैर-कार्यात्मक परीक्षण' क्या है और क्या इसे दायरे में कार्यात्मक परीक्षण से मौलिक रूप से अलग बनाता है?
A
Non-functional testing only requires manual execution; functional testing can be automated गैर-कार्यात्मक परीक्षण के लिए केवल मैन्युअल निष्पादन की आवश्यकता होती है; कार्यात्मक परीक्षण स्वचालित किया जा सकता है
B
Non-functional testing verifies quality attributes like performance, security, and usability rather than specific behaviours; it often requires the entire integrated system under realistic load and cannot be decomposed into unit tests गैर-कार्यात्मक परीक्षण विशिष्ट व्यवहारों के बजाय प्रदर्शन, सुरक्षा और प्रयोज्य जैसी गुणवत्ता विशेषताओं की पुष्टि करता है; इसके लिए अक्सर यथार्थवादी भार के तहत संपूर्ण एकीकृत प्रणाली की आवश्यकता होती है और इसे इकाई परीक्षणों में विघटित नहीं किया जा सकता है
C
Non-functional testing is performed by end users; functional testing by developers गैर-कार्यात्मक परीक्षण अंतिम उपयोगकर्ताओं द्वारा किया जाता है; डेवलपर्स द्वारा कार्यात्मक परीक्षण
D
Non-functional testing only applies after the product is released to production गैर-कार्यात्मक परीक्षण केवल उत्पाद को उत्पादन के लिए जारी किए जाने के बाद ही लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Functional tests verify 'what' the system does (correct outputs for given inputs). Non-functional tests verify 'how well' it does it — performance under load, security against attacks, usability with real users. These require realistic environments, specialist tools, and cannot be decomposed into isolated unit tests.
व्याख्या (हिन्दी) कार्यात्मक परीक्षण सत्यापित करते हैं कि सिस्टम 'क्या' करता है (दिए गए इनपुट के लिए सही आउटपुट)। गैर-कार्यात्मक परीक्षण यह सत्यापित करते हैं कि यह 'कितनी अच्छी तरह' काम करता है - लोड के तहत प्रदर्शन, हमलों के खिलाफ सुरक्षा, वास्तविक उपयोगकर्ताओं के साथ प्रयोज्य। इनके लिए यथार्थवादी वातावरण, विशेषज्ञ उपकरणों की आवश्यकता होती है और इन्हें पृथक इकाई परीक्षणों में विघटित नहीं किया जा सकता है।
277
EN + हिं Medium
GB In risk management for software projects, what distinguishes 'risk mitigation' from 'risk contingency'?
IN सॉफ़्टवेयर परियोजनाओं के लिए जोखिम प्रबंधन में, 'जोखिम शमन' को 'जोखिम आकस्मिकता' से क्या अलग करता है?
A
Risk mitigation is done before project start; risk contingency after project completion जोखिम शमन परियोजना शुरू होने से पहले किया जाता है; प्रोजेक्ट पूरा होने के बाद जोखिम आकस्मिकता
B
Risk mitigation reduces the probability or impact of a risk before it occurs; risk contingency is a plan activated only if the risk actually materialises — reactive rather than preventive जोखिम शमन किसी जोखिम के घटित होने से पहले ही उसकी संभावना या प्रभाव को कम कर देता है; जोखिम आकस्मिकता एक ऐसी योजना है जिसे तभी सक्रिय किया जाता है जब जोखिम वास्तव में सामने आता है - निवारक के बजाय प्रतिक्रियाशील
C
Risk mitigation is the responsibility of project managers; risk contingency of developers जोखिम कम करना परियोजना प्रबंधकों की जिम्मेदारी है; डेवलपर्स की जोखिम आकस्मिकता
D
Both terms are synonymous in PMI's PMBOK framework दोनों शब्द पीएमआई के पीएमबीओके ढांचे में पर्यायवाची हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Mitigation is proactive: actions taken now to reduce likelihood or severity (e.g., adding prototype to reduce requirements uncertainty). Contingency is reactive: a pre-planned response invoked when a risk event occurs (e.g., a reserve schedule buffer activated if a key dependency is late). Best practice uses both together.
व्याख्या (हिन्दी) शमन सक्रिय है: संभावना या गंभीरता को कम करने के लिए अब की गई कार्रवाई (उदाहरण के लिए, आवश्यकताओं की अनिश्चितता को कम करने के लिए प्रोटोटाइप जोड़ना)। आकस्मिकता प्रतिक्रियाशील होती है: जब कोई जोखिम घटना घटित होती है तो एक पूर्व-नियोजित प्रतिक्रिया लागू होती है (उदाहरण के लिए, यदि एक प्रमुख निर्भरता देर से होती है तो एक आरक्षित शेड्यूल बफर सक्रिय होता है)। सर्वोत्तम अभ्यास दोनों का एक साथ उपयोग करना है।
278
EN + हिं Easy
GB What is 'software configuration management' (SCM) and what four primary activities does it encompass?
IN 'सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन' (एससीएम) क्या है और इसमें कौन सी चार प्राथमिक गतिविधियाँ शामिल हैं?
A
SCM is project scheduling; activities are planning, monitoring, reporting, and closing एससीएम प्रोजेक्ट शेड्यूलिंग है; गतिविधियाँ योजना बनाना, निगरानी करना, रिपोर्टिंग करना और बंद करना हैं
B
SCM controls evolution of software products; its four activities are: configuration identification, change control, status accounting, and configuration auditing एससीएम सॉफ्टवेयर उत्पादों के विकास को नियंत्रित करता है; इसकी चार गतिविधियाँ हैं: कॉन्फ़िगरेशन पहचान, परिवर्तन नियंत्रण, स्थिति लेखांकन और कॉन्फ़िगरेशन ऑडिटिंग
C
SCM is a testing methodology encompassing unit, integration, system, and acceptance testing एससीएम एक परीक्षण पद्धति है जिसमें इकाई, एकीकरण, प्रणाली और स्वीकृति परीक्षण शामिल है
D
SCM manages developer team configuration; activities are hiring, training, reviewing, and promoting एससीएम डेवलपर टीम कॉन्फ़िगरेशन का प्रबंधन करता है; गतिविधियाँ भर्ती करना, प्रशिक्षण देना, समीक्षा करना और प्रचार करना हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SCM (IEEE 828) manages changes to software work products throughout the lifecycle. The four activities: 1) Identification — naming and versioning baselines; 2) Change control — evaluating and approving changes; 3) Status accounting — recording what changed when and why; 4) Auditing — verifying the baseline reflects agreed content.
व्याख्या (हिन्दी) SCM (IEEE 828) पूरे जीवनचक्र में सॉफ़्टवेयर कार्य उत्पादों में परिवर्तन का प्रबंधन करता है। चार गतिविधियाँ: 1) पहचान - आधार रेखाओं का नामकरण और संस्करणीकरण; 2) परिवर्तन नियंत्रण - परिवर्तनों का मूल्यांकन और अनुमोदन; 3) स्थिति लेखांकन - कब और क्यों क्या परिवर्तन हुआ, इसकी रिकॉर्डिंग करना; 4) ऑडिटिंग - बेसलाइन का सत्यापन सहमत सामग्री को दर्शाता है।
279
EN + हिं Easy
GB What is 'cleanroom software engineering' and what statistical assurance does it provide?
IN 'क्लीनरूम सॉफ्टवेयर इंजीनियरिंग' क्या है और यह क्या सांख्यिकीय आश्वासन प्रदान करती है?
A
Cleanroom SE is software developed in dust-free hardware manufacturing environments क्लीनरूम एसई धूल रहित हार्डवेयर विनिर्माण वातावरण में विकसित सॉफ्टवेयर है
B
Cleanroom SE uses mathematical specification, structured design, and statistical testing to certify a software's mean time to failure — providing quantifiable, statistically defensible reliability certificates क्लीनरूम एसई किसी सॉफ़्टवेयर की विफलता के औसत समय को प्रमाणित करने के लिए गणितीय विनिर्देश, संरचित डिज़ाइन और सांख्यिकीय परीक्षण का उपयोग करता है - मात्रात्मक, सांख्यिकीय रूप से रक्षात्मक विश्वसनीयता प्रमाणपत्र प्रदान करता है
C
Cleanroom SE is a synonym for test-driven development with 100% coverage क्लीनरूम एसई 100% कवरेज के साथ परीक्षण-संचालित विकास का पर्याय है
D
Cleanroom SE eliminates all bugs by refusing to allow defects to enter the codebase क्लीनरूम एसई दोषों को कोडबेस में प्रवेश करने की अनुमति देने से इनकार करके सभी बग को समाप्त कर देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Cleanroom (Mills, Dyer, Linger) uses formal methods for specification and design, combined with statistical usage-based testing that generates test cases from the operational profile. Unlike conventional testing, cleanroom provides a statistical certificate of mean time to failure based on test results — enabling formal reliability statements.
व्याख्या (हिन्दी) क्लीनरूम (मिल्स, डायर, लिंगर) विनिर्देशन और डिजाइन के लिए औपचारिक तरीकों का उपयोग करता है, जो सांख्यिकीय उपयोग-आधारित परीक्षण के साथ संयुक्त होता है जो परिचालन प्रोफ़ाइल से परीक्षण मामले उत्पन्न करता है। पारंपरिक परीक्षण के विपरीत, क्लीनरूम परीक्षण परिणामों के आधार पर विफलता के औसत समय का एक सांख्यिकीय प्रमाण पत्र प्रदान करता है - औपचारिक विश्वसनीयता कथनों को सक्षम करता है।
280
EN + हिं Medium
GB What is the 'capability maturity model integration' (CMMI) and how does it differ from CMM?
IN 'क्षमता परिपक्वता मॉडल एकीकरण' (सीएमएमआई) क्या है और यह सीएमएम से कैसे भिन्न है?
A
CMMI is a newer version of CMM with identical structure but updated terminology सीएमएमआई समान संरचना लेकिन अद्यतन शब्दावली के साथ सीएमएम का एक नया संस्करण है
B
CMMI integrates multiple CMM models (software, systems, acquisition) into one framework and supports both staged and continuous representations, while CMM was software-specific and staged only सीएमएमआई कई सीएमएम मॉडल (सॉफ्टवेयर, सिस्टम, अधिग्रहण) को एक ढांचे में एकीकृत करता है और चरणबद्ध और निरंतर प्रतिनिधित्व दोनों का समर्थन करता है, जबकि सीएमएम सॉफ्टवेयर-विशिष्ट था और केवल चरणबद्ध था
C
CMMI is used by small companies; CMM was designed for large enterprises only सीएमएमआई का उपयोग छोटी कंपनियों द्वारा किया जाता है; सीएमएम केवल बड़े उद्यमों के लिए डिज़ाइन किया गया था
D
CMMI replaced CMM because CMM had mathematical errors in its level definitions सीएमएमआई ने सीएमएम का स्थान ले लिया क्योंकि सीएमएम की स्तर परिभाषाओं में गणितीय त्रुटियां थीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CMM was originally developed for software development only with five maturity levels in a staged model. CMMI (2000+) consolidated multiple discipline-specific CMMs and introduced a continuous representation allowing organisations to improve selected process areas independently, making it applicable across engineering disciplines.
व्याख्या (हिन्दी) सीएमएम को मूल रूप से केवल चरणबद्ध मॉडल में पांच परिपक्वता स्तरों के साथ सॉफ्टवेयर विकास के लिए विकसित किया गया था। सीएमएमआई (2000+) ने कई अनुशासन-विशिष्ट सीएमएम को समेकित किया और संगठनों को स्वतंत्र रूप से चयनित प्रक्रिया क्षेत्रों में सुधार करने की अनुमति देते हुए एक निरंतर प्रतिनिधित्व पेश किया, जिससे यह इंजीनियरिंग विषयों पर लागू हो गया।
281
EN + हिं Easy
GB What is 'prototyping model' in software development and when does it fail as a strategy?
IN सॉफ़्टवेयर विकास में 'प्रोटोटाइपिंग मॉडल' क्या है और यह एक रणनीति के रूप में कब विफल हो जाता है?
A
Prototyping model fails when the prototype is written in a different language than the final system प्रोटोटाइप मॉडल तब विफल हो जाता है जब प्रोटोटाइप को अंतिम सिस्टम से भिन्न भाषा में लिखा जाता है
B
Prototyping builds a quick partial implementation to elicit requirements or prove feasibility; it fails when the prototype becomes the product — teams ship poorly structured throwaway code as the final system प्रोटोटाइपिंग आवश्यकताओं को पूरा करने या व्यवहार्यता साबित करने के लिए त्वरित आंशिक कार्यान्वयन बनाता है; यह तब विफल हो जाता है जब प्रोटोटाइप उत्पाद बन जाता है - टीमें अंतिम प्रणाली के रूप में खराब संरचित थ्रोअवे कोड भेजती हैं
C
Prototyping fails when team members have different programming language preferences जब टीम के सदस्यों की प्रोग्रामिंग भाषा प्राथमिकताएँ भिन्न होती हैं तो प्रोटोटाइप विफल हो जाता है
D
Prototyping model is only valid for mobile application development प्रोटोटाइप मॉडल केवल मोबाइल एप्लिकेशन विकास के लिए मान्य है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The classic prototyping failure occurs when management sees a working demo and insists on shipping it without architectural rework. Prototypes are deliberately quick-and-dirty — they cut corners on error handling, security, and scalability. Shipping them incurs massive technical debt and often requires complete rewrite later.
व्याख्या (हिन्दी) क्लासिक प्रोटोटाइप विफलता तब होती है जब प्रबंधन एक कार्यशील डेमो देखता है और वास्तुशिल्प पुन: कार्य के बिना इसे शिपिंग करने पर जोर देता है। प्रोटोटाइप जानबूझकर त्वरित और गंदे होते हैं - वे त्रुटि प्रबंधन, सुरक्षा और स्केलेबिलिटी पर ध्यान नहीं देते हैं। उन्हें शिपिंग करने पर बड़े पैमाने पर तकनीकी ऋण लगता है और अक्सर बाद में पूर्ण पुनर्लेखन की आवश्यकता होती है।
282
EN + हिं Easy
GB What is the 'V-model' in software development and what is its key advantage over basic Waterfall?
IN सॉफ्टवेयर विकास में 'वी-मॉडल' क्या है और बेसिक वॉटरफॉल की तुलना में इसका मुख्य लाभ क्या है?
A
V-model is a Waterfall variant where all testing is moved to the beginning of the project वी-मॉडल एक वॉटरफ़ॉल संस्करण है जहां सभी परीक्षण परियोजना की शुरुआत में ले जाया जाता है
B
V-model maps each development phase to a corresponding verification/validation activity — design decisions and test planning occur in parallel, enabling earlier defect detection than Waterfall वी-मॉडल प्रत्येक विकास चरण को संबंधित सत्यापन/सत्यापन गतिविधि में मैप करता है - डिजाइन निर्णय और परीक्षण योजना समानांतर में होती है, जिससे वॉटरफॉल की तुलना में पहले दोष का पता लगाना संभव हो जाता है।
C
V-model allows requirements to change freely throughout development unlike Waterfall वी-मॉडल वॉटरफॉल के विपरीत पूरे विकास के दौरान आवश्यकताओं को स्वतंत्र रूप से बदलने की अनुमति देता है
D
V-model eliminates the need for integration testing by design वी-मॉडल डिज़ाइन द्वारा एकीकरण परीक्षण की आवश्यकता को समाप्त करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The V-model (Verification and Validation model) pairs each left-side development phase with a right-side testing phase. System requirements pair with acceptance testing; architecture with system testing; detailed design with integration testing; code with unit testing. Test planning begins in parallel with development, catching testability issues early.
व्याख्या (हिन्दी) वी-मॉडल (सत्यापन और सत्यापन मॉडल) प्रत्येक बाईं ओर के विकास चरण को दाईं ओर के परीक्षण चरण के साथ जोड़ता है। सिस्टम आवश्यकताएँ स्वीकृति परीक्षण के साथ जोड़ी जाती हैं; सिस्टम परीक्षण के साथ वास्तुकला; एकीकरण परीक्षण के साथ विस्तृत डिज़ाइन; यूनिट परीक्षण के साथ कोड। परीक्षण की योजना विकास के साथ-साथ शुरू होती है, परीक्षण योग्यता के मुद्दों को पहले ही पकड़ लेती है।
283
EN + हिं Easy
GB What is a 'timeboxed' development approach and what problem does it solve that traditional scheduling cannot?
IN 'टाइमबॉक्स्ड' विकास दृष्टिकोण क्या है और यह किस समस्या का समाधान करता है जिसे पारंपरिक शेड्यूलिंग नहीं हल कर सकती?
A
Timeboxed development restricts total project duration to a fixed calendar year टाइमबॉक्स्ड विकास कुल परियोजना अवधि को एक निश्चित कैलेंडर वर्ष तक सीमित करता है
B
Timeboxing fixes the delivery date and varies scope — delivering the best possible product within a fixed time rather than a fixed scope by a variable date; solving the tendency of software to expand indefinitely टाइमबॉक्सिंग डिलीवरी की तारीख तय करती है और दायरा बदलता है - एक परिवर्तनीय तिथि के अनुसार एक निश्चित दायरे के बजाय एक निश्चित समय के भीतर सर्वोत्तम संभव उत्पाद वितरित करना; सॉफ़्टवेयर की अनिश्चित काल तक विस्तार करने की प्रवृत्ति को हल करना
C
Timeboxed development is identical to sprint planning in Scrum and was invented by Scrum creators टाइमबॉक्स्ड विकास स्क्रम में स्प्रिंट योजना के समान है और इसका आविष्कार स्क्रम रचनाकारों द्वारा किया गया था
D
Timeboxing only works when all team members work full-time on a single project टाइमबॉक्सिंग तभी काम करती है जब टीम के सभी सदस्य एक ही प्रोजेक्ट पर पूर्णकालिक काम करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traditional scheduling fixes scope and lets schedule slip. Timeboxing (DSDM, MoSCoW) inverts this: the date is immovable, so scope is negotiated. Features are prioritised as Must-have, Should-have, Could-have, Won't-have. If time runs short, Won't-have and Could-have features drop — ensuring on-time delivery of core value.
व्याख्या (हिन्दी) पारंपरिक शेड्यूलिंग दायरा तय करती है और शेड्यूल को खिसकने देती है। टाइमबॉक्सिंग (DSDM, MoSCoW) इसे उलट देता है: तारीख अचल है, इसलिए दायरे पर बातचीत की जाती है। सुविधाओं को अवश्य-होना चाहिए, होना चाहिए, हो सकता है, नहीं होना चाहिए के रूप में प्राथमिकता दी जाती है। यदि समय कम हो जाता है, तो 'नॉट-हैव' और 'कैड-हैव' सुविधाएँ कम हो जाती हैं - मुख्य मूल्य की समय पर डिलीवरी सुनिश्चित करना।
284
EN + हिं Easy
GB What is 'software process improvement' (SPI) and what evidence does literature provide about its ROI?
IN 'सॉफ़्टवेयर प्रक्रिया सुधार' (एसपीआई) क्या है और साहित्य इसके आरओआई के बारे में क्या सबूत प्रदान करता है?
A
SPI is the practice of updating programming languages used in development; ROI is proportional to language modernity एसपीआई विकास में प्रयुक्त प्रोग्रामिंग भाषाओं को अद्यतन करने का अभ्यास है; आरओआई भाषा आधुनिकता के समानुपाती है
B
SPI systematically analyses and modifies development processes to improve quality, predictability, and efficiency; studies (SEI, Brodman & Johnson) show typical ROIs of 3:1 to 9:1 but only when sustained over multiple years एसपीआई गुणवत्ता, पूर्वानुमेयता और दक्षता में सुधार के लिए विकास प्रक्रियाओं का व्यवस्थित रूप से विश्लेषण और संशोधन करता है; अध्ययन (एसईआई, ब्रोडमैन और जॉनसन) सामान्य आरओआई 3:1 से 9:1 दिखाते हैं, लेकिन केवल तभी जब कई वर्षों तक कायम रहे
C
SPI only improves developer productivity; it has no measurable impact on product quality एसपीआई केवल डेवलपर उत्पादकता में सुधार करता है; इसका उत्पाद की गुणवत्ता पर कोई मापने योग्य प्रभाव नहीं पड़ता है
D
SPI ROI can be achieved within the first month of implementation एसपीआई आरओआई कार्यान्वयन के पहले महीने के भीतर हासिल किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SPI (as in CMM/CMMI improvement initiatives) requires sustained investment in training, tools, and cultural change. SEI studies and industry surveys consistently show positive ROI (3:1 to 9:1 over 3-5 years) through defect reduction, shorter cycles, and predictable delivery — but only when organisations commit long-term rather than treating it as a short-term project.
व्याख्या (हिन्दी) एसपीआई (सीएमएम/सीएमएमआई सुधार पहल की तरह) को प्रशिक्षण, उपकरण और सांस्कृतिक परिवर्तन में निरंतर निवेश की आवश्यकता होती है। एसईआई अध्ययन और उद्योग सर्वेक्षण लगातार दोष में कमी, छोटे चक्र और पूर्वानुमानित डिलीवरी के माध्यम से सकारात्मक आरओआई (3-5 वर्षों में 3:1 से 9:1) दिखाते हैं - लेकिन केवल तब जब संगठन इसे अल्पकालिक परियोजना के रूप में मानने के बजाय दीर्घकालिक प्रतिबद्ध होते हैं।
285
EN + हिं Medium
GB What is the 'DevOps' movement and how does it extend traditional software process models?
IN 'डेवऑप्स' आंदोलन क्या है और यह पारंपरिक सॉफ्टवेयर प्रक्रिया मॉडल का विस्तार कैसे करता है?
A
DevOps is a specific programming methodology for cloud-native applications only DevOps केवल क्लाउड-नेटिव अनुप्रयोगों के लिए एक विशिष्ट प्रोग्रामिंग पद्धति है
B
DevOps extends the software lifecycle by unifying development and operations, enabling continuous delivery through automation of build, test, and deployment — breaking the traditional handoff barrier between dev and ops teams DevOps विकास और संचालन को एकीकृत करके सॉफ़्टवेयर जीवनचक्र का विस्तार करता है, निर्माण, परीक्षण और तैनाती के स्वचालन के माध्यम से निरंतर वितरण को सक्षम करता है - देव और ऑप्स टीमों के बीच पारंपरिक हैंडऑफ़ बाधा को तोड़ता है।
C
DevOps replaces software architecture with infrastructure-as-code and requires no design phase DevOps सॉफ़्टवेयर आर्किटेक्चर को इंफ्रास्ट्रक्चर-ए-कोड से बदल देता है और इसके लिए किसी डिज़ाइन चरण की आवश्यकता नहीं होती है
D
DevOps is only applicable to startups; enterprises cannot adopt it due to regulatory requirements DevOps केवल स्टार्टअप्स पर लागू है; नियामक आवश्यकताओं के कारण उद्यम इसे नहीं अपना सकते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) DevOps bridges the development-operations silos that traditional models left intact. By automating the entire pipeline (CI/CD/CD) and fostering shared ownership of production, DevOps enables organisations to deploy multiple times per day rather than quarterly, dramatically accelerating feedback loops and reducing mean time to recover from failures.
व्याख्या (हिन्दी) DevOps उन विकास-संचालन साइलो को पाटता है जिन्हें पारंपरिक मॉडल बरकरार रखते हैं। संपूर्ण पाइपलाइन (सीआई/सीडी/सीडी) को स्वचालित करके और उत्पादन के साझा स्वामित्व को बढ़ावा देकर, डेवऑप्स संगठनों को त्रैमासिक के बजाय प्रति दिन कई बार तैनात करने में सक्षम बनाता है, नाटकीय रूप से फीडबैक लूप में तेजी लाता है और विफलताओं से उबरने के लिए औसत समय को कम करता है।
271–285 of 647