TechVani: Semester 7 Electives and Minor Project Guide

Semester 7 - Page 4: Electives and Minor Project. 24 numbered practical topics, highlighted rules, worked cases, answered viva questions, workflow diagrams, evidence tables and a complete Python task-rule demo. General practical guide, not an official lab list, syllabus or submission rule. Match stack and assessment requirements to your current faculty handout.

Offline demo: Python 3, standard library only; nine behavior assertions are executed. It has an in-memory store and simulated owner names, not real authentication, API or durable storage. The practical index and capstone links below provide further resources, not a claim about this term required experiments.

Topic map

Current elective basket and prerequisites
Comparing electives by evidence
Indicative specialization themes
Minor versus major project scope
Problem statement and stakeholders
Feasibility and data access
Focused vertical slice
Requirements and acceptance tests
Literature and prior-work review
Architecture and boundary contracts
Data schema and privacy
Baseline and measurable comparison
Machine-learning split and leakage
Image-processing practical evidence
Big-data practical boundaries
Planning, milestones and dependencies
Version control and contribution evidence
Runtime, setup and dependency notes
Testing positive and negative paths
Results, units and limitations
Runnable rule contract demo
Report structure and citations
Demo, viva and fallback
Final checklist and next scope

1. Current elective basket and prerequisites

An elective must belong to the current approved scheme and satisfy prerequisites, credits and timetable requirements. Generic examples do not establish availability.

Worked example: A vision course fits a student's interest only if offered and supported this term.

Exam question: Can this page guarantee a specific Semester 7 credit structure?
Answer: No. Check current official rules.

2. Comparing electives by evidence

Compare interest, prior preparation, goals and support after eligibility checks. Scores are a discussion aid, not a universal ranking.

Worked example: Scores 5+4+5+4=18 versus 3+2+3+3=11 organize one student's preferences, not every student's choice.

Exam question: Does a higher score override a missing prerequisite?
Answer: No. Mandatory constraints come first.

3. Indicative specialization themes

Vision/learning, cloud/distributed systems, security and embedded systems suggest different skills, not guaranteed jobs or actual course titles..

Worked example: A security direction builds on networking/programming while vision often needs mathematical/image foundations.

Exam question: Does taking one elective guarantee its associated role?
Answer: No. Skills, evidence and hiring context matter.

4. Minor versus major project scope

Project names, timing, team size and deliverables depend on department rules. A minor project commonly offers a focused end-to-end learning build, without a universal size guarantee.

Worked example: One tested booking workflow is clearer than claiming an entire commercial platform.

Exam question: Does a generic guide fix every college's team size?
Answer: No. Follow the actual scheme.

5. Problem statement and stakeholders

State who needs what outcome, current alternatives and measurable boundaries. Avoid starting with a stack before validating the problem.

Worked example: A study reminder project targets missed tasks for a defined group rather than claiming to solve all student productivity.

Exam question: Can a technology list replace a problem statement?
Answer: No. It does not define value or acceptance.

6. Feasibility and data access

Verify required data, licenses, tools, compute and permission before committing scope. Public-looking data is not automatically usable without restrictions.

Worked example: A crop-price example needs a confirmed accessible dataset, units/date coverage and permissible reuse before forecasting claims.

Exam question: Does mentioning a dataset prove it exists and can be used?
Answer: No. Inspect the actual source and terms.

7. Focused vertical slice

Build one complete input-to-result workflow with error handling before extras. A working core should be demonstrable without unbuilt optional features.

Worked example: Accept a task, persist it, display it after restart and enforce caller rights before adding recommendation features.

Exam question: Does a rendered dashboard prove its backend works?
Answer: No. Verify actual state through the claimed path.

8. Requirements and acceptance tests

Write testable behavior, input constraints, permission rules and failure outcomes. Keep optional ideas separate from required acceptance.

Worked example: An invalid blank title should not create data and should retain useful input/error feedback.

Exam question: Can all requirements be described as fast/user-friendly only?
Answer: No. Define observable criteria and measurement conditions.

9. Literature and prior-work review

Compare relevant existing work with citations, strengths and limits. Explain an honest difference rather than claiming novelty because the UI is new.

Worked example: A standard library workflow with one measured improvement is an acceptable scoped claim, not a new algorithm.

Exam question: Does changing labels make copied work original research?
Answer: No. Attribution and actual contribution matter.

