proposal doc

21
1 PROPOSAL DOCUMENT Online course Registration System PROJECT PROPOSAL DOCUMENT NAME: ADM NO: E-mail: UNIT NAME: PROJECT UNIT CODE: SUPERVISOR: 1

Upload: victor-kariuki

Post on 23-Feb-2015

672 views

Category:

Documents


7 download

TRANSCRIPT

Page 1: Proposal Doc

1 PROPOSAL DOCUMENT

Online course Registration System

PROJECT PROPOSAL DOCUMENT

NAME:

ADM NO:

E-mail:

UNIT NAME: PROJECT

UNIT CODE:

SUPERVISOR:

This project is submitted in partial fulfillment of the requirements governing the

award of Bachelor of Science Degree in Information Technology

1

Page 2: Proposal Doc

2 PROPOSAL DOCUMENT

Contents

Chapter 1: Introduction....................................................................................................................3

Background..................................................................................................................................3

Problem statement.......................................................................................................................4

Justification..................................................................................................................................4

Access..........................................................................................................................................4

Records Management..................................................................................................................5

Features........................................................................................................................................5

Benefits........................................................................................................................................5

Considerations.............................................................................................................................5

Project scope................................................................................................................................5

System......................................................................................................................................5

Technology..............................................................................................................................5

Environment............................................................................................................................5

Chapter 3: Literature Review...........................................................................................................6

Case Study 1.................................................................................................................................7

Case Study Background...........................................................................................................7

Course Registration System Problem Statement.........................................................................7

The Role of Tools........................................................................................................................7

Project Summary.........................................................................................................................8

The Inception Phase.....................................................................................................................8

Business Goals and Needs.......................................................................................................8

Case Study 2.................................................................................................................................8

Problem Statement.......................................................................................................................8

Use Case Model...........................................................................................................................9

List of Use Cases (grouped by actors).....................................................................................9

Use Case Descriptions (brief)..................................................................................................9

Register for Courses Use Case..............................................................................................10

Chapter 3: Methodology................................................................................................................11

Research methods to be used.....................................................................................................12

2

Page 3: Proposal Doc

3 PROPOSAL DOCUMENT

Questionnaires.......................................................................................................................12

Interviews..............................................................................................................................13

Observations..........................................................................................................................13

Resources required for the project.............................................................................................13

Hardware platform.................................................................................................................13

Software platform..................................................................................................................14

Choice of programming tools....................................................................................................14

Project schedule.........................................................................................................................14

Conclusions................................................................................................................................15

References..................................................................................................................................15

Bibliography..........................................................................................................................15

Chapter 1: Introduction

Background

Pls write something about cooperative Bank and the training school and the link between the two

3

Page 4: Proposal Doc

4 PROPOSAL DOCUMENT

Problem statement

There is a widespread agreement that the policy in course registration is very complicated,

costly, take-time, and inconvenient to both Co-op Staffs and the institution offering the courses.

This is due the fact that at the beginning of each semester/ training session, the institutuions has

to pause or delay some activities to spend time for course registration of the Co-op Staffs. Some

staffs have to prepare for offering courses list (including selecting courses and inviting lecturers

…), print it out, and deliver the registration form to each Co-op Staff. After around one week, all

Co-op Staffs’ registration form will be returned. And the staffs have to input Co-op Staffs’

registration information to files. They also have to check manually whether the registration form

of each Co-op Staff is legal or not basing on some conditions such as prerequisite course,

maximum and minimum number of credits allowed to register … If there is anything wrong or

Co-op Staffs want to add or drop the courses, everything in the above process has to be restarted.

And sometimes some papers are lost when documents are moved from one place to another

place; both Co-op Staffs and institution have to spend time for retrieving necessary information

and approve it. However, it is impossible to do that in some cases.

In addition, managing Co-op Staffs’ academic history… are also thorny issues. Mistakes can

occur anytime. Co-op Staffs’ transcript management is also another issue. When Co-op Staffs

want to have transcript to see their academic history, they have to wait at least two weeks to

