CHAPTER 1

Gathering and Analyzing info

1.1 INTRODUCTION:

Student management system is a window based application. The student management system can
handle all the detail about student. The detail include college detail, course detail, personal detail,
academic details, attendance details etc. the student management system is an auto mated version of
manual student management system.

The student management system is software that is helpful for students as well as the college
authorities. Our student management system stores records of student and teachers. The main principle
behind the project is easy supervision of institute. This software can help us to explore all the activities
happening inside the organization. It can handle the detail of student, teachers, class details, fee details,
subject details and attendance details etc.

In this system only the administrator or manager can view the details of students and teachers. A
management system that manage the record of student regarding admissions and examination part.

SMS INVOLVES:

 Test Result
 Attendance call(to absents only)

1.2 Purpose:

The purpose of this document is to provide a platform to the management where they can manage their
students efficiently. This project helps in maintaining databases of students in any educational
organizational. We can easily access any student information any time and can be kept safely for long
period of time without any damage.

The project is about to handle all the information of the student regarding courses and examination.
Also manages resources which were managed and handled by manpower previously. The main purpose
of the project is to integrate distinct sections of the organization into consistent manner so that complex
functions can be handled smoothly by any technical or non-technical person.

Other purpose is developing this type of software is to generate reports automatically with in short time.
Reports automatically generation may be done in the center of the session or at the last of session.

The purpose of this system is to offer a detailed explanation of attendance management system by using
SMS GENERATION.

The project aims at following matters:

 To manage information about students, faculty, exams reports and attendance.

 Consistently update information of all the students.
 Reports.
 Assistant decision making.
  Student management system supports the student admission and registration process, the
maintenance of student personal, academic, fee and attendance related records.
 Generate an SMS against present and absent students.
 Generate student fee deposition related reports.

1.3 Scope:

For this project we want to define what will be done such that the final product meets expectations.
With this in mind, the following are the parts that will be completed. This product will maintain the
admission process of FA, FSC (pre-engineering), FSC (pre-medical), ICS, and ICOM. Activities like
insertion, updating, creation, and deletion will be performed by the system operator and will be
maintained in the form of tables for auditing and maintain integrity of the system.

 The project can be implemented on average sized organization.

 An average company will not be keen to spending loads of money on ledgers. Whereas the
project will greatly reduce the cost which is using common and cheap office items like database
and desktop computers (applications).
 The data is directly stored in the database in the hard disk of the pc.
 Our database system has the capacity to:
 Manage all the records of students.
 Do an automatic enrolled, payment, exam and attendance reports.
 Able to add edit or delete data(in case of error).

Existing system

The current system in used is a paper based system. It is too slow and cannot provide a updated list of
student related to fee, exam and attendance etc. the intention of the system is to reduce overtime pay
and increase the number of students that can be managed easily. Records are to be maintained for the
details of each student, fee detail, attendance detail, exam detail and subject detail. All these are
entered and retrieved manually.

Time consuming.

Update process.

Inaccuracy of data.

1.4 Definitions, Acronyms and Abbreviations:

 Administrator
o A person (user) responsible for carrying out the administration of a business or
organization.
Functional and Non-Functional Requirements:
Functional requirements:

Requirement # Description Priority

Network log on  Users who do not have the correct access rights High
 Owner/local user will be prevented from connecting to the
 Administrator database.
 acts as the system owner and can
perform all functions
 can view, input and modify records of all
students and teachers;

Insert The user will be able to insert records or register High

a student.

Update The user will be able to update or edit the record High
in case of correction.

Delete The user will be able to modify the record in case High
of wrong entry.

Search The user will be able to search about paid or High

non-paid student

Attendance The user will be able to check about present and High
absent students.

Subjects The user will be able to select subjects to which High

he wants to study.

Test The user will be able to select the test and assign High
to students.

Academic detail The user will be able to save and check about High
academic detail of student.

Fee payment The user will be able to check about payment High
status of students.
Reporting The user will be able to check the reports of High
students (exam, attendance etc.).

