SDLC আর process model — waterfall, V-model, iterative, incremental আর spiral

১ · Process model কেন — বাড়ির নকশা থেকে software

একটি বাড়ি বানানোর কথা ভাবুন। প্রথমে মালিকের সাথে কথা — কয়টি ঘর, বাজেট কত। তারপর নকশাকার নকশা আঁকেন, রাজউক বা পৌরসভা থেকে অনুমোদন নেওয়া হয়, তারপর রাজমিস্ত্রি ভিত দেন, দেয়াল তোলেন, শেষে রং আর বিদ্যুতের কাজ। কেউ ছাদ ঢালাইয়ের পরে বলেন না “আসলে নিচতলায় একটি গ্যারেজ চাই” — বললেও সেটি খুব দামি।

Software বানানোতেও কয়েকটি কাজ সবসময় থাকে। এই পুরো জীবনচক্রকে বলে SDLC (Software Development Life Cycle) — ধারণা থেকে শুরু করে চালু করা আর বছরের পর বছর রক্ষণাবেক্ষণ পর্যন্ত। প্রচলিত ধাপগুলো:

এখন প্রশ্ন — এই ধাপগুলো কি একবারে একটির পর একটি হবে? নাকি ছোট ছোট চক্রে বারবার? কখন গ্রাহক কাজ দেখবেন? কোথায় থেমে সিদ্ধান্ত নেওয়া হবে? এই প্রশ্নগুলোর উত্তরের কাঠামোই process model. পর্ব ০১-এ (Software engineering কী) দেখেছেন, software engineering মানে শুধু কোড লেখা নয়, পুরো কাজটি নিয়মমাফিক চালানো। Process model সেই নিয়মের নকশা।

পাঁচটি মৌলিক কাজ — সব মডেলেই থাকে

Roger Pressman-এর বহুল পঠিত পাঠ্যবই Software Engineering: A Practitioner's Approach একটি সাধারণ কাঠামো দেয়: প্রায় সব project-এ পাঁচটি framework activity থাকে।

এর পাশে কিছু umbrella activity পুরো project জুড়ে ছাতার মতো চলে — project tracking, risk management, quality assurance, review, configuration management (কোন ফাইলের কোন version — Git ঠিক এই কাজটিই করে, মডিউল ২ থেকে দেখবেন)।

২ · Waterfall — ধাপে ধাপে, এক দিকে

Waterfall model-এ কাজ ঝরনার পানির মতো ওপর থেকে নিচে নামে: requirement শেষ ও অনুমোদিত হলে নকশা, নকশা শেষ হলে কোড, তারপর test, তারপর deployment. প্রতিটি ধাপের শেষে একটি দলিল আর একটি অনুমোদন — এই অনুমোদন-বিন্দুকে অনেক সময় “phase gate” বলা হয়। পেছনে ফেরা নিয়মে নিষিদ্ধ নয়, কিন্তু দামি।

নিচের stepper-এ একটি কাল্পনিক বিশ্ববিদ্যালয়ের ফলাফল পোর্টাল waterfall-এ চলছে। পরিকল্পনা ২০ সপ্তাহের: requirement ২, নকশা ২, কোড ১২, test ৩, deployment ১ সপ্তাহ। খেয়াল করুন গ্রাহক কখন প্রথমবার কাজ করা software দেখেন।

Waterfall কখন ঠিক পছন্দ

Waterfall-কে “পুরোনো, খারাপ” বলে উড়িয়ে দেওয়া ভুল। যেখানে এটি যুক্তিসঙ্গত:

• Requirement স্থির ও ভালোভাবে বোঝা: যেমন একটি পুরোনো payroll system-কে একই নিয়মে নতুন platform-এ নেওয়া — কী বানাতে হবে, তা নিয়ে অনিশ্চয়তা কম।
• নির্দিষ্ট পরিধির চুক্তি: সরকারি টেন্ডার বা fixed-price চুক্তিতে শুরুতেই কাজের পরিধি, দাম আর গ্রহণের শর্ত লিখে দিতে হয়।
• নিয়ন্ত্রিত ক্ষেত্র: যেখানে নিয়ন্ত্রক সংস্থা প্রতিটি ধাপের দলিল আর অনুমোদন দেখতে চায়।

