Numerical সমস্যার অনুশীলন — COCOMO, function point, CPM-PERT আর complexity, পূর্ণ সমাধানসহ

average weights: EI 4, EO 5, EQ 4, ILF 10, EIF 7
UFP = 5x4 + 4x5 + 3x4 + 2x10 + 1x7 = 20 + 20 + 12 + 20 + 7 = 79
VAF = 0.65 + 0.01 x 42 = 1.07
AFP = 79 x 1.07 = 84.53

Sanity check: VAF ০.৬৫ আর ১.৩৫-এর মধ্যে, আর ΣGSC ৩৫-এর বেশি বলে VAF ১-এর একটু বেশি — আকার ৭% বাড়ল। সবচেয়ে সাধারণ ভুল EQ-কে EO-র weight (৫) দেওয়া; EQ কোনো হিসাব ছাড়া হুবহু ফেরত দেয়, তাই তার weight কম। UFP = ৭৯, VAF = ১.০৭, AFP ≈ ৮৪.৫৩.

EI : 3x3 + 2x4 + 2x6  = 9 + 8 + 12  = 29
EO : 1x4 + 2x5 + 1x7  = 4 + 10 + 7  = 21
EQ : 2x3 + 1x4 + 0x6  = 6 + 4       = 10
ILF: 0x7 + 3x10 + 1x15 = 30 + 15    = 45
EIF: 2x5 + 0x7 + 0x10 = 10          = 10
UFP = 29 + 21 + 10 + 45 + 10 = 115
sum GSC = 10x3 + 4x5 = 50  ->  VAF = 0.65 + 0.50 = 1.15
AFP = 115 x 1.15 = 132.25   ->   size ~ 132.25 x 50 / 1000 = 6.61 KLOC

খেয়াল করুন, ILF একাই ৪৫ — মোটের প্রায় ৩৯%. Data function-এর weight বেশি, কারণ ফাইল রক্ষণাবেক্ষণে কাজ বেশি। Sanity check: ΣGSC ৫০ ≤ ৭০ আর VAF ১.১৫ ≤ ১.৩৫. Backfiring-এর ফল (৬.৬১ KLOC) খুব মোটা দাগের — ভাষা আর দলভেদে LOC/FP অনেক বদলায়। UFP = ১১৫, AFP ≈ ১৩২.২৫, আকার প্রায় ৬.৬ KLOC.

organic: a = 2.4, b = 1.05, c = 2.5, d = 0.38
10^1.05 = 11.22
E = 2.4 x 11.22 = 26.9 person-months
D = 2.5 x 26.9^0.38 = 2.5 x 3.50 = 8.7 months
team = 26.9 / 8.7 = 3.1 people     (productivity 10000 / 26.9 = 371 LOC/PM)

Sanity check: E ≈ ২৭ PM মানে একজন মানুষের সোয়া দুই বছর; তিনজনে প্রায় নয় মাস — বাস্তবসম্মত। ক্যালকুলেটরে x^y না থাকলে log দিয়ে: ১০^১.০৫ = e^{১.০৫ × ln ১০}. E ≈ ২৬.৯ PM, D ≈ ৮.৭ মাস, দল প্রায় ৩ জন।

mode           E (PM)   D (months)   team   LOC/PM
organic         145.9      16.6        8.8     343
semi-detached   239.9      17.0       14.1     208
embedded        393.6      16.9       23.3     127

Effort প্রায় ২.৭ গুণ বাড়ে (১৪৫.৯ থেকে ৩৯৩.৬), কিন্তু সময় প্রায় একই (১৬.৬–১৭.০ মাস) — বাড়তি কাজ আসে বড় দল থেকে। কারণ সময়ের exponent d ছোট আর mode-ভেদে কমে (০.৩৮ → ০.৩২); তাই embedded-এর সময় (১৬.৯) semi-detached-এর (১৭.০) চেয়ে সামান্য কমও আসে। উৎপাদনশীলতা ৩৪৩ থেকে ১২৭ লাইনে নামে — কঠোর শর্তে প্রতিটি লাইনের পেছনে বেশি যাচাই। Effort আর দল সবচেয়ে বেশি বদলায়; সময় প্রায় স্থির।

EAF = 1.40 x 1.08 x 0.86 x 1.10 = 1.4304
Intermediate semi-detached: a = 3.0, b = 1.12, d = 0.35
40^1.12 = 62.27 ;  nominal E = 3.0 x 62.27 = 186.8 PM
E = 186.8 x 1.4304 = 267.2 PM
D = 2.5 x 267.2^0.35 = 2.5 x 7.07 = 17.7 months ;  team = 15.1

Semi-detached-এ Intermediate-এর a (৩.০) Basic-এর মতোই; organic (৩.২) আর embedded (২.৮)-এ আলাদা — এটি পরীক্ষার প্রিয় ফাঁদ। দক্ষ analyst (০.৮৬) effort কমালেও খুব উঁচু নির্ভরযোগ্যতা আর দুর্বল tool মিলে মোট ৪৩% বাড়িয়েছে। Sanity check: EAF ১-এর বেশি, তাই E nominal-এর চেয়ে বেশি হওয়ারই কথা। EAF ≈ ১.৪৩০, E ≈ ২৬৭.২ PM, D ≈ ১৭.৭ মাস।

sum SF = 2.48 + 3.04 + 2.83 + 1.10 + 4.68 = 14.13
E   = 0.91 + 0.01 x 14.13 = 1.0513
Pi EM = 1.10 x 1.17 x 0.88 x 0.90 = 1.0193
50^1.0513 = 61.11
PM  = 2.94 x 61.11 x 1.0193 = 183.1 person-months
F   = 0.28 + 0.2 x (1.0513 - 0.91) = 0.3083
TDEV = 3.67 x 183.1^0.3083 = 3.67 x 4.98 = 18.3 months ;  team = 10.0
doubling the size: PM x 2^1.0513 = x 2.072

