BCA Fourth semester Project I Guide: Proposal, Format & Report Structure

Every BCA fourth semester student at Tribhuvan University has to clear Project I (CACS256) — and most of the confusion around it comes down to one thing: not knowing the exact structure TU expects, from your very first proposal all the way to your final report and viva. This guide breaks down the whole process step by step, using the official TU syllabus as the source, so you can follow it without guessing.

1. What the Course Is Actually Testing

The course description is direct about this: it expects you to practically apply what you’ve learned across your first two years, and it explicitly encourages you to go beyond the syllabus to make your project “more realistic and technically sophisticated.” Specifically, TU wants to see that you can:

• Lead a software project from start to finish
• Work in a team (individually or in pairs of two)
• Use CASE tools appropriately
• Write and test your own code, including test cases
• Identify and solve problems independently
• Write a proper report and present it confidently

2. The Three Phases

Your entire semester is structured around three checkpoints. Missing or badly handling any one of them costs you marks directly.

3. Choosing and Scoping Your Project

You can build a desktop, web, or mobile application using any language or technology you’re comfortable with from your first four semesters — you’re not restricted to what’s officially covered in class. Popular categories include:

• Information systems (student management, inventory, library systems)
• E-commerce portals
• Game applications
• Any application involving CRUD operations or a more sophisticated algorithm

Two things the syllabus is explicit about: use appropriate CASE tools during development, and write your own modules rather than relying on third-party APIs or plugins, except where genuinely unavoidable.

The Four Development Phases to Focus On

Whatever you build, your work (and your report) should visibly move through these stages:

1. Problem Identification
2. System Analysis — feasibility study, system requirement specification (SRS)
3. System Design — architecture design, interface design, database/procedure/algorithm design
4. Implementation and Testing

4. How You’re Evaluated

Out of 100 total marks, here’s exactly how they break down:

Of the 100 marks, 80 count as internal assessment (stages 1 and 2) and 20 as external assessment (stage 3, the viva). Importantly, you have to pass the internal and external portions separately — scoring well overall doesn’t save you if you fail one half.

The evaluation committee itself consists of your project supervisor, the HOD/Coordinator, an internal examiner (regular faculty), and an external examiner from the university, and they’re jointly assessing your presentation skills, viva performance, project demonstration, report quality, level of work, and teamwork.

5. What Goes Into the Proposal

The proposal has a fixed, prescribed content flow. Don’t add extra chapters or skip any of these:

1. Introduction
2. Problem Statement
3. Objectives
4. Methodology
   • Requirement Identification (study of existing system, requirement collection)
   • Feasibility Study (technical, operational, economic)
   • High-Level Design of System (flowchart / methodology / working mechanism)
5. Gantt Chart (showing the project timeline)
6. Expected Outcome
7. References

6. What Goes Into the Final Report

The final report is a different, larger document from the proposal. Its prescribed structure is:

The Five Main Chapters

This is the part students most often get wrong — the main report isn’t freeform, it follows a fixed chapter structure:

Chapter 1: Introduction

• 1.1 Introduction
• 1.2 Problem Statement
• 1.3 Objectives
• 1.4 Scope and Limitation
• 1.5 Report Organization

Chapter 2: Background Study and Literature Review

• 2.1 Background Study — fundamental theories, general concepts, and terminologies related to your project
• 2.2 Literature Review — a review of similar projects or research done by others

Chapter 3: System Analysis and Design

• 3.1 System Analysis
  • 3.1.1 Requirement Analysis — functional requirements (use case diagram/list) and non-functional requirements
  • 3.1.2 Feasibility Analysis — technical, operational, economic, schedule
  • 3.1.3 Data Modelling (ER Diagram)
  • 3.1.4 Process Modelling (DFD)
• 3.2 System Design
  • 3.2.1 Architectural Design
  • 3.2.2 Database Schema Design
  • 3.2.3 Interface Design (UI / interface structure diagrams)
  • 3.2.4 Physical DFD

Chapter 4: Implementation and Testing

• 4.1 Implementation
  • 4.1.1 Tools Used (CASE tools, programming languages, database platforms)
  • 4.1.2 Implementation Details of Modules (description of procedures/functions)
• 4.2 Testing
  • 4.2.1 Test Cases for Unit Testing
  • 4.2.2 Test Cases for System Testing

Chapter 5: Conclusion and Future Recommendations

• 5.1 Lesson Learnt / Outcome
• 5.2 Conclusion
• 5.3 Future Recommendations

7. Referencing and Citation

TU draws a clear line between two things students often mix up:

• References — every article, book, or URL you actually cited in the document
• Bibliography — sources you studied but didn’t directly cite (only include this section if it applies)

All in-text citation and reference listing must follow the IEEE referencing standard. The full IEEE format specification is publicly available online if you need the exact citation syntax.

8. Report Format Standards

These formatting rules apply to both the proposal and the final report, and examiners do check them.

9. Binding and Final Submission

• Copies required: 3 total — one for the college library, one for yourself, and one for the Dean’s Office
• Binding: gold-embossed lettering with black binding
• Where it goes: the final, approved, signed copy is submitted to the Dean’s Office, Exam Section, FOHSS

Every stage of Project I — proposal, mid-term, and final — is graded against this same document, so keeping your own copy of it open while you write saves you from the most common mistake: building a good project but losing marks on structure and formatting that had nothing to do with your actual work. If you want, share your project idea and I can help map it directly onto this chapter structure, section by section.