# ফাইনাল ইয়ার প্রজেক্ট: শুধু demo নয়, আপনার কাজের প্রমাণ

এটি কাজের template, completed report নয়। প্রতিটি field-এর নিচে নিজের evidence লিখুন; example-কে result হিসেবে দেবেন না। Department rubric আর supervisor-এর নির্দেশ আগে মানবে। Private data বা secret এখানে দেবেন না। প্রয়োজনমতো section আলাদা করে issue, PR বা team document-এ নিন।

## 1. Project brief ও risk register

Scope নেওয়ার আগে supervisor-এর সঙ্গে সবচেয়ে ছোট useful outcome ঠিক করুন।

- Title / team / supervisor / review date / rubric link:
  উত্তর / evidence link:

- User ও problem / বাস্তব evidence বা research question / evidence ব্যবহারের permission:
  উত্তর / evidence link:

- সবচেয়ে ছোট measurable outcome / scope-এ কী / স্পষ্টভাবে scope-এর বাইরে কী:
  উত্তর / evidence link:

- Deadline / সাপ্তাহিক capacity / budget / equipment ও data constraint:
  উত্তর / evidence link:

- Risk / impact ও likelihood / early warning / owner / mitigation বা fallback / পরের review:
  উত্তর / evidence link:

- Ethics, privacy ও safety approval / approver / status / evidence link:
  উত্তর / evidence link:

## 2. Team agreement ও milestone plan

Kickoff-এ একসঙ্গে লিখুন; availability বা scope বদলালে আবার দেখুন।

- Member / সাপ্তাহিক availability / অনুপস্থিতি ও handoff ব্যবস্থা:
  উত্তর / evidence link:

- Shared board ও repo / যোগাযোগের channel / response window / escalation contact:
  উত্তর / evidence link:

- Issue owner ও reviewer rule / facilitation ও release role rotation / contribution credit:
  উত্তর / evidence link:

- Ready criteria / Done criteria / WIP limit / blocked কাজের নিয়ম:
  উত্তর / evidence link:

- Milestone / demo দেখানো যায় এমন outcome / acceptance evidence / target date / dependency / scope cut:
  উত্তর / evidence link:

- Supervisor review date / feature freeze / test-report-defense buffer / মতবিরোধের প্রক্রিয়া:
  উত্তর / evidence link:

## 3. কাজ শুরু করার মতো issue

Task manager-এ copy করুন। Peer Done বোঝাতে না পারলে task আরও ভাঙুন।

- Issue ID ও behavior-focused title / parent outcome বা milestone / requirement ID:
  উত্তর / evidence link:

- Problem ও এখন কেন / scope-এর ভিতরে কী / বাইরে কী:
  উত্তর / evidence link:

- Owner / reviewer / priority / estimate / dependency ID / risk বা spike question:
  উত্তর / evidence link:

- Acceptance: Given [শুরুর অবস্থা], when [কাজ], then [দেখা যায় এমন result]; failure/boundary case:
  উত্তর / evidence link:

- Implementation subtask / test approach ও data / কোন docs বদলাবে:
  উত্তর / evidence link:

- Status / blocked কারণ, সাহায্যকারী ও next check-in / PR link / verification evidence:
  উত্তর / evidence link:

## 4. Pull request ও peer review

একটি coherent change-এর জন্য নিন; সত্যি চালানো check লিখুন, failure-সহ।

- Issue / requirement / base ও feature branch / summary ও কারণ:
  উত্তর / evidence link:

- কীভাবে run ও review / test command / environment / actual result ও log link:
  উত্তর / evidence link:

- Acceptance evidence / দরকারি screenshot / failure ও recovery behavior:
  উত্তর / evidence link:

- Security, privacy, accessibility ও compatibility impact / config বা migration / rollback-এ কী ভাবতে হবে:
  উত্তর / evidence link:

- Docs change / known gap / reviewer / blocking feedback ও সমাধান / approval:
  উত্তর / evidence link:

- CI run link / merged commit / integrated verification / final issue status:
  উত্তর / evidence link:

## 5. Sync-up ও weekly review note