SEND SMS The user will be able to send SMS to those who High
are absent for specific Date.
1.5 Use cases and usage scenarios:
1.5.1 Admin related tasks:

1.5.1.1 Student related use cases:

1.5.2 Use case descriptions:
This section list use cases for student management system. The various classes identified the following
use cases and primary actors for the student management system.

Use case usage scenarios:

PRIMARY ACTORS Use cases

1. Log In
Local user 2. Insert
3. Update
4. Check Details
5. Register
6. Subjects
7. Attendance
8. Fee
9. Report
10. Send SMS
11. Assign Test
Administrator 12. Delete
Use case Log in
UID 1
ACTOR LOCAL USER, ADMINISTRATOR
DESCRIPTION User logged into his/her account
PRE CONDITION User must have a log in name and password
POST CONDITION User is logged in his/her account can perform operations according to
his/her roles.
NORMAL FLOW 1. If a user want to access the application then he has to log in
otherwise he will not be able to access the system.
2. If an administrator wants to make changes in the application (insert
update, delete, register, check detail, check records, attendance)
then he has to log in itself as well.
3. For log in he will only provide his name and password.
4. Now the admin or local user is log in and he makes any kind of
changes in the system.

ALTERNATIVE FLOW User provide incorrect user name and password.

Use case insert

UID 2
ACTOR LOCAL USER, ADMINISTRATOR
DESCRIPTION User goes to the application, log on to the application and he can insert
record of students, attendance, subjects, test and attendance as well.
PRE CONDITION User must have log on the system with his account.
POST CONDITION Admin successfully perform the operation.
NORMAL FLOW 1. Admin logs on the application and goes to the home page.
2. Select the information panel to which he wants to make
changes (admission form, create new user, subjects, test).
3. Enter the data in fields.
4. Perform insert operation on the selected things.
5. Successfully perform the operations.

ALTERNATIVE FLOW User provides incorrect user name and password.

Use case update
UID 3
ACTOR Admin
DESCRIPTION User goes to the application, log on to the application as admin and he
can update the student records, fee records, attendance records, and
subject records etc.
PRE CONDITION User must be log on to the application on admin account.
POST CONDITION Admin successfully perform the update operations.
NORMAL FLOW 1. Admin logs on the system and goes to the application’s home
page.
2. Go to the page of student / attendance/ subjects and exam he
wants to update.
3. Search the page to student/attendance/subjects/exams he
wants to update.
4. Perform update operation on the selected page (data).
5. Successfully perform the operation.
ALTERNATIVE FLOW 1. Admin did not perform any operation and leaves without
making any changes.
2. Admin could find the required data.

Use case Delete

UID 4
ACTOR Admin
DESCRIPTION User goes to the application logs on the application as admin and he
can search and delete the any record that he want for example
(student record, fee record, subjects, attendance records etc.).
PRE CONDITION Must be log on the application as admin.
POST CONDITION Admin successfully perform the delete operation.
NORMAL FLOW 1. Admin logs on the application as admin to home page.
2. Go to the page student record/attendance record/subject
details he wants to delete.
3. Search for the record to which he wants to delete.
4. Perform delete operation on the selected things.
5. Successfully perform the operation.
ALTERNATIVE FLOW 1. Admin did not perform any operation and leaves without
making any changes.
2. Admin could not find the required data(record).
Use case Search
UID 5
ACTOR Admin
DESCRIPTION Admin search the required data of students, attendance, subjects and
fee details etc.
PRE CONDITION Admin must be log on to application.
POST CONDITION Admin successfully view all the records.
NORMAL FLOW 1. User goes to the application and log on as admin.
2. Select the form student detail, fee detail, subject detail,
attendance details to view.
3. Search against the name, id, and phone number.
4. Search the required data.
ALTERNATIVE FLOW 1. Admin did not perform any operation and leaves without
making any changes.

Use case registration

