BINDURA UNIVERSITY OF SCIENCE EDUCATION
FACULTY OF SCIENCE AND ENGINEERING
DEPARTMENT OF COMPUTER SCIENCE
GUIDELINES FOR THE PROJECT CSH 218
1.0 Introduction
These guidelines have been prepared for use in the identification, development and assessment of
the project course CSH218. They are meant to provide guidance to the student and project
supervisor on the nature and required components of the project. The guidelines are structured so
as to indicate the expected main activities by the student and specific areas to be looked at within
each activity in the course of the project. The activities have been further allocated individual
measures of importance (weighting). Approval of the proposed system to be done by the lecturer
before the project commencement. The lecturer shall render guidance to the student according to
the agreed schedule throughout the course of the project. Completion of phases of the project has
to meet set timelines as communicated by the lecturer.
2.0 Aim
The software development project provides a platform for students to consolidate and apply
knowledge, skills and competences learnt in other courses such as systems analysis and design,
programming to produce a complete software product.
3.0 The Model of the Project
3.1 Part 1: This is preliminary meant to ensure that students get it right from the beginning.
3.1.1 An opportunity or problem which requires a software solution has to be identified first. This
should be done with the assistance of the supervisor.
3.1.2 If the opportunity or problem is within an organization probably where you are attached, formal
communication has be made by the organization indicating their acceptance for you to work on the
project. This should be handed to the supervisor.
3.1.3 Need to come up with a topic for the project.
3.1.4 Craft a research proposal for submission to the supervisor. See 3.2 explanation and the structure
of the proposal.
3.2 General Structure of Proposal
3.2.1 Provisional Title: Proposed system/project title should be stated.
3.2.2 Problem definition: Background of the problem: Paves way for statement of the problem and
the opportunity for software development being presented by the problem. Outlines what prompted
the choice of the area. A problem statement giving a clear expression of the existing problem should be
stated.
3.2.3 Investigation and description of current system/literature on existing similar systems:
Investigation through research instruments e.g. questionnaire, record inspection, interviews and
observation. Description of what is currently happening in the existing system.
3.2.4 System Scope: Opportunity to deal with the problem and latitude of the system in the context of
the organization or environment where the system is used.
3.2.5 System Objectives: Should give specific results that the system aim to achieve. Guide in the
planning and strategizing design and development activities of the system.
3.2.6 Brief description of the proposed system: Outline of proposed system components and how it’s
going to work.
3.2.7 Feasibility study: determines whether the solution considered to accomplish the requirements
is practical, workable and cost effective. Consider technical feasibility, operational feasibility, economic
feasibility and social feasibility.
Note*: At the end of this phase a proposal document should be produced and submitted to the lecturer
for approval be commencing on the project. The proposal becomes chapter 1 of your project
documentation except the feasibility study.
3.3 Part 2: Doing the Software Development Project.
Below is the format of the software development project.
Chapter 1: Problem Identification
1.1 Introduction
1.2 Investigation and description of current system/Literature on existing similar systems.
1.3 Statement of the Problem
1.4 System Objectives
1.5 Description of the proposed system
1.6 Limitations/challenges
1.7 Scope/delimitation of the system
1.8 Definition of terms
Chapter 2: Requirements Specification:
2.1 Introduction.
2.2 Requirements analysis: Fact finding plan is made. Fact finding, recording and analysis tools are
designed.
2.3 Data requirements: System input and output. How the system will accept input i.e. through
forms, files, tables in database etc. How output will be presented i.e. screen displays, reports etc.
2.4 Processing requirements: functionality expected is specified.
2.5 Software requirements: Platform/operating system specifications and developmental software
to be used.
2.6 Hardware requirements: Minimum hardware specification required for the software to be used.
Chapter 3: Design.
3.1 Introduction
3.2 User interface design: interfaces that users will interact with are designed
3.3 Input and output design
3.4 Database design
3.5 Processes design: Note: make use of DFDs/UML in designing
Chapter 4: Coding and Testing
4.1 Introduction
4.2 Technical documentation: system code (main code snippets)
4.3 Unit and System Testing: plan and results
4.4 User testing: plan and results
Chapter 5: Implementation/Deployment
5.1 Introduction
5.2 Conversion plan
5.3 User manual
5.4 User training: plan
Chapter 6: Evaluation and Conclusion
6.1 Introduction
6.2 Evaluation of the system
6.3 Future plans/developments
4.0 Submission requirements
At the end of the project, packaged system software on a portable storage disk (e.g. dvd/cd) and bound
project documentation should be submitted. (consult with the Lecturer for any changes)
The project documentation should be 35 to 50 pages (About 7000-9000 words), typed, one and half line
spaced, font 12 (Except headings), Times New Roman.
The project is due a month before end of semester.
Part 3: Viva All students are expected to present their work on a date to be advised (usually within a
month before end of semester).
3.0 Remember to include the following in the project documentation:
3.1 Title page
3.2 Dedication
3.3 Acknowledgements
3.4 Abstract: This is a summary of the entire project, which should fit on one page giving the reader
an overview of the research done. Though this comes before Chapter one, it must be done last.
3.5 Table of Contents: Outlines the contents of the documents and should show the page numbers
to direct the reader to the right page.
3.6 Appendices: Contains material that may not be included in the actual project but saves as
evidence of what was used in the research. Examples include: fact finding tools used (questionnaires,
interview question schedules etc.), signed research proposal Tables, other correspondences.
3.7 References.
3.8 Mind your punctuation throughout the report.
3.9 Topics and subtopics should be well numbered and not bulleted.
END
