Computer Science and IT Project Guide

1. General Procedures
It’s mandatory for Students in the Bachelor's program in computer Science and IT to
complete a project to satisfy the requirements for graduation.

This section describes general guidelines for the project, including the required proposal,
topics; advisors, deadlines, associated courses, etc. Section 2 lists current faculty members
from whom an advisor must be selected and their areas of interest. Section 3 describes the
required format for the proposal. Section 4 describes the format of the required final oral
presentation of the project results. Section 5 describes the format of the written report and
documentation required for the project.

1.1 PROJECT PROPOSAL

The PROJECT PROPOSAL is the background and planning document for the project. It
must be done with professional care and thoroughness. Bachelor's students develop the
project proposal as part of project and implement.
The proposal, with a cover sheet in triplicate obtainable from the department, is submitted
to the Computer Science and IT (CSIT) department for approval. Submit the proposal on
or before the deadline date to the Department. Retain a copy of the proposal for yourself.
The intended faculty advisor for the project should be indicated.

1.2 REMARKS
The student must obtain prior approval from the expected project advisor for a project to
be undertaken.

1
A student not finding an advisor may request the department to assign an advisor or may
submit a proposal which will be assigned to an advisor by the department. There is a
department limit on the number of advisees per faculty member.
Some advisors under special circumstances allow team projects. In a team proposal, the
final project must be completed before any member of the team can receive a grade.
Furthermore, if the team breaks up, a new proposal from each member is required before
a project can proceed.

1.3 DEPARTMENT ACTION ON PROPOSAL

The CSIT Department response to the submitted proposal will be communicated to
students. The possible Department responses are:
 ACCEPTED: the student may start work on the project, but should contact the
advisor for comments and an advisement schedule;
 CONDITIONALLY ACCEPTED: the student must modify the proposal according
to the advisor's indications and approval; upon subsequent approval, the student
may then start the project;
 REJECTED: the proposal is unacceptable: the student may contact the faculty
reviewer of the proposal for advice.
Proposals that are conditionally accepted must be resubmitted to the advisor one week
before the start of the next semester.

1.4 PROJECT TOPICS

Project topics vary greatly. A topic may be suggested by an advisor to the student or by
the student to an advisor. It is important to confirm the appropriateness of a topic with an
advisor as early as possible in the development of the proposal.

2
2. PROJECT PROPOSAL FORMAT

2.1 Introduction

Use the outline on the following page in preparing your proposal. Consult with your
advisor before deviating from the standard outline; failure to do so will result in rejection
of the proposal:
2.2 Project Proposal Outline

i. Title Page
ii. Approval Page
iii. Table of Contents
1. Introduction and Background
1.1 Problem Statement
1.2 Previous Work
1.3 Background
1.4 Glossary
2. Project Description
2.1 Functional Specification
2.1.1 Functions Performed
2.1.2 Limitations and Restrictions
2.1.3 User Interface Design [if required]
2.1.4 Other User Inputs [if required]
2.1.5 Other User Outputs [if required]
2.1.6 System Data Files
2.2 Design Specification
2.2.1 System Data Flow Diagrams
2.2.2 System Structure Chart
2.2.3 System Data Dictionary
2.2.4 Equipment Configuration
2.2.5 Implementation Languages
2.3 Implementation Plan
2.3.1 Deliverable Items
3
 2.3.2 Milestone Descriptions
2.3.3 Milestone Completion Criteria
2.3.4 Schedule of Milestone Completion
3. References
4. Qualifications
4.1 Personal Background
4.2 Courses Taken
4.3 Programs Written
4.4 Investigations
4.5 Projects
5. Grading Criteria

4
2.3 Description of Outline Sections
This section describes the purpose or format of each of the sections indicated in the
preceding proposal outline.

i. Title Page
See the sample in Section 3.4 for format.

ii. Approval Page

See the sample in Section 3.4 for format.

iii. Table of Contents

This should follow the outline given in Section 3.2 of this document.

1. Introduction and Background

The purpose of this section is to describe the general problem area.

1.1 Problem Statement

Give a brief, general statement of the problem to be investigated or solved by
the project. Assume the reader has little knowledge of the subject.

1.2 Previous Work

This is an historical or conceptual survey of relevant work done in the area
by previous investigators. Each contribution must be accompanied by
appropriate references to be listed in the reference section.

1.3 Background
Here you develop the theoretical and conceptual framework upon which the
project is based. It is appropriate to describe relevant data representations
and algorithms.