receive it from tutors.

Those are some typical examples for the inconvenience and complication of the current course

registration policy. They lead institutions to the decision of building Online Course Registration

System to improve effectiveness, reduce time and cost in course registration process.

Justification

Access

On line registration is easier and more efficient. Rather than holding a registration day in

an auditorium, with paper forms and manual filing, the on line system allows co-op staff

to browse a list of courses at an educational institution's web site. They can then choose

and register for their courses without having to appear in person.

4

Page 5: Proposal Doc

5 PROPOSAL DOCUMENT

Records Management

An on line course registration system can capture and store course registrations in real

time. These records are used to determine when a course is full, and for assessing the

demand for a specific class and instructor.

Features

Online registration websites can provide more details and often include graphic and

multimedia information for registrants. Most registration websites are database systems

that automate the collection, tabulation and reporting of registrant information.

Benefits

Online registration offers round-the-clock access to the registration process. It also allows

students to access registration data in real time. They can review registration requests as

they occur and prepare for events accordingly.

Considerations

The benefits of online registration are greater for larger events that occur on a regular

basis. The cost of developing a registration system, or of using a registration vendor,

should be weighed against the cost of using a manual system for smaller or less frequent

events.

Project scope

SystemThis project focuses on Course Registration System for Co-operative Bank staff.

TechnologyWe will be using a webbased technology with php as the programming language and

Mysql as the back end database

EnvironmentThis project will be tested at Co-op Bak management centre .

5

Page 6: Proposal Doc

6 PROPOSAL DOCUMENT

Chapter 3: Literature Review

Several registrations systems are used in the universities and colleges, some of them

support the online registration features and some do not. Some of these systems were purchased

by local or international software companies, and some are developed internally by the software

development teams in the computer centers each in the relevant university or college.

What makes this registration system almost distinguished when compared to others, is that it’s a

Special-Purpose Registration System. First of all, the system is explicitly used to enroll students

to the training center, here, courses are grouped into

Supervisory skills

6

Page 7: Proposal Doc

7 PROPOSAL DOCUMENT

Pressentation skills

Induction / teller

Debt collection

Case Study 1

Case Study Background

Course registration at the local university is currently done by hand. Students fill out forms that contain their course selections and return the forms to the registrar. Clerks then enter the selections into a database and a process is executed to create student schedules. The registration process takes from one to two weeks to complete.

The university decided to investigate the use of an online registration system. This system would be used by professors to indicate the courses they would teach, by students to select courses, and by the registrar to complete the registration process.

Course Registration System Problem Statement

At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.

The new on-line registration system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system, so the student can be billed for the semester.

Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offering.

For each semester, there is a period of time that students can change their schedules. Students must be able to access the on-line system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time.

The Role of Tools

Any software development method is best supported by a tool. This book uses the tool Rational Rose 4.0. Rational Rose is organized around the architectural views - use case, logical,

7

Page 8: Proposal Doc

8 PROPOSAL DOCUMENT

component and deployment. This case study will map the steps of the process into the views contained in the tool.

Project Summary

This system will have a short inception phase during which prototyping is used to select the database. The use case diagram is started in the inception phase and matured in the elaboration phase. By the end of the elaboration phase, an architectural iteration is complete. The system is evolved in the construction phase in two iterations. The process components of requirements analysis, design, implementation and test are used in all phases of the project lifecycle.

The Inception Phase

Business Goals and Needs

The first question to address is the need for a new registration system. Does the University have the resources needed to design and implement the new system? In addition to the assessment of need for the system, the risks posed by the new system are elaborated. In the case of an on-line registration system, one of the major risks is the ability to store the information in a manner that is easily and quickly accessible by all.

For the purposes of this case study it was decided that the new system should be built. Prototypes were completed to address the database risks.

Case Study 2

Problem StatementAt the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.

The new on-line registration system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the

8

Page 9: Proposal Doc

9 PROPOSAL DOCUMENT

registration system sends information to the billing system, so the student can be billed for the semester.

Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offering.

