BCA_NEW · BCSP-165 · SOCIS
IGNOU BCA Project (BCSP-165): From Approved Synopsis to Final Report
The IGNOU BCA project is BCSP-165, a 12-credit Semester VI software project in the BCA_NEW programme. You post a 12 to 15 page synopsis to your Regional Director, build the approved system, then send a hard-bound report of about 100 pages for 150 marks, followed by a 50-mark viva.
The course in one view
What is the IGNOU BCA project (BCSP-165)?
The IGNOU BCA project refers to BCSP-165 Project, the 12-credit course in Semester VI of the Bachelor of Computer Applications programme (BCA_NEW and BCA_NEWOL) run by the School of Computer and Information Sciences (SOCIS) at Indira Gandhi National Open University. The BCSP-165 Project Guidelines of July 2026 require the work to include software development and to pass through the whole software development life cycle: analysis, design, coding, testing and documentation. A learner sends a proforma, the guide’s bio-data and a 12 to 15 page synopsis to the Regional Director of the Regional Centre in one of two slots a year, and starts building only after approval. The finished work is a hard-bound report of about 100 double-spaced A-4 pages excluding code, marked out of 150, and a viva-voce marked out of 50 that includes a compulsory coding demonstration.
Most pages on this course stop at the proposal. This one is about what follows it. The synopsis template in the guidelines (Annexure-2) and the report template (Annexure-3) share their first three chapters heading for heading, so an approved synopsis is already half of the final report. The other half, Chapters 4 to 6, can only be written from records kept while the software is being built and tested. That build phase is where marks are won or lost, and it is short.
| Course | BCSP-165 Project, 12 credits, Semester VI; 12 counselling sessions listed in the Programme Guide |
|---|---|
| Programme and school | Bachelor of Computer Applications, BCA_NEW (ODL) and BCA_NEWOL; School of Computer and Information Sciences (SOCIS) |
| Proposal slots | 1 April to 30 June, or 1 October to 31 December, to the Regional Director of your Regional Centre |
| Decision on the proposal | 30 days after receipt (calendar), “within four weeks” (Section IV) |
| Report windows | 1 July to 30 September after an April to June approval; 1 January to 31 March after an October to December approval |
| Viva-voce | January for reports sent July to September; July for reports sent January to March; schedule sent by letter from the Regional Centre |
| Synopsis | 12 to 15 pages, on the Annexure-2 template |
| Report | About 100 double-spaced A-4 pages excluding code, 10 per cent variation allowed; hard bound; complete code attached |
| Marks | Report 150, viva-voce 50; pass rule stated as 50 per cent in the guidelines and 40 per cent in the Programme Guide (reconciled in the FAQ) |
| Guide | Ph.D. or M.Tech. in Computer Science; or B.E./B.Tech. (CS), MCA or M.Sc. (CS) with 2 years’ experience; at most 8 BCA_NEW/BCA_NEWOL learners at a time |
| Evaluation fee | Rs 500 for project work above 4 credits, paid with the Term-End Examination form |
| Medium | English only (Programme Guide 1.4) |
Timing
How much build time does BCSP-165 approval actually leave you?
Between about 9 and 22 weeks, depending on how early in the slot your proposal reaches the Regional Centre. Section V of the BCSP-165 Project Guidelines says a learner whose proposal is approved “can commence working on it and complete it”, so the build formally starts at approval. Section I then pairs each proposal slot with exactly one report window, and that window has a fixed closing date. The gap between the two is the whole build.
The table works it out from the calendar in Section I, which promises a decision 30 days after the proposal is received. It is a planning aid, not an IGNOU schedule: it assumes the decision arrives on day 30 and the report is posted on the last day of the window, and it does not count postal time in either direction.
| Proposal received | Decision due (30 days) | Report window closes | Build time left |
|---|---|---|---|
| 1 April | 1 May | 30 September | About 21 weeks |
| 15 May | 14 June | 30 September | About 15 weeks |
| 30 June | 30 July | 30 September | About 9 weeks |
| 1 October | 31 October | 31 March | About 21 weeks |
| 15 November | 15 December | 31 March | About 15 weeks |
| 31 December | 30 January | 31 March | About 9 weeks |
The practical meaning is plain: a proposal posted in the first week of a slot buys more than twice the build time of one posted in the last week. Learners who finish the synopsis late in a slot sometimes do better to hold it and post on the first day of the next slot, provided their programme duration allows the six-month shift. The BCSP-165 guidelines say nothing about reporting in a later window than the one paired with your approval, so if you expect to miss it, ask the Regional Centre in writing before you plan around it.
One rejection costs more than a slot. Section IV allows a revised synopsis only in the next slot, so a proposal returned from the April to June slot comes back in October to December, and its build then runs to 31 March.
What is already done
Which chapters of the BCA project report are already written at approval?
Chapters 1, 2 and 3. Annexure-2 (the BCSP-165 synopsis template) and Annexure-3 (the report template) list the same headings for Introduction, Requirements and Analysis, and Basic System Design, down to 3.6 Test Cases Design. What changes after approval is the tense and the detail, plus whatever the Project Proposal Evaluator wrote in the “Suggestions for reformulating the Project” box on your proforma, which the proforma itself says “should be implemented in the report”.
| Report part (Annexure-3) | In the synopsis? | What to do after approval |
|---|---|---|
| Front matter | Mostly | Swap in the original approved proforma; add a table of figures, which the synopsis template does not list |
| 1.1 to 1.3 Background, Objectives, Purpose, Scope, Applicability | Yes | Apply the evaluator’s suggestions; keep the title exactly as approved |
| 1.4 Software and Hardware Technologies | Yes, as “to be used” | Rename to “Used” and list the versions actually used; check it still matches item 6 of the proforma |
| 2.1 to 2.3 Problem, Requirements, Conceptual Models | Yes | Expand the SRS; update DFDs and ER or class diagrams to the system as built |
| 3.1 to 3.5 Modules, Database, Procedural, Interface, Security | Yes | Replace planned designs with final schemas, flow charts and screens |
| 3.6 Test Cases Design | Yes | Keep the designs here; results go to 4.3 and 5.1 |
| 4.1 to 4.4 Implementation, Coding Details, Testing, Screens | No | Write from the code, the test log and real screenshots |
| 5.1 and 5.2 Test Reports, User Documentation | No | Write from the test log and a user walk-through |
| 6.1 to 6.3 Conclusion, Limitations, Future Scope | No | Write last; record limitations found during testing |
| Glossary, Appendix A, Appendix B | No | Appendix B can carry the complete, commented code |
Two small wording traps sit inside these templates. Annexure-2 calls the front-matter certificate a “Certificate of Authentication of Work” and Annexure-3 calls it “Certificate of Authenticated Work”, yet the only certificate printed in the BCSP-165 section is the Certificate of Originality (Section IX), which Section V and Section VI make compulsory. Bind the Certificate of Originality in every case. Section 1.4 of the same block also asks for a Gantt chart and a PERT chart under planning and scheduling; Annexure-3 gives them no heading of their own, so they sit naturally inside Chapter 2.
During the build
What should you keep while building an IGNOU BCA project?
Five working records, each of which the guidelines describe in their own sections. Section 2.7 lists “Some students do not prepare documents such as the SRS, SDD, and Test Cases” and “Some students never consider the importance of notes and documentation” among the faults SOCIS sees in submitted projects, and Section 1.0 expects the report to draw on a project logbook kept throughout the work. Kept from week one, these records become Chapters 4 to 6 with little rewriting; reconstructed in the last fortnight, they read like reconstructions.
| Build record | Described in | Feeds report sections | Annexure-1 area |
|---|---|---|---|
| Software Requirements Specification | Section 3.2: an IEEE-style outline (introduction, overall description, specific requirements, processing actions, appendices) | 2.1, 2.2 | Analysis |
| System design specification | Sections 3.3 and 3.4: architecture, data design with one table per entity and data store, interface rules, procedural design | 3.1 to 3.5 | Design |
| Commented code to a standard | Section 3.5 and Section 2.6: header comments, naming conventions, validation checks, error handling | 4.1, 4.2, Appendix B | Coding |
| Test design document and test log | Section 3.7: test plan, recording format, unit, integration, system and acceptance testing, test log | 3.6, 4.3, 5.1 | Testing |
| Project logbook | Section 1.0: progress, intermediate results, design changes, milestones | 4.1, 6.2, 6.3, viva preparation | Viva presentation |
Section 2.3.2 adds advice that most learners ignore: do not write the report in page order. Write the inner chapters while the material is fresh and write the introduction last. Section 2.5 makes the same point from the other side, saying the report “will seem less discouraging if you write continuously and prepare the documentation of each phase from the start”.
Worked example
How does one requirement travel through a BCSP-165 report?
Through nine report sections, and the evaluator reads them as one chain. The example below follows a single requirement in an imaginary BCA project, an appointment-booking system for a one-doctor dental clinic. The project is invented for illustration; the section numbers, the mapping rules and the documentation items come from the BCSP-165 guidelines.
The requirement, as it would appear in the SRS: FR-04. The receptionist shall book a free 15-minute slot for a registered patient. A slot that is already booked, a date in the past, or an unregistered patient shall be refused with a message.
| Build record | What it holds for FR-04 | Report section |
|---|---|---|
| SRS | FR-04 as stated above, under specific requirements | 2.2 Requirements Specification |
| Conceptual models | Level 1 DFD process 3.0 Book Appointment, extended at Level 2 into 3.1 Check patient, 3.2 Check slot, 3.3 Save booking, 3.4 Print slip; data store D3 Appointments; ER entity APPOINTMENT | 2.3 Conceptual Models |
| Database design | Table appointment (appt_id primary key, patient_id foreign key to patient, slot_date, slot_time, status), with a unique constraint on slot_date plus slot_time | 3.2.1 and 3.2.2 |
| Procedural design | Flow chart and algorithm for process 3.0, with inputs, outputs and the three refusal paths | 3.3.1 and 3.3.2 |
| Test case design | TC-BOOK-01 free future slot; TC-BOOK-02 slot already booked; TC-BOOK-03 past date; TC-BOOK-04 unregistered patient | 3.6 Test Cases Design |
| Code | Function book_slot() with a header comment, called from the booking form | 4.2, 4.2.1, Appendix B |
| Test results | Unit results for TC-BOOK-01 to 04; an integration test with two receptionist sessions; the system test of the full booking routine | 4.3.1, 4.3.2, 4.3.3 |
| Test log and fix | The defect found, the change made and the re-run (shown in the next section) | 5.1 Test Reports |
| Logbook | Reminders by SMS were dropped for time | 6.2 Limitations, 6.3 Future Scope |
Notice how the chain satisfies the three notes printed under Annexure-2 and Annexure-3 without extra effort: the ER entity APPOINTMENT, the data store D3 and the table appointment are the same thing under three names; the module Book Appointment is the Level 1 process 3.0; and process 3.0 is extended to Level 2. A learner who builds every module this way can answer the most common viva move, “show me where this requirement is in your code”, in under a minute.
Section 2.6 of the guidelines lists what a code comment should describe: input, output, calls to and from other functions, parameters, main variables, data types and logic. In practice that becomes a short header on every function:
# Function : book_slot
# Module : Book Appointment (Level 1 DFD process 3.0)
# Input : patient_id (int), slot_date (date), slot_time (text, HH:MM)
# Output : new appt_id on success, or a refusal message
# Calls : patient_exists(), slot_is_free(), save_booking()
# Called by : booking_form_submit()
# Tables : patient (read), appointment (read, insert)
# Logic : refuse past dates, unknown patients and taken slots;
# otherwise insert one row with status BOOKEDTesting evidence
How should BCSP-165 testing be recorded?
Separately for unit, integration and system testing, both as designs and as results, with an account of debugging and code improvement. That is the wording of Section V of the BCSP-165 guidelines, and Annexure-1 repeats it as the Testing area of the report marks. Section 2.6 adds that the reports and results of test cases are expected for all three levels, and asks how the code was debugged and what was done to improve it.
Section 3.7 of the same block supplies the recording format: each test names the item tested, the test data, the expected result and the outcome, and a test log summarises them by function. Continuing the clinic example, the log for FR-04 would show the defect a careful integration test finds:
| Run | Test cases | Run | Passed | Note for 5.1 |
|---|---|---|---|---|
| Unit, run 1 | TC-BOOK-01 to 04 | 4 | 4 | Single-user checks behave as designed |
| Integration, run 1 | TC-INT-03: two receptionist sessions book one slot at the same moment | 1 | 0 | Both bookings saved: the slot check and the insert were separate steps |
| Integration, run 2 | TC-INT-03 after the fix | 1 | 1 | Unique constraint added on slot_date plus slot_time; the duplicate-key error is now caught and shown as “slot already booked” |
That one row of failure is worth more to the report than a page of passed cases. It gives 4.3.2 a real integration test, gives 5.1 a debugging and code-improvement account, and gives 3.2.2 a constraint with a reason behind it. Section 3.6 of the guidelines suggests exactly this kind of test, “Test for locking by invoking multiple concurrent processes”, alongside deliberately entering wrong data.
BK Sahni, who has guided 5,00,000 students till date, notes that the BCA reports hardest to defend at the viva are usually the ones whose testing chapter was written after the software was finished, from memory. Examiners can tell, because every case passes and nothing was ever fixed. A log kept while testing, failures included, reads as evidence; a tidy table written in the last week reads as decoration.
Avoidable losses
Which build-phase mistakes cost marks in the IGNOU BCA project?
Section 2.7 of the guidelines lists what SOCIS keeps finding in submitted projects, and Sections V and VI add the faults that get a report returned. Read together, they cluster around the build phase:
- Requirements never frozen. Section 2.7 notes that some learners keep changing what the system should do until coding, which leads to low-quality, less reliable software. Freeze the SRS once the synopsis is approved and record later changes in the logbook.
- Coding treated as the whole job. The same section warns that many learners assume coding is the only work. Annexure-1 gives Analysis, Design, Testing and report organisation their own place in the 150 marks.
- A testing chapter made of definitions. Explaining what unit testing is earns little; Section V asks for your designs and your results, level by level.
- Code snippets instead of complete code. Section 1.4, adapted from older material, says full source code is not needed. Section V and Annexure-1, written for BCSP-165, say the opposite: attach complete code, unless the organisation you worked for refuses in a letter from its project manager. Follow the stricter rule.
- A login screen with no security account. Section V asks every report with a user name and password to explain how they are protected during transmission to the server. Section 2.6 adds database-level security such as views, grant and revoke.
- A drifting title. If the report title differs from the title on the approved proforma, the report “will be rejected and will be returned back” (Section VI, point 7).
- Padding. Section 2.7 says there is “no need to write a detail history of Java or visual basic”, and Section 2.5 asks you to avoid theory already available in reference books. The documentation should describe your project only.
- Unacknowledged tools. Section 2.7 asks learners to reference the software they used, including the development environment, compilers and libraries, as well as printed and online sources.
- Photocopies and spiral binding. Printouts of text and screens must be original, the report must be hard bound, and a photocopied report is not accepted (Sections V and VI).
The last risk is not a formatting one. The coordinator’s message states that a copied project report “will be forwarded to the Exam Discipline Committee of the University as an Unfair means case”, and Section V adds that copied synopses and reports “will be awarded very low score”. A build record kept week by week is also the simplest proof that the work is yours.
The finish
How is the finished BCSP-165 report assembled, posted and defended?
As one hard-bound original, sent by registered insured post to the Regional Director in the report window paired with your approval. Section VI of the BCSP-165 guidelines sets the sequence, and a report missing any item “will be rejected and returned to students for compliance”.
- Title page in the Appendix 1 format, naming the guide under “Under Guidance of” and the course as PROJECT COURSE (BCSP-165).
- Original approved proforma, every item filled, signed and dated by you and your guide.
- The synopsis, signed by both of you, and the guide’s bio-data, signed by the guide.
- Certificate of Originality in the Section IX format. Every signature in the report carries a date.
- Chapters 1 to 6 on the Annexure-3 template, about 100 double-spaced A-4 pages excluding code, with a contents page and numbered pages, followed by references, glossary and appendices with the complete code.
- Post one original with “BCA_NEW/BCA_NEWOL PROJECT REPORT (BCSP-165)” on top of the envelope, and send the guide’s remuneration form, signed by the guide and by you, in a separate envelope with it.
- Keep an identical copy. Section VI says you are “supposed to carry” it to the viva-voce.
Section 2.5, carried over from older course material, mentions single line spacing and submission at the Study Centre. Section VI, written for BCSP-165, says double spacing and the Regional Director. Follow Section VI. How submission routes differ across other programmes is set out in the programme-by-programme IGNOU project hub.
The viva then tests the build directly. Annexure-1 says the coding demonstration is a must and carries significant weightage, and Section 2.6 says you may be asked to write code for a problem, or any segment of the code printed in your report. The build records double as rehearsal material: walk one requirement from 2.2 to its code, run one passing and one failing test case from your log, and explain the defect you fixed. Annexure-1 also marks your explanation of the subject area behind the project, so know the clinic, shop or office your software serves as well as you know its tables.
Quick answers
IGNOU BCA project: frequently asked questions
What is the course code for the IGNOU BCA project?
BCSP-165, also typed as BCSP 165, BCSP165 or BCSP-165 project, for BCA_NEW and BCA_NEWOL learners. Learners on the older BCA (Revised) syllabus have BCSP-064, an 8-credit course with its own guidelines. The BCA_NEW Programme Guide still tells learners to adhere to the BCSP-064 guidelines, but the July 2026 BCSP-165 block is the newer, course-specific document for anyone whose registration shows BCSP-165.
How many pages should the IGNOU BCA project report be?
About 100 double-spaced A-4 pages excluding program code, with 10 per cent variation either way, under Section V of the BCSP-165 guidelines. The synopsis is 12 to 15 pages.
What are the passing marks for the IGNOU BCA project?
The two July 2026 documents differ. Section V of the BCSP-165 guidelines asks for 50 per cent separately in the report (75 of 150) and the viva-voce, printing the viva minimum as “50/100” although the viva carries 50 marks. The BCA_NEW Programme Guide (Version 2.0) sets 40 per cent in each, 60 of 150 and 20 of 50. Aim for at least 75 and 25.
Can the software be changed after the BCA synopsis is approved?
The guidelines do not say. Item 6 of the proforma records the software, and Section 1.4 of the report lists the software actually used. A changed title gets the report returned under Section VI, but no rule covers a changed tool. A new version of the same tool rarely matters; a different language or database alters the design the evaluator approved, so agree it with your guide and ask the Regional Centre in writing before switching.
Does IGNOU publish a list of BCA project topics?
No. The BCSP-165 guidelines set conditions instead: software development is compulsory, the topic should be complex and large enough to justify a BCA project, and only one student may work on a project. Learners planning IGNOU’s MCA should note that its project guidelines ask them not to repeat the BCA topic.
Is complete source code compulsory in the BCA project report?
Yes, under Section V and Annexure-1, which say you must attach complete code. The only exception is a project done for an organisation that refuses permission, in which case a letter from its project manager and a detailed specification take the code’s place.
Can the IGNOU BCA project report be submitted online?
The BCSP-165 guidelines describe one route: a hard-bound original by registered insured post to the Regional Director. IGNOU’s online project portal for June 2026 asks for a scanned PDF and names only DECE04 as an exclusion, without mentioning BCA. The course-specific guidelines are the safer basis; confirm with your Regional Centre whether an upload is also expected in your session.
Verify before you act: the full 77-page BCSP-165 Project Guidelines on eGyanKosh carry the calendar, proforma, Certificate of Originality and Annexures 1 to 3, and the BCA_NEW Programme Guide on ignou.ac.in carries the programme structure and evaluation scheme. Dates, fees and routes change by notification, and the newest notice from SOCIS or your Regional Centre prevails over this page.
If the work has stalled between approval and the report window, a check of Chapters 4 to 6 against the Annexure-3 template, and of the trace from requirements to tests, can save a full slot. Details are on the ignouproject.shop project pages.
Independent study-help disclosure: ignouproject.shop is run by Shri Chakradhar Publication Pvt. Ltd. and is not the official website of IGNOU or SOCIS. This article summarises published university documents for guidance only; official notifications on ignou.ac.in prevail over anything written here.
BK Sahni iD 0009-0005-8092-459X
Founder, Shri Chakradhar Publication Pvt. Ltd. & its IGNOU Project study-help brand, helping IGNOU distance-learning students since 2010 and having guided 5,00,000 students till date across MBA, MCom, MA & more. Author of IGNOU exam guides, solved assignments & project reference books.
Disclosure: Shri Chakradhar Publication Pvt. Ltd. and ignouproject.shop are independent third-party study-help services, not the official IGNOU website. Always verify final dates and rules on ignou.ac.in.
Leave a Reply