৩ · V-model — প্রতিটি নকশার পাশে তার test

Waterfall-এ test আসে শেষে, আর “কী test করব” সেটিও প্রায়ই তখনই ভাবা হয়। V-model এই ফাঁকটি বন্ধ করে। ধাপগুলোকে ইংরেজি V অক্ষরের মতো সাজানো হয়: বাঁ বাহু দিয়ে নামতে নামতে requirement থেকে খুঁটিনাটি নকশা, নিচে কোড, তারপর ডান বাহু দিয়ে উঠতে উঠতে ছোট থেকে বড় test. সবচেয়ে গুরুত্বপূর্ণ কথা: বাঁ দিকের প্রতিটি ধাপের সাথে ডান দিকের একটি test স্তর জোড়া, আর সেই test-এর পরিকল্পনা নকশার সময়েই লেখা হয়।

ফলাফল পোর্টালে: requirement লেখার সময়েই acceptance test — “রেজিস্ট্রার ছাত্রের রোল দিলে ১০ সেকেন্ডের মধ্যে সঠিক GPA-সহ transcript দেখাবে।” GPA module-এর নকশার সময়েই unit test — “৪টি কোর্সে A, A-, B+, F থাকলে GPA কত?” লাভ দুটি: test লিখতে গিয়ে নকশার অস্পষ্টতা আগেই ধরা পড়ে, আর প্রতিটি requirement থেকে তার test পর্যন্ত সংযোগ থাকে, যাকে বলে traceability.

সীমাবদ্ধতা: V-model আসলে waterfall-এরই একটি রূপ — ধাপ এখনো ধারাবাহিক, কাজ করা software এখনো আসে শেষে, requirement বদলালে V-এর দুই বাহুই বদলাতে হয়। এর শক্তি অন্য জায়গায়: যেখানে প্রমাণ দেখাতে হয় যে প্রতিটি requirement যাচাই হয়েছে — চিকিৎসা যন্ত্র, গাড়ি, বিমান, রেলের সংকেত ব্যবস্থার software. ১৯৮০-র দশকে এটি পরিচিতি পায়; জার্মানির সরকারি project-এর জন্য তৈরি “V-Modell” (পরের বড় সংস্করণ V-Modell XT, ২০০৫ সালের দিকে) এর একটি সুপরিচিত আনুষ্ঠানিক রূপ।

৪ · Prototyping, incremental আর iterative

Prototyping — দেখলে তবে বোঝা যায়

দর্জির কাছে প্রথমবার পাঞ্জাবি বানাতে গেলে ভালো দর্জি একবার “ট্রায়াল” দেন — কাঁচা সেলাইয়ে গায়ে দিয়ে দেখা, কোথায় ঢিলা। Software-এ এর নাম prototype: আসল system-এর আগে দ্রুত বানানো একটি নমুনা। অনেক ব্যবহারকারী কাগজে লেখা requirement পড়ে কিছু বুঝতে পারেন না, কিন্তু পর্দায় একটি screen দেখলে সঙ্গে সঙ্গে বলেন “না, এটা না।” Prototype দুই রকম:

Incremental বনাম iterative — দুটি আলাদা কথা

এই দুটি শব্দ প্রায়ই গুলিয়ে ফেলা হয়, অথচ পরীক্ষায় এদের পার্থক্য খুব প্রিয় প্রশ্ন।

