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
2146
EN + हिं Easy
GB What is the 'document-driven' criticism of the Waterfall model?
IN वाटरफॉल मॉडल की 'दस्तावेज़-संचालित' आलोचना क्या है?
A
Waterfall produces too few documents, making maintenance difficult वॉटरफ़ॉल बहुत कम दस्तावेज़ बनाता है, जिससे रखरखाव मुश्किल हो जाता है
B
Producing exhaustive documentation at each phase gate consumes significant effort and yields artefacts that become outdated and rarely consulted प्रत्येक चरण के गेट पर विस्तृत दस्तावेज़ तैयार करने में काफी मेहनत लगती है और ऐसी कलाकृतियाँ प्राप्त होती हैं जो पुरानी हो जाती हैं और जिनकी शायद ही कभी सलाह ली जाती है।
C
Waterfall forbids developers from reading requirement documents वॉटरफ़ॉल डेवलपर्स को आवश्यक दस्तावेज़ पढ़ने से रोकता है
D
Modern IDEs cannot import Waterfall specification documents आधुनिक आईडीई वॉटरफ़ॉल विनिर्देश दस्तावेज़ आयात नहीं कर सकते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Waterfall mandates large formal documents (SRS, SDD, test plans) at every phase boundary. In fast-changing domains, these become obsolete quickly. Teams spend more time maintaining documentation than solving problems.
व्याख्या (हिन्दी) झरना प्रत्येक चरण सीमा पर बड़े औपचारिक दस्तावेज़ (एसआरएस, एसडीडी, परीक्षण योजना) को अनिवार्य करता है। तेजी से बदलते डोमेन में, ये जल्दी अप्रचलित हो जाते हैं। टीमें समस्याओं को सुलझाने की तुलना में दस्तावेज़ीकरण बनाए रखने में अधिक समय व्यतीत करती हैं।
2147
EN + हिं Easy
GB A project manager uses Waterfall for an e-commerce platform where UI preferences are unknown. What is the most critical flaw?
IN एक प्रोजेक्ट मैनेजर एक ई-कॉमर्स प्लेटफॉर्म के लिए वॉटरफॉल का उपयोग करता है जहां यूआई प्राथमिकताएं अज्ञात हैं। सबसे गंभीर दोष क्या है?
A
Waterfall does not support web-based technologies वॉटरफॉल वेब-आधारित प्रौद्योगिकियों का समर्थन नहीं करता है
B
Waterfall requires complete stable requirements upfront; unknown UI preferences mean requirements will change after implementation, triggering costly rework झरने के लिए पहले से ही पूर्ण स्थिर आवश्यकताओं की आवश्यकता होती है; अज्ञात यूआई प्राथमिकताओं का मतलब है कि कार्यान्वयन के बाद आवश्यकताएं बदल जाएंगी, जिससे महंगा पुनर्कार्य शुरू हो जाएगा
C
Waterfall cannot produce graphical user interfaces वॉटरफ़ॉल ग्राफ़िकल यूज़र इंटरफ़ेस उत्पन्न नहीं कर सकता
D
The e-commerce domain requires agile certification ई-कॉमर्स डोमेन के लिए त्वरित प्रमाणीकरण की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Waterfall's biggest weakness is its inability to gracefully accommodate requirement changes after a phase is complete. For UI-heavy consumer products where usability testing reveals needed changes, this rigidity is fatal.
व्याख्या (हिन्दी) झरने की सबसे बड़ी कमजोरी एक चरण पूरा होने के बाद आवश्यकता परिवर्तनों को खूबसूरती से समायोजित करने में असमर्थता है। यूआई-भारी उपभोक्ता उत्पादों के लिए जहां प्रयोज्य परीक्षण से आवश्यक परिवर्तनों का पता चलता है, यह कठोरता घातक है।
2148
EN + हिं Medium
GB In Waterfall, what distinguishes 'System Design' from 'Software Design'?
IN वॉटरफॉल में, 'सिस्टम डिज़ाइन' को 'सॉफ़्टवेयर डिज़ाइन' से क्या अलग करता है?
A
System Design writes actual code; Software Design creates flowcharts सिस्टम डिज़ाइन वास्तविक कोड लिखता है; सॉफ्टवेयर डिज़ाइन फ़्लोचार्ट बनाता है
B
System Design allocates requirements to hardware and software components and establishes overall architecture; Software Design details the internal structure of software modules सिस्टम डिज़ाइन हार्डवेयर और सॉफ़्टवेयर घटकों के लिए आवश्यकताओं को आवंटित करता है और समग्र वास्तुकला स्थापित करता है; सॉफ़्टवेयर डिज़ाइन सॉफ़्टवेयर मॉड्यूल की आंतरिक संरचना का विवरण देता है
C
System Design is by customers; Software Design by developers सिस्टम डिज़ाइन ग्राहकों द्वारा होता है; डेवलपर्स द्वारा सॉफ्टवेयर डिजाइन
D
System Design covers only database schemas सिस्टम डिज़ाइन केवल डेटाबेस स्कीमा को कवर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) System Design (architectural design) partitions the overall system into hardware, software, and network subsystems, defining their interfaces. Software Design then elaborates the software subsystem — specifying module structure, data structures, and algorithms.
व्याख्या (हिन्दी) सिस्टम डिज़ाइन (वास्तुशिल्प डिज़ाइन) समग्र सिस्टम को हार्डवेयर, सॉफ़्टवेयर और नेटवर्क सबसिस्टम में विभाजित करता है, उनके इंटरफेस को परिभाषित करता है। सॉफ़्टवेयर डिज़ाइन फिर सॉफ़्टवेयर सबसिस्टम को विस्तृत करता है - मॉड्यूल संरचना, डेटा संरचना और एल्गोरिदम को निर्दिष्ट करता है।
2149
EN + हिं Easy
GB What does Royce's original 1970 Waterfall paper actually recommend that many practitioners ignore?
IN रॉयस का मूल 1970 वॉटरफ़ॉल पेपर वास्तव में क्या अनुशंसा करता है जिसे कई चिकित्सक अनदेखा कर देते हैं?
A
Software should be written in COBOL for maximum portability अधिकतम पोर्टेबिलिटी के लिए सॉफ़्टवेयर को COBOL में लिखा जाना चाहिए
B
The Waterfall should include a preliminary iteration before main development, and feedback loops between phases are necessary झरने में मुख्य विकास से पहले एक प्रारंभिक पुनरावृत्ति शामिल होनी चाहिए, और चरणों के बीच फीडबैक लूप आवश्यक हैं
C
All testing should be outsourced to independent QA companies सभी परीक्षण स्वतंत्र QA कंपनियों को आउटसोर्स किए जाने चाहिए
D
Requirements should never be written down, only verbally communicated आवश्यकताओं को कभी भी लिखा नहीं जाना चाहिए, केवल मौखिक रूप से संप्रेषित किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Royce's 1970 paper actually warned that the simple sequential Waterfall was risky and recommended building a preliminary pilot version first, plus explicitly allowing feedback between adjacent phases. The 'pure' Waterfall that became industry dogma was a misreading.
व्याख्या (हिन्दी) रॉयस के 1970 के पेपर ने वास्तव में चेतावनी दी थी कि सरल अनुक्रमिक झरना जोखिम भरा था और पहले एक प्रारंभिक पायलट संस्करण बनाने की सिफारिश की गई थी, साथ ही आसन्न चरणों के बीच स्पष्ट रूप से प्रतिक्रिया की अनुमति दी गई थी। 'शुद्ध' झरना जो उद्योग की हठधर्मिता बन गया, एक गलत व्याख्या थी।
2150
EN + हिं Medium
GB Which Waterfall phase is most commonly associated with the highest rework cost when defects escape it?
IN जब दोष बच जाते हैं तो कौन सा झरना चरण सबसे अधिक पुनः कार्य लागत से जुड़ा होता है?
A
Implementation phase कार्यान्वयन चरण
B
Requirements phase आवश्यकताएँ चरण
C
Integration and Testing phase एकीकरण और परीक्षण चरण
D
System Design phase सिस्टम डिज़ाइन चरण
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Requirements defects are the most expensive to fix when discovered late because they affect every downstream phase. Capers Jones and Boehm documented that fixing a requirements defect in maintenance costs 100–200× more than fixing it during requirements review.
व्याख्या (हिन्दी) देर से पता चलने पर आवश्यकता दोषों को ठीक करना सबसे महंगा होता है क्योंकि वे प्रत्येक डाउनस्ट्रीम चरण को प्रभावित करते हैं। केपर्स जोन्स और बोहेम ने दस्तावेजीकरण किया कि रखरखाव में आवश्यकताओं की खराबी को ठीक करने में आवश्यकताओं की समीक्षा के दौरान इसे ठीक करने की तुलना में 100-200× अधिक खर्च होता है।
2151
EN + हिं Easy
GB In a Waterfall project, what does Acceptance Testing primarily verify and who owns it?
IN वॉटरफॉल प्रोजेक्ट में, स्वीकृति परीक्षण मुख्य रूप से क्या सत्यापित करता है और इसका मालिक कौन है?
A
That source code compiles without errors; owned by the development lead वह स्रोत कोड त्रुटियों के बिना संकलित होता है; विकास नेतृत्व के स्वामित्व में
B
That the delivered system meets contractual requirements and is fit for deployment; owned by the customer/client यह कि वितरित प्रणाली संविदात्मक आवश्यकताओं को पूरा करती है और तैनाती के लिए उपयुक्त है; ग्राहक/ग्राहक के स्वामित्व में
C
That each module performs unit-level function; owned by QA department प्रत्येक मॉड्यूल इकाई-स्तरीय कार्य करता है; QA विभाग के स्वामित्व में
D
That system performance meets SLA benchmarks; owned by infrastructure team वह सिस्टम प्रदर्शन SLA बेंचमार्क को पूरा करता है; इंफ्रास्ट्रक्चर टीम के स्वामित्व में
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Acceptance Testing (UAT) is performed by the customer to verify the delivered system fulfils agreed requirements and is suitable for operational use. It is the final gate before handover and the customer's formal sign-off mechanism.
व्याख्या (हिन्दी) स्वीकृति परीक्षण (यूएटी) ग्राहक द्वारा यह सत्यापित करने के लिए किया जाता है कि वितरित प्रणाली सहमत आवश्यकताओं को पूरा करती है और परिचालन उपयोग के लिए उपयुक्त है। यह हैंडओवर से पहले का अंतिम द्वार और ग्राहक का औपचारिक साइन-ऑफ तंत्र है।
2152
EN + हिं Medium
GB Why does Waterfall struggle with large multi-team projects despite its structured nature?
IN वाटरफॉल अपनी संरचित प्रकृति के बावजूद बड़ी बहु-टीम परियोजनाओं के साथ संघर्ष क्यों करता है?
A
Large projects require more programming languages than Waterfall supports बड़ी परियोजनाओं के लिए वॉटरफॉल समर्थन की तुलना में अधिक प्रोग्रामिंग भाषाओं की आवश्यकता होती है
B
Integration of subsystems developed in parallel reveals interface mismatches that cannot be detected until the integration phase, causing cascading rework समानांतर में विकसित उपप्रणालियों के एकीकरण से इंटरफ़ेस बेमेल का पता चलता है जिसे एकीकरण चरण तक पता नहीं लगाया जा सकता है, जिससे कैस्केडिंग पुनर्कार्य होता है
C
Waterfall requires all team members to be co-located वॉटरफॉल के लिए टीम के सभी सदस्यों का एक साथ स्थित होना आवश्यक है
D
Waterfall does not support module-level version control वॉटरफ़ॉल मॉड्यूल-स्तरीय संस्करण नियंत्रण का समर्थन नहीं करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In large multi-team Waterfall projects, teams design subsystems concurrently based on interface agreements. Interface misunderstandings accumulate invisibly until integration testing, surfacing as a cluster of defects — 'integration hell'.
व्याख्या (हिन्दी) बड़ी मल्टी-टीम वॉटरफ़ॉल परियोजनाओं में, टीमें इंटरफ़ेस समझौतों के आधार पर समवर्ती रूप से सबसिस्टम डिज़ाइन करती हैं। इंटरफ़ेस ग़लतफ़हमियाँ एकीकरण परीक्षण तक अदृश्य रूप से जमा होती रहती हैं, जो दोषों के एक समूह के रूप में सामने आती हैं - 'एकीकरण नरक'।
2153
EN + हिं Medium
GB What fundamental assumption of Waterfall makes it unsuitable for most modern software projects?
IN वॉटरफॉल की कौन सी मूलभूत धारणा इसे अधिकांश आधुनिक सॉफ्टवेयर परियोजनाओं के लिए अनुपयुक्त बनाती है?
A
All software can be built by a single developer सभी सॉफ़्टवेयर एक ही डेवलपर द्वारा बनाए जा सकते हैं
B
Complete and stable requirements can be elicited and frozen before any design or implementation begins किसी भी डिज़ाइन या कार्यान्वयन के शुरू होने से पहले पूर्ण और स्थिर आवश्यकताओं को प्राप्त और स्थिर किया जा सकता है
C
Testing is unnecessary if design reviews are thorough यदि डिज़ाइन समीक्षाएँ गहन हैं तो परीक्षण अनावश्यक है
D
All software follows the same domain-specific patterns सभी सॉफ़्टवेयर समान डोमेन-विशिष्ट पैटर्न का अनुसरण करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Waterfall's fatal assumption is that requirements are fully knowable and stable before development begins. In reality, users rarely know exactly what they want until they see a working system, markets change, and technology evolves — making frozen requirements an impossibility.
व्याख्या (हिन्दी) वॉटरफॉल की घातक धारणा यह है कि विकास शुरू होने से पहले आवश्यकताएं पूरी तरह से जानने योग्य और स्थिर होती हैं। वास्तव में, उपयोगकर्ताओं को शायद ही कभी पता चलता है कि वे क्या चाहते हैं जब तक कि वे एक कार्य प्रणाली, बाज़ार में बदलाव और प्रौद्योगिकी विकसित नहीं हो जाते - जिससे स्थिर आवश्यकताओं को असंभव बना दिया जाता है।
2154
EN + हिं Medium
GB In Boehm's Spiral model, what determines when the spiral terminates and the product is released?
IN बोहेम के सर्पिल मॉडल में, यह क्या निर्धारित करता है कि सर्पिल कब समाप्त होता है और उत्पाद जारी होता है?
A
After exactly four revolutions regardless of completeness पूर्णता की परवाह किए बिना ठीक चार क्रांतियों के बाद
B
When accumulated risk is sufficiently low and the product satisfies stakeholder objectives जब संचित जोखिम पर्याप्त रूप से कम हो और उत्पाद हितधारक के उद्देश्यों को पूरा करता हो
C
When the project budget is fully consumed जब परियोजना बजट पूरी तरह से खर्च हो जाता है
D
When all identified risks have been completely eliminated जब सभी पहचाने गए जोखिम पूरी तरह से समाप्त हो गए हों
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In the Spiral model, each revolution passes through risk analysis. If remaining risks are manageable and the product meets objectives, the team may release. The spiral is risk-driven, not schedule-driven.
व्याख्या (हिन्दी) स्पाइरल मॉडल में, प्रत्येक क्रांति जोखिम विश्लेषण से गुजरती है। यदि शेष जोखिम प्रबंधनीय हैं और उत्पाद उद्देश्यों को पूरा करता है, तो टीम जारी कर सकती है। सर्पिल जोखिम-प्रेरित है, शेड्यूल-चालित नहीं।
2155
EN + हिं Medium
GB What is the key difference between the Spiral model and Incremental development models?
IN स्पाइरल मॉडल और वृद्धिशील विकास मॉडल के बीच मुख्य अंतर क्या है?
A
Spiral delivers working software each cycle; Incremental does not स्पाइरल प्रत्येक चक्र में कार्यशील सॉफ़्टवेयर वितरित करता है; वृद्धिशील नहीं है
B
Spiral makes risk analysis an explicit mandatory activity driving iteration decisions; Incremental focuses on delivering planned functionality without formalised risk assessment स्पाइरल जोखिम विश्लेषण को पुनरावृत्ति निर्णयों को संचालित करने वाली एक स्पष्ट अनिवार्य गतिविधि बनाता है; इंक्रीमेंटल औपचारिक जोखिम मूल्यांकन के बिना नियोजित कार्यक्षमता प्रदान करने पर केंद्रित है
C
Spiral is always faster than Incremental for small projects छोटी परियोजनाओं के लिए स्पाइरल हमेशा इंक्रीमेंटल से तेज़ होता है
D
Only Incremental uses prototyping; Spiral does not केवल इंक्रीमेंटल प्रोटोटाइप का उपयोग करता है; सर्पिल नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Spiral model's defining characteristic is its risk-driven nature — each cycle begins with risk identification, and results determine whether to prototype, build, or pivot entirely. Incremental models preplan functionality delivery without this explicit risk-assessment gate.
व्याख्या (हिन्दी) स्पाइरल मॉडल की परिभाषित विशेषता इसकी जोखिम-संचालित प्रकृति है - प्रत्येक चक्र जोखिम की पहचान के साथ शुरू होता है, और परिणाम यह निर्धारित करते हैं कि प्रोटोटाइप, निर्माण या पूरी तरह से धुरी बनाना है या नहीं। वृद्धिशील मॉडल इस स्पष्ट जोखिम-मूल्यांकन गेट के बिना प्रीप्लान कार्यक्षमता वितरण।
2156
EN + हिं Medium
GB For which type of project is the Spiral model LEAST appropriate?
IN किस प्रकार की परियोजना के लिए स्पाइरल मॉडल सबसे कम उपयुक्त है?
A
Large defence contracts requiring formal acceptance criteria बड़े रक्षा अनुबंधों के लिए औपचारिक स्वीकृति मानदंड की आवश्यकता होती है
B
Small, well-understood projects with fixed budgets and tight deadlines where risk analysis overhead outweighs benefits निश्चित बजट और सख्त समय सीमा वाली छोटी, अच्छी तरह से समझी जाने वाली परियोजनाएँ जहाँ जोखिम विश्लेषण ओवरहेड लाभ से अधिक होता है
C
R&D software with high technological uncertainty उच्च तकनीकी अनिश्चितता के साथ अनुसंधान एवं विकास सॉफ्टवेयर
D
Systems requiring integration of heterogeneous legacy components विषम विरासत घटकों के एकीकरण की आवश्यकता वाली प्रणालियाँ
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Spiral model's overhead — formal risk assessments, prototyping, extensive planning per cycle — is only cost-effective for large complex high-risk projects. For small well-understood projects, this overhead consumes disproportionate resources.
व्याख्या (हिन्दी) स्पाइरल मॉडल का ओवरहेड - औपचारिक जोखिम मूल्यांकन, प्रोटोटाइप, प्रति चक्र व्यापक योजना - केवल बड़े जटिल उच्च जोखिम वाली परियोजनाओं के लिए लागत प्रभावी है। अच्छी तरह से समझी जाने वाली छोटी परियोजनाओं के लिए, यह ओवरहेड अनुपातहीन संसाधनों का उपभोग करता है।
2157
EN + हिं Easy
GB In the Spiral model, what does the 'radial dimension' of the spiral represent?
IN सर्पिल मॉडल में, सर्पिल का 'रेडियल आयाम' क्या दर्शाता है?
A
Number of developers working at any given time किसी भी समय काम करने वाले डेवलपर्स की संख्या
B
Cumulative cost incurred for the project up to that point उस बिंदु तक परियोजना के लिए संचयी लागत
C
Elapsed calendar time from project initiation परियोजना आरंभ से बीता हुआ कैलेंडर समय
D
Number of requirements successfully implemented आवश्यकताओं की संख्या सफलतापूर्वक कार्यान्वित की गई
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In Boehm's Spiral model diagram, the angular dimension represents progress through each phase within a cycle, while the radial dimension represents the cumulative cost expended. Moving outward means spending more money.
व्याख्या (हिन्दी) बोहेम के सर्पिल मॉडल आरेख में, कोणीय आयाम एक चक्र के भीतर प्रत्येक चरण के माध्यम से प्रगति का प्रतिनिधित्व करता है, जबकि रेडियल आयाम खर्च की गई संचयी लागत का प्रतिनिधित्व करता है। बाहर जाने का मतलब है अधिक पैसा खर्च करना।
2158
EN + हिं Medium
GB How does the Spiral model handle the scenario where risk analysis determines a project should be cancelled?
IN स्पाइरल मॉडल उस परिदृश्य को कैसे संभालता है जहां जोखिम विश्लेषण यह निर्धारित करता है कि किसी परियोजना को रद्द कर दिया जाना चाहिए?
A
Spiral model does not allow project cancellation स्पाइरल मॉडल प्रोजेक्ट रद्द करने की अनुमति नहीं देता है
B
Cancellation is an explicit legitimate outcome after risk analysis — stopping a high-risk unviable project is treated as success जोखिम विश्लेषण के बाद रद्दीकरण एक स्पष्ट वैध परिणाम है - एक उच्च जोखिम वाली अव्यवहार्य परियोजना को रोकना सफलता के रूप में माना जाता है
C
Cancellation requires board approval outside the Spiral process रद्दीकरण के लिए स्पाइरल प्रक्रिया के बाहर बोर्ड की मंजूरी की आवश्यकता होती है
D
Spiral escalates to Waterfall mode if cancellation criteria are met यदि रद्दीकरण मानदंड पूरे होते हैं तो स्पाइरल वॉटरफॉल मोड में बढ़ जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) One of Spiral's most underappreciated features is that it formally recognises project cancellation as valid. If risk analysis reveals the project cannot achieve acceptable risk levels within budget, cancelling is the correct decision — saving further wasted investment.
व्याख्या (हिन्दी) स्पाइरल की सबसे कम सराही गई विशेषताओं में से एक यह है कि यह औपचारिक रूप से परियोजना रद्दीकरण को वैध मानता है। यदि जोखिम विश्लेषण से पता चलता है कि परियोजना बजट के भीतर स्वीकार्य जोखिम स्तर हासिल नहीं कर सकती है, तो रद्द करना सही निर्णय है - आगे बर्बाद निवेश को बचाना।
2159
EN + हिं Medium
GB What is 'risk-driven prototyping' in the Spiral model, and how does it differ from requirements-driven prototyping?
IN स्पाइरल मॉडल में 'जोखिम-संचालित प्रोटोटाइप' क्या है, और यह आवश्यकताओं-संचालित प्रोटोटाइप से कैसे भिन्न है?
A
Risk-driven builds entire system first; requirements-driven builds only UI mockups जोखिम-संचालित पहले संपूर्ण सिस्टम का निर्माण करता है; आवश्यकताओं-संचालित केवल यूआई मॉकअप बनाता है
B
Risk-driven targets highest-risk unknowns to resolve them; requirements-driven builds prototypes to elicit and clarify user requirements जोखिम-संचालित लक्ष्य उच्चतम-जोखिम वाले अज्ञात लोगों को हल करने के लिए; आवश्यकताओं-संचालित उपयोगकर्ता की आवश्यकताओं को जानने और स्पष्ट करने के लिए प्रोटोटाइप बनाता है
C
Risk-driven uses formal mathematical proofs; requirements-driven uses informal walkthroughs जोखिम-संचालित औपचारिक गणितीय प्रमाणों का उपयोग करता है; आवश्यकता-संचालित अनौपचारिक वॉकथ्रू का उपयोग करता है
D
Both terms describe the same activity दोनों शब्द एक ही गतिविधि का वर्णन करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In the Spiral model, prototypes are built to resolve highest-priority risks — not just to clarify requirements. A risk might be technical (can we achieve required performance?) or algorithmic. This differs from exploratory prototyping where the goal is requirements elicitation.
व्याख्या (हिन्दी) स्पाइरल मॉडल में, प्रोटोटाइप सर्वोच्च-प्राथमिकता वाले जोखिमों को हल करने के लिए बनाए जाते हैं - न कि केवल आवश्यकताओं को स्पष्ट करने के लिए। जोखिम तकनीकी हो सकता है (क्या हम आवश्यक प्रदर्शन प्राप्त कर सकते हैं?) या एल्गोरिथम। यह खोजपूर्ण प्रोटोटाइप से भिन्न है जहां लक्ष्य आवश्यकताओं को प्राप्त करना है।
2160
EN + हिं Medium
GB A hospital system using Spiral reveals that real-time data sync is technically infeasible within budget during cycle 3. What should happen?
IN स्पाइरल का उपयोग करने वाली एक अस्पताल प्रणाली से पता चलता है कि चक्र 3 के दौरान बजट के भीतर वास्तविक समय डेटा सिंक तकनीकी रूप से असंभव है। क्या होना चाहिए?
A
Development team must implement it anyway and request a retroactive budget increase विकास दल को इसे वैसे भी लागू करना होगा और पूर्वव्यापी बजट वृद्धि का अनुरोध करना होगा
B
The risk finding should trigger stakeholder negotiation to revise requirement, increase budget, or reduce scope जोखिम खोज को आवश्यकता को संशोधित करने, बजट बढ़ाने या दायरे को कम करने के लिए हितधारक बातचीत को ट्रिगर करना चाहिए
C
Project must restart from cycle one with different technology प्रोजेक्ट को अलग-अलग तकनीक के साथ चक्र एक से पुनः आरंभ करना होगा
D
Spiral requires implementing a workaround even when risks are unacceptable जोखिम अस्वीकार्य होने पर भी स्पाइरल को वर्कअराउंड लागू करने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) This is exactly the scenario the Spiral model is designed for. Risk analysis revealing infeasibility triggers a formal review with stakeholders who can decide: relax the requirement, increase budget, use a different approach, or cancel.
व्याख्या (हिन्दी) स्पाइरल मॉडल बिल्कुल इसी परिदृश्य के लिए डिज़ाइन किया गया है। जोखिम विश्लेषण से अव्यवहार्यता का पता चलने पर हितधारकों के साथ एक औपचारिक समीक्षा शुरू हो जाती है जो निर्णय ले सकते हैं: आवश्यकता में ढील दें, बजट बढ़ाएं, एक अलग दृष्टिकोण का उपयोग करें, या रद्द करें।
2146–2160 of 2726