For each semester, there is a period of time that students can change their schedules. Students must be able to access the on-line system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time.

Use Case Model

List of Use Cases (grouped by actors) Student--someone who is registered to take courses at the University.

o Register for courses. Professor--someone who is licensed to teach at the University.

o Select courses to teach. o Request course offering roster.

Registrar--someone who is responsible for the maintenance of the Registration System. o Generate course catalogue. o Maintain professor information. o Maintain student information. o Maintain curriculum.

Billing System--external system that bills students each semester. o No use cases

Use Case Descriptions (brief) Register for courses

o The use case is started by the student. It provides the capability to create, review, modify, and delete a course schedule for a specified semester. All pertinent billing information is sent to the Billing System.

Request class roster o This use case is started by the professor. It provides the capability to request a

printed list of all students assigned to a specified course offering. Select courses to teach

o This use case is started by the professor. It provides the capability to select, review, modify, and delete a list of courses to teach for a specified semester.

Maintain professor information o This use case is started by the registrar. It provides the capability to create,

review, modify, and delete professor information. Maintain student information

o This use case is started by the registrar. It provides the capability to create, review, modify, and delete student information.

Maintain curriculum o This use case is started by the registrar. It provides the capability to create,

review, modify, and delete a list of course offerings for a given semester.

9

Page 10: Proposal Doc

10 PROPOSAL DOCUMENT

Generate catalogue o This use case is started by the registrar. It provides the capability to generate a

catalogue containing a list of course offerings for a specified semester.

Register for Courses Use CaseFlow of events:This use case begins when the student enters the student id number. The system verifies that the student id number is valid and prompts the student to select the current semester or a future semester. The student enters the desired semester. The system prompts the student to select the desired activity:

Create a schedule. Review a schedule. Change a schedule:

o Delete a course. o Add a course.

The student indicates that the activity is complete. The system will print the student schedule and notify the student that registration is complete. The system sends billing information for the student to the billing system for processing.

Alternate flowIf an invalid id number is entered, the system will not allow access to the registration system.

If an attempt is made to create a schedule for a semester where a schedule already exists, the system will prompt for another choice to be made.

Create a ScheduleThe student enters 4 primary course offering numbers and 2 alternate course offering numbers. The student then submits the request for courses. The system then:

1. Checks that prerequisites are satisfied for the requested course. 2. Adds the student to the course offering if the course offering is open.

Alternate flowIf a primary course offering is not available, the system will substitute an alternate course offering.

Review a ScheduleThe student requests information on all course offerings in which the student is registered for a given semester. The system displays all courses for which the student is registered including course name, course number, course offering number, days of the week, time, location, and number of credit hours.

Change Schedule - Delete a CourseThe student indicates which course offerings to delete. The system checks that the final date for

10

Page 11: Proposal Doc

11 PROPOSAL DOCUMENT

changes has not been exceeded. The system deletes the student from the course offering. The system notifies the student that the request has been processed.

Change Schedule - Add a CourseThe student indicates which course offerings to add. The system checks that the final date for changes has not been exceeded. The system then:

1. Verifies that the maximum course load for the student has not been exceeded. 2. Checks that prerequisites are satisfied for the requested course. 3. Adds the student to the course offering if the course offering is open.

Chapter 3: Methodology

In my project, I have used waterfall model. This model is used when requirements are well

defined and reasonably stable, and in my project ‘Online course Registration system’ all the

requirements are well defined.

The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential

approach to software development that begins with customer specification of requirements and

progresses through planning, modeling, construction and deployment, culminating in on-going

support of the complete software.

I have defined activities and represented them into seperated process phases. All the stages

overlap and fed information to each other. It is not a simple linear model but involves a sequence

of iterations of development activities.

This model is appropriate for my project as I had ample of time for designing it, so the time

constraints were not there. This model generally takes more time to complete the software life

cycle as when a stage completes it is signed off and development goes onto the next stage.

11

Page 12: Proposal Doc

12 PROPOSAL DOCUMENT

Research methods to be used

The main research techniques used to collect data was Questionnaires, Interviews and

