ফাইনাল ইয়ার প্রজেক্ট: শুধু demo নয়, আপনার কাজের প্রমাণ
এমন একটি ফাইনাল ইয়ার প্রজেক্ট বানান, যা আপনি বুঝিয়ে বলতে এবং অন্যের হাতে তুলে দিতে পারেন। Task planning, দলের Git workflow, কাজের sync-up, risk-based testing, CI ও evidence template—সবই এখানে পাবে।
এটি CSE-Pothik-এর প্রস্তাবিত quality bar—বিশ্ববিদ্যালয়ের নিয়ম, accreditation বা certification নয়। সবার আগে department-এর rubric, supervisor-এর নির্দেশনা ও ethics/safety requirement মানবে। সময় কমে গেলে scope ছোট করুন, কাজের প্রমাণ নয়।
পিছিয়ে থাকলে সবকিছু rewrite করতে যাবেন না। একটি core journey নিন, ঝুঁকি লিখুন, failing case ঠিক করুন, তারপর অন্য কাউকে চালিয়ে দেখতে দিন। ছোট কিন্তু নিজের ভাষায় বোঝানো যায় এমন কাজও শক্তিশালী portfolio evidence।
কাজের অভ্যাস: ছোট team, পরিষ্কার workflow
সব একসঙ্গে পড়ার দরকার নেই। আজ যে কাজ আটকে আছে সেটি বেছে নিন; প্রতিটি playbook-এ steps আর একটি worked example আছে।
01 · প্রথম feature-এর আগে
Team কীভাবে কাজ করবে, আগে ঠিক করুন
একটি দরকারি outcome, বাস্তবসম্মত সময় আর shared agreement দিয়ে শুরু করুন। Student team-এর দরকার স্পষ্টতা, ছোট আকারের corporate bureaucracy নয়।
কীভাবে করবে ও worked example: Team কীভাবে কাজ করবে, আগে ঠিক করুন
এক পৃষ্ঠায় agreement লিখুন
Rubric, deadline, class/exam বাদে সাপ্তাহিক সময়, যোগাযোগের channel, response window আর supervisor review date লিখুন। Concern, অনুপস্থিতি আর contribution credit কীভাবে সামলাবে ঠিক করুন। Commit count দিয়ে কাউকে rank করবেন না।
Ownership ভাগ করুন, দায়িত্ব rotate করুন
প্রতি issue-তে একজন owner আর আলাদা reviewer রাখুন। Meeting facilitation, release coordination আর quality check rotate করুন; QA সবার দায়িত্ব। Risky কাজ pair-এ করুন, যেন critical module শুধু একজনই না বোঝে। Solo হলে peer বা supervisor দিয়ে milestone review করান।
Evidence থেকে উল্টো দিকে plan করুন
ছোট end-to-end milestone ঠিক করে এক সপ্তাহের iteration-এ কাজ করুন। Review, testing, integration আর exam-এর সময় রাখুন। Risk list-এ owner, early warning আর fallback রাখুন। Data বা hardware access অনিশ্চিত হলে feature promise করার আগেই তা যাচাই করুন।
Scope কমান, ঘুম বা evidence নয়
নতুন কাজ এলে benefit, cost আর risk লিখুন; team ও supervisor-এর সঙ্গে কম জরুরি কাজ বাদ দিয়ে সেটি নিন। Cut list দৃশ্যমান রাখুন। Submission buffer-এর আগে অপ্রয়োজনীয় feature freeze করুন; সব testing বা report শেষ সপ্তাহে রাখবেন না।
উদাহরণ: ১২ সপ্তাহের window, বাধ্যতামূলক schedule নয়
সপ্তাহ ১–২: problem, permission, brief আর repo ঠিক করুন; সবচেয়ে বড় risk যাচাই করুন। সপ্তাহ ৩–৪: একটি tested vertical slice demo করুন।
সপ্তাহ ৫–৮: প্রতি সপ্তাহে review ও test-সহ শুধু core slice যোগ করুন। সপ্তাহ ৯–১০: integration, evaluation, repair আর recovery rehearsal করুন; নতুন scope বন্ধ করুন।
সপ্তাহ ১১–১২: অন্য কাউকে দিয়ে clean setup, final evidence, report আর defense rehearsal করুন। Report পুরো সময় জুড়েই লিখুন। নিজের semester আর approval অনুযায়ী এই উদাহরণ বদলান।
একটি shared task manager-এ আসল অবস্থা রাখুন। Outcome আর evidence track করুন—শুধু “frontend করুন” ধরনের অস্পষ্ট card নয়।
কীভাবে করবে ও worked example: Idea-কে ছোট, যাচাইযোগ্য task-এ ভাঙুন
ছোট board বানান
GitHub Issues-এর পাশে GitHub Projects দিয়ে শুরু করা সুবিধাজনক; আগে থেকেই Trello, Jira বা অন্য shared board থাকলে সেটিও ঠিক আছে। Status, Owner, Priority, Milestone আর Estimate field রাখুন; risk ও dependency label বা issue body-তে লিখুন। প্রতি task-এর একটিই record রাখুন; chat-এ আলাদা status না রেখে repo link করুন।
ব্যবহারযোগ্য behavior ধরে ভাগ করুন
Outcome → milestone → user-visible slice → implementation ও test task। একটি slice UI, logic আর data মিলিয়ে ছোট behavior দেয়; specialist-রা subtask নিতে পারে। প্রতি task আনুমানিক অর্ধ দিন থেকে দুই দিনের focused কাজের মতো রাখুন। Risk estimate না হলে question, experiment আর decision-সহ সময়-বাঁধা research spike করুন—অন্তহীন “research” card নয়।
Ready আর Done স্পষ্ট করুন
Ready মানে problem, owner, acceptance criteria, dependency আর test approach বোঝা হয়েছে। Done মানে reviewed ও merged code, relevant test pass, acceptance criteria যাচাই, updated docs আর evidence link। “আমার laptop-এ চলে” বা “PR merge হয়েছে” একা Done নয়। Merge-এ issue auto-close হলে verification আলাদা track করুন, অথবা merge-এর আগেই verify করুন।
Board-এ সত্যি অবস্থা রাখুন
Backlog → Ready → In progress → In review → Verify → Done। Blocked হলে কারণ, সাহায্যকারী আর next check-in লিখুন; Done-এ লুকাবেন না। শুরুতে জনপ্রতি একটি active implementation task রাখুন। নতুন কাজের আগে অপেক্ষায় থাকা review দেখুন। Acceptance fail হলে reproducible defect-সহ In progress-এ ফেরান; চাপ দিয়ে নয়, অভিজ্ঞতা দিয়ে estimate বদলান।
Worked task: double booking আটকাও
Outcome: নির্ভরযোগ্য equipment booking। Milestone: এক ধরনের equipment নিরাপদে book করা যায়। Slice: REQ-01 overlapping reservation আটকায়, simultaneous request-সহ।
Issue #42: atomic conflict protection দিন। Owner: একজন implementer; reviewer: অন্য teammate। Dependency: time-zone আর interval rule ঠিক করা। Estimate: এক focused দিন ও review; database spike-এর পরে দরকার হলে বদলান।
AC-01: একই slot-এর দুই valid concurrent request-এর একটি succeed, অন্যটিতে পরিষ্কার conflict, আর ঠিক একটি booking থাকবে। Task: database rule প্রমাণ, integration test-সহ implementation, তারপর linked task-এ accessible conflict message। Evidence: ADR-01 → PR #43 → TEST-01 log।
Git local history রাখে; hosted repository team-কে একসঙ্গে কাজ আর shared work recover করতে সাহায্য করে। Brief আর setup instruction দিয়েই শুরু করুন, submission-এর আগের রাতে নয়।
কীভাবে করবে ও worked example: প্রথম দিন থেকেই version control
একটি shared home বানান
Maintainer repository খুলে প্রত্যেকের নিজস্ব account-এ invite করবে, প্রয়োজনমতো permission দেবে। Supervisor আর data owner-এর সঙ্গে visibility ঠিক করুন; public সবসময় উপযুক্ত নয়। Account protection চালু করুন। অন্যরা সেই repository clone করবে; ZIP বা আলাদা অসংযুক্ত copy দিয়ে teamwork নয়।
প্রথম commit-ই কাজে লাগুক
README-তে purpose, prerequisite আর exact setup/test command; stack অনুযায়ী ignore file; safe .env.example; package lockfile; আর branch/review-সহ contribution guide রাখুন। Rights holder-এর সঙ্গে licensing ঠিক করুন; নিজের নয় এমন কাজের license দেবেন না। Diff দেখে ছোট logical change commit করুন; নিয়মিত push করুন, যেন শুধু local copy না থাকে।
Stack অনুযায়ী folder সাজান
Application source, test, docs, automation আর configuration আলাদা বোঝা যায় এমন রাখুন। নতুন layer বানানোর আগে framework-এর convention মানুন। Web app-এ src/, tests/, docs/, scripts/ আর .github/workflows/ হতে পারে; research-এ reproducible experiment config ও data manifest লাগতে পারে। Migration আর safe sample data version করুন, live database dump বা generated dependency/build folder নয়।
Data আর recovery রক্ষা করুন
Password, token, personal record আর অনুমতিহীন dataset Git, issue বা screenshot-এ রাখবেন না। Private repo secret vault নয়। অনুমোদিত বড় artifact আলাদা রেখে version/checksum ও access instruction দিন। Code থেকে আলাদা data backup আর restore test করুন। Credential leak হলে দ্রুত revoke/rotate, দায়িত্বশীল owner-কে জানানো আর host-এর cleanup process মানুন; শুধু file delete যথেষ্ট নয়।
প্রথম দিনের handoff check
Teammate নতুন folder-এ clone করে শুধু README মেনে locked dependency install ও সবচেয়ে ছোট check চালাবে। কোথায় আটকাল লিখে instruction ঠিক করে আবার করবে। কোন folder generated আর কোন evidence Git-এ থাকবে এখনই ঠিক করুন।
ছোট student team-এ short-lived feature branch আর working main রাখুন। এটি GitHub-flow ধরনের পরামর্শ; ভারী Gitflow-এর develop/release branch বাধ্যতামূলক নয়।
কীভাবে করবে ও worked example: সহজ branch → review → merge flow নিন
Main branch-এর নিয়ম ঠিক করুন
Main runnable রাখুন। Hosting plan-এ সম্ভব হলে pull request, অন্তত একটি peer approval আর passing CI বাধ্যতামূলক করুন; shared branch-এ force push নিষিদ্ধ রাখুন। না হলে একই review gate team agreement দিয়ে মানুন—server enforce করে এমন দাবি নয়। একাধিক version সত্যি maintain করলেই long-lived release branch ভাবুন।
Updated main থেকে branch করুন
Switch করার আগে git status দেখুন। আগে unrelated local কাজ শেষ করুন বা নিরাপদে সংরক্ষণ করুন। --ff-only দিয়ে main pull, feature/42-booking-conflict-এর মতো branch, তারপর staged diff দেখে শুধু relevant file commit করুন। Branch push করে risky approach হলে শুরুতেই draft PR খুলুন।
শুধু formatting নয়, behavior review করুন
Issue আর acceptance criteria link করুন; কী বদলেছে, কেন, কীভাবে test, risk আর দরকারি screenshot দিন। Reviewer logic, failure case, test, accessibility/security ও docs দেখবে; সম্ভব হলে চালাবে। Feedback blocking নাকি optional বলুন; code নিয়ে কথা বলুন, মানুষ নিয়ে নয়। Author fix ও evidence দিয়ে re-review চাইবে।
Conflict একসঙ্গে বুঝুন
Overlapping edit কে coordinate করবেন ঠিক করুন। Main বদলালে fetch-এর পরে feature branch-এ origin/main merge করে অন্য author-এর সঙ্গে intended behavior বুঝে conflict মেটান; আবার test ও push করুন। অন্ধভাবে “ours/theirs” বা reset --hard দিয়ে conflict লুকাবেন না। Update অস্পষ্ট হলে shared history বদলানোর আগে pair review করুন।
বুঝে merge, verify আর release করুন
Approval আর fresh passing check-এর পরে team convention হলে squash-merge, merged feature branch delete আর integrated acceptance criteria verify করুন। Task status ও evidence update করুন। Main-এর tested milestone tag করুন; সব commit release নয়। Bad merge reviewed revert/fix PR দিয়ে ঠিক করুন; deployment rollback-এর আগে data compatibility ভাবুন।
আগে clone করা repo-তে command-এর উদাহরণ
Clean working tree-তে এক লাইন করে চালান। উদাহরণের path আপনার project-এ থাকতে হবে; নিজের changed file, issue আর branch বসাও। Error এলে থেমে পড়ুন। এই command-এর পরে PR-এ review ও merge হবে।
git status
git switch main
git pull --ff-only
git switch -c feature/42-booking-conflict
# Implement and run the relevant tests, then:
git diff
git add src/booking.ts
git diff --staged
git commit -m "Prevent overlapping bookings (#42)"
git push -u origin feature/42-booking-conflict
Call দিয়ে blocker সরাও আর decision নিন; task board পড়ে শোনানোর জন্য নয়। Written update অনুপস্থিত teammate-কে যুক্ত রাখে, report-এর evidence-ও হয়।
কীভাবে করবে ও worked example: Sync-up ছোট, decision লিখিত রাখুন
Async তিন লাইনের update দিন
ঠিক করা workday-তে লিখুন: আগের update থেকে কী শেষ + issue/PR link; পরের কাজ; blocker + কী সাহায্য লাগবে। আগে board update করুন। Class আর ঘুমের সময় মেনে response window রাখুন। Blocker পেলে তখনই জানান, পরের call পর্যন্ত অপেক্ষা নয়।
দরকার হলে ১৫ মিনিটের sync করুন
আগে agenda আর link দিন। মিনিট ০–৩: milestone ও blocked card দেখুন। ৩–১০: decision নিন বা investigation-এর pair ঠিক করুন। ১০–১৫: প্রতিটি action-এর owner আর due/check-in date নিশ্চিত করুন। Deep debugging দরকারি মানুষ নিয়ে আলাদা follow-up-এ করুন। Written update-এই সমাধান হলে call বাদ দিন।
সাপ্তাহিক demo, একটি habit উন্নত করুন
২০–৩০ মিনিটে integrated slice acceptance criteria মিলিয়ে দেখান, failure-সহ—শুধু slide নয়। ঠিক করা review-এ supervisor-এর decision চান। তারপর ১০ মিনিটে কী সাহায্য করেছে, কী সমস্যা আর পরের সপ্তাহে একটি process change ঠিক করুন। বাকি capacity দেখে unfinished কাজ replan করুন; সব task চুপচাপ carry করবেন না।
Decision-এর trail রাখুন
ছোট note দিন: date, attendee, decision ও কারণ, owner/date-সহ action, unresolved question আর issue/ADR link। অনুপস্থিতদের summary দিন; চুপ থাকাকে approval ধরুন না, disagreement নিশ্চিত করুন। Consent ছাড়া call record বা public note-এ private participant information রাখবেন না।
06 · Acceptance criteria-তে, coding-এর সময় আর release-এর আগে
Coverage trophy নয়, risk ধরে test করুন
Implementation-এর আগে test approach লিখুন। Rule-এর জন্য দ্রুত focused check, boundary-তে integration test আর জরুরি user journey-তে অল্প end-to-end test রাখুন।
কীভাবে করবে ও worked example: Coverage trophy নয়, risk ধরে test করুন
সবচেয়ে risky behavior বেছে নিন
প্রতি requirement-এ কী fail হতে পারে আর impact লিখুন। Cosmetic issue-এর আগে data loss/corruption, unauthorized access, ভুল result আর unusable core journey দেখুন। প্রতি test-এ ID, requirement, level, owner, setup, input, action আর expected result রাখুন। না চালালে not-run লিখুন; planned test pass-এর evidence নয়।
Rule আর বাস্তব boundary test করুন
Unit test-এ deterministic logic আলাদা করে empty input, boundary আর invalid state দেখুন। Integration test-এ isolated test environment-এ real database constraint, migration বা service contract যাচাই করুন। দরকারে external service mock করুন, কিন্তু যে database behavior যাচাইয়ের দাবি করছেন সেটিই mock করবেন না। Test data reset আর সম্ভব হলে clock/randomness control করুন।
User journey আর failure যাচাই করুন
User-visible behavior আর stable accessible locator দিয়ে অল্প critical end-to-end journey automate করুন। Success, validation, permission, empty/error state আর recovery দেখুন। অকারণ sleep বা পরস্পরকে প্রভাবিত করা shared test account এড়াও। Local development-এর সঙ্গে real deployment path-এ production build test করুন।
Manual আর specialist check যোগ করুন
Interface-এ keyboard-only use, visible focus, label, zoom, সরু screen আর relevant language/theme দেখুন; automated accessibility scan conformance প্রমাণ করে না। অনুমোদিত sandbox-এ role permission, secret handling আর invalid input দেখুন। মাপার আগে device, dataset ও workload-সহ বাস্তব performance target ঠিক করুন। Project-type section মেনে ML, hardware ও network evidence বদলান; web E2E model evaluation বা hardware safety-এর বিকল্প নয়।
Defect থেকে regression evidence বানান
Bug report-এ environment/commit, ছোট reproduction, expected বনাম actual, impact আর safe log দিন। Severity (ক্ষতি) আর priority (কখন fix) আলাদা করুন। Reproduce, সম্ভব হলে failing regression test, fix, affected test ও core journey আবার চালান, তারপর peer verification। Flaky test খতিয়ে দেখুন; retry দিয়ে failure লুকাবেন না। Coverage gap খুঁজতে সাহায্য করে, কিন্তু ১০০% correctness প্রমাণ নয়।
TEST-01: REQ-01-এর plan, বানানো result নয়
Unit: agreed rule অনুযায়ী পাশাপাশি interval overlap নয়; invalid/উল্টো interval reject। Integration: empty isolated database আর দুই valid user দিয়ে একই slot-এ concurrently reservation দিন; ঠিক এক success, এক conflict আর এক stored booking assert করুন।
End-to-end/manual: unsuccessful user পরিষ্কার keyboard-এ ব্যবহারযোগ্য recovery path পায়, অন্য slot নিতে পারে। Security: অন্য user কারও booking cancel করতে পারে না। Recovery: cancel হলে slot আবার available, duplicate record ছাড়া।
Run record: commit/tag, database ও app version, fixture, command, timestamp, expected/actual, pass/fail/blocked/not-run আর log বা screenshot। Release candidate-এ আবার চালিয়ে failure issue-তে link করুন। বানানো pass count, latency বা screenshot নয়।
Continuous integration change প্রস্তাবের সময় agreed check চালায়। ছোট করে শুরু করুন, check বিশ্বাসযোগ্য রাখুন, আর যে artifact test ও handover করবে সেটিই build করুন।
কীভাবে করবে ও worked example: Check repeatable, release recoverable করুন
দ্রুত pull-request gate বানান
Pull request আর main update-এ clean runner, pinned runtime ও locked dependency install রাখুন। Formatting check (চুপচাপ auto-fix নয়), lint/static check, unit ও relevant integration test, তারপর production build চালান। Content site-এ schema/content check দিন। Local ও CI-তে একই documented command; skipped check-কে pass বলবে না।
Release candidate test করুন
Built artifact isolated test environment-এ serve করে critical E2E চালান। Milestone tag-এর আগে broader regression, accessibility/manual check, migration ও recovery rehearsal, আর অন্য কাউকে দিয়ে clean setup করান। Safe fixture ও third-party stub নিন; student CI যেন real card charge, user-কে email বা production data modify না করে।
Log নিরাপদ, failure দৃশ্যমান রাখুন
CI-তে minimum permission আর প্রয়োজন হলেই protected secret দিন; untrusted pull-request code-এ secret দেবেন না। Personal data বাদ দিয়ে test report ও দরকারি failure artifact সীমিত retention-এ রাখুন। Merge-এর আগে failed gate fix করুন; approved exception হলে owner ও follow-up লিখুন, green করতে test বন্ধ নয়।
Release আর handover rehearsal করুন
Tested commit/tag, দরকারে artifact checksum, config, migration step, known limit আর release owner লিখুন। Smoke test ও safe rollback/restore rehearsal করুন; code rollback incompatible data migration উল্টাতে পারে না। পরের maintainer-কে setup, architecture decision, test command, open issue ও access-transfer instruction দিন, report-এ secret নয়। Rubric অনুমতি দিলে offline demo backup রাখুন।
যে pipeline student explain করতে পারে
Pull request → clean install → format/lint/type check → unit/integration test → production build → preview smoke/E2E → peer review → merge। Milestone-এ full regression, manual check আর independent reproduction করে verified commit tag করুন।
CSE-Pothik-এর জন্য: yarn install --immutable; yarn check; yarn build; yarn verify:build; তারপর একই BASE_PATH-সহ PLAYWRIGHT_SERVER=preview দিয়ে yarn test:e2e ও yarn test:a11y। এগুলো এই repository-এর command, সব stack-এর universal pipeline নয়।
দশটি template একই Markdown toolkit-এ আছে। দরকারি অংশটি আপনার task manager বা repository-তে নিন। এগুলো লেখার শুরু, completed evidence নয়; এখানে কিছু জমা বা submit হয় না।
Project brief ও risk register
Scope নেওয়ার আগে supervisor-এর সঙ্গে সবচেয়ে ছোট useful outcome ঠিক করুন।
Title / team / supervisor / review date / rubric link:
User ও problem / বাস্তব evidence বা research question / evidence ব্যবহারের permission:
সবচেয়ে ছোট measurable outcome / scope-এ কী / স্পষ্টভাবে scope-এর বাইরে কী:
Deadline / সাপ্তাহিক capacity / budget / equipment ও data constraint:
Risk / impact ও likelihood / early warning / owner / mitigation বা fallback / পরের review:
Ethics, privacy ও safety approval / approver / status / evidence link:
Team agreement ও milestone plan
Kickoff-এ একসঙ্গে লিখুন; availability বা scope বদলালে আবার দেখুন।
Member / সাপ্তাহিক availability / অনুপস্থিতি ও handoff ব্যবস্থা:
শেষই করা যায় না—এমন বিশাল feature list-এর চেয়ে বাস্তব প্রশ্ন ও নির্ভরযোগ্য প্রমাণসহ ছোট প্রজেক্ট অনেক বেশি শেখায়।
আগে department-এর rubric ও supervisor-এর শর্তগুলো দেখুন: সময়সীমা, দলের আকার, ethics approval, assessment এবং report format।
কার সমস্যা সমাধান করছেন বা কোন research question-এর উত্তর খুঁজছেন, সমস্যাটি সত্যি হওয়ার প্রমাণ কী, আর সবচেয়ে ছোট উপকারী ফলটি কী—লিখে ফেলুন। Interview-এর আগে সম্মতি নিন; প্রয়োজন না থাকলে sensitive data সংগ্রহ করবেন না।
কোন কাজটি করবে, কোনটি করবে না, budget ও tool-এর সীমা, বড় তিনটি ঝুঁকি এবং data, lab বা dependency না পেলে বিকল্প—সব লিখে রাখুন।
এখন কতটুকু যথেষ্ট
Supervisor-এর feedback-সহ এক পাতার brief, যা পড়ে অন্য কেউ প্রজেক্টটি আবার আপনাকেই বুঝিয়ে বলতে পারে।
এখনই নয়: কোন সমস্যার সমাধান করবে সেটি বোঝানোর আগেই microservices, blockchain বা AI model বেছে বসবেন না। Technology দিয়ে নয়, সমস্যা দিয়ে শুরু করুন।
কোন আচরণ দেখলে বলবে কাজটি ঠিক হয়েছে, তা না জানলে ‘fast, secure, user-friendly’—শুধু সুন্দর তিনটি শব্দ হয়; implementation-এর নির্দেশনা নয়।
প্রতিটি গুরুত্বপূর্ণ requirement-কে একটি ID, user scenario ও চোখে দেখা যায় এমন acceptance criterion দিন। ভুল হলে কী ঘটবে এবং কীভাবে ফিরে আসবে, সেটিও লিখুন।
আপনার lab-এর সামর্থ্য অনুযায়ী মাপা যায়—এমন constraint ঠিক করুন: নির্দিষ্ট dataset বা device-এ response time, কোন screen support করবে, accessibility check এবং data কত দিন রাখবে।
Requirement-এর সঙ্গে design decision, implementation ও test-এর যোগসূত্র রাখুন। নিচের ছোট traceability example-টি একজন সহপাঠীর সঙ্গে মিলিয়ে দেখুন।
এখন কতটুকু যথেষ্ট
গুরুত্ব অনুযায়ী সাজানো requirement list ও test matrix, যেখান থেকে যে কেউ বুঝতে পারে কোনটি pass, কোনটি fail, আর কোনটি জেনেশুনে বাদ দেওয়া হয়েছে।
এখনই নয়: কারণ ছাড়া performance target বানাবেন না; সত্যিকারের পর্যবেক্ষণ ছাড়া usability যাচাই হয়েছে—এ দাবিও করবেন না।
Diagram তখনই কাজে লাগে, যখন system-এর সীমা ও trade-off বোঝায়; fashionable box-এর সংখ্যা বেশি হলেই architecture ভালো হয় না।
Component, data flow, trust boundary এবং deployment বা experiment setup আঁকুন। যেখানে দরকার API/data contract ও failure state লিখে দিন।
একটি গুরুত্বপূর্ণ সিদ্ধান্ত লিখে রাখুন: প্রেক্ষাপট কী, অন্তত দুটি বিকল্প কী ছিল, কোনটি বেছে নিলে এবং তার পরিণতি কী। প্রমাণ ছাড়া জটিলতার দরকার নেই; সহজ modular design-ই ভালো।
Implementation শুরুর আগেই data-এর মালিকানা, সর্বনিম্ন permission, secret handling, dependency-এর license এবং সম্ভাব্য threat নিয়ে ভাবুন।
এখন কতটুকু যথেষ্ট
একজন সহপাঠী design ধরে একটি scenario-এর পথ অনুসরণ করতে, বাদ দেওয়া বিকল্পটির কারণ বলতে এবং অন্তত একটি অমীমাংসিত ঝুঁকি চিহ্নিত করতে পারে।
এখনই নয়: শুধু ‘industry-level’ দেখানোর জন্য distributed service, Kubernetes বা custom authentication যোগ করবেন না। প্রজেক্টকে জটিল করলেই সে চাকরি পেয়ে যায় না।
বারবার অনুসরণ করা যায়—এমন team workflow প্রজেক্টেরই অংশ; submission-এর আগের রাতে বানানো paperwork নয়।
শুরু থেকেই version control ব্যবহার করুন। ছোট issue, পরিষ্কার commit ও সহজে review করা যায়—এমন pull request রাখুন। প্রত্যেকের অবদান লিখে রাখবে, তবে commit-এর সংখ্যা দিয়ে কারও কাজের মান মাপবে না।
শুরুর দিকেই ছোট একটি end-to-end flow চালিয়ে দেখুন। Requirement, code/design ও test একসঙ্গে review করুন। একা কাজ করলে নির্দিষ্ট সময়ে সহপাঠী বা supervisor-এর review নিন।
Formatting, static check ও প্রাসঙ্গিক test CI-তে চালান; dependency-এর version স্থির রাখুন, tool-এর version লিখে রাখুন, আর secret ও সত্যিকারের ব্যক্তিগত data Git-এর বাইরে রাখুন।
এখন কতটুকু যথেষ্ট
README-এর ধাপ অনুসরণ করে fresh checkout থেকে প্রজেক্ট চলে; review হওয়া পরিবর্তনটির সঙ্গে requirement, test result ও কার অবদান—সব দেখা যায়।
এখনই নয়: Integration শেষ সপ্তাহের জন্য তুলে রাখবেন না; আর নিজের অবদান বোঝাতে না পারলে tutorial clone-কে প্রজেক্ট বলে জমা দেবেন না।
সফল demo কেবল একটি পথ দেখায়। ভালো engineering evidence কোথায় সীমা, কীভাবে failure হয় এবং এখনও কী অজানা—সেটিও বলে।
গুরুত্বপূর্ণ logic, component boundary ও end-to-end journey test করুন। Invalid input, permission, data হারানো ও recovery, এবং বাস্তব device বা dataset-এর সীমাও ধরুন।
Interface-এ keyboard navigation, focus, label, contrast, resizing এবং error recovery পরীক্ষা করুন; automation-এর পাশাপাশি হাতে ধরেও দেখুন। যে device ও assistive tool সত্যিই ব্যবহার করেছেন, শুধু সেটিই লিখুন।
শুধু অনুমোদিত system-এ প্রাসঙ্গিক security/dependency check এবং সীমিত performance experiment চালান। Environment, পদ্ধতি, সত্যিকারের ফল ও সীমাবদ্ধতা লিখুন; গুরুত্বপূর্ণ defect ঠিক করে affected test আবার চালান।
এখন কতটুকু যথেষ্ট
Pass/fail ফল, ঠিক করা defect-এর প্রমাণ ও বাকি ঝুঁকিসহ traceable test report। ‘Zero bug’ বা ‘পুরোপুরি secure’—এমন অবাস্তব দাবি নয়।
এখনই নয়: শুধু সংখ্যা বাড়াতে 100% coverage-এর পেছনে ছুটবেন না, failure লুকাবেন না, কাল্পনিক participant বানাবেন না, আর AI বানানো measurement-কে আসল result হিসেবে দেবেন না।
৬ · অন্য কেউ যেন চালাতে পারে, সমস্যা হলে ফিরিয়েও আনতে পারে
‘আমার laptop-এ চলে’—এটি ভালো শুরু, কিন্তু handover plan নয়।
Release tag দিন; source, setup instruction, tool-এর version, secret ছাড়া example config ও নিরাপদ sample data রাখুন। License ও access restriction মেনে চলুন।
শুধু instruction দিয়ে একজন সহপাঠীকে rebuild বা experiment আবার চালাতে দিন। কোথায় আটকে গেল লিখে রাখুন, instruction বা setup ঠিক করুন, তারপর আবার চেষ্টা করান।
Deploy করা system-এর log, backup/restore, rollback এবং demo কে চালু রাখবে বা বন্ধ করবে—লিখে রাখুন। Offline project হলে একইভাবে চালানো যায়—এমন local setup ও deployment-এর সীমা বোঝান।
এখন কতটুকু যথেষ্ট
Release-এর সঙ্গে যুক্ত স্বাধীন reproduction note এবং যেখানে দরকার test করা recovery procedure।
এখনই নয়: শুধু public link দেখানোর জন্য production hosting-এ অপ্রয়োজনীয় খরচ করবেন না বা sensitive data প্রকাশ করবেন না।
কাজটি কেন উপকারী, তা কীভাবে জানুন এবং এরপর কী বদলাতে—এই তিনটি প্রশ্নের উত্তর আপনার জানা থাকা দরকার।
Department-এর report format মেনে চলুন। সমস্যা, related work, method/design, implementation, evaluation, সীমাবদ্ধতা, ethics ও reference রাখুন; অন্যের asset বা code থেকে নিজের কাজ স্পষ্টভাবে আলাদা করুন।
স্বাভাবিক flow, failure ও recovery, এবং requirement-এর সঙ্গে যুক্ত প্রমাণসহ ছোট demo তৈরি করুন। Internet বিগড়ে গেলে দেখানোর জন্য offline backup রাখুন—demo day-তে Wi-Fi-র নাটক নতুন কিছু নয়।
Department-এর policy অনুযায়ী AI ও tool ব্যবহারের কথা জানান, প্রতিটি citation যাচাই করুন এবং যে generated code রেখেছ সেটি বুঝিয়ে বলতে প্রস্তুত থাকুন। প্রত্যেকের অবদান ও অমীমাংসিত issue লিখে রাখুন।
এখন কতটুকু যথেষ্ট
Report, চালানো যায় এমন artifact ও defense-এর কথা একে অন্যের সঙ্গে মেলে; নতুন maintainer পরের নিরাপদ পরিবর্তনটি বুঝতে পারে।
এখনই নয়: প্রাসঙ্গিক প্রমাণ ছাড়া student prototype-কে production-ready, paper-কে accepted বা design-কে certified বলে দাবি করবেন না।
এটি শেখার উদাহরণ; আপনার domain আর supervisor-এর নির্দেশনা অনুযায়ী বদলাবে।
REQ-01 · প্রয়োজন
একই equipment একই সময়ে দুজনের জন্য confirmed booking হবে না।
AC-01 · গ্রহণযোগ্যতা
একই সময়ে দুটি request এলে ঠিক একটিই সফল হবে; অন্যটি পরিষ্কার conflict দেখাবে, duplicate record থাকবে না।
ADR-01 · সিদ্ধান্ত
শুধু button disable নয়—server/data layer-এ atomic conflict protection থাকবে; বেছে নেওয়া database-এর আচরণ test দিয়ে যাচাই হবে।
TEST-01 · যাচাই
একই সময়ের concurrent request দিয়ে integration test; পাশাপাশি পাশের সময়, cancel আর retry case-ও পরীক্ষা।
REL-01 · হস্তান্তর
Release tag, environment, আসল test log আর জানা সীমাবদ্ধতা report-এ দিন। নকল screenshot বা বানানো pass result নয়।
Project বদলালে evidence-ও বদলাবে।
শুধু নিজের project-এর ধরনটি মন দিয়ে পড়ুন; সব ধরনের project একসঙ্গে বোঝার দরকার নেই।
Web / mobile / software
ব্যবহারযোগ্য মূল journey, API/data contract, permission boundary, automated ও manual test, accessible failure state এবং release instruction দেখান। Mobile হলে lifecycle, offline state এবং সুযোগ থাকলে আসল target device-এ পরীক্ষা করুন।
Public deployment বাধ্যতামূলক নয়; বারবার চালানো যায়—এমন local demo অনেক সময় privacy ও খরচ দুটোই ভালোভাবে সামলায়।
Research / data / machine learning
Research question, data-এর উৎস ও অনুমতি, baseline, train/validation/test ভাগ, leakage check, uncertainty-সহ metric এবং আবার তৈরি করা যায়—এমন environment ও seed লিখে রাখুন। Negative result ও error analysis-ও দেখান।
শুধু বড় accuracy-ই contribution নয়। Publication আলাদা review process; graduation হলেই paper বের হবে—এমন প্রতিশ্রুতি নয়।
Hardware / embedded systems
Schematic, BOM, firmware/tool-এর version, test condition, simulation বনাম বাস্তব measurement, calibration ও uncertainty লিখে রাখুন; physical কাজের আগে supervisor-এর safety review নিন।
আগে simulator-এ যাচাই করুন। Student demonstration কোনো electrically certified product নয়; বিপজ্জনক circuit নিয়ে supervision ছাড়া কাজ করবেন না।
স্পষ্ট অনুমতি ও নিরাপদ scope ছাড়া campus, public বা client system-এ কোনো experiment করবেন না। কৌতূহল ভালো; অনুমতি ছাড়া কৌতূহল বিপদ ডেকে আনে।
Submission-এর আগে evidence মিলিয়ে দেখুন
এটি score বা tracker নয়। Team review-এ প্রতিটি দাবির evidence দেখান; ঘাটতি থাকলে scope কমান, ঠিক করুন অথবা limitation হিসেবে লিখে supervisor-এর সঙ্গে আলোচনা করুন।
Supervisor ও rubric-এর শর্ত এবং দলের প্রত্যেকের অবদান লেখা আছে।
প্রতিটি গুরুত্বপূর্ণ requirement-এর মাপা যায় এমন acceptance criteria ও তার সঙ্গে যুক্ত result আছে।
মূল design decision ও বাদ দেওয়া বিকল্পটির কারণ ব্যাখ্যা করা আছে।
একজন সহপাঠী README ও নিরাপদ sample data ব্যবহার করে tagged artifact চালাতে পারে।
Test-এ অন্তত একটি failure case আছে; result-এ environment ও বাকি সীমাবদ্ধতা বলা আছে।
প্রাসঙ্গিক accessibility, privacy, security ও physical-safety risk যাচাই করা হয়েছে।
License, citation, dataset-এর অনুমতি ও AI-এর সহায়তা সততার সঙ্গে উল্লেখ করা হয়েছে।
Recovery ও handover-এর ধাপ এবং জানা issue demo ও report-এর সঙ্গে মেলে।
এই সপ্তাহে একটি কাজ
Template নিয়ে এক পাতার brief আর একটি acceptance criterion লিখুন। Peer-কে পাঁচ মিনিটে সেটি বুঝিয়ে বলতে বলুন। যেখানে সে আটকে যায়, সেই অস্পষ্ট অংশ বদলান—এটাই প্রথম কাজে লাগা review।
এই guide একটি original editorial synthesis; reference provider-রা পুরো guide endorse করেনি। বাইরের reference-গুলোর বেশির ভাগই English। প্রতিটি source-এর review date আলাদা দেওয়া আছে।
Web E2E-তে user-visible behavior, test isolation আর resilient locator ব্যবহার করুন। এই source সব unit, research বা hardware testing-এর প্রয়োজন মেটায় না।