Software Engineering MCQ — SE ও Git প্রশ্নব্যাংক বাংলায় | পর্ব ৬৭

Q: Stub, mock, fake, spy — library সব কিছুকেই “Mock” বলে। পরীক্ষায় তাহলে কোন নাম ঠিক?

পরিভাষাটি এসেছে Gerard Meszaros-এর xUnit Test Patterns (২০০৭) থেকে, আর Martin Fowler-এর “Mocks Aren't Stubs” প্রবন্ধে জনপ্রিয় হয়েছে। সেখানে নাম ঠিক হয় ভূমিকা দিয়ে, library-র class দিয়ে নয়। Dummy শুধু parameter-এর জায়গা ভরে। Stub SUT-কে ঠিক করা উত্তর দেয় (indirect input), আর test যাচাই করে SUT-এর ফল — state verification. Spy ডাকগুলো লিখে রাখে, পরে test নিজে দেখে। Mock আগে থেকেই প্রত্যাশা জানে আর ডাকটিই যাচাই করে — behaviour verification. Fake সত্যি কাজ করে, সরল উপায়ে — in-memory repository, fake clock. Python-এর unittest.mock.Mock দিয়ে এই পাঁচটির যেকোনোটি বানানো যায়: শুধু return_value দিলে সেটি ভূমিকায় stub, assert_called_once_with দিলে mock. তাই পরীক্ষায় প্রশ্নে বর্ণিত আচরণ দেখে নাম দিন: ঠিক করা উত্তর দিয়ে ফল দেখা হলে stub, ডাক যাচাই হলে mock.

Q: সব test সবুজ, coverage ১০০%, spec পুরো মানা — তবু ব্যবহারকারী অখুশি বা bug production-এ। কোন তিনটি ভুল ধারণা একসাথে কাজ করছে?

এক — verification-কে validation ভাবা। Barry Boehm-এর পরিচিত রূপে verification প্রশ্ন করে “আমরা কি product-টি ঠিকভাবে বানাচ্ছি?” — spec আর নকশা মানা হচ্ছে কি না; validation প্রশ্ন করে “আমরা কি ঠিক product বানাচ্ছি?” — আসল প্রয়োজন মেটে কি না। Spec-এ মাসিক বন্ধের কাজটি না থাকলে সব test সবুজ থেকেও product অকেজো। দুই — coverage-কে quality ভাবা। Line বা branch coverage শুধু বলে কোন লাইন বা শাখা চলেছে; assertion-হীন test-ও ১০০% দেয়। Test-এর জোর মাপে mutation testing: ছোট ভুল ঢুকিয়ে দেখা হয় test লাল হয় কি না। বেঁচে থাকা mutant দেখায় কোন আচরণ কেউ যাচাই করছে না — যেমন সীমার মান। তিন — test oracle-কে কোড বানানো। AI বা মানুষ কোড চালিয়ে যা পেলেন তা-ই প্রত্যাশিত মান বসালে test কোডের ভুলও “নিশ্চিত” করে। প্রত্যাশিত মান আসে requirement বা হাতের হিসাব থেকে।

Q: “১ story point = ১ দিন”, “CMMI level ৩ মানে ভালো software”, “open source হলেই কোড নেওয়া যায়” — management-এর এই তিন ভুল ধারণা কেন ভুল?

Story point ঘণ্টা নয়। Story point একটি দলের reference story-র সাপেক্ষে আপেক্ষিক মাপ — আকার, জটিলতা আর অনিশ্চয়তা মিলিয়ে। দুই দলের মাপকাঠি আলাদা, তাই velocity তুলনা অর্থহীন; আর velocity-কে লক্ষ্য বানালে point ফুলে ওঠে — Goodhart-এর সূত্র। Forecast দিন পরিসরে, দলের নিজের velocity থেকে। CMMI প্রক্রিয়ার পরিপক্বতা মাপে। পাঁচ level — Initial, Managed, Defined, Quantitatively Managed, Optimizing (CMMI v1.3-এর staged নাম; পুরোনো software CMM-এ level ২ ছিল “Repeatable”). Level ৩ মানে প্রতিষ্ঠানের একটি মানক প্রক্রিয়া আছে, project তা মানিয়ে নেয় — কোনো নির্দিষ্ট product ভালো, তার প্রমাণ নয়। ISO 9001-ও একটি quality management system-এর সনদ, পণ্যের নয়। License-এর compatibility দিক-নির্ভর। MIT বা BSD-র মতো permissive license শুধু notice রাখতে বলে; GPL বিতরণের সময় একই license আর source চায়; AGPL-3.0-এর ধারা ১৩ network সেবাতেও source দিতে বলে।

এক নজরে · এই পাতা কীভাবে ব্যবহার করবেন

২৩৬টি প্রশ্ন, কোর্সের ক্রমে: প্রথমে কৌশল, তারপর মডিউল ১ থেকে ১০ — প্রতিটি অংশের শুরুতে “যে পর্বগুলো ঝালিয়ে নেবেন” তালিকা, পর্বের লিংকসহ।
আগে খাতায় উত্তর, তারপর চাপুন: যে অপশনই চাপুন, ব্যাখ্যা খুলবে — কেন সঠিক বা ভুল, আর কোন পর্বে বিষয়টি আছে।
কঠিনতা প্রশ্নের শুরুতেই: (সহজ), (মাঝারি) বা (কঠিন); মেশানো আছে সংজ্ঞা, “কোন command বা pattern মানায়”, Git-এর ফল অনুমান, UML পড়া, ছোট কোডে smell আর SOLID, numerical আর প্রচলিত ভুল ধারণা।
Git-এর ফল আসল, numerical script-এ যাচাই: “যাচাই করা” লেখা প্রতিটি Git আচরণ একটি খালি scratch repository-তে Git ২.৫৩ দিয়ে চালিয়ে দেখা; প্রতিটি সংখ্যা ছোট প্রোগ্রামে মেলানো। তিনটি checker-এ সংখ্যা বদলে নিজের হিসাবও মেলাতে পারবেন।
স্কোর দেখে দুর্বল মডিউল খুঁজুন: শেষে প্রথম চেষ্টার স্কোর দেখাবে; বেশি ভুলের অংশের পর্বগুলো আবার পড়ুন, আর “কেন এই উত্তর ভুল” অংশের ব্যাখ্যা খুলুন।

এই পর্বে যা করবেন

Software engineering আর Git-এর MCQ কোন ছাঁচে আসে তা চেনা, আর বাদ দেওয়ার পদ্ধতি ও সময় ভাগ শেখা
Git command-এর পরে working tree, index, branch আর history-র অবস্থা ধাপে ধাপে অনুমান করা
reset বনাম revert, merge বনাম rebase, -X ours বনাম -s ours, stub বনাম mock, verification বনাম validation — জোড়া-বিভ্রান্তিগুলো দূর করা
COCOMO, function point, PERT-CPM, coverage, mutation score আর DORA-র ছোট numerical-এ রীতি মেনে দ্রুত উত্তর
পুরো কোর্সের ২৩৬টি প্রশ্নে নিজের দুর্বল মডিউল খুঁজে সেই পর্বে ফিরে যাওয়া

১ · MCQ কীভাবে সামলাবেন — প্রশ্নের ধরন, বাদ দেওয়া, রীতি আর সময়

ধরুন রংপুরের তানিয়া একটি developer পদের অনলাইন screening-এ চল্লিশটি MCQ পেলেন। প্রশ্ন চেনা — “git reset HEAD~1-এর পরে ফাইলের কী হয়?”, “৩২ KLOC-এ organic COCOMO-র effort কত?” — কিন্তু অপশনে “staged” আর “unstaged” পাশাপাশি, “৯১” আর “৭৭” দুটিই। পরে দেখলেন, বেশিরভাগ ভুল এসেছে একটি default mode, একটি সূত্রের exponent বা “নয়” শব্দটি চোখ এড়িয়ে যাওয়ায়।

প্রশ্নকর্তা জেনেশুনে এমন ভুল অপশন রাখেন, যা কোনো আধা-সত্য নিয়ম বা চেনা হিসাবের ভুল থেকে আসে — একে বলে distractor. এই কোর্সের distractor-গুলো ঘুরেফিরে বারোটি ভুল ধারণা থেকেই আসে (নিচের টেবিল); সেগুলো চিনলে অর্ধেক কাজ শেষ।

প্রশ্নের ছয় ছাঁচ

ধরন	উদাহরণ	কৌশল
সংজ্ঞা ও জোড়া-ধারণা	verification বনাম validation, stub বনাম mock	সংজ্ঞার একটি চাবি-শব্দ ধরুন — spec বনাম প্রয়োজন, ফল বনাম ডাক
“কোনটি মানায়”	কোন command, pattern বা কৌশল	আগে পরিস্থিতির কঠিন শর্তটি খুঁজুন — shared কি না, interface বদলায় কি না
Git-এর ফল অনুমান	reset, merge, rebase-এর পরে কী থাকে	খাতায় commit graph আর তিন এলাকা আঁকুন; প্রতিটি command কোনটি সরায়, লিখুন
ছবি বা কোড পড়া	UML-এর হীরা-ত্রিভুজ, ছোট কোডে smell	চিহ্নের দিক আর রেখার ধরন আগে; কোডে কে কাকে চেনে
ছোট numerical	COCOMO, PERT, V(G), mutation score, CFR	সূত্র আর রীতি আগে খাতায়, উত্তরের মাত্রা আগে আন্দাজ
“কোনটি নয়” বা “ভুল”	কোনটি behavioral pattern নয়	প্রতিটি অপশনের পাশে স বা ভু লিখুন; “নয়” শব্দে দাগ দিন

কৌশল ১ · বাদ দেওয়ার পদ্ধতি — একটি কঠিন Git প্রশ্ন ধাপে ধাপে

সঠিক উত্তর সরাসরি খোঁজার চেয়ে ভুলগুলো বাদ দেওয়া প্রায়ই সহজ — একে বলে elimination method. নিচের প্রশ্নের তিনটি ভুল অপশন তিনটি আলাদা ভুল ধারণা থেকে বানানো; প্রতিটি নিয়ম দিয়েই কাটুন।

কে ours?HEAD = mainআর option -X
Conflict কোথায়শুধু feelimit পরিষ্কার
-X oursfee = 70গ, ঘ বাদ
-X ≠ -slimit আসেক বাদ
উত্তরখযাচাই করা

প্রশ্ন (কঠিন)একটি config ফাইল · কাল্পনিক

Base:  fee = 60   …   limit = 1000
main:  fee = 70   (শুধু এটুকু)
promo: fee = 50   …   limit = 800

main-এ থেকে: git merge -X ours promo
ফাইলে কী থাকবে?

ক) fee = 70, limit = 1000
খ) fee = 70, limit = 800
গ) fee = 50, limit = 800
ঘ) fee-তে conflict marker, limit = 800

ধাপ ২hunk ধরে তুলনা

লাইন     base   main   promo   অবস্থা
fee      60     70     50      দুই দিকে ভিন্ন → conflict
limit    1000   1000   800     শুধু promo বদলেছে → পরিষ্কার

ধাপ ৩-X ours কী করে

-X ours = conflict-এর hunk-এ ours (main) বেছে নেয়
fee   → 70          গ বাদ (সেটি -X theirs)
marker থাকে না      ঘ বাদ (-X নিজেই মীমাংসা করে)

ধাপ ৪strategy বনাম option

-s ours  = promo-র কিছুই নয়, শুধু history-তে merge
           → fee = 70, limit = 1000   (অপশন ক)
-X ours  = conflict-হীন বদল রাখে
           → limit = 800 আসে          ক বাদ

ধাপ ৫Git ২.৫৩-এ চালানো ফল

-X ours:    fee = 70   limit = 800    ← খ
-s ours:    fee = 70   limit = 1000
-X theirs:  fee = 50   limit = 800

আগে কে ours, আর কোন flag. Merge-এ HEAD-এর branch ours, আনা branch theirs; আর -X একটি strategy option, -s একটি strategy — দুটি আলাদা জিনিস (পর্ব ১৩, ৫৪)।
Conflict কোন hunk-এ, খাতায় টেবিল করুন। fee দুই দিকে ভিন্নভাবে বদলেছে, তাই conflict; limit শুধু promo বদলেছে, তাই three-way merge সেটি সরাসরি নেয় (পর্ব ১৩)।
-X ours শুধু conflict-এর hunk-এ ours বাছে। তাই fee = ৭০ — promo-র ৫০ নেওয়া অপশন গ বাদ; আর -X নিজেই মীমাংসা করে বলে marker-ওয়ালা অপশন ঘ-ও বাদ (পর্ব ৫৪)।
-X ours আর -s ours গুলিয়ে ফেলাই বড় ফাঁদ। -s ours হলে promo-র কোনো বদলই আসত না — ঠিক অপশন ক। কিন্তু -X conflict-হীন বদল রাখে, তাই limit = ৮০০; ক বাদ (পর্ব ৫৪)।
উত্তর খ — আর আসল Git-এ মিলিয়ে দেখা। একটি scratch repository-তে তিনটি merge চালিয়ে ফল ওপরের মতোই এসেছে। প্রশ্নের প্রতিটি অপশন আসলে একটি আলাদা command-এর ফল — এটিই ভালো distractor-এর চিহ্ন।

কৌশল ২ · রীতি আর একক আগে, হিসাব পরে

Numerical-এ নম্বর বেশি হারায় গুণ-ভাগে নয়, রীতি আর সূত্রের একটি অংশ ভুলে। এই পাতা কোর্সের পর্বগুলোর রীতি মানে; ভিন্ন হলে প্রশ্নেই লেখা।

বিষয়	রীতি বা সূত্র	যাচাইয়ের কৌশল
Quality ও flow	A = MTBF ÷ (MTBF + MTTR); DRE = আগে ÷ (আগে + পরে); Little: cycle time = WIP ÷ throughput	শতাংশ ১০০ ছাড়ালে ভাগ উল্টে গেছে (পর্ব ৩, ৬)
Velocity	বাকি ÷ গড় velocity, তারপর উপরে গোল	Sprint ভাঙা যায় না; point ঘণ্টা নয় (পর্ব ৫)
Coupling	I = Ce ÷ (Ca + Ce), A = Na ÷ Nc, D = \|A + I − ১\|	I আর A ০ থেকে ১-এর মধ্যে (পর্ব ২৫)
Testing	V(G) = E − N + 2P; score = killed ÷ (মোট − equivalent); 1 − (1 − p)ⁿ	+2P আর equivalent বাদ — দুটিই প্রিয় ফাঁদ (পর্ব ৫০, ৫১)
Estimation	VAF = ০.৬৫ + ০.০১ × ΣGSC; te = (O + 4M + P) ÷ ৬; E = a × KLOC^b, D = 2.5 × E^d	সময় = effort ÷ ১২ নয়; σ আর σ² আলাদা (পর্ব ৬০)
Planning ও risk	float = LS − ES; slope = Δখরচ ÷ Δদিন; SPI = EV ÷ PV, CPI = EV ÷ AC; RRL = (RE আগে − পরে) ÷ খরচ	EV সবসময় লবে (পর্ব ৬১, ৬২)

নিচের checker মডিউল ১, ২, ৩, ৫ আর ৯-এর কয়েকটি numerical আবার করে; সংখ্যা বদলে নিজের প্রশ্নও মেলাতে পারেন:

// Re-check the flow, design-metric and Git numericals of modules 1-3, 5 and 9.
const f = (x, d = 2) => Number(x.toFixed(d));
const avg = a => a.reduce((s, x) => s + x, 0) / a.length;
console.log("Paths, 8 people n(n-1)/2   :", 8 * 7 / 2);
console.log("Availability 499/(499+1)   :", f(100 * 499 / 500, 1) + "%");
console.log("DRE 140/(140+60)           :", f(100 * 140 / 200, 0) + "%");
console.log("Sprints for 140 pts, avg   :", f(avg([24, 30, 27])), "->", Math.ceil(140 / avg([24, 30, 27])));
console.log("Little: WIP 24 / 8 per week:", 24 / 8, "weeks");
console.log("Flow efficiency 6 h / 40 h :", f(100 * 6 / 40, 0) + "%");
console.log("Branch life 2 -> 5 days    :", (5 / 2) ** 2, "x conflicts");
const Ca = 3, Ce = 1, I = Ce / (Ca + Ce), A = 2 / 8;
console.log("I, A, D (Ca 3, Ce 1, 2/8)  :", I, A, Math.abs(A + I - 1));
console.log("ISP unused (6-2)+(6-3)     :", (6 - 2) + (6 - 3));
console.log("Bisect, 1000 suspects      :", Math.ceil(Math.log2(1000)), "tests");
console.log("Snapshot store 200 + 5x20  :", 200 + 5 * 20, "KB");

আউটপুট (নির্ধারিত, প্রতিবার একই):

Paths, 8 people n(n-1)/2   : 28
Availability 499/(499+1)   : 99.8%
DRE 140/(140+60)           : 70%
Sprints for 140 pts, avg   : 27 -> 6
Little: WIP 24 / 8 per week: 3 weeks
Flow efficiency 6 h / 40 h : 15%
Branch life 2 -> 5 days    : 6.25 x conflicts
I, A, D (Ca 3, Ce 1, 2/8)  : 0.25 0.25 0.5
ISP unused (6-2)+(6-3)     : 7
Bisect, 1000 suspects      : 10 tests
Snapshot store 200 + 5x20  : 300 KB

প্রথম ছয় লাইন মডিউল ১-এর: যোগাযোগের পথ, availability, DRE, velocity থেকে Sprint (গড় ২৭, তাই ৬টি), Little-এর সূত্র আর flow efficiency. তারপর মডিউল ৩-এর branch-আয়ুর বর্গ নিয়ম, মডিউল ৫-এর I, A, D আর ISP-এর অপ্রয়োজনীয় নির্ভরতা, মডিউল ৯-এর bisect আর মডিউল ২-এর snapshot store. প্রতিটি সংখ্যা নিচের কোনো প্রশ্নের উত্তর।

কৌশল ৩ · Git-এর প্রশ্নে খাতায় ছবি

Git-এর প্রশ্নে মনে মনে হিসাব না করে তিনটি জিনিস আঁকুন: commit graph (কে কার parent, branch আর HEAD কোথায়), তিনটি এলাকা (working tree, index, repository) আর command-টি কোনটি সরায়। নিচের ছবিটি সবচেয়ে বেশি ভুল হওয়া প্রশ্নের এক নজরের উত্তর।

reset-এর তিন mode আর revert — কোনটি কী বদলায়

What git reset --soft / --mixed / --hard and git revert change in the branch, the index and the working tree

কৌশল ৪ · negative marking আর সময় ভাগ

ভুলে নম্বর কাটলে (negative marking) আন্দাজ একটি হিসাবের সিদ্ধান্ত। ধরা যাক ঠিক হলে +১, ভুলে −০.২৫. চারটি অপশনে অন্ধ আন্দাজের গড় লাভ মাত্র +০.০৬২৫; একটি নিশ্চিতভাবে বাদ দিলে +০.১৬৭; দুটি বাদ দিলে +০.৩৭৫. সাধারণ নিয়ম: k টি অপশন বাকি থাকলে আন্দাজ লাভজনক, যতক্ষণ কাটা নম্বর ১ ÷ (k − ১)-এর কম। কত কাটে বা আদৌ কাটে কি না, পরীক্ষাভেদে আলাদা — নিজের পরীক্ষার নিয়ম দেখে নিন।