• Incremental development: software-কে অংশে ভাগ করে প্রতিবার একটি নতুন, সম্পূর্ণ অংশ যোগ করা। প্রথম release-এ login আর ফলাফল দেখা; পরেরটিতে transcript; তারপর মেধাতালিকা। প্রতিটি increment যোগের সময়েই ব্যবহারযোগ্য। প্রশ্ন: “এবার কোন অংশ যোগ হবে?”
• Iterative development: একই জিনিসে বারবার ফিরে এসে উন্নত করা। প্রথমে পুরো পোর্টালের একটি মোটা দাগের রূপ, তারপর প্রতিটি iteration-এ মতামত দেখে আরও নিখুঁত। প্রশ্ন: “যা আছে, তা কীভাবে আরও ভালো হবে?”

শুধু incremental-এর বিপদ: প্রথম অংশটি যদি ভুল বোঝা হয়, বাকিগুলোও সেই ভুলের ওপর দাঁড়াবে। শুধু iterative-এর বিপদ: সবকিছু বারবার “একটু ভালো” হতে থাকে, কিন্তু কোনো অংশই ব্যবহারযোগ্য অবস্থায় হাতে আসে না। তাই বাস্তবে প্রায় সব আধুনিক পদ্ধতি দুটো মেশায় — প্রতিটি iteration-এ একটি ব্যবহারযোগ্য increment. Agile-এর sprint ঠিক এটাই: পর্ব ০৫-এ (Agile আর Scrum) এর নিয়মকানুন বিস্তারিত পাবেন। একদম শুরুর ছোট্ট ব্যবহারযোগ্য রূপটিকে অনেকে বলেন MVP.

এবার আগের ফলাফল পোর্টালটিকেই তিনটি iteration-এ চালিয়ে দেখি। একই ১২টি feature, একই ২০ সপ্তাহ, একই নিয়ম-পরিবর্তন — শুধু ক্রম বদলেছে।

Stepper-এর সংখ্যা একটি গল্প; এবার একই কথা নিয়মে বেঁধে যাচাই করি। অনুমান: ১২টি feature, ২০ সপ্তাহ। Waterfall-এ সব নকশা চতুর্থ সপ্তাহে স্থির, গ্রাহক software দেখেন ২০তম সপ্তাহে। Iterative-এ ৫ সপ্তাহের ৪টি iteration, প্রতিটিতে ৩টি feature — প্রথম সপ্তাহে নকশা, শেষ সপ্তাহে demo. প্রতি সপ্তাহে ৩৫% সম্ভাবনায় একটি পরিবর্তন আসে, আর প্রতিটি feature ২৫% সম্ভাবনায় ভুল বোঝা — ধরা পড়ে গ্রাহক সেটি প্রথম চালিয়ে দেখলে। দুই মডেলে একই তালিকা। খরচ: নকশা স্থির হওয়ার আগে পরিবর্তন ০.২৫ সপ্তাহ; পরে ০.৫, সাথে স্থির হওয়ার পর প্রতি সপ্তাহে আরও ০.১ — কারণ সময়ের সাথে আরও কাজ সেই সিদ্ধান্তের ওপর দাঁড়ায়।

