FFCS registration system

19
OOAD & POS PROJECT FFCS REGISTRATI ON SYSTEM 2.Backgroundwo rk 8.Verification and Validation 3.Requirements 7.System Design 4.Critical Systems 6.System Design and Architecture 5.Software Process Model . 9.Algorithm 1.Introduction 10.Conclusion

description

FFCS registration system of a college

Transcript of FFCS registration system

Page 1: FFCS registration system

OOAD & POS PROJECT

FFCS REGISTRATION

SYSTEM

2.Backgroundwork

8.Verification and Validation

3.Requirements

7.System Design 4.Critical Systems

6.System Design and Architecture

5.Software Process Model.

9.Algorithm

1.Introduction 10.Conclusion

Page 2: FFCS registration system

1. INTRODUCTION

FFCS REGISTRATION

SYSTEM

Page 3: FFCS registration system

2. BACKGROUND WORK

FFCS REGISTRATION

SYSTEM

Page 4: FFCS registration system

3. REQUIREMENTS

3.1 Functional Requirements

3.3 User Requirements

user requirementsFFCS

REGISTRATION SYSTEM

3.4 Domain Requirements

3.5 System Requirements

system requirements

3.2 Non-Functional Requirementsnon functional requirements

Page 5: FFCS registration system

4.CRITICAL SYSTEMS SPECIFICATION

4.4. Software Reliability Specification

4.1Risk Specification

4.3.Security Specification

4.2.Safety Specification

FFCS REGISTRATION

SYSTEM

Page 6: FFCS registration system

4.1 RISK SPECIFICATION

4.1.4.Risk Reduction Management

4.1.1.Risk Identificationpossible risks in system

4.1.3.Risk Decomposition

4.1.2.Risk Analysisclassification table

.

FFCS REGISTRATION

SYSTEM

Page 7: FFCS registration system

4.2 SAFETY SPECIFICATION

FFCS REGISTRATION

SYSTEM

Page 8: FFCS registration system

4.3 SECURITY SPECIFICATION

4.3.4 Technology Analysis

4.3.1 Asset Identification

4.3.3 Threat Assignment

4.3.2 Threat Analysis and Risk Assessment

FFCS REGISTRATION

SYSTEM

Page 9: FFCS registration system

4.4 SOFTWARE RELIABILITY SPECIFICATION

4.4.3 Operator Reliability

4.4.1 Hardware Reliability

FFCS REGISTARTION

SYSTEM

4.4.2 Software Reliability

Page 10: FFCS registration system

5.SOFTWARE PROCESS MODEL

5.3 Component Based Software Engineering

5.1 Water-Fall Model

FFCS REGISTRATION

SYSTEM

5.2 Evolutionary Model

Page 11: FFCS registration system

5.3 COMPONENT-BASED SOFTWARE ENGINEERING

5.3.4 Development and Integration

5.3.1 Component Analysis

5.3.3 System Design with Reuse

5.3.2 Requirements Specification

FFCS REGISTRATION

SYSTEM

Page 12: FFCS registration system

6.SYSTEM DESIGN AND ARCHITECTURE

FFCS REGISTRATION

SYSTEM

Page 13: FFCS registration system

CLIENT-SERVER MODEL

Page 14: FFCS registration system

7.SYSTEM TESTING

7.1 Integration Testing

7.2 Release Testing

FFCS REGISTRATION

SYSTEM

Page 15: FFCS registration system

7.1 INTEGRATION TESTING

FFCS Registration

System

Page 16: FFCS registration system

7.2 RELEASE TESTING

FFCS Registration

System

Page 17: FFCS registration system

8. VERIFICATION AND VALIDATION

8.1 Verificationverification process

8.2 Validationvalidation process

FFCS REGISTRATION

SYSTEM

Page 18: FFCS registration system

9. ALGORITHM

FFCS REGISTRATION

SYSTEM

The process involved is 1. First the user gets in to the authentication process2. Then the batch is selected by the usersNow in case of student:He/she selects the registration3. The course available and the compulsory courses and its credits for a

particular semester are viewed.4. Then the courses and its corresponding teachers are selected.5. Cancelation of already registered courses is also possible with in particular

period of time.6. Finally printed copy of timetable is sent to the user’s mail or to their system.Now in case of a teacher:7. He/she selects the student batch and different branches.8. Then teacher views the list of students who chose him/her.9. Then time table is viewed by the teachers.10.Finally printed form is sent to teacher’s mail.

Page 19: FFCS registration system

10. CONCLUSION

FFCS REGISTRATION

SYSTEM

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.• Directing the time table to the most constrained parts of the timetable so that, if necessary, adjustments may be made 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.