সময় ভাগ করুন দুই দফায়: প্রথমে সংজ্ঞার প্রশ্ন, Git-এর ছবি বা numerical লাগলে চিহ্ন দিয়ে এগিয়ে যান; পরে চিহ্নিতগুলো, খাতায় — Git-এ আগে graph, numerical-এ আগে সূত্র।

বারোটি বড় ফাঁদ

ফাঁদ	ভুল ধারণা	সঠিক কথা
reset বনাম revert	“দুটিই undo, একই কাজ”	reset branch সরিয়ে history বদলায়; revert নতুন উল্টো commit যোগ করে (পর্ব ১১)
merge বনাম rebase	“rebase-এর পরে hash একই”	replay-তে parent বদলায়, তাই নতুন hash; shared commit rebase নয় (পর্ব ১৫)
ours আর theirs	“ours সবসময় আমার branch”	rebase-এ উল্টো: ours = নতুন base (পর্ব ১৫)
-X ours বনাম -s ours	“দুটিই অন্য branch-এর বদল ফেলে”	-X শুধু conflict-এর hunk-এ; -s সবকিছু (পর্ব ৫৪)
.gitignore	“ignore করলে tracked ফাইলও থামে”	শুধু untracked; tracked হলে rm --cached (পর্ব ১০)
DRY	“কোনো সংখ্যা দুবার লেখা নিষেধ”	একটি জ্ঞান, একটি জায়গা; কাকতালীয় মিল আলাদা থাকে (পর্ব ২৬)
SRP	“এক class, এক কাজ”	এক module-এর দায় এক actor-এর কাছে (পর্ব ২৭)
stub বনাম mock	“সব double-ই mock”	stub উত্তর দেয়, ফল যাচাই; mock ডাকটিই যাচাই (পর্ব ৪৯)
verification বনাম validation	“spec মানলেই ঠিক product”	spec মানা verification; প্রয়োজন মেটানো validation (পর্ব ৩, ৪৫)
coverage	“১০০% coverage = bug নেই”	লাইন চলা মাপে; assertion আর mutation দেখুন (পর্ব ৫০)
story point	“১ point = ১ দিন, দুই দলের velocity তুলনীয়”	আপেক্ষিক, দলের নিজের; তুলনা অর্থহীন (পর্ব ৫, ৬০)
license	“open source হলেই সব মেলে”	compatibility দিক-নির্ভর; AGPL network-এ, GPL বিতরণে (পর্ব ৬৩)

এই পাতার প্রশ্নগুলো সম্পর্কে: প্রশ্নগুলো এই কোর্সের জন্য নতুন করে লেখা — বিশ্ববিদ্যালয়ের পরীক্ষা, চাকরির লিখিত পরীক্ষা আর ইন্টারভিউতে এ ধরনের প্রশ্ন প্রায়ই আসে, এমন ধারণা থেকে বানানো; কোনোটিই কোনো নির্দিষ্ট পরীক্ষা বা প্রতিষ্ঠানের আসল প্রশ্ন নয়। প্রতিষ্ঠান আর case কাল্পনিক। Git-এর আচরণ নির্ভর করে version আর config-এর ওপর — এখানে Git ২.৫৩, কোনো বাড়তি system বা global config ছাড়া। পূর্ণ সমাধানের বড় numerical পাবেন পর্ব ৬৬-এ, কারণসহ লিখিত উত্তর পর্ব ৬৮-এ।

২ · মডিউল ১ — Software engineering-এর ভিত্তি (২২টি প্রশ্ন)

এই অংশে সংজ্ঞা, ইতিহাস, quality-র মাপ, process model, Scrum আর Kanban. নম্বর বেশি হারায় তিন জায়গায় — Brooks's law-এর কারণ, availability আর DRE-এর হর, আর velocity বা story point-কে ঘণ্টা ভাবা।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ০১–০৬

পর্ব ০১ · Software engineering কী আর পর্ব ০২ · Software crisis ও ইতিহাস — IEEE সংজ্ঞা, Brooks-এর চার কঠিনতা, n(n − ১)/২, NATO ১৯৬৮, Ariane 5 আর Mars Climate Orbiter
পর্ব ০৩ · Software quality — ISO/IEC 25010-এর আট characteristic, fault-error-failure, MTBF-MTTR, DRE, cost of quality
পর্ব ০৪ · Process model — waterfall আর Royce, V-model-এর জোড়া, incremental বনাম iterative, spiral-এ RE = P × L
পর্ব ০৫ · Agile আর Scrum আর পর্ব ০৬ · Kanban আর lean — Manifesto-র “over”, timebox, velocity, Little-এর সূত্র, flow efficiency

(সহজ) ISO/IEC/IEEE 24765-এর প্রচলিত সংজ্ঞায় software engineering-এর সারকথা কোনটি?

শুধু বড় দলের জন্য দলিল লেখার নিয়ম
নতুন programming language আর tool তৈরির বিদ্যা
Software-এর development, operation ও maintenance-এ systematic, disciplined, quantifiable পদ্ধতির প্রয়োগ
যত দ্রুত সম্ভব কাজ করা কোড লেখার দক্ষতা

(সহজ) ৮ জনের একটি দলে সবাই সবার সাথে কথা বললে মোট কতটি communication path হয়?

৬৪
২৮
৫৬
১৬

(মাঝারি) একটি project তিন মাস পিছিয়ে আছে। শেষ মাসে ম্যানেজার ৫ জনের দলে আরও ৫ জন নতুন developer দিলেন। Brooks's law অনুযায়ী সবচেয়ে সম্ভাব্য ফল এবং তার কারণ কোনটি?

Quality বাড়বে, কিন্তু সময় একই থাকবে
আরও দেরি — নতুনদের শেখানো, কাজ ভাগ আর যোগাযোগের খরচ বাড়ে
সময় অর্ধেক হবে, কারণ লোক দ্বিগুণ
কোনো প্রভাব নেই, কারণ নতুনরা আলাদা module-এ কাজ করবেন

(সহজ) “Software engineering” নামটি জনপ্রিয় করা NATO সম্মেলন কোথায় ও কবে হয়েছিল?

Garmisch, জার্মানি — ১৯৬৮
Snowbird — ২০০১
রোম — ১৯৬৯
Dartmouth — ১৯৫৬

(মাঝারি) Brooks-এর “No Silver Bullet” (১৯৮৬) অনুযায়ী নিচের কোনটি accidental complexity-র উদাহরণ?

ব্যাংকের সুদের নিয়ম প্রতি বছর বদলানো
একটি system-কে সরকারের নির্ধারিত report format মেনে চলতে হয়
Software দেখা যায় না, তাই নকশা ছবিতে পুরো ধরা কঠিন
পুরোনো tool-এ প্রতিটি build-এর জন্য হাতে বিশটি ধাপ চালানো

(মাঝারি) একটি ঘটনায় reuse করা পুরোনো কোড 64-bit floating-point মানকে 16-bit signed integer-এ রূপান্তর করতে গিয়ে overflow করে, handler ছিল না, আর দুটি navigation unit-ই বন্ধ হয়। এটি কোন সুপরিচিত ব্যর্থতা?

Mars Climate Orbiter (১৯৯৯)
Ariane 5 Flight 501 (১৯৯৬)
Therac-25 (১৯৮০-এর দশক)
Knight Capital (২০১২)

(সহজ) ISO/IEC 25010:2011-এ নিচের কোনটি আটটি মূল characteristic-এর একটি নয়, বরং একটি sub-characteristic?

Compatibility
Security
Testability
Portability

(মাঝারি) একটি ফলাফল পোর্টালের কোডে m >= 80-এর জায়গায় m > 80 লেখা; চলার সময় ঠিক ৮০ পাওয়া এক ছাত্রের জন্য ভুল শাখা নেওয়া হলো, আর পাতায় তিনি A+-এর বদলে A দেখলেন। “পাতায় ভুল গ্রেড দেখানো” অংশটি কী?

Defect density
Error
Failure
Fault

(মাঝারি) একটি system-এর MTBF ৪৯৯ ঘণ্টা আর MTTR ১ ঘণ্টা। দীর্ঘ সময়ের গড় availability কত?

৪৯৯%
৯৯.৯%
০.২%
৯৯.৮%

(মাঝারি) একটি release-এর আগে review আর test মিলিয়ে ১৪০টি defect ধরা পড়ল; release-এর পরে ব্যবহারকারীরা আরও ৬০টি পেলেন। Defect removal efficiency (DRE) কত?

≈ ৪২.৯%
৩০%
≈ ২৩৩%
৭০%

(সহজ) ব্যবহারকারীদের সাথে acceptance test-এ দেখা হচ্ছে software আসলে তাঁদের প্রয়োজন মেটায় কি না। এটি মূলত কোনটি?

Verification — “building the product right”
Validation — “building the right product”
Regression testing
Static testing

(মাঝারি) V-model-এ “architecture design” ধাপটি কোন test স্তরের সাথে জোড়া?

System test
Acceptance test
Integration test
Unit test

(কঠিন) Spiral model-এর একটি loop-এ দুটি ঝুঁকি: A — সম্ভাবনা ১০%, ক্ষতি ৳৮০ লাখ; B — সম্ভাবনা ৪০%, ক্ষতি ৳৩০ লাখ। Risk exposure দিয়ে বিচার করলে এই loop-এ কোনটি আগে সামলানো উচিত?

B, কারণ RE = ৳১২ লাখ, যা A-র ৳৮ লাখের বেশি
A, কারণ ক্ষতির অঙ্ক বড়
দুটি সমান, কারণ দুটিরই RE = ৳৮ লাখ
A, কারণ RE = ৳৮০ লাখ

(সহজ) একটি দল প্রথমে পুরো অ্যাপের একটি মোটা খসড়া বানাল, তারপর প্রতি চক্রে সেই একই screen-গুলো ব্যবহারকারীর মত নিয়ে আরও উন্নত করল। এটি মূলত কোন ধরন?

Iterative
Incremental
V-model
Waterfall

(মাঝারি) Winston Royce-এর ১৯৭০ সালের লেখা নিয়ে প্রচলিত ভুল ধারণা কোনটি?

লেখাটিতে ধাপগুলোর একটি চিত্র আছে
তিনি সরল ধারাবাহিক waterfall-কে আদর্শ পদ্ধতি হিসেবে প্রস্তাব করেছিলেন
তিনি দলিল আর test-এর ওপর জোর দিয়েছিলেন
তিনি বড় system-এর অভিজ্ঞতা থেকে লিখেছিলেন

(সহজ) Agile Manifesto-র “Working software over comprehensive documentation”-এ “over” শব্দের অর্থ কী?

দুটিরই মূল্য আছে, তবে বাঁয়ের দিকটিকে বেশি অগ্রাধিকার
দলিল সম্পূর্ণ বাদ দিতে হবে
দুটির ওজন সব সময় সমান
আগে দলিল, পরে software

(মাঝারি) Scrum Guide 2020 অনুযায়ী এক মাসের Sprint-এ কোন timebox সঠিক?

Daily Scrum ৩০ মিনিট
Sprint Planning সর্বোচ্চ ৮ ঘণ্টা
Sprint Review সর্বোচ্চ ৮ ঘণ্টা
Sprint Retrospective সর্বোচ্চ ১ ঘণ্টা

(মাঝারি) একটি দলের শেষ তিন Sprint-এর velocity ২৪, ৩০ আর ২৭ point. বাকি কাজ ১৪০ point. গড় velocity ধরে আর কতগুলো পূর্ণ Sprint লাগবে?

(মাঝারি) দল A-র velocity ৪০ আর দল B-র ২০ point. ম্যানেজার বললেন, “A দলের productivity দ্বিগুণ।” সবচেয়ে সঠিক প্রতিক্রিয়া কোনটি?

ঠিক, যদি দুই দলের সদস্যসংখ্যা সমান হয়
ঠিক, কারণ point ঘণ্টার সমান
তুলনা অর্থহীন — story point প্রতিটি দলের নিজের আপেক্ষিক মাপ
B দলকে velocity ৪০ লক্ষ্য দেওয়া উচিত

(মাঝারি) একটি স্থিতিশীল Kanban ব্যবস্থায় গড় WIP ২৪টি card, আর গড় throughput সপ্তাহে ৮টি। Little-এর সূত্রে গড় cycle time কত?

৩ সপ্তাহ
৩২ সপ্তাহ
১৯২ সপ্তাহ
০.৩৩ সপ্তাহ

(মাঝারি) একটি ticket-এর lead time ৪০ ঘণ্টা, যার মধ্যে কেউ সক্রিয়ভাবে কাজ করেছেন মোট ৬ ঘণ্টা; বাকি সময় অপেক্ষায়। Flow efficiency কত?

১৫%
৮৫%
≈ ৬৬৭%
৩৪%

(মাঝারি) Scrum Master সম্পর্কে কোন বক্তব্যটি Scrum Guide 2020-এর সাথে মেলে?

তিনি Product Backlog-এর ক্রম ঠিক করেন
তিনি দলের project manager, প্রতিদিন কাজ বণ্টন করেন
তিনি Increment গ্রহণ বা বাতিলের চূড়ান্ত সিদ্ধান্ত দেন
দলের কার্যকারিতার জন্য জবাবদিহি করেন — বাধা সরান, শেখান, কিন্তু কাজ ভাগ করে দেন না

৩ · মডিউল ২ ও ৩ — Git-এর মৌলিক আর Git দিয়ে দলগত কাজ (৫০টি প্রশ্ন)

দুই মডিউল এক অংশে, কারণ প্রশ্নের ধরন এক: একটি command-এর পরে কী থাকে। প্রতিটি “যাচাই করা” প্রশ্নের ফল একটি খালি scratch repository-তে চালিয়ে দেখা। উত্তর দেওয়ার আগে খাতায় graph আর তিন এলাকা আঁকুন।

মডিউল ২ — Git-এর মৌলিক (২৫টি প্রশ্ন)

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ০৭–১৩