সব scale factor nominal হলে ΣSF হতো ১৮.৯৭ আর E ≈ ১.১০; এখানে অভিজ্ঞতা, দলের সমন্বয় আর আগেভাগে ঝুঁকি মীমাংসা exponent কমিয়ে ১.০৫-এ এনেছে। দ্বিগুণ আকারে PM ২.০৭২ গুণ — দ্বিগুণের সামান্য বেশি, অর্থাৎ diseconomy of scale এখনো আছে, তবে কম। সাধারণ ভুল: scale factor-কে EM-এর মতো গুণ করা — SF বসে exponent-এ, EM বসে গুণফলে। E = ১.০৫১৩, PM ≈ ১৮৩.১, TDEV ≈ ১৮.৩ মাস, দল প্রায় ১০ জন।

E = 2.4 x KLOC^1.05   ->   KLOC = (E / 2.4)^(1 / 1.05)
KLOC = (60 / 2.4)^(0.9524) = 25^0.9524 = 21.45
check: 2.4 x 21.45^1.05 = 60.0 PM
D = 2.5 x 60^0.38 = 11.8 months

উল্টো প্রশ্নে ঘাতকে উল্টাতে হয়: ১ ÷ ১.০৫ ≈ ০.৯৫২৪. Sanity check: ৬০ ÷ ২.৪ = ২৫, আর exponent ১-এর একটু কম বলে উত্তর ২৫-এর একটু কম — মেলে। উত্তর বসিয়ে আবার effort বের করা (৬০.০) সবচেয়ে ভালো উল্টো চেক। প্রায় ২১.৪৫ KLOC, সময় প্রায় ১১.৮ মাস।

task      te = (O + 4M + P)/6        sigma = (P - O)/6   variance
login     (2 + 16 + 8)/6  = 4.33      1.00               1.00
search    (3 + 20 + 9)/6  = 5.33      1.00               1.00
payment   (4 + 28 + 16)/6 = 8.00      2.00               4.00
report    (1 + 8 + 3)/6   = 2.00      0.33               0.11
total mean = 19.67 days ; total variance = 6.11 ; total sigma = sqrt(6.11) = 2.47

ফাঁদ: σ-গুলো সরাসরি যোগ করলে ৪.৩৩ আসে — ভুল। স্বাধীন কাজে variance যোগ হয়, তারপর বর্গমূল। payment-এর গড় (৮) M (৭)-এর চেয়ে বেশি, কারণ দেরির দিকের লেজ লম্বা। Normal ধরে মোটামুটি ৮৪% সম্ভাবনায় ১৯.৬৭ + ২.৪৭ ≈ ২২.১ দিনের মধ্যে — সেই হিসাবের পূর্ণ রূপ ভাগ ৩-এ। মোট ≈ ১৯.৬৭ দিন, σ ≈ ২.৪৭ দিন।

average velocity = (21 + 18 + 24 + 19 + 23) / 5 = 105 / 5 = 21
best  = ceil(160 / 24) = ceil(6.67)  = 7 sprints
mid   = ceil(175 / 21) = ceil(8.33)  = 9 sprints
worst = ceil(190 / 18) = ceil(10.56) = 11 sprints
range: 7 to 11 sprints = 14 to 22 weeks

Sprint অর্ধেক হয় না, তাই প্রতিটিতে ওপরের দিকে গোল (⌈ ⌉)। সেরা ক্ষেত্রে সবচেয়ে কম কাজ ভাগ সর্বোচ্চ velocity, খারাপ ক্ষেত্রে সবচেয়ে বেশি কাজ ভাগ সর্বনিম্ন velocity — পর্ব ০৫-এর নিয়মেই। একটি সংখ্যা (৯) না বলে পরিসর বলাই সৎ forecast. ৭ থেকে ১১ Sprint, অর্থাৎ ১৪ থেকে ২২ সপ্তাহ; মাঝামাঝি অনুমান ৯ Sprint.

act dur  ES  EF  LS  LF  TF  FF
 A   3    0   3   0   3   0   0
 B   5    3   8   3   8   0   0
 C   4    3   7   7  11   4   0
 D   6    8  14   8  14   0   0
 E   3    8  11  11  14   3   3
 F   5    7  12  13  18   6   6
 G   4   14  18  14  18   0   0
 H   2   18  20  18  20   0   0
paths: A-B-D-G-H = 20, A-B-E-G-H = 17, A-C-E-G-H = 16, A-C-F-H = 14

E-র ES = max(B-র EF ৮, C-র EF ৭) = ৮ — “সামনে বড়টি”। C-র LF = min(E-র LS ১১, F-এর LS ১৩) = ১১ — “পেছনে ছোটটি”। C-র TF ৪ হলেও FF ০, কারণ C-র EF ৭ আর তার উত্তরসূরি F-এর ES-ও ৭: C এক দিন দেরি করলে F-কেও পিছাতে হয় — float-টি C, E আর F ভাগ করে নেয়। Sanity check: critical path-এর দৈর্ঘ্য (২০) = সবচেয়ে বড় EF (২০), আর সব পথের মধ্যে এটিই দীর্ঘতম। Critical path A-B-D-G-H, ২০ দিন।

critical path A-B-D-G-H:
  te  : 3 + 5 + 6 + 4 + 2 = 20 days
  var : 0.111 + 0.444 + 1.000 + 1.778 + 0.111 = 3.444 ;  sigma = 1.856
P(T <= 22): Z = (22 - 20) / 1.856 = 1.078 ~ 1.08  ->  Phi = 0.8599 (exact 0.8594)
P(T <= 18): Z = -1.078  ->  1 - 0.8594 = 0.1406
95% date  : 20 + 1.645 x 1.856 = 23.05 days
near-critical A-B-E-G-H: mu = 17, var = 2.889 -> P(<= 22) = 0.998

G-র অনুমান (২, ৩, ১০) ডান দিকে লম্বা — মোট variance-এর অর্ধেকের বেশি (১.৭৭৮ ÷ ৩.৪৪৪) শুধু এখান থেকে। টেবিল থেকে Z = ১.০৮ পড়লে ০.৮৫৯৯, দশমিক না কেটে ০.৮৫৯৪ — দুটোই পূর্ণ নম্বর পাওয়ার মতো, কোনটি নিলেন তা লিখুন। Sanity check: P(≤ ১৮) + P(≤ ২২) = ১, কারণ দুটি T গড় থেকে সমান দূরে, দুই দিকে। Near-critical পথটি ২২ দিনে প্রায় নিশ্চিত শেষ, তাই এখানে merge bias সামান্য। প্রায় ৮৬% আর ১৪%; ৯৫%-এর তারিখ প্রায় ২৩.০৫ দিন।

