Proposal Doc
-
Upload
victor-kariuki -
Category
Documents
-
view
673 -
download
7
Transcript of 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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