Risk আর quality management — risk register, CMMI, ISO 9001 আর software metric

১ · Risk কী — আর risk management-এর চার ধাপ

বর্ষার আগে একজন কৃষক কী করেন? বীজতলা একটু উঁচু জায়গায় করেন, নালা পরিষ্কার রাখেন, কেউ কেউ শস্যবিমা করেন, আর ঠিক করে রাখেন — পানি উঠলে চারা কোথায় সরাবেন। বন্যা হবেই, এমন নয়। কিন্তু হলে কী ক্ষতি, আর আগে থেকে কী করলে ক্ষতি কমে — এই হিসাবটাই risk management.

Software project-এও একই কথা। একটি risk বা ঝুঁকি হলো এমন একটি অনিশ্চিত ঘটনা, যা ঘটলে সময়, খরচ বা মানের ক্ষতি হবে। “Server বসে গেছে” ঝুঁকি নয় — সেটি ঘটে যাওয়া সমস্যা (issue). “ঈদের ভিড়ে server বসে যেতে পারে” ঝুঁকি, কারণ এখনো ঘটেনি, আর এখনো কিছু করার সুযোগ আছে। Risk management মানে সেই সুযোগটি কাজে লাগানোর সুশৃঙ্খল পদ্ধতি।

এই পর্বে একটি কাল্পনিক উদাহরণ বারবার আসবে: একটি কৃষিপণ্যের অনলাইন বাজার অ্যাপ (কাল্পনিক), যেখানে কৃষকেরা সবজি-ফল তোলেন আর শহরের ক্রেতারা অর্ডার দেন। দল ছয়জনের, বাজেট আর সময় সীমিত, আর প্রথম বড় পরীক্ষা ঈদের আগের সপ্তাহ।

চার ধাপের চক্র

বিভিন্ন বই ধাপগুলোকে ভিন্ন নামে ভাগ করে। Ian Sommerville-এর পরিচিত পাঠ্যবই Software Engineering চারটি ধাপ বলে, যা এখানে আমরা মানব:

Barry Boehm তাঁর ১৯৯১ সালের প্রবন্ধ “Software Risk Management: Principles and Practices” (IEEE Software)-এ একই কাজকে দুই ভাগে দেখান: risk assessment (identification, analysis, prioritization) আর risk control (management planning, resolution, monitoring). Boehm-এর spiral model (পর্ব ০৪) প্রতিটি loop-এ এই চক্রটিই চালায় — সেখানে আপনি RE = P × L দিয়ে কোন ঝুঁকি আগে সামলাবেন তা দেখেছেন। এই পর্বে সেই ভিত্তির ওপর পুরো ব্যবস্থাটি দাঁড় করাব।

Boehm-এর “top 10” software ঝুঁকি

একই প্রবন্ধে Boehm অভিজ্ঞ project manager-দের জরিপের ভিত্তিতে software project-এর দশটি প্রধান ঝুঁকির একটি তালিকা দেন। তালিকাটি ১৯৯১ সালের, তাই প্রযুক্তি বদলেছে; তবু বহু পাঠ্যবই এখনো এটি উদ্ধৃত করে। নিচে আমাদের জানামতে মূল তালিকার ভাব সংক্ষেপে (শব্দ আর ক্রম মূল প্রবন্ধে মিলিয়ে নিন):

২ · ঝুঁকির ধরন আর ঝুঁকি খুঁজে বের করা

Sommerville ঝুঁকিকে তিন ভাগে দেখান। ভাগটি জরুরি, কারণ ধরন অনুযায়ী দায়িত্ব আর প্রতিকার আলাদা হয়:

একই ঘটনা একাধিক ধরনে পড়তে পারে। ভিড়ে checkout বসে গেলে সেটি product risk (system-এর ক্ষমতা), আবার business risk-ও (ক্রেতা আর কৃষকের আস্থা হারানো)। Register-এ প্রধান ধরনটি লিখে বাকিটি উল্লেখ করলেই যথেষ্ট।

ঝুঁকি খোঁজার কৌশল

• Checklist আর taxonomy: Boehm-এর তালিকা, বা আরও বিস্তারিত SEI risk taxonomy. Carnegie Mellon বিশ্ববিদ্যালয়ের Software Engineering Institute (SEI)-এর ১৯৯৩ সালের প্রতিবেদন “Taxonomy-Based Risk Identification” (Carr ও সহকর্মীরা) ঝুঁকিকে তিনটি বড় শ্রেণিতে ভাগ করে — product engineering (requirement, design, code, test), development environment (প্রক্রিয়া, tool, ব্যবস্থাপনা) আর program constraints (সম্পদ, চুক্তি, বাইরের নির্ভরতা) — আর প্রতিটির জন্য প্রশ্নমালা দেয় (আমাদের জানামতে প্রায় দুইশো প্রশ্ন)।
• Brainstorming আর pre-mortem: দল কল্পনা করে, “ছয় মাস পরে project ব্যর্থ হয়েছে — কেন?” তারপর প্রত্যেকে কারণ লেখেন। মনোবিজ্ঞানী Gary Klein-এর জনপ্রিয় করা এই কৌশল চুপচাপ সদস্যদের দুশ্চিন্তাও সামনে আনে।
• Assumption analysis: পরিকল্পনার প্রতিটি অনুমান (“payment API বদলাবে না”, “কৃষকদের স্মার্টফোন আছে”) একটি সম্ভাব্য ঝুঁকি।