C: TF = 4, FF = 0
C late 3 days: C = 7 days, EF = 10 -> E starts 10, F starts 10; T stays 20
C late 5 days: C = 9 days, EF = 12 -> path A-C-E-G-H = 3 + 9 + 3 + 4 + 2 = 21
               new critical path A-C-E-G-H, T = 21 (1 day late)

Total float ৪ মানে চার দিন পর্যন্ত দেরি project-কে ছোঁয় না — কিন্তু free float ০ বলে প্রথম দিন থেকেই E আর F-এর শুরু পিছায়, তাদের নিজের float খেয়ে। পাঁচ দিনে float শেষ হয়ে এক দিন বেশি, আর critical path বদলে যায়। ৩ দিনে কোনো প্রভাব নেই (২০ দিন); ৫ দিনে project ২১ দিন, নতুন critical path A-C-E-G-H.

sigma = sqrt(16) = 4
(a) Z = (45 - 40) / 4 = 1.25        P = Phi(1.25) = 0.8944
(b) Z = -1 .. +1                    P = Phi(1) - Phi(-1) = 0.8413 - 0.1587 = 0.6827
(c) Z = (48 - 40) / 4 = 2           P = 1 - Phi(2) = 1 - 0.9772 = 0.0228
(d) Z = 2.326                       T = 40 + 2.326 x 4 = 49.30 days

ফাঁদ: variance ১৬-কে σ ধরে Z = ৫ ÷ ১৬ লেখা। আগে বর্গমূল নিন। “বেশি লাগার” প্রশ্নে ১ − Φ, আর “মাঝে” প্রশ্নে দুই Φ-এর বিয়োগ। Sanity check: (খ)-তে ±১σ, তাই প্রায় ৬৮% — normal বণ্টনের চেনা মান। (ক) ≈ ০.৮৯৪৪, (খ) ≈ ০.৬৮২৭, (গ) ≈ ০.০২২৮, (ঘ) ≈ ৪৯.৩ দিন।

(a) slope = (61 - 40) / (8 - 5) = 21 / 3 = 7 thousand taka per day
(b) paths: P-Q-S-U = 4+6+3+2 = 15 ;  P-R-T-U = 4+5+3+2 = 14
 T   critical      cheapest cut          direct  indirect  total
 15  PQSU          -                      200     180      380
 14  PQSU          Q (5)                  205     168      373
 13  PQSU, PRTU    Q+R (5+3 = 8)          213     156      369
 12  PQSU, PRTU    P (9)                  222     144      366   <- minimum
 11  PQSU, PRTU    S+T (10+6 = 16 > 12)   238     132      370

প্রথম ধাপে শুধু P-Q-S-U critical; সেখানে সবচেয়ে সস্তা Q (৫)। R-এর slope (৩) কম হলেও তখন R critical নয় — কমালে টাকা নষ্ট। ১৪ দিনে দুটি পথই critical, তাই দুটিকেই কাটতে হয়: সাধারণ activity P (৯) বনাম প্রতিটি পথ থেকে একটি করে Q+R (৮) — Q+R সস্তা। Q তখন crash সীমায় (৪), R-ও (৪)। এরপর P (৯) — দুই পথেই আছে। শেষ বিকল্প S+T (১৬) দৈনিক পরোক্ষ খরচ ১২-র বেশি, তাই মোট খরচ বাড়ে। (ক) দিনে ৭ হাজার টাকা; (খ) ১২ দিনে, মোট খরচ ৩৬৬ হাজার টাকা।

SV  = EV - PV = 200 - 240 = -40      SPI = 200 / 240 = 0.833
CV  = EV - AC = 200 - 230 = -30      CPI = 200 / 230 = 0.870
EAC = BAC / CPI = 500 / 0.870 = 575.0
ETC = EAC - AC = 575 - 230 = 345.0 ;  VAC = BAC - EAC = -75.0
other EAC forms: AC + (BAC - EV) = 530.0 ;  AC + (BAC - EV)/(CPI x SPI) = 644.0
TCPI = (BAC - EV) / (BAC - AC) = 300 / 270 = 1.111

SPI আর CPI দুটিই ১-এর কম: পরিকল্পনার চেয়ে পিছিয়ে, আর যতটুকু কাজ হয়েছে তাতেও বেশি খরচ — প্রতি ১ টাকায় ০.৮৭ টাকার কাজ। এখনকার হারে চললে শেষে ৫৭৫, অর্থাৎ ৭৫ হাজার বেশি। কোন EAC নেবেন তা নির্ভর করে বাড়তি খরচ কেন হলো তার ওপর: একবারের ঘটনা হলে ৫৩০, দেরি আর খরচ দুটিই চলতে থাকলে ৬৪৪. TCPI (কিছু বইয়ে থাকে) বলে বাজেটে শেষ করতে বাকি কাজে ১.১১১ দক্ষতা লাগবে — এখনকার ০.৮৭ থেকে যা অবাস্তব লাফ। SV −৪০, CV −৩০, SPI ০.৮৩৩, CPI ০.৮৭০, EAC ৫৭৫, ETC ৩৪৫, VAC −৭৫ — পিছিয়ে এবং বাজেট ছাড়িয়ে।

PV = 40 + 60 + 80 + 0.5 x 20 = 190
50/50 rule: started = 50%, finished = 100%
   EV = 40 + 60 + 0.5 x 80 + 0 = 140   SPI = 140/190 = 0.737   CPI = 140/150 = 0.933
0/100 rule: only finished work counts
   EV = 40 + 60 + 0 + 0 = 100          SPI = 100/190 = 0.526   CPI = 100/150 = 0.667

দুই নিয়মের কোনোটিই “৬০% শেষ” দাবি গোনে না — software-এ “৯০% শেষ” সমস্যা এড়াতেই এগুলোর জন্ম (পর্ব ৬১)। 0/100 সবচেয়ে রক্ষণশীল; তাই একই অবস্থায় SPI অনেক খারাপ দেখায়। Sanity check: EV কখনো BAC (২০০)-এর বেশি হতে পারে না। 50/50: EV ১৪০, SPI ০.৭৩৭, CPI ০.৯৩৩; 0/100: EV ১০০, SPI ০.৫২৬, CPI ০.৬৬৭.

