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
226
EN + हिं Easy
GB What is the 'cone of uncertainty' in agile estimation and what does it imply for release planning?
IN त्वरित अनुमान में 'अनिश्चितता का शंकु' क्या है और रिलीज़ योजना के लिए इसका क्या अर्थ है?
A
Physical area where developers can work without distractions भौतिक क्षेत्र जहां डेवलपर्स बिना ध्यान भटकाए काम कर सकते हैं
B
Project estimation uncertainty is highest at the start and narrows as the project progresses — early release commitments will have large uncertainty ranges परियोजना अनुमान की अनिश्चितता शुरुआत में सबसे अधिक होती है और जैसे-जैसे परियोजना आगे बढ़ती है, यह कम होती जाती है - प्रारंभिक रिलीज प्रतिबद्धताओं में अनिश्चितता की बड़ी सीमाएँ होंगी
C
Maximum team size beyond which Agile methods become ineffective अधिकतम टीम आकार जिसके आगे एजाइल विधियां अप्रभावी हो जाती हैं
D
Period between Sprint Planning and Sprint execution स्प्रिंट योजना और स्प्रिंट निष्पादन के बीच की अवधि
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Cone of Uncertainty shows initial estimates can vary by 4× in either direction. As design and implementation proceed, the range narrows. Agile teams address this by providing range estimates rather than point estimates and refining each sprint.
व्याख्या (हिन्दी) अनिश्चितता का शंकु दर्शाता है कि प्रारंभिक अनुमान किसी भी दिशा में 4× भिन्न हो सकते हैं। जैसे-जैसे डिज़ाइन और कार्यान्वयन आगे बढ़ता है, दायरा कम होता जाता है। फुर्तीली टीमें बिंदु अनुमान के बजाय सीमा अनुमान प्रदान करके और प्रत्येक स्प्रिंट को परिष्कृत करके इसका समाधान करती हैं।
227
EN + हिं Easy
GB In Kanban, what is a WIP limit and what systemic problem does it solve?
IN कानबन में, WIP सीमा क्या है और यह किस प्रणालीगत समस्या का समाधान करती है?
A
WIP limits restrict number of developers in the office at any time WIP सीमाएं किसी भी समय कार्यालय में डेवलपर्स की संख्या को सीमित करती हैं
B
WIP limits cap items in each workflow stage, exposing bottlenecks and preventing work piling up faster than it can be completed — solving multitasking overload and hidden queuing delays WIP प्रत्येक वर्कफ़्लो चरण में कैप आइटम को सीमित करता है, बाधाओं को उजागर करता है और काम को पूरा होने की तुलना में तेजी से जमा होने से रोकता है - मल्टीटास्किंग अधिभार और छिपी हुई कतार में देरी को हल करता है
C
WIP limits define maximum story point value for a single user story WIP सीमाएँ एकल उपयोगकर्ता कहानी के लिए अधिकतम कहानी बिंदु मान को परिभाषित करती हैं
D
WIP limits ensure only senior developers work on critical path items WIP सीमाएँ सुनिश्चित करती हैं कि केवल वरिष्ठ डेवलपर ही महत्वपूर्ण पथ आइटम पर काम करें
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) WIP limits are Kanban's core flow optimisation mechanism. When a stage hits its WIP limit, upstream workers must stop and help clear the bottleneck rather than adding more work — revealing systemic constraints per Little's Law and reducing context switching.
व्याख्या (हिन्दी) WIP सीमाएँ कानबन की मुख्य प्रवाह अनुकूलन तंत्र हैं। जब कोई चरण अपनी डब्ल्यूआईपी सीमा तक पहुंचता है, तो अपस्ट्रीम कार्यकर्ताओं को रुकना चाहिए और अधिक काम जोड़ने के बजाय बाधा को दूर करने में मदद करनी चाहिए - लिटिल के कानून के अनुसार प्रणालीगत बाधाओं को प्रकट करना और संदर्भ स्विचिंग को कम करना।
228
EN + हिं Medium
GB What is the critical difference between SAFe and LeSS in scaling Agile across multiple teams?
IN कई टीमों में एजाइल को बढ़ाने में SAFe और LeSS के बीच महत्वपूर्ण अंतर क्या है?
A
SAFe only works for software companies; LeSS for all industries SAFe केवल सॉफ्टवेयर कंपनियों के लिए काम करता है; सभी उद्योगों के लिए एलईएसएस
B
SAFe adds prescriptive structure (Program Increments, ARTs, hierarchical roles) to coordinate large organisations; LeSS deliberately minimises additional structure, preserving Scrum's simplicity through team self-organisation SAFe बड़े संगठनों के समन्वय के लिए निर्देशात्मक संरचना (कार्यक्रम वृद्धि, एआरटी, पदानुक्रमित भूमिकाएं) जोड़ता है; LeSS जानबूझकर अतिरिक्त संरचना को कम करता है, टीम स्व-संगठन के माध्यम से स्क्रम की सादगी को संरक्षित करता है
C
SAFe uses 3-month sprints; LeSS uses 1-week sprints SAFe 3 महीने की स्प्रिंट का उपयोग करता है; LeSS 1-सप्ताह की स्प्रिंट का उपयोग करता है
D
Both are identical differing only in ceremony terminology दोनों समान हैं, केवल समारोह शब्दावली में अंतर है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SAFe addresses enterprise scaling through formal structure — Program and Solution levels, Agile Release Trains, PI Planning. Critics argue this re-introduces bureaucracy. LeSS keeps Scrum intact and scales by having fewer larger feature teams sharing a single product backlog.
व्याख्या (हिन्दी) SAFe औपचारिक संरचना के माध्यम से उद्यम स्केलिंग को संबोधित करता है - कार्यक्रम और समाधान स्तर, एजाइल रिलीज़ ट्रेनें, पीआई योजना। आलोचकों का तर्क है कि यह नौकरशाही को फिर से प्रस्तुत करता है। LeSS एकल उत्पाद बैकलॉग को साझा करने वाली कम बड़ी फीचर टीमों के द्वारा स्क्रम को बरकरार रखता है और स्केल करता है।
229
EN + हिं Easy
GB What is 'continuous integration' in Agile development and what specific failure mode does it prevent?
IN एजाइल विकास में 'निरंतर एकीकरण' क्या है और यह किस विशिष्ट विफलता मोड को रोकता है?
A
Integrating new team members without formal onboarding औपचारिक ऑनबोर्डिंग के बिना नई टीम के सदस्यों को एकीकृत करना
B
Merging developers' code into a shared repository frequently with automated build/test verification — preventing 'integration hell' where long-lived branches diverge so far that merging becomes extremely complex स्वचालित बिल्ड/परीक्षण सत्यापन के साथ डेवलपर्स के कोड को एक साझा रिपॉजिटरी में बार-बार मर्ज करना - 'एकीकरण नरक' को रोकना जहां लंबे समय तक रहने वाली शाखाएं इतनी दूर तक अलग हो जाती हैं कि विलय बेहद जटिल हो जाता है
C
A deployment strategy releasing new features to users automatically without testing एक परिनियोजन रणनीति बिना परीक्षण के उपयोगकर्ताओं को स्वचालित रूप से नई सुविधाएँ जारी करती है
D
Integrating customer feedback sessions into the development calendar विकास कैलेंडर में ग्राहक प्रतिक्रिया सत्रों को एकीकृत करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CI prevents 'integration hell' — the painful experience of merging months of parallel development where teams have made incompatible changes. By integrating frequently with automated tests, conflicts are detected within hours of introduction when the context is fresh.
व्याख्या (हिन्दी) सीआई 'एकीकरण नरक' को रोकता है - समानांतर विकास के महीनों के विलय का दर्दनाक अनुभव जहां टीमों ने असंगत परिवर्तन किए हैं। स्वचालित परीक्षणों के साथ बार-बार एकीकरण करके, संदर्भ ताज़ा होने पर परिचय के कुछ घंटों के भीतर विरोधों का पता लगाया जाता है।
230
EN + हिं Medium
GB In XP, what is the purpose of pair programming and what does research indicate about its productivity impact?
IN एक्सपी में, जोड़ी प्रोग्रामिंग का उद्देश्य क्या है और अनुसंधान इसके उत्पादकता प्रभाव के बारे में क्या संकेत देता है?
A
Doubles productivity by having two developers work independently in parallel दो डेवलपर्स के समानांतर में स्वतंत्र रूप से काम करने से उत्पादकता दोगुनी हो जाती है
B
Two developers share one workstation — driver writes, navigator reviews real-time; research shows 15% overhead but significantly fewer defects, reducing total project cost दो डेवलपर्स एक वर्कस्टेशन साझा करते हैं - ड्राइवर लिखता है, नेविगेटर वास्तविक समय में समीक्षा करता है; शोध से पता चलता है कि 15% ओवरहेड है लेकिन काफी कम दोष हैं, जिससे कुल परियोजना लागत कम हो गई है
C
Requires two developers to independently implement same feature and choose the better one एक ही सुविधा को स्वतंत्र रूप से लागू करने और बेहतर को चुनने के लिए दो डेवलपर्स की आवश्यकता होती है
D
Only used for debugging; normal development is always solo in XP केवल डिबगिंग के लिए उपयोग किया जाता है; XP में सामान्य विकास हमेशा एकल होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Pair programming (Williams et al.) shows approximately 15% time overhead but 15–50% fewer defects. Since defect repair is the largest cost driver, the net economics are typically positive — with additional benefits of knowledge sharing and reduced bus factor.
व्याख्या (हिन्दी) जोड़ी प्रोग्रामिंग (विलियम्स एट अल.) लगभग 15% समय ओवरहेड लेकिन 15-50% कम दोष दिखाता है। चूंकि दोष की मरम्मत सबसे बड़ी लागत चालक है, इसलिए शुद्ध अर्थशास्त्र आम तौर पर सकारात्मक है - ज्ञान साझा करने के अतिरिक्त लाभ और कम बस कारक के साथ।
231
EN + हिं Medium
GB What is the 'Last Responsible Moment' principle in Lean Software Development and why is it valuable?
IN लीन सॉफ्टवेयर डेवलपमेंट में 'लास्ट रिस्पॉन्सिबल मोमेंट' सिद्धांत क्या है और यह मूल्यवान क्यों है?
A
The latest moment to escalate a project risk to senior management वरिष्ठ प्रबंधन के लिए परियोजना जोखिम बढ़ाने का नवीनतम क्षण
B
Delaying irreversible decisions until maximum information is available, keeping options open — reducing the cost of wrong decisions made prematurely on insufficient information अधिकतम जानकारी उपलब्ध होने तक अपरिवर्तनीय निर्णयों में देरी करना, विकल्प खुले रखना - अपर्याप्त जानकारी पर समय से पहले लिए गए गलत निर्णयों की लागत को कम करना
C
The deadline after which project must be cancelled regardless of completion वह समय सीमा जिसके बाद परियोजना पूरी होने की परवाह किए बिना रद्द कर दी जानी चाहिए
D
The final sprint where all remaining backlog items must be completed अंतिम स्प्रिंट जहां सभी शेष बैकलॉग आइटम को पूरा किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Last Responsible Moment (Poppendieck) recognises that premature decisions made under uncertainty incur high error costs. By deliberately keeping options open and deciding only when the decision must be made, teams make better decisions with more data.
व्याख्या (हिन्दी) द लास्ट रिस्पॉन्सिबल मोमेंट (पॉपेंडिएक) मानता है कि अनिश्चितता के तहत समय से पहले लिए गए निर्णयों में उच्च त्रुटि लागत होती है। जानबूझकर विकल्प खुले रखने और केवल तभी निर्णय लेने से जब निर्णय लिया जाना चाहिए, टीमें अधिक डेटा के साथ बेहतर निर्णय लेती हैं।
232
EN + हिं Easy
GB What is 'requirements creep' and what process practice most effectively controls it?
IN 'रिक्वायरमेंट्स क्रीप' क्या है और कौन सी प्रक्रिया अभ्यास इसे सबसे प्रभावी ढंग से नियंत्रित करती है?
A
Developers adding features without customer approval; controlled by daily standups डेवलपर्स ग्राहक की मंजूरी के बिना सुविधाएँ जोड़ रहे हैं; दैनिक स्टैंडअप द्वारा नियंत्रित
B
Uncontrolled addition of requirements after baseline without corresponding scope/budget/schedule adjustment; controlled through formal change control with impact analysis संबंधित दायरे/बजट/अनुसूची समायोजन के बिना बेसलाइन के बाद आवश्यकताओं का अनियंत्रित जोड़; प्रभाव विश्लेषण के साथ औपचारिक परिवर्तन नियंत्रण के माध्यम से नियंत्रित
C
Process of gradually making requirements more specific during elaboration विस्तार के दौरान आवश्यकताओं को धीरे-धीरे और अधिक विशिष्ट बनाने की प्रक्रिया
D
Inevitable and uncontrollable in any software project किसी भी सॉफ्टवेयर प्रोजेक्ट में अपरिहार्य और अनियंत्रित
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Requirements creep accumulates when stakeholders request changes informally after scope is agreed. Formal change control — requiring impact analysis on schedule, cost, and quality for every proposed change before approval — provides visibility and forces trade-off decisions.
व्याख्या (हिन्दी) जब हितधारक दायरे पर सहमति के बाद अनौपचारिक रूप से परिवर्तन का अनुरोध करते हैं तो आवश्यकताएं कम हो जाती हैं। औपचारिक परिवर्तन नियंत्रण - अनुमोदन से पहले प्रत्येक प्रस्तावित परिवर्तन के लिए अनुसूची, लागत और गुणवत्ता पर प्रभाव विश्लेषण की आवश्यकता होती है - दृश्यता प्रदान करता है और व्यापार-बंद निर्णयों को मजबूर करता है।
233
EN + हिं Medium
GB What is the 'viewpoint-oriented' approach in requirements engineering and why is it valuable?
IN आवश्यकता इंजीनियरिंग में 'दृष्टिकोण-उन्मुख' दृष्टिकोण क्या है और यह मूल्यवान क्यों है?
A
All requirements must be written from the end user's perspective only सभी आवश्यकताओं को केवल अंतिम उपयोगकर्ता के दृष्टिकोण से लिखा जाना चाहिए
B
It structures requirements elicitation around multiple distinct stakeholder perspectives, helping discover conflicts and requirements invisible from any single viewpoint यह कई अलग-अलग हितधारक दृष्टिकोणों के इर्द-गिर्द आवश्यकताओं की संरचना करता है, जिससे किसी एक दृष्टिकोण से अदृश्य संघर्षों और आवश्यकताओं को खोजने में मदद मिलती है
C
Only applicable to multi-tenant cloud systems केवल बहु-किरायेदार क्लाउड सिस्टम पर लागू
D
Requires each team member to write separate requirements documents independently प्रत्येक टीम सदस्य को स्वतंत्र रूप से अलग-अलग आवश्यकता दस्तावेज़ लिखने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Different stakeholders (users, administrators, regulators) have different and sometimes conflicting views. Viewpoint-oriented methods systematically capture each perspective, then explicitly reconcile conflicts — better surfaced during elicitation than during testing.
व्याख्या (हिन्दी) विभिन्न हितधारकों (उपयोगकर्ताओं, प्रशासकों, नियामकों) के अलग-अलग और कभी-कभी परस्पर विरोधी विचार होते हैं। दृष्टिकोण-उन्मुख तरीके प्रत्येक परिप्रेक्ष्य को व्यवस्थित रूप से पकड़ते हैं, फिर स्पष्ट रूप से संघर्षों को सुलझाते हैं - परीक्षण के दौरान की तुलना में स्पष्टीकरण के दौरान बेहतर ढंग से सामने आते हैं।
234
EN + हिं Easy
GB What is 'prototyping' as a requirements elicitation technique and what is its primary risk?
IN आवश्यकताओं को पूरा करने की तकनीक के रूप में 'प्रोटोटाइपिंग' क्या है और इसका प्राथमिक जोखिम क्या है?
A
Creating a detailed architectural design before writing code; risk is over-specification कोड लिखने से पहले एक विस्तृत वास्तुशिल्प डिज़ाइन बनाना; जोखिम अति-विशिष्टता है
B
Building a partial/simulated version to elicit requirements through user interaction; primary risk is stakeholders mistaking the prototype for the final system and resisting necessary rework उपयोगकर्ता इंटरैक्शन के माध्यम से आवश्यकताओं को पूरा करने के लिए आंशिक/सिम्युलेटेड संस्करण का निर्माण; प्राथमिक जोखिम यह है कि हितधारक प्रोटोटाइप को अंतिम प्रणाली समझ लेते हैं और आवश्यक पुनर्कार्य का विरोध करते हैं
C
Always the cheapest requirements technique and should be used in all projects हमेशा सबसे सस्ती आवश्यकताओं वाली तकनीक और सभी परियोजनाओं में इसका उपयोग किया जाना चाहिए
D
Replaces requirements documentation entirely in modern development आधुनिक विकास में आवश्यकताओं के दस्तावेज़ीकरण को पूरी तरह से बदल देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Prototyping is powerful for eliciting tacit requirements users can't articulate verbally. The critical risk (Sommerville's 'prototype as final system') is that stakeholders see working UI and assume the system is nearly done, pressuring the team to release the technically inadequate prototype.
व्याख्या (हिन्दी) प्रोटोटाइप उन मौन आवश्यकताओं को प्राप्त करने के लिए शक्तिशाली है जिन्हें उपयोगकर्ता मौखिक रूप से व्यक्त नहीं कर सकते हैं। गंभीर जोखिम (सोमरविले का 'अंतिम सिस्टम के रूप में प्रोटोटाइप') यह है कि हितधारक काम कर रहे यूआई को देखते हैं और मान लेते हैं कि सिस्टम लगभग पूरा हो चुका है, जिससे टीम पर तकनीकी रूप से अपर्याप्त प्रोटोटाइप जारी करने का दबाव पड़ता है।
235
EN + हिं Medium
GB What distinguishes 'elicitation' from 'analysis' in requirements engineering?
IN आवश्यकता इंजीनियरिंग में 'एलिसिटेशन' को 'विश्लेषण' से क्या अलग करता है?
A
Elicitation is done by customers; analysis by developers उद्दीपन ग्राहकों द्वारा किया जाता है; डेवलपर्स द्वारा विश्लेषण
B
Elicitation discovers and gathers requirements from stakeholders; analysis studies them for consistency, completeness, and resolves conflicts among elicited requirements एलीसिटेशन हितधारकों से आवश्यकताओं की खोज करता है और उन्हें एकत्र करता है; विश्लेषण निरंतरता, पूर्णता के लिए उनका अध्ययन करता है और उत्पन्न आवश्यकताओं के बीच टकराव का समाधान करता है
C
Elicitation only uses interviews; analysis only uses formal specification languages एलीसिटेशन केवल साक्षात्कार का उपयोग करता है; विश्लेषण केवल औपचारिक विनिर्देश भाषाओं का उपयोग करता है
D
Analysis precedes elicitation in the requirements process आवश्यकताओं की प्रक्रिया में विश्लेषण से पहले विश्लेषण किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Elicitation focuses on discovering what stakeholders need through interviews, workshops, observation. Analysis takes raw discovered requirements and studies them for internal consistency (no contradictions), completeness, and feasibility. Requirements from different stakeholders often conflict and analysis is where those conflicts are resolved.
व्याख्या (हिन्दी) एलीसिटेशन साक्षात्कार, कार्यशालाओं, अवलोकन के माध्यम से यह पता लगाने पर केंद्रित है कि हितधारकों को क्या चाहिए। विश्लेषण कच्ची खोजी गई आवश्यकताओं को लेता है और आंतरिक स्थिरता (कोई विरोधाभास नहीं), पूर्णता और व्यवहार्यता के लिए उनका अध्ययन करता है। विभिन्न हितधारकों की आवश्यकताओं में अक्सर टकराव होता है और विश्लेषण वह जगह है जहां उन संघर्षों का समाधान किया जाता है।
236
EN + हिं Easy
GB In IEEE 830, what does the 'verifiability' property of a good requirement mean?
IN आईईईई 830 में, एक अच्छी आवश्यकता की 'सत्यापनीयता' संपत्ति का क्या मतलब है?
A
Requirement has been verified by at least two senior stakeholders आवश्यकता को कम से कम दो वरिष्ठ हितधारकों द्वारा सत्यापित किया गया है
B
A cost-effective test, inspection, demonstration, or analysis method must exist that can confirm whether the requirement has been met एक लागत प्रभावी परीक्षण, निरीक्षण, प्रदर्शन या विश्लेषण विधि मौजूद होनी चाहिए जो पुष्टि कर सके कि आवश्यकता पूरी हो गई है या नहीं
C
Requirement source has been identified and documented आवश्यकता स्रोत की पहचान और दस्तावेजीकरण किया गया है
D
Requirement can be traced to a business objective in the project charter आवश्यकता का पता प्रोजेक्ट चार्टर में व्यावसायिक उद्देश्य से लगाया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IEEE 830 requires verifiability: a requirement must be stated so that a finite cost-effective procedure exists to check that the system satisfies it. 'User-friendly' is not verifiable; 'new users complete registration in under 3 minutes on first attempt' is verifiable through usability testing.
व्याख्या (हिन्दी) आईईईई 830 को सत्यापन की आवश्यकता है: एक आवश्यकता बताई जानी चाहिए ताकि यह जांचने के लिए एक सीमित लागत प्रभावी प्रक्रिया मौजूद हो कि सिस्टम इसे पूरा करता है। 'उपयोगकर्ता-अनुकूल' सत्यापन योग्य नहीं है; 'नए उपयोगकर्ता पहले प्रयास में 3 मिनट से कम समय में पंजीकरण पूरा कर लेते हैं' को प्रयोज्यता परीक्षण के माध्यम से सत्यापित किया जा सकता है।
237
EN + हिं Easy
GB What is the 'gold plating' problem in requirements engineering and from which side does it typically originate?
IN आवश्यकताओं की इंजीनियरिंग में 'गोल्ड प्लेटिंग' समस्या क्या है और यह आमतौर पर किस तरफ से उत्पन्न होती है?
A
Customers demanding premium features outside budget ग्राहक बजट से बाहर प्रीमियम सुविधाओं की मांग कर रहे हैं
B
Developers adding unrequested features believing they improve the product — wasting effort on features customers may never use डेवलपर्स बिना अनुरोध वाली सुविधाएँ जोड़ रहे हैं, यह विश्वास करते हुए कि वे उत्पाद को बेहतर बनाते हैं - उन सुविधाओं पर प्रयास बर्बाद कर रहे हैं जिनका ग्राहक कभी उपयोग नहीं कर सकते हैं
C
Excessive requirements documentation adding cost without clarity अत्यधिक आवश्यकताओं वाला दस्तावेज़ स्पष्टता के बिना लागत जोड़ता है
D
A financial software engineering term for transaction security layers लेनदेन सुरक्षा परतों के लिए एक वित्तीय सॉफ्टवेयर इंजीनियरिंग शब्द
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gold plating occurs when developers add features beyond what was requested, typically out of enthusiasm. While well-intentioned, it wastes resources, introduces unplanned testing requirements, and can complicate the interface.
व्याख्या (हिन्दी) गोल्ड प्लेटिंग तब होती है जब डेवलपर्स आम तौर पर उत्साह से, अनुरोधित सुविधाओं से अधिक सुविधाएँ जोड़ते हैं। नेक इरादे से होते हुए भी, यह संसाधनों को बर्बाद करता है, अनियोजित परीक्षण आवश्यकताओं को प्रस्तुत करता है, और इंटरफ़ेस को जटिल बना सकता है।
238
EN + हिं Medium
GB What is 'requirements traceability' and why is it particularly important in safety-critical systems?
IN 'आवश्यकताओं का पता लगाने की क्षमता' क्या है और यह सुरक्षा-महत्वपूर्ण प्रणालियों में विशेष रूप से महत्वपूर्ण क्यों है?
A
Ability to track who requested each requirement and their contact information यह ट्रैक करने की क्षमता कि प्रत्येक आवश्यकता और उनकी संपर्क जानकारी का अनुरोध किसने किया
B
Documented relationship linking requirements to design, code, and tests — enabling impact analysis and verification that all requirements are implemented; critical in safety systems for certification compliance डिज़ाइन, कोड और परीक्षणों से आवश्यकताओं को जोड़ने वाला दस्तावेज़ीकृत संबंध - प्रभाव विश्लेषण और सत्यापन को सक्षम करना कि सभी आवश्यकताएं लागू की गई हैं; प्रमाणीकरण अनुपालन के लिए सुरक्षा प्रणालियों में महत्वपूर्ण
C
Version control strategy for managing multiple branches of requirements documents आवश्यकता दस्तावेज़ों की अनेक शाखाओं के प्रबंधन के लिए संस्करण नियंत्रण रणनीति
D
Only applies to hardware requirements केवल हार्डवेयर आवश्यकताओं पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traceability matrices link requirements to design decisions, implementation, and test cases bidirectionally. In safety-critical systems, regulators require proof every safety requirement has been implemented and tested — traceability is the evidence.
व्याख्या (हिन्दी) ट्रैसेबिलिटी मैट्रिक्स आवश्यकताओं को डिजाइन निर्णयों, कार्यान्वयन और परीक्षण मामलों से द्विदिश रूप से जोड़ता है। सुरक्षा-महत्वपूर्ण प्रणालियों में, नियामकों को प्रमाण की आवश्यकता होती है कि प्रत्येक सुरक्षा आवश्यकता को लागू किया गया है और परीक्षण किया गया है - पता लगाने की क्षमता इसका प्रमाण है।
239
EN + हिं Easy
GB What is the 'requirements baseline' and what governance rules typically apply to it?
IN 'आवश्यकताओं की आधार रेखा' क्या है और इस पर आमतौर पर कौन से शासन नियम लागू होते हैं?
A
A preliminary draft of requirements used only for initial cost estimation आवश्यकताओं का प्रारंभिक मसौदा केवल प्रारंभिक लागत अनुमान के लिए उपयोग किया जाता है
B
A formally approved version of the requirements document serving as the agreed reference; changes require formal change control — impact assessment, CCB approval, and version management सहमत संदर्भ के रूप में कार्य करने वाले आवश्यकता दस्तावेज़ का औपचारिक रूप से अनुमोदित संस्करण; परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है - प्रभाव मूल्यांकन, सीसीबी अनुमोदन और संस्करण प्रबंधन
C
Automatically updated whenever a developer commits code जब भी कोई डेवलपर कोड करता है तो स्वचालित रूप से अपडेट हो जाता है
D
Produced by the testing team after system testing is complete सिस्टम परीक्षण पूरा होने के बाद परीक्षण टीम द्वारा उत्पादित किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A requirements baseline establishes a controlled reference. Once baselined, requirements are under configuration management — changes cannot be made informally. A Change Control Board evaluates impact on cost, schedule, and quality, approving or rejecting proposed changes.
व्याख्या (हिन्दी) आवश्यकताओं की आधार रेखा एक नियंत्रित संदर्भ स्थापित करती है। एक बार आधारभूत हो जाने पर, आवश्यकताएँ कॉन्फ़िगरेशन प्रबंधन के अंतर्गत होती हैं - परिवर्तन अनौपचारिक रूप से नहीं किए जा सकते। एक परिवर्तन नियंत्रण बोर्ड प्रस्तावित परिवर्तनों को स्वीकृत या अस्वीकार करते हुए लागत, अनुसूची और गुणवत्ता पर प्रभाव का मूल्यांकन करता है।
240
EN + हिं Easy
GB What does the Dependency Inversion Principle (DIP) state and what design problem does it solve?
IN निर्भरता व्युत्क्रम सिद्धांत (डीआईपी) क्या बताता है और यह किस डिज़ाइन समस्या का समाधान करता है?
A
All class dependencies should be injected through constructors rather than setters सभी वर्ग निर्भरताओं को सेटर्स के बजाय कंस्ट्रक्टर्स के माध्यम से इंजेक्ट किया जाना चाहिए
B
High-level modules should not depend on low-level modules; both should depend on abstractions — solving the problem where changing a low-level component forces changes throughout the system उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए; दोनों को अमूर्तता पर निर्भर होना चाहिए - उस समस्या को हल करना जहां निम्न-स्तरीय घटक को बदलने से पूरे सिस्टम में परिवर्तन होता है
C
All software dependencies must be managed by a centralised dependency registry सभी सॉफ़्टवेयर निर्भरताएँ एक केंद्रीकृत निर्भरता रजिस्ट्री द्वारा प्रबंधित की जानी चाहिए
D
Inheritance is prohibited; composition required instead विरासत निषिद्ध है; इसके बजाय रचना की आवश्यकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) DIP inverts the traditional dependency flow. Business logic depending on a database interface (abstraction) rather than the database directly means changing the database doesn't break business logic. This decouples layers and makes components independently replaceable.
व्याख्या (हिन्दी) डीआईपी पारंपरिक निर्भरता प्रवाह को उलट देता है। व्यावसायिक तर्क डेटाबेस के बजाय डेटाबेस इंटरफ़ेस (अमूर्त) पर निर्भर करता है, इसका सीधा मतलब है कि डेटाबेस को बदलने से व्यावसायिक तर्क नहीं टूटता है। यह परतों को अलग करता है और घटकों को स्वतंत्र रूप से बदलने योग्य बनाता है।
226–240 of 647