1.4 Glossary

5
 This section defines all terms, concepts, symbols, and acronyms used in the
proposal.

2. Project Description
The purpose of this section is to describe the proposed project in detail: what will
you do, how will you do it, and when will you do it.

6
2.1 Functional Specification
This is a detailed specification of functions performed by the proposed
system, from an external or user perspective, not from an internal or
programmer viewpoint. Thus, the system is regarded as a black box with
various inputs and outputs related by the functions performed by the system.
The description should be sufficient for another programmer to implement the
system.

2.1.1 Functions Performed

List and briefly describe each of the functions which the system will be
designed to perform for its user: What the system will do.

2.1.2 Limitations and Restrictions

List and describe each of the internal (self) and external (environment)
limitations and/or restrictions on the range of system functions: What
will the system not do. DO NOT INSULT THE READER BY
INCLUDING ITEMS THAT WOULD NOT BE A SURPRISE.

2.1.3 User Interface Design

Give a detailed description of the system user interface including
diagrams of all the “work” windows (or screens or panes), a table of
operations for each work window, and precise descriptions of each
operation that the user would regard as unfamiliar. A work window is
one that contains data the user is editing, browsing or viewing. This
section is required for all programs that engage the user interactively.
Refer to the sample in Section 3.4 of this document.

2.1.3 Other User Inputs

Give a precise description of the other inputs to the system including
source (human or storage) syntax (format) and semantics (meaning).
Give examples. This section is required for all programs that obtain
input from their environment none interactively.
7
2.1.4 Other User Outputs
Give a precise description of the other outputs of the system including
syntax and semantics. Correlate the outputs with the inputs and the
functions performed. Give examples. This section is required for all
programs that obtain input from their environment none interactively.

8
 2.1.5 System Data Files
Give a precise description of the data files created or maintained by the
system. Thus, for example, you would include files in a database and
you would exclude executable files and text files.

2.2 Design Specification

This is a top level preliminary or provisional indication of the proposed system
architecture and flow. You should correlate system functions with system
structure and interface specifications.

2.2.1 System Data Flow Diagrams

This is a hierarchical (or leveled) set of diagrams showing the flow of
data elements into and out of the functional units of the program, data
stores and environmental sources and sinks. Labeled arrows denote
data flows. This diagram is complementary to the structure chart
described next. Refer to the sample in Section 3.4 of this document.

2.2.2 System Structure Chart(s)

This is a (set of) chart(s) showing the functional units of the system
hierarchically organized to show which units call, use or contain other
units. Each interface between two units (a call) is annotated with small
arrows and data item labels to show the data exchanged between the
units. Refer to the sample in Section 3.4 of this document.

2.2.3 System Data Dictionary

This is a comprehensive dictionary of all the data items that appear in
the system data flow diagrams and the structure charts. At a minimum
it contains, for each data item, its identifier, any abbreviation used
instead of the identifier, the name of the type of the data, and a
definition of the data item in the form of either a symbolic expression or
a precise description. Refer to the sample in Section 3.4 of this
document.
9
2.2.4 Equipment Configuration
Describe the equipment you will use to support the operation and
development of your system.

2.2.5 Implementation Languages

List the programming languages you plan to use for the implementation
of your project and give reasons for choosing each language.

10
2.3 Implementation Plan
This is a description of the plan for implementing the project. Here you
commit yourself to a course of action and specify the criteria by which your
performance is to be judged. Your final grade will depend, in large measure,
upon your success in achieving the goals agreed upon between you and your
project advisor.

2.3.1 Deliverable Items

List and describe each of the items you will submit in fulfillment of the
project requirements. Deliverable items include, but are not limited to,
program executable file(s), program data file(s), program listings,
program documentation, user manual and sample program runs.

2.3.2 Milestone Identification

Identify each of the milestones or check points that mark the
completion of some phase of project implementation. Milestones
include, but are not limited to, detailed system analysis, system design,
file design, module design, system test design, module coding, working
breadboard with stubs, and working system with stubs, system testing
and documentation.

2.3.3 Milestone Completion Criteria

List the criteria by which the completion of each milestone is to be
judged. If an objective measure is available then it should be specified.
If a personal judgement is required then indicate who will make the
determination. This information may be given in tabular form if
desired.

2.3.4 Schedule of Milestone Completion

Prepare a diagram or table giving the proposed completion date for
each of the milestones listed in the previous two sections. See the
sample in section 3.4 of this document.
11
3. References
In this section you list in standard bibliographic format the books, papers, course
notes and project or thesis reports which you have used in preparing your project
proposal.