R1: 0.3  x 20 = 6.0
R2: 0.6  x 5  = 3.0
R3: 0.1  x 50 = 5.0
R4: 0.25 x 16 = 4.0
order by RE: R1 (6) > R3 (5) > R4 (4) > R2 (3) ;  total RE = 18.0 lakh

সম্ভাবনায় সবচেয়ে বড় (R2, ০.৬) তালিকার শেষে, আর ক্ষতিতে সবচেয়ে বড় (R3, ৫০) দ্বিতীয় — RE দুটিকে একসাথে দেখে বলেই এটি দরকারি। তবে R3-এর মতো “কম সম্ভাবনা, বিশাল ক্ষতি” ঝুঁকি শুধু RE দেখে নিচে নামানো বিপজ্জনক হতে পারে; পর্ব ৬২-এ দেখেছেন, ছোট প্রতিষ্ঠানের জন্য একটি খারাপ ফলই যথেষ্ট। ক্রম R1, R3, R4, R2; মোট RE ১৮ লাখ।

M1: RE after = 0.1 x 20 = 2.0    RRL = (6 - 2.0) / 1.5 = 2.67
M2: RE after = 0.05 x 12 = 0.6   RRL = (6 - 0.6) / 3   = 1.80
cost + residual RE:  M1 = 1.5 + 2.0 = 3.5 ;  M2 = 3 + 0.6 = 3.6 ;  do nothing = 6

দুটিরই RRL ১-এর বেশি, অর্থাৎ দুটিই খরচের চেয়ে বেশি প্রত্যাশিত ক্ষতি কমায়। প্রতি টাকায় M1 বেশি কাজ করে (২.৬৭ বনাম ১.৮০), আর “খরচ + বাকি ঝুঁকি”-র মোটেও M1 সামান্য কম। M2-এর residual ঝুঁকি কম — ঝুঁকি একেবারেই সইতে না পারলে সেটিও যুক্তিসঙ্গত। M1 (RRL ≈ ২.৬৭) ভালো বিনিয়োগ।

build: 0.7 x 100 + 0.3 x 40 = 70 + 12 = 82 ;  82 - 30 = 52
buy  : 0.9 x 100 + 0.1 x 60 = 90 + 6  = 96 ;  96 - 45 = 51
decision: build (52 > 51)
tie: 100p + 40(1 - p) - 30 = 51  ->  60p = 41  ->  p = 0.683

পার্থক্য মাত্র ১ লাখ, আর সমতার বিন্দু ০.৬৮৩ — দলের ০.৭ অনুমান একটু আশাবাদী হলেই সিদ্ধান্ত উল্টে যায়। এমন ক্ষেত্রে sensitivity লিখে দেওয়াই পূর্ণ উত্তর। Build-এর খারাপ ফল (৪০ − ৩০ = ১০) buy-এর খারাপ ফলের (৬০ − ৪৫ = ১৫) চেয়েও খারাপ — ঝুঁকি এড়াতে চাইলে buy. EMV-তে build (৫২ বনাম ৫১); সম্ভাবনা ০.৬৮৩-এর নিচে নামলে buy.

(a) A = 500 / (500 + 2) = 0.99602 = 99.602%
    downtime = (1 - 0.99602) x 8760 = 34.9 hours per year
    target 99.9%: MTTR = 500 x 0.001 / 0.999 = 0.5005 h = 30.0 minutes
(b) uptime = 720 - 6 = 714 h ;  MTBF = 714 / 4 = 178.5 h ;  MTTR = 6 / 4 = 1.5 h
    A = 178.5 / (178.5 + 1.5) = 99.167%     (check: 714 / 720 = 99.167%)

(খ)-তে MTBF মানে চলার গড় সময়, তাই মেরামতের ৬ ঘণ্টা বাদ দিয়ে ভাগ — ৭২০ ÷ ৪ = ১৮০ নিলে MTBF আর MTTR যোগ হয়ে যায় (কিছু বই একে MTTF-এর সাথে মিলিয়ে বলে, পর্ব ০৩ দেখুন)। Sanity check: দীর্ঘ সময়ের availability = চলা সময় ÷ মোট সময় = ৭১৪ ÷ ৭২০ — একই উত্তর। (ক)-এর শিক্ষা: availability বাড়াতে failure কমানো ছাড়াও দ্রুত ফেরা (MTTR ২ ঘণ্টা থেকে ৩০ মিনিট) সমান কার্যকর। (ক) ৯৯.৬০২%, বছরে প্রায় ৩৪.৯ ঘণ্টা, MTTR ৩০ মিনিট; (খ) MTBF ১৭৮.৫ ঘণ্টা, MTTR ১.৫ ঘণ্টা, A ≈ ৯৯.১৬৭%.

before release = 60 + 90 = 150 ;  after = 30 ;  total = 180
DRE = 150 / 180 = 0.833 = 83.3%
density (all)          = 180 / 25 = 7.20 per KLOC
density (post-release) =  30 / 25 = 1.20 per KLOC

DRE সবসময় “এখন পর্যন্ত জানা” defect-এর ওপর — ৯০ দিনের পরে আরও বেরোলে DRE কমবে। দুটি density দুটি ভিন্ন প্রশ্নের উত্তর দেয়, তাই রিপোর্টে কোনটি দিচ্ছেন স্পষ্ট লিখুন। Sanity check: DRE ১-এর বেশি হতে পারে না, আর আগে-পরে যোগ মোটের সমান। DRE ≈ ৮৩.৩%, ৭.২০ আর ১.২০ প্রতি KLOC.

mean = 130 / 10 = 13.0
squared deviations: 1, 4, 4, 1, 0, 9, 1, 9, 1, 0  -> sum = 30
sample sigma = sqrt(30 / 9) = sqrt(3.333) = 1.826
UCL = 13 + 3 x 1.826 = 18.48 ;  LCL = 13 - 3 x 1.826 = 7.52
week 11: 21 > 18.48  ->  outside the limits: look for a special cause

