Software Engineering — MCQ Practice

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

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2476
EN + हिं Easy
GB What is 'program comprehension' in maintenance and why does it consume the majority of maintenance effort?
IN रखरखाव में 'प्रोग्राम कॉम्प्रिहेंशन' क्या है और यह अधिकांश रखरखाव प्रयास का उपभोग क्यों करता है?
A
Formal documentation process preceding any code change किसी भी कोड परिवर्तन से पहले औपचारिक दस्तावेज़ीकरण प्रक्रिया
B
The cognitive process of understanding existing code well enough to modify it safely; consumes 50-60% of maintenance effort because code was not written to be understood — names are ambiguous, logic implicit, and decision rationale absent मौजूदा कोड को इतनी अच्छी तरह समझने की संज्ञानात्मक प्रक्रिया कि उसे सुरक्षित रूप से संशोधित किया जा सके; रखरखाव प्रयास का 50-60% खर्च होता है क्योंकि कोड को समझने के लिए नहीं लिखा गया था - नाम अस्पष्ट हैं, तर्क अंतर्निहित हैं, और निर्णय तर्क अनुपस्थित हैं
C
Only necessary for code written more than five years ago केवल पाँच वर्ष से अधिक पहले लिखे गए कोड के लिए आवश्यक है
D
Converting natural language requirements into formal specifications प्राकृतिक भाषा आवश्यकताओं को औपचारिक विशिष्टताओं में परिवर्तित करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Erlikh (2000) found comprehension accounts for approximately 50% of maintenance cost. Developers read code far more than they write it. Poor naming, absent comments, and no documentation of design rationale force maintainers to reverse-engineer intent before any change. This is why coding standards have outsized ROI in long-lived systems.
व्याख्या (हिन्दी) एर्लिख (2000) ने पाया कि रखरखाव लागत का लगभग 50% समझ से आता है। डेवलपर्स कोड को लिखने से कहीं अधिक पढ़ते हैं। ख़राब नामकरण, अनुपस्थित टिप्पणियाँ, और डिज़ाइन तर्क का कोई दस्तावेज़ीकरण नहीं होने से रखरखाव करने वालों को किसी भी बदलाव से पहले रिवर्स-इंजीनियर इरादे के लिए मजबूर होना पड़ता है। यही कारण है कि कोडिंग मानकों ने लंबे समय तक चलने वाले सिस्टम में आरओआई को बढ़ा दिया है।
2477
EN + हिं Medium
GB What is 'software process capability' and how does CMM level 3 differ from level 2?
IN 'सॉफ़्टवेयर प्रक्रिया क्षमता' क्या है और सीएमएम स्तर 3, स्तर 2 से किस प्रकार भिन्न है?
A
Level 3 has more developers than level 2 लेवल 3 में लेवल 2 की तुलना में अधिक डेवलपर हैं
B
At level 2 processes are project-specific and repeatable; at level 3 processes are organisation-wide, standardised, and defined — enabling consistent performance across all projects स्तर 2 पर प्रक्रियाएँ परियोजना-विशिष्ट और दोहराने योग्य हैं; स्तर 3 पर प्रक्रियाएं संगठन-व्यापी, मानकीकृत और परिभाषित हैं - सभी परियोजनाओं में लगातार प्रदर्शन को सक्षम करना
C
Level 3 requires automated testing tools; level 2 only requires manual testing स्तर 3 के लिए स्वचालित परीक्षण उपकरणों की आवश्यकता होती है; लेवल 2 के लिए केवल मैन्युअल परीक्षण की आवश्यकता है
D
CMM levels 2 and 3 are identical; only the assessment cost differs सीएमएम स्तर 2 और 3 समान हैं; केवल मूल्यांकन लागत भिन्न है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CMM Level 2 (Repeatable) means basic project management is in place and similar projects can repeat past successes. Level 3 (Defined) means the organisation has a documented standard process tailored per project — enabling consistent engineering practices across the entire organisation, not just within individual projects.
व्याख्या (हिन्दी) सीएमएम लेवल 2 (दोहराने योग्य) का मतलब है कि बुनियादी परियोजना प्रबंधन मौजूद है और इसी तरह की परियोजनाएं पिछली सफलताओं को दोहरा सकती हैं। लेवल 3 (परिभाषित) का मतलब है कि संगठन के पास प्रति प्रोजेक्ट तैयार की गई एक प्रलेखित मानक प्रक्रिया है - जो केवल व्यक्तिगत परियोजनाओं के भीतर ही नहीं, बल्कि पूरे संगठन में लगातार इंजीनियरिंग प्रथाओं को सक्षम करती है।
2478
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 चैनल) बढ़ाए जाते हैं, जिससे कोई लाभ दिखने से पहले अस्थायी रूप से उत्पादकता कम हो जाती है।
2479
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.
व्याख्या (हिन्दी) वृद्धिशील विकास एक स्थिर आधार में नई सुविधाएँ जोड़ता है; प्रत्येक वृद्धि एक टुकड़ा जोड़ने वाला एक छोटा झरना है। पुनरावृत्तीय विकास पूरे सिस्टम के किसी न किसी संस्करण से शुरू होता है और धीरे-धीरे इसमें सुधार करता है। चंचल तरीके अक्सर दोनों को जोड़ते हैं - मौजूदा सुविधाओं को पुनरावृत्तीय रूप से परिष्कृत करते हुए वृद्धिशील रूप से सुविधाएँ जोड़ते हैं।
2480
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.
व्याख्या (हिन्दी) सॉफ़्टवेयर उत्पाद श्रृंखलाएँ (क्लेमेंट्स और नॉर्थ्रॉप) व्यवस्थित पुन: उपयोग के माध्यम से प्रतिस्पर्धात्मक लाभ पैदा करती हैं: प्रत्येक उत्पाद को खरोंच से बनाने के बजाय, संगठन उत्पादों के एक परिवार में साझा किए गए मुख्य परिसंपत्ति आधार (वास्तुकला, पुन: प्रयोज्य घटकों, प्रक्रियाओं) में निवेश करते हैं, जिससे प्रत्येक उत्पाद प्रकार के लिए लागत और समय-समय पर बाजार में कमी आती है।
2481
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).
व्याख्या (हिन्दी) एक सिस्टम अत्यधिक विश्वसनीय हो सकता है (शायद ही कभी विफल होता है) लेकिन इसकी उपलब्धता कम होती है (दुर्लभ विफलताओं के बाद पुनरारंभ होने में लंबा समय लगता है)। इसके विपरीत, बार-बार छोटी विफलताओं वाली प्रणाली में अभी भी उच्च उपलब्धता हो सकती है। विश्वसनीयता विफलता की आवृत्ति के बारे में है; उपलब्धता विफलता की आवृत्ति और पुनर्प्राप्ति समय दोनों को ध्यान में रखती है: उपलब्धता = एमटीटीएफ / (एमटीटीएफ + एमटीटीआर)।
2482
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.
व्याख्या (हिन्दी) वास्तुशिल्प निर्णय रणनीतिक हैं और उन्हें बदलना महंगा है: वास्तुशिल्प शैली का विकल्प (माइक्रोसर्विसेज बनाम मोनोलिथ), परिनियोजन मॉडल, अंतर-सिस्टम प्रोटोकॉल। डिज़ाइन निर्णय सामरिक और स्थानीय होते हैं: वर्ग संरचना, एल्गोरिदम विकल्प, एक घटक के भीतर डेटा प्रारूप। ख़राब वास्तुकला की भरपाई अच्छे डिज़ाइन से नहीं की जा सकती।
2483
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.
व्याख्या (हिन्दी) कार्यात्मक परीक्षण सत्यापित करते हैं कि सिस्टम 'क्या' करता है (दिए गए इनपुट के लिए सही आउटपुट)। गैर-कार्यात्मक परीक्षण यह सत्यापित करते हैं कि यह 'कितनी अच्छी तरह' काम करता है - लोड के तहत प्रदर्शन, हमलों के खिलाफ सुरक्षा, वास्तविक उपयोगकर्ताओं के साथ प्रयोज्य। इनके लिए यथार्थवादी वातावरण, विशेषज्ञ उपकरणों की आवश्यकता होती है और इन्हें पृथक इकाई परीक्षणों में विघटित नहीं किया जा सकता है।
2484
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.
व्याख्या (हिन्दी) शमन सक्रिय है: संभावना या गंभीरता को कम करने के लिए अब की गई कार्रवाई (उदाहरण के लिए, आवश्यकताओं की अनिश्चितता को कम करने के लिए प्रोटोटाइप जोड़ना)। आकस्मिकता प्रतिक्रियाशील होती है: जब कोई जोखिम घटना घटित होती है तो एक पूर्व-नियोजित प्रतिक्रिया लागू होती है (उदाहरण के लिए, यदि एक प्रमुख निर्भरता देर से होती है तो एक आरक्षित शेड्यूल बफर सक्रिय होता है)। सर्वोत्तम अभ्यास दोनों का एक साथ उपयोग करना है।
2485
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) ऑडिटिंग - बेसलाइन का सत्यापन सहमत सामग्री को दर्शाता है।
2486
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.
व्याख्या (हिन्दी) क्लीनरूम (मिल्स, डायर, लिंगर) विनिर्देशन और डिजाइन के लिए औपचारिक तरीकों का उपयोग करता है, जो सांख्यिकीय उपयोग-आधारित परीक्षण के साथ संयुक्त होता है जो परिचालन प्रोफ़ाइल से परीक्षण मामले उत्पन्न करता है। पारंपरिक परीक्षण के विपरीत, क्लीनरूम परीक्षण परिणामों के आधार पर विफलता के औसत समय का एक सांख्यिकीय प्रमाण पत्र प्रदान करता है - औपचारिक विश्वसनीयता कथनों को सक्षम करता है।
2487
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+) ने कई अनुशासन-विशिष्ट सीएमएम को समेकित किया और संगठनों को स्वतंत्र रूप से चयनित प्रक्रिया क्षेत्रों में सुधार करने की अनुमति देते हुए एक निरंतर प्रतिनिधित्व पेश किया, जिससे यह इंजीनियरिंग विषयों पर लागू हो गया।
2488
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.
व्याख्या (हिन्दी) क्लासिक प्रोटोटाइप विफलता तब होती है जब प्रबंधन एक कार्यशील डेमो देखता है और वास्तुशिल्प पुन: कार्य के बिना इसे शिपिंग करने पर जोर देता है। प्रोटोटाइप जानबूझकर त्वरित और गंदे होते हैं - वे त्रुटि प्रबंधन, सुरक्षा और स्केलेबिलिटी पर ध्यान नहीं देते हैं। उन्हें शिपिंग करने पर बड़े पैमाने पर तकनीकी ऋण लगता है और अक्सर बाद में पूर्ण पुनर्लेखन की आवश्यकता होती है।
2489
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.
व्याख्या (हिन्दी) वी-मॉडल (सत्यापन और सत्यापन मॉडल) प्रत्येक बाईं ओर के विकास चरण को दाईं ओर के परीक्षण चरण के साथ जोड़ता है। सिस्टम आवश्यकताएँ स्वीकृति परीक्षण के साथ जोड़ी जाती हैं; सिस्टम परीक्षण के साथ वास्तुकला; एकीकरण परीक्षण के साथ विस्तृत डिज़ाइन; यूनिट परीक्षण के साथ कोड। परीक्षण की योजना विकास के साथ-साथ शुरू होती है, परीक्षण योग्यता के मुद्दों को पहले ही पकड़ लेती है।
2490
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) इसे उलट देता है: तारीख अचल है, इसलिए दायरे पर बातचीत की जाती है। सुविधाओं को अवश्य-होना चाहिए, होना चाहिए, हो सकता है, नहीं होना चाहिए के रूप में प्राथमिकता दी जाती है। यदि समय कम हो जाता है, तो 'नॉट-हैव' और 'कैड-हैव' सुविधाएँ कम हो जाती हैं - मुख्य मूल्य की समय पर डिलीवरी सुनिश्चित करना।
2476–2490 of 2726