Software quality — ISO/IEC 25010, maintainability, reliability আর quality মাপা

১ · “ভালো software” বলতে আসলে কী বোঝায়

একটি কাল্পনিক দৃশ্য দিয়ে শুরু করি। একটি বিশ্ববিদ্যালয়ের ফলাফল পোর্টাল (কাল্পনিক) বানানো হলো। Requirement ছিল: “রোল নম্বর দিলে ফল দেখাবে।” ডেভেলপার দল সব test পাস করিয়ে জমা দিল। ফল প্রকাশের দিন সকাল ১০টায় হাজার হাজার শিক্ষার্থী একসাথে ঢুকলেন — পাতা খুলতে লাগল দুই মিনিট, অনেকে পেলেন শুধু error. আবার যাঁরা ফল পেলেন, তাঁদের কয়েকজনের ৮০ নম্বরে গ্রেড এলো A, অথচ নিয়মে A+ হওয়ার কথা।

Software টি কি “ভালো”? ডেভেলপার বলবেন, “সব requirement তো মেনেছি।” শিক্ষার্থী বলবেন, “যেদিন দরকার, সেদিনই কাজ করেনি।” দুজনেই আংশিক ঠিক। এই পর্বের মূল প্রশ্ন এটাই — software quality কী, আর সেটি কীভাবে মাপা যায়।

দুটি বিখ্যাত সংজ্ঞা

১৯৮৪ সালে David Garvin একটি প্রবন্ধে quality দেখার পাঁচটি দৃষ্টিভঙ্গি দেখান — transcendent (দেখলেই চেনা যায়, সংজ্ঞায় আনা কঠিন), product-based (পণ্যের মাপা যায় এমন গুণ), user-based (ব্যবহারকারীর সন্তুষ্টি), manufacturing-based (spec মেনে তৈরি) আর value-based (দামের তুলনায় কতটা পাওয়া গেল)। পরে software engineering-এর লেখকেরা (যেমন Kitchenham ও Pfleeger, ১৯৯৬) এই পাঁচ দৃষ্টিভঙ্গি software-এ প্রয়োগ করে আলোচনা করেন। মূল শিক্ষা হলো: quality কোনো একটি সংখ্যা নয়; কে দেখছেন, তার ওপর নির্ভর করে কোন দিকটি জরুরি।

২ · ISO/IEC 25010 — quality-র একটি সাধারণ ভাষা

দলের একজন বলছেন “software টা ভালো না”, আরেকজন বলছেন “ভালোই তো”। দুজন হয়তো আলাদা জিনিসের কথা বলছেন — একজন গতির, আরেকজন কোডের পরিচ্ছন্নতার। এই বিভ্রান্তি কমাতে আন্তর্জাতিক মানসংস্থা ISO আর IEC মিলে quality-র একটি শ্রেণিবিন্যাস দাঁড় করিয়েছে: ISO/IEC 25010. এটি SQuaRE (Systems and software Quality Requirements and Evaluation) নামের ISO/IEC 25000 সিরিজের অংশ, আর আগের ISO/IEC 9126 (১৯৯১; চার খণ্ডে হালনাগাদ ২০০১–২০০৪) মডেলের উত্তরসূরি।

২০১১ সালের সংস্করণে product quality-কে আটটি quality characteristic-এ ভাগ করা হয়েছে, আর প্রতিটির নিচে কয়েকটি sub-characteristic. নিচের গাছটি দেখুন — প্রতিটি বাক্সে দুটি করে উদাহরণ দেওয়া আছে, পুরো তালিকা টেবিলে।

Quality in use — ব্যবহারের সময়ের গুণমান

Product quality বলে software-এর নিজের গুণ। কিন্তু একই software একজন অভিজ্ঞ হিসাবরক্ষকের হাতে চমৎকার, আর প্রথমবার স্মার্টফোন হাতে নেওয়া একজন দোকানদারের হাতে বিভ্রান্তিকর হতে পারে। তাই ২০১১ সালের ISO/IEC 25010-এ আলাদা একটি quality in use মডেল আছে, যার পাঁচটি characteristic: effectiveness (কাজটা আসলে সম্পন্ন হলো কি না), efficiency (কত সময় ও শ্রম লাগল), satisfaction (ব্যবহারকারী সন্তুষ্ট ও আস্থাশীল কি না), freedom from risk (অর্থ, স্বাস্থ্য বা পরিবেশের ঝুঁকি কতটা কম) আর context coverage (ভিন্ন ভিন্ন পরিস্থিতিতেও কাজ করে কি না)।