সীমার ভেতরের ওঠানামা (যেমন ১৬) স্বাভাবিক — একে নিয়ে তদন্ত করলে সময় নষ্ট। ২১ সীমার বাইরে, তাই কোনো বিশেষ কারণ খুঁজুন (একটি তাড়াহুড়োর release, নতুন module). পর্ব ৬২-এর মতো এখানে সরলতার জন্য নমুনার σ; আনুষ্ঠানিক XmR chart-এ moving range থেকে σ আসে, তাতে সংখ্যা সামান্য বদলায়। Population σ (১০ দিয়ে ভাগ, ১.৭৩২) নিলে UCL ১৮.২০ — প্রশ্নে কোনটি চাওয়া, দেখে নিন। UCL ≈ ১৮.৪৮, LCL ≈ ৭.৫২; ২১ out of control.

Ca = 3, Ce = 1
I = Ce / (Ca + Ce) = 1 / 4 = 0.25
A = 6 / 8 = 0.75
D = |0.75 + 0.25 - 1| = 0.00

Stable (অনেকে নির্ভর করে) আর abstract (বেশিরভাগ interface) — ঠিক main sequence-এর ওপর। এটিই Martin-এর stable abstractions principle-এর আদর্শ: যাকে অনেকে ব্যবহার করে, তাকে বদলানো কঠিন, তাই তার ভেতরে interface রাখুন যাতে বাড়ানো যায়। I = ০.২৫, A = ০.৭৫, D = ০ — ভারসাম্যপূর্ণ।

package  Ca Ce    I     A     D
app       0  3  1.00  0.00  0.00
orders    1  2  0.67  0.17  0.17
payment   1  2  0.67  0.25  0.08
report    1  2  0.67  0.00  0.33
db        2  1  0.33  0.75  0.08
gateway   1  0  0.00  0.00  1.00   zone of pain
domain    4  0  0.00  0.00  1.00   zone of pain

Ca গুনতে প্রতিটি package-এর দিকে আসা তীর গুনুন: domain-এর দিকে orders, payment, report আর db — ৪টি। domain পুরো stable (I = ০) অথচ পুরো concrete (A = ০) — বদলানো কঠিন, বাড়ানোর জায়গাও নেই: zone of pain. Domain model-এর ক্ষেত্রে এটি প্রায়ই মেনে নেওয়া হয়, যদি domain খুব কম বদলায়; gateway-র ক্ষেত্রে বেশি চিন্তার — বাইরের payment সেবা বদলালে payment-কেও বদলাতে হবে, তাই একটি PaymentGateway interface রাখাই ভালো। domain আর gateway, দুটিই D = ১.০০.

shared attribute: addMarks - totalMarks - exportCsv   (marks)
call links      : gpa -> totalMarks ;  sendEmail -> formatEmail
components:
  1. addMarks, totalMarks, gpa, exportCsv
  2. sendEmail, formatEmail
  3. logAccess
LCOM4 = 3

gpa নিজে marks ছোঁয় না, কিন্তু totalMarks-কে ডাকে — তাই LCOM4-এ সে প্রথম দলে। sendEmail আর formatEmail কোনো attribute ভাগ করে না, তবু ডাকার সম্পর্কে এক দল। তিনটি টুকরো মানে তিনটি দায়িত্ব: ফল হিসাব (ResultCalculator), নোটিশ (Notifier) আর logging — SRP-র (পর্ব ২৭) সংখ্যাগত ইঙ্গিত। LCOM4 = ৩; তিনটি class-এ ভাঙা যায়।

paths(n) = n(n - 1) / 2
paths(6) = 6 x 5 / 2 = 15
paths(9) = 9 x 8 / 2 = 36
new paths = 36 - 15 = 21

লোক ৫০% বাড়ল (৬ → ৯), কিন্তু যোগাযোগের পথ বাড়ল ১৪০% (১৫ → ৩৬)। সাথে নতুনদের শেখানোর সময় — এটাই Brooks-এর সূত্রের (১৯৭৫) পেছনের হিসাব: দেরি হওয়া project-এ লোক যোগ করলে তা আরও দেরি করে। ছোট দল আর পরিষ্কার interface এই সংখ্যা কমায়। ১৫টি পথ; নতুন ২১টি, মোট ৩৬.

knows (>= 25%):
  auth: Rafi (12/15 = 0.80; Mitu 0.20)      cart: Rafi 0.58, Tanvir 0.42
  pay: Rafi                                  search: Mitu (Rafi 0.09)
  ui: Sumi 0.67, Mitu 0.33                   form: Sumi
  deploy: Rafi (Tanvir 0.20)                 README: Sumi 0.40, Rafi 0.40 (Tanvir 0.20)
files known: Rafi 5, Sumi 3, Mitu 2, Tanvir 1
remove Rafi -> orphans: auth, pay, deploy = 3/8   (not more than half)
recount: Sumi 3, Mitu 2, Tanvir 1 -> remove Sumi
-> orphans: auth, pay, deploy, form, README = 5/8 > 4   stop
bus factor = 2

দুজন (Rafi আর Sumi) হঠাৎ না থাকলে আটটির পাঁচটি ফাইল কেউ জানেন না। ২৫%-এর সীমায় Tanvir README জানেন না (২০%) — সীমা বদলালে উত্তরও বদলায়, আর গবেষণার আসল পদ্ধতি (পর্ব ৬৩-এ উল্লেখিত Avelino ও সহকর্মীদের ২০১৬ সালের কাজ) আরও সূক্ষ্ম। তাই উত্তরে নিয়মটি লিখে দিন। প্রতিকার: pairing আর review-তে auth ও pay-এ দ্বিতীয় একজনকে যুক্ত করা। Bus factor = ২.

classes: invalid low (<= 0) | valid 1..50 | invalid high (>= 51)   -> 3
2-value BVA: 0, 1, 50, 51                  -> 4 values
3-value BVA: 0, 1, 2, 49, 50, 51           -> 6 values

২-মানে প্রতিটি সীমা আর অন্য পাশের নিকটতম মান; ৩-মানে সীমার দুই প্রতিবেশীও। ৩-মানের ২ এমন ভুল ধরে, যেখানে কোডে qty >= 1-এর বদলে qty == 1 লেখা — ২-মানের ০ আর ১ তা ধরতে পারে না; ৪৯ ওপরের সীমায় একই কাজ করে। খালি ঘর, অক্ষর বা দশমিকের মতো ধরনের দিক থেকে invalid partition আলাদা গুনতে হবে, যদি প্রশ্ন চায়। ৩টি class; ২-মানে ৪টি, ৩-মানে ৬টি মান।