আগে agenda দিন, পরে decision প্রকাশ করুন; অনুপস্থিত teammate-দের জানান।

- Date / attendee / facilitator / agenda ও milestone:
  উত্তর / evidence link:

- Async update: শেষ কাজ + issue/PR; পরের কাজ; blocker + কী সাহায্য দরকার:
  উত্তর / evidence link:

- Demo / যাচাই করা acceptance criteria / actual evidence ও feedback:
  উত্তর / evidence link:

- Decision / কারণ / ADR বা issue link / unresolved question:
  উত্তর / evidence link:

- Action / একজন owner / due বা next check-in date / dependency:
  উত্তর / evidence link:

- Retrospective: কী রাখব / কী বদলাব / পরের সপ্তাহের একটি experiment / owner:
  উত্তর / evidence link:

## 6. Decision ও traceability record

শুধু diagram নয়, tradeoff বোঝান আর requirement থেকে evidence যুক্ত করুন।

- ADR ID / context / constraint / অন্তত দুটি option / choice ও কারণ:
  উত্তর / evidence link:

- Consequence / risk / reviewer / review date / কখন আবার ভাববে:
  উত্তর / evidence link:

- সংযোগ লিখুন: Requirement ID → scenario → acceptance criterion ID → issue/ADR → implementation/PR → test ID → actual result → release:
  উত্তর / evidence link:

## 7. Risk-based test plan ও run report

Implementation-এর আগে plan; test চালানোর পরেই actual result লিখুন।

- Scope / বাদ দেওয়া check ও কারণ / সবচেয়ে বড় risk / release criteria:
  উত্তর / evidence link:

- Test ID / requirement ID / risk / unit, integration, E2E বা manual / owner:
  উত্তর / evidence link:

- Setup / safe fixture / input / action বা exact command / expected outcome:
  উত্তর / evidence link:

- Run: commit/tag / runtime ও dependency version / device বা environment / date:
  উত্তর / evidence link:

- Actual outcome / PASS, FAIL, BLOCKED বা NOT RUN / safe log বা screenshot / defect link:
  উত্তর / evidence link:

- এই project-এর উপযুক্ত accessibility, permission, performance ও recovery check:
  উত্তর / evidence link:

- Retest commit / আবার চালানো affected test / peer verification / বাকি limitation:
  উত্তর / evidence link:

## 8. Reproduce করা যায় এমন bug report

কী fail করেছে এমনভাবে লিখুন যেন অন্যজন অনুমান ছাড়াই reproduce করতে পারে।

- Title / requirement বা test ID / affected commit / environment:
  উত্তর / evidence link:

- Precondition / ছোট steps ও safe input / expected result / actual result:
  উত্তর / evidence link:

- Frequency / severity ও impact / priority ও কারণ / private তথ্য বাদ দেওয়া evidence:
  উত্তর / evidence link:

- দায়িত্বশীল owner / workaround / failing regression test / fix PR / retest evidence / যাচাইকারী:
  উত্তর / evidence link:

## 9. Release, reproduction ও handover

Peer-কে নিয়ে clean environment-এ rehearsal করুন; শুধু checklist tick নয়।

- Release tag ও commit / প্রযোজ্য artifact ও checksum / owner / release note:
  উত্তর / evidence link:

- Prerequisite / exact setup-build-test command / secret ছাড়া config example / safe sample data:
  উত্তর / evidence link:

- Independent reproducer / environment / actual result / পাওয়া issue ও repair:
  উত্তর / evidence link:

- Deployment ও migration step / smoke test / backup ও restore evidence / rollback limit:
  উত্তর / evidence link:

- Known issue / safe operating limit / maintenance owner / credential প্রকাশ ছাড়া access transfer:
  উত্তর / evidence link:

- Report ও demo link / defense question / অনুমোদিত offline fallback / department sign-off:
  উত্তর / evidence link:

## 10. Contribution, source ও AI disclosure

Department ও publication rule মানুন; প্রত্যেকে কী defend করতে পারে লিখুন।

- Member / design, implementation, testing বা research contribution / evidence link:
  উত্তর / evidence link:

- ধার করা code, asset ও dataset / source / license বা permission / citation:
  উত্তর / evidence link:

- Policy-তে অনুমোদিত AI/tool assistance / কোথায় ব্যবহার / human verification / limitation:
  উত্তর / evidence link:

- নিরাপদে রাখা consent ও approval record / public report থেকে বাদ দেওয়া private তথ্য / reviewer:
  উত্তর / evidence link:

## Readiness review

- 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-এর সঙ্গে মেলে।

## Stage অনুযায়ী quality bar

### ১ · দরকারি, শেষ করা যায় এমন সমস্যা

Supervisor-এর feedback-সহ এক পাতার brief, যা পড়ে অন্য কেউ প্রজেক্টটি আবার আপনাকেই বুঝিয়ে বলতে পারে।

কোন সমস্যার সমাধান করবে সেটি বোঝানোর আগেই microservices, blockchain বা AI model বেছে বসবেন না। Technology দিয়ে নয়, সমস্যা দিয়ে শুরু করুন।

### ২ · Requirement-কে যাচাই করা যায়—এমন করুন

গুরুত্ব অনুযায়ী সাজানো requirement list ও test matrix, যেখান থেকে যে কেউ বুঝতে পারে কোনটি pass, কোনটি fail, আর কোনটি জেনেশুনে বাদ দেওয়া হয়েছে।

কারণ ছাড়া performance target বানাবেন না; সত্যিকারের পর্যবেক্ষণ ছাড়া usability যাচাই হয়েছে—এ দাবিও করবেন না।

### ৩ · সবচেয়ে ছোট সুসংগত system-টি design করুন

একজন সহপাঠী design ধরে একটি scenario-এর পথ অনুসরণ করতে, বাদ দেওয়া বিকল্পটির কারণ বলতে এবং অন্তত একটি অমীমাংসিত ঝুঁকি চিহ্নিত করতে পারে।

শুধু ‘industry-level’ দেখানোর জন্য distributed service, Kubernetes বা custom authentication যোগ করবেন না। প্রজেক্টকে জটিল করলেই সে চাকরি পেয়ে যায় না।

### ৪ · ছোট ছোট অংশে কাজ করুন, review নিয়ে এগিয়ে যান

README-এর ধাপ অনুসরণ করে fresh checkout থেকে প্রজেক্ট চলে; review হওয়া পরিবর্তনটির সঙ্গে requirement, test result ও কার অবদান—সব দেখা যায়।

Integration শেষ সপ্তাহের জন্য তুলে রাখবেন না; আর নিজের অবদান বোঝাতে না পারলে tutorial clone-কে প্রজেক্ট বলে জমা দেবেন না।

### ৫ · সফলতার পাশাপাশি failure-ও পরীক্ষা করুন

Pass/fail ফল, ঠিক করা defect-এর প্রমাণ ও বাকি ঝুঁকিসহ traceable test report। ‘Zero bug’ বা ‘পুরোপুরি secure’—এমন অবাস্তব দাবি নয়।

শুধু সংখ্যা বাড়াতে 100% coverage-এর পেছনে ছুটবেন না, failure লুকাবেন না, কাল্পনিক participant বানাবেন না, আর AI বানানো measurement-কে আসল result হিসেবে দেবেন না।

### ৬ · অন্য কেউ যেন চালাতে পারে, সমস্যা হলে ফিরিয়েও আনতে পারে

Release-এর সঙ্গে যুক্ত স্বাধীন reproduction note এবং যেখানে দরকার test করা recovery procedure।

শুধু public link দেখানোর জন্য production hosting-এ অপ্রয়োজনীয় খরচ করবেন না বা sensitive data প্রকাশ করবেন না।

### ৭ · সততার সঙ্গে বোঝান, defend করুন ও handover দিন

Report, চালানো যায় এমন artifact ও defense-এর কথা একে অন্যের সঙ্গে মেলে; নতুন maintainer পরের নিরাপদ পরিবর্তনটি বুঝতে পারে।

প্রাসঙ্গিক প্রমাণ ছাড়া student prototype-কে production-ready, paper-কে accepted বা design-কে certified বলে দাবি করবেন না।

CSE-Pothik · https://cse-pothik.com · All rights reserved