12
2.4 Sample Sections of the Project Proposal

The following pages illustrate some of the items which each proposal should contain.

13
2.4.1 Sample Title Page

Automated Software Configuration Management and Change Control System

(SCM)

Submitted to the Department of Computer and Information Technology

Kenya Highlands University in Partial Fulfillment of the Requirements for
the Degree of Bachelor of Science in Computer Science
By
Name
(Reg. Number)

September 20

14
2.4.2 Sample Approvals Page

APPROVALS

Agree to Advise:
(Signature of Faculty Advisor)
Date Submitted:
Date Approved:
Approved by:
(Signature of Faculty Advisor)

15
2.4.3 Sample User Interface Design
Window with Two Panes
The left pane of this window contains an outline or table of contents of the material in the
right pane. The left pane may be used 1) to rapidly locate material for the right pane, or 2)
to edit and reorganize the right pane material.

This is a Window with Two Panes

File Edit View ... Help
1. First Part
1.1 Sub-part
1.2 Sub-part
1.2.1 Sub-sub-part
1.2.2 Sub-sub-part
1.3 Sub-part

2. Second Part
2.1 Sub-part
2.1.1 Sub-sub-part

Operations for Left Pane

Operation Visual Keyboard Mouse Access Menu Access
Feedback Access
Page Up See New Page Up Drag
Page Down Page Page Down Scrollbar
Row Up See Highlight Up Arrow Click On
Row Down Move Down Arrow Row
Move Divider See It Move Drag Divider
New Item See New Form Insert Edit | New
Delete Item Item Vanishes Delete Edit | Delete
New Item opens a dialog box to specify the level and identifier of the new item in the tree.

16
Delete Item deletes the highlighted item in the left pane and all its associated items in the
right pane.
Operations for Right Pane
Operation Visual Keyboard Mouse Access Menu Access
Feedback Access
Page Up See New Page Up Drag
Page Down Page Page Down Scrollbar
Row Up See Highlight Up Arrow Click On
Row Down Move Down Arrow Row
Edit Item See Edit Form Enter Dbl Clk Item Edit | Item
Edit Item opens a form for editing the item attributes.

17
 Get Bal
Bal Initial
Balance
Compute
Balance Bal
Get T
T Trans-
action
Current
Balance

2.4.4 Sample System Data Flow Diagram

2.4.5 Sample System Structure Chart

Produce
Bank
Statement

Bal Bal Bal Bal

Get Process Write
Initial All New
Balance Transactions Balance

Bal T T, Bal
Get Compute
One Current
Read Write Balance
Initial Initial Transaction
Balance Balance

Bal Bal

Read Write
2.4.6 Sample Data Dictionary One One
Data Item Transaction
Abbreviation Type Transaction
Description
Balance Bal Currency Current amount of money in account

18
Transaction T Currency Amount of deposit or withdrawal
Statement Record Balance + {Transaction} + Balance

19
 2.4.7 Sample Project Schedule
Item Start Date End Date Jan Feb Mar Apr May

Note: the month names and time bars are merely examples and are not meant to be taken
literally.
2.4.8 Sample Grading Criteria
Item Weight (%) Mark

User Interface Design 25

Software Design 30

Implementation 30

Test Plan 10

User Manual 5

Totals: 100

Grade:

Notes:
1) Identify each item by name.
2) No weight should be less than 5 percent.

20
4. PROJECT ORAL PRESENTATION FORMAT

4.1 Presentation Guidelines

An oral presentation of the project is made at the end of the semester in which the project
is completed and is prepared during that semester. The presentations are viewgraph
presentations, 15 minutes long, with a few minutes for questions. Typically, about 15
viewgraphs are required.
The schedule for the presentations is announced by the department several weeks before
the end of the semester.
Use the presentation outline below as a guide for the format of your talk. However, check
with your advisor for modifications appropriate to your project, particularly for research
and hardware projects. Generally speaking, the viewgraphs will include the following: title
page, problem statement, the functions performed by the project, input identification and
description, outputs, major data structures/files, hierarchical diagram, top-level flowcharts,
description of one or two modules (eg. purpose of module, flowchart for module, required
data structure), and conclusions.
Depending on the project, variations are possible. For example, for many projects a
carefully presented example may help clarify the presentation. For hardware projects,
hardware diagrams will be appropriate. In general:

(a) KEEP IT SIMPLE and understandable - so that when you're done the audience has
an idea of what your project problem and method of solution were. Your presentation
should make sense to a CIS peer who has no prior knowledge of your project. Keep this
criterion in mind as you develop your talk. It should be self-contained, simple, and not
bogged down with unhelpful detail.
(b) Keep the viewgraphs professionally neat, uncluttered, simple, short and to the point.
(c) If appropriate, illustrate your problem with an example. The example could illustrate
the problem itself, the tables or data needed to solve the problem, and the solution
technique.

The presentation of the example may well span several viewgraphs.

21
(d) Select an interesting module from your project and give an idea of how it works. The
flow of logic and relevant data structure can be given - but omit overly technical detail.
(e) Ask yourself: do I get across the problem, the basic issues, and how I resolve them?

22
4.2 Presentation Outline
1. Introduction and Background
 Purpose of Section: Overview of subject and project
 Level of Presentation: Introductory, general, non-technical
1.1 Problem Statement
1.2 Previous Work
1.3 Background
1.4 Brief Project Description (what and why)
2. System Functional Specification
 Purpose of Section: Detailed explanation of what the system does, not
how the function is accomplished
 Level of Presentation: System user, not programmer
2.1 Functions Performed
2.2 User Interface Design [if required]
2.3 Other User Inputs [if required]
2.4 Other User Outputs [if required]
2.5 System Files
2.6 Internal and External Limitations and Restrictions
3. System Design Overview
 Purpose of Section: Overview of system structure and operation
 Level of Presentation: CIS student peer.
3.1 System Organizational Chart
3.2 System Flow Chart (data and/or control)
3.3 System-wide Data Structures (internal)
3.4 Description of System operation
3.5 Equipment Configuration
3.6 Implementation Languages

23
4. Selected Subprogram Descriptions
 Purpose of Section: Functional (what) and operational (how)
description of selected subprogram.
 Level of Presentation: CIS student peer.
4.1 Subprogram Functional Specification
4.1.1 Functions Performed
4.1.2 Interface Specification (Arg’s, Globals, Files, etc.)
4.1.3 Limitations and Restrictions
4.2 Subprogram Description
4.2.1 Local Data Specification
4.2.2 Algorithm Description
5. Project Testing
 Purpose of Section: Functional (what) and operational (how)
 Level of Presentation: CIS student peer.
5.1 Description of Test Case Selection Procedure
5.2 Test Result Evaluation Method
5.3 Sample Test Runs
5.4 Discussion of Test Results

6. Conclusions
 Purpose of Section: Description of what you learned from working on
the project.
 Level of Presentation: CIS student peer.
6.1 Problems Encountered and Solved
6.2 Suggestions for Better Approach to Problem
6.3 Suggestions for Future Extensions to Project

24
5. PROJECT FINAL REPORT FORMAT
Check with your advisor for modifications appropriate to your project, particularly for
hardware projects. Submit the documentation, one copy to your advisor, and one copy.

YOU MUST USE THE STANDARD SPIRAL BOUND.

Please note the following:
1) The report should be printed on one side of the page, double-spaced, with wide
margins.
2) Your report must be complete when you submit it for acceptance. Pay particular
attention to include:
Title page
Faculty Advisor approval page
Contents page
Abstract page
Text
Bibliography
3) Number each sheet consecutively at the bottom of the page.
4) Headings: Chapter titles start on a new page. Chapter numerals should be Arabic, not
Roman numerals. Type the chapter number and title in upper and lower case, flush left, at
the top of the report page; leave an extra space and then begin the text. Since you will
have several levels of subheadings, distinguish one level from another in a consistent way,
such as (1, 1.1, 1.2, 2, 2.1, 2.1.1, 2.1.2, 2.2). Avoid having more than three levels of
subheadings.
5) Abstract: A brief abstract should be included before the beginning of the text.
6) Footnotes should be used sparingly and should be placed at the bottom of the page in
which they are referenced.
7) All tables and figures should be centered in the column on the paper. Table captions
should be centered above the table. All figure captions must appear centered under the
figure.
8) YOU MUST HAVE THE SIGNATURE OF YOUR PROJECT ADVISOR ON THE
FACULTY APPROVAL PAGE.

25
5.1 Report Outline
Note: Section numbers as shown are mandatory; font, indentation and main section titles
in bold are merely for clarity here and are optional.

