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
196
EN + हिं Medium
GB Which factor does NOT directly influence the unadjusted function point count in Function Point Analysis?
IN फ़ंक्शन बिंदु विश्लेषण में कौन सा कारक असमायोजित फ़ंक्शन बिंदु गणना को सीधे प्रभावित नहीं करता है?
A
Number of external inputs बाह्य इनपुट की संख्या
B
Number of internal logical files आंतरिक तार्किक फ़ाइलों की संख्या
C
Number of external outputs बाह्य आउटपुट की संख्या
D
Programming language used for implementation कार्यान्वयन के लिए प्रोग्रामिंग भाषा का उपयोग किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Unadjusted Function Points are derived from five functional components: external inputs, outputs, inquiries, internal logical files, and external interface files. The programming language affects productivity but not the functional size measurement.
व्याख्या (हिन्दी) असमायोजित फ़ंक्शन पॉइंट पांच कार्यात्मक घटकों से प्राप्त होते हैं: बाहरी इनपुट, आउटपुट, पूछताछ, आंतरिक तार्किक फ़ाइलें और बाहरी इंटरफ़ेस फ़ाइलें। प्रोग्रामिंग भाषा उत्पादकता को प्रभावित करती है लेकिन कार्यात्मक आकार माप को नहीं।
197
EN + हिं Easy
GB What does 'technical debt' specifically imply in the context of long-running software projects?
IN लंबे समय से चलने वाली सॉफ़्टवेयर परियोजनाओं के संदर्भ में 'तकनीकी ऋण' का विशेष रूप से क्या अर्थ है?
A
Financial cost of purchasing software licenses सॉफ़्टवेयर लाइसेंस खरीदने की वित्तीय लागत
B
Accumulated suboptimal design decisions for short-term gain that must be refactored at greater future cost अल्पकालिक लाभ के लिए संचित उप-इष्टतम डिजाइन निर्णय जिन्हें भविष्य में अधिक लागत पर दोबारा तैयार किया जाना चाहिए
C
Outstanding unresolved bug reports in the backlog बैकलॉग में बकाया अनसुलझे बग रिपोर्ट
D
Lag between software release and user adoption सॉफ़्टवेयर रिलीज़ और उपयोगकर्ता द्वारा अपनाए जाने के बीच अंतराल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Technical debt (Ward Cunningham) is the implied cost of rework caused by choosing quick-and-easy solutions over better long-term approaches. Like financial debt, it accrues interest — the longer it is left unaddressed, the more expensive it becomes to fix.
व्याख्या (हिन्दी) तकनीकी ऋण (वार्ड कनिंघम) बेहतर दीर्घकालिक दृष्टिकोण की तुलना में त्वरित और आसान समाधान चुनने के कारण होने वाली पुन: कार्य की निहित लागत है। वित्तीय ऋण की तरह, इस पर ब्याज लगता है - जितना अधिक समय तक इसका समाधान नहीं किया जाता है, इसे ठीक करना उतना ही महंगा हो जाता है।
198
EN + हिं Medium
GB According to Lehman's Law of Continuing Change, what must happen to an E-type program?
IN लेहमैन के सतत परिवर्तन के नियम के अनुसार, ई-प्रकार के कार्यक्रम का क्या होना चाहिए?
A
Its complexity must be actively reduced each release प्रत्येक रिलीज़ में इसकी जटिलता को सक्रिय रूप से कम किया जाना चाहिए
B
It must be continually adapted or it becomes progressively less satisfactory in its real-world environment इसे लगातार अनुकूलित किया जाना चाहिए अन्यथा यह अपने वास्तविक दुनिया के वातावरण में उत्तरोत्तर कम संतोषजनक होता जाएगा
C
Its rate of change is proportional to team size इसके परिवर्तन की दर टीम के आकार के समानुपाती होती है
D
Its functionality grows at a constant rate इसकी कार्यक्षमता निरंतर दर से बढ़ती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Lehman's First Law states that an E-type (embedded) system must be continually adapted to remain satisfactory in its changing operational environment. Failure to adapt causes the system to become increasingly unsatisfactory and eventually obsolete.
व्याख्या (हिन्दी) लेहमैन का पहला कानून कहता है कि एक ई-प्रकार (एम्बेडेड) प्रणाली को अपने बदलते परिचालन वातावरण में संतोषजनक बने रहने के लिए लगातार अनुकूलित किया जाना चाहिए। अनुकूलन में विफलता के कारण प्रणाली तेजी से असंतोषजनक और अंततः अप्रचलित हो जाती है।
199
EN + हिं Medium
GB Which software quality attribute is most directly compromised by high coupling between modules?
IN मॉड्यूल के बीच उच्च युग्मन द्वारा किस सॉफ़्टवेयर गुणवत्ता विशेषता से सबसे अधिक सीधे समझौता किया जाता है?
A
Portability पोर्टेबिलिटी
B
Maintainability रख-रखाव
C
Usability प्रयोज्य
D
Reliability विश्वसनीयता
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) High coupling means modules are tightly dependent on each other's internals, so a change in one requires corresponding changes in others. This directly undermines maintainability because isolated modifications, testing, and replacement of modules become difficult.
व्याख्या (हिन्दी) उच्च युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के अंदरूनी हिस्सों पर मजबूती से निर्भर हैं, इसलिए एक में बदलाव के लिए दूसरों में इसी तरह के बदलाव की आवश्यकता होती है। यह सीधे तौर पर रखरखाव को कमजोर करता है क्योंकि अलग-अलग संशोधन, परीक्षण और मॉड्यूल का प्रतिस्थापन मुश्किल हो जाता है।
200
EN + हिं Easy
GB In 'No Silver Bullet', Fred Brooks distinguishes essential complexity from accidental complexity. What is essential complexity?
IN 'नो सिल्वर बुलेट' में, फ्रेड ब्रूक्स आवश्यक जटिलता को आकस्मिक जटिलता से अलग करते हैं। आवश्यक जटिलता क्या है?
A
Complexity introduced by poor programmers खराब प्रोग्रामर द्वारा पेश की गई जटिलता
B
Complexity inherent to the problem being solved that cannot be designed away हल की जा रही समस्या में अंतर्निहित जटिलता जिसे दूर नहीं किया जा सकता
C
Complexity arising from tools and languages उपकरणों और भाषाओं से उत्पन्न होने वाली जटिलता
D
Complexity that applies only to OS development जटिलता जो केवल ओएस विकास पर लागू होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Brooks distinguished essential complexity (inherent to the problem — it cannot be designed away without losing functionality) from accidental complexity (arising from representation choices, tools, and processes — it can potentially be reduced).
व्याख्या (हिन्दी) ब्रूक्स ने आवश्यक जटिलता (समस्या में निहित - इसे कार्यक्षमता खोए बिना डिज़ाइन नहीं किया जा सकता) को आकस्मिक जटिलता (प्रतिनिधित्व विकल्पों, उपकरणों और प्रक्रियाओं से उत्पन्न - इसे संभावित रूप से कम किया जा सकता है) से अलग किया।
201
EN + हिं Medium
GB In COCOMO II, what do 'scale factors' primarily represent?
IN COCOMO II में, 'स्केल कारक' मुख्य रूप से क्या दर्शाते हैं?
A
Ratio of actual to estimated lines of code कोड की वास्तविक और अनुमानित पंक्तियों का अनुपात
B
Factors affecting the exponential scaling of effort with project size such as team cohesion and process maturity प्रोजेक्ट आकार के साथ प्रयास की घातीय स्केलिंग को प्रभावित करने वाले कारक जैसे टीम सामंजस्य और प्रक्रिया परिपक्वता
C
Multiplier to convert LOC to function points LOC को फ़ंक्शन पॉइंट में बदलने के लिए गुणक
D
Cost per developer per month प्रति डेवलपर प्रति माह लागत
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) COCOMO II scale factors influence the exponent in the effort equation, controlling how effort scales non-linearly with size. Higher scale factors increase the exponent, making large projects disproportionately more costly.
व्याख्या (हिन्दी) COCOMO II पैमाने के कारक प्रयास समीकरण में घातांक को प्रभावित करते हैं, यह नियंत्रित करते हैं कि प्रयास आकार के साथ गैर-रैखिक रूप से कैसे बढ़ता है। उच्च पैमाने के कारक घातांक को बढ़ाते हैं, जिससे बड़ी परियोजनाएं अनुपातहीन रूप से अधिक महंगी हो जाती हैं।
202
EN + हिं Easy
GB Which of the following best exemplifies a 'wicked problem' in software engineering?
IN निम्नलिखित में से कौन सॉफ्टवेयर इंजीनियरिंग में 'दुष्ट समस्या' का सबसे अच्छा उदाहरण है?
A
Implementing a well-defined sorting algorithm in a new language एक नई भाषा में एक अच्छी तरह से परिभाषित सॉर्टिंग एल्गोरिदम लागू करना
B
Designing a national healthcare system where requirements are contradictory and no clear solution exists एक ऐसी राष्ट्रीय स्वास्थ्य देखभाल प्रणाली तैयार करना जहां आवश्यकताएं विरोधाभासी हों और कोई स्पष्ट समाधान मौजूद न हो
C
Fixing a null pointer exception in a deployed web application तैनात वेब एप्लिकेशन में एक शून्य सूचक अपवाद को ठीक करना
D
Migrating a database following a documented migration plan दस्तावेज़ीकृत माइग्रेशन योजना के बाद डेटाबेस को माइग्रेट करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Wicked problems (Rittel and Webber) have no definitive formulation, no stopping rule, and solutions that are good-or-bad rather than true/false. Complex sociotechnical systems like national healthcare platforms exemplify this.
व्याख्या (हिन्दी) दुष्ट समस्याओं (रिटेल और वेबर) का कोई निश्चित सूत्रीकरण नहीं है, कोई रोकने का नियम नहीं है, और समाधान सही/गलत के बजाय अच्छे या बुरे हैं। राष्ट्रीय स्वास्थ्य सेवा मंच जैसी जटिल सामाजिक-तकनीकी प्रणालियाँ इसका उदाहरण हैं।
203
EN + हिं Medium
GB Why can historical analogy cost estimation produce highly inaccurate results?
IN ऐतिहासिक सादृश्य लागत अनुमान अत्यधिक गलत परिणाम क्यों उत्पन्न कर सकता है?
A
Historical projects always use different programming languages ऐतिहासिक परियोजनाएँ हमेशा विभिन्न प्रोग्रामिंग भाषाओं का उपयोग करती हैं
B
Subtle differences in team skill, domain complexity, technology, and organisational context between reference and new project are hard to quantify and often overlooked संदर्भ और नई परियोजना के बीच टीम कौशल, डोमेन जटिलता, प्रौद्योगिकी और संगठनात्मक संदर्भ में सूक्ष्म अंतर को मापना कठिन है और अक्सर इसे अनदेखा कर दिया जाता है।
C
Historical data is never in a compatible format ऐतिहासिक डेटा कभी भी संगत प्रारूप में नहीं होता है
D
Analogy requires at least ten reference projects सादृश्य के लिए कम से कम दस संदर्भ परियोजनाओं की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Analogy-based estimation assumes the new project is sufficiently similar to historical ones. Even seemingly similar projects differ in team experience, culture, technology maturity, and domain nuances — factors difficult to capture quantitatively, leading to systematic bias.
व्याख्या (हिन्दी) सादृश्य-आधारित अनुमान मानता है कि नई परियोजना ऐतिहासिक परियोजनाओं के समान ही है। यहां तक ​​​​कि प्रतीत होता है कि समान परियोजनाएं टीम के अनुभव, संस्कृति, प्रौद्योगिकी परिपक्वता और डोमेन बारीकियों में भिन्न होती हैं - कारकों को मात्रात्मक रूप से पकड़ना मुश्किल होता है, जिससे व्यवस्थित पूर्वाग्रह होता है।
204
EN + हिं Medium
GB What fundamental problem did the 'software crisis' of the 1960s highlight?
IN 1960 के दशक के 'सॉफ्टवेयर संकट' ने किस मूलभूत समस्या को उजागर किया?
A
Insufficient hardware to run large software systems बड़े सॉफ़्टवेयर सिस्टम को चलाने के लिए अपर्याप्त हार्डवेयर
B
Inability of informal ad-hoc methods to reliably deliver large software on time, within budget, and with acceptable quality बड़े सॉफ़्टवेयर को समय पर, बजट के भीतर और स्वीकार्य गुणवत्ता के साथ विश्वसनीय रूप से वितरित करने में अनौपचारिक तदर्थ तरीकों की असमर्थता
C
Lack of qualified assembly language programmers योग्य असेम्बली भाषा प्रोग्रामरों की कमी
D
High cost of computer time compared to programmer salaries प्रोग्रामर के वेतन की तुलना में कंप्यूटर समय की उच्च लागत
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 1960s software crisis arose because projects regularly overran budgets, missed deadlines, and delivered unreliable products. This drove the 1968 NATO conference and the subsequent discipline of software engineering.
व्याख्या (हिन्दी) 1960 के दशक का सॉफ़्टवेयर संकट इसलिए उत्पन्न हुआ क्योंकि परियोजनाएँ नियमित रूप से बजट से आगे निकल गईं, समय सीमा चूक गईं और अविश्वसनीय उत्पाद वितरित किए गए। इसने 1968 के नाटो सम्मेलन और उसके बाद सॉफ्टवेयर इंजीनियरिंग के अनुशासन को आगे बढ़ाया।
205
EN + हिं Medium
GB Which process model is most appropriate when requirements are poorly understood and likely to change significantly?
IN जब आवश्यकताओं को कम समझा जाता है और महत्वपूर्ण रूप से बदलने की संभावना होती है तो कौन सा प्रक्रिया मॉडल सबसे उपयुक्त होता है?
A
Waterfall model झरना मॉडल
B
V-model वि मॉडल
C
Evolutionary/Iterative model विकासवादी/पुनरावृत्तीय मॉडल
D
Formal transformation model औपचारिक परिवर्तन मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Evolutionary/iterative models are designed for unstable requirements. They deliver working increments, gather feedback, and refine requirements iteratively. Waterfall and V-model require stable requirements upfront.
व्याख्या (हिन्दी) विकासवादी/पुनरावृत्त मॉडल अस्थिर आवश्यकताओं के लिए डिज़ाइन किए गए हैं। वे कामकाजी वेतन वृद्धि प्रदान करते हैं, फीडबैक एकत्र करते हैं और आवश्यकताओं को क्रमिक रूप से परिष्कृत करते हैं। वॉटरफ़ॉल और वी-मॉडल को पहले से ही स्थिर आवश्यकताओं की आवश्यकता होती है।
206
EN + हिं Easy
GB What is the core criticism of using Lines of Code (LOC) as a software productivity metric?
IN सॉफ्टवेयर उत्पादकता मीट्रिक के रूप में लाइन्स ऑफ कोड (एलओसी) का उपयोग करने की मुख्य आलोचना क्या है?
A
LOC cannot be counted automatically LOC की गणना स्वचालित रूप से नहीं की जा सकती
B
LOC incentivises verbose redundant code, penalises elegant solutions, varies with language, and counts non-functional code एलओसी वर्बोज़ अनावश्यक कोड को प्रोत्साहित करता है, सुरुचिपूर्ण समाधानों को दंडित करता है, भाषा के साथ बदलता रहता है, और गैर-कार्यात्मक कोड को गिनता है
C
LOC only applies to procedural languages LOC केवल प्रक्रियात्मक भाषाओं पर लागू होती है
D
LOC is not recognised by any international standard एलओसी को किसी भी अंतरराष्ट्रीय मानक द्वारा मान्यता प्राप्त नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) LOC is a poor productivity metric because it rewards code volume over quality. A developer writing 500 elegant tested lines contributes more than one writing 2,000 bloated lines. It also varies across languages and counts blank lines, comments, and boilerplate.
व्याख्या (हिन्दी) LOC एक खराब उत्पादकता मीट्रिक है क्योंकि यह गुणवत्ता की तुलना में कोड वॉल्यूम को अधिक महत्व देता है। 500 सुंदर परीक्षणित पंक्तियाँ लिखने वाला एक डेवलपर 2,000 फूली हुई पंक्तियाँ लिखने से अधिक का योगदान देता है। यह विभिन्न भाषाओं में भी भिन्न होता है और रिक्त पंक्तियों, टिप्पणियों और बॉयलरप्लेट को गिनता है।
207
EN + हिं Medium
GB In Rapid Application Development (RAD), which condition is MOST critical for successful application?
IN रैपिड एप्लिकेशन डेवलपमेंट (आरएडी) में, सफल एप्लिकेशन के लिए कौन सी स्थिति सबसे महत्वपूर्ण है?
A
Project must use only open-source tools प्रोजेक्ट को केवल ओपन-सोर्स टूल का उपयोग करना चाहिए
B
Active and continuous user involvement throughout the development cycle पूरे विकास चक्र में सक्रिय और निरंतर उपयोगकर्ता भागीदारी
C
Development team must have fewer than five members विकास दल में पाँच से कम सदस्य होने चाहिए
D
System must use only visual programming tools सिस्टम को केवल विज़ुअल प्रोग्रामिंग टूल का उपयोग करना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RAD depends on rapid prototyping and iterative feedback cycles with users. Without active, continuous user participation to review prototypes and clarify requirements, RAD devolves into unguided iteration producing a system that fails to meet actual needs.
व्याख्या (हिन्दी) आरएडी उपयोगकर्ताओं के साथ तेजी से प्रोटोटाइप और पुनरावृत्त प्रतिक्रिया चक्र पर निर्भर करता है। प्रोटोटाइप की समीक्षा करने और आवश्यकताओं को स्पष्ट करने के लिए सक्रिय, निरंतर उपयोगकर्ता भागीदारी के बिना, आरएडी एक ऐसी प्रणाली का निर्माण करने वाले अनिर्देशित पुनरावृत्ति में बदल जाता है जो वास्तविक जरूरतों को पूरा करने में विफल रहता है।
208
EN + हिं Medium
GB What distinguishes a 'process model' from a 'process' in software engineering?
IN सॉफ़्टवेयर इंजीनियरिंग में 'प्रक्रिया मॉडल' को 'प्रक्रिया' से क्या अलग करता है?
A
A process model is theoretical; a process is the actual enactment of activities in a specific project context एक प्रक्रिया मॉडल सैद्धांतिक है; एक प्रक्रिया एक विशिष्ट परियोजना संदर्भ में गतिविधियों का वास्तविक अधिनियमन है
B
A process model includes budget estimates; a process does not एक प्रक्रिया मॉडल में बजट अनुमान शामिल होते हैं; एक प्रक्रिया नहीं है
C
A process model applies to large projects only एक प्रक्रिया मॉडल केवल बड़ी परियोजनाओं पर लागू होता है
D
A process is defined by management; process model by developers एक प्रक्रिया प्रबंधन द्वारा परिभाषित की जाती है; डेवलपर्स द्वारा प्रक्रिया मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A process model is an abstract generalised framework (Waterfall, Spiral) describing the typical structure of a development approach. A process is the specific instantiation of that model in a real project — tailored and enacted within actual resource and organisational constraints.
व्याख्या (हिन्दी) एक प्रक्रिया मॉडल एक अमूर्त सामान्यीकृत ढांचा (झरना, सर्पिल) है जो विकास दृष्टिकोण की विशिष्ट संरचना का वर्णन करता है। एक प्रक्रिया एक वास्तविक परियोजना में उस मॉडल की विशिष्ट तात्कालिकता है - वास्तविक संसाधन और संगठनात्मक बाधाओं के भीतर तैयार और अधिनियमित।
209
EN + हिं Medium
GB Which software development model explicitly incorporates risk analysis as a repeating activity in each iteration?
IN कौन सा सॉफ़्टवेयर विकास मॉडल स्पष्ट रूप से प्रत्येक पुनरावृत्ति में दोहराई जाने वाली गतिविधि के रूप में जोखिम विश्लेषण को शामिल करता है?
A
Waterfall model झरना मॉडल
B
Incremental model वृद्धिशील मॉडल
C
Spiral model सर्पिल मॉडल
D
Prototype model प्रोटोटाइप मॉडल
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Barry Boehm's Spiral model is unique in making risk analysis an explicit quadrant in every iteration. Each spiral pass involves: planning, risk analysis and prototyping, engineering, and customer evaluation — making it ideal for large high-risk projects.
व्याख्या (हिन्दी) बैरी बोहेम का स्पाइरल मॉडल प्रत्येक पुनरावृत्ति में जोखिम विश्लेषण को एक स्पष्ट चतुर्थांश बनाने में अद्वितीय है। प्रत्येक सर्पिल पास में शामिल हैं: योजना, जोखिम विश्लेषण और प्रोटोटाइप, इंजीनियरिंग और ग्राहक मूल्यांकन - जो इसे बड़े उच्च जोखिम वाली परियोजनाओं के लिए आदर्श बनाता है।
210
EN + हिं Medium
GB In Unified Process (UP), what is the purpose of the 'Elaboration' phase?
IN एकीकृत प्रक्रिया (यूपी) में, 'विस्तार' चरण का उद्देश्य क्या है?
A
To deploy the final system and train users अंतिम प्रणाली को तैनात करना और उपयोगकर्ताओं को प्रशिक्षित करना
B
To establish project scope, eliminate highest-risk elements, define architecture baseline, and refine requirements परियोजना का दायरा स्थापित करने के लिए, उच्चतम जोखिम वाले तत्वों को खत्म करें, वास्तुकला आधार रेखा को परिभाषित करें और आवश्यकताओं को परिष्कृत करें
C
To decompose the system into modules and assign to developers सिस्टम को मॉड्यूल में विघटित करना और डेवलपर्स को सौंपना
D
To collect initial requirements through stakeholder interviews हितधारकों के साक्षात्कार के माध्यम से प्रारंभिक आवश्यकताएँ एकत्र करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In UP's Elaboration phase, the goal is to mitigate the project's top architectural risks by building an architectural prototype, refining and stabilising the use-case model, and establishing a stable baseline for construction.
व्याख्या (हिन्दी) यूपी के विस्तार चरण में, लक्ष्य एक वास्तुशिल्प प्रोटोटाइप का निर्माण, उपयोग-केस मॉडल को परिष्कृत और स्थिर करना और निर्माण के लिए एक स्थिर आधार रेखा स्थापित करके परियोजना के शीर्ष वास्तुशिल्प जोखिमों को कम करना है।
196–210 of 647