Table of contents: Project Description

Functions used
Project Vision

Feasibility Study Working Of Present System

DISADVANTAGES OF PRESENT WORKING SYSTEM

Characteristic of the Proposed System Characteristic of the Proposed System DFD ER Diagram

Project Description

A student info system (SIS) is a software application for education establishments to manage student data. Student information systems provide capabilities for entering student test and other assessment scores through an electronic grade book, building student schedules, tracking student attendance, and managing many other student-related data needs in a school, college or university. Also known as student information management system (SIMS). Functions These systems vary in size, scope and capability, from packages that are implemented in relatively small organizations to cover student records alone, to enterprise-wide solutions that aim to cover most aspects of running large multi-campus organizations with significant local responsibility. Many systems can be scaled to different levels of functionality by purchasing addon "modules" and can typically be configured by their home institutions to meet local needs. Until recently, the common functions of a student records system are to support the maintenance of personal and study information relating to:

Handling inquiries from prospective students Enrolling new students and storing teaching option choices Handling records of examinations, assessments, marks, grades and academic progression Maintaining records of absences and attendance Recording communications with students Maintaining discipline records Providing statistical reports Maintenance boarding house details Communicating student details to parents through a parent portal Special Education / Individual Education Plan (IEP) services Human resources services Accounting and budgeting services

Student health records

I this project I use Graphs, Graphics and other tools for representation of information. In this project any technical aspects like Database platform, page designing tool, etc and feature may be changed according to need.

Project Vision

The vision for the Student Information System Project is to provide state-of-the-art software for managing student academic and financial records. The system will provide the tools to create, maintain and report on student data in an efficient and convenient manner. Upon completion of the project, the system will improve the quality of the academic experience for students, faculty and staff. PeopleSoft SIS will be the single, integrated, authoritative source for student-related data.
___________________________________________________________________

Scope of Project: The scope of the student information system implementation project is to evaluate the current business processes through fit/gap analysis and install a new student information system to meet the needs of all Undergraduate, Graduate and Professional Programs at Case. It also encompasses interfaces for students. The Fit/Gap Analysis phase will build a working prototype of the student information system and identify any gaps in service or functionality. The objective is to develop and define specific strategies for addressing these gaps in Student Records, Student Financials and Campus Community IDP sessions. The decisions made in these sessions will determine the full scope of the project

Feasibility Study

Economically Feasibility:

The system being developed is economic with respect to School or Collages point of view. It is cost effective in the sense that has eliminated the paper work completely. The system is also time effective because the calculations are automated which are made at the end of the month or as per the user requirement. The result obtained contains minimum errors and are highly accurate as the data is required.

Technical feasibility: The technical requirement for the system is economic and it does not use any other additional Hardware and software. Behavioral Feasibility: The system working is quite easy to use and learn due to its simple but attractive interface. User requires no special training for operating the system.

Working Of Present System In the present system all work is done on paper. The whole session attendance is stored in register and at the and of the session the reports are generated. We are not interested in generating report in the middle of the session or as per the requirement because it takes more time in calculation. At the end of session the students who dont have 75% attendance get a notice.

DISADVANTAGES OF PRESENT WORKING SYSTEM

Not User Friendly: The existing system is not user friendly because the retrieval of data is very slow and data is not maintained efficiently.

Difficulty in report generating: We require more calculations to generate the report so it is generated at the end of the session. And the student not get a single chance to improve their attendance

Manual control: All calculations to generate report is done manually so there is greater chance of errors.

Lots of paperwork: Existing system requires lot of paper work. Loss of even a single register/record led to difficult situation because all the papers are needed to generate the reports.

Time consuming: Every work is done manually so we cannot generate report in the middle of the session or as per the requirement because it is very time consuming.

Characteristic of the Proposed System

User Friendly:- The proposed system is user friendly because the retrieval and storing of data is fast and data is maintained efficiently. Moreover the graphical user interface is provided in the proposed system, which provides user to deal with the system very easily.

Reports are easily generated: reports can be easily generated in the proposed system so user can generate the report as per the requirement (monthly) or in the middle of the session. User can give the notice to the students so he/she become regular.

Very less paper work: The proposed system requires very less paper work. All the data is feted into the computer immediately and reports can be generated through computers. Moreover work become very easy because there is no need to keep data on papers.

Computer operator control: Computer operator control will be there so no chance of errors. Moreover storing and retrieving of information is easy. So work can be done speedily and in time.

DFD :

SIS data

St

Initialize System Data