10. Architecture and boundary contracts

Separate UI, API/domain logic, persistence and external services with explicit data/error contracts. Choose complexity justified by the problem.

Worked example: If storage fails, the UI must not report a confirmed saved task merely because its card rendered.

Exam question: Does a local function test establish a hosted API contract?
Answer: No. Test the actual boundary too.

UI input -> API/domain contract
         -> identity + object rules
         -> durable stored state
         <- verified result/error

One vertical slice needs real boundary evidence, not only a rendered card.

11. Data schema and privacy

Define identifiers, types, units, relationships and retention; use minimal synthetic data in demos unless real data use is authorized..

Worked example: A task ID and owner relationship needs a server-enforced permission check; logs should not expose secrets.

Exam question: Does replacing names with numbers guarantee anonymity?
Answer: No. Linkability can remain.

12. Baseline and measurable comparison

Use a simple baseline and consistent data/test conditions before claiming improvement. Metrics depend on the intended user/problem.

Worked example: A forecast compares against an appropriate naive time baseline rather than only reporting low training error.

Exam question: Does one impressive score without a baseline prove improvement?
Answer: No. It lacks context and may hide leakage.

13. Machine-learning split and leakage

Split by subject/source/time where required and fit preprocessing on training only. Preserve a genuinely final test from repeated tuning.

Worked example: Future outcome aggregates cannot be features for earlier predictions; near-duplicate subjects across splits can inflate results.

Exam question: Can a pipeline fix a wrongly chosen split automatically?
Answer: No. Split design remains your responsibility.

Allowed historical features
 -> relevant unit/time split
 -> train-only fitting
 -> validation choices
 -> frozen final test

No future outcome enters an earlier prediction feature.

14. Image-processing practical evidence

Record channel order, dtype, range, border/kernel and coordinate conventions. Inspect actual images before claiming visual improvement.

Worked example: A synthetic median calculation is useful but does not prove a noisy-photo restoration pipeline.

Exam question: Can a console number claim rendered-image quality?
Answer: No. Pixel evidence and task-relevant evaluation are needed.

15. Big-data practical boundaries

Distinguish local finite calculations from actual distributed execution. State schema, retry, window and sink policies when using frameworks.

Worked example: A Python grouping demo proves its output on toy input, not Spark cluster scaling or exactly-once effects.

Exam question: Does a successful toy sum prove distributed failure tolerance?
Answer: No. Test that environment and boundary separately.

16. Planning, milestones and dependencies

Use an illustrative timeline adjusted to the actual deadline, dependencies and team capacity. Reserve testing/report time, not only implementation time.

Worked example: Data access and baseline acceptance should precede a large feature sprint; blocked external dependencies need an alternate plan.

Exam question: Can a generic thirteen-week plan override a shorter official deadline?
Answer: No. Re-plan against the real schedule.

17. Version control and contribution evidence

Keep meaningful commits/issues and documented module ownership. Repository history supports work evidence but does not establish every author's understanding.

Worked example: Each member explains their implementation/tests and credits external code rather than relying on one shared final upload.

Exam question: Does commit count measure contribution quality directly?
Answer: No. Content and actual work matter.

18. Runtime, setup and dependency notes

State exact setup commands, runtime/dependency versions and configuration without exposing secrets. Test from a clean checkout/environment.

Worked example: A Node web server, browser app and Python console script have different execution requirements.

Exam question: Does code copied into any online compiler necessarily run?
Answer: No. Runtime and system capabilities differ.

19. Testing positive and negative paths

Test valid inputs, invalid types/values, permissions, duplicates, missing state and controlled failure. Assertions must correspond to actual executed behavior.

Worked example: The synthetic task demo rejects blank titles, denies other owners and checks repeated completion under an explicit rule.

Exam question: Does one happy-path screenshot establish reliability?
Answer: No. Negative and integration paths remain.

20. Results, units and limitations

Report actual measured values with input/environment/method and uncertainties. Separate verified behavior, simulation and planned features.

Worked example: A local in-memory success is reported as local/in-memory rather than durable authenticated deployment.

Exam question: Can an unimplemented feature appear as a completed result?
Answer: No. Label future scope honestly.

21. Runnable rule contract demo

A small offline contract test can isolate business logic, but simulated identity/in-memory storage do not replace actual authentication/persistence..