৩ · ঝুঁকি মাপা — probability × impact matrix আর risk exposure

চিহ্নিত ঝুঁকি হয়তো ত্রিশটি; সবকটির পেছনে সমান সময় দেওয়া যায় না। তাই সাজাতে হয়। দুটি প্রচলিত উপায় আছে — গুণগত আর পরিমাণগত।

গুণগত বিশ্লেষণ — heat map

প্রতিটি ঝুঁকিকে সম্ভাবনা আর ক্ষতির জন্য ১ থেকে ৫ পর্যন্ত একটি ধাপ (band) দেওয়া হয়, তারপর দুটি গুণ করে score. ছবিতে সাজালে পাওয়া যায় probability–impact matrix, যাকে রঙের কারণে heat map-ও বলে। আমাদের কাল্পনিক দল band ঠিক করেছে এভাবে: সম্ভাবনা ০.২ পর্যন্ত ১, ০.৪ পর্যন্ত ২, ০.৬ পর্যন্ত ৩, ০.৮ পর্যন্ত ৪, তার বেশি ৫; ক্ষতি ৳২ লাখ পর্যন্ত ১, ৳৫ লাখ পর্যন্ত ২, ৳১০ লাখ পর্যন্ত ৩, ৳২০ লাখ পর্যন্ত ৪, তার বেশি ৫। Score ১২ বা বেশি লাল (উচ্চ), ৫ থেকে ১১ হলুদ (মাঝারি), ৪ বা কম সবুজ (নিম্ন)। এই সীমাগুলো দলের নিজের সিদ্ধান্ত — কোনো মানদণ্ড নির্দিষ্ট সংখ্যা চাপিয়ে দেয় না।

পরিমাণগত বিশ্লেষণ — risk exposure

পর্ব ০৪-এ দেখেছেন Boehm-এর সংজ্ঞা: risk exposure RE = P × L, অর্থাৎ ঘটার সম্ভাবনা গুণ ঘটলে ক্ষতি। এটি প্রত্যাশিত ক্ষতি — অনেকগুলো একই রকম project-এর গড়ে যা হারানোর আশঙ্কা। Heat map-এর score-এর সাথে এর বড় পার্থক্য হলো, band-এ ভাগ করলে তথ্য হারায়: ০.৪১ আর ০.৬০ দুটিই band ৩, আর ৳২১ লাখ ও ৳৮০ লাখ দুটিই band ৫। নিচের program আটটি ঝুঁকির RE বের করে, সাজায়, band আর score দেখায়, তারপর প্রস্তাবিত চারটি প্রতিকারের RRL হিসাব করে (RRL অংশ ৫-এ বিস্তারিত)।

// Risk register (fictional farm-produce market app): RE = P x L, L in lakh taka
const risks = [
  { id: "R1", what: "payment API changes",      p: 0.5, L: 12 },
  { id: "R2", what: "key developer leaves",     p: 0.3, L: 15 },
  { id: "R3", what: "Eid traffic overload",     p: 0.5, L: 24 },
  { id: "R4", what: "requirements keep moving", p: 0.7, L: 6  },
  { id: "R5", what: "farmer data leak",         p: 0.1, L: 80 },
  { id: "R6", what: "SMS price rise",           p: 0.6, L: 2  },
  { id: "R7", what: "map API licence change",   p: 0.2, L: 10 },
  { id: "R8", what: "estimate too optimistic",  p: 0.6, L: 10 },
];
const band = (x, cuts) => 1 + cuts.filter(c => x > c).length;   // 1..5
const pBand = p => band(p, [0.2, 0.4, 0.6, 0.8]), iBand = L => band(L, [2, 5, 10, 20]);
const zone = s => s >= 12 ? "HIGH" : s >= 5 ? "MED " : "LOW ";
for (const r of risks) r.re = r.p * r.L;
risks.sort((a, b) => b.re - a.re);
console.log("id  RE    P-band x I-band = score zone  risk");
for (const r of risks) {
  const s = pBand(r.p) * iBand(r.L);
  console.log(r.id, r.re.toFixed(1).padStart(5), "  ", pBand(r.p), "x", iBand(r.L),
    "=", String(s).padStart(2), " ", zone(s), r.what);
}
console.log("total RE =", risks.reduce((t, r) => t + r.re, 0).toFixed(1), "lakh");
const plans = [                       // proposed mitigation: new P (maybe new L), cost
  { id: "R3", act: "load test + autoscaling",  cost: 3,   p: 0.1 },
  { id: "R5", act: "security audit + encrypt", cost: 4,   p: 0.02 },
  { id: "R2", act: "pairing + runbooks",       cost: 1.5, p: 0.15, L: 10 },
  { id: "R6", act: "2-year SMS contract",      cost: 1,   p: 0.3 },
];
for (const m of plans) {
  const r = risks.find(x => x.id === m.id), after = m.p * (m.L ?? r.L);
  const rrl = (r.re - after) / m.cost;                  // Boehm's RRL
  console.log(m.id, m.act.padEnd(25), "RE", r.re.toFixed(1), "->", after.toFixed(1),
    " RRL =", rrl.toFixed(2), rrl > 1 ? "worth it" : "weak");
}