UID 6
ACTOR Admin.
DESCRIPTION User provides the correct personal information to become a registered
student and user.
PRE CONDITION Visit the organization/school/academy.
POST CONDITION User become a registered student and can take classes, can be marked
absent or present, can be assigned subjects etc.
NORMAL FLOW 1 If a user want to be a student of particular organization then
he makes himself registered with that’s one organization.
2. Submit his personal details.
3. Gives interview.
4. Takes admission.
5. Fee payment.
6. Collection of fee receipt.
ALTERNATIVE FLOW 1 User did not provide the correct information on form.
2 User did not attend the interview.
3 User did not pay the fee.
Use case subjects
UID 7
ACTOR admin
DESCRIPTION Admin can assign the number of subjects to the students
depending upon their criteria or back ground.
PRE CONDITION User must be log on the application and the student must be
registered before assigning subjects.
POST CONDITION Admin successfully assign subjects to all the students and to
specific student.
NORMAL FLOW 1 Receiving the form from office.
2 Submission of details.
3 Gives interview.
4 Subject allocation.
5 Get registered.
6 Pay fee.
7 Collection of fee receipt.
ALTERNATIVE FLOW 1 User did not provide the correct information on form.
2 User did not attend the interview.
3 User did not pay the fee.

Use case Attendance

UID 8
ACTOR Admin/local user
DESCRIPTION Admin open the attendance form and change the status of
students as present or absent.
PRE CONDITION User must be log on by admin.
POST CONDITION Admin successfully marked the status of student as P for
present or A for absent.
NORMAL FLOW 1 User log on the application as administrator or local
user.
2 Opens the attendance form in the application.
3 By default all the students are present as comparatively
mostly student are present, right after thirty minute it
is confirmed that how many students are absent or
how many of them are present in the class or
organization.
4 Those who are absent they are marked as A.
5 Those who are not assigned any value those are
marked as P default.
6 An SMS is send to those who are absent.
ALTERNATIVE FLOW 1 Admin did not perform any operation and leaves
without making any changes
Use case Fee
UID 9
ACTOR Admin/local user
DESCRIPTION Student select methods to make payment of fee.
PRE CONDITION Contact to the management.
POST CONDITION Payment is fulfilled and closed.
NORMAL FLOW 1The user will log on the system as admin.
2 The user will generate the report for those whose fee status is
paid.
3 The admin will also check for those whose status of payment is
not paid.
4 The user will asked to those or enlist those whose status is not
paid.
5 Student will be fined RS:50 after 10th of every month and
RS:100 will be charged after the 15 of every month and right
after 25 the will not be eligible to sit in the class.
6 Cashier will receive the fee and make their status paid.
7 Successfully perform the operation and close the window
(application).
ALTERNATIVE FLOW 1 The admin could not find the record of student that
whatever he has been registered or not.
2 Did not perform any task close the application without
making changes in the application.

Use case Reports Generation

UID 10
ACTOR Admin/local user
DESCRIPTION The purpose of this use case is to enable a user to create view, or work
with a report and also provides the basic report as well as provide
response to all the queries that are asked by owner or other staff
member.
PRE CONDITION Must contact to the management
POST CONDITION Report has been generated exactly according to the criteria that is
specified by the owner or staff member.
NORMAL FLOW 1 User access the reporting & correspondence area of the
application.
2 System presents report type screen list.
3 User selects the desired report type from the list
4 System presents report detail screen. this screen displays input
 fields for the report’s configurable parameters so that a user
may create a new instance of the report .
5 System validates the input parameters and upon successful
prompts the user to select a file type to render the report in.
6 These options will be for specific type of report as word, pdf,
and excel you select and choose continuing.
7 If the system presents the report then the systems display it
abruptly on the report viewer screen.
8 It might be an attendance report.
9 It might be an exam report.
10 It might be a performance report as well.
ALTERNATIVE FLOW 1 User may filter the reports by the category ID.
2 User selects to view a previously created instance of the report
from the list of available instance.
3 User did not perform any operation and closed the application
without making any changes to the system.

Use case Send SMS