partitions: <0 | 0-12 | 13-59 | 60-120 | >120         -> 5
2-value: -1, 0, 12, 13, 59, 60, 120, 121               -> 8
3-value: -1, 0, 1, 11, 12, 13, 14, 58, 59, 60, 61,
         119, 120, 121                                  -> 14

পাশাপাশি দুটি partition-এর সীমা (১২ আর ১৩, ৫৯ আর ৬০) একে অপরের off point, তাই ২-মানে বাড়তি মান লাগে শুধু দুই প্রান্তে (−১, ১২১)। ৩-মানে পুনরাবৃত্তি বাদ দিতে ভুলবেন না — ১২-র প্রতিবেশী ১৩ আর ১৩-র প্রতিবেশী ১২ একই মান। সূত্রে মিলিয়ে দেখুন: k = ৩ হলে ২k + ২ = ৮ আর ৪k + ২ = ১৪. ৫টি partition; ৮টি আর ১৪টি মান।

full table: 2^3 = 8 rules
 C1 GPA>=3.5   Y   Y   Y   Y   N   N   N   N
 C2 low income Y   Y   N   N   Y   Y   N   N
 C3 sports     Y   N   Y   N   Y   N   Y   N
 waiver %     100 100  50  50  25   0  25   0
collapsed:
 C1            Y   Y   N   N
 C2            Y   N   -   -
 C3            -   -   Y   N
 waiver %     100  50  25   0      -> 4 rules (4 tests)

YYY আর YYN-এর কাজ একই (১০০) আর শুধু C3-এ পার্থক্য, তাই মিশে YY−। একইভাবে YN−, আর N-এর দিকে C2-র প্রভাব নেই বলে NYY ও NNY মিশে N−Y, NYN ও NNN মিশে N−N. প্রতিটি “−” একটি দাবি — কোডে সত্যিই প্রভাব নেই কি না, ঝুঁকি থাকলে একটি বাড়তি test দিয়ে দেখা ভালো। ৮টি rule; ছোট করে ৪টি।

(a) all combinations = 3 x 3 x 2 = 18
    lower bound = 3 x 3 = 9 (every browser-language pair must appear once)
    a 9-test suite covering all pairs exists -> minimum = 9
(b) all combinations = 2^5 = 32
    lower bound = 2 x 2 = 4, but the true minimum is 6
    (exhaustive search: no 5-row suite covers all 40 pairs)

দুটি বড় parameter-এর সব জোড়া অন্তত একবার আসতেই হবে — তাই গুণফলটি নিম্নসীমা। (ক)-তে এই সীমা পূরণ করা যায়: প্রতিটি browser-ভাষা জোড়ার সাথে ভূমিকা এমনভাবে বসানো যে প্রতিটি browser আর প্রতিটি ভাষার সাথে দুই ভূমিকাই আসে। (খ) ফাঁদ: নিম্নসীমা ৪ হলেও পাঁচটি binary parameter-এ ৬টির কমে হয় না — এটি একটি স্ক্রিপ্টে সব ৫-সারির সমন্বয় পরীক্ষা করে যাচাই করা (চারটি parameter হলে ৫টিই যথেষ্ট)। পরীক্ষায় সাধারণত নিম্নসীমা আর একটি বাস্তব suite চাওয়া হয়। (ক) ১৮ বনাম ৯; (খ) ৩২ বনাম ৬.

(1) E - N + 2P = 13 - 10 + 2 x 1 = 5
(2) decision nodes (2 outgoing edges): 2 (loop), 3 (if), 4 (?:), 8 (if) = 4  ->  4 + 1 = 5
(3) regions (planar drawing, outer one included) = E - N + 2 = 5
basis path testing -> 5 independent paths to test

Ternary ?:-ও একটি দুই-মুখী decision — অনেকে এটি বাদ দিয়ে ৪ লেখেন। tool-ভেদে ?: আর &&-কে গোনার নিয়ম আলাদা (পর্ব ৫০), তাই খাতায় নিয়মটি লিখুন। Sanity check: তিনটি হিসাব একই। Loop থাকায় basis-এর কিছু পথ হুবহু চালানো যায় না (যেমন শূন্যবার loop-এ fine > ৫০০ অসম্ভব) — তখন পর্ব ৫০-এর নিয়মে কাছাকাছি একটি সম্ভব পথ বেছে নিতে হয়। V(G) = ৫.

statement: 1 test   ship(6, True)  -> 140 (both if-bodies run)
branch   : 2 tests  ship(6, True) -> 140 ;  ship(3, False) -> 50
path     : 4 tests  (T,T) (T,F) (F,T) (F,F): e.g. 140, 70, 100, 50
MC/DC    : 2 tests here (each decision has a single condition = branch)

else ছাড়া if-এ statement আর branch-এর পার্থক্য সবচেয়ে স্পষ্ট: একটি test-এ দুটি body-ই চলে, কিন্তু দুটি F শাখা একবারও নেওয়া হয় না। দুটি স্বাধীন if পরপর থাকায় path ২ × ২ = ৪. Sanity check: branch coverage statement-কে subsume করে, তাই branch-এর suite (২) কখনো statement-এর (১)-এর চেয়ে ছোট হয় না। ১, ২ আর ৪টি test.

row  a b c  out        independence pairs (only one condition differs, outcome differs)
T1   0 0 0   0         a : (T2, T6)   001 -> 0, 101 -> 1
T2   0 0 1   0         b : (T2, T4)   001 -> 0, 011 -> 1
T3   0 1 0   0         c : (T3, T4), (T5, T6), (T7, T8)
T4   0 1 1   1
T5   1 0 0   0         a and b each have ONE pair, both use T2
T6   1 0 1   1         -> must take T2, T4, T6; add one c pair that reuses them:
T7   1 1 0   0            (T3, T4) or (T5, T6)
T8   1 1 1   1         minimum MC/DC = 4 tests: {T2, T3, T4, T6} or {T2, T4, T5, T6}
multiple-condition coverage = 2^3 = 8 tests

a-র প্রভাব দেখাতে b = ০ আর c = ১ রাখতেই হয় (b = ১ হলে a || b এমনিতেই সত্য, c = ০ হলে পুরোটা এমনিতেই মিথ্যা) — তাই একটিমাত্র জোড়া। ন্যূনতম সংখ্যা n + ১ = ৪, যা and/or-এর decision-এ সাধারণ ফল। Sanity check: সেটে প্রতিটি শর্ত T আর F দুটিই পেয়েছে, আর decision-ও দুই ফল দিয়েছে। ৪টি test (যেমন T2, T3, T4, T6); MCC-তে ৮টি।