id  RE    P-band x I-band = score zone  risk
R3  12.0    3 x 5 = 15   HIGH Eid traffic overload
R5   8.0    1 x 5 =  5   MED  farmer data leak
R1   6.0    3 x 4 = 12   HIGH payment API changes
R8   6.0    3 x 3 =  9   MED  estimate too optimistic
R2   4.5    2 x 4 =  8   MED  key developer leaves
R4   4.2    4 x 3 = 12   HIGH requirements keep moving
R7   2.0    1 x 3 =  3   LOW  map API licence change
R6   1.2    3 x 1 =  3   LOW  SMS price rise
total RE = 43.9 lakh
R3 load test + autoscaling   RE 12.0 -> 2.4  RRL = 3.20 worth it
R5 security audit + encrypt  RE 8.0 -> 1.6  RRL = 1.60 worth it
R2 pairing + runbooks        RE 4.5 -> 1.5  RRL = 2.00 worth it
R6 2-year SMS contract       RE 1.2 -> 0.6  RRL = 0.60 weak

৪ · Risk register, trigger, contingency আর RMMM

বিশ্লেষণ করা ঝুঁকিগুলো রাখা হয় একটি জীবন্ত তালিকায় — risk register. বিয়েবাড়ির আয়োজনের তালিকার মতো: কোন কাজে কী গোলমাল হতে পারে, কে দায়িত্বে, আগে কী করা হবে, আর গোলমাল হলে বিকল্প কী (বাবুর্চি না এলে কোন হোটেলে ফোন)। Register সাধারণত একটি spreadsheet বা issue tracker-এর বিশেষ ধরনের টিকিট; ফরম্যাট প্রতিষ্ঠানভেদে আলাদা, কিন্তু মূল ঘরগুলো প্রায় একই। নিচে R3-এর সারিটি ধাপে ধাপে পূরণ করা দেখুন।

Mitigation বনাম contingency

দুটি গুলিয়ে ফেলা খুব সাধারণ ভুল। Mitigation আগেই করা হয়, সম্ভাবনা বা ক্ষতি কমাতে — খরচ নিশ্চিত, ঝুঁকি ঘটুক বা না ঘটুক। Contingency শুধু ঝুঁকি ঘটলে বা trigger জ্বললে চালু হয় — আগে থেকে শুধু পরিকল্পনা আর অনুমোদন নেওয়া থাকে। লোডশেডিংয়ের উদাহরণে: IPS কিনে রাখা mitigation; বিদ্যুৎ গেলে কোন কাজ আগে বন্ধ করবেন, কার কাছে জেনারেটর ভাড়া পাবেন — contingency. বাজেটে contingency-র জন্য আলাদা সংরক্ষিত অর্থ (contingency reserve) রাখার রীতি project management-এর বইয়ে প্রচলিত।

RMMM plan (Pressman)

Roger Pressman-এর পাঠ্যবই Software Engineering: A Practitioner's Approach ঝুঁকির পরিকল্পনাকে RMMM নামে তিন ভাগে লিখতে বলে — Risk Mitigation (এড়ানো বা কমানোর ব্যবস্থা), Monitoring (কোন সূচক দেখে বুঝবেন ঝুঁকি বাড়ছে) আর Management (ঝুঁকি ঘটলে কী করবেন, অর্থাৎ contingency). বাস্তবে অনেক দল আলাদা RMMM দলিল না রেখে register-এর ঘরগুলোতেই এই তিনটি তথ্য রাখে — নাম নয়, তিনটি প্রশ্নের উত্তর থাকা জরুরি।

৫ · ঝুঁকির জবাব — avoid, transfer, mitigate, accept আর RRL

প্রতিটি ঝুঁকির জন্য একটি risk response কৌশল বাছতে হয়। Project Management Institute (PMI)-এর PMBOK Guide আর বেশিরভাগ পাঠ্যবই ক্ষতিকর ঝুঁকির (threat) জন্য চারটি মূল কৌশল বলে:

ঝুঁকি সবসময় খারাপ নয় — অনিশ্চয়তা ভালো দিকেও যেতে পারে (opportunity): ধরুন একটি সরকারি কৃষি-তথ্য সেবা নতুন open API দিতে পারে, যা পেলে দামের তথ্য বিনা খরচে দেখানো যাবে। PMBOK-এর ষষ্ঠ সংস্করণ (২০১৭) সুযোগের জন্য exploit (নিশ্চিতভাবে কাজে লাগানো), share (অংশীদারের সাথে ভাগ করা), enhance (সম্ভাবনা বা লাভ বাড়ানো) আর accept বলে, আর দুই দিকেই escalate (project-এর বাইরের উচ্চতর কর্তৃপক্ষের কাছে পাঠানো) যোগ করে। পরের সংস্করণগুলো নীতিভিত্তিক হওয়ায় তালিকার উপস্থাপনা বদলেছে, তাই পরীক্ষার উত্তরে কোন সংস্করণ মানছেন উল্লেখ করা নিরাপদ।

Risk reduction leverage — কোন প্রতিকার আগে

টাকা সীমিত, প্রতিকারের প্রস্তাব অনেক। Boehm-এর ১৯৯১ সালের প্রবন্ধের risk reduction leverage (RRL) এই সিদ্ধান্তের একটি সরল মাপ:

RRL ১-এর বেশি মানে খরচের চেয়ে বেশি প্রত্যাশিত ক্ষতি কমছে; যত বড়, তত ভালো বিনিয়োগ। নিচে R3-এর জন্য দুটি প্রস্তাব তুলনা করা হলো।

৬ · Expected monetary value আর decision tree

কিছু সিদ্ধান্ত একটি ঝুঁকির প্রতিকারের চেয়ে বড় — যেমন payment আর হিসাবের অংশটি নিজেরা বানাবেন (build), নাকি তৈরি একটি software কিনবেন (buy). প্রতিটি পথে আলাদা অনিশ্চয়তা। এখানে কাজে লাগে expected monetary value (EMV): প্রতিটি সম্ভাব্য ফলের মূল্য তার সম্ভাবনা দিয়ে গুণ করে যোগফল, অর্থাৎ EMV = Σ (P_i × মূল্য_i). RE আসলে EMV-রই একটি বিশেষ রূপ — শুধু খারাপ ফলটি ধরে।

একাধিক ধাপের সিদ্ধান্ত আঁকা হয় decision tree দিয়ে। এতে দুই রকম শাখা-বিন্দু: decision node (□, যেখানে আপনি বাছেন) আর chance node (○, যেখানে ভাগ্য বাছে, সম্ভাবনাসহ)। হিসাব চলে ডান থেকে বাঁয়ে (rollback): chance node-এ সম্ভাবনা দিয়ে গড়, decision node-এ খরচ বাদ দিয়ে সবচেয়ে বড়টি।

# Build vs buy: decision tree rolled back by expected monetary value (EMV).
# Values in lakh taka (fictional). Leaf = benefit over 3 years; cost on the branch.
tree = ("decision", {
    "build": (40, ("chance", [
        (0.6, ("leaf", 120)),                        # finished on time
        (0.4, ("decision", {                         # late: continue or stop?
            "continue": (10, ("chance", [(0.5, ("leaf", 80)), (0.5, ("leaf", 40))])),
            "abandon":  (0,  ("leaf", 15)),          # salvage value
        })),
    ])),
    "buy": (30, ("chance", [(0.8, ("leaf", 95)), (0.2, ("leaf", 45))])),
})

def emv(node, depth=0, label="start"):
    kind, body = node
    pad = "  " * depth
    if kind == "leaf":
        return body                                  # payoff, nothing to print
    if kind == "chance":
        value = sum(p * emv(child, depth + 1, f"p={p}") for p, child in body)
    else:  # decision: pick the branch with the largest (EMV - cost)
        options = {name: emv(child, depth + 1, name) - cost
                   for name, (cost, child) in body.items()}
        best = max(options, key=options.get)
        value = options[best]
        print(f"{pad}  choose {best!r}: " +
              ", ".join(f"{k}={v:.1f}" for k, v in options.items()))
    print(f"{pad}{label}: {kind} EMV = {value:.1f}")
    return value

emv(tree)
# Sensitivity: build EMV = 120p + 50(1-p) - 40; at what p does build tie with buy?
p_tie = (55 - 50 + 40) / (120 - 50)
print(f"build beats buy only if P(on time) > {p_tie:.3f}")

      continue: chance EMV = 60.0
      choose 'continue': continue=50.0, abandon=15.0
    p=0.4: decision EMV = 50.0
  build: chance EMV = 92.0
  buy: chance EMV = 85.0
  choose 'buy': build=52.0, buy=55.0
start: decision EMV = 55.0
build beats buy only if P(on time) > 0.643

