SDLC Models and Methodologies
1. What is the SDLC, and what are its typical phases?
SDLC হলো একটি structured process বা framework, যা কোনো software তৈরি করার সময় অনুসরণ করা হয়। এটি একটি software কে idea থেকে শুরু করে সম্পূর্ণ deployment এবং maintenance পর্যন্ত পুরো journey কে systematic ভাবে পরিচালনা করার জন্য ব্যবহৃত হয়। SDLC অনুসরণ করলে software এর quality ভালো হয়, cost এবং time কমে যায়, এবং team members দের মধ্যে coordination সহজ হয়।
PreviewClick to view details
Business idea
|
v
Requirements -> Design -> Development -> Testing -> Release -> Maintenance
^ |
|---------------- feedback / change --------------------|
বাস্তবে phase- গুলো সবসময় একবার করে শেষ হয় না। Modern team feedback পেলে requirements, design, বা code-এ ফিরে যায়। Model-এর পার্থক্য মূলত এই feedback loop কত দ্রুত এবং কত formal।
SDLC-এর typical phases
i. Requirement Analysis (Planning) এই phase-এ client বা stakeholder দের সাথে কথা বলে বোঝা হয় যে তারা আসলে কী চায়। Business requirements, user needs, এবং project এর feasibility নিয়ে বিস্তারিত analysis করা হয়।
ii. Design Requirement gathering শেষ হওয়ার পর system এর architecture তৈরি করা হয়। এখানে database design, UI/UX design, system architecture, এবং technical specifications ঠিক করা হয়।
iii. Implementation (Coding/Development) এই phase-এ team design ও acceptance criteria অনুযায়ী code/configuration তৈরি করে। কোন phase সবচেয়ে বেশি সময় নেবে তা product, domain, reuse এবং operational context-এর ওপর নির্ভর করে।
iv. Testing Verification পুরো lifecycle জুড়েই হওয়া উচিত: developer code-এর সঙ্গে unit test লেখে, integration/system test increment যাচাই করে এবং acceptance activity stakeholder need validate করে। Sequential model-এ dedicated test phase পরে হতে পারে, কিন্তু testing শুধু coding শেষের কাজ নয়।
v. Deployment Testing সফলভাবে সম্পন্ন হওয়ার পর software টি production environment-এ release করা হয়, যেখানে actual end-user রা এটি ব্যবহার করতে পারবেন।
vi. Maintenance Deployment এর পরও software এর কাজ শেষ হয় না। এই phase-এ bug fixes, updates, performance improvements, এবং নতুন feature addition করা হয় প্রয়োজন অনুযায়ী।
Phase মানে strict handoff না
একজন developer requirements বুঝতে গিয়ে ambiguity ধরতে পারে। QA test করতে গিয়ে missing rule ধরতে পারে। তাই healthy team-এ সবাই quality নিয়ে কাজ করে, যদিও ownership আলাদা।
Product owner: "Free delivery কখন?"
Developer: "Minimum order amount দরকার।"
QA: "Coupon + free delivery একসাথে হলে কী হবে?"
Result: clearer requirement before production bug.
What are the key deliverables or artifacts typically produced at each phase of the SDLC?
১. Requirement Analysis (Planning)
- Software Requirement Specification (SRS) document — এটি সবচেয়ে গুরুত্বপূর্ণ deliverable, যেখানে functional এবং non-functional requirements লেখা থাকে
- Feasibility Study Report — project টি technically, economically এবং operationally সম্ভব কিনা তার analysis
- Project Plan — timeline, resource allocation, budget estimation
- Use Case Documents — user রা system এর সাথে কীভাবে interact করবে তার description
২. Design
- High-Level Design (HLD) document — overall system architecture, module breakdown, technology stack
- Low-Level Design (LLD) document — প্রতিটি module এর internal logic, algorithm, class diagrams
- Database Design (ER diagrams, schema)
- UI/UX Wireframes বা Mockups
- System Architecture Diagrams
৩. Implementation (Coding/Development)
- Source Code — actual codebase
- Unit Test Cases — developer রা নিজেদের code test করার জন্য যে test লেখেন
- Code Documentation — comments, technical documentation, API documentation
- Build files এবং version control commits (Git repository)
৪. Testing
- Test Plan document — কী কী test করা হবে তার outline
- Test Cases এবং Test Scripts
- Bug/Defect Reports — কোন কোন bug পাওয়া গেছে তার list
- Test Summary Report — testing এর ফলাফল কী দাঁড়ালো
- UAT Sign-off — client বা end-user দের approval
৫. Deployment
- Deployment Plan/Checklist
- Release Notes — নতুন version-এ কী কী change বা feature আছে
- Installation/Configuration Guide
- User Manual/Training Documents
৬. Maintenance
- Bug Fix Logs
- Change Request Documents
- System Performance Reports
- Updated Documentation (নতুন feature বা patch অনুযায়ী)
2. What is the Waterfall model, and what are its sequential phases?
Waterfall Model হলো SDLC এর সবচেয়ে পুরনো এবং সবচেয়ে traditional model। এটি একটি linear এবং sequential approach, যেখানে একটি phase সম্পূর্ণভাবে শেষ না হওয়া পর্যন্ত পরের phase শুরু হয় না — অনেকটা ঝর্ণা (waterfall) থেকে পানি নিচের দিকে একটি নির্দিষ্ট ধারায় পড়ার মতো, তাই এই নাম।
Sequential Phases:
- Requirement Analysis — সব requirement আগে থেকেই সম্পূর্ণভাবে gather এবং document করা হয়
- System Design — requirement অনুযায়ী পুরো architecture এবং design চূড়ান্ত করা হয়
- Implementation (Coding) — design অনুযায়ী code লেখা হয়
- Testing — সম্পূর্ণ system একসাথে test করা হয়
- Deployment — software client বা production-এ release করা হয়
- Maintenance — deployment এর পর bug fix এবং updates করা হয়
প্রতিটি phase এর একটি নি র্দিষ্ট output থাকে, যা পরের phase এর input হিসেবে কাজ করে, এবং সাধারণত আগের phase-এ ফিরে যাওয়ার সুযোগ থাকে না (বা খুবই সীমিত)।
What are the main advantages and disadvantages of the Waterfall model?
Advantages:
- Simple এবং সহজে understand করা যায় — structure টা straightforward
- Clear milestones এবং deliverables থাকে প্রতিটি phase-এ, তাই progress track করা সহজ
- Documentation heavy — প্রতিটি phase এ বিস্তারিত document তৈরি হয়, যা future reference এর জন্য useful
- Discipline বজায় থাকে — একটি phase শেষ না হলে পরেরটায় যাওয়া যায় না, তাই process টা organized থাকে
- Budget এবং timeline আগে থেকেই ভালোভাবে estimate করা যায়
Disadvantages:
- Flexibility কম — requirement change হলে সেটা handle করা কঠিন এবং costly
- Testing শুরু হয় শুধু development শেষ হওয ়ার পর, তাই bugs বা design flaws অনেক দেরিতে ধরা পড়ে
- Client বা end-user রা final product না দেখা পর্যন্ত feedback দেওয়ার সুযোগ পান না
- High risk এবং uncertainty — যদি শুরুতে কোনো requirement ভুল বোঝা যায়, তাহলে সেটা পুরো project কে প্রভাবিত করে
- Complex এবং long-term project এর জন্য উপযুক্ত নয়
In what kinds of projects is Waterfall still a reasonable choice?
Waterfall মডেল এখনও নিচের ক্ষেত্রে ভালো কাজ করে:
- Requirements পুরোপুরি clear এবং fixed থাকলে, যেখানে project চলাকালীন change হওয়ার সম্ভাবনা কম
- Small এবং short-duration projects, যেখানে complexity কম
- যেসব project-এ regulatory বা compliance requirement আছে এবং প্রতিটি phase এর জন্য বিস্তারিত documentation বাধ্যতামূলক (যেমন: government contracts, defense projects)
- Well-understood domain এর project, যেখানে technology এবং solution আগে থেকেই প্রমাণিত (proven)
- যেখানে client বা stakeholder মাঝপথে requirement পরিবর্তন করবেন না বলে নিশ্চিত
- Hardware-dependent projects, যেখানে software আর hardware একসাথে develop করতে হয় এবং পরবর্তীতে change করা expensive
What is the V-model, and how does it extend Waterfall by pairing each development phase with a corresponding testing phase?
V-Model (Verification and Validation Model) হলো Waterfall model এর একটি extension, যেখানে প্রতিটি development phase এর সাথে একটি corresponding testing phase যুক্ত করা হয়। এই কারণে diagram টি "V" আকৃতির হয় — বাম দিকে development phases নিচের দিকে নামে, আর ডান দিকে testing phases উপরের দিকে ওঠে।
V-Model এ প্রতিটি Development Phase এর সাথে Testing Phase এর Pairing:
| Development Phase (বাম পাশ) | Corresponding Testing Phase (ডান পাশ) |
|---|---|
| Requirement Analysis | Acceptance Testing (UAT) |
| System Design | System Testing |
| High-Level Design (Architecture) | Integration Testing |
| Low-Level Design (Module Design) | Unit Testing |
| Coding | (Bottom of the V — যেখানে development এবং testing মিলিত হয়) |
V-Model কীভাবে Waterfall কে Extend করে:
- Waterfall-এ testing শুধু coding শেষ হওয়ার পর একটি আলাদা phase হিসেবে হয়, কিন্তু V-Model-এ প্রতিটি development phase এর জন্য একটি নির্দিষ্ট test plan আগে থেকেই তৈরি করা হয় — অর্থাৎ testing কে development এর সাথে সমান্তরালভাবে (parallel) plan করা হয়
- এতে early defect detection সম্ভব হয়, কারণ requirement বা design এর ভুল coding শুরু হওয়ার আগেই ধরা পড়ার সুযোগ থাকে
- এটি Verification (আমরা কি সঠিকভাবে product টা বানাচ্ছি? - "Are we building the product right?") এবং Validation (আমরা কি সঠিক product টা বানাচ্ছি? - "Are we building the right product?") — এই দুটো বিষয়কে শক্তভাবে emphasize করে
- Waterfall এর মতোই V-Model ও rigid এবং sequential, তাই flexibility এর দিক থেকে একই ধরনের limitation থেকে যায়, কিন্তু quality assurance অনেক বেশি strong হয়
3. What is the Iterative and Incremental model, and how does it differ from Waterfall?
Iterative and Incremental Model হলো এমন একটি SDLC approach, যেখানে পুরো software টি একবারে সম্পূর্ণভাবে তৈরি না করে, ছোট ছোট অংশে ভাগ করে repeated cycles বা iterations এর মাধ্যমে ধীরে ধীরে তৈরি করা হয়। প্রতিটি iteration-এ requirement analysis, design, coding, এবং testing — এই সবগুলো mini-phase পার হয়ে একটি working version তৈরি হয়, যা আগের version এর উপর নতুন feature যোগ করে।
এখানে দুটো concept একসাথে কাজ করে:
- Iterative — একই feature বা module কে বারবার refine করা হয়, feedback এর ভিত্তিতে
- Incremental — নতুন নতুন feature বা module ধাপে ধাপে যোগ করে পুরো system টি সম্পূর্ণ করা হয়
Waterfall থেকে মূল পার্থক্য:
| বিষয় | Waterfall | Iterative and Incremental |
|---|---|---|
| Approach | Linear এবং sequential — একবার একটি phase | Cyclical — একই phase গুলো বারবার repeat হয় |
| Requirement | শুরুতেই সম্পূর্ণভাবে fix করতে হয় | ধীরে ধীরে evolve করতে পারে, প্রতিটি iteration-এ refine করা যায় |
| Delivery | পুরো software একবারে শেষে deliver হয় | ছোট ছোট working version বারবার deliver হয় |
| Client Feedback | শুধু শেষে পাওয়া যায় | প্রতিটি iteration এর শেষে পাওয়া যায় |
| Flexibility | কম, change করা কঠিন এবং costly | বেশি, change কে accommodate করা তুলনামূলক সহজ |
| Risk Detection | দেরিতে ধরা পড়ে (testing phase-এ) | early stage-এই ধরা পড়ে, কারণ প্রতিটি iteration test হয় |
| Testing | একবারে, শেষ দিকে | প্রতিটি iteration-এ আলাদাভাবে |
How does delivering the system in increments help reduce overall project risk?
Increment আকারে software deliver করলে risk কমার পেছনে কয়েকটি কারণ কাজ করে:
১. Early এবং Frequent Feedback প্রতিটি increment এর পরে client বা end-user রা actual working software দেখতে পান এবং feedback দিতে পারেন। ফলে requirement misunderstanding থাকলে সেটা প্রথম দিকেই ধরা পড়ে, পুরো project শেষ হওয়ার পর নয়।
২. Early Detection of Technical Problems Design flaw, architecture issue, বা integration problem গুলো প্রথম কয়েকটি increment-এই সামনে চলে আসে, যেখানে সেগুলো fix করা তুলনামূলক সহজ এবং কম খরচের। Waterfall-এ এই ধরনের সমস্যা শেষ দিকে ধরা পড়লে fix করা অনেক costly এবং time-consuming হয়ে যায়।
৩. Small, Manageable Chunks পুরো project কে ছোট ছোট increment-এ ভাগ করার ফলে প্রতিটি অংশ নিয়ে কাজ করা এবং manage করা সহজ হয়। একটি increment fail করলে পুরো project এর উপর সেটার প্রভাব সীমিত থাকে, পুরো project ভেঙে পড়ে না।
৪. Flexibility to Adapt Market condition, business priority, বা technology change হলে পরবর্তী increment গুলোতে সেই change সহজেই accommodate করা যায়। Waterfall-এ requirement change মানেই বড় ধরনের rework।
৫. Continuous Testing প্রতিটি increment আলাদাভাবে test হওয়ার কারণে bug গুলো ছোট ছোট আকারে ধরা পড়ে এবং early fix করা যায়, যার ফলে শেষ দিকে বড় ধরনের critical bug জমা হয়ে যাওয়ার সম্ভাবনা কমে যায়।
৬. Demonstrable Progress এবং Stakeholder Confidence Regular increment deliver হওয়ার কারণে stakeholder রা project এর actual progress দেখতে পান, যা confidence বাড়ায় এবং project cancel বা budget cut হওয়ার risk কমায়।
৭. Reduced "All Eggs in One Basket" Risk Waterfall-এ পুরো project এর success নির্ভর করে শেষে একবারে সবকিছু ঠিকঠাক কাজ করার উপর। Iterative approach-এ risk টা বিভিন্ন increment জুড়ে distribute হয়ে যায়, ফলে একটি single point of failure এর কারণে পুরো project ব্যর্থ হওয়ার সম্ভাবনা কমে যায়।
4. What is the Spiral model, and how does it incorporate risk management into the SDLC?
Spiral Model হলো Barry Boehm প্রস্তাবিত একটি SDLC model, যা Waterfall model এর systematic, controlled approach এবং Iterative model এর flexibility — এই দুটোকে একসাথে combine করে, সাথে যোগ করে একটি শক্তিশালী risk analysis এবং risk management component। এটিকে "spiral" বলা হয় কারণ এর diagram টা দেখতে একটি ঘূর্ণায়মান spiral বা কুণ্ডলীর মতো, যেখানে প্রতিটি loop project এর একটি phase কে represent করে এবং কেন্দ্র থেকে বাইরের দিকে যত যাওয়া হয়, project তত বেশি matured এবং complete হতে থাকে।
Spiral Model-এ risk management টা কোনো আলাদা বা optional activity নয় — এটি প্রতিটি loop এর একটি core, mandatory অংশ। প্রতিটি iteration শুরু করার আগে সম্ভাব্য risk গুলো (technical risk, cost risk, schedule risk, ইত্যাদি) চিহ্নিত করা হয়, সেগুলোর impact analyze করা হয়, এবং সেই risk কমানোর জন্য prototype তৈরি, simulation, বা feasibility study করা হয়। যদি কোনো risk অত্যধিক বেশি মনে হয়, তাহলে সেই পর্যায়েই project বন্ ধ করে দেওয়ার সিদ্ধান্তও নেওয়া যেতে পারে — এতে বড় ধরনের ক্ষতি এড়ানো যায়।
How many "loops" or iterations does the Spiral model typically involve, and what activities happen in each?
Spiral Model-এ কোনো fixed সংখ্যক loop নির্ধারিত নেই — project এর size, complexity, এবং risk এর উপর ভিত্তি করে loop এর সংখ্যা কম-বেশি হতে পারে। তবে সাধারণত একটি typical project-এ ৪ থেকে ৬টি loop দেখা যায়। প্রতিটি loop-এর মধ্যে সাধারণত চারটি quadrant বা activity থাকে:
Quadrant ১: Objectives Determination (Planning) এই ধাপে সেই particular iteration এর জন্য objectives, requirements, এবং alternative solutions চিহ্নিত করা হয়। Constraints (cost, schedule, resource) ও নির্ধারণ করা হয়।
Quadrant ২: Risk Analysis and Resolution সম্ভাব্য risk গুলো identify এবং analyze করা হয়। প্রয়োজনে prototype তৈরি করা হয় risk verify করার জন্য। এটি Spiral Model এর সবচেয়ে গুরুত্বপূর্ণ এবং distinctive quadrant।
Quadrant ৩: Development and Testing এই ধাপে actual product develop করা হয় (design, coding) এবং সেটা test করা হয় — অনেকটা একটি mini Waterfall বা Iterative cycle এর মতো।
Quadrant ৪: Review and Planning for Next Iteration তৈরি হওয়া product/prototype client বা stakeholder দের কাছে review করানো হয়, feedback নেওয়া হয়, এবং পরবর্তী loop এর জন্য planning করা হয়।
এভাবে প্রতিটি loop শেষে project একটু একটু করে আরও matured এবং complete হতে থাকে, যতক্ষণ না final product সম্পূর্ণভাবে তৈরি হয়ে যায়।
How does the Spiral model differ from a simple iterative/incremental model?
| বিষয় | Iterative/Incremental Model | Spiral Model |
|---|---|---|
| মূল Focus | Feature বা module ধাপে ধাপে delivery করা | Risk identification এবং management কে কেন্দ্র করে project পরিচালনা |
| Risk Analysis | প্রতিটি iteration-এ formal risk analysis বাধ্যতামূলক নয় | প্রতিটি loop-এ explicit এবং formal risk analysis phase থাকে |
| Prototype ব্যবহার | সাধারণত ব্যবহার হয় না, বা optional | Risk কমানোর জন্য prototype তৈরি করা মূল কার্যক্রমের অংশ |
| Complexity | তুলনামূলক সহজ এবং কম formal | বেশি complex, বেশি formal এবং structured |
| উপযুক্ততা | Medium-size project, যেখানে requirement মোটামুটি জানা আছে | Large, high-risk, এবং high-cost project, যেখানে uncertainty বেশি |
| Decision Point | সাধারণত প্রতিটি iteration শেষে continue করার সিদ্ধান্ত হয় | প্রতিটি loop এর risk analysis এর পর project continue করবে না বন্ধ করবে সেই সিদ্ধান্তও নেওয়া হয় |
| Cost এবং Documentation | তুলনামূলক কম | বেশি, কারণ risk analysis, prototype তৈরি ইত্যাদির জন্য বাড়তি সময় ও খরচ লাগে |
সব Spiral project-ই iterative, কিন্তু সব iterative project Spiral নয় — কারণ Spiral Model-এ risk-driven approach টাই মূল ভিত্তি, যা এটিকে সাধারণ Iterative/Incremental model থেকে আলাদা করে তোলে। এই কারণে Spiral Model সাধারণত সেইসব project-এ ব্যবহার করা হয় যেখানে budget বেশি, risk বেশি, এবং failure এর cost অনেক বড় — যেমন বড় ধরনের enterprise system বা mission-critical software।
5. What is the Prototype model, and when is it useful?
Prototype Model হলো এমন একটি SDLC approach, যেখানে সম্পূর্ণ software তৈরি করার আগে একটি working sample বা prototype তৈরি করা হয়, যা মূল system এর সীমিত কিন্তু functional একটি version। এই prototype টি client বা end-user দের দেখানো হয়, তাদের কাছ থেকে feedback নেওয়া হয়, এবং সেই feedback এর ভিত্তিতে prototype টি refine করা হয় — যতক্ষণ না requirement গুলো পুরোপুরি clear এবং accurate হয়ে যায়। এরপর সেই finalized requirement অনুযায়ী actual, full-fledged system develop করা হয়।
Prototype Model এর সাধারণ Process:
- Basic requirement gathering
- Quick design তৈরি করা (focus থাকে core functionality এবং UI-তে, পুরো system এ নয়)
- Prototype তৈরি করা
- Client/user দের কাছ থেকে evaluation এবং feedback নেওয়া
- Feedback অনুযায়ী prototype refine করা (প্রয়োজনে বারবার)
- Requirement finalize হলে actual system develop করা
কখন Prototype Model Useful:
- যখন client নিজেও সঠিকভাবে জানেন না তারা আসলে কী চান — অর্থাৎ requirement গুলো vague বা unclear
- যখন system এর UI/UX অত্যন্ত গুরুত্বপূর্ণ এবং user experience আগে থেকে verify করা দরকার
- Complex এবং large system এর ক্ষেত্রে, যেখানে শুরুতে সব requirement বোঝা কঠিন
- যখন new বা innovative technology ব্যবহার করা হচ্ছে এবং সেটার feasibility আগে থেকে test করা দরকার
- Client engagement এবং continuous feedback পাওয়া জরুরি হলে
- যেখানে requirement change হওয়ার সম্ভাবনা বেশি থাকে
What is the difference between a throwaway prototype and an evolutionary prototype?
Throwaway Prototype (Rapid/Close-ended Prototype)
- এই prototype টি তৈরি করা হয় শুধুমাত্র requirement বোঝা এবং clarify করার জন্য
- একবার requirement clear হয়ে গেলে, prototype টি সম্পূর্ণভাবে discard বা throw away করে দেওয়া হয়
- Actual system টি শুরু থেকে নতুন করে (from scratch) develop করা হয়, prototype এর code ব্যবহার করা হয় না
- Prototype তৈরিতে সাধারণত code quality, performance, বা scalability নিয়ে চিন্তা করা হয় না — শুধু দ্রুত কিছু দেখানোই মূল লক্ষ্য
- কম সময়ে এবং কম resource দিয়ে তৈরি করা যায়
- উদাহরণ: UI mockup বা wireframe তৈরি করে client কে দেখানো, যাতে তারা বুঝতে পারেন system টা দেখতে কেমন হব ে, এরপর সেই mockup ফেলে দিয়ে actual, production-quality code লেখা হয়
Evolutionary Prototype (Open-ended Prototype)
- এই prototype টি ধীরে ধীরে refine এবং improve করতে করতে শেষ পর্যন্ত actual final product-এ পরিণত হয়
- Prototype টি discard করা হয় না — এটাই ক্রমান্বয়ে full system-এ evolve করে
- শুরু থেকেই ভালো মানের, well-structured code লেখার দিকে গুরুত্ব দেওয়া হয়, কারণ এটাই শেষ পর্যন্ত থেকে যাবে
- এটি একটি iterative process, যেখানে প্রতিটি version আগের version এর উপর build হয়
- Time এবং resource তুলনামূলক বেশি লাগে, কারণ শুরু থেকেই production-quality standard বজায় রাখতে হয়
- উদাহরণ: একটি web application এর basic version release করে user feedback নেওয়া, তারপর ধাপে ধাপে feature যোগ করে সেই একই codebase কে পূর্ণাঙ্গ product-এ রূপান্তর করা
6. What is the Rapid Application Development (RAD) model?
Rapid Application Development (RAD) হলো একটি SDLC model, যেখানে মূল লক্ষ্য থাকে দ্রুততম সময়ে high-quality software develop করা, traditional Waterfall এর মতো দীর্ঘ planning এবং rigid documentation এর উপর জোর না দিয়ে। এই model টি James Martin প্রস্তাব করেছিলেন। RAD-এ minimal planning এবং maximum prototyping এর মাধ্যমে দ্রুত development করা হয়, এবং heavy emphasis দেওয়া হয় user feedback এবং iterative refinement এর উপর।
RAD Model সাধারণত নিচের মূল ধাপ গুলো অনুসরণ করে:
- Requirements Planning — high-level requirement দ্রুত gather করা হয়, client এবং developer দের মধ্যে workshop বা discussion এর মাধ্যমে
- User Design — client এবং developer একসাথে বসে prototype তৈরি এবং refine করেন, বারবার feedback নিয়ে
- Rapid Construction — prototype অনুযায়ী actual code লেখা হয়, সাধারণত reusable components এবং automated tools ব্যবহার করে দ্রুত development করা হয়
- Cutover (Implementation) — system টি testing শেষে deploy করা হয়, ডেটা migration এবং user training সহ
What are its key characteristics, and what types of projects is it best suited for?
- Speed-focused development — traditional model এর তুলনায় অনেক দ্রুত software delivery হয়
- Heavy use of prototyping — actual working prototype বারবার তৈরি এবং refine করা হয়
- Component-based এবং Reusable Code — আগে থেকে তৈরি components, libraries, এবং tools প্রচুর ব্যবহার করা হয়, যাতে বার বার একই জিনিস নতুন করে লিখতে না হয়
- Minimal Planning, Maximum Iteration — বিস্তারিত upfront planning এর বদলে, কাজ করতে করতে requirement আরও স্পষ্ট হয়
- Active User/Client Involvement — client প্রতিটি iteration-এ সরাসরি involved থাকেন, যার ফলে feedback loop অনেক দ্রুত হয়
- Time-boxed Development — কাজ ছোট ছো ট time-frame বা "time box"-এ ভাগ করা হয়, যাতে প্রতিটি অংশ নির্দিষ্ট সময়ের মধ্যেই শেষ হয়
- Use of CASE tools এবং Automated Development Tools — code generation, debugging, testing দ্রুত করার জন্য advanced tools ব্যবহার করা হয়
- Modular Approach — পুরো system কে ছোট ছোট module এ ভাগ করে, প্রতিটি module আলাদা আলাদা team দ্বারা parallel-ভাবে develop করা যায়
- Flexible এবং Adaptive — requirement change হলে সহজেই accommodate করা যায়
RAD কোন ধরনের Project এর জন্য Best Suited
RAD Model সাধারণত নিচের ধরনের project-এ ভালো কাজ করে:
- যেসব project-এ দ্রুত (short timeline-এ) delivery প্রয়োজন এবং business দ্রুত market-এ product আনতে চায়
- Well-defined business requirement সহ project, যেখানে scope মোটামুটি স্পষ্ট (যদিও পুরোপুরি fixed না)
- Modular system, যেখানে বিভিন্ন অংশকে আলাদা আলাদা module-এ ভাগ করে parallel-ভাবে develop করা যায়
- যেসব project-এ reusable components বা existing libraries/frameworks পাওয়া যায় এবং ব্যবহার করা সম্ভব
- Small থেকে medium-size project, যেখানে বেশি সংখ্যক skilled এবং experienced developer পাওয়া যায় (কারণ RAD-এর জন্য দক্ষ team দরকার)
- যেসব project-এ active এবং accessible client/user পাওয়া যায়, যারা প্রতিটি iteration-এ feedback দিতে পারবেন
- Data-driven business applications — যেমন inventory management system, CRM, বা internal business tools, যেখানে UI এবং functionality দ্রুত prototype করে দেখানো যায়
যেখানে RAD উপযুক্ত নয়:
- Large-scale, highly complex system (যেমন mission-critical বা safety-critical software)
- যেসব project-এ high performance বা technical risk বেশি গুরুত্বপূর্ণ (RAD সেই দিকে কম focus দেয়)
- Budget সীমিত থাকলে, কারণ RAD-এর জন্য skilled developer এবং advanced tools দরকার হয়, যা costly হতে পারে
- যেখানে client বা user দের regular involvement পাওয়া সম্ভব নয়
7. How would you compare Waterfall, Spiral, Iterative, and Agile models in terms of flexibility, risk handling, and customer involvement?
| বিষয় | Waterfall | Spiral | Iterative | Agile |
|---|---|---|---|---|
| Flexibility | Baseline change formal ও costly হতে পারে | প্রতি loop-এ direction বদলানো যায়, governance heavy হতে পারে | Increment-এর মাঝে priority/refinement বদলানো যায় | Framework অনুযায়ী short feedback cycle-এ backlog adapt করা যায় |
| Risk Handling | দুর্বল — risk সাধারণত দেরিতে (testing phase এ) ধরা পড়ে | সবচেয়ে শক্তিশালী — formal risk analysis প্রতিটি loop এর mandatory অংশ | মোটামুটি ভালো — প্রতিটি iteration test হওয়ায় risk তুলনামূলক আগে ধরা পড়ে | ভালো — ছোট sprint এবং continuous testing এর কারণে risk দ্রুত identify হয়, তবে Spiral এর মতো formal নয় |
| Customer Involvement | Formal milestone-কেন্দ্রিক হতে পারে | Loop review-এ stakeholder evaluation থাকে | Increment review-এ feedback নেওয়া যায় | Frequent stakeholder collaboration উৎসাহিত; exact cadence framework/team-নির্ভর |
| Documentation | সবচেয়ে বেশি এবং heavy | বেশি (risk analysis, prototype documentation সহ) | মাঝ ারি | তুলনামূলক কম, working software কেই বেশি গুরুত্ব দেওয়া হয় |
| Delivery Cadence | সাধারণত বড় release শেষে | Risk-reduction loop অনুযায়ী | Usable increment অনুযায়ী | ছোট batch ঘন ঘন; Scrum ব্যবহার করলে Sprint এক মাস বা কম |
| সবচেয়ে উপযুক্ত | Fixed, well-understood requirement সহ project | Large, high-risk, high-cost project | Medium complexity project, যেখানে requirement ধীরে ধীরে স্পষ্ট হয় | Rapidly changing requirement এবং competitive market এর project |
সংক্ষেপে বলতে গেলে:
- Waterfall সবচেয়ে rigid, predictable কিন্তু কম adaptive
- Spiral risk-driven, systematic কিন্তু heavy এবং costly process
- Iterative flexibility এবং structure এর মধ্যে একটি balance রাখে
- Agile সবচেয়ে flexible, customer-centric, এবং fast-paced
For a project with rapidly changing requirements, which model would you recommend, and why?
এই ধরনের project এর জন্য আমি Agile Model recommend করবো। এর কারণগুলো হলো:
১. Built-in Flexibility for Change Agile Manifesto “responding to change over following a plan” value করে। Scrum ব্যবহার করলে Sprint boundary-তে backlog re-evaluate করা যায়; অন্য Agile approach continuous flow ব্যবহার করতে পারে। Change-এর rework/cost থাকতে পারে, তবে early feedback সেটি ছোট রাখতে সাহায্য করে।
২. Continuous Customer Feedback Scrum-এ Product Owner accountable থাকেন এবং Sprint Review stakeholder feedback-এর formal opportunity। অন্য Agile framework-এ role ও feedback event আলাদা হতে পারে; গুরুত্বপূর্ণ হলো নিয়মিত বাস্তব feedback।
৩. Frequent, Incremental Delivery Scrum Sprint-এ Definition of Done পূরণ করা usable increment তৈরি হয়। Requirement change হলে backlog reprioritize করা যায়, তবে architecture/data migration বা discarded behavior-এর rework এখনও হতে পারে।
৪. Reduced Risk of Building the Wrong Thing যেহেতু Waterfall বা Spiral এর মতো শুরুতেই সব requirement lock করে ফেলার প্রয়োজন হয় না, তাই "wrong product" তৈরি হয়ে যাওয়ার risk অনেক কম থাকে — কারণ ভুল দিক ধরা পড়লে সাথে সাথেই course-correct করা যায়।
৫. Prioritization Flexibility Agile এর Product Backlog সবসময় dynamic — নতুন priority আসলে সহজেই top এ নিয়ে আসা যায়, পুরোনো বা কম গুরুত্বপূর্ণ item গুলো পিছিয়ে দেওয়া যায়। এটি rapidly changing business environment এর জন্য অত্যন্ত উপযোগী।
তুলনামূলক ব্যাখ্যা: Iterative model ও কিছুটা flexibility দেয়, কিন্তু Agile এ change management টা অনেক বেশি formalized এবং structured (যেমন: Scrum এর Sprint Planning, Backlog Grooming, Daily Standup) — যা frequent change কে systematic ভাবে handle করতে সাহায্য করে। অন্যদিকে Waterfall এবং Spiral উভয়েই তুলনামূলক rigid, এবং বারবার requirement change হলে এই দুই model এ significant rework এবং cost overrun এর ঝুঁকি অনেক বেশি।