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
2161
EN + हिं Medium
GB Why is the Spiral model considered a 'meta-model' rather than just another process model?
IN स्पाइरल मॉडल को केवल एक अन्य प्रक्रिया मॉडल के बजाय 'मेटा-मॉडल' क्यों माना जाता है?
A
It was designed to model other software process models, not actual software इसे अन्य सॉफ़्टवेयर प्रक्रिया मॉडल को मॉडल करने के लिए डिज़ाइन किया गया था, वास्तविक सॉफ़्टवेयर के लिए नहीं
B
It can accommodate other process models (Waterfall, Incremental, Prototyping) within its framework, selecting the appropriate approach for each cycle based on risk यह जोखिम के आधार पर प्रत्येक चक्र के लिए उपयुक्त दृष्टिकोण का चयन करते हुए, अपने ढांचे के भीतर अन्य प्रक्रिया मॉडल (वाटरफॉल, इंक्रीमेंटल, प्रोटोटाइपिंग) को समायोजित कर सकता है।
C
It requires formal mathematical specifications before any development किसी भी विकास से पहले इसे औपचारिक गणितीय विशिष्टताओं की आवश्यकता होती है
D
It combines UML modelling with runtime process execution traces यह यूएमएल मॉडलिंग को रनटाइम प्रक्रिया निष्पादन ट्रेस के साथ जोड़ता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm called the Spiral a meta-model because it does not mandate a specific development approach. Its risk-driven framework can envelope other models: if risks show requirements are stable, use Waterfall; if unclear, use prototyping.
व्याख्या (हिन्दी) बोहेम ने स्पाइरल को मेटा-मॉडल कहा क्योंकि यह किसी विशिष्ट विकास दृष्टिकोण को अनिवार्य नहीं करता है। इसका जोखिम-संचालित ढांचा अन्य मॉडलों को कवर कर सकता है: यदि जोखिम दिखाते हैं कि आवश्यकताएं स्थिर हैं, तो वॉटरफॉल का उपयोग करें; यदि अस्पष्ट हो, तो प्रोटोटाइप का उपयोग करें।
2162
EN + हिं Easy
GB What are 'anchor point milestones' in Boehm's Win-Win Spiral model?
IN बोहेम के विन-विन स्पाइरल मॉडल में 'एंकर प्वाइंट मील के पत्थर' क्या हैं?
A
Mandatory security audits at fixed calendar intervals निश्चित कैलेंडर अंतराल पर अनिवार्य सुरक्षा ऑडिट
B
Defined checkpoints where stakeholders review and agree on progress, risk status, and commitment to proceed — specifically LCO, LCA, and IOC परिभाषित चौकियाँ जहाँ हितधारक प्रगति, जोखिम की स्थिति और आगे बढ़ने की प्रतिबद्धता की समीक्षा करते हैं और सहमत होते हैं - विशेष रूप से एलसीओ, एलसीए और आईओसी
C
Hardware benchmarks to evaluate the deployment platform परिनियोजन प्लेटफ़ॉर्म का मूल्यांकन करने के लिए हार्डवेयर बेंचमार्क
D
Automated test suite checkpoints before each spiral cycle प्रत्येक सर्पिल चक्र से पहले स्वचालित परीक्षण सूट चौकियाँ
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Boehm's Win-Win Spiral introduced anchor point milestones as formal decision gates: LCO validates scope/approach; LCA validates architecture stability; IOC validates readiness for deployment. These prevent the spiral from continuing without explicit stakeholder commitment.
व्याख्या (हिन्दी) बोहेम के विन-विन स्पाइरल ने औपचारिक निर्णय द्वार के रूप में एंकर पॉइंट मील के पत्थर पेश किए: एलसीओ दायरे/दृष्टिकोण को मान्य करता है; एलसीए वास्तुकला स्थिरता को मान्य करता है; आईओसी तैनाती के लिए तैयारी की पुष्टि करता है। ये स्पष्ट हितधारक प्रतिबद्धता के बिना सर्पिल को जारी रखने से रोकते हैं।
2163
EN + हिं Medium
GB A team discovers mid-Spiral that a critical third-party API has been deprecated. How does the Spiral model's structure specifically help?
IN एक टीम को मध्य-सर्पिल में पता चलता है कि एक महत्वपूर्ण तृतीय-पक्ष एपीआई को हटा दिया गया है। स्पाइरल मॉडल की संरचना विशेष रूप से कैसे मदद करती है?
A
Spiral automatically selects an alternative API स्पाइरल स्वचालित रूप से एक वैकल्पिक एपीआई का चयन करता है
B
The risk discovery triggers an explicit risk resolution phase where alternatives are evaluated before committing to the next iteration जोखिम की खोज एक स्पष्ट जोखिम समाधान चरण को ट्रिगर करती है जहां अगले पुनरावृत्ति के लिए प्रतिबद्ध होने से पहले विकल्पों का मूल्यांकन किया जाता है
C
Team must roll back to previous cycle and restart with different technology टीम को पिछले चक्र में वापस जाना होगा और विभिन्न तकनीक के साथ पुनः आरंभ करना होगा
D
Spiral flags this as project failure and recommends termination स्पाइरल ने इसे परियोजना विफलता के रूप में चिह्नित किया और समाप्ति की सिफारिश की
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Risk analysis in the Spiral model surfaces exactly this type of dependency risk early. When identified, the model mandates resolving it before proceeding — preventing the team from discovering the problem deep in implementation when switching approaches would be far more expensive.
व्याख्या (हिन्दी) स्पाइरल मॉडल में जोखिम विश्लेषण बिल्कुल इसी प्रकार के निर्भरता जोखिम को जल्दी सामने लाता है। जब पहचान की जाती है, तो मॉडल आगे बढ़ने से पहले इसे हल करने का आदेश देता है - टीम को कार्यान्वयन में गहराई से समस्या की खोज करने से रोकता है जब दृष्टिकोण बदलना कहीं अधिक महंगा होगा।
2164
EN + हिं Easy
GB What does the Agile Manifesto's 'responding to change over following a plan' specifically NOT mean?
IN एजाइल मेनिफेस्टो के 'योजना का पालन करने के बजाय परिवर्तन पर प्रतिक्रिया' का विशेष रूप से क्या मतलब नहीं है?
A
That planning is unnecessary and teams should work without structure वह योजना अनावश्यक है और टीमों को संरचना के बिना काम करना चाहिए
B
That plans are bad and should be entirely avoided ये योजनाएँ ख़राब हैं और इनसे पूरी तरह बचा जाना चाहिए
C
That teams should abandon plans whenever a member suggests a new idea जब भी कोई सदस्य कोई नया विचार सुझाता है तो टीमों को योजनाएँ छोड़ देनी चाहिए
D
All the above are incorrect interpretations of the Agile value उपरोक्त सभी एजाइल मूल्य की गलत व्याख्याएँ हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Agile Manifesto explicitly states it values items on the left MORE, not that items on the right have no value. Planning is still essential in Agile; teams plan differently (short cycles, adaptive replanning) and prioritise adaptability.
व्याख्या (हिन्दी) एजाइल मेनिफेस्टो में स्पष्ट रूप से कहा गया है कि वह बाईं ओर की वस्तुओं को अधिक महत्व देता है, न कि दाईं ओर की वस्तुओं का कोई मूल्य नहीं है। एजाइल में योजना अभी भी आवश्यक है; टीमें अलग-अलग योजना बनाती हैं (छोटे चक्र, अनुकूली पुनर्योजना) और अनुकूलन क्षमता को प्राथमिकता देती हैं।
2165
EN + हिं Medium
GB In Scrum, what is the primary purpose of the Sprint Retrospective, and how does it differ from the Sprint Review?
IN स्क्रम में, स्प्रिंट रेट्रोस्पेक्टिव का प्राथमिक उद्देश्य क्या है, और यह स्प्रिंट समीक्षा से कैसे भिन्न है?
A
Sprint Retrospective reviews product increment with customers; Sprint Review assesses team processes स्प्रिंट रेट्रोस्पेक्टिव ग्राहकों के साथ उत्पाद वृद्धि की समीक्षा करता है; स्प्रिंट रिव्यू टीम प्रक्रियाओं का आकलन करता है
B
Sprint Retrospective is an internal team inspection of their working process to identify improvements; Sprint Review demonstrates the increment to stakeholders for product feedback स्प्रिंट रेट्रोस्पेक्टिव सुधारों की पहचान करने के लिए उनकी कार्य प्रक्रिया का एक आंतरिक टीम निरीक्षण है; स्प्रिंट समीक्षा उत्पाद प्रतिक्रिया के लिए हितधारकों की वृद्धि को दर्शाती है
C
Sprint Retrospective updates Sprint Backlog; Sprint Review updates Product Backlog स्प्रिंट पूर्वव्यापी अद्यतन स्प्रिंट बैकलॉग; स्प्रिंट समीक्षा उत्पाद बैकलॉग को अद्यतन करती है
D
Both events serve the same purpose and can be combined दोनों घटनाएँ एक ही उद्देश्य की पूर्ति करती हैं और इन्हें जोड़ा जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Sprint Review is product-focused — showing what was built to stakeholders for feedback. The Sprint Retrospective is process-focused — the team reflects on how they worked and creates improvement plans. Conflating the two undermines both purposes.
व्याख्या (हिन्दी) स्प्रिंट समीक्षा उत्पाद-केंद्रित है - यह दिखाती है कि प्रतिक्रिया के लिए हितधारकों को क्या बनाया गया था। स्प्रिंट रेट्रोस्पेक्टिव प्रक्रिया-केंद्रित है - टीम इस बात पर विचार करती है कि उन्होंने कैसे काम किया और सुधार योजनाएं बनाती हैं। दोनों को मिलाने से दोनों उद्देश्य कमजोर हो जाते हैं।
2166
EN + हिं Easy
GB What does 'velocity' in Scrum measure and what is its most critical limitation?
IN स्क्रम में 'वेग' क्या मापता है और इसकी सबसे महत्वपूर्ण सीमा क्या है?
A
Team physical movement between workstations कार्यस्थानों के बीच टीम की शारीरिक गतिविधि
B
Story points completed per sprint; its limitation is team-specificity, non-comparability across teams, and susceptibility to gaming by inflating estimates प्रति स्प्रिंट पूरी की गई कहानी के बिंदु; इसकी सीमा टीम-विशिष्टता, टीमों में गैर-तुलनीयता और अनुमान बढ़ाकर गेमिंग के प्रति संवेदनशीलता है।
C
Number of customer complaints resolved per sprint प्रति स्प्रिंट हल की गई ग्राहक शिकायतों की संख्या
D
Lines of code written per day — an industry-standard metric प्रतिदिन लिखी गई कोड की पंक्तियाँ - एक उद्योग-मानक मीट्रिक
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Velocity (story points per sprint) helps teams forecast future delivery based on historical performance. However story points are relative and team-specific — comparing velocity across teams is meaningless. Velocity can also be gamed when management uses it as a performance target.
व्याख्या (हिन्दी) वेलोसिटी (प्रति स्प्रिंट कहानी बिंदु) टीमों को ऐतिहासिक प्रदर्शन के आधार पर भविष्य की डिलीवरी का पूर्वानुमान लगाने में मदद करती है। हालाँकि कहानी के बिंदु सापेक्ष और टीम-विशिष्ट हैं - टीमों में वेग की तुलना करना अर्थहीन है। जब प्रबंधन इसे प्रदर्शन लक्ष्य के रूप में उपयोग करता है तो वेग से भी खिलवाड़ किया जा सकता है।
2167
EN + हिं Medium
GB What is the 'Definition of Done' (DoD) in Scrum and what happens when a team lacks a shared DoD?
IN स्क्रम में 'डन की परिभाषा' (डीओडी) क्या है और जब किसी टीम के पास साझा डीओडी की कमी होती है तो क्या होता है?
A
DoD is the list of features planned for the next sprint DoD अगले स्प्रिंट के लिए नियोजित सुविधाओं की सूची है
B
DoD is the shared standard defining when an increment is complete and shippable; without it different team members have different completion criteria leading to hidden technical debt DoD एक साझा मानक है जो परिभाषित करता है कि वेतन वृद्धि कब पूर्ण और शिप करने योग्य है; इसके बिना अलग-अलग टीम के सदस्यों के पास अलग-अलग पूर्णता मानदंड होते हैं, जिससे छिपे हुए तकनीकी ऋण का सामना करना पड़ता है
C
DoD specifies which developers handle which user stories DoD निर्दिष्ट करता है कि कौन से डेवलपर कौन सी उपयोगकर्ता कहानियों को संभालते हैं
D
DoD is optional; teams can operate effectively without it डीओडी वैकल्पिक है; टीमें इसके बिना प्रभावी ढंग से काम कर सकती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without a shared DoD, 'done' means different things to different people, accumulating as undeclared technical debt and making sprint velocity unreliable. The DoD creates transparency about what has truly been completed.
व्याख्या (हिन्दी) साझा DoD के बिना, 'किया गया' का अलग-अलग लोगों के लिए अलग-अलग मतलब होता है, जो अघोषित तकनीकी ऋण के रूप में जमा होता है और स्प्रिंट वेग को अविश्वसनीय बनाता है। DoD वास्तव में जो पूरा हो चुका है उसके बारे में पारदर्शिता बनाता है।
2168
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× भिन्न हो सकते हैं। जैसे-जैसे डिज़ाइन और कार्यान्वयन आगे बढ़ता है, दायरा कम होता जाता है। फुर्तीली टीमें बिंदु अनुमान के बजाय सीमा अनुमान प्रदान करके और प्रत्येक स्प्रिंट को परिष्कृत करके इसका समाधान करती हैं।
2169
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 सीमाएँ कानबन की मुख्य प्रवाह अनुकूलन तंत्र हैं। जब कोई चरण अपनी डब्ल्यूआईपी सीमा तक पहुंचता है, तो अपस्ट्रीम कार्यकर्ताओं को रुकना चाहिए और अधिक काम जोड़ने के बजाय बाधा को दूर करने में मदद करनी चाहिए - लिटिल के कानून के अनुसार प्रणालीगत बाधाओं को प्रकट करना और संदर्भ स्विचिंग को कम करना।
2170
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 एकल उत्पाद बैकलॉग को साझा करने वाली कम बड़ी फीचर टीमों के द्वारा स्क्रम को बरकरार रखता है और स्केल करता है।
2171
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.
व्याख्या (हिन्दी) सीआई 'एकीकरण नरक' को रोकता है - समानांतर विकास के महीनों के विलय का दर्दनाक अनुभव जहां टीमों ने असंगत परिवर्तन किए हैं। स्वचालित परीक्षणों के साथ बार-बार एकीकरण करके, संदर्भ ताज़ा होने पर परिचय के कुछ घंटों के भीतर विरोधों का पता लगाया जाता है।
2172
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% कम दोष दिखाता है। चूंकि दोष की मरम्मत सबसे बड़ी लागत चालक है, इसलिए शुद्ध अर्थशास्त्र आम तौर पर सकारात्मक है - ज्ञान साझा करने के अतिरिक्त लाभ और कम बस कारक के साथ।
2173
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.
व्याख्या (हिन्दी) द लास्ट रिस्पॉन्सिबल मोमेंट (पॉपेंडिएक) मानता है कि अनिश्चितता के तहत समय से पहले लिए गए निर्णयों में उच्च त्रुटि लागत होती है। जानबूझकर विकल्प खुले रखने और केवल तभी निर्णय लेने से जब निर्णय लिया जाना चाहिए, टीमें अधिक डेटा के साथ बेहतर निर्णय लेती हैं।
2174
EN + हिं Easy
GB What is the key distinction between functional and non-functional requirements, and which is typically harder to elicit?
IN कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के बीच मुख्य अंतर क्या है, और आमतौर पर किसका पता लगाना कठिन है?
A
Functional describe system performance; non-functional describe user stories कार्यात्मक प्रणाली के प्रदर्शन का वर्णन करें; गैर-कार्यात्मक उपयोगकर्ता कहानियों का वर्णन करें
B
Functional describe what the system does (behaviour); non-functional describe qualities like performance and security — non-functional are harder because stakeholders struggle to quantify them precisely कार्यात्मक वर्णन करता है कि सिस्टम क्या करता है (व्यवहार); गैर-कार्यात्मक प्रदर्शन और सुरक्षा जैसे गुणों का वर्णन करते हैं - गैर-कार्यात्मक कठिन हैं क्योंकि हितधारक उन्हें सटीक रूप से मापने के लिए संघर्ष करते हैं
C
Non-functional requirements are defined by developers; functional by customers गैर-कार्यात्मक आवश्यकताएं डेवलपर्स द्वारा परिभाषित की जाती हैं; ग्राहकों द्वारा कार्यात्मक
D
Functional only apply to UI layer; non-functional to backend कार्यात्मकता केवल यूआई परत पर लागू होती है; बैकएंड के लिए गैर-कार्यात्मक
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Functional requirements specify specific behaviours. Non-functional requirements (NFRs) specify quality attributes. NFRs are harder to elicit because stakeholders say 'it should be fast' rather than providing measurable thresholds, requiring analysts to probe for testable acceptance criteria.
व्याख्या (हिन्दी) कार्यात्मक आवश्यकताएँ विशिष्ट व्यवहार निर्दिष्ट करती हैं। गैर-कार्यात्मक आवश्यकताएं (एनएफआर) गुणवत्ता विशेषताओं को निर्दिष्ट करती हैं। एनएफआर प्राप्त करना कठिन है क्योंकि हितधारकों का कहना है कि मापने योग्य सीमाएं प्रदान करने के बजाय 'यह तेज़ होना चाहिए', जिससे विश्लेषकों को परीक्षण योग्य स्वीकृति मानदंडों की जांच करने की आवश्यकता होती है।
2175
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.
व्याख्या (हिन्दी) जब हितधारक दायरे पर सहमति के बाद अनौपचारिक रूप से परिवर्तन का अनुरोध करते हैं तो आवश्यकताएं कम हो जाती हैं। औपचारिक परिवर्तन नियंत्रण - अनुमोदन से पहले प्रत्येक प्रस्तावित परिवर्तन के लिए अनुसूची, लागत और गुणवत्ता पर प्रभाव विश्लेषण की आवश्यकता होती है - दृश्यता प्रदान करता है और व्यापार-बंद निर्णयों को मजबूर करता है।
2161–2175 of 2726