All the processes that are shown on this diagram are bottom level processes. Process 5.1 prompts the user for an ID number, and checks the syntax of the ID number that the user returns. If this is syntactically correct then this is sent to Process 5.2, and Process 5.1 terminates. Otherwise the problem is reported to the user, who has the option of either cancelling the operation or trying again. The process repeats this until the user has either cancelled the request, or supplied a valid ID number. Process 5.2 uses the ID number received from Process 5.1, and interacts with the ``Students'' data area, to select all the instances of ``Student'' (in the system) whose ID numbers are less than or equal to the one supplied by Process 5.2. The set of these instances is sent to Processes 5.3 and 5.6. Process 5.3 removes some unneeded information from this set and uses it to compute an ``old student info'' report, which is sent to Process 5.5. Process 5.4 resembles Process 5.1, except that it prompts for and validates a file name, instead of an ID number. If a valid file name is obtained, then it is sent to Process 5.5. Process 5.5 generates a text file using the ``old student info'' it received from Process 5.3, and tries to write it to the File System, using the file name that was supplied by Process 5.4. If this attempt succeeds then an ``ok'' signal is sent to Process 5.6. Otherwise (when the write failed), the problem is reported to the user, and the user is asked whether the old students should be deleted anyway. If the user's answer is ``Yes'' then an ``ok"' signal is sent to Process 5.6; this signal isn't sent, otherwise.

Finally, Process 5.6 receives a set of ``old students'' from Process 5.2. If it also receives an ``ok'' signal from Process 5.5, then it deletes all the students in the set of ``old students'' from the ``Students'' data area; otherwise it makes no change. Note that this is not a good example of a leveled set of data flow diagrams: At least some of Processes 1, 3.1, 3.2, 3.3, 4.1, 4.2, 4.3, and 6 should really be refined by lower level data flow diagrams instead of by process specifications, and it might not be necessary to used quite as many processes to refine Process 5 as are shown above. A more sensible set of diagrams (and process specifications) for this system would probably include more diagrams and processes than are shown here; the ones used here are complete enough to serve as a useful example for ``structured design'' (and it will take less time to apply ``structured design'' to these, than it would to apply it to a more sensible set of diagrams for the same system). Starting Point We will begin with one large data flow diagram for the entire system. As described this can be obtained by starting with the context diagram and repeatedly replacing processes with the lower level diagrams that refine them, until every process shown on the diagram is refined by a process specification instead. The diagram (of this type) that corresponds to the above example is as follows.

First Iteration: The Entire Diagram Now, we'll begin to reply the recursive process in order to map DFD processes to modules on a structure chart.

