Software estimation — story point, planning poker, function point আর COCOMO II

১ · অনুমান কেন কঠিন — cone of uncertainty

একটি কাল্পনিক বিশ্ববিদ্যালয়ের রেজিস্ট্রার অফিস জানতে চাইল: “অনলাইন ফলাফল পোর্টাল বানাতে কত দিন লাগবে, খরচ কত?” তখনো কেউ জানে না পোর্টালে transcript থাকবে কি না, পুনর্মূল্যায়নের আবেদন লাগবে কি না, কত হাজার শিক্ষার্থী একসাথে ফল দেখবেন। তবু উত্তর চাই আজই। এটাই software estimation-এর মূল সমস্যা: সবচেয়ে কম জানার সময়েই সবচেয়ে গুরুত্বপূর্ণ সংখ্যাটি চাওয়া হয়।

Barry Boehm ১৯৮১ সালের বই Software Engineering Economics-এ project-এর বিভিন্ন পর্যায়ে অনুমানের ভুলের পরিসর দেখিয়েছিলেন। পরে Steve McConnell (Software Project Survival Guide, ১৯৯৭; Software Estimation: Demystifying the Black Art, ২০০৬) এই ছবিকে “cone of uncertainty” নামে জনপ্রিয় করেন। McConnell-এর বইয়ে প্রচলিত সংখ্যাগুলো এমন:

অনিশ্চয়তার আরও কিছু উৎস আছে: requirement বদলায় (পর্ব ২৪-এর scope creep), মানুষ ভুলে যান যে test, review, deploy-ও কাজ, আর অনুমানকারী নিজেই আশাবাদী। মনোবিজ্ঞানী Daniel Kahneman ও Amos Tversky ১৯৭৯ সালের দিকে এই প্রবণতার নাম দেন planning fallacy: অতীতে বারবার দেরি হলেও মানুষ নিজের পরের কাজের সময় কম ধরে। Software-এর বাইরে, ঢাকার রাস্তায় “দশ মিনিটে আসছি” বলাও এর পরিচিত রূপ।

২ · Estimate, target আর commitment — তিনটি আলাদা কথা

McConnell Software Estimation (২০০৬) বইয়ের শুরুতেই তিনটি শব্দ আলাদা করেন। অনেক project-এর ঝগড়ার মূলে থাকে এই তিনটিকে গুলিয়ে ফেলা।

খেয়াল করুন, target আর estimate মেলেনি — ৩০ বনাম ৪০–৫২. ভুল পথ হলো estimate-কে চাপ দিয়ে ৩০ বানানো; তাতে কাজ কমে না, শুধু সংখ্যাটা মিথ্যা হয়। সঠিক পথ হলো আলোচনা: scope কমানো, লোক বা সময় বাড়ানো (সাবধানে — অংশ ৮-এ Brooks), নাকি ঝুঁকি মেনে নেওয়া। Commitment সেই আলোচনার ফল। McConnell-এর ভাষায়, estimation-এর কাজ target পূরণের পরিকল্পনা নয়; target বাস্তবসম্মত কি না, তা যাচাই করা।

৩ · বিশেষজ্ঞ, তুলনা, Wideband Delphi আর তিন-বিন্দু অনুমান

সূত্র ছাড়া অনুমানের তিনটি প্রচলিত পথ আছে, আর বাস্তবে এগুলোই সবচেয়ে বেশি ব্যবহৃত:

তিন-বিন্দু অনুমান আর PERT

একটি সংখ্যার বদলে তিনটি নিন: O (optimistic — সব ঠিকঠাক গেলে), M (most likely — সবচেয়ে সম্ভাব্য), P (pessimistic — অনেক কিছু ভুল গেলে, তবে প্রলয় নয়)। এটাই three-point estimation. PERT (১৯৫০-এর দশকের শেষে যুক্তরাষ্ট্রের নৌবাহিনীর Polaris প্রকল্পে তৈরি) এই তিনটিকে একটি beta বণ্টনের মতো ধরে সরল সূত্র দেয়:

উদাহরণ: “নম্বর জমার মডিউল” — O = ৩, M = ৫, P = ১৩ দিন। গড় = (৩ + ২০ + ১৩) ÷ ৬ = ৩৬ ÷ ৬ = ৬ দিন; standard deviation σ = (১৩ − ৩) ÷ ৬ = ১.৬৭ দিন। খেয়াল করুন, গড় ৬ সবচেয়ে সম্ভাব্য মান ৫-এর চেয়ে বেশি — কারণ দেরির দিকের লেজ লম্বা (P অনেক দূরে)। Software-এর কাজ প্রায় সবসময় এমন: আগে শেষ হওয়ার সুযোগ সীমিত, দেরির সুযোগ অনেক।