৭ · Quality management — quality planning, QA আর QC

Risk management প্রশ্ন করে “কী খারাপ হতে পারে?”; quality management প্রশ্ন করে “ভালো বলতে কী বুঝি, আর নিশ্চিত করব কীভাবে?” Quality কী আর কীভাবে মাপা হয় — ISO/IEC 25010, MTBF, DRE, cost of quality — তা পর্ব ০৩-এ দেখেছেন। এখানে প্রশ্নটি ব্যবস্থাপনার: কোন কাজ কে কখন করবেন, যাতে quality দুর্ঘটনা না হয়ে নিয়মিত ফল হয়।

ISO 9000:2015-এর সংজ্ঞার ভাব অনুযায়ী, QA হলো quality management-এর সেই অংশ যা “quality requirement পূরণ হবে” এমন আস্থা দেয়, আর QC সেই অংশ যা requirement পূরণ করার দিকে মনোযোগ দেয়। বাস্তবে software শিল্পে “QA” শব্দটি প্রায়ই tester-এর পদবি হিসেবে ব্যবহৃত হয় — যে কাজটি আসলে বেশিরভাগই QC. শব্দের এই ঢিলেঢালা ব্যবহার জানা থাকলে চাকরির বিজ্ঞপ্তি আর পাঠ্যবইয়ের মধ্যে বিভ্রান্তি হয় না। Software QA প্রক্রিয়ার একটি মানদণ্ড IEEE Std 730 (সর্বশেষ বড় সংস্করণ ২০১৪, আমাদের জানামতে)। Verification আর validation-এর পার্থক্য, আর test-এর স্তর পর্ব ৪৫-এ আছে।

৮ · Process improvement — CMMI, ISO 9001, Six Sigma, PDCA আর PSP/TSP

QA-র বড় প্রশ্ন: আমাদের প্রক্রিয়া কতটা পরিপক্ব, আর কীভাবে উন্নত করব? এর জন্য কয়েকটি প্রতিষ্ঠিত কাঠামো আছে।

CMMI — পাঁচটি maturity level

CMMI (Capability Maturity Model Integration)-এর শিকড় SEI-তে Watts Humphrey-র কাজ আর software CMM-এ (সংস্করণ ১.০ ১৯৯১, ১.১ ১৯৯৩); পরে বিভিন্ন CMM মিলিয়ে CMMI আসে (প্রথম সংস্করণ ২০০০ সালের দিকে; বহুল ব্যবহৃত v1.3, ২০১০)। Staged representation-এ প্রতিষ্ঠানের প্রক্রিয়াকে পাঁচটি maturity level-এ রাখা হয়:

প্রতিটি level-এ কিছু process area (v2.0 থেকে নাম practice area) থাকে — যেমন requirement management, project planning, configuration management, peer review. একটি প্রতিষ্ঠান level ৩ “পেয়েছে” মানে, একটি আনুষ্ঠানিক appraisal-এ (v1.3-এ SCAMPI নামের পদ্ধতি) দেখা গেছে ওই level পর্যন্ত সব নির্ধারিত অংশ নিয়মিত চর্চা হচ্ছে। এটি পণ্যের মানের সনদ নয়, প্রক্রিয়ার মূল্যায়ন। নিচে একটি অংশ — peer review — কীভাবে ধাপে ধাপে ওপরে ওঠে, তার একটি উদাহরণমূলক চিত্র (CMMI-র আসল practice-এর ভাষা নয়, ধারণাটি বোঝানোর জন্য সরল রূপ)।

ISO 9001 — quality management system

ISO 9001 একটি সাধারণ মানদণ্ড, যা যেকোনো শিল্পের প্রতিষ্ঠানের quality management system (QMS)-এর শর্ত বলে — software, পোশাক কারখানা বা হাসপাতাল, সবার জন্য একই। লেখার সময়ে প্রচলিত সংস্করণ ISO 9001:2015 (২০২৪ সালে জলবায়ু-বিষয়ক একটি ছোট সংশোধনী যোগ হয়েছে; নতুন সংস্করণের কাজ চলছে বলে জানা যায়)। ২০১৫ সংস্করণে আছে অন্যান্য ISO management system মানদণ্ডের সাথে মেলানো ১০টি clause-এর কাঠামো, risk-based thinking (clause ৬.১-এ ঝুঁকি ও সুযোগ বিবেচনা) আর ISO 9000-এর সাতটি নীতির ভিত্তি — যেমন customer focus, process approach আর evidence-based decision making.

Software-এ ISO 9001 কীভাবে প্রয়োগ করবেন, তার নির্দেশিকা ISO/IEC/IEEE 90003 (সর্বশেষ সংস্করণ ২০১৮, আমাদের জানামতে)। মনে রাখুন: ISO নিজে সনদ দেয় না; স্বাধীন certification body audit করে সনদ দেয়। আর ISO 9001 সনদ বলে প্রতিষ্ঠানের একটি নথিবদ্ধ, নিরীক্ষিত quality ব্যবস্থা আছে — প্রতিটি পণ্য ভালো, এমন নিশ্চয়তা দেয় না।

