1. OOAD & POS PROJECT
10.Conclusion 1.Introduction
9.Algorithm 2.Backgroundwork
FFCS
8.Verification and REGISTRATION 3.Requirements
Validation SYSTEM
7.System Design 4.Critical Systems
6.System Design 5.Software Process
and Architecture
. Model
4. 3. REQUIREMENTS
3.1 Functional 3.3 User
Requirements Requirements
user
FFCS requirements
REGISTRATION
SYSTEM
3.4 Domain
Requirements
3.2 Non-Functional
Requirements
non functional
requirements 3.5 System
Requirements
system requirements
5. 4.CRITICAL SYSTEMS SPECIFICATION
4.1Risk Specification 4.2.Safety Specification
FFCS
REGISTRATION
SYSTEM
4.4. Software Reliability
Specification 4.3.Security Specification
6. 4.1 RISK SPECIFICATION
4.1.1.Risk Identification 4.1.2.Risk Analysis
possible risks in system classification table
FFCS
REGISTRATION
SYSTEM
.
4.1.4.Risk Reduction 4.1.3.Risk Decomposition
Management
10. 5.SOFTWARE PROCESS MODEL
5.1 Water-Fall Model 5.2 Evolutionary Model
FFCS
REGISTRATION
SYSTEM
5.3 Component Based
Software Engineering
11. 5.3 COMPONENT-BASED SOFTWARE
ENGINEERING
5.3.2 Requirements
5.3.1 Component Analysis Specification
FFCS
REGISTRATION
5.3.4 Development and 5.3.3 System Design with
SYSTEM
Integration Reuse
17. 8. VERIFICATION AND VALIDATION
8.1 Verification
verification process
FFCS
REGISTRATION
SYSTEM
8.2 Validation
validation process
18. 9. ALGORITHM
The process involved is
1. First the user gets in to the authentication process
2. Then the batch is selected by the users
Now in case of student:
He/she selects the registration
1. The course available and the compulsory courses and its credits for a
particular semester are viewed.
2. Then the courses and its corresponding teachers are selected.
FFCS
3. Cancelation of already registered courses is also possible with in particular
period of time. REGISTRATION
SYSTEM
4. Finally printed copy of timetable is sent to the user’s mail or to their system.
Now in case of a teacher:
1. He/she selects the student batch and different branches.
2. Then teacher views the list of students who chose him/her.
3. Then time table is viewed by the teachers.
4. Finally printed form is sent to teacher’s mail.
19. 10. CONCLUSION
We have described a general purpose prototype University scheduling system
which is capable of:
• Handling many different forms of timetabling constraint while only ever dealing
with feasible timetables.
• Generating high-quality solutions despite the increasing problems which has
resulted from modularization.
• Providing a choice of several different good schedules from which the user may
choose the best. FFCS
• Directing the time table to the most constrained parts of the timetable so that, if
REGISTRATION
necessary, adjustments may be made SYSTEM
manually.
• Allowing database queries to produce a schedule for any staff
member, student, room or item of equipment.
• Generating a personalized view of the timetable for each member of
staff, communicating this over the campus network, and inviting on-line
comments on perceived quality.