UID 11
ACTOR Admin/local user
DESCRIPTION An SMS is send to those who are registered in the organization, to
those who are absent, and to those who participated in the exams.
PRE CONDITION Student must be registered. Must be absent, must be participated in
the exams.
POST CONDITION Student successfully received the message.
NORMAL FLOW 1 User log on the application as admin.
2 User marks the students who are present or to those who are
absent.
3 Those who are marked as absent they receive the message
(string….).
4 When a new record of or new student is registered then an
SMS is generated and send to their parents.
5 At the time of exam the schedule is send to the students as
well.
ALTERNATIVE FLOW 1 User did not enter the correct contact# at the time of
admission or registration.
2 Sending failure notification has been received.
Use case Assign test
UID 12
ACTOR Admin/local user
DESCRIPTION A date is fixed to test and asked the student for that.
PRE CONDITION Students must have a class.
POST CONDITION Test is announced and its marks have been entered.
NORMAL FLOW 1 User log on the application as admin.
2 Select a class
3 Select a date for test.
4 Receive result.
5 Enter the result in system.
6 Keeps the record about students.
ALTERNATIVE FLOW 1 The user did not arrange the test.
2 User could not find the class for which the test has been
announced.
3 Wrong date has been entered.
1.6 SUPPLEMENTRY REQUIRMENT

1.6.1 Usability
Describes the ease with which the system can be learned or used

 The end user/admin shall be able to check the whole system (whole academy management)
with in only 1 minute.
 The end user/admin shall be able to access any page with in four seconds.

1.6.1.1 Understandability
 Interface elements are easy to understand.
 For clerk/admin to manage the academy using this system, the purpose of this system is easily
understandable.

1.6.1.2 Learnability
 The design system is user friendly.
 The system must be easy to understand.

1.6.1.3 Operability
 The interface elements and actions are consistent.
 Error message explain how to recover from the error.
 Undo should be available for most actions.

1.6.1.4 Attractiveness
The screen layout and colts that has been is the systems are appealing.

1.6.2 Reliability
 Describes the degree to which the system must work for users. Specifications for reliability
typically refer to availability, mean time between failures, and mean time to repair, accuracy,
and maximum acceptable bugs.
 The purposed system will be fall tolerant.
 It will be down hardly once in a year.
 It provides secure login facility to user/admin.
1.6.3 Supportability
 Refers to the software’s ability to be easily modified or maintained to accommodate typical
usage or change scenarios.
 The system shall allow users to create new work flows without the need for additional
programing.
 The system shall allow the system administrator to create and populate a message to the absent
students.

1.6.4 System requirements

1.6.4.1 User interface

 The user interface for the software shall be compatible to any operating system such as
windows 7(32 bit OR 64 bit), windows 8, or higher.

1.6.4.2 Hardware interface

 Since the application must run over the windows platform, all the hardware shall require to
connect internet or VODA-PHONE MODEM will be the hardware interface for the system. As for
e.g. MODEM, WAN-LAN, Ethernet cross-cable.

1.6.4.3 Software interface

 The designer screen shall communicate with the configurator to identify all the available
components to configure the application.
 The designer screen shall communicate with the admin to get, specify, insert, update, delete,
edit offering the application.

1.6.4.4 Communications interface

The application system shall use a system ram for the whole communication between MS SQL SERVER
2012 and application.
 CHAPTER 2
PLANING THE PROJECT
2.1 Introduction
In this phase we will talk about the various models which are used in software development. There are
different models are used in software development i.e. waterfall model, object oriented model, RAD
model, incremental model and prototyping model.
The implementation of a data collection program should follow a normal project cycle. During the
planning phase, a legal and institutional framework needs to be put in place, and the current working
practices and budget will need to be reviewed, so that appropriate resources can be secured for a
sustainable program.
We will shortly discuss pros and cons of these methodologies. At the end of this phase we will select the
most appropriate model or combination of these models for our project. We will also give the suitable
reason for our choice. In our project combination we would be used rational unified process model. This
methodology is fast and becoming a popular software development to map business process and
practices. Development is phased into four stages. In this way we can make our project more accurate
according to user requirements. Our final project would be more efficient, flexible and maintainable.
Maintainability is the greatest issue in the software development maintainability can be increased by
using risk analysis at each step and user interaction. By using rational unified process model we make
our final product more maintainable. It increases performance of our product. Waterfall model is a
sequential approach. It is documented driven which has 5 or 8 stages. Because of the cascade from one
phase to another, this model is known as the waterfall model. We will talk in detail in upcoming
heading.