Determining the Information Flow An inspection of the above diagram(s) suggests that Process 1 is active once, before all the others, and terminates before any others begin. As well, the only direct communication between Process 1 and the rest of the system is the transmission of a control signal, ``ready.'' Therefore, we'll start by deciding that the large diagram displays two independent system: 1. An ``Initialization'' subsystem, consisting only of Process #1 2. A ``Command Processing'' subsystem, consisting of all the other processes shown on the diagram. Partitioning the Diagram Since we've identified independent subsystem, this is straightforward: We'll simply break the diagram into two sub diagrams, each showing one of the two subsystems listed above. First Level Factoring This is also straightforward for independent subsystem We will create a main module (since one hasn't been produced already), and we'll name this ``Student Information System.'' Second Level Factoring We won't map any modules to processes yet. Instead, we'll apply this method, recursively, to each of the diagrams obtained above. Structure Chart The piece of the structure chart generated so far, with ``off page connectors'' in place of the subcharts we'll create recursively, is as follows. (If you're using Netscape or another powerful browser then you should find that the ``off page connectors'' are clickable, so that you can use them to move from one part of the structure chart to another).

Second Iteration: The First Subsystem Now, we'll apply this method to the diagram for the first subsystem. Data Flow Diagram

Determining the Information Flow Since the diagram includes only one process, it's clearly visible so we'll just map it directly to module. Structure Chart The resulting structure chart is as follows.

Third Iteration: The Second Subsystem In this third iteration, we'll apply the method to the second subsystem that was obtained during the first iteration of the method. Data Flow Diagram The data flow diagram to be processed is as follows.

Determining the Information Flow A consideration of the shape of this system, and the description of Processes 2.1 and 2.2, suggests that this diagram has transaction flow. Partitioning the Diagram

When partitioning a data flow diagram with transaction flow, we must identify the transaction center, command acquisition path, and activity paths. The above diagram includes a transaction center, a ``command acquisition path'' that includes only a single module, and eight ``activity paths:''

Transaction Center: Process 2.2 Command Acquisition Path: Process 2.1 Activity Path #1: Process 3.1 Activity Path #2: Process 3.2 Activity Path #3: Process 3.3 Activity Path #4: Process 4.1 Activity Path #5: Process 4.2 Activity Path #6: Process 4.3 Activity Path #7: Processes 5.1, 5.2, 5.3, 5.4, 5.5, 5.6 Activity Path #8: Process 6

First Level Factoring During first level factoring, we will create a main module (called ``Command Processing'') for this subsystem, and two modules that it controls: a controller called ``Command Acquisition Control,'' and a module that corresponds to the transaction center and that has the same name (``Choose Command Subsystem''). Second Level Factoring During second level factoring, the processes on the command acquisition path will be mapped to modules that are controlled (directly, or indirectly) by the ``Command Acquisition Control'' module created above. In this case, there is only one module on the command acquisition path Process 2.1 - so we'll create a module with its name (``Obtain and Validate Command'') and we'll make this a child of the controller. The activity paths will be processed recursively; the main modules of their structure charts will be made children of the transaction center's module in order to connect all the structure charts together. Structure Chart The (piece of the) structure chart that we've obtained is shown below. It includes the modules that were created during first- and second-level factoring, and ``off page connectors'' (leading down below it) that will be connected to the structure charts for activity paths that were mentioned above.

Fourth Iteration: Activity Path #1 The data flow diagram for this subsystem is trivial - it includes only one process. The structure subchart that corresponds to it is as follows.

Fifth Iteration: Activity Path #2

The data flow diagram for this system is also trivial; its structure subchart is shown below.

Sixth Iteration: Activity Path #3 The structure chart for the third activity path, which is also trivial, is as follows.

Seventh Iteration: Activity Path #4 Here is the structure chart for the fourth (trivial) activity path.

Eighth Iteration: Activity Path #5 The structure chart for the fifth activity path is as follows.

Ninth Iteration: Activity Path #6 The structure chart for the sixth activity path is shown below.

Tenth Iteration: Activity Path #7 The tenth iteration will apply the method to the data flow diagram for the seventh activity path. Data Flow Diagram The data flow diagram for this subsystem is as follows.

< p> Determining the Information Flow This diagram is nontrivial, and it doesn't seem to include independent subsystems or transaction flow. Therefore, we'll decide that it has transform flow. Partitioning the Diagram In order to partition a diagram with transform flow, we must decide whether each process is an ``input flow'' process, an ``output flow'' process, or in the ``transform center.''

Input Flow: Processes 5.1, 5.4

Output Flow: Process 5.5 Transform Center: Processes 5.2, 5.3, 5.6

First Level Factoring During first level factoring we'll create a main module for this subsystem, called ``Deletion of Old Students,'' and we'll create three controllers that it can call: an ``input'' controller called ``Old Student Input Acquisition,'' a ``processing'' controller called ``Old Student Processing,'' and an ``output'' controller called ``Old Student Reporting.'' Second Level Factoring During second level factoring, we'll map each of the ``input flow'' processes to a module (with the same name) that's controlled, directly or indirectly, by the above ``input'' controller. In this case there are two ``input flow'' processes, and they both pass data across the input flow boundary (to output flow processes or to processes in the central transform), so we'll make the module for each process a child of the ``input'' controller. We'll also create modules for each of the ``output flow'' processes and will have them controlled by the ``output'' controller. In this case, there is only one such process, so we'll make its module a child of this controller. We'll apply the method recursively to the set of processes in the transform center. However, there are only three of these, so they form a ``trivial'' data flow diagram - so we'll skip a step and finish the job, and make the module for each a child of the ``processing'' controller, as the description of processing a trivial diagram should suggest. Structure Chart Top of Chart The top of the structure chart for this system (showing the main module, and off page connectors that link to the system's controllers) is as follows.

Subchart for Input Flow The subchart for input flow is as follows.

Subchart for Processing The subchart for processing is as follows.

Subchart for Output Flow Finally, the subchart for output flow is shown below.

Eleventh (and Final) Iteration: Activity Path #8 The structure chart for the eighth (trivial) activity path is as follows.

Data Areas Finally, a data area should be added for the data store that is shown on the data flow diagrams. This would be drawn at the bottom of the structure chart.

Control connections should be added, from the module for each process that accesses the data store (on the data flow diagrams), down to this data area: namely, the modules for Processes #1, #3.1, #3.2, #3.3, #4.1, #4.2, #4.3, #5.2, #5.6, and #6. Data Flows Data and control signals should be added for each of the data and control flows on the data flow diagrams that flow between two processes, or between a process and a data store. For each data (or control) flow between a process and a data store, you'll have added a control connection from the module for the process down to the data area, already. Draw a single data (or control) signal for the data (or control) flow, and showing at as moving along this control connection. It won't always be true that there's a control connection between the modules that correspond to two processes, such that data flows between them. However, since the modules we've added to the structure chart form a hierarchical ``tree'' structure, these two modules will have a unique ``lowest common ancestor'' in the tree. Show the data (or control) signal as moving along control connections, up from the ``source'' module to the common ancestor, and then back down from the common ancestor to the ``destination.''

ER Diagram:

Extra Features

displays the Assignment Submission page for student. The interesting part is a real-time timer, which can help student estimate submission time and enrich user experience. The correspond technologies I implement are:

AJAX Extensions Update Panel

References:
In the preparation of this capstone project report on the topic Student Information System I am oblique towards too many book writers and their journal which has help me in the preparation of the report and some of the sites are listed below which has helped me in the report preparation
1. eberly@cpsc.ucalgary.ca

2. www.thebooktailor.com 3. www.dotnetspider.com 4. www.wikipedia.com 5. www.dbmsoracle.com