৩ · পুরোনো দুই মডেল — McCall আর Boehm

ISO-র আগেও quality-কে ভাগ করে দেখার চেষ্টা হয়েছে। পরীক্ষায় প্রায়ই এই দুই মডেলের তুলনা চাওয়া হয়, তাই সংক্ষেপে জেনে রাখুন।

দুটি মডেলের মূল ধারণা একই: বড়, অস্পষ্ট গুণকে ভেঙে ছোট ছোট গুণে নামানো, যতক্ষণ না কোনো সংখ্যা দিয়ে মাপা যায়। ISO/IEC 9126 আর পরে 25010 এই ধারণাকে আন্তর্জাতিক ঐকমত্যে নিয়ে আসে। পর্ব ০২-এ (software crisis-এর ইতিহাস) দেখবেন, ১৯৭০-এর দশকে বড় সরকারি ও সামরিক project-এর অভিজ্ঞতা থেকেই এ ধরনের মডেলের চাহিদা তৈরি হয়েছিল।

৪ · Quality মাপা — metric আর quality scenario

“অ্যাপটা দ্রুত হতে হবে”, “ব্যবহার সহজ হতে হবে”, “নিরাপদ হতে হবে” — requirement-এর খাতায় এমন বাক্য প্রায়ই দেখা যায়। সমস্যা হলো, এগুলো test করা যায় না। ৫ সেকেন্ড দ্রুত, নাকি ৫০০ মিলিসেকেন্ড? কার জন্য সহজ? কখন দ্রুত — রাত ২টায়, নাকি ফল প্রকাশের সকালে? যা মাপা যায় না, তা নিয়ে ডেভেলপার আর গ্রাহকের বিবাদ মেটানোর কোনো উপায় থাকে না।

সমাধান হলো দুটি জিনিস। প্রথমত metric — একটি সংখ্যা, যার মাপার নিয়ম স্পষ্ট (কী গোনা হবে, কোন একক, কোথা থেকে তথ্য)। দ্বিতীয়ত quality scenario — একটি ছোট, কাঠামোবদ্ধ বাক্য, যাতে বলা থাকে কোন পরিস্থিতিতে কী ঘটলে software কী প্রতিক্রিয়া দেবে আর সেটি কোন সংখ্যা দিয়ে মাপা হবে। Software Engineering Institute (SEI)-র লেখকেরা (যেমন Bass, Clements ও Kazman-এর Software Architecture in Practice) এর ছয়টি অংশ ব্যবহার করেন: source, stimulus, artifact, environment, response আর response measure. নিচের stepper-এ একটি অস্পষ্ট চাওয়াকে ধাপে ধাপে scenario বানানো দেখুন।

Percentile আর tail latency কেন গড়ের চেয়ে ভালো, তার বিস্তারিত গণিত System Design কোর্সের পর্ব ০৪ · Latency, throughput আর percentile-এ আছে। একই কৌশল অন্য গুণেও খাটে:

৫ · Reliability — fault, error, failure আর MTBF-MTTR

“Software-এ bug আছে” — কথাটা আমরা খুব ঢিলেঢালাভাবে বলি। কিন্তু reliability মাপতে হলে তিনটি জিনিস আলাদা করতে হয়: কোডের ভেতরের ভুল, চলার সময়ের ভুল অবস্থা, আর বাইরে দেখা দেওয়া ব্যর্থতা। দুঃখের বিষয়, শব্দগুলোর অর্থ নিয়ে দুটি প্রচলিত ধারা আছে — পরীক্ষায় লেখার সময় কোন ধারা মানছেন, সেটি উল্লেখ করা নিরাপদ।

এই শিকলের সবচেয়ে গুরুত্বপূর্ণ শিক্ষা: fault থাকলেই failure হয় না। একটি ছোট গ্রেডিং function দিয়ে দেখি। নিয়ম: ৮০ বা তার বেশি পেলে A+, ৭০ থেকে ৭৯ পেলে A. প্রোগ্রামার ভুল করে >=-এর জায়গায় > লিখেছেন।