পর্ব ০৭ · Version control কী আর পর্ব ০৮ · প্রথম Git repository — centralized বনাম distributed, তিন এলাকা, commit index থেকে, commit -a, rm --cached
পর্ব ০৯ · History আর পার্থক্য — status -s-এর দুই ঘর, diff বনাম diff --staged, hunk header, HEAD~ বনাম HEAD^
পর্ব ১০ · .gitignore আর config — logs/ বনাম logs/*, শুরুর /, tracked ফাইল, autocrlf, config-এর স্তর
পর্ব ১১ · ভুল শোধরানো আর পর্ব ১২ · Branch — reset-এর তিন mode, revert -m 1, amend, reflog, detached HEAD
পর্ব ১৩ · Merge আর conflict — fast-forward বনাম --no-ff, three-way merge, marker পড়া, semantic conflict

(সহজ) অফিসের internet বন্ধ। Git ব্যবহারকারী একজন developer-এর পক্ষে নিচের কোনটি সম্ভব, যা Subversion-এর মতো centralized VCS-এ সাধারণত সম্ভব নয়?

সহকর্মীর নতুন commit সাথে সাথে পাওয়া
নিজের কম্পিউটারে commit করা আর পুরো history দেখা
Server-এর repository-তে সরাসরি push করা
Pull request খোলা

(সহজ) Git আর GitHub-এর সম্পর্ক কোনটি?

GitHub হলো Git-এর নতুন version
দুটি একই প্রতিষ্ঠানের একই product-এর দুই নাম
Git শুধু GitHub-এর server-এ চলে
Git একটি version control tool; GitHub Git repository রাখার ও দলের কাজের একটি hosting platform

(মাঝারি) একটি project-এর ৫টি version রাখা হবে। এতে একটি ২০০ KB-এর ছবি (কখনো বদলায় না) আর একটি ২০ KB-এর কোড-ফাইল (প্রতিটি version-এ বদলায়)। একই বিষয়বস্তু একবারই রাখে এমন snapshot store-এ, সংকোচন ছাড়া, মোট কত KB লাগবে?

৩০০ KB
১,০০০ KB
২২০ KB
১,১০০ KB

(মাঝারি) নতুন repository-তে echo v1 > a.txt, git add a.txt, তারপর echo v2 > a.txt, তারপর git commit -m "Add a". এরপর git show HEAD:a.txt আর git status -s কী দেখাবে (Git ২.৫৩-এ যাচাই করা)?

v2, আর status-এ M a.txt
v2, আর status পরিষ্কার
Commit ব্যর্থ, কারণ ফাইল add-এর পরে বদলেছে
v1, আর status-এ M a.txt

(মাঝারি) একটি commit করা notes.txt-এ git rm --cached notes.txt চালানোর পরে git status -s কী দেখায় (Git ২.৫৩-এ যাচাই করা)?

দুটি লাইন: D notes.txt আর ?? notes.txt
AM notes.txt
কিছুই না, কারণ ফাইল ফোল্ডারে আছে
শুধু D notes.txt

(সহজ) একটি tracked ফাইল t.txt বদলানো, আর new.txt নতুন (কখনো add হয়নি)। git commit -a -m two চালালে কী হয়?

Commit ব্যর্থ, কারণ একটি ফাইল untracked
দুটি ফাইলই commit হয়
শুধু t.txt-এর বদল commit হয়; new.txt untracked থাকে
শুধু new.txt commit হয়

(মাঝারি) সব পরিবর্তন git add করা হয়েছে, এখনো commit হয়নি। এখন git diff (কোনো option ছাড়া) কী দেখাবে?

পরের commit-এ যা যাবে, তার পুরো diff
কিছুই না — working tree আর index এখন এক
শেষ দুই commit-এর পার্থক্য
HEAD আর working tree-র পার্থক্য

(মাঝারি) একটি diff-এর hunk header @@ -5,6 +5,4 @@. কোনটি নিশ্চিতভাবে বলা যায়?

ফাইলটি ৫ থেকে ৬ লাইনে বেড়েছে
লাইন ৫ আর ৬ বদলেছে
পুরোনো ফাইলের লাইন ৫ থেকে ৬টি লাইন, নতুনের লাইন ৫ থেকে ৪টি — নিট ২টি লাইন কমেছে
৬টি লাইন যোগ আর ৪টি মোছা হয়েছে

(কঠিন) একটি merge commit M-এর প্রথম parent P1 আর দ্বিতীয় parent P2. P1-এর একমাত্র parent Q1, আর P2-এর একমাত্র parent Q2. HEAD = M হলে HEAD~2 আর HEAD^2 কোন দুটি commit?

HEAD~2 = P2, HEAD^2 = Q1
HEAD~2 = Q2, HEAD^2 = P1
HEAD~2 = Q1, HEAD^2 = P2
দুটিই P2

(মাঝারি) .gitignore-এ দুটি লাইন: logs/* আর !logs/keep.txt. git check-ignore -v logs/keep.txt কী দেখায় (যাচাই করা)?

.gitignore:2:!logs/keep.txt — negation মিলেছে, তাই ফাইলটি ignored নয়
Error, কারণ logs/* আর ! একসাথে চলে না
.gitignore:1:logs/* — ফাইলটি ignored
কিছু দেখায় না, কারণ negation-এর লাইন check-ignore পড়ে না

(মাঝারি) Repository-র মূলে .gitignore-এ একটিমাত্র লাইন /build/. কোন path ignored হবে না?

build/debug/x.o
build/ folder নিজে
build/app.o
src/build/app.o

(সহজ) .env আগেই commit হয়েছে। এখন .gitignore-এ .env লিখে ফাইলটি বদলালে git status -s-এ কী আসে?

কিছুই না, কারণ ফাইলটি এখন ignored
!! .env
D .env
M .env — ignore শুধু untracked ফাইলে কাজ করে

(মাঝারি) Windows-এ core.autocrlf=true, কোনো .gitattributes নেই। CRLF line ending-এর একটি text file add করে commit, তারপর ফাইল মুছে আবার checkout করা হলো। Repository আর working tree-তে কী থাকে (যাচাই করা)?

Repository-তে LF, working tree-তে CRLF
দুই জায়গাতেই CRLF
Repository-তে CRLF, working tree-তে LF
দুই জায়গাতেই LF

(সহজ) user.email global config-এ b@example.com আর local .git/config-এ c@example.com. কোনো -c বা include নেই। পরের commit কোন email-এ হবে?

c@example.com — local পরে পড়া হয়, শেষ মান জেতে
দুটিই commit-এ লেখা হয়
b@example.com — global সবসময় জেতে
Error, কারণ দুই স্তরে একই key

(মাঝারি) একটি branch-এ পরপর commit C1 → C2 → C3, প্রতিটিতে f.txt-এ একটি করে লাইন যোগ। Working tree পরিষ্কার। git reset HEAD~2 (কোনো mode ছাড়া) চালানোর পরে কী অবস্থা (যাচাই করা)?

Branch C1-এ; বদল staged অবস্থায় (M f.txt)
Branch C1-এ; ফাইলে তিনটি লাইনই আছে, আর status-এ M f.txt (unstaged)
C2 আর C3 চিরতরে মুছে গেছে
Branch C1-এ; ফাইলে একটিই লাইন

(মাঝারি) একটি bug-ওয়ালা commit দলের shared main-এ push হয়ে গেছে, কয়েকজন pull-ও করেছেন। সবচেয়ে নিরাপদ undo কোনটি?

git commit --amend, তারপর push
git revert <commit>, তারপর সাধারণ push
git restore .
git reset --hard HEAD~1, তারপর git push --force

(কঠিন) Shared main-এ HEAD একটি merge commit. git revert --no-edit HEAD চালালে Git ২.৫৩ কী বলে, আর সঠিক command কোনটি?

error: commit … is a merge but no -m option was given. — git revert -m 1 HEAD
Error আসে — git revert -m 2 HEAD সবসময় ঠিক
fatal: cannot revert — merge কখনো revert করা যায় না
কোনো error নেই; দুই parent-এর বদলই উল্টে যায়

(মাঝারি) শেষ commit-এর শুধু বার্তা বদলাতে git commit --amend -m "নতুন বার্তা" চালানো হলো, কোনো ফাইল বদলায়নি। Commit ID-র কী হয়?

শুধু ID-র শেষ অক্ষর বদলায়
নতুন ID; পুরোনো commit object থেকে যায়, শুধু branch আর তাকে দেখায় না
ID একই, কারণ ফাইল বদলায়নি
পুরোনো commit সাথে সাথে মুছে যায়

(সহজ) git branch feature/x চালালে ভেতরে আসলে কী তৈরি হয়?

পুরো project-এর একটি কপি
একটি নতুন commit
একটি নতুন working folder
একটি ছোট ref, যাতে বর্তমান commit-এর hash লেখা — কোনো ফাইল কপি হয় না

(মাঝারি) main-এ থাকা অবস্থায় cart.txt-এ commit না করা বদল আছে, আর cart.txt main ও feature-এ আলাদা। git switch feature চালালে Git ২.৫৩ কী করে?

নিজে থেকে stash করে switch করে
Error দিয়ে থামে — “Your local changes … would be overwritten by checkout” — কিছুই বদলায় না
Switch করে, আর বদলগুলো feature-এ commit করে দেয়
Switch করে, আর অসংরক্ষিত বদল মুছে দেয়

(মাঝারি) Detached HEAD অবস্থায় একটি commit করে কোনো branch না বানিয়েই git switch main করেছেন। Commit-টি ফেরত আনার সঠিক উপায় কোনটি?

কিছু করার নেই — commit মুছে গেছে
git pull
git reflog থেকে hash নিয়ে git branch rescue <hash>
git revert HEAD

(মাঝারি) main-এ শুধু A → B, আর B থেকে খোলা feature-এ C → D; main-এ B-এর পরে কোনো commit নেই। main-এ থেকে git merge feature আর আলাদাভাবে git merge --no-ff feature দিলে কী পার্থক্য (যাচাই করা)?

প্রথমটি C আর D-কে main-এ নতুন ID-তে কপি করে
দ্বিতীয়টি error দেয়, কারণ fast-forward সম্ভব
দুটিই একই merge commit বানায়
প্রথমটি fast-forward — main শুধু D-তে সরে; দ্বিতীয়টি দুই parent-এর (B, D) একটি merge commit বানায়

(মাঝারি) একটি config ফাইলে merge base-এ limit = 10 আর অনেক নিচে fee = 5. ours করেছে শুধু fee = 7, theirs করেছে শুধু limit = 12. Three-way merge-এর ফল কী (যাচাই করা)?

limit = 10 আর fee = 7 — ours জেতে
limit = 12 আর fee = 7, কোনো conflict ছাড়া
Conflict, কারণ দুই পক্ষই ফাইল বদলেছে
limit = 12 আর fee = 5 — theirs জেতে

(সহজ) main-এ থেকে git merge hotfix দেওয়ার পরে ফাইলে দেখা গেল <<<<<<< HEAD / fee = 70 / ======= / fee = 50 / >>>>>>> hotfix. fee = 70 কোথা থেকে?

hotfix (theirs) থেকে
Merge base থেকে
Git-এর প্রস্তাবিত সমাধান
বর্তমান branch main (ours) থেকে

(মাঝারি) একটি branch fee() function-এর নাম deliveryFee() করল আর সব পুরোনো ডাক বদলাল; আরেক branch ফাইলের অন্য জায়গায় fee() ডাকে এমন নতুন function যোগ করল। Merge-এর সবচেয়ে সম্ভাব্য ফল?

Merge বাতিল হয়
Merge পরিষ্কার হয়, কিন্তু build বা test-এ প্রোগ্রাম ভাঙে — semantic conflict
Textual conflict হয়, কারণ function-এর নাম বদলেছে
Git নিজে নতুন ডাকটিও deliveryFee() করে দেয়

মডিউল ৩ — Git দিয়ে দলগত কাজ (২৫টি প্রশ্ন)

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ১৪–১৯

পর্ব ১৪ · Remote repository — fetch বনাম pull, ahead/behind, rejected push, divergent pull, --force-with-lease
পর্ব ১৫ · Rebase — replay আর নতুন hash, rebase-এ ours/theirs, todo list, --onto, ORIG_HEAD, সোনালি নিয়ম
পর্ব ১৬ · Pull request আর fork আর পর্ব ১৭ · Branching strategy — তিন merge পদ্ধতি, fork হালনাগাদ, Git Flow-এর hotfix, upstream first
পর্ব ১৮ · Commit, tag আর release আর পর্ব ১৯ · বড় repository — Conventional Commits থেকে SemVer, precedence, tag-এর ধরন, gitlink, shallow clone, LFS pointer

(সহজ) git fetch origin চালালে নিচের কোনটি বদলাতে পারে?

শুধু object database আর origin/… remote-tracking ref
Remote-এর branch
বর্তমান branch আর working tree-র ফাইল
Staging area

(মাঝারি) রহিমের git status বলছে [ahead 3], অথচ git push “rejected (fetch first)” দিল। Fetch-এর পরে status দেখাল [ahead 3, behind 1] (যাচাই করা)। কেন প্রথমবার “behind” দেখায়নি?

Push আসলে সফল হয়েছিল
ahead/behind-এর তুলনা হয় local origin/main-এর সাথে, যা fetch-এর আগে পুরোনো ছিল
Git সরাসরি server দেখে, কিন্তু server ধীর ছিল
সহকর্মী force push করেছিলেন

(কঠিন) origin/main = D, যেখানে A ← B ← C ← D. Local main = Z, যেখানে C ← X ← Y ← Z (C থেকে শাখা)। git rev-list --left-right --count main...origin/main-এর ফল কী (যাচাই করা)?

4 2
1 3
3 1 — local ৩টি এগিয়ে (X, Y, Z), ১টি পিছিয়ে (D)
3 4

(মাঝারি) দুই পথ আলাদা হয়ে গেছে, আর pull.rebase বা pull.ff কোনোটিই সেট নেই (system config-ও নয়)। Git ২.৫৩-এ শুধু git pull দিলে কী হয় (যাচাই করা)?

“You have divergent branches…” hint দিয়ে fatal: Need to specify how to reconcile divergent branches.
নীরবে rebase করে
Remote-এর commit মুছে local রাখে
নীরবে merge commit বানায়

(মাঝারি) রহিম নিজের feature branch-এর শেষ commit amend করেছেন, কিন্তু এর মধ্যে fetch করেননি; আর সহকর্মী সেই branch-এ একটি commit push করেছেন। রহিম git push --force-with-lease দিলে কী হয় (যাচাই করা)?

Push সফল, সহকর্মীর commit মুছে যায়
Git দুটি commit নিজে merge করে push করে
“Everything up-to-date”
! [rejected] … (stale info) — সহকর্মীর commit রক্ষা পায়

(মাঝারি) Local main-এ X, Y, Z (তিনটি নিজের commit) আর remote-এ একটি নতুন D. git pull --rebase-এর পরে ইতিহাস কেমন (যাচাই করা)?

একটি merge commit, যার parent Z আর D
D বাদ পড়ে, X Y Z থাকে
… C ← D ← X′ ← Y′ ← Z′ — নিজের তিন commit D-এর ওপর নতুন ID-তে
X, Y, Z একটি commit-এ মিশে যায়

(কঠিন) feature-এ দাঁড়িয়ে git rebase main-এ conflict হলো। তখন git checkout --ours k.txt আর --theirs k.txt কোন সংস্করণ দেয় (যাচাই করা)?

--ours = main-এর (নতুন base), --theirs = feature-এর replay হওয়া commit
দুটিই main-এর
--ours = feature-এর, --theirs = main-এর
Rebase চলাকালে --ours/--theirs কাজ করে না

(মাঝারি) Interactive rebase-এ চারটি commit — Add A, Add B, Add C, Add D — এর todo list বদলে লেখা হলো: pick A, fixup B, pick C, drop D. সফল হলে নতুন ইতিহাসে কী থাকে (যাচাই করা)?

দুটি commit — “Add A” (A আর B-র বদল মিলিয়ে) আর “Add C”; D-র ফাইল নেই
দুটি commit — “Add B” আর “Add C”
তিনটি commit — “Add A”, “Add B”, “Add C”
চারটি commit, শুধু D-র বার্তা মুছে যায়

(কঠিন) main: A ← B ← C. topic: B ← D ← E. fix: E ← F ← G. git rebase --onto main topic fix-এর পরে fix-এর ইতিহাস কী (যাচাই করা)?

A ← B ← C ← G′ — শুধু শেষ commit
A ← B ← C ← D′ ← E′ ← F′ ← G′
A ← B ← D ← E ← F ← G — কিছুই বদলায় না
A ← B ← C ← F′ ← G′ — শুধু F আর G replay হয়

(সহজ) নিচের কোন পরিস্থিতিতে rebase করা সবচেয়ে বিপজ্জনক?

নিজের PR branch, শুধু আপনি push করেন
Review-এর আগে নিজের fixup commit মেলানো
দলের shared main, যার commit অন্যরা ইতিমধ্যে pull করেছেন
নিজের local branch, যা কখনো push হয়নি

(মাঝারি) একটি rebase শেষ হওয়ার ঠিক পরে বুঝলেন ফল ভুল, আর এর মধ্যে আর কোনো command চালাননি। আগের অবস্থায় ফেরার সরাসরি উপায়?

git pull
git revert HEAD
git reset --hard ORIG_HEAD
git rebase --abort

(সহজ) Pull request সম্পর্কে কোনটি সঠিক?

এটি শুধু fork থেকে খোলা যায়
এটি hosting platform-এর সুবিধা; branch আর commit Git-এর, আলোচনা ও review platform-এর
এটি git pull command-এর একটি option
Merge-এর সময় এটি সব commit squash করতে বাধ্য করে

(মাঝারি) PR-এর branch-এ দুটি commit P1, P2. কোন merge পদ্ধতিতে P1 আর P2-এর আসল hash main-এর history-তে অপরিবর্তিত থাকে?

Merge commit (git merge --no-ff)
Rebase and merge
তিনটিতেই hash একই থাকে
Squash and merge

(কঠিন) git merge --squash feat, তারপর git commit. এরপর git branch -d feat চালালে কী হয় (যাচাই করা)?

Squash commit উল্টে যায়
branch নিরাপদে মুছে যায়
“error: the branch 'feat' is not fully merged” — squash commit-এর একটিই parent
feat-এর commit-গুলোও main থেকে মুছে যায়

(মাঝারি) Fork workflow-এ আপনার clone-এ দুটি remote: origin (আপনার fork) আর upstream (মূল project). Local main-কে upstream-এর সাথে নিরাপদে হালনাগাদ করার প্রচলিত ক্রম কোনটি?

git clone করে নতুন করে শুরু
git pull origin main
git push upstream main
git fetch upstream, git switch main, git merge --ff-only upstream/main, git push origin main

(সহজ) Git Flow অনুযায়ী production-এর জরুরি bug-এর hotfix branch কোথা থেকে খোলা হয় আর কোথায় merge হয় (কোনো release branch চালু নেই)?

main থেকে খুলে শুধু main-এ
develop থেকে খুলে main-এ
develop থেকে খুলে শুধু develop-এ
main থেকে খুলে main আর develop দুটিতেই

(মাঝারি) Trunk থেকে কাটা release/2.1-এ একটি bug পাওয়া গেল, যা trunk-এও আছে। Upstream-first নীতিতে সঠিক পথ কোনটি?

আগে trunk-এ fix, তারপর git cherry-pick -x দিয়ে release/2.1-এ
শুধু release/2.1-এ fix, পরে release branch trunk-এ merge
শুধু release/2.1-এ fix
Trunk-এ fix, আর release/2.1 মুছে নতুন করে কাটা

(মাঝারি) একটি সরল মডেলে দুই branch প্রতিদিন সমান সংখ্যক এলোমেলো লাইন বদলায়, আর প্রত্যাশিত সংঘর্ষ branch-এর আয়ুর বর্গের সমানুপাতিক। আয়ু ২ দিন থেকে ৫ দিন হলে প্রতি merge-এ সংঘর্ষ কত গুণ?

২৫ গুণ
৩ গুণ
৬.২৫ গুণ
২.৫ গুণ

(মাঝারি) একটি library-র শেষ release 1.4.2. এরপর দুটি commit: feat(api): add paging আর fix(api): handle null id; কোনোটিতে ! বা BREAKING CHANGE নেই। Conventional Commits আর SemVer 2.0.0 মেনে পরের version?

2.0.0
1.4.3
1.5.2
1.5.0

(কঠিন) SemVer 2.0.0-এর precedence অনুযায়ী কোন ক্রমটি ছোট থেকে বড়?

1.0.0-beta.11 < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0
1.0.0-rc.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0
1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
1.0.0 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1

(মাঝারি) git tag v1.0.0 আর git tag -a v1.1.0 -m "Release 1.1.0"-এর পরে তিনটি commit. git cat-file -t v1.0.0, git cat-file -t v1.1.0 আর git describe কী ছাপে (যাচাই করা)?

tag, commit, আর error
commit, tag, আর v1.1.0-3-g…
commit, commit, আর v1.0.0-3-g…
tag, tag, আর v1.1.0

(সহজ) একটি annotated tag বানিয়ে শুধু git push origin main দেওয়া হলো। Remote-এ tag পৌঁছায় কি (যাচাই করা)?

শুধু lightweight tag যায়
হ্যাঁ, সব tag স্বয়ংক্রিয়ভাবে যায়
Tag push করা যায় না
না — tag আলাদা করে git push origin v2.0.0 বা --follow-tags দিয়ে পাঠাতে হয়

(মাঝারি) একটি superproject-এ libs/ui একটি submodule. Superproject-এর commit-এর tree-তে এর জন্য কী থাকে (যাচাই করা)?

Mode 160000-এর একটি entry, ধরন commit, আর submodule-এর একটি commit hash (gitlink)
Submodule-এর branch-এর নাম
কিছুই না; সব তথ্য শুধু .gitmodules-এ
Submodule-এর সব ফাইলের blob

(মাঝারি) একটি local folder থেকে git clone --depth 1 super shallow1 (সাধারণ path, URL নয়) চালালে Git ২.৫৩ কী করে (যাচাই করা)?

নীরবে shallow clone বানায়
Error দিয়ে থামে
শুধু সর্বশেষ ফাইল কপি করে, .git ছাড়া
“warning: --depth is ignored in local clones; use file:// instead.” — পূর্ণ clone

(মাঝারি) .gitattributes-এ *.psd filter=lfs diff=lfs merge=lfs -text আর Git LFS চালু। ৩,০০,০০০ byte-এর banner.psd commit করার পর git cat-file -p HEAD:banner.psd কী দেখায় (যাচাই করা)?

Error, কারণ binary ফাইল Git-এ রাখা যায় না
ফাইলের পুরো binary বিষয়বস্তু
তিন লাইনের pointer — version https://git-lfs.github.com/spec/v1, oid sha256:…, size 300000
একটি SHA-1 hash, এক লাইনে

৪ · মডিউল ৪ — Requirement engineering (২১টি প্রশ্ন)

এখানে প্রশ্ন আসে শ্রেণিবিভাগ থেকে (FR, NFR, constraint, design), লেখার মান থেকে (EARS, shall, মাপা যায় কি না) আর অগ্রাধিকারের হিসাব থেকে (RICE, Kano). “কী” বনাম “কীভাবে” আলাদা করতে পারাই অর্ধেক নম্বর।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ২০–২৪

পর্ব ২০ · Requirement engineering — সাত কাজ, power/interest grid, observation আর tacit knowledge, payback
পর্ব ২১ · Functional আর non-functional — constraint, EARS-এর ছাঁচ, shall/should, nearest-rank percentile, fit criterion
পর্ব ২২ · Use case আর user story আর পর্ব ২৩ · Requirement modeling — INVEST, Scenario Outline, «include»/«extend», multiplicity, DFD আর join
পর্ব ২৪ · Requirement management — RICE, Kano, volatility, traceability, scope creep বনাম gold-plating

(সহজ) Pressman-এর তালিকায় requirement engineering-এর সাতটি কাজের সঠিক ক্রম কোনটি?

Specification → elicitation → inception → validation → negotiation → elaboration → management
Inception → specification → management → elicitation → negotiation → validation → elaboration
Inception → elicitation → elaboration → negotiation → specification → validation → management
Elicitation → inception → specification → elaboration → management → validation → negotiation

(মাঝারি) একটি ফার্মেসি-অ্যাপের power/interest grid-এ ফার্মাসিস্টের project-এর সিদ্ধান্তে ক্ষমতা কম, কিন্তু প্রতিদিন ব্যবহার করবেন বলে আগ্রহ খুব বেশি। প্রচলিত কৌশল কোনটি?

Keep informed — নিয়মিত interview, prototype পরীক্ষা আর হালনাগাদ খবর
Monitor — ন্যূনতম যোগাযোগ
Keep satisfied
Manage closely

(মাঝারি) একটি project-এ শুরুতে ৳১৫ লাখ বিনিয়োগ, আর পরের বছরগুলোতে প্রতি বছর ৳৬ লাখ নিট লাভ। টাকার সময়-মূল্য বাদ দিয়ে সাধারণ payback period কত?

০.৪ বছর
২.৫ বছর
৯ বছর
৩ বছর

(মাঝারি) একজন অভিজ্ঞ কর্মী interview-এ নিজের কাজের ধারা পরিষ্কার বলতে পারছেন না, কারণ কাজটি তাঁর অভ্যাসে চলে। এই tacit knowledge বের করতে সবচেয়ে উপযোগী কৌশল?

Observation বা job shadowing
পুরোনো SRS পড়া
Closed প্রশ্নের দীর্ঘ প্রশ্নপত্র
অনলাইন survey

(সহজ) নিচের কোন বাক্যটি requirement নয়, বরং design-এর সিদ্ধান্ত?

৩ সেকেন্ডের মধ্যে অনুমোদনের পাতা খুলবে
ফার্মাসিস্ট অনুমোদন না দিলে prescription-এর ওষুধ বিক্রি হবে না
প্রতিটি অনুমোদনে অনুমোদনকারীর নাম ও সময় রেকর্ড থাকবে
Order টেবিলে approved_by নামের একটি কলাম থাকবে

(সহজ) একটি হাসপাতাল-অ্যাপের requirement: “অ্যাপটি হাসপাতালের বিদ্যমান PostgreSQL database ব্যবহার করবে।” এটি সাধারণত কোন শ্রেণিতে পড়ে?

Functional requirement
User story
Design ও implementation constraint
Performance requirement

(মাঝারি) “While the exam portal is in maintenance mode, the system shall display the maintenance notice.” — EARS-এর কোন ছাঁচ?

Unwanted behaviour (If…then)
State-driven (While)
Optional feature (Where)
Event-driven (When)

(মাঝারি) একটি load test-এ ৪০০টি response time মাপা হয়েছে। Nearest-rank পদ্ধতিতে p95 সাজানো তালিকার কততম মান?

৩৮১তম
৩৯৫তম
৩৮০তম
২০তম

(সহজ) “The system should be user-friendly.” — এই requirement-এর প্রধান সমস্যা কী?

এতে কোনো design constraint নেই
“should” বাধ্যতামূলক নয়, আর “user-friendly” মাপা যায় না
এটি functional requirement-এর মতো লেখা
এটি বড্ড ছোট বাক্য

(সহজ) INVEST-এ “E” কোন গুণ বোঝায়?

Essential
Epic
Executable
Estimable — দল আকার আন্দাজ করতে পারে

(মাঝারি) “As a developer, I want a payments table in the database, so that the API can save data.” — INVEST অনুযায়ী প্রধান সমস্যা কী?

ব্যবহারকারীর কাছে সরাসরি মূল্য নেই — এটি একটি task, Valuable নয়
এটি Negotiable নয়, কারণ কোনো role নেই
এটি Testable নয়, কারণ table বানানো যাচাই করা যায় না
এটি বড্ড বড়, তাই Small নয়

(মাঝারি) একটি Gherkin Scenario Outline-এর Examples টেবিলে একটি header সারি আর ৬টি data সারি। মোট কতটি আসল scenario চলবে?

৭
৬ × ধাপের সংখ্যা
৬
১

(মাঝারি) Use case diagram-এ “প্রিয় নম্বর সেভ করা” শুধু গ্রাহক চাইলে “মোবাইল রিচার্জ করা”-র শেষে যোগ হয়, আর base use case এটির কথা জানে না। কোন সম্পর্ক আর ড্যাশ তীর কোন দিকে?

«extend» — প্রিয় নম্বর থেকে রিচার্জের দিকে
«extend» — রিচার্জ থেকে প্রিয় নম্বরের দিকে
Generalization — নিরেট রেখা, ফাঁপা ত্রিভুজ
«include» — রিচার্জ থেকে প্রিয় নম্বরের দিকে

(মাঝারি) একটি domain model-এ Customer আর Order-এর association-এ Customer প্রান্তে 1 আর Order প্রান্তে 0..*. অর্থ কী?

Customer না থাকলেও Order থাকতে পারে
একটি Order-এর অনেক Customer থাকতে পারে
প্রতিটি Customer-এর ঠিক একটি Order
প্রতিটি Order ঠিক একজন Customer-এর; একজন Customer-এর শূন্য বা অনেক Order

(মাঝারি) একটি activity diagram-এ fork-এ দুটি সমান্তরাল পথ, তারপর একটি join. Merge আর join-এর পার্থক্য হিসেবে কোনটি সঠিক?

Join শুধু swimlane পার হওয়ার জন্য
Merge সব পথের অপেক্ষা করে, join করে না
Join সব আগত পথ শেষ হওয়ার অপেক্ষা করে; merge যেকোনো একটি এলেই এগোয়
দুটি একই — শুধু আঁকার ধরন আলাদা

(সহজ) একটি data flow diagram-এ নিচের কোনটি নিয়মবিরুদ্ধ?

একটি data store থেকে আরেকটি data store-এ সরাসরি flow
External entity থেকে process-এ flow
Data store থেকে process-এ flow
Process থেকে data store-এ flow

(মাঝারি) একটি feature-এর reach প্রতি quarter-এ ২,০০০ জন, impact ২, confidence ৭৫%, effort ৫ person-month. RICE স্কোর কত?

১৫,০০০
৬০০
২,০০৭.৭৫
৮০০

(মাঝারি) একটি backlog-এর শুরুতে ৪০টি requirement. এক মাসে ৪টি যোগ, ২টি বাদ আর ৬টি বদলানো হলো। Volatility = (যোগ + বাদ + বদল) ÷ শুরুর মোট ধরলে কত?

৩০%
১৫%
১০%
২৫%

(সহজ) কোনো গ্রাহক চাননি, তবু একজন developer নিজে থেকে app-এ dark mode আর animation যোগ করলেন। এটি কী?

Scope creep
Delighter (Kano)
Gold-plating
Requirement volatility

(মাঝারি) একটি traceability matrix-এ দেখা গেল test T9-এর সাথে কোনো requirement যুক্ত নেই। কোন যাচাইয়ে এটি ধরা পড়ে, আর T9-কে কী বলে?

Validation — acceptance test
Forward traceability — gold-plating
Backward traceability — orphan test
Baseline — change request

(মাঝারি) Kano প্রশ্নপত্রে একজন গ্রাহক বললেন — feature থাকলে: “এমনিতেই প্রত্যাশিত”, না থাকলে: “খারাপ লাগবে”। Feature-টি তাঁর কাছে কোন শ্রেণির?

Indifferent
Must-be (basic)
Attractive (delighter)
One-dimensional (performance)

৫ · মডিউল ৫ — Design-এর নীতি আর UML (২৩টি প্রশ্ন)

এই অংশে ছোট কোড দেখে নীতি চেনা আর UML-এর চিহ্ন পড়া। কোডের প্রশ্নে জিজ্ঞেস করুন “নতুন কিছু যোগ করলে কোথায় কোথায় হাত দিতে হবে”; UML-এ আগে রেখার ধরন (নিরেট না ড্যাশ), তারপর মাথার চিহ্ন (ত্রিভুজ, হীরা, খোলা তীর)।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ২৫–৩১

পর্ব ২৫ · Coupling আর cohesion আর পর্ব ২৬ · নকশার নীতি — স্তরের ক্রম, I/A/D, LCOM4, DRY-এর আসল অর্থ, Law of Demeter, CQS, YAGNI
পর্ব ২৭ · SOLID ১ আর পর্ব ২৮ · SOLID ২ — actor ধরে SRP, type-switch আর OCP, Rectangle-Square, ISP-এর হিসাব, DIP ≠ DI
পর্ব ২৯ · UML class diagram আর পর্ব ৩০ · UML behaviour diagram — হীরা আর ত্রিভুজ, visibility, association বনাম dependency, message-এর তীর, self-transition-এর ক্রম
পর্ব ৩১ · Interface আর contract — precondition কার দায়, python -O আর assert

(সহজ) Coupling-এর ক্লাসিক স্তরগুলো খারাপ থেকে ভালো ক্রমে কোনটি?

Content → common → external → control → stamp → data
Common → content → control → data → stamp → external
Control → content → common → stamp → external → data
Data → stamp → control → external → common → content

(মাঝারি) def send_report(student): sms(student.phone) — function পুরো student object নেয়, কিন্তু ব্যবহার করে শুধু phone. এটি কোন coupling?

Control coupling
Stamp coupling
Content coupling
Data coupling

(মাঝারি) একটি startup() function database খোলে, SMS template লোড করে আর print queue খালি করে — শুধু কারণ তিনটিই প্রোগ্রাম শুরুর সময় দরকার। এর cohesion কোন স্তরের?

Coincidental
Functional
Sequential
Temporal

(কঠিন) একটি package-এর ওপর ৩টি package নির্ভর করে (Ca = 3), আর এটি নিজে ১টির ওপর নির্ভর করে (Ce = 1). এর ৮টি class-এর ২টি abstract. Martin-এর সূত্রে I, A আর D কত?

I = 0.25, A = 0.25, D = 0.5
I = 0.75, A = 0.25, D = 0
I = 0.25, A = 0.25, D = 1.5
I = 3, A = 4, D = 6

(কঠিন) একটি class-এ চারটি method: a() আর b() field x ব্যবহার করে; c() ব্যবহার করে y; d() ব্যবহার করে z আর ভেতরে c()-কে ডাকে। LCOM4 (field ভাগ বা ডাক থাকলে method যুক্ত) কত?

(মাঝারি) একটি app-এ “৮০০ টাকার বেশি অর্ডারে ১০% ছাড়” (মার্কেটিংয়ের নিয়ম) আর “৮০০ টাকার বেশি অর্ডারে delivery ফ্রি” (delivery বিভাগের নিয়ম)। দুটিকে একটি THRESHOLD = 800-এ জোড়া লাগানো নিয়ে কোনটি সঠিক?

ঠিক — কারণ YAGNI বলে একটিই constant রাখতে
ভুল — এটি কাকতালীয় duplication; দুটি আলাদা কারণে বদলায়
এতে কিছু আসে যায় না, দুটির ফল সবসময় এক
ঠিক — DRY মানে কোনো সংখ্যা দুবার লেখা যাবে না

(সহজ) নিচের কোনটি Law of Demeter ভাঙার সবচেয়ে স্পষ্ট উদাহরণ (সব object সাধারণ business object)?

total = sum(prices)
builder.name("Rahim").phone("01…").build()
order.customer.wallet.balance -= total
order.charge(total)

(মাঝারি) একটি loyalty card-এর get_points() প্রতিবার ডাকলে ১০ point fee কেটে নতুন মান ফেরত দেয়। Program প্রথমে log-এ get_points() ছাপে, তারপর get_points() >= 85 যাচাই করে। শুরুতে ১০০ point থাকলে যাচাইয়ের সময় কত দেখা যাবে, আর কোন নীতি ভাঙা?

১০০ — Law of Demeter
৮০ — command–query separation
৯০ — single responsibility
৮০ — DRY

(সহজ) একটি দলে একটিই SMS সরবরাহকারী, অন্য কোনোটির পরিকল্পনা নেই। তবু একজন developer abstract provider interface, factory আর plugin loading বানালেন “যদি পরে লাগে”। এটি প্রধানত কোন নীতির বিরুদ্ধে?

YAGNI
Liskov substitution
Open-closed principle
DRY

(মাঝারি) Robert C. Martin-এর Clean Architecture (২০১৭)-এ SRP-এর ভাষা কোনটির সবচেয়ে কাছে?

একটি class শুধু একটি method রাখবে
একটি function শুধু একটি কাজ করবে
একটি module-এর দায় থাকবে একটি, এবং কেবল একটি, actor-এর কাছে
একটি module কখনো বদলাবে না

(মাঝারি) নিচের Python কোডে কোন SOLID নীতি সবচেয়ে স্পষ্টভাবে ভাঙছে?
def fee(c):
  if c.kind == "bike": return 60
  elif c.kind == "van": return 150
  elif c.kind == "drone": return 300
— একই শৃঙ্খল আরও তিনটি function-এ আছে, আর প্রায় প্রতি মাসে নতুন kind আসে।

Interface segregation principle
Dependency inversion principle
Liskov substitution principle
Open-closed principle

(মাঝারি) class Square(Rectangle) — দুটি setter-ই দুই বাহু সমান করে। একটি test: set_width(4), set_height(5), তারপর area() == 20. Square-এ ফল কী, আর কেন?

পাস — ক্ষেত্রফল ২০
ফেল — ক্ষেত্রফল ১৬
Error — Square-এ set_width নেই
ফেল — ক্ষেত্রফল ২৫; Rectangle-এর setter-এর postcondition (অন্য বাহু অপরিবর্তিত) ভেঙেছে

(মাঝারি) Base class-এর ship(order) যেকোনো ওজনের অর্ডার নেয় আর ৫ দিনের মধ্যে পৌঁছানোর প্রতিশ্রুতি দেয়। কোন subclass LSP মানে?

শুধু ১০ কেজির কম নেয়, ২ দিনে পৌঁছায়
যেকোনো ওজন নেয়, আর ৩ দিনের মধ্যে পৌঁছায়
যেকোনো ওজন নেয়, কিন্তু ভারী হলে নতুন একটি exception ছোড়ে
যেকোনো ওজন নেয়, ৭ দিনে পৌঁছায়

(মাঝারি) class OrderService: def __init__(self, repo: MySQLRepository) — আর OrderService-এর ফাইল mysql module import করে। কোনটি সঠিক?

Dependency injection আছে, কিন্তু dependency inversion নেই
দুটির কোনোটিই নেই
DIP আছে, DI নেই
DIP আর DI দুটিই আছে

(মাঝারি) একটি interface-এ ৬টি method. দুটি client যথাক্রমে ২টি আর ৩টি method ব্যবহার করে। Client-দের মোট অপ্রয়োজনীয় নির্ভরতা কত, আর কোন নীতি এ নিয়ে কথা বলে?

১২ — open-closed principle
৭ — interface segregation principle
৫ — interface segregation principle
৭ — single responsibility principle

(সহজ) একটি class diagram-এ Bus আর Seat-এর রেখায় Bus প্রান্তে ভরাট হীরা আর 1, Seat প্রান্তে 1..*. অর্থ কী?

Dependency — Bus শুধু মাঝে মাঝে Seat ব্যবহার করে
Generalization — Seat হলো Bus-এর একটি রূপ
Composition — প্রতিটি আসন ঠিক একটি বাসের অংশ; বাস মুছলে আসনও মোছে
Aggregation — আসন অন্য বাসের সাথে ভাগ হতে পারে

(মাঝারি) Class diagram-এ WalletPayment থেকে «interface» PaymentMethod-এর দিকে ড্যাশ রেখা, PaymentMethod প্রান্তে ফাঁপা ত্রিভুজ। Java-তে এর রূপ?

class PaymentMethod implements WalletPayment
class WalletPayment extends PaymentMethod
class WalletPayment { PaymentMethod m; }
class WalletPayment implements PaymentMethod

(সহজ) UML class diagram-এ attribute লেখা # fare : Money [0..1]. অর্থ কী?

fare protected; মান না-ও থাকতে পারে, থাকলে একটি Money
fare private; ঠিক একটি Money
fare static; সর্বোচ্চ ১ টাকা
fare package-visible; Money-র একটি list

(মাঝারি) Java: class Trip { private Bus bus; } আর class FareCalc { int fare(Trip t) { … } } — FareCalc-এ কোনো field নেই। Class diagram-এ কী আঁকবেন?

দুটিই association
দুটিই dependency
Trip আর Bus-এর মাঝে composition
Trip → Bus association, আর FareCalc থেকে Trip-এ ড্যাশ রেখার dependency

(সহজ) UML sequence diagram-এ ভরাট মাথার সরল তীর, খোলা মাথার সরল তীর আর ড্যাশ রেখার তীর — যথাক্রমে কী?

Synchronous message, asynchronous message, reply
Reply, synchronous, asynchronous
Synchronous, reply, destroy
Asynchronous, synchronous, create

(কঠিন) State S-এ entry / a আর exit / b. S থেকে S-এ একটি self-transition e / c আছে (internal transition নয়)। S-এ থাকা অবস্থায় e এলে কোন ক্রমে কাজ চলে?

a, c, b
b, c, a
শুধু c
c, b, a

(মাঝারি) withdraw(amount)-এর precondition amount > 0, postcondition balance = old balance − amount. একটি ডাকে amount = −৫০ দেওয়ায় precondition মিথ্যা। Design by contract অনুযায়ী bug কোথায়?

ডাকার পক্ষে (caller)
withdraw-এর ভেতরে (supplier)
কারও দোষ নেই, এটি প্রত্যাশিত ব্যর্থতা
Class invariant-এ

(মাঝারি) একটি Python function ব্যবহারকারীর দেওয়া ছাড়ের হার যাচাই করে assert 0 <= pct <= 100 দিয়ে। Server-এ python -O app.py চালালে pct = 150 এলে কী হয়?

pct নিজে থেকে ১০০-তে আটকে যায়
AssertionError আসে
Python চালু হতে অস্বীকার করে
Assert বাদ পড়ে, কোনো check হয় না — ১৫০% দিয়েই হিসাব চলে

৬ · মডিউল ৬ — Design pattern (২২টি প্রশ্ন)

Pattern-এর প্রশ্নে নামের চেয়ে উদ্দেশ্য বড়: interface বদলায় (adapter), একই রেখে যোগ করে (decorator), প্রবেশ নিয়ন্ত্রণ করে (proxy), সহজ দরজা দেয় (facade). কাছাকাছি গঠনের জোড়ায় জিজ্ঞেস করুন — “কে বদলায়, কখন জোড়া হয়?”

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৩২–৩৭

পর্ব ৩২ · Design pattern কী আর পর্ব ৩৩ · Creational pattern — ৫/৭/১১-এর বণ্টন, golden hammer, Factory Method বনাম Abstract Factory, shallow copy, Singleton-এর দাম
পর্ব ৩৪ · Structural pattern — decorator-এর ক্রম, composite-এর হিসাব, Bridge-এর m + n, proxy বনাম decorator
পর্ব ৩৫ · Behavioral pattern ১ আর পর্ব ৩৬ · Behavioral pattern ২ — undo/redo-র দুই stack, lapsed listener, State বনাম Strategy, middleware, visitor-এর দুর্বলতা
পর্ব ৩৭ · Dependency injection আর composition — captive dependency, fragile base class

(সহজ) Gang of Four-এর ১৯৯৪ সালের বইয়ের ২৩টি pattern-এর পরিবারভিত্তিক বণ্টন কোনটি?

Creational ৭, structural ৫, behavioral ১১
Creational ৮, structural ৮, behavioral ৭
Creational ৫, structural ৭, behavioral ১১
Creational ৫, structural ৯, behavioral ৯

(সহজ) নিচের কোনটি GoF-এর behavioral pattern নয়?

Observer
Template method
Visitor
Facade

(মাঝারি) একটি দল সদ্য Observer শিখে সব নতুন feature-এ — একটিমাত্র listener থাকলেও — subject, observer আর event class বসাচ্ছে। এটি কোন anti-pattern?

Lava flow
Service locator
God object
Golden hammer

(মাঝারি) নতুন কোড pay(order) আশা করে, কিন্তু একটি পুরোনো payment library দেয় makePayment(amount, currency), যা বদলানো যাবে না। কোন pattern?

Proxy
Adapter
Decorator
Facade

(মাঝারি) Factory Method আর Abstract Factory-র পার্থক্য কোনটি?

Factory Method সবসময় singleton ফেরত দেয়
Abstract Factory মানে abstract class-এর ভেতরে একটি static method
দুটি একই pattern-এর দুই নাম
Factory Method-এ subclass override করে একটি product ঠিক করে; Abstract Factory একটি object দিয়ে মিলে যাওয়া পুরো পরিবার বানায়

(কঠিন) একটি Abstract Factory-তে ৩টি concrete factory (SMS, email, push) আর ৩টি product-এর ধরন। কোন বদলে সবচেয়ে বেশি পুরোনো কোড খুলতে হয়?

একটি product-এর ভেতরের বাস্তবায়ন বদলানো
Client-কে অন্য factory দেওয়া
প্রতিটি পরিবারে চতুর্থ product-এর ধরন যোগ করা
চতুর্থ পরিবার (WhatsApp) যোগ করা

(মাঝারি) JavaScript: const a = { tags: ["x"] }; const b = { ...a }; b.tags.push("y"); b.n = 1; console.log(a.tags.length, a.n); — কী ছাপে?

1 undefined
2 undefined
2 1
1 1

(মাঝারি) দুটি test আলাদাভাবে পাস করে, একসাথে নির্দিষ্ট ক্রমে চালালে একটি ব্যর্থ। দুটিই Settings.instance() singleton পড়ে-লেখে। কারণ আর ভালো সমাধান?

দুটি test-কে একটি বড় test-এ মেলানো
Singleton thread-safe নয়
Test runner-এর bug
Singleton-এর অবস্থা এক test থেকে আরেকটিতে চুইয়ে পড়ে; settings constructor দিয়ে দেওয়া (DI)

(মাঝারি) Python-এ @a, তার নিচে @b, তার নিচে def f(): … — এটি কোন লাইনের সমান?

f = a(f) + b(f)
f = b(a(f))
f = a(b(f))
f = a(f); f = b(f)

(কঠিন) একটি অর্ডারের গাছ: বান্ডিল A-তে item ৩০০ আর বান্ডিল B; B-তে item ২০০ আর item ৪০০, B-তে ২০% ছাড়। A-তে ছাড় নেই। Composite-এর recursive total()-এ A-র মোট কত?

৭২০
৮২০
৭৮০
৯০০

(মাঝারি) ৫টি আকৃতি আর ৪টি rendering পদ্ধতি। প্রতিটি জোড়ার subclass বানালে কয়টি class, আর Bridge-এ কয়টি concrete class?

৯ আর ১
২০ আর ৯
২০ আর ২০
৯ আর ২০

(মাঝারি) Proxy আর Decorator — দুটিই একই interface রাখে আর ভেতরে একটি object ধরে। পার্থক্য কোথায়?

উদ্দেশ্যে: proxy প্রবেশ নিয়ন্ত্রণ করে (lazy, protection, remote, caching), decorator নতুন দায়িত্ব যোগ করে
Decorator শুধু Python-এ, proxy শুধু Java-তে
Proxy interface বদলায়, decorator রাখে
Decorator inheritance দিয়ে, proxy composition দিয়ে

(কঠিন) একটি editor-এ undo stack আর redo stack; নতুন command এলে redo stack খালি হয়। খালি text থেকে: run Insert(0,"ab"), run Insert(2,"c"), undo, run Insert(2,"x"), undo, redo. শেষে text কী?

ab
abcx
abx
abc

(মাঝারি) একটি page খোলার সময় দীর্ঘজীবী দামের feed-এ callback যোগ করে, বন্ধের সময় সরায় না। বারবার খোলা-বন্ধের ফল?

Garbage collector নিজে callback সরিয়ে দেয়
শ্রোতা জমতে থাকে — memory leak, আর বন্ধ page-ও প্রতিটি বদলে কাজ করে (lapsed listener)
Feed বন্ধ হয়ে যায়
নতুন callback আগেরটিকে বদলে দেয়

(মাঝারি) Strategy আর Template method — দুটিই algorithm-এর অংশ বদলায়। মূল পার্থক্য?

Strategy inheritance-ভিত্তিক, Template method composition-ভিত্তিক
দুটির মধ্যে কোনো পার্থক্য নেই
Template method চলার সময় বদলানো যায়, Strategy যায় না
Strategy composition দিয়ে, চলার সময় জোড়ে; Template method inheritance দিয়ে, class লেখার সময় বাঁধে

(মাঝারি) State আর Strategy-র class diagram প্রায় একই। মূল পার্থক্য?

State structural pattern, Strategy behavioral
State-এ object ঘটনার জবাবে নিজে অবস্থা বদলায়; Strategy বাইরে থেকে বেছে দেওয়া হয়
Strategy শুধু একবার ঠিক হয়, কখনো বদলায় না
State-এ interface নেই

(মাঝারি) Python-এ stock = {"rice": 5}, তারপর for k in stock: stock["oil"] = 2. কী ঘটে?

oil যোগ হয়, loop দুবার চলে
oil যোগ হয়, loop একবার চলে, কোনো error নেই
RuntimeError: dictionary changed size during iteration
অসীম loop

(মাঝারি) একটি Express-ধাঁচের server-এ একটি middleware কোনো শাখায় উত্তরও দেয় না, next()-ও ডাকে না। সেই অনুরোধের কী হয়?

ঝুলে থাকে, সাধারণত timeout পর্যন্ত
পরের middleware নিজে থেকে চলে
Server crash করে
Framework স্বয়ংক্রিয় ২০০ OK দেয়

(সহজ) ৬টি UI component প্রত্যেকে প্রত্যেকের সাথে সরাসরি কথা বললে কতগুলো যোগাযোগ-জোড়া, আর একটি mediator দিয়ে কয়টি?

১৫ আর ১
৩৬ আর ৬
৩০ আর ৬
১৫ আর ৬

(মাঝারি) একটি compiler-এর AST-তে ১২টি node type আর ৫টি visitor. Visitor pattern-এ কোন বদলে সবচেয়ে বেশি পুরোনো class খুলতে হয়?

নতুন visitor যোগ করা
Node-গুলোর ক্রম বদলানো
নতুন node type যোগ করা
একটি visitor-এর ভেতরের logic বদলানো

(মাঝারি) একটি web app-এর DI container-এ CartService scoped (প্রতি request-এ একটি) আর PriceCache singleton; PriceCache-এর constructor একটি CartService নেয়। সমস্যা কী?

Constructor injection এখানে নিষিদ্ধ
প্রতি request-এ নতুন PriceCache তৈরি হবে
কোনো সমস্যা নেই, container সব সামলায়
Captive dependency — প্রথম request-এর CartService singleton-এর ভেতরে আটকে পরের সব request-এ ভাগ হয়

(কঠিন) Base class-এ add(x) একটি উপাদান যোগ করে, আর add_all(xs) প্রতিটির জন্য self.add(x) ডাকে। Subclass দুটিই override করে: add-এ count += 1, add_all-এ count += len(xs), তারপর super()-এর method. নতুন object-এ add_all(["a", "b", "c"]) ডাকার পর count কত?

৭ · মডিউল ৭ — Architecture, clean code আর maintenance (২৩টি প্রশ্ন)

এখানে প্রশ্ন আসে নির্ভরতার দিক (layer, dependency rule, port), কোডের লক্ষণ (smell, flag argument) আর debt-এর অগ্রাধিকার থেকে। “কে কাকে চেনে” প্রশ্নটি architecture-এর প্রায় সব প্রশ্নের চাবি।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৩৮–৪৪

পর্ব ৩৮ · Software architecture আর পর্ব ৩৯ · MVC, MVP আর MVVM — quality scenario-র ছয় অংশ, strict বনাম relaxed, ADR, classic MVC, pure reducer
পর্ব ৪০ · Clean আর hexagonal architecture — driving বনাম driven adapter, dependency rule, aggregate, bounded context
পর্ব ৪১ · Clean code আর পর্ব ৪২ · Code smell আর refactoring — flag argument, guard clause, magic number, feature envy, shotgun surgery
পর্ব ৪৩ · Technical debt আর legacy code আর পর্ব ৪৪ · Code review — Fowler-এর চতুর্ভুজ, hotspot, ISO/IEC 14764, sprout method, মন্তব্যের লেবেল

(মাঝারি) একটি quality attribute scenario: “ঈদের আগের ভিড়ে একটি app server হঠাৎ বন্ধ হলো; বাকি server ৩০ সেকেন্ডের মধ্যে সব অনুরোধ নেবে।” “৩০ সেকেন্ডের মধ্যে” কোন অংশ?

Response measure
Artifact
Stimulus
Environment

(মাঝারি) চার স্তরের app: 4 presentation, 3 application, 2 domain, 1 data. Presentation-এর একটি module সরাসরি data স্তরের (1) একটি module ডাকে। কোনটি ঠিক?

Strict-এ অনুমোদিত, relaxed-এ নিষিদ্ধ
দুই ধরনেই অনুমোদিত
দুই ধরনেই নিষিদ্ধ
Strict layering-এ নিষিদ্ধ, relaxed-এ অনুমোদিত

(মাঝারি) Michael Nygard-এর ২০১১ সালের ADR ছাঁচের অংশ নয় কোনটি?

Context
Cost estimate (খরচের হিসাব)
Status
Consequences

(মাঝারি) একটি ADR-এর সিদ্ধান্ত পরে বদলাল। প্রচলিত রীতি কোনটি?

পুরোনো ADR ফাইল মুছে ফেলা
কিছুই না; ADR একবার লেখার জিনিস
পুরোনো ADR-এর decision অংশ মুছে নতুন লেখা
নতুন ADR লেখা, আর পুরোনোটির শুধু status “superseded by …” করা

(মাঝারি) Classic (Smalltalk-ধাঁচের) MVC-তে model বদলালে view কীভাবে জানে?

View নির্দিষ্ট সময় পরপর model পড়ে
Controller প্রতিবার view-কে নতুন মান পাঠায়
Data binding দিয়ে
Model নিবন্ধিত view-দের খবর দেয় (observer), view নিজে model পড়ে

(মাঝারি) একটি MVVM অ্যাপের ResultViewModel ফাইলে কোনটি থাকা সবচেয়ে বড় নকশাগত ভুল?

document.querySelector("#gpa").textContent = gpa
this.isPassed = this.gpa >= 2.0
this.save = () => service.save(this.marks)
this.gpa = computeGpa(marks)

(মাঝারি) Redux-ধাঁচের reducer হিসেবে কোনটি সঠিক?

(s, a) => ({ ...s, items: [...s.items, a.item] })
(s, a) => ({ ...s, at: Date.now() })
(s, a) => { fetch("/save"); return s; }
(s, a) => { s.items.push(a.item); return s; }

(মাঝারি) Hexagonal architecture-এ core-এর PaymentPort interface একটি WalletApi class বাস্তবায়ন করে, আর use case charge() ডাকে। WalletApi কোন ধরনের adapter?

Entity
Driven (secondary) adapter
Use case
Driving (primary) adapter

(কঠিন) Clean Architecture-এর বৃত্ত ভেতর থেকে বাইরে: entities (০), use cases (১), interface adapters (২), frameworks (৩)। কোন import dependency rule ভাঙে?

PlaceOrder use case (১) → SmsGateway adapter (২)
OrderController (২) → PlaceOrder (১)
PlaceOrder (১) → Order entity (০)
Web framework-এর route (৩) → OrderController (২)

(মাঝারি) একটি Order aggregate-এর invariant: মোট দাম ≤ credit limit ২০০০ টাকা। বর্তমান মোট ১৫০০। একটি command ৬০০ টাকার নতুন line যোগ করতে চায়। ভালো নকশার aggregate কী করবে?

Line যোগ করে limit বাড়িয়ে দেবে
Repository-কে সিদ্ধান্ত নিতে দেবে
Line যোগ করে, পরে একটি background job ঠিক করবে
বদলের আগেই ২১০০ হিসাব করে command প্রত্যাখ্যান, অবস্থা অপরিবর্তিত

(মাঝারি) বিক্রয় বিভাগের কাছে “product” মানে ছবি, দাম, বিবরণ; গুদামের কাছে তাক নম্বর, ওজন, মজুত। DDD-র সবচেয়ে উপযুক্ত নকশা?

একটি বিশাল Product class, সব field-সহ
দুটি bounded context — Sales আর Warehouse-এ আলাদা Product model, একই id দিয়ে যুক্ত
গুদামের দিক বাদ দেওয়া
Product-কে value object বানানো

(সহজ) কোডে render(report, True) — দ্বিতীয় parameter সত্য হলে PDF, মিথ্যা হলে HTML. মূল সমস্যা?

Parameter বেশি
True বড় হাতের অক্ষরে
Function-এর নাম বড্ড ছোট
Flag argument — call site-এ True-র অর্থ বোঝা যায় না, আর function দুটি কাজ করে

(মাঝারি) if (a) { if (b) { if (c) { doWork(); } } } — a, b, c তিনটিই পূর্বশর্ত। Guard clause-এ বদলালে (if (!a) return; ইত্যাদি) doWork() কত গভীর nesting-এ থাকবে?

৩
০ — কোনো ব্লকের ভেতরে নয়
১
২

(কঠিন) fee = months * 2500; if (months > 6) fee -= 500; if (late) fee += 500;. একজন developer ছাড়ের অঙ্ক কমাতে find-and-replace-এ সব “500” বদলে “200” করলেন। months = 8, late = false হলে এখন fee কত?

19500
19800
17600
17400

(সহজ) Martin Fowler-এর সংজ্ঞায় কোন বদলটি refactoring?

একটি off-by-one bug ঠিক করা
রাতের delivery-তে নতুন চার্জ যোগ
Database query দ্রুত করতে index যোগ
একটি private function-এর নাম calc2 থেকে delivery_fee, সব ডাকসহ; test আগের মতো সবুজ

(মাঝারি) Invoice-এর delivery_fee(c) customer c-এর zone, years আর orders — তিনটি field পড়ে, নিজের object-এর শুধু base. প্রধান smell আর প্রতিকার?

Duplicated code — Extract Function
Feature envy — Move Function (হিসাব Customer-এ)
Shotgun surgery — Inline Class
Long parameter list — Introduce Parameter Object

(মাঝারি) নতুন জেলার delivery চার্জ যোগ করতে প্রতিবার cart, invoice, SMS, report, admin panel আর API — ছয়টি file-এ ছোট বদল লাগে। কোন smell?

Middle man
Divergent change
Large class
Shotgun surgery

(মাঝারি) একটি দল বলল: “Demo-র তারিখ বদলানো যাবে না; জানি payment module-এর নকশা দুর্বল থাকছে, ticket খুলে পরের দুই sprint-এ ঠিক করব।” Fowler-এর quadrant-এ এটি কোন ঘরে?

বেপরোয়া · জেনেশুনে
বিবেচক · অজান্তে
বিবেচক · জেনেশুনে (prudent, deliberate)
বেপরোয়া · অজান্তে

(মাঝারি) চারটি file-এর (ছয় মাসের commit, জটিলতা): P (৮০, ৯০), Q (৫, ৯৫), R (৯০, ৮), S (১৫, ২০)। Hotspot-এর যুক্তিতে কোনটির debt আগে?

(সহজ) সরকার নতুন VAT হার ঘোষণা করায় billing software-এ হিসাব বদলাতে হলো। ISO/IEC 14764 অনুযায়ী এটি কোন maintenance?

Preventive
Corrective
Adaptive
Perfective

(মাঝারি) Test ছাড়া একটি জটিল build_invoice()-এ নতুন ছাড়ের নিয়ম যোগ করতে হবে। “Sprout method” কী?

পুরোনো function কপি করে নতুন নামে বদলানো
নতুন নিয়ম পুরোনো function-এর মাঝে সরাসরি বসানো
পুরো function নতুন করে লেখা
নতুন লজিক আলাদা, test-সহ function-এ লিখে পুরোনো function থেকে এক লাইনে ডাকা

(মাঝারি) Review-এ দেখা গেল sql = f"SELECT * FROM coupons WHERE code = '{code}'", যেখানে code ব্যবহারকারীর form থেকে আসে। সবচেয়ে উপযুক্ত মন্তব্য?

nit: f-string একটু অগোছালো দেখাচ্ছে
“এভাবে কে লেখে?”
issue (blocking): ইনপুট সরাসরি SQL-এ জোড়া — SQL injection-এর ঝুঁকি; parameterized query ব্যবহার করবেন?
কোনো মন্তব্য নয়; CI test সবুজ

(মাঝারি) একটি দলের review-মন্তব্যের অর্ধেকের বেশি indentation আর quote চিহ্ন নিয়ে। সবচেয়ে কার্যকর পরিবর্তন?

Style-এর মন্তব্য নিষিদ্ধ করা
Reviewer-দের আরও কড়া হতে বলা
Formatter config ঠিক করে pre-commit hook আর CI-তে চালানো
প্রতিটি PR-এ দুজন reviewer

৮ · মডিউল ৮ — Testing আর code quality (২৫টি প্রশ্ন)

Testing-এর প্রশ্নের অর্ধেক সংজ্ঞার জোড়া (verification-validation, severity-priority, stub-mock), বাকি অর্ধেক ছোট হিসাব — BVA-র মান, decision table, V(G), MC/DC, mutation score আর flaky test-এর সম্ভাবনা।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৪৫–৫১

পর্ব ৪৫ · Testing-এর মৌলিক আর পর্ব ৪৬ · Unit test — validation, 2⁶⁴ ইনপুট, severity বনাম priority, confirmation বনাম regression, test oracle, ভাগ করা fixture
পর্ব ৪৭ · Test case নকশা আর পর্ব ৪৮ · TDD আর BDD — ২-মান ও ৩-মান BVA, 2ⁿ rule, pairwise, error masking, fake it
পর্ব ৪৯ · Test double — stub, patch-এর target, autospec, “don't mock what you don't own”
পর্ব ৫০ · Coverage আর complexity আর পর্ব ৫১ · Test pyramid — condition বনাম branch, V(G), MC/DC, mutation score, ice-cream cone, contract test

(সহজ) একটি হিসাবের software তার লিখিত spec পুরো মানে, সব test পাস করে; কিন্তু হিসাবরক্ষকেরা মাসিক বন্ধের কাজটি করতেই পারেন না, কারণ spec-এ সেটি ছিল না। কোনটি ব্যর্থ হয়েছে?

Validation — ঠিক product বানানো হয়নি
Unit testing
Regression testing
Verification — product ঠিকভাবে বানানো হয়নি

(মাঝারি) একটি function দুটি 32-bit integer নেয়। সেকেন্ডে 10⁹ test চালালে সব ইনপুট-জোড়া পরীক্ষা করতে মোটামুটি কত সময়?

প্রায় ৫৮৪ দিন
প্রায় ৫৮৪ বছর
প্রায় ১৮ ঘণ্টা
প্রায় ৪.৩ সেকেন্ড

(মাঝারি) একটি ফলাফল পোর্টালে দুটি defect: (A) হোম পেজে প্রতিষ্ঠানের নাম ভুল বানানে, ফল প্রকাশ আগামীকাল; (B) পুরোনো archive export-এ crash, যা বছরে দুই-একবার কেউ করেন আর বিকল্প পথ আছে। যুক্তিসংগত মূল্যায়ন?

A: কম severity, উচ্চ priority; B: উচ্চ severity, কম priority
A: উচ্চ severity, উচ্চ priority; B: কম দুটিই
Priority সবসময় severity-র সমান
দুটিরই severity আর priority সমান

(মাঝারি) একটি defect ঠিক করার পরে tester (১) ঠিক যে test ফেল করেছিল, সেটি আবার চালালেন; (২) আশেপাশের পুরোনো সব automated test চালালেন। দুটির নাম?

(১) smoke, (২) sanity
(১) regression, (২) confirmation
(১) confirmation testing, (২) regression testing
দুটিই acceptance testing

(মাঝারি) AI একটি tax(amount)-এর test লিখেছে; প্রতিটি প্রত্যাশিত মান AI কোডটি চালিয়ে যা পেয়েছে তা-ই বসিয়েছে। সব test সবুজ। মূল সমস্যা?

Test-গুলো বড্ড ধীর
Test-এর সংখ্যা কম
Test oracle কোড নিজেই — কোডে ভুল থাকলেও test পাস করবে
AI-এর লেখা test সবসময় flaky

(মাঝারি) একটি unittest class-এ cart = Cart() class attribute (কোনো setUp নেই)। test_add_item ৮০ টাকার চাল যোগ করে total ৮০ দেখে; test_new_cart_is_empty total ০ দেখে। test_add_item আগে চললে?

unittest নিজে থেকে প্রতিটি test-এ class attribute নতুন করে বানায়
test_add_item পাস, test_new_cart_is_empty ব্যর্থ
দুটিই ব্যর্থ
দুটিই পাস

(মাঝারি) একটি ঘরে integer 1 থেকে 50 বৈধ। ২-মান আর ৩-মান BVA-তে যথাক্রমে কয়টি test মান?

৬ আর ৯
৪ আর ৬
৫০ আর ৫২
২ আর ৩

(কঠিন) Requirement: “x ≤ 10 হলে গ্রহণ”, কিন্তু কোডে লেখা x == 10. কোন test মান এই ভুল ধরে, যা ২-মান BVA-র (10, 11) তালিকায় নেই?

9
1000
10
11

(সহজ) পাঁচটি স্বাধীন Y/N শর্তের নিয়ম। Don't-care ছাড়া পূর্ণ decision table-এ কয়টি rule?

১০
২৫
১৬
৩২

(মাঝারি) ৪টি parameter, প্রতিটির ৩টি মান। Pairwise-এ ন্যূনতম কয়টি test, আর সব মিলন কয়টি?

৩ আর ৬৪
৯ আর ৮১
৯ আর ১২
১২ আর ৮১

(মাঝারি) একটি ফর্মে নম্বর আর roll দুটি ঘর। Tester একটি test-এ নম্বর 105 আর roll “abc” — দুটি অবৈধ মান একসাথে দিলেন। প্রধান সমস্যা?

Test বড্ড ধীর হয়
দুটি বৈধ partition বাদ পড়ে
কোনো সমস্যা নেই, এতে test কমে
Error masking — প্রথম ভুলে system থামলে দ্বিতীয় ঘরের যাচাই আছে কি না জানা যায় না

(সহজ) TDD-তে নতুন test লিখে প্রথমবার চালাতেই সবুজ হলো, production কোডে কিছু না বদলেই। সবচেয়ে ভালো প্রতিক্রিয়া?

কেন সবুজ বোঝা — কোড ইচ্ছা করে ভেঙে দেখা test ফেল করতে পারে কি না
Test মুছে ফেলা
আনন্দে পরের test-এ যাওয়া
Refactor ধাপ বাদ দেওয়া

(মাঝারি) assertEqual(points(500), 5)-কে সবুজ করতে developer লিখলেন def points(amount): return 5. কৌশলের নাম আর পরের ধাপ?

Fake it — তারপর ভিন্ন উদাহরণের test (যেমন 1250 → 12) দিয়ে triangulation
Obvious implementation — শেষ
Mocking — একটি mock points বানানো
Triangulation — refactor বাদ

(মাঝারি) Payment gateway-র জায়গায় এমন object, যার charge() সবসময় "declined" দেয়; test শেষে দেখা হয় SUT "declined" ফেরত দিয়েছে কি না। Meszaros-এর ভাষায় এটি কোন double?

Fake
Dummy
Mock
Stub

(মাঝারি) orders.py-এ from sms_lib import send_sms, আর notify() ডাকে send_sms(…). Test-এ patch-এর সঠিক target?

"orders.notify"
"orders.send_sms"
"sms_lib.send_sms"
"send_sms"

(মাঝারি) SUT-এর কোডে ভুল বানানে gateway.chrage(100). Test-এ gateway একটি সাধারণ Mock(), আর test শুধু দেখে exception হয়নি। কী ঘটবে?

Python syntax error দেবে
Mock নিজে থেকে বানান ঠিক করে নেবে
Test নীরবে পাস করবে; create_autospec দিলে AttributeError ধরা পড়ত
AttributeError আসবে

(মাঝারি) একটি দল সরাসরি একটি third-party payment SDK-র class mock করে শত শত test লিখেছে। নতুন SDK-তে response-এর গঠন বদলেছে; test সবুজ, production-এ payment ব্যর্থ। প্রতিকার?

SDK-র পুরোনো version-এ চিরকাল আটকে থাকা
SDK-কে নিজের interface-এর adapter-এ মুড়ে নিজের interface-এর double, আর adapter-কে contract বা integration test-এ যাচাই
সব test মুছে শুধু হাতে test
আরও বেশি mock লেখা

(মাঝারি) if (a && b) { x = 1; } — দুটি test: (a = T, b = F) আর (a = F, b = T). এরা কোন মাপকাঠি পূরণ করে?

MC/DC
Branch coverage
শুধু condition coverage
Statement coverage

(মাঝারি) একটি function-এর control-flow graph-এ ১৫টি edge আর ১২টি node, একটিই যুক্ত অংশ (P = 1). Cyclomatic complexity V(G) কত?

২৯
৩
৫
৪

(কঠিন) if (a || b || c) — তিনটি স্বাধীন condition. Unique-cause MC/DC আর multiple-condition coverage-এর জন্য সবচেয়ে কম কয়টি test?

MC/DC ৪, multiple-condition ৮
MC/DC ৮, multiple-condition ৮
MC/DC ২, multiple-condition ৪
MC/DC ৩, multiple-condition ৬

(মাঝারি) Mutation tool ৪০টি mutant বানাল; test suite ৩০টি মারল, ১০টি বাঁচল; বেঁচে থাকাদের ৪টি equivalent. Mutation score কত?

৭৫%
≈ ৯৪.৪%
≈ ৮৩.৩%
৮৫%

(সহজ) একটি দলের suite-এ ১০০% line coverage. কোন দাবিটি অবশ্যই সত্য?

Code-এ কোনো bug নেই
সব branch-এর দুই দিকই চলেছে
প্রতিটি লাইন অন্তত একবার চলেছে — এর বেশি কিছু নয়
Mutation score-ও ১০০%

(মাঝারি) একটি suite-এ ৫০টি test, প্রতিটি স্বাধীনভাবে ২% সম্ভাবনায় flaky. একটি run-এ অন্তত একটি মিথ্যা fail-এর সম্ভাবনা মোটামুটি কত?

প্রায় ৬৪%
প্রায় ৩৬%
১০০%
২%

(সহজ) একটি দলের suite-এ ৮০টি unit, ৪০টি integration আর ৪০০টি UI-ভিত্তিক E2E test, সাথে release-এর আগে দুই দিনের হাতে test. এই আকারের নাম?

Test pyramid
Ice-cream cone — ধীর, দামি, flaky আর দেরিতে feedback
Honeycomb
Testing trophy

(মাঝারি) Mobile app-এর unit test-এ order API-র mock {"total": 450} দেয়। API-র দল total-এর নাম amount করল; দুই দিকের test সবুজ, production-এ দাম ফাঁকা। কোন ব্যবস্থা এটি deploy-এর আগে ধরত?

আরও বেশি unit test
Code coverage ১০০% করা
Consumer-driven contract test, provider-এর build-এ যাচাই
Flaky test quarantine

নিজে যাচাই করুন — testing-এর হিসাব

নিচের checker এই অংশের numerical-গুলো আবার করে; সীমা, edge, node বা flaky-হার বদলে নিজের প্রশ্নের উত্তর মেলান:

// Re-check the testing numericals of module 8: inputs, BVA, tables, V(G), mutation, flakiness.
const pct = (x, d = 1) => (100 * x).toFixed(d) + "%";
const yearS = 365 * 86400;               // 365-day year, as in the lesson
console.log("Two 32-bit ints at 1e9/s  :", Math.floor(2 ** 64 / 1e9 / yearS), "years (about)");
const bva2 = (a, b) => [a - 1, a, b, b + 1];
const bva3 = (a, b) => [a - 1, a, a + 1, b - 1, b, b + 1];
console.log("BVA 1..50, 2-value        :", bva2(1, 50).join(", "));
console.log("BVA 1..50, 3-value        :", bva3(1, 50).join(", "));
console.log("Decision table, 5 Y/N     :", 2 ** 5, "rules");
console.log("All combos 4 params x 3   :", 3 ** 4, "(pairwise needs 9)");
const vg = (E, N, P = 1) => E - N + 2 * P;
console.log("V(G), E 15, N 12          :", vg(15, 12));
console.log("MC/DC vs MCC, 3 conditions:", 3 + 1, "vs", 2 ** 3);
const score = (killed, total, equiv) => killed / (total - equiv);
console.log("Mutation 30 of 40, 4 equiv:", pct(score(30, 40, 4)));
const anyFlaky = (n, p) => 1 - (1 - p) ** n;
console.log("50 tests, 2% flaky each   :", pct(anyFlaky(50, 0.02)), "chance of a false red run");
console.log("  ...all green            :", pct((1 - 0.02) ** 50));

আউটপুট (নির্ধারিত, প্রতিবার একই):

Two 32-bit ints at 1e9/s  : 584 years (about)
BVA 1..50, 2-value        : 0, 1, 50, 51
BVA 1..50, 3-value        : 0, 1, 2, 49, 50, 51
Decision table, 5 Y/N     : 32 rules
All combos 4 params x 3   : 81 (pairwise needs 9)
V(G), E 15, N 12          : 5
MC/DC vs MCC, 3 conditions: 4 vs 8
Mutation 30 of 40, 4 equiv: 83.3%
50 tests, 2% flaky each   : 63.6% chance of a false red run
  ...all green            : 36.4%

প্রথম লাইন exhaustive testing-এর অসম্ভবতা দেখায় (৩৬৫ দিনের বছর ধরে, পর্ব ৪৫-এর মতো)। তারপর ২-মান আর ৩-মান BVA-র তালিকা, decision table-এর 2⁵, pairwise-এর তুলনায় সব মিলন, V(G), MC/DC বনাম MCC, equivalent বাদ দিয়ে mutation score, আর flaky test-এর জমে ওঠা সম্ভাবনা — ২% করে ৫০টি test-এ প্রায় দুই-তৃতীয়াংশ run-এ অন্তত একটি মিথ্যা লাল।

৯ · মডিউল ৯ — উন্নত Git আর automation (২৪টি প্রশ্ন)

এই অংশ Git-এর ভেতরের মডেল নিয়ে: object, ref, reflog, merge-এর strategy, bisect, stash, cherry-pick, স্বাক্ষর আর CI. সব “যাচাই করা” প্রশ্ন আসল repository-তে চালানো; ভাবার সময় মনে রাখুন — প্রায় সব “ধ্বংসাত্মক” command শুধু ref সরায়।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৫২–৫৮

পর্ব ৫২ · Git-এর ভেতরে আর পর্ব ৫৩ · Ref, reflog আর উদ্ধার — blob-এর header, plumbing-এর তিন ধাপ, HEAD@{1} বনাম @{1}, gc-র মেয়াদ, fsck --lost-found
পর্ব ৫৪ · Merge-এর ভেতরে — -X ours বনাম -s ours, merge-base --all, stage 1/2/3, merge-tree
পর্ব ৫৫ · Git দিয়ে bug খোঁজা আর পর্ব ৫৬ · শক্তিশালী হাতিয়ার — ⌈log₂ n⌉, exit code 125, -S বনাম -G, ignore-revs, stash pop, A..B, worktree
পর্ব ৫৭ · Git-এ নিরাপত্তা আর পর্ব ৫৮ · Continuous integration — আগে key বাতিল, %G?-এর U, CI-এর সংজ্ঞা, DAG-এ বাদ পড়া job, SHA pinning, আগে revert

(সহজ) Git-এর একটি blob object-এ কী থাকে?

ফাইলের নাম আর বিষয়বস্তু
Author আর commit-এর সময়
আগের version-এর সাথে diff
শুধু ফাইলের বিষয়বস্তু (ধরন আর আকারের ছোট header-সহ)

(মাঝারি) একটি ফাইলে শুধু hi আর একটি newline (মোট ৩ byte). Git blob ID হিসাব করতে কোন byte-গুলো SHA-1-এ দেয়?

ফাইলের নাম, তারপর hi\n
blob 2, শূন্য byte, hi
blob 3, একটি শূন্য byte, তারপর hi\n
শুধু hi\n

(মাঝারি) git commit plumbing-এর ভাষায় মোটামুটি কোন তিনটি ধাপ করে?

hash-object → cat-file → push
write-tree → commit-tree → update-ref
update-ref → write-tree → add
diff → patch → merge

(কঠিন) আপনি main-এ। HEAD-এর reflog: HEAD@{0} = “checkout: moving from feature to main”, HEAD@{1} = “checkout: moving from main to feature” (তখন feature ছিল c4-এ)। main-এর reflog: main@{0} = m3, main@{1} = m2. HEAD@{1} আর @{1} কী দেয়?

দুটিই c4
HEAD@{1} = m2, @{1} = c4
HEAD@{1} = c4, @{1} = m2
দুটিই m2

(মাঝারি) ডিফল্ট config-এ একটি commit reset করে সরানো; সেটি এখন শুধু HEAD-এর reflog-এর ১০ দিন পুরোনো entry থেকে পৌঁছানো যায়। এখন git gc (option ছাড়া) চালালে?

কিছুই মোছে না — unreachable entry-র ৩০ দিনের মেয়াদ এখনো আছে
Commit সাথে সাথে মুছে যায়
gc-ই চলে না, reflog থাকলে
Reflog খালি হয়ে যায়

(মাঝারি) নতুন ফাইল pay.js add করার পর আরও কয়েক লাইন যোগ করলেন (add করেননি), তারপর ভুলে git reset --hard. git fsck --lost-found কী ফেরাতে পারে?

কিছুই না
শুধু ফাইলের নাম
শেষবার add করা রূপ, hash-নামের একটি ফাইলে — নাম আর পরের বদল নয়
পুরো সর্বশেষ রূপ, নামসহ

(কঠিন) Base-এ fee = 60 আর অনেক নিচে limit = 1000. main শুধু fee = 70 করেছে; promo করেছে fee = 50 আর limit = 800. main-এ থেকে git merge -X ours promo দিলে ফাইলে কী থাকে?

fee = 50, limit = 800
fee = 70, limit = 1000
Conflict marker-সহ fee, আর limit = 800
fee = 70, limit = 800

(মাঝারি) git merge-base --all main side দুটি ভিন্ন commit hash ছাপল। অর্থ কী?

main আর side-এর কোনো সাধারণ ইতিহাস নেই
Repository নষ্ট
একটি merge base আর একটি tag
দুটি best common ancestor, কেউ কারও ancestor নয় — সম্ভবত criss-cross merge

(মাঝারি) Conflict চলাকালে git ls-files -u একটি ফাইলের জন্য শুধু stage 1 আর stage 3 দেখায়, stage 2 নেই। কোন অবস্থা?

Ours ফাইলটি মুছেছে, theirs বদলেছে
Theirs ফাইলটি মুছেছে
দুই পক্ষই নতুন ফাইল যোগ করেছে
Conflict মীমাংসা হয়ে গেছে

(সহজ) একটি CI bot একটি bare repository-তে জানতে চায় main আর feature conflict ছাড়া মিলবে কি না, কোনো checkout ছাড়া। উপযুক্ত command?

git rerere
git merge-tree --write-tree main feature
git diff main feature
git merge --no-commit feature

(মাঝারি) ১,০০০টি সন্দেহভাজন commit (প্রথম খারাপ commit এদের যেকোনোটি)। প্রতিটি পরীক্ষাযোগ্য, bug একবার ঢুকলে থাকে। git bisect-এ সর্বোচ্চ কয়টি পরীক্ষা?

৩২
৫০০
১০
৯

(সহজ) git bisect run ./check.sh-এ একটি commit-এ project build-ই হয় না। Script কোন exit code দিলে Git commit-টি skip করে?

(মাঝারি) একটি commit শুধু একটি ছোট function-কে একই ফাইলের নিচ থেকে ওপরে সরিয়েছে, লেখায় কোনো বদল নেই; diff-এ function-এর লাইনগুলো নিচে − আর ওপরে + হিসেবে আসে। git log -S'def fmt' আর git log -G'def fmt'-এর কোনটি commit-টি দেখায় (যাচাই করা)?

শুধু -S
শুধু -G
কোনোটিই না
দুটিই

(মাঝারি) পুরো codebase-এ formatter চালানোর commit-এর পরে git blame প্রায় সব লাইন সেই commit-এর নামে দেখায়। দলের জন্য স্থায়ী সমাধান?

Commit-এর পুরো hash .git-blame-ignore-revs-এ রেখে commit, আর blame.ignoreRevsFile config
Formatter-এর commit revert করা
blame-এর বদলে log --oneline
History rebase করে formatting সব commit-এ ছড়িয়ে দেওয়া

(মাঝারি) git stash pop-এ “CONFLICT (content): Merge conflict in app.js”. Stash-এর তালিকায় সেই entry-র কী অবস্থা?

সব stash entry মুছে যায়
Entry থাকে; সমাধানের পরে নিজে git stash drop করতে হয়
Entry মুছে যায়
Entry একটি branch হয়ে যায়

(মাঝারি) সরলরেখার ইতিহাস P → Q → R → S. অন্য branch-এ git cherry-pick Q..S চালালে কোন commit-এর বদল আসে?

R আর S
P থেকে S সব
শুধু S
Q, R আর S

(মাঝারি) মূল folder-এ feature/discount checkout করা। একই repository থেকে git worktree add ../review feature/discount চালালে Git ২.৫৩?

দ্বিতীয় folder-এ একই branch খোলে
Detached HEAD-এ খোলে
নিজে থেকে নতুন branch বানায়
“fatal: 'feature/discount' is already used by worktree at …” — থামে

(মাঝারি) একজন developer git commit --no-verify দিয়ে নিয়ম-ভাঙা commit বানিয়ে push করলেন। কোনটি push আটকাতে পারে?

core.hooksPath সেট করা
Server-এর pre-receive hook, বা বাধ্যতামূলক CI check-সহ protected branch
.gitignore-এ নিয়ম লেখা
Local pre-commit hook

(সহজ) একটি public repository-তে ভুলে cloud API key push হয়ে গেছে। সবার আগে কী?

Provider-এ key বাতিল আর নতুন key
git filter-repo দিয়ে history পরিষ্কার
Repository private করা
পরের commit-এ ফাইল থেকে key মুছে দেওয়া

(মাঝারি) git log --format="%h %G? %s"-এ একটি commit-এর পাশে U, আর verify-commit বলছে “Good … signature … No principal matched.” অর্থ?

স্বাক্ষর জাল
স্বাক্ষর গাণিতিকভাবে ঠিক, কিন্তু key-টি কার তা বিশ্বস্ত তালিকায় নেই
Commit sign-ই হয়নি
Key-এর মেয়াদ শেষ

(মাঝারি) একটি দলে প্রতিটি feature branch-এ স্বয়ংক্রিয় build আর test চলে, dashboard সবসময় সবুজ; কিন্তু branch গড়ে তিন সপ্তাহ পরে main-এ মেলে। CI-এর মূল সংজ্ঞায় কোনটি ঠিক?

Continuous deployment
পুরো অর্থে CI নয় — mainline-এ মেলানো তিন সপ্তাহে একবার
পুরো CI, কারণ প্রতিটি push-এ build চলে
Trunk-based development

(কঠিন) একটি pipeline: install-এর পরে lint, build আর scan — তিনটিই শুধু install-এর ওপর নির্ভরশীল; unit নির্ভর করে build-এর ওপর; package নির্ভর করে lint, unit আর scan-এর ওপর। Build ব্যর্থ হলে (নির্ভরশীল job বাদ, স্বাধীন job চলে)?

unit চলে, package বাদ
সব job সাথে সাথে থামে
lint আর scan চলে; unit আর package বাদ
শুধু package বাদ

(মাঝারি) Workflow-এ uses: someone/deploy-tool@v3. নিরাপত্তা-পর্যালোচক পূর্ণ ৪০ অক্ষরের commit hash দিয়ে pin করতে বললেন। কারণ?

Platform hash ছাড়া action চালায় না
v3 tag-এ secret থাকে
Tag সরানো যায়; commit hash একটি নির্দিষ্ট বিষয়বস্তু চিহ্নিত করে
Hash দিলে pipeline দ্রুত চলে

(সহজ) সকাল ১০টায় main-এর CI একটি commit-এর পরে লাল, আবার চালালেও লাল; লেখক meeting-এ, সঠিক fix অনিশ্চিত। প্রচলিত অনুশীলনে প্রথম পদক্ষেপ?

নতুন merge থামিয়ে ভাঙা commit git revert করে main সবুজ করা
Test-টি skip করা
লেখক না ফেরা পর্যন্ত সবাই merge চালিয়ে যাওয়া
git push --force দিয়ে commit মুছে দেওয়া

১০ · মডিউল ১০ — Delivery, project management আর পেশাদারি (২৬টি প্রশ্ন)

এখানে numerical সবচেয়ে বেশি — DORA, function point, PERT, COCOMO, CPM, earned value, RRL, EMV আর control chart — সাথে CMMI, license আর নৈতিকতার জোড়া-ধারণা। সূত্রের ধ্রুবক পর্ব ৬০-এর মতোই; প্রশ্নে দেওয়া থাকলে সেটিই ব্যবহার করুন।

যে পর্বগুলো ঝালিয়ে নেবেন · পর্ব ৫৯–৬৫

পর্ব ৫৯ · Continuous delivery আর DevOps — delivery বনাম deployment, build once, CFR আর median lead time, Goodhart, GitOps
পর্ব ৬০ · Software estimation আর পর্ব ৬১ · Project planning — VAF, PERT, COCOMO 81 আর II, target বনাম estimate, float, cost slope, SPI-CPI
পর্ব ৬২ · Risk আর quality management — RRL, EMV, ৩σ সীমা, CMMI-র পাঁচ level, transfer
পর্ব ৬৩ · দলগত কাজ আর open source, পর্ব ৬৪ · পেশাগত নৈতিকতা আর পর্ব ৬৫ · ক্যাপস্টোন — AGPL, Apache-2.0 আর GPL-2.0, DCO, four-fifths, preselection, জনস্বার্থ, tag --contains

(সহজ) একটি দলের pipeline-এ প্রতিটি পরিবর্তন সব স্বয়ংক্রিয় test পার হয়ে staging-এ যায়; production-এ পাঠাতে product owner একটি বোতাম চাপেন। দলটি কোন অনুশীলন করছে?

Waterfall release
Continuous deployment
শুধু continuous integration
Continuous delivery

(মাঝারি) একটি দল একই commit থেকে staging-এর জন্য একবার, আর তিন দিন পরে production-এর জন্য আবার build করে; dependency-র version range আছে, lockfile নেই। প্রধান ঝুঁকি?

Production-এর artifact staging-এ test হওয়া artifact থেকে আলাদা হতে পারে
Git tag মুছে যাবে
Staging-এর config production-এ চলে যাবে
Build-এর সময় বেশি লাগে

(মাঝারি) একটি দল ২৮ দিনে ২৪টি production deploy করেছে; তার ৩টির পরে rollback বা hotfix লেগেছে। Change failure rate আর সপ্তাহে deploy-এর গড়?

৮৭.৫%, সপ্তাহে ৬টি
১২.৫%, সপ্তাহে ৬টি
৩%, সপ্তাহে ৬টি
১২.৫%, সপ্তাহে ২৪টি

(মাঝারি) একটি deploy-এ পাঁচটি commit, যাদের lead time (ঘণ্টা) ৩, ৪০, ৫, ৯ আর ২. Median আর গড় কত?

Median ২১, গড় ১১.৮
Median ৯, গড় ১১.৮
Median ৫, গড় ৫
Median ৫, গড় ১১.৮

(মাঝারি) Deployment frequency-র সাথে বোনাস বাঁধার পরে deploy সপ্তাহে ৫ থেকে ৪০ হলো; বেশিরভাগ নতুন deploy-এ শুধু comment-এর বদল। সবচেয়ে যুক্তিসংগত সিদ্ধান্ত?

Metric লক্ষ্য হওয়ায় সাজানো হয়েছে (Goodhart) — সংজ্ঞা আর প্রণোদনা ঠিক করতে হবে
দলের গতি আট গুণ বেড়েছে
Change failure rate কমেছে, তাই সব ঠিক আছে
Lead time মাপা বন্ধ করা উচিত

(মাঝারি) GitOps-এ Git-এর desired state বলে একটি service-এর ৩টি copy; agent-এর self-heal চালু। রাতে একজন ইঞ্জিনিয়ার cluster-এ সরাসরি ৬টি copy করলেন। পরের reconcile loop-এ?

পুরো service বন্ধ হবে
৬টি থেকে যাবে, Git নিজে হালনাগাদ হবে
Agent drift ধরে আবার ৩টিতে নামাবে; ৬ রাখতে হলে Git-এ পরিবর্তন লাগবে
Agent একটি conflict marker লিখবে

(মাঝারি) একটি system-এর UFP = ২৫০, আর ১৪টি general system characteristic-এর মোট রেটিং ৪০. Adjusted function point কত?

১৬২.৫
৩৫০
২৬২.৫
২৯০

(সহজ) একটি কাজের তিন-বিন্দু অনুমান: O = ৩, M = ৬, P = ১৫ দিন। PERT-এ প্রত্যাশিত সময় আর standard deviation?

৭ দিন, σ = ৪
৬ দিন, σ = ১২
৮ দিন, σ = ২
৭ দিন, σ = ২

(কঠিন) Basic COCOMO 81-এর organic mode (a = 2.4, b = 1.05, c = 2.5, d = 0.38)-এ ৩২ KLOC-এর একটি project-এর effort আর development time মোটামুটি কত?

≈ ৯১ person-month, ≈ ১৩.৯ মাস
≈ ৯১ person-month, ≈ ৭.৬ মাস
≈ ২৩০ person-month, ≈ ১৪.৩ মাস
≈ ৭৭ person-month, ≈ ৬.৪ মাস

(মাঝারি) COCOMO II.2000-এ পাঁচটি scale factor-এর যোগফল ১৬.২ হলে size-এর exponent E কত (B = ০.৯১)?

১.০৫
১.০৭২
১৭.১১
০.৭৪৮

(সহজ) “ফল প্রকাশের আগে, ৩০ দিনে পোর্টাল চালু চাই” — রেজিস্ট্রারের এই কথা McConnell-এর পরিভাষায় কী?

Target
Estimate
Velocity
Commitment

(মাঝারি) Activity: A ৩ দিন; B ৪ দিন (A-র পরে); C ২ দিন (A-র পরে); D ৩ দিন (B আর C দুটির পরে)। Project-এর ন্যূনতম সময় আর C-র total float?

১২ দিন, float ০
৮ দিন, float ২ দিন
১০ দিন, float ৪ দিন
১০ দিন, float ২ দিন

(মাঝারি) একটি activity normal অবস্থায় ১২ দিনে ৳৬০,০০০, crash করলে ৮ দিনে ৳১,০০,০০০. Cost slope কত?

প্রতি দিন ৳৫,০০০
প্রতি দিন ৳১০,০০০
প্রতি দিন ৳১২,৫০০
প্রতি দিন ৳৪০,০০০

(মাঝারি) একটি তারিখে PV = ২০০, EV = ১৫০, AC = ১৮০ (হাজার টাকা)। কোনটি সঠিক?

দুটিই ১, কারণ project চলছে
SPI = ০.৭৫, CPI ≈ ০.৮৩ — পিছিয়ে, বাজেটও ছাড়িয়ে
SPI = ০.৯, CPI = ০.৭৫
SPI ≈ ১.৩৩, CPI = ১.২ — এগিয়ে আর সাশ্রয়ী

(কঠিন) একটি ঝুঁকির সম্ভাবনা ৪০%, ক্ষতি ৳২৫ লাখ। ৳৩ লাখ খরচের প্রতিকারে সম্ভাবনা নামে ১০%-এ (ক্ষতি একই)। Boehm-এর risk reduction leverage কত?

২.৫
৩.৩৩
০.৪
৭.৫

(মাঝারি) একটি সিদ্ধান্তে ৬০% সম্ভাবনায় ৳১০ লাখ লাভ, ৪০% সম্ভাবনায় ৳৫ লাখ ক্ষতি। Expected monetary value কত?

৳৫ লাখ
৳৮ লাখ
৳৪ লাখ
৳৬ লাখ

(মাঝারি) একটি দলের সাপ্তাহিক defect-এর control chart-এ mean ৩০, σ ৪. ৩σ নিয়মে control limit কত?

UCL ৩৮, LCL ২২
UCL ৩৪, LCL ২৬
UCL ৪২, LCL ০
UCL ৪২, LCL ১৮

(সহজ) CMMI-র staged representation-এ যে level-এ প্রক্রিয়া সংখ্যা ও পরিসংখ্যান দিয়ে নিয়ন্ত্রিত হয়, তার নাম?

Quantitatively Managed (level ৪)
Defined (level ৩)
Optimizing (level ৫)
Repeatable (level ২)

(মাঝারি) একটি দল payment অংশ বাইরের প্রতিষ্ঠানকে নির্দিষ্ট দামের চুক্তিতে দিল; দেরির জরিমানা ওই প্রতিষ্ঠানের। কোন risk response?

Avoid
Transfer
Mitigate
Accept

(মাঝারি) একটি কোম্পানি AGPL-3.0 database-এর source বদলে নিজের server-এ চালায় আর ইন্টারনেটে গ্রাহকদের সেবা দেয়, কিন্তু কোনো কপি বিতরণ করে না। প্রচলিত ব্যাখ্যায় কী করতে হবে?

কিছুই না, কারণ বিতরণ নেই
গ্রাহকদের বদলানো source পাওয়ার সুযোগ দিতে হবে (ধারা ১৩)
Database-এর নাম বদলাতে হবে
License fee দিতে হবে

(মাঝারি) একটি GPL-2.0-only project-এ Apache-2.0 কোড আনতে চান। FSF-এর প্রচলিত মত কী?

শুধু MIT হলে যায়, Apache-2.0 নিজেই copyleft
হ্যাঁ — permissive কোড যেকোনো copyleft-এ আনা যায়
সরাসরি নয় — Apache-2.0 GPL-3.0-এর সাথে মেলে, GPL-2.0-এর সাথে নয়
হ্যাঁ — দুটিই open source, তাই সবসময় মেলে

(সহজ) একটি open-source project প্রতিটি commit-এ Signed-off-by লাইন চায়, আলাদা চুক্তি স্বাক্ষর ছাড়া। এটি কী?

SPDX identifier
GPG signed commit
Developer Certificate of Origin (DCO)
Contributor License Agreement (CLA)

(মাঝারি) ঋণ-অনুমোদন system-এ গোষ্ঠী P-এর selection rate ০.৫০ (সর্বোচ্চ) আর Q-এর ০.৪২. Four-fifths rule কী বলে?

পার্থক্য ০.০৮, তাই নিয়ম প্রযোজ্য নয়
Ratio ০.৮৪, যা ০.৮০-র বেশি — এই নিয়মে সতর্কসংকেত নেই, যদিও অন্য বিশ্লেষণ লাগতে পারে
Ratio ১.১৯ — Q গোষ্ঠী সুবিধা পাচ্ছে
Ratio ০.৮৪ — disparate impact প্রমাণিত

(সহজ) একটি checkout পাতায় “আমাকে বিজ্ঞাপনী email পাঠান” বাক্সটি আগে থেকেই টিক দেওয়া। GDPR-এর সম্মতির শর্ত আর deceptive design-এর দৃষ্টিতে এটি কী?

বৈধ সম্মতি নয় — preselection ধরনের dark pattern
Privacy by default-এর উদাহরণ
বৈধ, কারণ ব্যবহারকারী টিক তুলে দিতে পারেন
Accessibility-র সমস্যা

(মাঝারি) ACM/IEEE-CS Software Engineering Code (১৯৯৯)-এর আটটি নীতির কেন্দ্রে কোনটি?

Self
Product
Client and Employer
Public — জনস্বার্থ

(মাঝারি) একটি release-এর পরে bisect দেখাল, bug ঢুকেছে commit 3f9a1c2-এ। এখন পর্যন্ত কোন কোন release (tag) এই bug বহন করে, তা জানতে কোন command (যাচাই করা)?

git blame 3f9a1c2
git describe 3f9a1c2
git log --tags
git tag --contains 3f9a1c2

নিজে যাচাই করুন — estimation, planning, risk আর delivery-র হিসাব

// Re-check the estimation, planning, risk and delivery numericals of module 10.
const r = (x, d = 2) => Number(x.toFixed(d));
const afp = (ufp, gsc) => ufp * (0.65 + 0.01 * gsc);
const pert = (o, m, p) => [(o + 4 * m + p) / 6, (p - o) / 6];
const basic = (kloc, a, b, c, d) => { const E = a * kloc ** b; return [r(E, 1), r(c * E ** d, 1)]; };
console.log("AFP: UFP 250, sum GSC 40   :", afp(250, 40));
console.log("PERT O 3, M 6, P 15 -> te,s:", pert(3, 6, 15).join(", "));
console.log("COCOMO 81 organic, 32 KLOC :", basic(32, 2.4, 1.05, 2.5, 0.38).join(" PM, "), "months");
console.log("  embedded, 32 KLOC        :", basic(32, 3.6, 1.20, 2.5, 0.32).join(" PM, "), "months");
console.log("COCOMO II E, sum SF 16.2   :", r(0.91 + 0.01 * 16.2, 3));
// CPM: A3; B4 after A; C2 after A; D3 after B, C
const ES = { A: 0, B: 3, C: 3, D: 3 + 4 }, dur = { A: 3, B: 4, C: 2, D: 3 };
const finish = ES.D + dur.D, lsC = ES.D - dur.C;
console.log("CPM finish, float of C     :", finish, "days,", lsC - ES.C, "days");
console.log("Crash slope (100k-60k)/4   :", (100000 - 60000) / (12 - 8), "taka/day");
console.log("SPI, CPI (PV200 EV150 AC180):", r(150 / 200), r(150 / 180));
const re = (p, l) => p * l;
console.log("RRL (10 - 2.5) / 3         :", (re(0.4, 25) - re(0.1, 25)) / 3);
console.log("EMV 0.6x10 + 0.4x(-5)      :", 0.6 * 10 + 0.4 * -5, "lakh");
console.log("Control limits 30 +/- 3x4  :", 30 + 12, 30 - 12);
console.log("CFR 3/24, deploys per week :", r(100 * 3 / 24, 1) + "%,", 24 / 4);
const lt = [3, 40, 5, 9, 2].sort((a, b) => a - b);
console.log("Lead time median, mean     :", lt[2], r(lt.reduce((s, x) => s + x) / 5, 1));
console.log("Four-fifths 0.42 / 0.50    :", r(0.42 / 0.50));

আউটপুট (নির্ধারিত, প্রতিবার একই):

AFP: UFP 250, sum GSC 40   : 262.5
PERT O 3, M 6, P 15 -> te,s: 7, 2
COCOMO 81 organic, 32 KLOC : 91.3 PM, 13.9 months
  embedded, 32 KLOC        : 230.4 PM, 14.3 months
COCOMO II E, sum SF 16.2   : 1.072
CPM finish, float of C     : 10 days, 2 days
Crash slope (100k-60k)/4   : 10000 taka/day
SPI, CPI (PV200 EV150 AC180): 0.75 0.83
RRL (10 - 2.5) / 3         : 2.5
EMV 0.6x10 + 0.4x(-5)      : 4 lakh
Control limits 30 +/- 3x4  : 42 18
CFR 3/24, deploys per week : 12.5%, 6
Lead time median, mean     : 5 11.8
Four-fifths 0.42 / 0.50    : 0.84

Function point, PERT আর দুই mode-এর Basic COCOMO (organic বনাম embedded — একই KLOC-এ effort আড়াই গুণ), COCOMO II-এর exponent, ছোট network-এর CPM (C-র float ২ দিন), crashing-এর slope, SPI-CPI, RRL, EMV, ৩σ control limit, DORA-র CFR আর median lead time, শেষে four-fifths ratio. ধ্রুবক পর্ব ৬০-এর টেবিলের মতোই।

AI-এর যুগে — AI দিয়ে আরও MCQ বানান, কিন্তু উত্তর নিজে যাচাই করুন

এই পাতা শেষ হলে আরও অনুশীলন চাইবেন, আর AI চ্যাটবট মুহূর্তে শত শত MCQ বানাতে পারে। কিন্তু software engineering আর Git-এর MCQ-তে AI প্রায়ই ভুল অপশনকে “সঠিক” বলে, বা একই প্রশ্নে দুটি সঠিক অপশন রাখে। ভুল হয় ঠিক এই পাতার ফাঁদগুলোতে — reset-এর default mode, rebase-এ ours/theirs, -X আর -s, COCOMO-র exponent, পুরোনো Git-এর আচরণ।

AI-এর প্রচলিত ভুল	উদাহরণ	কীভাবে ধরবেন
পুরোনো বা বানানো Git আচরণ	“plain git pull নীরবে merge করে”, অস্তিত্বহীন flag	throwaway repository-তে চালান; `git help <command>` পড়ুন; version লিখুন
ধ্বংসাত্মক “সমাধান”	প্রতিটি সমস্যায় reset --hard বা push --force	প্রশ্ন করুন: shared কি না, কী হারাবে; reflog আর --force-with-lease
ভুল হিসাব, নিশ্চিত সুরে	COCOMO-তে D = E ÷ ১২, PERT-এ σ²-কে σ	নিজে খাতায়, বা এই পাতার checker-এ সংখ্যা বসান
সংজ্ঞা মেশানো	stub-কে mock, DIP-কে DI, SRP-কে “এক কাজ”	সংশ্লিষ্ট পর্বের সংজ্ঞার সাথে শব্দে শব্দে মেলান
দুটি সঠিক অপশন	“কোনটি structural?” — adapter আর facade দুটিই	প্রতিটি অপশনের পাশে স বা ভু লিখে দেখুন ঠিক একটি টেকে কি না
বানানো উৎস	ভুল বছর, standard-এর নম্বর; “অমুক পরীক্ষায় এসেছিল”	উৎস দেখাতে না পারলে দাবি বাদ

নিচের প্রম্পটটি AI-কে প্রশ্ন বানাতে বলে, সাথে এমন তথ্যও চায়, যা দিয়ে আপনি উত্তর যাচাই করতে পারবেন:

আমি software engineering আর Git-এর MCQ পরীক্ষার প্রস্তুতি নিচ্ছি (বিশ্ববিদ্যালয়, চাকরির লিখিত পরীক্ষা আর ইন্টারভিউ)। বিষয়: [যেমন: git reset ও revert / rebase ও conflict / SOLID / UML class diagram / test double / COCOMO ও function point / CPM-PERT] কঠিনতা: [সহজ / মাঝারি / কঠিন] ১০টি MCQ বানাও। প্রতিটির জন্য: ১. প্রশ্ন আর ঠিক ৪টি অপশন; শুধু একটি সঠিক। দরকারি সব তথ্য (commit graph, কোড, সংখ্যা) প্রশ্নেই থাকবে। ২. Git-এর প্রশ্নে Git-এর version আর config ধরে নিচ্ছ কি না লেখো, আর আমি যাতে একটি খালি repository-তে চালিয়ে দেখতে পারি, সেই command-এর ক্রম দাও। ৩. সঠিক উত্তর, আর প্রতিটি ভুল অপশন কোন ভুল ধারণা বা কোন হিসাবের ভুল থেকে এসেছে — এক লাইনে। ৪. numerical-এ সূত্র, ধ্রুবক আর প্রতিটি ধাপ দেখাও। ৫. history বদলানো command (reset --hard, push --force) উত্তরে থাকলে ঝুঁকিটিও লেখো। ৬. নিশ্চিত না হলে “নিশ্চিত নই” লেখো; কোনো প্রশ্নকে কোনো নির্দিষ্ট পরীক্ষার আসল প্রশ্ন বলে দাবি করবে না।

যাচাইয়ের চেকলিস্ট

প্রতিটি Git প্রশ্নের command নিজে একটি throwaway repository-তে চালিয়েছি, আর ফল অপশনের সাথে মিলিয়েছি
প্রতিটি numerical নিজে খাতায় বা ছোট script-এ করেছি; সূত্রের ধ্রুবক কোর্সের পর্বের সাথে মিলেছে
চারটি অপশনের মধ্যে ঠিক একটি সত্য — দুটি সত্য হয়ে যাওয়া প্রশ্ন ঠিক করেছি
সংজ্ঞাগুলো (stub-mock, SRP, DIP, CMMI-র level) পর্বের লেখার সাথে মিলিয়েছি
উৎস, বছর আর standard-এর নম্বর যাচাই না করে বিশ্বাস করিনি

কেন এই উত্তর ভুল? — রিভিশনের কৌশল আর সবচেয়ে বেশি ভুল হওয়া ধারণা

প্রথমটি এই প্রশ্নব্যাংক দিয়ে কীভাবে রিভিশন করবেন তা নিয়ে; বাকিগুলো এমন ধারণা, যেখানে এই পাতার প্রশ্নে সবচেয়ে বেশি ভুল হয়। আগে নিজে ভাবুন — তারপর খুলে দেখুন।

প্র ০১এতগুলো প্রশ্ন একবারে পড়ে মনে থাকে না। এই প্রশ্নব্যাংক দিয়ে কীভাবে রিভিশন করলে সবচেয়ে বেশি কাজে লাগে?

একটানা পড়ে যাওয়া — প্রশ্ন দেখা, উত্তর চাপা, এগোনো — সবচেয়ে কম কাজে লাগে। শেখার গবেষণায় বারবার কার্যকর পাওয়া গেছে দুটি অভ্যাস: নিজে থেকে মনে করা (active recall) আর বিরতি দিয়ে ফেরা (spaced repetition).

এক অংশ, পুরো মনোযোগ: একবারে একটি মডিউল নিন। চাপার আগে খাতায় উত্তর আর এক লাইনের কারণ লিখুন — “mixed, তাই index ফেরে, ফাইল থাকে”. কারণ লিখতে না পারলে ঠিক হলেও ভুল গুনুন।
ভুলের খাতা: প্রতিটি ভুলের পাশে প্রশ্ন নয়, নিয়মটি লিখুন — “equivalent mutant হর থেকে বাদ”. পরীক্ষায় একই নিয়ম অন্য সংখ্যায় আসবে।
Git-এর প্রশ্ন নিজে চালান: একটি খালি folder-এ git init, তারপর প্রশ্নের command — দশ মিনিটে যে বিশ্বাস জন্মায়, তা পড়ে আসে না।
পর্বে ফিরুন: একটি অংশে চারটির বেশি ভুল হলে তার পর্বগুলো আবার পড়ুন; ১, ৩ আর ৭ দিন পরে শুধু ভুলগুলো করুন, অপশন পড়ার আগেই উত্তর বলে।

মূল উপলব্ধি: প্রশ্ন নয়, প্রশ্নের পেছনের নিয়ম মনে রাখাই লক্ষ্য — নিজে উত্তর আর কারণ লিখুন, Git চালিয়ে দেখুন, বিরতি দিয়ে ফিরে আসুন।

প্র ০২reset, revert আর restore — তিনটিই “undo”. তবু shared main-এ reset ভুল উত্তর, আর reset --hard-এর পরেও কাজ ফেরে — কেন?

তিনটি command তিনটি আলাদা জিনিস বদলায়। git reset branch-এর pointer সরায় — mode ঠিক করে আর কতদূর: soft শুধু branch, mixed (ডিফল্ট) সাথে index, hard সাথে working tree-ও। git revert কিছুই সরায় না; একটি নতুন commit যোগ করে, যা আগের commit-এর বদল উল্টে দেয়। git restore commit ছোঁয় না, শুধু ফাইল বা index ফেরায়।

Shared main-এ reset ভুল, কারণ সহকর্মীদের clone-এ পুরোনো commit-গুলো আছে। আপনি branch পিছিয়ে force push করলে তাঁদের পরের pull-এ ইতিহাস মেলে না, আর কারও push আপনার মোছা commit আবার ফিরিয়ে আনে। Revert-এ ইতিহাস শুধু সামনে বাড়ে — সবাই সাধারণ pull-এ সেটি পান। Merge commit উল্টাতে -m 1 লাগে, নইলে Git ২.৫৩ “is a merge but no -m option was given” বলে থামে — এই পাতার একটি প্রশ্নে আসল বার্তাটিই আছে।

reset --hard-এর পরেও commit ফেরে, কারণ কোনো reset object মোছে না; HEAD-এর reflog-এ আগের অবস্থান থাকে, তাই git reset --hard HEAD@{1} বা git branch rescue <hash>. যা ফেরে না, তা হলো কখনো add না করা লেখা — Git সেটি কখনো দেখেনি।

মূল উপলব্ধি: প্রশ্নে দুটি জিনিস খুঁজুন — বদলটি কোথায় (ফাইল, index, commit) আর অন্যরা কি পেয়েছেন। shared হলে revert; নিজের local হলে reset, আর ভুল হলে reflog (পর্ব ১১, ৫৩)।

প্র ০৩Merge-এ “ours” মানে নিজের branch, rebase-এ উল্টো। এই উল্টো ভূমিকার কারণ কী, আর -X ours আর -s ours কোথায় আলাদা?

Ours সবসময় HEAD — যে commit-এর ওপর দাঁড়িয়ে Git কাজ করছে। Merge-এ আপনি নিজের branch-এ দাঁড়িয়ে অন্যটি টেনে আনেন, তাই ours = আপনার কাজ। Rebase-এ Git প্রথমে নতুন base-এ (যেমন main) চলে যায়, তারপর আপনার commit একে একে replay করে। তখন HEAD = main আর ইতিমধ্যে বসানো commit, আর যে commit বসানো হচ্ছে সেটি theirs. তাই rebase-এর conflict-এ --theirs আপনার লেখা দেয় — এই পাতায় Git ২.৫৩-এ চালিয়ে দেখা।

দ্বিতীয় বিভ্রান্তি strategy আর option-এ। -s ours একটি merge strategy: অন্য branch-এর কোনো বদলই নেয় না, শুধু ইতিহাসে লিখে রাখে “মেলানো হয়েছে” — পুরোনো branch বন্ধ ঘোষণার মতো। -X ours ডিফল্ট ort strategy-কে একটি option দেয়: যেখানে conflict, সেখানে ours; যেখানে conflict নেই, সেখানে অন্য branch-এর বদল স্বাভাবিকভাবেই আসে। -s theirs বলে কোনো strategy নেই, কিন্তু -X theirs আছে।

আরেকটি ফাঁদ: git checkout --ours conflict-এর সময় শুধু working tree-তে একটি সংস্করণ বসায়; মীমাংসা হয় git add-এর পরে, যখন index-এর stage ১/২/৩ মুছে stage ০ লেখা হয়।

মূল উপলব্ধি: ours = HEAD, আর rebase-এ HEAD নতুন base; -s ours সব ফেলে, -X ours শুধু conflict-এর hunk-এ জেতে (পর্ব ১৩, ১৫, ৫৪)।

প্র ০৪Stub, mock, fake, spy — library সব কিছুকেই “Mock” বলে। পরীক্ষায় তাহলে কোন নাম ঠিক?

পরিভাষাটি এসেছে Gerard Meszaros-এর xUnit Test Patterns (২০০৭) থেকে, আর Martin Fowler-এর “Mocks Aren't Stubs” প্রবন্ধে জনপ্রিয় হয়েছে। সেখানে নাম ঠিক হয় ভূমিকা দিয়ে, library-র class দিয়ে নয়। Dummy শুধু parameter-এর জায়গা ভরে। Stub SUT-কে ঠিক করা উত্তর দেয় (indirect input), আর test যাচাই করে SUT-এর ফল — state verification. Spy ডাকগুলো লিখে রাখে, পরে test নিজে দেখে। Mock আগে থেকেই প্রত্যাশা জানে আর ডাকটিই যাচাই করে — behaviour verification. Fake সত্যি কাজ করে, সরল উপায়ে — in-memory repository, fake clock.

Python-এর unittest.mock.Mock দিয়ে এই পাঁচটির যেকোনোটি বানানো যায়: শুধু return_value দিলে সেটি ভূমিকায় stub, assert_called_once_with দিলে mock. তাই পরীক্ষায় প্রশ্নে বর্ণিত আচরণ দেখে নাম দিন: ঠিক করা উত্তর দিয়ে ফল দেখা হলে stub, ডাক যাচাই হলে mock.

ব্যবহারের নিয়মও প্রশ্নে আসে: যা নিজের নয় (third-party SDK), তা সরাসরি mock না করে নিজের adapter-এর পেছনে রাখুন; আর ভেতরের প্রতিটি ডাক mock করলে test implementation-এর আয়না হয়ে refactoring-এ মিথ্যা লাল দেখায়।

মূল উপলব্ধি: Double-এর নাম ভূমিকা দিয়ে — উত্তর দেয় (stub), ডাক লেখে (spy), ডাক যাচাই করে (mock), সত্যি কাজ করে (fake); library-র নাম প্রায়ই এগুলো মানে না (পর্ব ৪৯)।

প্র ০৫সব test সবুজ, coverage ১০০%, spec পুরো মানা — তবু ব্যবহারকারী অখুশি বা bug production-এ। কোন তিনটি ভুল ধারণা একসাথে কাজ করছে?

এক — verification-কে validation ভাবা। Barry Boehm-এর পরিচিত রূপে verification প্রশ্ন করে “আমরা কি product-টি ঠিকভাবে বানাচ্ছি?” — spec আর নকশা মানা হচ্ছে কি না; validation প্রশ্ন করে “আমরা কি ঠিক product বানাচ্ছি?” — আসল প্রয়োজন মেটে কি না। Spec-এ মাসিক বন্ধের কাজটি না থাকলে সব test সবুজ থেকেও product অকেজো।

দুই — coverage-কে quality ভাবা। Line বা branch coverage শুধু বলে কোন লাইন বা শাখা চলেছে; assertion-হীন test-ও ১০০% দেয়। Test-এর জোর মাপে mutation testing: ছোট ভুল ঢুকিয়ে দেখা হয় test লাল হয় কি না। বেঁচে থাকা mutant দেখায় কোন আচরণ কেউ যাচাই করছে না — যেমন সীমার মান।

তিন — test oracle-কে কোড বানানো। AI বা মানুষ কোড চালিয়ে যা পেলেন তা-ই প্রত্যাশিত মান বসালে test কোডের ভুলও “নিশ্চিত” করে। প্রত্যাশিত মান আসে requirement বা হাতের হিসাব থেকে।

Dijkstra-র পুরোনো কথাটিও মনে রাখুন: test ভুলের উপস্থিতি দেখাতে পারে, অনুপস্থিতি নয় — আর দুটি 32-bit integer-এর সব জোড়া পরীক্ষাতেই প্রায় ৫৮৪ বছর লাগে।

মূল উপলব্ধি: সবুজ test আর উঁচু coverage প্রয়োজনীয়, যথেষ্ট নয়; সঠিক requirement, স্বাধীন oracle আর mutation score মিলিয়েই আস্থা (পর্ব ৩, ৪৫, ৫০)।

প্র ০৬“১ story point = ১ দিন”, “CMMI level ৩ মানে ভালো software”, “open source হলেই কোড নেওয়া যায়” — management-এর এই তিন ভুল ধারণা কেন ভুল?

Story point ঘণ্টা নয়। Story point একটি দলের reference story-র সাপেক্ষে আপেক্ষিক মাপ — আকার, জটিলতা আর অনিশ্চয়তা মিলিয়ে। দুই দলের মাপকাঠি আলাদা, তাই velocity তুলনা অর্থহীন; আর velocity-কে লক্ষ্য বানালে point ফুলে ওঠে — Goodhart-এর সূত্র। Forecast দিন পরিসরে, দলের নিজের velocity থেকে।

CMMI প্রক্রিয়ার পরিপক্বতা মাপে। পাঁচ level — Initial, Managed, Defined, Quantitatively Managed, Optimizing (CMMI v1.3-এর staged নাম; পুরোনো software CMM-এ level ২ ছিল “Repeatable”). Level ৩ মানে প্রতিষ্ঠানের একটি মানক প্রক্রিয়া আছে, project তা মানিয়ে নেয় — কোনো নির্দিষ্ট product ভালো, তার প্রমাণ নয়। ISO 9001-ও একটি quality management system-এর সনদ, পণ্যের নয়।

License-এর compatibility দিক-নির্ভর। MIT বা BSD-র মতো permissive license শুধু notice রাখতে বলে; GPL বিতরণের সময় একই license আর source চায়; AGPL-3.0-এর ধারা ১৩ network সেবাতেও source দিতে বলে। আবার FSF-এর মতে Apache-2.0 GPL-3.0-এর সাথে মেলে, কিন্তু GPL-2.0-এর সাথে নয়। সন্দেহে আইনি পরামর্শ নিন।

মূল উপলব্ধি: সংখ্যা আর সনদের পেছনের সংজ্ঞা জানুন — point আপেক্ষিক, CMMI প্রক্রিয়ার, license দিক-নির্ভর (পর্ব ৫, ৬০, ৬২, ৬৩)।

শেষ ধাপ — ক্রম সাজান আর স্কোর দেখুন

উপরের সব MCQ শেষ করলে নিচে আপনার মোট স্কোর দেখাবে — প্রথম চেষ্টায় কয়টি ঠিক হয়েছে।

ক্রমএকটি public repository-তে ভুলে API key push হয়েছে। করণীয়গুলো আগে থেকে পরে সাজান (▲▼ চেপে সরান)

Provider-এ key বাতিল করা
নতুন key বানিয়ে secret store-এ রাখা
git filter-repo দিয়ে history থেকে ফাইলটি সরানো
সব branch আর tag force push করা
দলকে নতুন করে clone করতে বলা আর host-কে জানানো
Log দেখে key-এর অপব্যবহার হয়েছে কি না যাচাই

শব্দকোষ

লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব শব্দ এখানে একসাথে:

মনে রাখুন

বাদ দিয়ে উত্তর: প্রতিটি অপশনের পেছনের নিয়মটি খুঁজুন — ভালো distractor প্রায়ই অন্য একটি command বা সূত্রের সঠিক ফল।
Git-এ ছবি আঁকুন: graph, তিন এলাকা আর কোন ref সরে; reset-এর mode, rebase-এ ours = নতুন base, -X বনাম -s — আর সন্দেহ হলে throwaway repository-তে চালান।
নীতির আসল সংজ্ঞা: DRY = এক জ্ঞান এক জায়গা, SRP = এক actor, DIP ≠ DI; UML-এ রেখা আর মাথার চিহ্ন একসাথে পড়ুন।
Testing-এর জোড়া: verification বনাম validation, severity বনাম priority, stub বনাম mock; coverage চলা মাপে, mutation score জোর মাপে।
সূত্রের অংশ ভুলবেন না: +2P, equivalent বাদ, VAF-এর ০.৬৫, D = 2.5 × E^d, EV লবে, RRL-এ খরচ দিয়ে ভাগ — আর point ঘণ্টা নয়।

পরের পর্বে: MCQ চেনায় কোনটি সঠিক; লিখিত পরীক্ষা আর ভাইভা চায় কেন সঠিক। পর্ব ৬৮-এ process, requirement, design, testing আর management-এর লিখিত ও মৌখিক প্রশ্ন — কীভাবে ধাপে ধাপে উত্তর সাজাবেন আর ছবি আঁকবেন।

MCQ প্রশ্নব্যাংক — software engineering ও Git

এই পর্বে যা করবেন

১ · MCQ কীভাবে সামলাবেন — প্রশ্নের ধরন, বাদ দেওয়া, রীতি আর সময়

প্রশ্নের ছয় ছাঁচ

কৌশল ১ · বাদ দেওয়ার পদ্ধতি — একটি কঠিন Git প্রশ্ন ধাপে ধাপে

কৌশল ২ · রীতি আর একক আগে, হিসাব পরে

কৌশল ৩ · Git-এর প্রশ্নে খাতায় ছবি

কৌশল ৪ · negative marking আর সময় ভাগ

বারোটি বড় ফাঁদ

২ · মডিউল ১ — Software engineering-এর ভিত্তি (২২টি প্রশ্ন)

৩ · মডিউল ২ ও ৩ — Git-এর মৌলিক আর Git দিয়ে দলগত কাজ (৫০টি প্রশ্ন)

মডিউল ২ — Git-এর মৌলিক (২৫টি প্রশ্ন)

মডিউল ৩ — Git দিয়ে দলগত কাজ (২৫টি প্রশ্ন)

৪ · মডিউল ৪ — Requirement engineering (২১টি প্রশ্ন)

৫ · মডিউল ৫ — Design-এর নীতি আর UML (২৩টি প্রশ্ন)

৬ · মডিউল ৬ — Design pattern (২২টি প্রশ্ন)

৭ · মডিউল ৭ — Architecture, clean code আর maintenance (২৩টি প্রশ্ন)

৮ · মডিউল ৮ — Testing আর code quality (২৫টি প্রশ্ন)

নিজে যাচাই করুন — testing-এর হিসাব

৯ · মডিউল ৯ — উন্নত Git আর automation (২৪টি প্রশ্ন)

১০ · মডিউল ১০ — Delivery, project management আর পেশাদারি (২৬টি প্রশ্ন)

নিজে যাচাই করুন — estimation, planning, risk আর delivery-র হিসাব

AI-এর যুগে — AI দিয়ে আরও MCQ বানান, কিন্তু উত্তর নিজে যাচাই করুন

যাচাইয়ের চেকলিস্ট

কেন এই উত্তর ভুল? — রিভিশনের কৌশল আর সবচেয়ে বেশি ভুল হওয়া ধারণা

শেষ ধাপ — ক্রম সাজান আর স্কোর দেখুন

শব্দকোষ

মনে রাখুন

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