// Waterfall vs iterative: same 12 features, same seeded requirement changes.
let seed = 3; function rand() {   // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const N = 12, WEEKS = 20, P_CHANGE = 0.35, P_WRONG = 0.25;
const changes = [];               // [week, feature]: a change request arrives
for (let w = 1; w <= WEEKS; w++) if (rand() < P_CHANGE) changes.push([w, Math.floor(rand() * N)]);
const wrong = [];                 // features the team misunderstood (found at first demo)
for (let f = 0; f < N; f++) if (rand() < P_WRONG) wrong.push(f);
console.log("changes (week:feature): " + changes.map(([w, f]) => w + ":F" + f).join(" "));
console.log("misunderstood: " + wrong.map(f => "F" + f).join(" "));
// design = week the feature's design is frozen; demo = week the customer first sees it work
const plans = {
  waterfall: () => ({ design: 4, demo: 20 }),          // all designed by wk 4, one release wk 20
  iterative: f => { const k = Math.floor(f / 3);       // 4 iterations x 5 weeks, 3 features each
                    return { design: 5 * k + 1, demo: 5 * k + 5 }; }
};
// Rule: before design is frozen a change costs 0.25 wk; after that 0.5 wk
// plus 0.1 wk for every week since the freeze (more work now rests on it).
const cost = (week, p) => week <= p.design ? 0.25 : 0.5 + 0.1 * (week - p.design);
for (const [name, plan] of Object.entries(plans)) {
  let rc = 0, rw = 0;
  for (const [w, f] of changes) rc += cost(w, plan(f));
  for (const f of wrong) rw += cost(plan(f).demo, plan(f));
  let first = WEEKS; for (let f = 0; f < N; f++) first = Math.min(first, plan(f).demo);
  console.log(name.padEnd(10) + " first value: week " + String(first).padStart(2) +
    " | rework: changes " + rc.toFixed(2) + " + misunderstandings " + rw.toFixed(2) +
    " = " + (rc + rw).toFixed(2) + " wk");
}

changes (week:feature): 2:F5 3:F9 6:F3 8:F1 13:F8 14:F8 18:F10 19:F11
misunderstood: F2 F5 F6
waterfall  first value: week 20 | rework: changes 8.90 + misunderstandings 6.30 = 15.20 wk
iterative  first value: week  5 | rework: changes 4.95 + misunderstandings 2.70 = 7.65 wk

৫ · Spiral model — সবচেয়ে বড় ঝুঁকি আগে

১৯৮৬ সালে (ACM SIGSOFT Software Engineering Notes-এ) আর আরও পরিচিত রূপে ১৯৮৮ সালে (IEEE Computer পত্রিকায়) Barry Boehm প্রকাশ করেন “A Spiral Model of Software Development and Enhancement” নামের লেখা। তাঁর মূল প্রশ্ন: পরের ধাপে কী করব, তা কে ঠিক করবে? Waterfall-এর উত্তর — দলিলের তালিকা। Boehm-এর উত্তর — ঝুঁকি. যে অনিশ্চয়তা project ডোবাতে পারে, সেটিই আগে পরীক্ষা করুন।

Spiral model-এ project একটি প্যাঁচানো পথ ধরে কেন্দ্র থেকে বাইরে যায়। প্রতিটি পাক বা loop চারটি ভাগ (quadrant) পার হয় — ঘড়ির কাঁটার দিকে:

1. লক্ষ্য, বিকল্প ও সীমা ঠিক করা — এই loop-এ কী চাই, কোন কোন পথে, কোন বাজেট-সময়ে।
2. বিকল্প মূল্যায়ন, ঝুঁকি চিহ্নিত ও সমাধান — prototype, simulation বা benchmark দিয়ে ঝুঁকি কমানো।
3. পরের স্তরের product তৈরি ও যাচাই — প্রথম দিকের loop-এ হয়তো শুধু requirement, পরের দিকে নকশা ও কোড।
4. পরের ধাপের পরিকল্পনা — stakeholder review, আর পরের loop-এর অঙ্গীকার অথবা project থামানো।

Boehm-এর ছবিতে কেন্দ্র থেকে দূরত্ব মানে এখন পর্যন্ত মোট খরচ, আর ঘূর্ণন মানে অগ্রগতি। প্রতিটি loop-এ কত বিস্তারিত কাজ হবে, তা ঠিক করে ঝুঁকি — ঝুঁকি বেশি হলে আরও prototype, কম হলে সোজা waterfall-এর মতো এগোনো। এই অর্থে spiral একটি “মডেল বানানোর মডেল”: ঝুঁকি অনুযায়ী এক project-এর ভেতরেই waterfall, prototyping বা incremental অংশ আসতে পারে।

Risk exposure — কোন ঝুঁকি আগে

প্রতিটি risk-এর দুটি দিক: ঘটার সম্ভাবনা (P) আর ঘটলে ক্ষতি (L, টাকায় বা সপ্তাহে)। Boehm-এর ১৯৯১ সালের লেখা “Software Risk Management: Principles and Practices” (IEEE Software)-এ সংজ্ঞাটি এমন:

যেমন, payment gateway জোড়া দিতে ব্যর্থ হওয়ার সম্ভাবনা ০.৪, ঘটলে ক্ষতি ৳২০ লাখ → RE = ০.৪ × ২০ = ৳৮ লাখ। এটি প্রত্যাশিত ক্ষতি — বহু project-এর গড়ে যা হারানোর আশঙ্কা। সব ঝুঁকির RE সাজিয়ে সবচেয়ে বড়টি আগে সামলানো spiral-এর মূল কৌশল। একই লেখায় Boehm ঝুঁকি কমানোর একটি ব্যবস্থা কতটা লাভজনক তা মাপতে risk reduction leverage-এর কথাও বলেন: (আগের RE − পরের RE) ÷ ব্যবস্থার খরচ। পুরো risk register আর risk management আসবে পর্ব ৬২-তে।

নিচের stepper একটি কাল্পনিক অনলাইন বাজার অ্যাপের দ্বিতীয় loop দেখায়, যেখানে সবচেয়ে বড় ঝুঁকি ঈদের সেলের ভিড়। ঈদের আগে বাসের টিকিটের ভিড়ের মতো — সারা বছর ঠিক চলা সিস্টেম ওই কয়েক দিনেই ভেঙে পড়ে।

একই কৌশল কয়েকটি loop জুড়ে: ছয়টি ঝুঁকি দিয়ে শুরু; প্রতি loop-এ দুটি সবচেয়ে বড় অমীমাংসিত ঝুঁকিতে prototype বা spike (ঝুঁকি যাচাইয়ের ছোট পরীক্ষামূলক কাজ)। Seeded PRNG ঠিক করে পরীক্ষাটি পুরো সফল (৮০%) নাকি আংশিক — আংশিক হলে সম্ভাবনা শুধু অর্ধেক। Loop ১-এ পাওয়া নতুন ঝুঁকি (পুরোনো ডেটা স্থানান্তর) loop ২ থেকে যোগ হয়। মোট RE ৳৭ লাখের নিচে নামলে পুরো তৈরির অঙ্গীকার।

// Spiral: each loop attacks the 2 biggest risks first (risk exposure RE = P x impact).
let seed = 7; function rand() {   // mulberry32: decides whether a spike/prototype works
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
// [id, probability, impact in lakh taka, P after a successful mitigation]
const risks = [
  ["R1 payment gateway", 0.40, 20, 0.05], ["R2 Eid-sale load", 0.50, 12, 0.10],
  ["R3 unclear delivery rules", 0.60, 8, 0.10], ["R4 key dev leaves", 0.20, 15, 0.10],
  ["R5 new framework", 0.30, 6, 0.05], ["R6 store approval", 0.25, 4, 0.10]
].map(([id, p, imp, after]) => ({ id, p, imp, after }));
const re = r => r.p * r.imp;
const total = () => risks.reduce((s, r) => s + re(r), 0);
const LIMIT = 7.0;                 // stakeholders accept the plan below this total RE
console.log("start: total RE = " + total().toFixed(2) + " lakh");
for (let loop = 1; loop <= 4 && total() >= LIMIT; loop++) {
  if (loop === 2) risks.push({ id: "R7 data migration", p: 0.5, imp: 6, after: 0.1 }); // found in loop 1
  risks.sort((a, b) => re(b) - re(a));
  const parts = [];
  for (const r of risks.filter(r => !r.done).slice(0, 2)) {
    const before = re(r), ok = rand() < 0.8;   // 80% of spikes fully work
    r.p = ok ? r.after : r.p / 2; r.done = ok;  // a failed spike still halves P
    parts.push(r.id + " " + before.toFixed(2) + "->" + re(r).toFixed(2) + (ok ? "" : " (partly)"));
  }
  console.log("loop " + loop + ": " + parts.join(", ") + " | total " + total().toFixed(2));
}
console.log(total() < LIMIT ? "risk acceptable: commit to build" : "still risky: rethink or stop");
risks.sort((a, b) => re(b) - re(a));
console.log("left: " + risks.map(r => r.id.split(" ")[0] + "=" + re(r).toFixed(2)).join(" "));

start: total RE = 24.60 lakh
loop 1: R1 payment gateway 8.00->1.00, R2 Eid-sale load 6.00->1.20 | total 12.80
loop 2: R3 unclear delivery rules 4.80->2.40 (partly), R4 key dev leaves 3.00->1.50 | total 11.90
loop 3: R7 data migration 3.00->0.60, R3 unclear delivery rules 2.40->0.80 | total 7.90
loop 4: R5 new framework 1.80->0.30, R6 store approval 1.00->0.40 | total 5.80
risk acceptable: commit to build
left: R4=1.50 R2=1.20 R1=1.00 R3=0.80 R7=0.60 R6=0.40 R5=0.30

Anchor point — কোথায় থেমে অঙ্গীকার

Spiral-এর একটি সমালোচনা ছিল: loop কতবার চলবে, কখন “যথেষ্ট” — তা অস্পষ্ট। ১৯৯৬ সালে Boehm “Anchoring the Software Process” (IEEE Software) লেখায় তিনটি anchor point milestone প্রস্তাব করেন, যেখানে stakeholder-রা একসাথে বসে পরের বড় খরচের অঙ্গীকার করেন:

• LCO (Life Cycle Objectives): লক্ষ্য, পরিধি আর অন্তত একটি সম্ভাব্য architecture আছে — project-টি করার মতো কি?
• LCA (Life Cycle Architecture): architecture বাছাই হয়েছে, বড় ঝুঁকিগুলো সমাধান বা পরিকল্পিত — এখন পুরো তৈরিতে টাকা দেওয়া যায় কি?
• IOC (Initial Operational Capability): প্রথম ব্যবহারযোগ্য রূপ ব্যবহারকারীর কাছে যাওয়ার জন্য প্রস্তুত।

এই তিনটি বিন্দু পরে Unified Process-এর phase-সীমায় প্রায় হুবহু ঢুকে যায় — পরের অংশে দেখবেন।

তিনটি মডেল পাশাপাশি

৬ · Unified Process আর RAD — সংক্ষেপে

Unified Process (RUP) — চারটি phase, ভেতরে iteration

১৯৯০-এর দশকের শেষে Rational Software কোম্পানির Ivar Jacobson, Grady Booch আর James Rumbaugh — যাঁরা UML-এরও প্রধান স্থপতি — The Unified Software Development Process (১৯৯৯) বইয়ে একটি কাঠামো দেন। এর বাণিজ্যিক রূপ Rational Unified Process (RUP); ২০০৩ সালে IBM Rational-কে কিনে নেয়। মূল চিন্তা: project চারটি ধারাবাহিক phase-এ ভাগ, কিন্তু প্রতিটি phase-এর ভেতরে এক বা একাধিক iteration.

প্রথম তিনটি milestone-এর নাম Boehm-এর anchor point (LCO, LCA, IOC)-এর সাথে মিলিয়ে দেখুন — এটি কাকতালীয় নয়। RUP-এর “hump chart”-এ দেখা যায় সব কাজ প্রতিটি phase-এ চলে, শুধু অনুপাত বদলায়: inception-এ requirement বেশি, construction-এ কোড বেশি। সমালোচনা ছিল এর ভার — অনেক role, artifact আর দলিল।

RAD — দ্রুততাই লক্ষ্য

RAD (Rapid Application Development) নামটি জনপ্রিয় হয় James Martin-এর ১৯৯১ সালের একই নামের বই থেকে। এর উপাদান: ব্যবহারকারীর সাথে কয়েক দিনের নিবিড় workshop, দ্রুত prototype, তৈরি টুল আর code generator, আর একটি কঠোর timebox — সাধারণত কয়েক মাস; সময় শেষ হলে কাজ কমানো হয়, সময় বাড়ানো হয় না। ছোট দল, ব্যবহারকারী সহজে পাওয়া যায়, আর একটি ব্যবসায়িক application যা ভাগ করে বানানো যায় — এমন জায়গায় RAD ভালো। বড়, জটিল, উচ্চ-নিরাপত্তার system-এ এটি কম মানায়। RAD-এর কিছু চিন্তা পরে DSDM-এর মতো পদ্ধতি হয়ে Agile আন্দোলনে মিশেছে।

৭ · কোন মডেল কখন — সিদ্ধান্তের টেবিল

“কোন মডেল সেরা?” — প্রশ্নটাই ভুল। আসল প্রশ্ন: এই project-এ কোন অনিশ্চয়তা সবচেয়ে বড়, আর কোন সীমা অনড়? রেলের সময়সূচির কথা ভাবুন — ঢাকা-চট্টগ্রাম রুটে বছরের পর বছর একই সময়সূচি চলে, আগে থেকে ঠিক করা যায়; কিন্তু ঈদের বিশেষ ট্রেনের পরিকল্পনা প্রতি বছর ভিড় দেখে বদলায়। দুটিই রেলের কাজ, পদ্ধতি আলাদা।

এই টেবিলকেই নিয়মে বেঁধে একটি ছোট সহকারী প্রোগ্রাম বানাই। প্রতিটি নিয়ম একটি বৈশিষ্ট্য দেখে কোনো মডেলকে পয়েন্ট দেয় আর কারণটি লিখে রাখে। নিয়ম আর পয়েন্ট আমাদের ঠিক করা — কোনো মান (standard) নয়; উদ্দেশ্য হলো যুক্তিটা স্পষ্ট করে লেখা, যাতে তর্ক করা যায়।

// A rule-based helper: project traits -> points for each process model, with reasons.
const RULES = [  // [condition, model, points, reason]
  [p => p.reqStable,        "Waterfall",   2, "requirements are stable and signed off"],
  [p => p.fixedContract,    "Waterfall",   1, "fixed-scope contract needs an up-front spec"],
  [p => p.regulated,        "V-model",     2, "regulator wants each phase traced to a test level"],
  [p => p.safetyCritical,   "V-model",     2, "safety: plan verification from day one"],
  [p => !p.reqStable,       "Iterative",   2, "requirements will change; get feedback often"],
  [p => p.customerNearby,   "Iterative",   1, "customer can review every 2-4 weeks"],
  [p => p.earlyRelease,     "Incremental", 2, "users need a core part early"],
  [p => p.reqStable && p.earlyRelease, "Incremental", 1, "scope is known, so it splits cleanly"],
  [p => p.risk === "high",  "Spiral",      3, "high technical risk: retire risks first"],
  [p => p.size === "large" && p.risk !== "low", "Spiral", 1, "large and uncertain"],
  [p => p.uiUnclear,        "Prototyping", 2, "users cannot say what they want until they see it"],
];
function recommend(name, p) {
  const score = {}, why = {};
  for (const [test, model, pts, reason] of RULES) if (test(p)) {
    score[model] = (score[model] || 0) + pts; (why[model] = why[model] || []).push(reason);
  }
  const ranked = Object.entries(score).sort((a, b) => b[1] - a[1]);
  console.log(name + ": " + ranked.map(([m, s]) => m + "=" + s).join(" "));
  const [best, s] = ranked[0];
  console.log("  -> " + best + " (" + s + "): " + why[best].join("; "));
}
recommend("A. payroll for a fixed tender", { reqStable: true, fixedContract: true, regulated: false,
  safetyCritical: false, customerNearby: false, earlyRelease: false, risk: "low", size: "medium", uiUnclear: false });
recommend("B. infusion-pump firmware", { reqStable: true, fixedContract: false, regulated: true,
  safetyCritical: true, customerNearby: false, earlyRelease: false, risk: "medium", size: "medium", uiUnclear: false });
recommend("C. new online-bazaar app", { reqStable: false, fixedContract: false, regulated: false,
  safetyCritical: false, customerNearby: true, earlyRelease: true, risk: "medium", size: "medium", uiUnclear: true });

A. payroll for a fixed tender: Waterfall=3
  -> Waterfall (3): requirements are stable and signed off; fixed-scope contract needs an up-front spec
B. infusion-pump firmware: V-model=4 Waterfall=2
  -> V-model (4): regulator wants each phase traced to a test level; safety: plan verification from day one
C. new online-bazaar app: Iterative=3 Incremental=2 Prototyping=2
  -> Iterative (3): requirements will change; get feedback often; customer can review every 2-4 weeks

বাস্তবে hybrid — বিশুদ্ধ মডেল বিরল

বইয়ের মডেলগুলো আদর্শ রূপ; বাস্তবের বেশিরভাগ দল একটি hybrid চালায়। কয়েকটি পরিচিত মিশ্রণ:

• শুরুতে পরিকল্পনা, ভেতরে iteration: চুক্তি আর বাজেটের জন্য শুরুতে মোটা দাগের requirement ও architecture (waterfall-এর মতো), তারপর ২–৪ সপ্তাহের iteration-এ তৈরি, শেষে আনুষ্ঠানিক acceptance test. Forrester-এর বিশ্লেষক Dave West ২০১১ সালের দিকে এর নাম দেন “Water-Scrum-Fall” — প্রশংসা আর সতর্কতা দুই অর্থেই।
• নিয়ন্ত্রিত ক্ষেত্রে iterative V: প্রতিটি increment-এর ভেতরে ছোট একটি V — requirement থেকে test পর্যন্ত traceability বজায় রেখে।
• Agile দলে spiral-এর চিন্তা: অনিশ্চিত কাজের আগে ছোট “spike” — স্পষ্ট ঝুঁকি-চালিত সিদ্ধান্ত, শুধু নামটা আলাদা।

Flow আর কাজের সীমা (WIP limit) দিয়ে আরেকটি পথ — Kanban আর lean — পর্ব ০৬-এ (Kanban আর lean) দেখবেন। আর release-কে ঘন ঘন আর নিরাপদ করার কৌশল পর্ব ৫৮ (continuous integration) আর পর্ব ৫৯ (continuous delivery আর DevOps)-এ।

৮ · পরীক্ষার প্রিয় তুলনা — সুবিধা আর অসুবিধা

৯ · AI-এর যুগে process model

AI-কে “আমার project-এর জন্য কোন SDLC model ভালো?” জিজ্ঞেস করলে প্রায়ই আত্মবিশ্বাসী উত্তর আসে — “Agile ব্যবহার করুন”, সাথে একটি সুবিধা-অসুবিধার তালিকা। কিন্তু AI আপনার চুক্তি, নিয়ন্ত্রক বা দলের কথা জানে না, যদি না আপনি বলেন; আর ইতিহাস ও মান নিয়ে প্রায়ই ভুল বলে।

AI-এর পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• সুপারিশটি আমার project-এর নির্দিষ্ট তথ্য (চুক্তি, নিয়ন্ত্রক, দল, গ্রাহকের সময়) ধরে যুক্তি দিয়েছে — সাধারণ সুবিধা-অসুবিধার তালিকা নয়
• প্রতিটি ঐতিহাসিক দাবি (Royce, Boehm, Unified Process) মূল উৎস বা নির্ভরযোগ্য পাঠ্যবইয়ে মিলিয়েছি
• প্রতিটি পরিসংখ্যানের উৎস খুঁজেছি; না পেলে বাদ দিয়েছি
• Risk exposure-এর গুণ নিজে আবার করেছি, আর সম্ভাবনাগুলো দলের সাথে আলোচনা করে ঠিক করেছি
• AI-কে বিপক্ষের যুক্তিও জিজ্ঞেস করেছি: “এই মডেল কোন পরিস্থিতিতে ব্যর্থ হবে?”
• Project-এর গোপন তথ্য, গ্রাহকের নাম বা চুক্তির অংশ prompt-এ দিইনি