2.2 Methodology
We have chosen rational unified process for the development of the project because it is a closely
approach of object oriented model. And prototyping because we first made a prototype of user
requirement showed to user what does he requires what it is going correct or wrong.

2.3 Available methodologies

Existing methodologies that are commonly used in software development projects are given as below.
Water fall model
Incremental model
RAD
Object oriented life cycle model
 Extreme programing model
 Fountain model
2.3.1 Waterfall model:
The first published model of the software development process was derived from other engineering
processes. Because of the cascade from one phase to another, this model is known as the waterfall
model. This model is also known as linear sequential model. This model is depicted in the following
diagram.
The principal stages of the model map directly onto fundamental development activities.

It suggest a systematic, sequential approach to software development that begins at the system level
and progress through the analysis, design , coding, testing, and maintenance.

In the literature, people have identified from 5 to 8 stages fo software development. The five stages
above are as follows:

1. Requirement definition and analysis: what the system services, constraints and goals are
established by consultation with system users. They are then define in detail and serve as
system specification.
2. System and software design: the system design process partitions the requirements to either
hardware of software systems. It establishes and overall system architecture, software design
involves fundamental system abstractions and their relationships.

3 Implementation and unit testing: how during this stage the software design is realized as a set of
program or program units. Unit testing involves verifying that each unit meets its specifications.
 4 Integration and system testing: the individual program unit or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After
testing, the software system I delivered to the customer.
5 Operation and maintenance: normally this is the longest phase of the software life cycle. The
system is installed and put into practical use. Maintenance involves correcting errors which were
not discovered in earlier stages of the life cycle, improving the implementation of system units
and enhancing the system; s services as new requirements are discovered.

In principle the result of each phase is one or more documents which are approved. No phase is
complete until the documentation for the phase has been completed and products f the phase have
been approved. The following phase should not start until the previous phase has finished.

Real projects rarely follow the sequential flow that the model proposes. In general these phases overlap
and feed information to each other. Hence there should be an element of iteration and feedback. A
mistake caught any stage should be referred back to the source and all the subsequent stages need to
be revisited and corresponding documents should be updated accordingly. This fees back path is shown
in the following diagram.

Because of the costs of producing and approving document, iteration is costly and requires significant
rework.
The waterfall model is a documentation-driven model. It therefore generates complete and
comprehensive documentation and hence makes the maintenance task much easier. It however suffers
from the fact that the client feedback is received when the product is finally delivered and hence any
errors in the requirement specification are not discovered until the product is sent to the client after
completion. This therefore has major time and cost related consequences.
2.3.2 Incremental models
As discussed above, the major drawbacks of the waterfall model are due to the fact that the entire
product is developed and delivered to the client in one package. This results in delayed feedback from
the client. Because of the long elapsed time, a huge new investment of time and money may be
required to fix any errors of omission or commission or to accommodate any new requirements
cropping up during this period. This may render the product as unusable. Incremental model may be
used to overcome these issues.
In the incremental models, as opposed to the waterfall model, the product is partitioned into smaller
pieces which are then built and delivered to the client in increments at regular intervals. Since each
piece is much smaller than the whole, it can be built and sent to the client quickly. This results in quick
feedback from the client and any requirement related errors or changes can be incorporated at a much
lesser cost. It is therefore less traumatic as compared to the waterfall model. It also required smaller
capital outlay and yield a rapid return on investment. However, this model need and open architecture
to allow integration of subsequent builds to yield the bigger product. A number of variations are used in
object oriented life cycle models.

There are two fundamental approaches to the incremental development. In the first case the
requirements, specifications, and architectural design for the whole product are completed before
implementation of the various build commences.
In a more risky version, once the user requirements have been elicited, the specifications of the first
build are drawn up, when this has been completed; the specification team turns to the specification of
the second build while the design team designs the first build. Thus the various builds are constructed in
parallel, with each team making use of the information gained in the all the previous builds.
This approach incurs the risk that the resulting build will not fit together and hence requires careful
monitoring.