score = killed / (total - equivalent) = 28 / (40 - 4) = 28 / 36 = 77.8%
naive (wrong): 28 / 40 = 70.0%
after 5 more kills: 33 / 36 = 91.7%   (3 non-equivalent survivors left)

Equivalent mutant কোনো test-ই মারতে পারে না, তাই হর থেকে বাদ — নইলে ১০০% কখনো সম্ভব নয়। কোনটি equivalent তা সাধারণভাবে যন্ত্রে নির্ধারণ করা যায় না, মানুষকে দেখতে হয়। বাকি ৩টি টিকে থাকা mutant-ই এখন সবচেয়ে দামি তথ্য: কোন ভুল আপনার test ধরে না। ৭৭.৮%; পরে ৯১.৭%.

(a) 2^16 x 2^16 = 2^32 = 4,294,967,296 cases
    4,294,967,296 / 10^6 per second = 4295 s = 71.6 minutes
    three 32-bit inputs: 2^96 ~ 7.9 x 10^28 -> about 2.5 x 10^15 years at the same speed
(b) 3 x 4 x 5 x 2 = 120 combinations

দুটি ছোট integer-এই এক ঘণ্টার বেশি, তিনটি 32-bit-এ মহাবিশ্বের বয়সের চেয়ে অনেক বেশি — এটাই “exhaustive testing অসম্ভব” নীতির সংখ্যাগত রূপ (পর্ব ৪৫), আর EP, BVA আর pairwise-এর কারণ। (ক) ২^৩২ ≈ ৪২৯ কোটি test, প্রায় ৭১.৬ মিনিট; (খ) ১২০টি।

cycle time = WIP / throughput = 24 / 6 = 4 weeks
target 2 weeks: WIP = cycle time x throughput = 2 x 6 = 12 cards
second team: WIP = 5 days x 3 per day = 15 cards

সূত্রটি গড়ের, আর স্থিতিশীল ব্যবস্থার — যত card ঢোকে প্রায় তত বেরোয়। প্রতি সপ্তাহে backlog বাড়তে থাকলে (আগমন > throughput) পুরো ব্যবস্থায় এটি খাটে না। তিনটি সংখ্যাই একই “শুরু” আর “শেষ” বিন্দু দিয়ে মাপতে হবে। ৪ সপ্তাহ; WIP ১২; দ্বিতীয় দলে গড়ে ১৫টি card.

active = 6 + 1 + 3 = 10 h
waiting = 20 + 14 + 22 + 6 = 62 h
lead time = 10 + 62 = 72 h
flow efficiency = 10 / 72 = 13.9%

কাজের সময়ের প্রায় ছয় গুণ সময় card অপেক্ষায়। সবচেয়ে বড় অপেক্ষা test-এর আগে (২২ ঘণ্টা) — tester-দের WIP বা automated test বাড়ানো সবচেয়ে বেশি লাভ দেবে। developer-কে আরও দ্রুত কোড লেখানো (৬ ঘণ্টা কমানো) প্রায় কিছুই বদলাবে না। Lead time ৭২ ঘণ্টা, flow efficiency প্রায় ১৩.৯%.

deployment frequency = 8 / 14 = 0.57 per day (about 4 per week)
lead times sorted (12 commits): 1 2 3 3 4 5 6 7 8 12 26 30
   median = ceil(0.5 x 12) = 6th value = 5 h      (mean 8.92 h)
change failure rate = 3 / 8 = 37.5%
restore times sorted: 25 40 90 -> ceil(0.5 x 3) = 2nd = 40 min

Lead time প্রতিটি commit-এর জন্য একটি মান — deploy-এর জন্য নয়। গড় (৮.৯২) দুটি দীর্ঘ commit (২৬, ৩০) টেনে তোলে, median নয়; তাই DORA median নেয়। ছোট নমুনায় একটি deploy এদিক-ওদিক হলেই CFR ১২.৫ শতাংশ-বিন্দু বদলায় — সংখ্যার পাশে নমুনার আকারও লিখুন। পড়ার কথা: গতি ভালো, কিন্তু প্রায় তিনটির একটি deploy সমস্যা ঘটাচ্ছে। ০.৫৭/দিন, ৫ ঘণ্টা, ৩৭.৫%, ৪০ মিনিট।

RICE = R x I x C / E
  F1: 2000 x 2 x 0.8 / 4 = 800
  F2: 5000 x 1 x 1.0 / 2 = 2500
  F3:  800 x 3 x 0.5 / 1 = 1200      order: F2 > F3 > F1
WSJF = (BV + TC + RR) / size
  F1: (8 + 3 + 2) / 8  = 1.63
  F2: (5 + 2 + 1) / 3  = 2.67
  F3: (6 + 13 + 3) / 2 = 11.00       order: F3 > F2 > F1

RICE-এ বেশি মানুষের কাছে পৌঁছানো F2 এগিয়ে; WSJF-এ সময়ের চাপ (time criticality ১৩) F3-কে এক নম্বরে তোলে — মৌসুম পেরিয়ে গেলে এর মূল্য অনেক কমে, যা RICE-এ ধরা পড়ে না। দুটিতেই F1 শেষে: বড় effort বা বড় job size. সংখ্যাগুলো অনুমান — সূত্র অনুমানকে সাজায়, সত্য বানায় না (পর্ব ২৪)। RICE: F2, F3, F1; WSJF: F3, F2, F1.

sorted: 1 1 2 2 2 2 2 3 3 3 3 4 4 5 5 6 7 8 9 12
p50 = ceil(0.50 x 20) = 10th = 3 days
p85 = ceil(0.85 x 20) = 17th = 7 days
p95 = ceil(0.95 x 20) = 19th = 9 days        (mean = 84 / 20 = 4.2 days)