কয়েকটি স্বাধীন কাজ যোগ করলে গড় যোগ হয়, আর variance (σ²) যোগ হয় — σ নয়। তাই মোটের σ = √(σ₁² + σ₂² + …). কাজগুলো একটির পর একটি নির্ভরশীল হলে কোন পথ সবচেয়ে লম্বা (critical path), আর নির্দিষ্ট তারিখে শেষ হওয়ার সম্ভাবনা কত — সেই হিসাব পর্ব ৬১ · Project planning-এ CPM আর PERT network দিয়ে। নিচে অংশ ৪-এর শেষের প্রোগ্রামে পাঁচটি কাজের যোগফল চালিয়ে দেখবেন।

৪ · Agile অনুমান — story point, planning poker আর velocity

Agile দলগুলো সাধারণত ঘণ্টায় নয়, আপেক্ষিক আকারে অনুমান করে। Story point (পর্ব ০৫-এ পরিচয়) একটি কাজের জটিলতা, অনিশ্চয়তা আর পরিমাণ মিলিয়ে আপেক্ষিক আকার। যুক্তি: মানুষ “এটা কত ঘণ্টা” বলতে দুর্বল, কিন্তু “এটা ওটার প্রায় দ্বিগুণ” বলতে বেশ ভালো। দল একটি চেনা, শেষ হওয়া কাজকে reference story ধরে — ধরা যাক “লগইন পাতায় পাসওয়ার্ড ভুললে SMS” = ২ point — আর বাকিগুলো তার সাথে তুলনা করে।

Point-এর জন্য সাধারণত Fibonacci-র মতো একটি স্কেল ব্যবহার হয়: ১, ২, ৩, ৫, ৮, ১৩, ২০, ৪০, ১০০ (Mike Cohn-এর জনপ্রিয় করা “modified Fibonacci”; অনেকে ০ আর ½-ও রাখেন)। ফাঁকগুলো ইচ্ছা করে বড় হতে থাকে: বড় কাজে ১৩ আর ১৪-এর পার্থক্য কেউ নিশ্চিত বলতে পারেন না, তাই স্কেলেই সেই অনিশ্চয়তা বসানো। ২০ বা তার বেশি পেলে সাধারণত কাজটি ভাঙার সংকেত।

Planning poker — কেন একসাথে কার্ড উল্টানো

Planning poker-এর বর্ণনা James Grenning ২০০২ সালের একটি লেখায় দেন বলে সাধারণভাবে ধরা হয়; Mike Cohn-এর Agile Estimating and Planning (২০০৫) বই একে ব্যাপক জনপ্রিয় করে। নিয়ম সরল: প্রত্যেকের হাতে স্কেলের কার্ড; Product Owner story পড়েন, প্রশ্নোত্তর হয়; তারপর সবাই গোপনে একটি কার্ড বেছে একসাথে উল্টান। সবচেয়ে কম আর সবচেয়ে বেশি যিনি দিয়েছেন, তাঁরা কারণ বলেন; আবার ভোট — যতক্ষণ না কাছাকাছি একটি সংখ্যায় দল একমত হয়।

একসাথে উল্টানোর কারণ anchoring: প্রথম শোনা সংখ্যা পরের সবার অনুমান নিজের দিকে টানে (Tversky ও Kahneman, ১৯৭৪-এর গবেষণা থেকে পরিচিত)। দলের সবচেয়ে অভিজ্ঞ মানুষ আগে “৩” বললে নতুন সদস্য তাঁর মাথায় আসা “১৩” বলতে দ্বিধা করেন — অথচ সেই নতুন সদস্যই হয়তো জানেন যে পুরোনো database-এ বাংলা নাম ভাঙা অবস্থায় আছে। সবচেয়ে বড় লাভটা আসলে আলোচনায়: পার্থক্য লুকানো ঝুঁকি বের করে আনে।

“একজন শিক্ষার্থী হিসেবে আমি নিজের ফলের
 PDF ডাউনলোড করতে চাই, যাতে বৃত্তির
 আবেদনে জমা দিতে পারি।”
reference: পাসওয়ার্ড ভুললে SMS = 2 point
স্কেল: 1 2 3 5 8 13 20 40

রাফি  মিতু  তানভীর  সুমি  অনিক
  5     3     13       2     8
পরিসর: 2 … 13  → ঐকমত্য নেই

সুমি (2):    “শুধু একটা PDF library ডাকব।”
তানভীর (13): “বাংলা font PDF-এ ভাঙে;
             আর ফলের সাথে QR কোড লাগবে
             যাচাইয়ের জন্য — PO কি চান?”
PO: “QR লাগবে।” → নতুন তথ্য সবাই জানলেন

রাফি  মিতু  তানভীর  সুমি  অনিক
  5     5      8       3     8
পরিসর: 3 … 8  → এখনো দুই ধাপ ফাঁক

রাফি  মিতু  তানভীর  সুমি  অনিক
  5     5      8       5     8