2.3.3 Rapid Application Development (RAD)

Rapid application development is another form of incremental model. It is a high sped adaptation of the
linear sequential model in which fully functional system in a very short time (2-3 months). This model is
only applicable in the projects where requirements are well understood and project scope is
constrained. Because of this reason it is used primarily for information systems.
2.3.4 Object Oriented Life Cycle Models
Object oriented life cycle models appreciate the need for iteration within and between phases. There
are number of these models. All of these models incorporate some form of iteration, parallelism, and
incremental development.

2.3.4.1 Extreme programing

It is a somewhat controversial new approach. In this approach user requirements are captured through
stories which are scenarios presenting the features needed by all the clients?
Estimate for duration and cost of each story is then carried out. Stories for the next build are selected.
Then each build is divided into tasks. Test cases for task are drawn up first before and development and
continuous testing is performed throughout the development process.
One very important feature of extreme programing is the concept of pair programing in this a team of
two developers develops the software, working in team as a pair to the extent that they even share a
single computer.
In extreme programing model, computers are put in center of large room lined with cubicles and client
representative is always present. One very important restriction imposed in this model is that no team is
allowed to work overtime for 2 successive weeks. XP has had some successes. It is good when
requirements are vague or changing and the overall scope of the project is limited. It is however too
soon to evaluate XP.

2.3.4.2 Fountain Model

Fountain model is another object-oriented lifecycle model. This is depicted in the following diagram.
In this model the circles representing the various phases overlap, explicitly representing an overlap
between activities. The arrows within a phase represent iteration within the phase. The maintenance
cycle is smaller, to symbolize reduced maintenance effort when the object oriented paradigm is used.

2.4 Chosen Methodology

Our adopted methodology is rational unified process model. Rup is created by IBM that provides a
framework for development for project software.

This process model is very closely and associated with UML and Krutch n’s architectural model. A
software product is designed and built in a succession of incremental iterations. It incorporates early
testing and validation of design ideas and early risk mitigation the horizontal dimension represents the
dynamic aspect of the process. This includes cycles, phases, iterations, and milestones. the vertical
dimension represents the static aspects of the process described in terms of process components which
include activities disciplines, artifacts, and roles .the process emphasizes that during development, all
the activities are performed in parallel , however and at a given time one activity may have more
emphasis than the other.

The following figure depicting RUP is taken from Krutch n’s paper.
2.5 Reasons for chosen methodology:
The rational unified process (RUP) is a software process product designed as an object oriented and
desktop-enabled program development methodology.

It is a software engineering tool which compounds development aspects such as manuals, documents,
codes, models etc. with the procedural aspects of development such as techniques mechanics, define
stages, and practices with in a unified framework.

This methodology is fast and becoming a popular software development to map business process and
practices. Development is phased in to four stages. RUP methodology is highly flexible in its
developmental path as any stage can be updated at any time. The first stage or inception centers on
assessing needs, requirements, viability and feasibility of the program or project. The second step or
elaboration measures the architecture of the system’s appropriateness based on the project needs. The
third stage is the construction phase, where in the actual software system is made by the developing
components and features. This phase also includes the first release of the developed software. The final
stage is that of transition and marks the end of the development cycle; if all the objectives are met this
phase deals with the training of the end user beta testing and the final implementation of the system.
Advantages of RUP software development
RUP offers better control over the software development process. This is a benefit in term of quality
assurance.

 It has ability to control the software also makes it less flexible in the development process.
 RUP refers businesses the control they need when high security is necessary y providing a step
by step approval system ensuring that each step in the software development process has been
designed accurately.
 Each change must be looked at an approved through a designate management process before it
can be implemented in the project.
 It is proactively able to resolve the project risks associated with the client’s evolving
requirements requiring careful change request management.
 It takes less time is required for integrations the process of integration goes throughout the
software development life cycle
 The development time required is less due to reuse of components.

2.6 Work plan