i Title Page
ii Acceptance/Approval
Page iii Abstract
iv Key Words and Phrases
v Computing Review Subject Codes (see last page)
vi Table of Contents
1. Introduction and Background
1.1 Statement of Problem Area (brief, non-technical)
1.2 Previous and Current Work, Methods and Procedures (representative)
1.3 Background
1.4 Brief Project Description (overview of new, extended or
different functions, structure or operation)
1.5 Purpose/Objectives/justification of Project (theoretical, practical, or
educational impacts on hardware, software, or users)
2. System Functional Specification
2.1 Functions Performed (itemize and describe)
2.2 User Interface Design [if required]
2.2 Other User Input Preview [if required]
2.3 Other User Output Preview [if required]
2.4 System Data Base/File Structure Preview
2.5 External and Internal Limitations and Restrictions
Prof. Turoff requires the following items as well:
2.6 User Interface Specification
5.5.1 Interface Metaphor Model
5.5.2 User Screens/Dialog
5.5.3 Report Formats/Sample Data
5.5.4 On-line Help Material
26
 5.5.5 Error Conditions and System Messages
5.5.6 Control Functions
3. System Performance Requirements
3.1 Efficiency (speed, size, peripheral device usage)
3.2 Reliability

27
 3.2.1 Description of Reliability Measures (accuracy,
precision, consistency, reproducibility, etc.)
3.2.2 Error/Failure Detection and Recovery (failure modes, failure
consequences, error logging and reporting, manual and automatic
recovery procedures)
3.2.3 Allowable/Acceptable Error/Failure Rate
3.3 Security
3.3.1 Hardware Security
3.3.2 Software Security
3.3.3 Data Security
3.3.4 Execution Security (user validation)
3.4 Maintainability
3.5 Modifiability
3.6 Portability
3.7 Others
4. System Design Overview
4.1 System Data Flow Diagrams
4.2 System Structure Charts
4.3 System Data Dictionary
4.4 System Internal Data Structure Preview
4.5 Description of System Operation (high level)
4.6 Equipment Configuration (diagram and description)
4.7 Implementation Languages (which and why)
4.8 Required Support Software (pre-existing)
5. System Data Structure Specifications
5.1 Other User Input Specification
5.1.1 Identification of Input Data
5.1.2 Source of Input Data (NOT input device)
5.1.3 Input Medium and/or Device
5.1.4 Data Format/Syntax
5.1.5 Legal Value Specification
5.1.6 Examples
28
5.2 Other User Output Specification
5.2.1 Identification of Output Data
5.2.2 Destination of Output Data (NOT output device)
5.2.3 Output Medium and/or Device
5.2.4 Output Format/Syntax
5.2.5 Output Interpretation (meaning of output)

29
 5.2.6 Examples
5.3 System Data Base/File Structure Specification
5.3.1 Identification of Data Base/Files
5.3.2 (Sub)systems Accessing the Data Base (creating, updating, using;
frequency)
5.3.3 Logical File Structure (record formats, file organization, access
methods, rationale, examples)
5.3.4 Physical File Structure (storage device, blocking, organization,
access, etc.)
5.3.5 Data Base Management Subsystems Used (internal or external)
5.3.6 Data Base Creation and Update Procedure (if NOT by system)
5.4 System Internal Data Structure Specification
5.4.1 Identification of Data-Structures
5.4.2 Modules Accessing Structures (creating, updating, using)
5.4.3 Logical Structure of Data (format, organization, access, rationale,
examples)
6. Module Design specifications (for each module)
6.1 Module Functional specification
6.1.1 Functions Performed
6.1.2 Module Interface Specifications (input/output
arguments/global variables/files)
6.1.3 Module Limitations and Restrictions
6.2 Module operational Specification
6.2.1 Locally Declared Data Specifibations (variable dictionary)
6.2.2 Algorithm Specification (flowchart, pseudocode, decision table,
etc)
6.2.3 Description of Module Operation
7. System Verification
7.1 Items/Functions to be Tested
7.2 Description of Test Cases
7.3 Justification of Test Cases
7.4 Test Run Procedures and Results
30
7.5 Discussion of Test Results
Prof. Turoff requires the following items as well:
7.6 Evaluation of User System
5.6.1 Protocol Study
5.6.2 User Survey
5.6.3 Real Time Monitoring

31
 5.6.4 Interviews
8. Conclusions
8.1 Summary
8.2 Problems Encountered and Solved
8.3 Suggestions for Better Approaches to Problem/Project
8.4 Suggestions for Future Extensions to Project
9. Bibliography
10. Appendices
11. Program Listings
12. User Manual