সৎ উত্তর: “৮৫% সম্ভাবনায় ৭ দিনের মধ্যে, ৯৫% সম্ভাবনায় ৯ দিনের মধ্যে।” গড় ৪.২ দিন বললে প্রায় অর্ধেক card-ই দেরিতে মনে হবে, কারণ লম্বা লেজ (১২) গড়কে টানে। Percentile-এর অন্য পদ্ধতিতে (interpolation) সংখ্যা সামান্য বদলাতে পারে, তাই পদ্ধতির নাম লিখুন। p50 = ৩, p85 = ৭, p95 = ৯ দিন।

table (row = functional, column = dysfunctional):
  row 1: Q A A A O     rows 2-4: R I I I M     row 5: R R R R Q
15 -> O (one-dimensional)  x4
25 -> M (must-be)           x2
14 -> A (attractive)        x1
13 -> A (attractive)        x1
majority: O = 4 of 8  ->  one-dimensional (performance) feature

“থাকলে পছন্দ, না থাকলে অপছন্দ” (১৫) মানে যত ভালো, তত খুশি — performance বা one-dimensional. দুজনের কাছে এটি ইতিমধ্যে must-be (২৫) — সময়ের সাথে আনন্দদায়ক feature মৌলিক হয়ে যায়, Kano-র একটি পরিচিত পর্যবেক্ষণ। Sanity check: ৪ + ২ + ১ + ১ = ৮. One-dimensional (performance).

n = suspects = commits after the good one, up to and including the bad one
(a) n = 300  : 2^8 = 256 < 300 <= 512 = 2^9   -> ceil(log2 300)  = 9 tests
(b) n = 1024 : 2^10 = 1024 exactly            -> ceil(log2 1024) = 10 tests
(c) n = 1025 : just above 2^10                -> ceil(log2 1025) = 11 tests
one by one, worst case: n - 1 tests (299, 1023, 1024) - the last one needs no test

প্রতিটি পরীক্ষা সন্দেহের তালিকা অর্ধেক করে, তাই k টি পরীক্ষায় ২^kটি সম্ভাবনা আলাদা করা যায়। ফাঁদ: জানা ভালো commit-টিকেও n-এ গোনা — সেটি সন্দেহভাজন নয়। জানা খারাপটি গোনা হয়, কারণ সেটিই প্রথম খারাপ হতে পারে (পর্ব ৫৫)। একে একে দেখার খারাপ ক্ষেত্রে n − ১টি, কারণ বাকি একটি থাকলে সেটিই উত্তর। Skip করা commit থাকলে সংখ্যা বাড়ে। (ক) ৯, (খ) ১০, (গ) ১১.

একটি scratch repository-তে ঠিক এই ইতিহাস বানিয়ে Git ২.৫৩-এ চালানো হয়েছে (hash আপনার repository-তে আলাদা হবে):

$ git log --oneline --graph --all
* 026020c c5
* 8af12f3 c4
| * b286ca6 f2
| * f4c41e8 f1
|/
* 8e33805 c3
* 632d184 c2
* bf0d89c c1
$ git log --oneline main..feature
b286ca6 f2
f4c41e8 f1
$ git log --oneline feature..main
026020c c5
8af12f3 c4
$ git rev-list --count main...feature
4
$ git rev-list --left-right --count main...feature
2	2
$ git log --oneline -1 $(git merge-base main feature)
8e33805 c3

main..feature মানে “feature থেকে পৌঁছানো যায়, main থেকে নয়” — f1, f2. উল্টো দিকে c4, c5. তিন বিন্দুতে দুই দিকের যোগ, ২ + ২ = ৪; --left-right --count দুটিকে আলাদা করে দেখায় (বাঁয়ে main-এর ২, ডানে feature-এর ২)। merge base c3, তাই rebase ঠিক main..feature-এর commit-গুলো — f1 আর f2 — c5-এর ওপর নতুন hash-এ বসাবে। (ক) f2, f1 আর c5, c4; (খ) ৪; (গ) ২টি।

$ git log --oneline --graph --all
* ee82f0c c4
*   bde15bc M: merge feature
|\
* | 4db7579 c3
| | * 5754fdd f3
| |/
| * dc70ad0 f2
| * 1ca1ffb f1
|/
* 42181b9 c2
* 569c0d6 c1
$ git log --oneline main..feature
5754fdd f3
$ git log --oneline feature..main
ee82f0c c4
bde15bc M: merge feature
4db7579 c3
$ git rev-list --count main
7
$ git rev-list --count --first-parent main
5
$ git log --oneline -1 $(git merge-base main feature)
dc70ad0 f2

বহু উত্তরদাতা main..feature-এ f1, f2, f3 — তিনটি লেখেন। কিন্তু M-এর দ্বিতীয় parent f2, তাই f1 আর f2 এখন main থেকেও reachable; বাকি থাকে শুধু f3. উল্টো দিকে c3, M আর c4 — merge commit-ও একটি commit, গোনা হয়। main থেকে reachable: c1, c2, c3, f1, f2, M, c4 = ৭; প্রথম parent ধরে হাঁটলে f1 আর f2 বাদ, তাই ৫. Merge base এখন f2 (dc70ad0), c2 নয়। ১ আর ৩; reachable ৭, first-parent ৫.

$ git fetch
From ../origin
   bf4ebf7..2312357  main       -> origin/main
$ git status -sb
## main...origin/main [ahead 2, behind 3]
$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 2 and 3 different commits each, respectively.
  (use "git pull" if you want to integrate the remote branch with yours)
…
$ git rev-list --left-right --count main...origin/main
2	3
$ git rebase origin/main
Successfully rebased and updated refs/heads/main.
$ git status -sb
## main...origin/main [ahead 2]
$ git log --oneline --graph
* db41281 r2
* d447b78 r1
* 2312357 n3
* 4e31114 n2
* f894430 n1
* bf4ebf7 c2
* b23e050 c1

Fetch শুধু origin/main সরায়, রাফির main-কে ছোঁয় না — তাই “diverged”: রাফির ২টি commit remote-এ নেই (ahead ২), নীলার ৩টি রাফির কাছে নেই (behind ৩)। Rebase রাফির ২টি commit নীলার ৩টির ওপরে নতুন করে বসায়; এখন রাফির main origin/main-এর সব commit ধারণ করে (behind ০), আর নিজের ২টি এখনো push হয়নি (ahead ২)। এরপর সাধারণ git push-ই যথেষ্ট, force লাগে না। Fetch-এর পরে ahead ২, behind ৩; rebase-এর পরে ahead ২, behind ০.