Observation.

Questionnaires

Questionnaires are an inexpensive way to gather data from a potentially large number of

respondents. This is an alternative to use of interviews and observation and has its advantages

over other forms of data collection. I used this method because I wanted collect similar data from

all personnel of this department and also save time unlike in use of interviews. The questionnaire

was well structured and entailed the following categories of questions:

Contingency questions – a question that is answered only if the respondent gives a

particular response to a previous question. This avoids asking questions of people that do

not apply to

Matrix questions - Identical response categories are assigned to multiple questions. The

questions are placed one under the other, forming a matrix with response categories along

the top and a list of questions down the side which is an efficient use of page space and

respondents’ time.

Closed ended questions - Respondents’ answers are limited to a fixed set of responses.

12

Page 13: Proposal Doc

13 PROPOSAL DOCUMENT

Open ended questions - No options or predefined categories are suggested. The

respondent supplied their own answer without being constrained by a fixed set of

possible responses.(Content Management System Team, 2006)

Interviews

I had an opportunity to interact with some of the senior management staff and other members of

staff thus giving me a first hand experience on the situation at hand. I used the top-down

approach i.e. interviewing the management followed by users of the system. Each of these

persons interacts with the system at different levels thus facing different problems – thus

justifying the reason to interview each individually. From the interviews I was able to understand

various individual problems that users experience.

Observations

This involves experiencing or witnessing the users using the existing system to perform their

tasks. This method helped me to gain an inside view of the current system. This method is

advantageous because I gathered data and refined it directly in the interaction.

Resources required for the project

Hardware platform

P3 computer with the following specifications:

1.6 GHz processor

1 GB RAM

160 GB Hard disk

Software platform

The software used was as follows:

PHP Language.

MYSQL – Used to design the back end database.

Microsoft Word 2003 – for documentation.

13

Page 14: Proposal Doc

14 PROPOSAL DOCUMENT

UML – to draw the Use Case Diagrams.

Choice of programming tools

Visual studio 2010 was chosen as the programming language because of the following:

Convenience

It is easy to use even to the beginners.

Versatility

It provides a user friendly platform for both coding and designing of forms and summary

reports.

Powerful

It provides powerful tools such as Visual Component Manager, package and deployment

wizard, visual modeler add source code control.

Project schedule

Task Activity Description Duration Deliverable

Project idea Coming up with a project idea 1 week Project idea

Proposal

presentation

- - Proposal presentation

doc

Preparing

Proposal

documentation

Proposal doc acts as a tentative

summary of the proposed system

highlighting the scope, objectives

and justification for the system

1 week Proposal document

Working on

system

requirement

Data analysis to identify the needs

for the system- evaluation of

current system for example

4 weeks

System requirement

specification

documentation

System design Design of the system as it would

like to the user- involves use of

dataflow diagrams

4 weeks System design

specification

documentation

Development Actual coding 5 weeks Progress report

Testing Performance of module,

integrated and system testing

2 week Test plan documentation

Implementation Involves deploying the system to 2 weeks Implementation plan

14

Page 15: Proposal Doc

15 PROPOSAL DOCUMENT

and user training the intended client- to test for its

live performance

documentation

Preparation of

user manual

User manual is the document to

help the user e.g. configure and

run the system effectively later on.

2 week User manual

Preparation of

final

documentation

Final documentation gives the

overall content about the software

and includes details of all the

above deliverables

1 week Final documentation

plus the software

Conclusions

With a system like this Online course registration system, co-op bank management centre will

be able to efficiently keep records of courses and staff applying for the course.

By the end of the project I should have achieved the following

Development of a system that automates the application functions like courses serch and

back end administration

Development of a system that provides security to private data

Development of a system that can be implemented in the real world.

References

Bibliography

1. Let Us C by Yashavant Kanetkar

2. Computer Science, C++ by Sumita Arora

3. The Complete Reference, C++ by Herbert Schildt Software Engineering by Roger S.

Pressman

4. Kemu past Library Projects

5. Kemu Library

15