Worked example: The code below executes nine task behavior assertions and prints one stored synthetic task.

Exam question: Does its owner string authenticate a real person?
Answer: No. It is a teaching argument only.

Nine local task-rule assertions with simulated identity

tasks = {}
next_id = 1

def create(owner, title):
    global next_id
    if not isinstance(title, str) or not title.strip():
        return "invalid title"
    key = next_id
    tasks[key] = {"owner": owner, "title": title.strip(), "done": False}
    next_id += 1
    return key

def complete(user, key):
    if key not in tasks:
        return "not found"
    if tasks[key]["owner"] != user:
        return "forbidden"
    tasks[key]["done"] = True
    return "completed"

assert create("Asha", "  ") == "invalid title"
assert len(tasks) == 0
key = create("Asha", " Revise subnetting ")
assert key == 1 and tasks[key]["title"] == "Revise subnetting"
assert complete("Ravi", key) == "forbidden"
assert tasks[key]["done"] is False
assert complete("Asha", key) == "completed"
assert complete("Asha", key) == "completed"
assert len(tasks) == 1
assert complete("Asha", 999) == "not found"
print("9 behavior assertions passed")
print("stored tasks:", len(tasks))
print("task:", tasks[key])
print("In-memory rule demo only; no real identity, API or durable database.")

Checked output:

9 behavior assertions passed
stored tasks: 1
task: {'owner': 'Asha', 'title': 'Revise subnetting', 'done': True}
In-memory rule demo only; no real identity, API or durable database.

22. Report structure and citations

Follow the official format, using a clear problem, prior work, requirements, design, implementation, tests, results, limits and sources. Include original contribution.

Worked example: Actual output and error cases are stronger than screenshots alone when executable evidence is required.

Exam question: Does a generic chapter list guarantee submission compliance?
Answer: No. Check the current rubric/template.

23. Demo, viva and fallback

Prepare one complete verified story, one failure case, architecture explanation and personal contribution. A fallback video/local run is support, not guaranteed marks.

Worked example: If Wi-Fi fails, a recorded/local verified path illustrates work while the hosted outage is described honestly.

Exam question: Can fallback evidence prove the unavailable hosted system is currently working?
Answer: No. It proves only the recorded/local state.

Demo: one complete story
   -> failure/permission case
   -> actual tests/results
   -> limits + contribution

Fallbacks do not establish unverified hosted behavior.

24. Final checklist and next scope

Reconcile promised features with actual results, clean setup, privacy, attribution and official rules before submission. Extend only after core acceptance.

Worked example: A minor project's next major-project step may deepen evaluation/reliability rather than add unrelated features.

Exam question: What makes the final handoff trustworthy?
Answer: Reproducible verified work, clear limits and honest source/contribution evidence.

Project evidence

Area	Practice	Evidence
Requirements	One focused workflow	Positive/negative acceptance cases
Learning	Baseline and relevant split	Metric counts and leakage controls
Images	Explicit pixel conventions	Actual image results plus limits
Data processing	Schema and retry/window policy	Exact semantics and runtime boundary
Team/report	Citations and contribution	Clean setup, actual work and honest scope

Test matrix

Case	Expected	Actual evidence needed
Valid create	One stored task	Response + durable readback
Blank title	No write; useful error	Input/result + unchanged state
Other owner	Server denial	Actual object permission test
Repeated completion	Stated consistent behavior	Duplicate-operation check
Storage failure	No false success	Controlled failure + retained input
Lost response	Reconcile commitment	State/idempotency check

Runtime distinctions

Exercise	Environment	Limit
Browser DOM	Browser HTML/JS	Not plain Node console
Node HTTP	Node + permitted port	Not every online compiler
Portable C calculation	C compiler	Not POSIX socket evidence
POSIX loopback socket	Suitable local OS/network	Requires permission/process support
C# GUI	Course Windows framework	Console compile is not GUI proof
Offline Python rules	Python3	No actual authentication/persistence

Submission and viva checklist

Verify required experiments and format, run setup from a clean state, keep actual outputs and error cases, cite data/code, credit contributors and remove secrets/private records. Present only features that actually work. No elective list is inferred from a generic semester hub.

Resources and sources

Existing practical links are preserved. Core notes explain the theory; linked lab files specify their own code and runtime assumptions.