1function grade(m) {2  if (m > 80) return "A+";  // spec: 80 বা বেশি3  if (m >= 70) return "A";4  return "B-";5}

কতবার failure দেখা যাবে, তা নির্ভর করে কে কোন ইনপুট দেন তার ওপর — একে বলে usage profile বা operational profile. নিচের program একই buggy function-কে দুই রকম শিক্ষার্থীর দল দিয়ে ১০০০ বার করে চালায়। এলোমেলো সংখ্যা আসে একটি seed দেওয়া PRNG (mulberry32) থেকে, তাই প্রতিবার একই ফল আসবে।

// A fault can sleep: it causes a failure only for some inputs.
// Spec: marks 80 or more -> "A+", 70..79 -> "A", below 70 -> "B or less".
function gradeBuggy(m) {
  if (m > 80) return "A+";        // FAULT: should be m >= 80
  if (m >= 70) return "A";
  return "B-";
}
function gradeSpec(m) {           // the oracle: what the spec says
  return m >= 80 ? "A+" : m >= 70 ? "A" : "B-";
}
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(2026);
// Two usage profiles: uniform marks 0..100, and a class of strong students 75..100
const profiles = { "uniform 0-100": () => Math.floor(rnd() * 101),
                   "strong 75-100": () => 75 + Math.floor(rnd() * 26) };
for (const [name, draw] of Object.entries(profiles)) {
  let failures = 0, first = null;
  for (let i = 1; i <= 1000; i++) {
    const m = draw();
    if (gradeBuggy(m) !== gradeSpec(m)) { failures++; if (first === null) first = i; }
  }
  console.log(name.padEnd(14), "failures:", failures, "/ 1000, first at run", first);
}
console.log("gradeBuggy(80) =", gradeBuggy(80), " spec says", gradeSpec(80));

uniform 0-100  failures: 5 / 1000, first at run 8
strong 75-100  failures: 36 / 1000, first at run 3
gradeBuggy(80) = A  spec says A+

MTBF, MTTR আর availability

Reliability মাপার দুটি পরিচিত সংখ্যা: MTBF (Mean Time Between Failures — দুটি failure-এর মাঝে গড়ে কত সময় system ঠিক চলে) আর MTTR (Mean Time To Repair বা Restore — failure-এর পর আবার চালু হতে গড়ে কত সময় লাগে)। এ দুটি থেকে দীর্ঘ সময়ের গড় availability:

// Availability from MTBF and MTTR (steady state): A = MTBF / (MTBF + MTTR)
const HOURS_PER_YEAR = 365 * 24;                 // 8760 h
const systems = [                                // fictional systems, hours
  { name: "result-portal", mtbf: 720,  mttr: 4   },
  { name: "payment-api",   mtbf: 2000, mttr: 1   },
  { name: "chat-service",  mtbf: 200,  mttr: 0.1 },
  { name: "library-app",   mtbf: 8760, mttr: 8   },
];
for (const s of systems) {
  const A = s.mtbf / (s.mtbf + s.mttr);
  const downH = (1 - A) * HOURS_PER_YEAR;        // expected downtime per year
  const failures = HOURS_PER_YEAR / (s.mtbf + s.mttr);
  console.log(s.name.padEnd(14), (A * 100).toFixed(3) + "%",
    " down/yr " + downH.toFixed(2) + " h", " failures/yr " + failures.toFixed(1));
}
// Check one system by simulation: exponential up/down times, seeded PRNG
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(42), expo = m => -m * Math.log(1 - rnd());
let up = 0, down = 0;
for (let i = 0; i < 100000; i++) { up += expo(720); down += expo(4); }
console.log("simulated result-portal A =", (100 * up / (up + down)).toFixed(3) + "%");

result-portal  99.448%  down/yr 48.40 h  failures/yr 12.1
payment-api    99.950%  down/yr 4.38 h  failures/yr 4.4
chat-service   99.950%  down/yr 4.38 h  failures/yr 43.8
library-app    99.909%  down/yr 7.99 h  failures/yr 1.0

৯৯.৯%, ৯৯.৯৯% (“nines”) থেকে বন্ধ সময়ের বাজেট, একাধিক অংশ series বা parallel-এ জুড়লে availability কীভাবে বদলায়, আর redundancy — এসব System Design কোর্সের পর্ব ০৫ · Availability আর reliability-এ পূর্ণ হিসাবসহ আছে; এখানে আর পুনরাবৃত্তি করছি না।

৬ · Defect density আর defect removal efficiency

Reliability চালানো system-এর গুণ। কিন্তু release-এর আগে, তৈরির সময়েই quality-র আভাস পেতে দুটি পুরোনো ও বহুল ব্যবহৃত metric আছে।

• Defect density = defect-এর সংখ্যা / কোডের আকার। আকার সাধারণত মাপা হয় KLOC-এ (হাজার লাইন কোড)। কোন defect গোনা হবে — শুধু release-এর পরে পাওয়া, নাকি সব — সেটি আগে ঠিক করে নিতে হয়।
• DRE (Defect Removal Efficiency) = release-এর আগে পাওয়া defect / (আগে পাওয়া + পরে পাওয়া defect). অর্থাৎ মোট defect-এর কত ভাগ ব্যবহারকারীর হাতে পৌঁছানোর আগেই ধরা গেল। Capers Jones-এর মতো লেখকেরা এই metric জনপ্রিয় করেছেন; “পরে পাওয়া” সাধারণত release-এর পর নির্দিষ্ট একটি সময় (যেমন ৯০ দিন) ধরে গোনা হয়।

একটি কাল্পনিক release ধরে ধাপে ধাপে DRE বের করি। কোডের আকার ১৬ KLOC.

এক release-এর সংখ্যা দিয়ে খুব বেশি বলা যায় না; আসল তথ্য আসে প্রবণতা (trend) থেকে। নিচের program তিনটি কাল্পনিক release-এর হিসাব একসাথে করে।

// Defect density and Defect Removal Efficiency (DRE) per release.
// pre  = defects found BEFORE release (reviews + tests)
// post = defects reported by users in the first 90 days after release
const releases = [
  { v: "v1.0", kloc: 12, pre: 84,  post: 21 },
  { v: "v1.1", kloc: 15, pre: 120, post: 15 },
  { v: "v2.0", kloc: 22, pre: 150, post: 50 },
];
console.log("release KLOC total  total/KLOC post/KLOC  DRE");
for (const r of releases) {
  const total = r.pre + r.post;
  const dre = r.pre / total;                    // share caught before users
  console.log(r.v.padEnd(8) + String(r.kloc).padEnd(5) +
    String(total).padEnd(7) + (total / r.kloc).toFixed(2).padEnd(11) +
    (r.post / r.kloc).toFixed(2).padEnd(11) + (dre * 100).toFixed(1) + "%");
}
// Same numbers over all three releases together
const sum = k => releases.reduce((s, r) => s + r[k], 0);
const P = sum("pre"), Q = sum("post");
console.log("all     " + sum("kloc") + " KLOC, DRE = " + P + "/" + (P + Q) +
  " = " + (100 * P / (P + Q)).toFixed(1) + "%");

release KLOC total  total/KLOC post/KLOC  DRE
v1.0    12   105    8.75       1.75       80.0%
v1.1    15   135    9.00       1.00       88.9%
v2.0    22   200    9.09       2.27       75.0%
all     49 KLOC, DRE = 354/440 = 80.5%

৭ · Maintainability, usability-accessibility আর security

Maintainability — যে গুণ চোখে পড়ে না, কিন্তু খরচ ঠিক করে

একটি software তৈরিতে যত খরচ হয়, তার পরের বছরগুলোতে বদলানো, bug সারানো আর নতুন feature যোগে প্রায়ই তার চেয়ে বেশি খরচ হয় — এ কথা software engineering-এর বহু বইয়ে আছে, যদিও সঠিক অনুপাত নিয়ে বিভিন্ন সূত্রে ভিন্ন সংখ্যা পাওয়া যায়। তাই maintainability-কে কয়েকটি পরোক্ষ সূচক দিয়ে নজরে রাখা হয়:

এর কোনোটিই একা maintainability নয় — এগুলো আভাস। ১০০% coverage-এর কোডও অর্থহীন test-এ ভরা থাকতে পারে, আর complexity কম হলেও নাম আর গঠন বিভ্রান্তিকর হতে পারে। Maintainability-র অবনতি দীর্ঘ সময়ে কীভাবে technical debt হয়ে জমে, তা পর্ব ৪৩-এ দেখবেন।

Usability আর accessibility

Usability মানে নির্দিষ্ট ব্যবহারকারী নির্দিষ্ট কাজ কতটা কার্যকরভাবে, দক্ষতার সাথে আর সন্তুষ্ট হয়ে করতে পারেন। এর একটি অংশ accessibility — দৃষ্টি, শ্রবণ, চলাচল বা বোধশক্তির প্রতিবন্ধকতা থাকা মানুষও যেন software ব্যবহার করতে পারেন। ওয়েবের জন্য সবচেয়ে প্রচলিত মানদণ্ড W3C-র WCAG (Web Content Accessibility Guidelines); লেখার সময়ে সর্বশেষ সংস্করণ WCAG 2.2 (২০২৩)। এর চারটি মূলনীতি সংক্ষেপে POUR: perceivable (বোঝা যায় এমনভাবে দেখানো), operable (keyboard-সহ নানা উপায়ে চালানো যায়), understandable (বোধগম্য) আর robust (screen reader-এর মতো সহায়ক প্রযুক্তিতেও কাজ করে)। বাস্তব HTML-এ কীভাবে করবেন, তা HTML & CSS কোর্সের অ্যাক্সেসিবিলিটি পর্বে আছে।

Security — quality-র একটি অংশ, পরে জোড়া দেওয়ার জিনিস নয়

ISO/IEC 25010 security-কে quality characteristic হিসেবেই রেখেছে। এর কেন্দ্রে তথ্য-নিরাপত্তার পরিচিত তিনটি লক্ষ্য, CIA triad: confidentiality (অনুমতি ছাড়া কেউ দেখতে পারবে না), integrity (অনুমতি ছাড়া কেউ বদলাতে পারবে না) আর availability (যাঁর অনুমতি আছে, তিনি দরকারের সময় পাবেন)। ISO-র sub-characteristic-এ আরও আছে authenticity (যিনি দাবি করছেন তিনিই কি না), accountability (কে কী করেছেন তার হিসাব) আর non-repudiation (করা কাজ পরে অস্বীকার করা যায় না)।

প্রতিরোধমূলক দৃষ্টিতে quality হিসেবে security মানে: requirement-এর সময়েই ঝুঁকি চিহ্নিত করা, সবচেয়ে কম প্রয়োজনীয় অনুমতি (least privilege), ইনপুট যাচাই, গোপন তথ্য (password, API key) কখনো কোডে বা Git history-তে না রাখা, আর dependency হালনাগাদ রাখা। Git-এ গোপন তথ্য ফাঁস ঠেকানোর ব্যবহারিক কৌশল পর্ব ৫৭-এ আছে।

৮ · Trade-off — সব গুণ একসাথে সর্বোচ্চ হয় না

প্রতিটি quality attribute কিছু না কিছু দাম চায়। কয়েকটি পরিচিত টানাপোড়েন:

• Security বনাম usability: প্রতিবার OTP চাইলে নিরাপত্তা বাড়ে, কিন্তু ব্যবহারকারী বিরক্ত হন।
• Performance বনাম maintainability: সর্বোচ্চ গতির জন্য লেখা কৌশলী কোড প্রায়ই পড়তে ও বদলাতে কঠিন।
• Reliability বনাম খরচ ও সরলতা: প্রতিটি অংশের বাড়তি কপি (redundancy) রাখলে availability বাড়ে, কিন্তু খরচ আর জটিলতাও বাড়ে।
• Portability বনাম performance: সব platform-এ চলার মতো সাধারণ কোড কোনো একটি platform-এর বিশেষ সুবিধা কাজে লাগাতে পারে না।

তাহলে দুটি নকশার মধ্যে কোনটি বাছবেন? একটি সহজ, বহুল ব্যবহৃত কৌশল হলো weighted scoring: দল প্রতিটি attribute-কে project-এর জন্য গুরুত্ব অনুযায়ী ওজন (weight) দেয়, তারপর প্রতিটি নকশাকে ১ থেকে ৫ নম্বর দেয়। মোট নম্বর = Σ (ওজন × নম্বর)। নিচে দুটি কাল্পনিক নকশা: X — একটি সার্ভার, সরল কোড; Y — একাধিক replica, বেশি নিরাপদ ও নির্ভরযোগ্য, কিন্তু জটিল।

// Weighted quality score: which design wins depends on the priorities.
// Scores 1..5 given by the team for two fictional design options.
const attrs = ["performance", "reliability", "security", "maintainability", "usability"];
const X = { name: "X: single server", s: [3, 2, 3, 5, 4] };
const Y = { name: "Y: replicated",    s: [4, 5, 4, 2, 4] };
const profiles = {                       // weights add up to 1.0
  "exam-day result portal": [0.30, 0.35, 0.15, 0.10, 0.10],
  "small internal tool":    [0.10, 0.10, 0.15, 0.45, 0.20],
  "balanced (all equal)":   [0.20, 0.20, 0.20, 0.20, 0.20],
};
const score = (opt, w) => opt.s.reduce((t, v, i) => t + v * w[i], 0);
for (const [p, w] of Object.entries(profiles)) {
  const x = score(X, w), y = score(Y, w);
  console.log(p.padEnd(24), "X=" + x.toFixed(2), "Y=" + y.toFixed(2),
    "-> winner " + (x > y ? "X" : "Y"));
}
// How robust is the balanced decision? Shake each weight by +-50 %.
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(7), base = profiles["balanced (all equal)"];
let yWins = 0;
for (let k = 0; k < 1000; k++) {
  const w = base.map(v => v * (0.5 + rnd()));
  const sum = w.reduce((a, b) => a + b, 0), wn = w.map(v => v / sum);
  if (score(Y, wn) > score(X, wn)) yWins++;
}
console.log("balanced: Y still wins in", yWins, "of 1000 shaken weight sets");

exam-day result portal   X=2.95 Y=4.15 -> winner Y
small internal tool      X=4.00 Y=3.20 -> winner X
balanced (all equal)     X=3.40 Y=3.80 -> winner Y
balanced: Y still wins in 930 of 1000 shaken weight sets

৯ · Verification, validation আর quality-র খরচ

Quality নিশ্চিত করার কাজকে দুই প্রশ্নে ভাগ করা হয়, যা Barry Boehm-এর পরিচিত বাক্যে ধরা আছে:

শুরুর ফলাফল পোর্টালের গল্পে ৮০ নম্বরে A দেখানো verification-এর ব্যর্থতা (spec মানা হয়নি); আর spec-এ ফল প্রকাশের দিনের ভিড়ের কথাই না থাকা validation-এর ব্যর্থতা (ঠিক জিনিস চাওয়া হয়নি)। V&V কীভাবে test-এর স্তরের সাথে মেলে, তা পর্ব ৪৫-এ (Testing-এর মৌলিক) দেখবেন; process-এর ভেতরে এর স্থান দেখাবে পরের পর্বের V-model (পর্ব ০৪)।

Cost of quality — quality-র দামের হিসাব

Quality-র খরচকে চার ভাগে দেখার প্রচলিত কাঠামো হলো PAF মডেল (prevention, appraisal, failure), যার শিকড় Armand Feigenbaum-এর মতো quality-বিশেষজ্ঞদের ১৯৫০-এর দশকের কাজে। Software-এ একে এভাবে পড়া যায়:

Cost of quality-এর মূল যুক্তি: প্রথম দুই ভাগে একটু বেশি খরচ করলে শেষ দুই ভাগের খরচ অনেক কমে। “পরে ধরা পড়া defect সারাতে বহুগুণ বেশি খরচ” — এই দাবি পুরোনো বইয়ে নির্দিষ্ট গুণিতক (যেমন ১০ বা ১০০ গুণ) দিয়ে লেখা থাকে। তবে পরবর্তী কিছু গবেষণা দেখিয়েছে, আধুনিক ছোট-ধাপের (iterative) প্রক্রিয়ায় এই বৃদ্ধি সব project-এ এত নাটকীয় নয়। তাই দিকটি মনে রাখুন (আগে ধরা সাধারণত সস্তা), কিন্তু নির্দিষ্ট গুণিতক মুখস্থ সংখ্যা হিসেবে চালাবেন না। Review কোন ভাগে পড়বে, তা নিয়েও লেখকভেদে মতভেদ আছে — অনেকে নকশার review-কে prevention ধরেন, কোডের review-কে appraisal.

১০ · AI-এর যুগে software quality

AI এখন requirement-এর খসড়া, test, এমনকি পুরো module লিখে দেয়। এতে quality-র প্রশ্ন কমেনি, বরং বেড়েছে — কারণ AI এমন লেখা দেয় যা দেখতে নিখুঁত, কিন্তু যাচাই না করলে ভুল। Quality-র ক্ষেত্রে AI-এর কয়েকটি সাধারণ ভুল:

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

• প্রতিটি quality requirement-এ সংখ্যা, একক, পরিবেশ আর যাচাইয়ের উপায় আছে
• মানদণ্ডের নাম, সংস্করণ আর characteristic-এর তালিকা মূল সূত্রের সাথে মিলিয়েছি
• AI-এর লেখা test-এ কোডে একটি ছোট ভুল ঢুকিয়ে দেখেছি — test ফেল করে কি না
• MTBF, availability, DRE-র মতো হিসাব নিজে একবার হাতে বা ছোট script-এ মিলিয়েছি
• Prompt-এ কোনো আসল ব্যক্তিগত তথ্য, গোপন key বা গ্রাহকের log দিইনি
• Trade-off-এর সিদ্ধান্ত (ওজন, অগ্রাধিকার) দলের সাথে বসে নিয়েছি — AI-এর ওপর ছেড়ে দিইনি