নিয়ম: সব কার্ড পাশাপাশি দুই মানে → সবচেয়ে
      বেশিবার আসা মান = 5 point

T-shirt sizing, velocity আর release পরিকল্পনা

Backlog-এ শত শত item থাকলে প্রতিটিতে planning poker অনেক সময় নেয়। তখন T-shirt sizing: XS, S, M, L, XL — দর্জির মাপের মতো মোটা দাগে। শুরুর দিকে বা epic স্তরে এটি যথেষ্ট; পরে Sprint-এর কাছাকাছি এলে point দেওয়া হয়। কোনো কোনো দল প্রতিটি সাইজের সাথে একটি point-এর পরিসর জুড়ে দেয়, তবে সেটি দলের নিজের চুক্তি।

Point থেকে সময় আসে velocity দিয়ে: বাকি backlog ২০০ point আর velocity ১৭–২৫ হলে release planning-এ ৮ থেকে ১২ Sprint-এর পরিসর। এই হিসাব, burndown আর Monte Carlo দিয়ে “৮৫% নিশ্চয়তায় কত Sprint” — সব পর্ব ০৫ · Agile আর Scrum-এ পূর্ণভাবে করা আছে; আর point ছাড়াই আসল cycle time-এর percentile দিয়ে পূর্বাভাস পর্ব ০৬ · Kanban আর lean-এ। এখানে শুধু মনে রাখুন: story point দলের নিজের একক, দুই দলের তুলনা চলে না, আর velocity-কে লক্ষ্য বানালে point ফুলে ওঠে (Goodhart’s law).

এবার planning poker আর PERT একসাথে চালিয়ে দেখুন। প্রোগ্রামটি seed দেওয়া PRNG (mulberry32) দিয়ে পাঁচজনের প্রথম কার্ড তৈরি করে, যাতে প্রতিবার একই ফল আসে। আলোচনার পরের নিয়মটি ইচ্ছা করে সরল রাখা: প্রত্যেকে স্কেলে নিজের কার্ড আর দলের median কার্ডের মাঝামাঝি সরে যান; সব কার্ড এক ধাপের মধ্যে এলে সবচেয়ে বেশিবার আসা কার্ড। তারপর ফলাফল পোর্টালের পাঁচটি কাজের তিন-বিন্দু অনুমান যোগ করা হয়:

// Planning poker rounds (seeded) + three-point PERT for 5 tasks.
let seed = 2005;                                  // mulberry32: small seeded PRNG
function rand() {
  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 CARDS = [1, 2, 3, 5, 8, 13, 20, 40];
// round 1: each of 5 people secretly picks a card index around index 3 (= 5 points)
let idx = Array.from({ length: 5 }, () => Math.max(0, Math.min(7, 3 + Math.floor(rand() * 5) - 2)));
for (let round = 1; round <= 4; round++) {
  console.log("round " + round + ": " + idx.map(i => CARDS[i]).join(", "));
  if (Math.max(...idx) - Math.min(...idx) <= 1) {  // rule: all within one card -> agree
    const freq = {}; idx.forEach(i => freq[i] = (freq[i] || 0) + 1);
    const best = Object.keys(freq).map(Number).sort((a, b) => freq[b] - freq[a] || b - a)[0];
    console.log("  consensus -> " + CARDS[best] + " points"); break;
  }
  console.log("  lowest (" + CARDS[Math.min(...idx)] + ") and highest (" + CARDS[Math.max(...idx)] + ") explain");
  const med = [...idx].sort((a, b) => a - b)[2]; // after talking, move halfway to the median card
  idx = idx.map(i => Math.round((i + med) / 2));
}
// three-point estimates in days: [optimistic, most likely, pessimistic]
const tasks = { login: [2, 3, 6], marks: [3, 5, 13], pdf: [1, 2, 5], recheck: [2, 4, 8], tests: [2, 3, 4] };
let mean = 0, variance = 0;
for (const [name, [o, m, p]] of Object.entries(tasks)) {
  const te = (o + 4 * m + p) / 6, sd = (p - o) / 6;
  mean += te; variance += sd * sd;                 // variances add if tasks are independent
  console.log(name.padEnd(8) + " O=" + o + " M=" + m + " P=" + p + "  mean=" + te.toFixed(2) + "  sd=" + sd.toFixed(2));
}
const sdSum = Math.sqrt(variance);
console.log("total mean = " + mean.toFixed(2) + " days, sd = " + sdSum.toFixed(2));
console.log("about 84% chance within mean + 1 sd = " + (mean + sdSum).toFixed(1) + " days (normal approx.)");

round 1: 5, 3, 13, 2, 8
  lowest (2) and highest (13) explain
round 2: 5, 5, 8, 3, 8
  lowest (3) and highest (8) explain
round 3: 5, 5, 8, 5, 8
  consensus -> 5 points
login    O=2 M=3 P=6  mean=3.33  sd=0.67
marks    O=3 M=5 P=13  mean=6.00  sd=1.67
pdf      O=1 M=2 P=5  mean=2.33  sd=0.67
recheck  O=2 M=4 P=8  mean=4.33  sd=1.00
tests    O=2 M=3 P=4  mean=3.00  sd=0.33
total mean = 19.00 days, sd = 2.19
about 84% chance within mean + 1 sd = 21.2 days (normal approx.)

৫ · আকার মাপা — LOC-এর সমস্যা আর function point

Effort-এর সূত্র (COCOMO) চায় software-এর আকার। সবচেয়ে সহজ মাপ LOC (lines of code), হাজারে KLOC. কিন্তু এর তিনটি বড় সমস্যা:

• শুরুতে জানা যায় না। কোড লেখার আগে লাইন গোনা যায় না — অনুমান করতে হয়, অর্থাৎ এক অনুমান দিয়ে আরেক অনুমান।
• ভাষা আর ধরনের ওপর নির্ভরশীল। একই কাজ assembly-তে হাজার লাইন, Python-এ কয়েক ডজন। লাইন গোনার নিয়মও আলাদা (comment, ফাঁকা লাইন, এক লাইনে কয়টি statement).
• উৎপাদনশীলতার উল্টো ছবি। LOC প্রতি person-month দিয়ে মাপলে নিম্নস্তরের ভাষার দলকে বেশি “উৎপাদনশীল” দেখায় — Capers Jones এই বিভ্রান্তি নিয়ে বহু লেখা লিখেছেন। লাইন বাড়িয়ে পুরস্কার পাওয়া গেলে মানুষ লাইন বাড়াবে।

১৯৭৯ সালে IBM-এর Allan Albrecht একটি বিকল্প প্রস্তাব করেন: function point — software ব্যবহারকারীকে কী কাজ দেয়, সেটা গুনে আকার। কোন ভাষায় লেখা, তাতে কিছু আসে যায় না, আর requirement পেলেই গোনা যায়। ১৯৮৬ সালে গঠিত IFPUG এখন গোনার নিয়ম (Counting Practices Manual) রক্ষা করে।

পাঁচ ধরনের function

প্রথম কাজ application boundary আঁকা — কোনটা আমাদের system, কোনটা বাইরে। তারপর দুই দলে পাঁচ ধরনের function:

প্রতিটি function low, average না high — তা IFPUG manual-এর ছক থেকে ঠিক হয়: transaction-এর জন্য কয়টি data element (DET) আর কয়টি file ছোঁয় (FTR), data function-এর জন্য DET আর record type (RET). পরীক্ষায় সাধারণত জটিলতা বলে দেওয়া থাকে। পাঁচটির weight সংখ্যা দিয়ে গুণ করে যোগ করলে unadjusted function point (UFP).

তারপর সমন্বয়: ১৪টি general system characteristic (GSC) — data communications, distributed data processing, performance, heavily used configuration, transaction rate, online data entry, end-user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, facilitate change — প্রতিটিকে ০ (প্রভাব নেই) থেকে ৫ (অপরিহার্য)। মোট (ΣGSC, যাকে TDI-ও বলে) থেকে value adjustment factor:

ΣGSC ০ থেকে ৭০, তাই VAF 0.65 থেকে 1.35 — অর্থাৎ সমন্বয়ে আকার সর্বোচ্চ ৩৫% কমে বা বাড়ে। এবার পোর্টালের পূর্ণ গণনা ধাপে ধাপে:

ধরন   low  avg  high
EI     4    3    1    নম্বর জমা, লগইন, CSV upload …
EO     2    3    1    ফলাফলপত্র, transcript PDF …
EQ     3    2    0    শিক্ষার্থী খোঁজা, ফল দেখা …
ILF    2    2    1    শিক্ষার্থী, কোর্স, নম্বর …
EIF    1    1    0    ফি সিস্টেম, বোর্ডের তথ্য

EI : 4×3 + 3×4 + 1×6  = 12 + 12 + 6  = 30
EO : 2×4 + 3×5 + 1×7  =  8 + 15 + 7  = 30

EQ : 3×3 + 2×4 + 0×6   =  9 +  8 +  0 = 17
ILF: 2×7 + 2×10 + 1×15 = 14 + 20 + 15 = 49
EIF: 1×5 + 1×7 + 0×10  =  5 +  7 +  0 = 12

UFP = 30 + 30 + 17 + 49 + 12 = 138

data comm 4  distributed 2  performance 4
heavy config 3  transaction rate 4
online entry 5  end-user eff. 4  online update 3
complex proc. 2  reusability 1  install 2
operational 3  multiple sites 0  change 1
ΣGSC = 38   →   VAF = 0.65 + 0.38 = 1.03

AFP = UFP × VAF = 138 × 1.03 = 142.14 FP

একই হিসাব Python-এ, প্রতিটি ধাপ ছাপিয়ে — নিজের সংখ্যা বসিয়ে চালাতে পারেন:

# Function point count for a fictional university result portal (IFPUG-style).
WEIGHTS = {"EI": (3, 4, 6), "EO": (4, 5, 7), "EQ": (3, 4, 6),
           "ILF": (7, 10, 15), "EIF": (5, 7, 10)}        # low, average, high
COUNTS = {"EI": (4, 3, 1),   # login, mark entry, profile edit, recheck form, CSV upload...
          "EO": (2, 3, 1),   # grade sheet, transcript PDF, merit list...
          "EQ": (3, 2, 0),   # search student, view result...
          "ILF": (2, 2, 1),  # student, course, marks...
          "EIF": (1, 1, 0)}  # fee system, national exam board data

ufp = 0
for kind, (lo, av, hi) in COUNTS.items():
    w = WEIGHTS[kind]
    sub = lo * w[0] + av * w[1] + hi * w[2]
    ufp += sub
    print(f"{kind:3}: {lo}x{w[0]} + {av}x{w[1]} + {hi}x{w[2]} = {sub}")
print("UFP (unadjusted) =", ufp)

GSC = {"data communications": 4, "distributed processing": 2, "performance": 4,
       "heavily used config": 3, "transaction rate": 4, "online data entry": 5,
       "end-user efficiency": 4, "online update": 3, "complex processing": 2,
       "reusability": 1, "installation ease": 2, "operational ease": 3,
       "multiple sites": 0, "facilitate change": 1}            # each 0..5
tdi = sum(GSC.values())
vaf = 0.65 + 0.01 * tdi
print(f"14 GSC ratings sum (TDI) = {tdi}")
print(f"VAF = 0.65 + 0.01 x {tdi} = {vaf:.2f}")
afp = ufp * vaf
print(f"AFP = {ufp} x {vaf:.2f} = {afp:.2f}")
print(f"VAF range check: {0.65 + 0.01*0:.2f} .. {0.65 + 0.01*70:.2f}")

EI : 4x3 + 3x4 + 1x6 = 30
EO : 2x4 + 3x5 + 1x7 = 30
EQ : 3x3 + 2x4 + 0x6 = 17
ILF: 2x7 + 2x10 + 1x15 = 49
EIF: 1x5 + 1x7 + 0x10 = 12
UFP (unadjusted) = 138
14 GSC ratings sum (TDI) = 38
VAF = 0.65 + 0.01 x 38 = 1.03
AFP = 138 x 1.03 = 142.14
VAF range check: 0.65 .. 1.35

৬ · Use case point আর backfiring — আকার থেকে লাইনে

Requirement যদি use case আকারে থাকে (পর্ব ২২), তাহলে Gustav Karner-এর ১৯৯৩ সালের use case point পদ্ধতি ব্যবহার করা যায়। প্রচলিত রূপে: প্রতিটি use case-কে transaction-এর সংখ্যা অনুযায়ী simple / average / complex ধরে weight ৫ / ১০ / ১৫ (যোগফল UUCW); actor-দের simple / average / complex ধরে ১ / ২ / ৩ (UAW). তারপর:

TFactor আসে ১৩টি প্রযুক্তিগত গুণকের weight দেওয়া রেটিং থেকে, EFactor আসে ৮টি পরিবেশগত গুণক (দলের অভিজ্ঞতা, requirement-এর স্থিরতা ইত্যাদি) থেকে। ছোট উদাহরণ: ৮টি average use case (UUCW = ৮ × ১০ = ৮০) আর তিনজন average actor (UAW = ৩ × ২ = ৬); তাহলে ৮০ + ৬ = ৮৬. TCF = ১.০ আর ECF = ০.৯৫ হলে UCP = ৮৬ × ১.০ × ০.৯৫ = ৮১.৭. Karner প্রতি UCP-তে প্রায় ২০ person-hour প্রস্তাব করেছিলেন; সেই হারে ৮১.৭ × ২০ = ১,৬৩৪ ঘণ্টা। পরে অনেকে নিজেদের তথ্যে এই হার আলাদা পেয়েছেন — তাই হারটি নিজের দলের অতীত থেকে ঠিক করাই নিরাপদ।

Backfiring — function point থেকে KLOC

COCOMO 81 আকার চায় KLOC-এ। Function point থেকে KLOC-এ যাওয়ার মোটা দাগের পথ backfiring: ভাষাভিত্তিক একটি গড় অনুপাত — “এই ভাষায় এক function point-এ গড়ে কত লাইন” — দিয়ে গুণ। Capers Jones, QSM-সহ বিভিন্ন উৎস এমন ছক প্রকাশ করেছে; মোটা দাগে C-এর মতো ভাষায় অনুপাত একশোর ওপরে, Java-র মতো ভাষায় তার প্রায় অর্ধেক বা কম — কিন্তু উৎস আর দলভেদে সংখ্যাগুলো অনেক আলাদা। তাই সবসময় ধরে নেওয়া অনুপাতটি স্পষ্ট লিখুন।

ধরা যাক ফলাফল পোর্টালের ভাষার জন্য ৫০ LOC/FP (একটি অনুমান, কোনো মানদণ্ড নয়)। তাহলে ১৪২.১৪ × ৫০ = ৭,১০৭ লাইন ≈ ৭.১ KLOC. COCOMO II সরাসরি function point নিয়েও কাজ করতে পারে — ভেতরে এই রূপান্তরই করে।

৭ · COCOMO 81 — Basic আর Intermediate

Barry Boehm ১৯৮১ সালে Software Engineering Economics বইয়ে COCOMO (COnstructive COst MOdel) প্রকাশ করেন। প্রায় ৬৩টি project-এর তথ্য থেকে (মূলত TRW-তে, যেখানে Boehm কাজ করতেন) তিনি আকার আর effort-এর সম্পর্কের সূত্র বের করেন। Effort-এর একক person-month (PM) — একজন মানুষের এক মাসের কাজ।

তিনটি mode

খেয়াল করুন, b সবসময় ১-এর বেশি। এর মানে diseconomy of scale: আকার দ্বিগুণ হলে effort দ্বিগুণের বেশি, কারণ বড় project-এ যোগাযোগ, integration আর সমন্বয়ের কাজ আকারের চেয়ে দ্রুত বাড়ে। আর সময়ের সূত্রে d ছোট (০.৩২–০.৩৮) — effort আট গুণ হলেও সময় মাত্র দুই গুণের মতো বাড়ে; বাকিটা আসে বেশি মানুষ থেকে।

আকার: 32 KLOC   mode: organic
a = 2.4   b = 1.05   c = 2.5   d = 0.38

32^1.05 = e^(1.05 × ln 32)
        = e^(1.05 × 3.4657) = e^3.6390
        = 38.05

E = 2.4 × 38.05 = 91.3 person-month

E^0.38 = 91.3^0.38 = 5.56
D = 2.5 × 5.56 = 13.9 মাস

দল  = 91.3 ÷ 13.9 = 6.6 জন (গড়ে)
LOC/PM = 32000 ÷ 91.3 = 350

13.9 মাস → 7 মাস = 50% সময়
Boehm: nominal-এর প্রায় 75%-এর নিচে সংকোচন
       কার্যত অসম্ভব → 0.75 × 13.9 ≈ 10.4 মাস
       পর্যন্ত চেষ্টা করা যায়, বেশি খরচে

তিনটি mode একসাথে, আর আকার দ্বিগুণ করলে কী হয় — প্রোগ্রামে দেখুন:

// Basic COCOMO (Boehm, 1981): effort, duration and average team size for 3 modes.
const MODES = {
  organic:       { a: 2.4, b: 1.05, c: 2.5, d: 0.38 },
  semidetached:  { a: 3.0, b: 1.12, c: 2.5, d: 0.35 },
  embedded:      { a: 3.6, b: 1.20, c: 2.5, d: 0.32 },
};
const KLOC = 32;                                   // estimated size: 32 thousand lines
console.log("size = " + KLOC + " KLOC");
console.log("mode           effort(PM)  time(months)  team  LOC/PM");
for (const [name, m] of Object.entries(MODES)) {
  const effort = m.a * Math.pow(KLOC, m.b);        // person-months
  const time = m.c * Math.pow(effort, m.d);        // calendar months
  const team = effort / time;                      // average people
  const prod = (KLOC * 1000) / effort;             // lines per person-month
  console.log(name.padEnd(14) + effort.toFixed(1).padStart(11) + time.toFixed(1).padStart(14) +
    team.toFixed(1).padStart(6) + prod.toFixed(0).padStart(8));
}
// Diseconomy of scale: what happens when size doubles?
for (const k of [16, 32, 64]) {
  const e = 2.4 * Math.pow(k, 1.05);
  console.log("organic " + String(k).padStart(2) + " KLOC -> " + e.toFixed(1) + " PM");
}

size = 32 KLOC
mode           effort(PM)  time(months)  team  LOC/PM
organic              91.3          13.9   6.6     350
semidetached        145.5          14.3  10.2     220
embedded            230.4          14.3  16.2     139
organic 16 KLOC -> 44.1 PM
organic 32 KLOC -> 91.3 PM
organic 64 KLOC -> 189.1 PM

Intermediate COCOMO — ১৫টি cost driver

Basic COCOMO শুধু আকার দেখে। Intermediate COCOMO ১৫টি cost driver যোগ করে, চার দলে: product (RELY — প্রয়োজনীয় নির্ভরযোগ্যতা, DATA, CPLX), computer (TIME, STOR, VIRT, TURN), personnel (ACAP — analyst-এর দক্ষতা, AEXP, PCAP — programmer-এর দক্ষতা, VEXP, LEXP) আর project (MODP, TOOL, SCED). প্রতিটির রেটিং (very low থেকে extra high) একটি গুণক দেয়; সবগুলোর গুণফল EAF. সূত্র E = a × KLOC^b × EAF, যেখানে a বদলে যায়: organic ৩.২, semi-detached ৩.০, embedded ২.৮; b আগের মতো।

উদাহরণ: ৩২ KLOC organic, RELY high (১.১৫), CPLX high (১.১৫), ACAP high (০.৮৬), TOOL low (১.১০), বাকি nominal (১.০০)। EAF = ১.১৫ × ১.১৫ × ০.৮৬ × ১.১০ = ১.২৫১; nominal effort ৩.২ × ৩৮.০৫ = ১২১.৮ PM; E = ১২১.৮ × ১.২৫১ = ১৫২.৪ PM; D = ২.৫ × ১৫২.৪^০.৩৮ = ১৬.৯ মাস। দক্ষ analyst effort কমালেও উচ্চ নির্ভরযোগ্যতা, জটিলতা আর দুর্বল tool মিলে মোট ২৫% বাড়িয়ে দিল। (গুণকের মানগুলো Boehm-এর ১৯৮১ সালের ছক থেকে; পরীক্ষায় সাধারণত দেওয়া থাকে।)

৮ · COCOMO II — scale factor, effort multiplier আর schedule

১৯৮১ সালের মডেল তৈরি হয়েছিল mainframe আর waterfall-এর যুগে। Reuse, GUI builder, iterative উন্নয়ন এলে Boehm ও সহকর্মীরা ১৯৯০-এর দশকে নতুন মডেল তৈরি করেন; পূর্ণ বিবরণ ২০০০ সালের বই Software Cost Estimation with COCOMO II-এ। সবচেয়ে প্রচলিত ক্রমাঙ্কন (calibration) “COCOMO II.2000”. নিচের ধ্রুবকগুলো সেই model definition manual অনুযায়ী; গুরুত্বপূর্ণ কাজে মূল manual মিলিয়ে নিন। COCOMO II-এর তিনটি উপ-মডেল আছে (application composition, early design, post-architecture); এখানে post-architecture:

Size KSLOC-এ (হাজার source line; reuse আর বদলের জন্য সমন্বয় করা) বা function point থেকে রূপান্তর করে। Manual অনুযায়ী TDEV-এর সূত্রে PM হলো SCED গুণক বাদ দিয়ে হিসাব করা effort (PM_NS); নিচের উদাহরণে SCED nominal (১.০০), তাই পার্থক্য নেই। মূল পরিবর্তন হলো exponent: COCOMO 81-এ এটি তিনটি স্থির মান, এখানে পাঁচটি scale factor থেকে হিসাব হয়:

সব nominal হলে ΣSF = ১৮.৯৭, E = ০.৯১ + ০.১৮৯৭ = ১.০৯৯৭ — তখনো ১-এর বেশি। সব extra high হলে E = ০.৯১ — বিরল ক্ষেত্রে economy of scale-ও সম্ভব। Scale factor exponent-এ বসে, তাই বড় project-এ এদের প্রভাব অনেক বেশি।

Exponent-এর বাইরে গুণক হিসেবে বসে ১৭টি effort multiplier (nominal = ১.০০): product (RELY, DATA, CPLX, RUSE, DOCU), platform (TIME, STOR, PVOL), personnel (ACAP, PCAP, PCON, APEX, PLEX, LTEX) আর project (TOOL, SITE, SCED). প্রোগ্রামে ব্যবহৃত মানগুলো: RELY high ১.১০, CPLX high ১.১৭, ACAP high ০.৮৫, TOOL high ০.৯০.

# COCOMO II.2000 post-architecture: effort and schedule (constants as published).
A, B, C, D = 2.94, 0.91, 3.67, 0.28
PMAT = {"VL": 7.80, "L": 6.24, "N": 4.68, "H": 3.12, "VH": 1.56, "XH": 0.00}

def cocomo2(ksloc, sf, em):
    E = B + 0.01 * sum(sf.values())           # size exponent
    pi_em = 1.0
    for v in em.values():
        pi_em *= v
    pm = A * ksloc ** E * pi_em                # person-months
    F = D + 0.2 * (E - B)                      # schedule exponent
    tdev = C * pm ** F                         # calendar months
    return E, pi_em, pm, F, tdev

size = 20                                      # KSLOC (fictional result portal v2)
sf = {"PREC": 3.72, "FLEX": 2.03, "RESL": 5.65, "TEAM": 3.29, "PMAT": 4.68}
em = {"RELY": 1.10, "CPLX": 1.17, "ACAP": 0.85, "TOOL": 0.90}  # other 13 = 1.00

E, pi_em, pm, F, tdev = cocomo2(size, sf, em)
print(f"sum SF = {sum(sf.values()):.2f}  ->  E = {E:.4f}")
print(f"product of EMs = {pi_em:.4f}")
print(f"PM   = 2.94 x {size}^{E:.4f} x {pi_em:.4f} = {pm:.1f}")
print(f"F    = 0.28 + 0.2 x ({E:.4f} - 0.91) = {F:.4f}")
print(f"TDEV = 3.67 x {pm:.1f}^{F:.4f} = {tdev:.1f} months, team ~ {pm / tdev:.1f}")

print("sensitivity: change only PMAT (process maturity)")
for rating, value in PMAT.items():
    E2, _, pm2, _, t2 = cocomo2(size, {**sf, "PMAT": value}, em)
    print(f"  PMAT {rating:2} ({value:.2f}): E={E2:.4f}  PM={pm2:6.1f}  TDEV={t2:4.1f}")

sum SF = 19.37  ->  E = 1.1037
product of EMs = 0.9846
PM   = 2.94 x 20^1.1037 x 0.9846 = 79.0
F    = 0.28 + 0.2 x (1.1037 - 0.91) = 0.3187
TDEV = 3.67 x 79.0^0.3187 = 14.8 months, team ~ 5.3
sensitivity: change only PMAT (process maturity)
  PMAT VL (7.80): E=1.1349  PM=  86.7  TDEV=15.7
  PMAT L  (6.24): E=1.1193  PM=  82.8  TDEV=15.2
  PMAT N  (4.68): E=1.1037  PM=  79.0  TDEV=14.8
  PMAT H  (3.12): E=1.0881  PM=  75.4  TDEV=14.4
  PMAT VH (1.56): E=1.0725  PM=  71.9  TDEV=14.0
  PMAT XH (0.00): E=1.0569  PM=  68.7  TDEV=13.6

Brooks-এর সূত্র — মানুষ আর মাস বদলযোগ্য নয়

COCOMO-র সময়ের সূত্র (D = c × E^d) আসলে Fred Brooks-এর পর্যবেক্ষণের গাণিতিক রূপ। The Mythical Man-Month (১৯৭৫) বইয়ে Brooks দেখান, দেরি হওয়া project-এ লোক বাড়ালে নতুনদের শেখাতে পুরোনোদের সময় যায়, আর যোগাযোগের পথ বাড়ে n(n − ১) ÷ ২ হারে — ৫ জনে ১০টি পথ, ১০ জনে ৪৫টি। এ কারণেই Brooks’s law: “Adding manpower to a late software project makes it later.” ইতিহাস আর প্রসঙ্গ পর্ব ০২-এ আছে। ঈদের আগে বাস টার্মিনালে টিকিট কাউন্টারে আরও দশজন নতুন কর্মী বসালেই লাইন কমে না, যদি তাঁরা টিকিটের system চেনেন না আর পুরোনোদের বারবার জিজ্ঞেস করেন।

৯ · AI-এর যুগে software estimation

AI মুহূর্তে COCOMO-র হিসাব করে দেয়, backlog-এ point বসিয়ে দেয়, এমনকি “এই project ১২০ দিনে শেষ হবে” বলে দেয়। কিন্তু অনুমানের সবচেয়ে মূল্যবান অংশ — আপনার দলের অতীত, আপনার codebase-এর লুকানো ঝুঁকি, গ্রাহকের অস্পষ্ট চাওয়া — AI দেখেনি। তাই AI-কে হিসাবের সহকারী হিসেবে ব্যবহার করুন, অনুমানকারী হিসেবে নয়।

Software engineering-এ AI ব্যবহারের চেকলিস্ট

• AI-এর দেওয়া সূত্র আর ধ্রুবক মূল উৎসে (Boehm-এর বই, COCOMO II manual, IFPUG manual) মিলিয়েছি
• অনুমানকে একটি পরিসর আর ধরে নেওয়া শর্তসহ জানিয়েছি; AI-এর একটিমাত্র সংখ্যাকে commitment বানাইনি
• AI-এর লেখা হিসাবের কোড বা test নিজে চালিয়ে দেখেছি, আর ইচ্ছা করে ভুল মান দিয়ে test সত্যিই ব্যর্থ হয় কি না যাচাই করেছি
• AI যে Git command দিয়েছে (বিশেষ করে reset --hard বা push --force), তা আগে একটি আলাদা clone-এ চালিয়েছি আর git help পড়েছি
• AI-এর দেওয়া কোডের উৎস আর license যাচাই করেছি, আর prompt-এ কোনো password, key, বাজেট বা গ্রাহকের গোপন তথ্য দিইনি