बैंकिंग IT प्रोजेक्ट्स में SDLC: Models, Testing और Governance (CAIIB ITDB 2026)
बैंकिंग IT प्रोजेक्ट्स में SDLC वह structured, phase-by-phase process है जिसे बैंक किसी भी IT सिस्टम को plan, build, test और roll out करने के लिए फॉलो करते हैं — चाहे वह core banking upgrade हो या नया mobile banking module। CAIIB ITDB के उम्मीदवारों के लिए यह topic software engineering और banking operations के बीच का point है: examiners यह उम्मीद करते हैं कि आपको phases पता हों, अलग-अलग तरह के प्रोजेक्ट्स के लिए बैंक जो models चुनते हैं, testing के वे stages जो customer के पैसे की सुरक्षा करते हैं, और वे governance controls जो IT change को नियंत्रण में रखते हैं। यह गाइड इन चारों को exam-ready depth में कवर करती है, और इसे आप Introduction To Software और Information Technology And Its Implications जैसे foundational chapters के साथ पढ़कर underlying concepts मजबूत कर सकते हैं।
🔄 SDLC क्या है और बैंक इसे क्यों फॉलो करते हैं
Software Development Life Cycle (SDLC) उन stages का sequence है जिनसे गुजरकर बैंक की IT team और vendors किसी business need को एक working, tested सिस्टम में बदलते हैं। आमतौर पर पढ़ाए जाने वाले phases हैं: requirement gathering and analysis, system design, coding/development, testing, implementation (deployment/go-live), और maintenance। कुछ frameworks शुरुआत में एक feasibility या planning stage और अंत में एक formal post-implementation review भी जोड़ते हैं।
बैंक IT प्रोजेक्ट्स को informal coding exercises की तरह treat नहीं कर सकते क्योंकि इनमें शामिल सिस्टम deposits, loans, payments और regulatory reporting को touch करते हैं। यदि कोई defect core banking या payment system में production तक पहुंच जाए, तो गलत interest posting, failed settlements, या हजारों accounts में reconciliation breaks हो सकते हैं। एक defined SDLC फॉलो करने से बैंक को एक repeatable, auditable trail मिलता है — किसने कौन-सी requirement approve की, किसने कौन-सा scenario test किया, और go-live से पहले किसने sign-off दिया। यही कारण है कि IT audit teams और regulators यह उम्मीद करते हैं कि हर महत्वपूर्ण बैंक IT प्रोजेक्ट — चाहे in-house बना हो या किसी vendor के जरिए — किसी documented SDLC policy को फॉलो करे, न कि ad-hoc build-and-fix approach को।
SDLC business involvement के लिए natural checkpoints भी बनाता है। Branch operations staff, compliance और risk teams को requirements review करने और outputs validate करने का formal मौका मिलता है, बजाय इसके कि problems केवल system live होने के बाद पता चलें। यह structured involvement ही एक कारण है जिसकी वजह से SDLC discipline CAIIB ITDB assessments में बार-बार आता है — यह जितना technical topic है, उतना ही governance topic भी है।
💡 Exam Tip: अगर कोई question यह describe करे कि "user needs को एक written specification में convert किया जाता है," तो यह आपको requirement analysis phase पर test कर रहा है — design पर नहीं। Phase को उसके output document से match करें, सिर्फ नाम से नहीं।
📊 बैंक IT प्रोजेक्ट्स में इस्तेमाल होने वाले SDLC Models
एक ही छह phases को प्रोजेक्ट के हिसाब से अलग-अलग तरीके से arrange किया जा सकता है। Waterfall model हर phase को strictly sequence में चलाता है — design तब तक शुरू नहीं हो सकता जब तक requirements sign off न हो जाएं, और testing तब तक शुरू नहीं होती जब तक coding पूरी न हो जाए। यह उन प्रोजेक्ट्स के लिए उपयुक्त है जिनकी requirements स्थिर और अच्छी तरह समझी गई हों, जैसे कि fixed regulatory format वाला कोई statutory reporting change।
V-Model इसी का एक variant है जो हर development phase को एक corresponding testing/validation phase के साथ pair करता है — requirements acceptance testing से map होती हैं, design system testing से, और इसी तरह आगे। चूंकि यह test planning को requirement analysis जितना early शुरू करने पर मजबूर करता है, बैंक इसे उन प्रोजेक्ट्स के लिए पसंद करते हैं जिनमें भारी compliance और audit scrutiny होती है, जैसे core banking system (CBS) में बदलाव।
Iterative और Spiral models सिस्टम को repeated cycles में बनाते हैं, हर cycle में functionality जोड़ी जाती है और risk को फिर से देखा जाता है। Spiral हर loop में explicitly एक risk-analysis step जोड़ता है, जो large, high-uncertainty प्रोजेक्ट्स जैसे किसी पूरे CBS migration के लिए उपयुक्त है, जहां प्रोजेक्ट आगे बढ़ने के साथ requirements बदल सकती हैं।
Agile model काम को छोटे sprints में बांटता है जिसमें customer/business से continuous feedback मिलता रहता है, और यह exhaustive upfront documentation के बजाय working software को प्राथमिकता देता है। बैंक अब customer-facing digital channels — mobile banking apps, UPI-linked features, internet banking enhancements — के लिए Agile का इस्तेमाल बढ़ा रहे हैं, जहां user experience में बार-बार tuning की जरूरत होती है। इन models के पीछे के computing concepts की गहरी जानकारी के लिए Introduction To Computing और Computer Languages And Operating Systems देखें।
| SDLC Model | Approach | Typical Banking Use | Heavy Upfront Documentation Needed |
|---|---|---|---|
| Waterfall | Strict sequential phases | Fixed-scope regulatory/reporting changes | ✅ Yes |
| V-Model | Each phase paired with a test level | Core banking system changes, CBS migration | ✅ Yes |
| Spiral / Iterative | Repeated cycles with risk review | Large, evolving projects with high uncertainty | ❌ No (evolves per cycle) |
| Agile | Short sprints, continuous feedback | Mobile/internet banking, digital channel features | ❌ No (lightweight, adaptive) |
📌 Note: हर बैंक प्रोजेक्ट के लिए कोई एक model "सही" नहीं होता। Examiners अक्सर यह test करते हैं कि क्या आप किसी प्रोजेक्ट के description (fixed regulatory deadline बनाम evolving customer-facing feature) को सबसे उपयुक्त model से match कर सकते हैं, न कि सिर्फ models को अलग-अलग define कर सकते हैं।
🧪 बैंक सिस्टम के Go Live होने से पहले Testing के Stages
बैंकिंग IT प्रोजेक्ट में testing layered होती है, और हर layer एक अलग तरह का defect पकड़ती है। Unit testing developers individual modules या functions पर करते हैं। Integration testing यह check करती है कि modules — जैसे loan module और accounting/general ledger module — आपस में data सही तरीके से exchange करते हैं या नहीं। System testing पूरे, assembled application को functional specification के against end to end validate करती है।
Security testing, जिसमें vulnerability assessment और penetration testing शामिल है, उन सभी चीजों के लिए non-negotiable है जो payments, credentials या customer data को touch करती हैं, क्योंकि banking systems attackers के लिए कितने आकर्षक target होते हैं। Performance और load testing यह check करती है कि सिस्टम peak transaction volumes — month-end salary credits, festival-season payment spikes — में टिकता है या नहीं, न कि सिर्फ normal daily load में।
User Acceptance Testing (UAT) वह stage है जहां business users — branch staff, operations teams, product owners — सिस्टम को real banking scenarios के against test करते हैं और go-live से पहले formally sign off करते हैं। UAT sign-off आमतौर पर deployment से पहले का आखिरी gate होता है, और इसका अभाव बैंक प्रोजेक्ट्स में सबसे common IT audit findings में से एक है।
Core banking जैसे critical systems के लिए, कई बैंक parallel run भी चलाते हैं — यानी कुछ समय के लिए पुराने और नए सिस्टम को साथ-साथ चलाना और outputs compare करना — पूरी तरह cut over करने से पहले। यह qualitative safeguard big-bang failure के risk को कम करता है। Go-live के बाद, जब भी कोई patch या change apply किया जाता है, regression testing दोहराई जाती है, ताकि यह confirm हो सके कि existing functionality अभी भी सही काम कर रही है। Reports और data migration के लिए database-heavy testing भी Database Management Systems में दिए concepts पर निर्भर करती है।
⚠️ Caution: UAT को system testing के साथ confuse न करें। System testing IT/QA team द्वारा specification के against चलाई जाती है; UAT business users द्वारा real-world usage के against चलाई जाती है, और सिर्फ UAT sign-off ही go-live को authorise करता है।
🛡️ Governance, Change Management और IS Audit Controls
कोई भी SDLC तभी मजबूत होता है जब उसके चारों ओर governance मजबूत हो। ज्यादातर बैंक senior level पर एक IT Steering Committee रखते हैं जो major IT projects को prioritise और oversee करती है, और एक Change Advisory Board (CAB) या equivalent change management forum रखते हैं जो production environment में move होने से पहले हर change को review और approve करता है। इससे unreviewed code का live systems तक पहुंचना रुकता है।
Segregation of duties एक core control है: जो developers code लिखते या modify करते हैं, उनके पास उस code को production में move करने के rights नहीं होने चाहिए, और production access आमतौर पर एक separate deployment/operations team तक सीमित रखा जाता है। हर release के साथ एक documented roll-back या back-out plan होना चाहिए ताकि deployment से issues आने पर बैंक जल्दी revert कर सके।
Source code का version control, साथ ही structured documentation — Business Requirement Documents, Functional and System Requirement Specifications, test plans, और UAT sign-off records — वह audit trail बनाते हैं जिसे internal और statutory IS auditors review करते हैं। बैंकों के IT governance frameworks, regulatory expectations के अनुरूप, यह मांग करते हैं कि यह documentation प्रोजेक्ट की पूरी life में maintain की जाए, न कि audit से ठीक पहले retrospectively बनाई जाए।
जहां प्रोजेक्ट्स में external vendors शामिल होते हैं, वहां outsourcing और vendor-risk management controls भी लागू होते हैं — भले ही development outsource किया गया हो, delivered system की quality और security की जिम्मेदारी बैंक की ही रहती है। एक structured post-implementation review, जो go-live के कुछ समय बाद conducted की जाती है, यह check करके loop को बंद करती है कि क्या प्रोजेक्ट ने अपने original objectives पूरे किए और क्या किसी residual issue पर follow-up चाहिए।
💡 Exam Tip: Governance-focused questions अक्सर इस पर टिके होते हैं कि "production में move करने को कौन approve करता है" (Change Advisory Board / change management process) बनाम "functionality को कौन test करता है" (QA/business users) — अपने notes में इन roles को अलग-अलग रखें।
📝 वह Documentation जो बैंक IT प्रोजेक्ट को Anchor करती है
बैंक प्रोजेक्ट में हर SDLC phase एक document बनाता है जो audit trail का हिस्सा बनता है। Requirement analysis से एक Business Requirement Document (BRD) और अक्सर एक Functional Requirement Specification (FRS) बनती है। Design से एक System Requirement Specification (SRS) या detailed design document बनता है जो screens, data flows और interfaces describe करता है। Testing phase से test plans, test cases, और defect logs बनते हैं, जो implementation से पहले एक formal UAT sign-off certificate पर culminate होते हैं।
यह paper trail तीन कारणों से मायने रखता है। पहला, यह किसी नए team member या auditor को यह reconstruct करने देता है कि go-live के महीनों या सालों बाद भी सिस्टम उस तरह क्यों behave करता है। दूसरा, यह वह primary evidence है जिसे IS auditors और regulators यह assess करते समय देखते हैं कि बैंक की IT governance effective है या नहीं — एक strong SDLC के साथ अगर documentation कमजोर हो, तो compliant होना demonstrate करना मुश्किल हो जाता है। तीसरा, यह बैंक को operationally protect करता है: जब production में कोई defect सामने आता है, तो structured documentation support teams को उस exact requirement, design decision, या test gap तक issue को trace करने देती है जो उसे miss कर गया था, न कि सिर्फ अंदाजा लगाने देती है।
Candidates को इसे Hardware, Software, Networking And Data Communications और Networking Systems के तहत कवर की गई hardware और networking dependencies से भी जोड़ना चाहिए, क्योंकि deployment और rollback plans को सिर्फ application code नहीं बल्कि उस infrastructure का भी ध्यान रखना होता है जिस पर नया सिस्टम चलता है।
🧠 Practice MCQs: बैंकिंग IT प्रोजेक्ट्स में SDLC
Q1. कौन-सा SDLC model phases को strict sequential order में execute करता है, जहां बाद वाला phase तब तक शुरू नहीं हो सकता जब तक पहले वाला पूरी तरह sign off न हो जाए? (a) Agile model (b) Waterfall model (c) Spiral model (d) Rapid Application Development
Answer: (b) - Waterfall model phases का एक fixed, sequential order फॉलो करता है जिसमें कोई overlap नहीं होता।
Q2. किसी बैंक के core banking migration प्रोजेक्ट में, कौन-सा testing stage मुख्य रूप से IT/vendor team के बजाय business users और branch staff द्वारा conduct किया जाता है? (a) Unit testing (b) Integration testing (c) User Acceptance Testing (UAT) (d) Code review
Answer: (c) - UAT business users द्वारा go-live sign-off से पहले real banking scenarios को validate करते हुए perform की जाती है।
Q3. SDLC में V-Model को इस रूप में सबसे अच्छा describe किया जाता है कि यह हर development phase को किससे pair करता है: (a) Marketing phase (b) Testing/validation phase (c) Budgeting phase (d) Vendor selection phase
Answer: (b) - V-Model हर development phase को एक matching test level से map करता है, जैसे requirements को acceptance testing से।
Q4. Evolving requirements और frequent releases की जरूरत वाले बैंक IT प्रोजेक्ट, जैसे mobile banking app, के लिए कौन-सा SDLC model सबसे उपयुक्त है? (a) Waterfall (b) Big Bang model (c) Agile model (d) Pure V-Model
Answer: (c) - Agile के छोटे sprints और continuous feedback fast-changing, customer-facing digital projects के लिए उपयुक्त होते हैं।
Q5. IT project governance में, कौन-सी body आमतौर पर बैंक के production environment में changes के move होने से पहले उन्हें review और approve करती है? (a) Marketing department (b) Change Advisory Board / change management committee (c) HR department (d) Branch manager अकेले
Answer: (b) - Change Advisory Board या equivalent forum production deployment से पहले changes को authorise करता है, जिससे segregation of duties लागू होती है।
Chapter-wise mock tests चाहिए 100+ MCQs के साथ? Start practising free
बैंकिंग IT प्रोजेक्ट में SDLC के मुख्य phases क्या हैं?
आमतौर पर पढ़ाए जाने वाले phases हैं requirement gathering and analysis, system design, coding/development, testing, implementation (go-live), और maintenance, जिनसे पहले कभी-कभी एक feasibility/planning stage भी होता है।
Core banking system upgrades के लिए बैंक कौन-सा SDLC model इस्तेमाल करते हैं?
Core banking में बदलाव के लिए Waterfall या V-Model जैसे structured models आम हैं, क्योंकि इनमें heavy documentation और formal sign-off requirements होती हैं, हालांकि बड़े migrations evolving risk को manage करने के लिए Spiral/iterative approach भी अपना सकते हैं।
System testing और User Acceptance Testing (UAT) में क्या फर्क है?
System testing IT/QA team द्वारा technical specification के against perform की जाती है, जबकि UAT business users द्वारा real-world scenarios के against perform की जाती है; UAT sign-off आमतौर पर go-live से पहले का आखिरी gate होता है।
बैंकों के लिए SDLC में change management क्यों महत्वपूर्ण है?
Change management, Change Advisory Board या इसी तरह के किसी forum के जरिए, यह सुनिश्चित करता है कि production तक पहुंचने से पहले हर change review और approve हो, जिससे segregation of duties लागू होती है और customer accounts को प्रभावित करने वाले unauthorised या untested changes का risk कम होता है।
SDLC के phases, models, testing layers और governance controls को सही तरीके से समझना CAIIB ITDB के सबसे scoring areas में से एक है, क्योंकि एक बार आप "क्या बनाया जा रहा है," "इसे कैसे test किया जाता है," और "इसे कौन approve करता है" को अलग-अलग कर लें, तो logic consistent हो जाती है। Linked chapters दोबारा देखें, OSI model in banking networks और digital signature in banking जैसे related topics पर काम करें, और देखें कि SDLC governance risk management की तरफ expected credit loss framework जैसे risk topics से कैसे जुड़ता है। ज्यादा subject coverage के लिए Information Technology and Digital Banking elective articles देखें, या database management systems in banking पर related reads पढ़ें। फिर अपनी preparation को full-length practice के साथ lock in करें: explore the CAIIB course या आज ही take a free mock test।
Quick quiz on this topic
5 exam-style questions from our free test bank — check yourself before you move on.
Practice this topic
मुफ़्त मॉक टेस्ट दें, चैप्टर PDF डाउनलोड करें या वीडियो क्लास देखें — सब iibf.store पर मुफ़्त है।