PDCA আর Six Sigma

PDCA (Plan–Do–Check–Act) সবচেয়ে সরল উন্নতির চক্র: পরিকল্পনা করুন, ছোট পরিসরে করুন, ফল মাপুন, তারপর ভালো হলে স্থায়ী করুন বা না হলে বদলান। এর শিকড় Bell Labs-এর পরিসংখ্যানবিদ Walter Shewhart-এর ১৯২০–৩০-এর দশকের কাজে; W. Edwards Deming ১৯৫০ সালে জাপানে বক্তৃতায় এটি ছড়ান, জাপানি প্রকৌশলীরা PDCA রূপ দেন, আর Deming নিজে পরে “Check”-এর বদলে “Study” (PDSA) পছন্দ করতেন। Scrum-এর retrospective আর Kanban-এর kaizen (পর্ব ০৬) এই চক্রেরই আত্মীয়।

Six Sigma ১৯৮০-র দশকের মাঝামাঝি Motorola-তে শুরু (প্রকৌশলী Bill Smith-এর নাম প্রায়ই আসে), ১৯৯০-এর দশকে General Electric-এ বিখ্যাত হয়। লক্ষ্য প্রক্রিয়ার ওঠানামা কমানো; “প্রতি দশ লাখ সুযোগে ৩.৪টি defect” সংখ্যাটি দীর্ঘ মেয়াদে ১.৫σ সরে যাওয়ার একটি বিতর্কিত অনুমানের ওপর দাঁড়ানো। উন্নতির প্রকল্প চলে DMAIC ধাপে: Define (সমস্যা আর লক্ষ্য), Measure (বর্তমান অবস্থা মাপা), Analyze (মূল কারণ), Improve (সমাধান পরীক্ষা) আর Control (উন্নতি ধরে রাখা, প্রায়ই control chart দিয়ে)।

PSP আর TSP

Humphrey-র আরেকটি অবদান Personal Software Process (PSP; বই A Discipline for Software Engineering, ১৯৯৫): একজন ডেভেলপার নিজের সময়, আকার আর defect মেপে নিজের অনুমান আর quality উন্নত করেন — যেন একজন ব্যক্তির জন্য ছোট CMMI. দলের রূপ Team Software Process (TSP). মাপজোখের শ্রমের কারণে এদের ব্যবহার সীমিত, তবে “নিজের defect কোথা থেকে আসে, মেপে দেখা” ধারণাটি আজও কাজের।

৯ · Software metric programme — GQM, metric-এর ধরন, ফাঁদ আর control chart

“চলুন সব কিছু মাপি” — এভাবে শুরু হওয়া metric programme প্রায়ই dashboard-ভর্তি সংখ্যায় শেষ হয়, যা কেউ ব্যবহার করেন না। ভালো software metric শুরু হয় উল্টো দিক থেকে: আগে প্রশ্ন, তারপর সংখ্যা।

GQM — Goal, Question, Metric

Victor Basili ও David Weiss ১৯৮৪ সালে NASA-র software প্রকল্পের তথ্য সংগ্রহ নিয়ে একটি প্রবন্ধে যে পদ্ধতির ভিত্তি দেন, পরে Basili, Caldiera ও Rombach (১৯৯৪) তা Goal–Question–Metric (GQM) নামে গুছিয়ে লেখেন। তিন স্তর:

• Goal — কী অর্জন করতে চাই, কার দৃষ্টিতে। প্রচলিত ছাঁচ: “বস্তু-কে বিশ্লেষণ করা, উদ্দেশ্য-এ, কোন গুণ-এর দিক থেকে, কার দৃষ্টিতে, কোন প্রেক্ষাপটে।”
• Question — লক্ষ্য পূরণ হচ্ছে কি না বুঝতে কোন প্রশ্নের উত্তর লাগবে।
• Metric — প্রতিটি প্রশ্নের উত্তর দিতে কোন সংখ্যা, কোন সংজ্ঞায়, কোথা থেকে।

কৃষি-বাজার অ্যাপের দল লক্ষ্য ঠিক করল: “Release প্রক্রিয়াকে বিশ্লেষণ করা, ব্যবহারকারীর কাছে পৌঁছানো defect কমানোর উদ্দেশ্যে, ব্যবহারকারীর (কৃষক ও ক্রেতা) দৃষ্টিতে।” দুটি প্রশ্ন আর তিনটি metric — যার একটি নতুন: escape rate, অর্থাৎ মোট defect-এর কত ভাগ release-এর পরে ব্যবহারকারী পেলেন (= ১ − DRE).

