Project I
Semester IV · BCA 256 · 2 credits
0 / 5
chapters done
-
The syllabus asks for
- What Project I is, and what it is not
- Where good ideas come from
- Writing the problem statement
- Scope: what is in, and what is out
- Feasibility: can this really be finished?
- The project life cycle used in this book
- Eight reasons student projects fail, and the cure
Key points
- A good Project I is small, finished and explained; it is judged on method, not size.
- Ideas come from real problems; a funnel with three gates leaves one project.
- The problem statement carries numbers; objectives are SMART; the scope table says what is out.
- Feasibility is technical, economic, operational and schedule; a weighted score makes the decision.
-
The syllabus asks for
- Work breakdown and estimates
- Critical path: the tasks that cannot slip
- Task boards, stand-ups and pair programming
- Roles in a student team
- Version control with Git
- Eight practices of a team that finishes
Key points
- A WBS with durations and dependencies gives a schedule; the critical path shows what cannot slip.
- A Gantt chart shows the plan, a Kanban or Scrum board shows today.
- Roles are shared but every member must know every module.
- Git gives history, branches, merges and backup; main always works.
-
The syllabus asks for
- Requirements: what the system must do
- Use-case diagram
- Data-flow diagrams: how data moves
- The ER diagram and the database schema
- Screen design: wireframes
- Eight benefits of designing before coding
Key points
- Requirements are written as testable functional and non-functional statements.
- Use-case diagrams show actors and functions; DFDs show data movement at level 0 and level 1.
- The ER diagram becomes the schema; foreign keys protect the data (a real script proved it).
- Wireframes and a design-first habit save weeks of rework and help in the viva.
-
The syllabus asks for
- Structure: three layers
- The CampusShelf logic layer
- Kinds of testing
- Test cases linked to requirements
- Automated tests with unittest
- Defects and the bug life cycle
- Eight reasons to test early and often
Key points
- Separate screen, logic and data so that parts can be built and tested alone.
- The CampusShelf logic layer runs: hashed login, 14-day loans, Rs 2 fines, overdue list.
- Test cases are tied to requirements; unittest automates them (8 of 8 pass).
- A bug log with steps to reproduce, severity and status keeps fixing organised.
-
The syllabus asks for
- The shape of a project report
- Budgeting the writing
- Writing, figures and references
- The ten-minute presentation
- The demo script
- Twelve viva questions, with model answers
- An illustrative marking rubric
- Eight habits of a good viva
Key points
- The report mirrors the phases of the project; write each chapter when its phase ends.
- Number figures and tables, use one reference style, and never copy without credit.
- A ten-minute talk has about eight slides and a rehearsed demo with a backup.
- In the viva, speak in numbers, explain from whole to part, admit limits and know every module.
No chapter matches. Try another word.
The paper
TU assessment: 60% final examination set by the university, 40% internal (assignments, lab work, attendance). Confirm the split in your college's notice.