# Goal-Question-Metric: print the tree and compute each metric from a data table.
releases = [  # fictional: size, defects before/after release, fix days (sample)
    {"v": "r1", "kloc": 20, "pre": 72, "post": 18, "fix_days": [2, 5, 1, 9, 3]},
    {"v": "r2", "kloc": 24, "pre": 95, "post": 12, "fix_days": [1, 2, 4, 2]},
    {"v": "r3", "kloc": 30, "pre": 88, "post": 22, "fix_days": [6, 3, 8, 2, 11]},
]
def escape_rate(r): return r["post"] / (r["pre"] + r["post"])
def post_density(r): return r["post"] / r["kloc"]
def median_fix(r):
    d = sorted(r["fix_days"]); n = len(d)
    return d[n // 2] if n % 2 else (d[n // 2 - 1] + d[n // 2]) / 2

gqm = {
    "goal": "Reduce defects that reach farmers and buyers (viewpoint: users)",
    "questions": [
        ("Q1 How many defects escape to users?",
         [("M1 escape rate = post/(pre+post)", escape_rate, "{:.1%}"),
          ("M2 post-release defects per KLOC", post_density, "{:.2f}")]),
        ("Q2 How fast do we fix what escapes?",
         [("M3 median days to fix", median_fix, "{:.1f}")]),
    ],
}
print("G :", gqm["goal"])
for q, metrics in gqm["questions"]:
    print("  " + q)
    for name, fn, fmt in metrics:
        values = "  ".join(r["v"] + "=" + fmt.format(fn(r)) for r in releases)
        print("     " + name.ljust(34) + values)
targets = {"M1": (escape_rate, 0.15), "M2": (post_density, 0.8), "M3": (median_fix, 3)}
last = releases[-1]
print("latest", last["v"], "vs target:", ", ".join(
    k + (" ok" if fn(last) <= t else " MISSED") for k, (fn, t) in targets.items()))

G : Reduce defects that reach farmers and buyers (viewpoint: users)
  Q1 How many defects escape to users?
     M1 escape rate = post/(pre+post)  r1=20.0%  r2=11.2%  r3=20.0%
     M2 post-release defects per KLOC  r1=0.90  r2=0.50  r3=0.73
  Q2 How fast do we fix what escapes?
     M3 median days to fix             r1=3.0  r2=2.0  r3=6.0
latest r3 vs target: M1 MISSED, M2 ok, M3 MISSED

তিন ধরনের metric

Project metric-এর একটি ছোট হিসাব: Earned value পদ্ধতিতে PV (planned value — এ পর্যন্ত যতটুকু কাজের বাজেট পরিকল্পনায় ছিল), EV (earned value — আসলে যতটুকু কাজ শেষ, তার বাজেট-মূল্য) আর AC (actual cost — আসলে খরচ)। Schedule variance SV = EV − PV, cost variance CV = EV − AC. ধরুন PV ৳৫০ লাখ, EV ৳৪০ লাখ, AC ৳৫৫ লাখ: SV = −১০ (পিছিয়ে), CV = −১৫ (বাজেট ছাড়িয়ে), SPI = EV ÷ PV = ০.৮, CPI = EV ÷ AC ≈ ০.৭৩। অর্থাৎ পরিকল্পনার ৮০% গতিতে চলছে, আর প্রতি টাকা খরচে ৭৩ পয়সার কাজ হচ্ছে।

Metric-এর ফাঁদ

• Goodhart-এর সূত্র: সংখ্যা লক্ষ্য হলে মানুষ সংখ্যাটিই ঠিক করেন, আসল গুণ নয় — coverage-এর উদাহরণ পর্ব ৫০-এ দেখেছেন। “Escape rate ১০%-এর নিচে” বোনাসের সাথে জুড়লে ব্যবহারকারীর অভিযোগ “feature request” নামে লেখা শুরু হতে পারে।
• Vanity metric: যে সংখ্যা সবসময় বাড়ে আর ভালো লাগে, কিন্তু কোনো সিদ্ধান্ত বদলায় না — মোট download, মোট commit, মোট লেখা লাইন। Eric Ries-এর The Lean Startup (২০১১) শব্দটি জনপ্রিয় করে। পরীক্ষা: “এই সংখ্যা খারাপ হলে আমরা কী আলাদা করব?” উত্তর না থাকলে সেটি vanity.
• মানুষ মাপা আর সংজ্ঞাহীন সংখ্যা: ব্যক্তির defect-সংখ্যা দিয়ে মূল্যায়ন করলে মানুষ defect লুকান; আর “defect” কোনটি লেখা না থাকলে মাসে মাসে তুলনা অর্থহীন।

সময়ের সাথে সংখ্যা পড়া — statistical process control

এই সপ্তাহে defect ১৭টি, গত সপ্তাহে ১০টি — এটা কি সমস্যা? সব প্রক্রিয়ায় স্বাভাবিক ওঠানামা থাকে (common cause variation); আবার কখনো নির্দিষ্ট কোনো কারণ থাকে, যেমন তাড়াহুড়ার একটি release (special cause). Shewhart ১৯২৪ সালে Bell Labs-এ এ দুটি আলাদা করার জন্য control chart প্রস্তাব করেন — statistical process control (SPC)-এর মূল হাতিয়ার। একটি স্থির সময়ের তথ্য থেকে মাঝের রেখা (mean) আর দুই সীমা টানা হয়: UCL = mean + 3σ, LCL = mean − 3σ. সীমার বাইরের বিন্দু বা অস্বাভাবিক নকশা (pattern) special cause-এর সংকেত। Western Electric-এর ১৯৫৬ সালের Statistical Quality Control Handbook-এ এমন কয়েকটি নিয়ম আছে; বহুল উদ্ধৃত একটি হলো, মাঝের রেখার একই পাশে পরপর ৮টি বিন্দু (বইভেদে সংখ্যা ৭, ৮ বা ৯ দেখা যায়)।

// Control chart for weekly defect counts (fictional team, seeded data).
function mulberry32(a) { return function () {
  a |= 0; a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rnd = mulberry32(62);
const weeks = [];
for (let w = 1; w <= 24; w++) {
  let mean = 12;
  if (w >= 15) mean = 15;                    // a quiet process change from week 15
  let x = Math.round(mean + (rnd() + rnd() + rnd() - 1.5) * 4);
  if (w === 13) x += 14;                     // one bad release in week 13
  weeks.push(x);
}
const base = weeks.slice(0, 12);             // limits come from weeks 1-12 only
const m = base.reduce((s, x) => s + x, 0) / base.length;
const sd = Math.sqrt(base.reduce((s, x) => s + (x - m) ** 2, 0) / (base.length - 1));
const UCL = m + 3 * sd, LCL = Math.max(0, m - 3 * sd);
console.log("mean", m.toFixed(2), " sigma", sd.toFixed(2),
  " UCL", UCL.toFixed(2), " LCL", LCL.toFixed(2));
let run = 0, side = 0;
weeks.forEach((x, i) => {
  const s = Math.sign(x - m);                // +1 above centre, -1 below
  run = (s !== 0 && s === side) ? run + 1 : 1; side = s;
  const flags = [];
  if (x > UCL || x < LCL) flags.push("OUT of limits");
  if (run >= 8 && s !== 0) flags.push("run of " + run + (s > 0 ? " above" : " below"));
  const bar = "#".repeat(x);
  console.log(String(i + 1).padStart(2), String(x).padStart(3), bar.padEnd(28), flags.join(", "));
});

mean 11.75  sigma 2.67  UCL 19.75  LCL 3.75
 1  10 ##########
 2   9 #########
 3  17 #################
 4  11 ###########
 5  10 ##########
 6  14 ##############
 7   9 #########
 8  14 ##############
 9  13 #############
10  13 #############
11  13 #############
12   8 ########
13  27 ###########################  OUT of limits
14   7 #######
15  18 ##################
16  15 ###############
17  14 ##############
18  14 ##############
19  14 ##############
20  14 ##############
21  16 ################
22  16 ################             run of 8 above
23  14 ##############               run of 9 above
24  16 ################             run of 10 above

এই পর্বের ধরনের সংখ্যা-নির্ভর আরও প্রশ্ন, পূর্ণ সমাধানসহ, পাবেন পর্ব ৬৬-এ (Numerical সমস্যার অনুশীলন)।

১০ · AI-এর যুগে risk আর quality management

AI এক মিনিটে চল্লিশটি ঝুঁকির তালিকা বা একটি পুরো quality plan লিখে দিতে পারে। দেখতে পেশাদার, কিন্তু তালিকা লেখা risk management নয় — সম্ভাবনা আর ক্ষতির বিচার, দায়িত্ব আর নজরদারিই আসল কাজ, আর সেগুলো আপনার project-এর তথ্য ছাড়া হয় না। এই কাজে AI-এর সাধারণ ভুল:

AI-এর দেওয়া ঝুঁকি বা quality-র কাজ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি সম্ভাবনা আর ক্ষতির অঙ্ক দলের সাথে বসে ঠিক করেছি, AI-এর সংখ্যা সরাসরি নিইনি
• RE, RRL আর EMV একটি ছোট script-এ বা হাতে আবার হিসাব করেছি
• প্রতিটি ঝুঁকির owner একজন নির্দিষ্ট মানুষ, আর trigger মাপা যায়
• CMMI, ISO 9001 বা অন্য মানদণ্ডের নাম, সংস্করণ আর clause অফিসিয়াল সূত্রে মিলিয়েছি
• প্রস্তাবিত প্রতিটি metric-এর পেছনে একটি goal আর question আছে
• Prompt-এ আসল গ্রাহক, দাম, চুক্তি বা নিরাপত্তা-দুর্বলতার তথ্য দিইনি