Student Information System

hamburgerfensuckedSecurity

Nov 20, 2013 (3 years and 6 months ago)

96 views

Software Design Document

Student
Information System

1


Student Information System



Abbreviated Name:
SIS_
S
D
D

Software Design Document (SDD)

Revision: V1.0



Name

Signatures


Firas Alhamad
-

30098498


Abdulrahman Altoibi

-

30082171


Saud Aldawish
-

30097195


Fahad Alyahya

-

30089051





Software Design Document

Student
Information System

2

Contents



1. Scope

................................
................................
................................
................................
................................
................................
.......................

7

1.1 Identification.

................................
................................
................................
................................
................................
...............................

7

1.2 Purpose of Document.

................................
................................
................................
................................
................................
..............

7

1.2 System overview.

................................
................................
................................
................................
................................
........................

7

1.3 Document overview.

................................
................................
................................
................................
................................
.................

8

1.4. R
eferenced Documents.

................................
................................
................................
................................
................................
..........

8

1.5 System scope.

................................
................................
................................
................................
................................
...............................

8

1.5.1 Objectives

................................
................................
................................
................................
................................
..............................

8

1.5.2 Scope

................................
................................
................................
................................
................................
................................
.......

8

1.5.3 Non
-
function
al requirements

................................
................................
................................
................................
.......................

9

1.5.4 Interface with other systems

................................
................................
................................
................................
......................

10

1.5.5 Team Member Details

................................
................................
................................
................................
................................
....

10

2. Context Diagram.

................................
................................
................................
................................
................................
..............................

12

2.1 System Interfaces.

................................
................................
................................
................................
................................
....................

12

3.

Development Methodology and Technologies
................................
................................
................................
................................
.....

12

3.1 Applicability to project

................................
................................
................................
................................
................................
...........

13

3.2 Deliverables

................................
................................
................................
................................
................................
................................

13

3.3 Design Tools Used

................................
................................
................................
................................
................................
....................

15

3.4 Use Case Diagram

................................
................................
................................
................................
................................
.....................

15

3.5 Requirement Traceability

................................
................................
................................
................................
................................
.....

17

3.6 System Architecture and Interfaces.
................................
................................
................................
................................
.................

18

3.6.1 Interface identification and diagrams.

................................
................................
................................
................................
....

18

3.7 Interface Requirements (Interaction with External Systems).

................................
................................
.............................

19

3.7.1 CSV/Excel File Imports

................................
................................
................................
................................
................................
.......

19

3.7.2 CSV/Excel File Exports (for Reports)

................................
................................
................................
................................
...........

20

3.8 Adaptation.

................................
................................
................................
................................
................................
................................
..

20

3.9 Safety.

................................
................................
................................
................................
................................
................................
............

20

3.10 Security and privacy.

................................
................................
................................
................................
................................
............

20

3.10.1 Security by Design

................................
................................
................................
................................
................................
.........

20

3.
11 Operating Environment.

................................
................................
................................
................................
................................
.....

22

3.12 Development Technology

................................
................................
................................
................................
................................
...

23

3.12.1 Server Operating System

................................
................................
................................
................................
............................

23

3.12.2 Computer software.

................................
................................
................................
................................
................................
......

23

3.12.3 Decision Log/Rationale.
................................
................................
................................
................................
..............................

23

3.13 Software quality.

................................
................................
................................
................................
................................
....................

25

3.13.1 Externa
l System Quality

................................
................................
................................
................................
.............................

25

Software Design Document

Student
Information System

3

3.13.2 Internal System Quality

................................
................................
................................
................................
..............................

26

3.14 User and Technical Training.

................................
................................
................................
................................
............................

27

3.15 Non Functional Requirements.

................................
................................
................................
................................
........................

28

4. Entity Relationship Diagram.

................................
................................
................................
................................
................................
......

29

4.1 File Formats.

................................
................................
................................
................................
................................
...............................

30

4.1.1 Import File Formats

................................
................................
................................
................................
................................
........

30

4.1.2 Report Formats

................................
................................
................................
................................
................................
.................

30

5. Data Dictionary.

................................
................................
................................
................................
................................
................................

31

6. Object Oriented Design.

................................
................................
................................
................................
................................
.................

34

6.1 Class Diagram

................................
................................
................................
................................
................................
.............................

34

6.2 Sequence diagrams

................................
................................
................................
................................
................................
..................

35

6.2.1 Login to the system

................................
................................
................................
................................
................................
.........

35

6.2.2 Create new user

................................
................................
................................
................................
................................
................

36

6.2.3 Assign roles/privileges to a user

................................
................................
................................
................................
...............

37

6.2.4 Record a new student

................................
................................
................................
................................
................................
.....

38

6.2.5 Record welfare information

................................
................................
................................
................................
........................

39

6.2.6 Record incident information

................................
................................
................................
................................
.......................

40

7. Screen Prototypes

................................
................................
................................
................................
................................
............................

41

7.1 Login Screen

................................
................................
................................
................................
................................
...............................

41

7.2 Import Student Fil
e

................................
................................
................................
................................
................................
..................

42

7.3 Create Roles

................................
................................
................................
................................
................................
................................

43

7.4 All Roles

................................
................................
................................
................................
................................
................................
........

44

7.5 Role Privileges

................................
................................
................................
................................
................................
...........................

45

7.6 Create User

................................
................................
................................
................................
................................
................................
..

46

8. Implementation.

................................
................................
................................
................................
................................
...............................

47

8.1 System Decomposition

................................
................................
................................
................................
................................
...........

47

8.2 Implementation Diagram

................................
................................
................................
................................
................................
......

49

8.3 Modular Decomposition

................................
................................
................................
................................
................................
........

50

9. Style Guide.

................................
................................
................................
................................
................................
................................
.........

51

9.1 Header Style

................................
................................
................................
................................
................................
................................

51

9.1.1 Header Style Sample

................................
................................
................................
................................
................................
.......

51

9.1.2 Header style CSS

................................
................................
................................
................................
................................
...............

51

9.2 Navigation Style

................................
................................
................................
................................
................................
........................

52

9.2.1 Navigation Style sample

................................
................................
................................
................................
................................

52

9.2.2 Navigation C
SS

................................
................................
................................
................................
................................
..................

52

9.3 Body Text Style

................................
................................
................................
................................
................................
..........................

53

9.3.1 Body Text sample

................................
................................
................................
................................
................................
.............

53

9.3.2 Navigation CSS

................................
................................
................................
................................
................................
..................

53

Software Design Document

Student
Information System

4

9.4 Button Style
................................
................................
................................
................................
................................
................................
.

54

9.4.1 Button sample

................................
................................
................................
................................
................................
...................

54

9.4.2 Button CSS

................................
................................
................................
................................
................................
...........................

54

10. References.

................................
................................
................................
................................
................................
................................
.......

55

11. Appendixes.
................................
................................
................................
................................
................................
................................
......

56

11.1 Website External Quality Checklist

................................
................................
................................
................................
................

56

11.2 PHP Coding Stan
dards

................................
................................
................................
................................
................................
.........

58







Software Design Document

Student
Information System

5

Modification History


Version

Date

Authors

Summary of Changes

0.1

9/08 to 17/08

Project Team

Document Drafted

0.1

4/09

Project Team

Updated to incorporate lecturer feedback














Software Design Document

Student
Information System

6

Glossary


Term Name

Definition

Behaviour

Student behaviour including fights, disputes etc

Incident

Same as behaviour

On Demand Results

The twice an year exams done by students

System
Principles

School users with higher level of privileges

UML

Unified Modelling Language

ER

Entity Relationship

OOAD

Object Oriented Analysis and Design

IIS

Internet Information Server




Software Design Document

Student
Information System

7

1. Scope

1.1 Identification.

The Student Information System (referred to as SIS from here onwards in this document) is identified by
the
acronym SIS (Student Information System).

This document is the
Software Design
Document identified by
SDD SIS v0.2.

1.2 Purpose of Document.

The

purpose of this document is to provide

a System Design Document that will guide the technical development
(coding) and testing of the document.

The document

contains the following major design artefacts:

1.

Development Environment
and
Languages

2.

GUI Design

a.

Screen Designs

b.

Report Layouts

3.

Style guide

a.

Colour Maps

b.

Fonts

c.

Button Layouts

d.

Menu Designs

4.

Design and Implementation Decision rationale

5.

Preliminary Data Dictionary

6.

Entity Relationship Diagram

7.

Class Diagram

8.

Sequence Diagrams

9.

System Architecture Diagram

10.

Non Fun
ctional Design Qualities

11.

System Decomposition into Sub Systems

1.2 System overview.

The Client Organization has identified that they are now collecting a range of data about their students including
attendance data, achievement data, behaviour data, con
tact details, timetables, alternative programs data and
other information.

The ultimate aim is to develop a unified IT System for administrative staff, academic staff and management which
will populate a centralized information system. This information sys
tem will then also be able to expose the
information collected to individual staff members in a usable and efficient manner.

Major objectives of this project are:



Provide a single consistent gateway to student data for all levels of school administration
staff,



Create a consistent, easy to use, accessible and secure system around the needs of school administration
and management,



Deliver a unified student information management system to allow administrators and academics to
perform their respective tasks
efficiently,



Simplify the administrative processes for students and parents,



Provide easy accessibility to student information via a central point

Software Design Document

Student
Information System

8

1.3 Document overview.

The purpose of this document is to provide a
system analysis and design

specification document that
expands on
the business requirements defined in the System Requirements Definition document and provides a solution
direction for the technical team to begin technical development (coding).


The document is developed for the pu
rpose of reading and review by the following parties:

1.

Development Team

2.

Design Team

3.

Analysis Team

4.

Testing Team

5.

Student Information System Users

6.

Project Sponsor

The document must be used by the above parties in strict confidence.

1.4
. Referenced Documents.

Software Project Management Plan

Work Breakdown Structure

Client Meetings and Status Reports

System Requirements Specification

1.5 System scope.

1.5.1 Objectives


Major objectives of this project are:



Provide a single consistent gateway to student
data for all levels of school administration staff,



Create a consistent, easy to use, accessible and secure system around the needs of school administration
and management,



Deliver a unified student information management system to allow administrators and

academics to
perform their respective tasks efficiently,



Simplify the administrative processes for students and parents,



Provide easy accessibility to student information via a central point

1.5.2 Scope

1.5.2.1 Key Features and Functionalities of the
System

Note
: The key features and functionalities of the system are listed below. However, these features and
functionalities are not meant to be in detail. The detailed requirements will be presented in a separate user
requirements document later on in th
e project.

Feature

Functionalities Required

Master Data Management

Allow respective administrators
to manage the master data such
as Room Details, Program Data,
Subject Data

1.

Allow administrators to update master data
including room details, program data

and subject
data

2.

Allow ‘super’ administrator users to define access
灲楶楬敧es⁴漠m慳t敲⁤慴愠敬em敮es


Software Design Document

Student
Information System

9

Feature

Functionalities Required



Student Data Management

All respective administrators to
manage the student data
including attendance data,
achievement data, behaviour
data, contact
details, timetables,
alternative programs data and
other information



1.

Allow administrators to update student data element

2.

Enforce business rules to ensure the integrity of
student data

3.

Allow ‘super’ administrator users to define access
灲楶楬敧es⁴漠
s瑵摥湴t摡d愠敬敭敮es



Access/Search

Allow the users to search for
required information easily


1.

Authorized users should be able to view information
as required.

2.

Allow a multi dimensional search based upon
keyword, id, name, description, notes etc.

3.

I
nclude multiple types of search criteria such as
exact match, partial match, wildcard search etc.

4.

Authorized users only should be able to query the
relevant information.

Reporting

Allow users to generate
summary and detailed reports
on student data.


1.

Allow generation of period administrative reports
such as monthly attendance reports.

2.

Allow generation of summary reports such as total
numbers of students by each class.

3.

Allow generation of detailed reports such as all
students enrolled in a class or prog
ram of study.

Administrative Tools

Administrators should be able to
manage the report’s
慤ainis瑲慴t潮o慮a
c潮oig畲慴u潮



The administrators should be able to manage the
users


-

Reports on users of the system

-

Tools to remove users from the system

-

Define access privileges for users

-

Run maintenance tasks (TBC)

2.

Audit the usage of the system

3.

Run audit reports for activities in the system


1.5.3 Non
-
functional requirements

Operational
Requirements


-

The system should provide 100% uptime.

-

The
system must be technologically, functionally and operationally feasible for at least 5 years from go live.

-

The system must provide different levels of access for users

-

The system must have a high level of accessibility and usability


Security Requirements

Software Design Document

Student
Information System

10

-

Confidential data should only be viewable by authorised personnel.

-

Different types of user groups are to be created with different roles and privileges.


Performance Requirements

The system should be able to handle

-

Up to 50 simultaneous users

-

Data for appr
oximately 1000 active students at any given time

-

Data for approximately 10000 students historically


Other non functional requirements


-

The system must be robust such that additional development/maintenance on the system can be performed
without any major
restructure of the system


1.5.
4

Interface with other systems

Initially the system will not interact with any other information systems at the organization. The only interfaces
will be:

Interface to CSV/text files to import core data into the Student In
formation System (Initial and Periodic).

There will be no other systems to any web systems in this first phase of the project. The interface to the web
systems may be considered in a future phase to allow students/guardians or employees to access the infor
mation
from home.

1.5.
5

Team Member Details

The following table contains the names of TechOne team members with their roles and responsibilities:

Member Name

Role

Responsibilities

Skills

Saud Aldawish

Student Id: 30097195

smdowish@hotmail.com

Contact No:
0421649513


Business Analyst

-

Analyse, understand and
document the processes in
system’s current state.

-

Identify stakeholders
and
devise a communication
plan.

-

Identify and document all
business, technical and
process requirements.

-

Work with users to
prioritize and rationalize
the requirements.

-

Help Project Manager in
defining acceptance criteria
for the project.

-

Help Project Mana
ger in
busy period writing and
reviewing documentation.

-

Analytical and
investigative skills

-

Process Modelling

-

Data Modelling

-

Specification
writing and
business writing

-

Interpersonal
communication
skills

-

Presentation and
training skills

-

Knowledge of both
tr
aditional and
agile software
development
techniques

-

Leadership skills

Abdulrahman Altoibi

Student Id: 30082171

Mr_altoom@hotmail.com

System Designer
/ Programmer

-

Design high level software
infrastructure.

-

Design prototypes and
models according to user
requirements.

-

Assist business analysts in
-

Unified modelling
techniques

-

Object Oriented
design and analysis
skills

-

Database design
Software Design Document

Student
Information System

11

Contact No:
0422213751

designing use case
diagrams and use case
scenarios.

-

Help programmers in
designing unified
mode
lling diagrams, entity
relationship diagrams, data
flow diagrams, mock
screens and wire frames.

-

Help in code reviews and
code quality assurance.

and development
skills

-

Well developed
coding skills in

-

Web based
technologies
including ASP.NET
and PHP

-

DBMS systems
including MySQL,
Oracle and MS
Access

Firas Alhamad

Student Id: 30098498

feras.alhamad@hotmail.com

Contact No:
0402519733


Programmer

-

Assist business analysts in
documenting business
requirements.

-

Work with business
analysts and system
designer to convert the
business requirements into

a technical design.

-

Undertake program design.

-

Write code to meet
program design
specifications.

-

Modify code to correct
errors or enhance the
program design.

-

Prepare documentation for
other programmers and
support personnel.

-

Advise Business Analysts,
Syste
m Designer on
functional aspects of the
system.

-

Database design
and development
skills

-

Well developed
coding skills in

-

Web based
technologies
including ASP.NET
and PHP

-

DBMS systems
including MySQL,
Oracle and MS
Access

Fahad Alyahya

Student Id:
30089051


fahad12@hotmail.com.au

Contact No:
0410155999


Tester

-

Help the project manager,
quality manager in
developing a quality plan
and acceptance crite
ria.

-

Build test plans

-

Build test scripts

-

Execute test scripts

-

Help the project manager
and business analysts
developing a risk
management plan with
mitigation strategies.

-

Conduct the technical and
functional testing (Follow
the V
-
Model of testing)

-

Test Pla
n
development skills

-

Test script
development and
execution skills

-

Proficient in use of
test tools such as
Quality Centre

-

Skilled in
functional,
technical and
quality testing

-

User acceptance
testing skills





Software Design Document

Student
Information System

12

2. Context Diagram.


0
Student Information
System
Teachers
,
System
Principles
,
Counsellors
Welfare Information
Welfare Information Reporting
Super User
On Demand Result Information
On Demand Reporting
Incident Information
Behaviour Information
Behaviour Reporting
Incident Reporting
User Report
New User Details
Contact Detail Information
Contact Reporting
Record Update Confirmation Emails
Incident Reporting Email Configuration
Behaviour Reporting Email Configuration
Welfare Reporting Email Configuration
Roles
/
Privileges configuration
User Privilege Information

2.
1

System Interfaces.

Initially the system will not interact with any other information systems at the organization
. The only interfaces
will be:

Interface to CSV/text files to import core data into the Student Information S
ystem (Initial and Periodic)

There will be no other systems to any web systems in this first phase of the project. The interface to the web
systems may be considered

in a future phase to allow students/guardians or employees to access the information
from
home.

3
.
Development Methodology

and Technologies

Traditional software development methodology “Waterfall Model” will be used in the development of this system.
The phases in the Waterfall Model include:

Requirements
: The requirements gathering phase
has already been completed. This included the requirements
elicitation with the client, requirements analysis and documentation. The requirements have been signed off by
the client prior to this document being written.

Design
: This document is part of the
Design phase of the project.

The design phase involves expanding the user
requirements into a functional solution design ready for implementation.

Implementation
:

The implementation phase is the next phase of the project that will begin once this document
has been signed off. The implementation phase will include

coding and bash testing. The bash testing will be done
by the developers during
implementation to remove any obvious bugs.

Verification
:

The verification phase will involve comprehensive functional

and non
-
functional testing of the
system.

Maintenance
:

The project team will not be involved in the maintenance phase. At implementation, the project
team will hand over the fully functional system to the client and it will be responsibility of the client

organization
to maintain the system.

The key activities, as also indicated in the Work Breakdown Structure are:

Software Design Document

Student
Information System

13



Project Initiation



Requirements Analysis



Project Planning



Software Design



Technical Development


-

Infrastructure Setup

-

Development (Code Writing
)



Technical Testing



Documentation



System Implementation



Maintenance and Support


The waterfall methodology has been chosen for the following reasons:

1.

The project team is working together for the first time. Therefore, the project team needed a methodology
that will provide a regulated and sequential process for the development of
Student Information System
. A
non
-
sequential and non
-
definitive methodolo
gy such as Agile requires a lot of discipline which can take
time to establish in a new project team;

2.

The project is going to last for one year. It is a client (project supervisor) requirement that the first half of
the project is used to plan and analyse
the system. This is only possible in waterfall methodology. In
methodologies such as agile methodology or Scrum
, the development and analysis go side by side.

3.

The project length of one year is suitable for waterfall model. The agile projects are usually sm
aller and are
done in iterations.

4.

The project related deliverables (System Requirements Specification, System Analysis and Design
Document) are only relevant to the waterfall development cycle.

5.

The use waterfall development cycle has meant that
the deliver
ables are comprehensive, signed off and
refined. None of the knowledge and information gathered in the first phase of the project will be lost
during the one month break in the project where the project team is on holiday (semester break).

3
.1
Applicabilit
y to project

The Waterfall Methodology will be specifically applicable to this project for the following reasons:

1.

The system is an initial development (there is no existing system apart from some spreadsheets).
Therefore
, significant analysis and docume
ntation will be required to assert the accuracy and reliability of
the system.

2.

The client does not have time to engage in Rapid Application Development sessions very frequently. The
client prefers to work via solid documentation and approval workflow.


3.2

Deliverables

The project must deliver the following as a minimum:

Deliverable Type

Deliverable Details

Delivery Date

Software Design Document

Student
Information System

14

Deliverable Type

Deliverable Details

Delivery Date

Software Project Management
Plan

Project Plan containing

-

Project Introduction

-

Scope definition

-

Risk Management Strategy

-

Assumptions
and Constraints

-

Quality Plan

-

Communication Plan


23
-
Mar
-
2012

Delivered and
Signed
-
off

Project Plan Document

Project Plan containing

-

Project Introduction

-

Scope definition

-

Project Cost and Schedule (Gantt Chart)

-

Risk Management Strategy

-

Assumptions and
Constraints


13
-
Apr
-
2012

Delivered and
Signed
-
off

System Requirement
Specifications

Requirement Specifications

-

High level user requirement definition

-

Detailed user requirement definition


27
-
Apr
-
2012

Delivered and
Signed
-
off


Design Documents

Software Design document

-

Wire frames

-

User Interface Mock Designs

-

Database Design (Data Flow and Entity
Relationship)

-

Technical Architecture

-

Unified Modelling Language (UML) Diagrams


25
-
May
-
2012

This document.


Technical Development

-

Database scripts

-

Project code


30
-
Aug
-
2012


Future
Deliverable


Testing

-

Test plan document

-

Test scripts

-

Issue register

-

Test execution and results document

-

Acceptance Testing Documentation

30
-
Sep
-
2012


Future
Deliverable


Product Documentation

-

User Guide

-

Systems Manual

30
-
Oct
-
2012


Future
Deliverable


Support Strategy

-

Support Team Structure

-

Support documentation (Manuals)

15
-
Nov
-
2012


Future
Software Design Document

Student
Information System

15

Deliverable Type

Deliverable Details

Delivery Date

Deliverable


Go Live

Implementation and Go
-
Live

30
-
Nov
-
2012


Future
Deliverable


3.
3

Design Tools Used

A number

of different design tools (methods and technical software tools) have been utilized to produce the
artefacts to represent the system design.

The

design methods used are:

1)

Unified Modelling Language for Class Diagram and Sequence Diagrams (UML Standards v2.
0)

2)

Context Diagram

3)

Entity Relationship Diagram

4)

System Architecture Diagram

The tools that have been used to develop these diagrams include:

1.

Microsoft Office Word

2007

2.

Microsoft Office Visio

2007

3.

Enterprise Architect

2.4.1

4.

SD Edit (Open Source tool for
sequence diagramming)

v1.0

3.
4

Use Case Diagram

1.

NAPLAN Results will also be covered as part of the Record On Demand Results.


Software Design Document

Student
Information System

16

2.

2. The file imports will be in SV and TXT format.


Teachers/

Counsellors/

System
Principles


Record
Welfare
Information

Record
Incident
Resolutions

Generate
Reports

Record
Behaviour
Actions

Record
Contact
Information

Record
Incident
Information

Record
Behaviour
Information

Search
Students

Import

Student List

Student
Informatio
n System

Record on
Demand
Results

Add

Students

Send Update
Email

Add new
users in
system

Login

To

System

Validate
Login
Information

<<includes>>


<<includes>>


<<includes>>


<<includes>>


<<includes>>


<<includes>>


Setup
roles/privilig
es

Setup
roles/privile
ge for users

Super User

Software Design Document

Student
Information System

17

3.
5

Requirement
Traceability

Note: Please note that the below are not use case stories. Th
ese are requirement specifications are per the IEEE
standards.

Reference
: Deakin University, Practical Software Development Study Guide

UR_1

The system should allow the user to import a student list file into the system

UR_
2

The user should be able to
add a new student into the system by providing student id,
given names and last name

UR_
3

The user should be able to add the contact details for a student into the system

UR_
4

The user should be able to add the contact details for a parent into the syste
m

UR_
5

The user should be able to record incident information into the system

UR_
6

The user should be able to configure who should receive the incident reports

UR_
7

The user should be able to welfare information into the system

UR_
8

The user should be
able to configure who should receive the welfare reports

UR_
9

The user should be able to behaviour information into the system

UR
_
10

The user should be able to generate reports in the system

UR_
1
1

The user should be able to create new roles

UR_
1
2

The u
ser should be able to update privileges that are assigned to the role

UR_
1
3

The user should be able to assign/change a role to the user

UR_
1
4

The user should be able to add and update the
On
Demand

results into the system

UR_
1
5

The admin users should be

able to add new teachers into the system.





Software Design Document

Student
Information System

18

3.
6

System Architecture and Interfaces
.

3.
6
.1 Interface identification and diagrams.

The Student Information System Software System will be developed as a web application using PHP & MySQL
Technology. The
point of mentioning the technology at this stage is that the application will need to interact with a
web based server with a standard web browser acting as the client.


Figure

1
: Interface Identification

Client


The client will be a standard browser,

Web Application


The web application will run on a server with load balancer.

SIS

Database


The web server will connect to the SIS database.

Therefore, there are mainly two interfaces


Client to the web server


Web Server to the database

In addition to
this, the system will need to be able to import/export from CSV files.

Import = Data Load / Maintenance Purposes

Export = Reporting Purposes

This will be the only interface apart from the commonly used multi
-
tier architecture.

Software Design Document

Student
Information System

19


3.6.1.1 Limitations/Constrai
nts


1.

All users must have access to the internet to be able to access the system.

2.

The school must be willing to either buy dedicated in
-
house servers or outsource the hosting to an external
third party server space provider.

3.

There will be a need to proac
tive find software upgrades (to the LAMP stack) and apply those upgrades
because of the free and open source software being utilized (PHP/MySQL)

4.

There will be a need to establish in house hosting for the web based system since the privacy laws prohibit
the

data of students being stored on outside hosting

a.

The outside hosting will require complex contractual requirements which is not within the school
administration’s skill

set

5.

There are no in
-
house skills in the school to maintain a web based system. So, the
re will be a need to either
hire at least one person full time or contract out the development and support for the system


3.6.1.2
Architecture Qualities (Advantages)


1.

Portability

The chosen architecture will allow for the system to be highly portable. The system can be
deployed on most server systems including windows, unix and linux that
can run the lamp stack. If the
system’s coding standards suggested in this document are follow
ed, then there will not be any need to
make any changes to the system except minor configuration changes.

2.

Feature Richness

The chosen architecture allows making use of the web standards and features for
example Web 2.0, access from anywhere for the users

u
sing a web browser.

3.

Security

The security of the system will be centralized on the server. It will be easier to secure the system
since the server software provides much better level of security compared to
the desktop based
applications such as Microsoft
Office databases.

4.

Central Management

The code will be managed centrally on a production server. This will ensure
maintainability of the system.

3.
7

Interface Requirements (Interaction with External Systems)
.

The only interface requirement is to

1.

Bulk
import of data from excel spreadsheets (Excel or CSV Format)

2.

Exporting reports into excel spreadsheets (Excel or CSV Format)

The following diagram illustrates the interfacing requirements with other systems and tools (including f
ile
import/export requireme
nts).

3.7.1 CSV/Excel File Imports

1
.
File Import Request
2
.
File Connection
3
.
File Data
4
.
Store in Database

1.

The user requested file import

2.

The system makes a connection to the
CSV
/excel file

3.

The system

imports the file data

4.

The web server stores the data into the physical database

Software Design Document

Student
Information System

20

3.7.2 CSV/Excel Fi
le Exports (for Reports)

1
.
Report Generate and
Export
2
.
File Connection
2
.
Get Report Data
from Database
3
.
Export to Excel
/
CSV

1.

The user requests a report export into CSV/excel

2.

The system extracts the data from the database for the report

3.

The system makes a connection to the CSV/excel file

4.

The system exports the report into
excel/CSV file

3.
8

Adaptation.

There are a number of adaptation requirements applicable to the implementation of the system at the school:

1.

The teachers, system principles, managers and counsellors will need to adapt to use of the system for
entering inc
ident reports as opposed to use of manual paper based systems.

2.

The system principles, managers and counsellors will need to adapt to use of the system for entering
student welfare information as opposed to use of manual paper based systems.

3.

The users of th
e system including teachers, system principles, managers and counsellors will need to adapt
to the use of the system to generate reports as opposed to manual processing in MS Excel.

4.

The school in general will need to adapt to use of technology and maintena
nce of the infrastructure in
accordance with maintenance plan to be provided at a later stage in the project.

3.
9

Safety.

There are no physical safety requirements related to the system.

3.
10

Security and privacy.

The system is going to record
following confidential information about students:

1.

Student/Parent Contact Information

2.

Student Welfare Information

3.

Incident Reports and Counselling Information

4.

Student Achievement Information (On Demand)

This information is highly confidential and if this i
nformation is exposed to people who are not authorised to use
this information, it can have serious legal and integrity issues for the school. Therefore, there is a need to ensure

1.

No one outside the information can access any information that is held in th
e system.

2.


There are roles that can be setup by a
super

user and these roles can be configured down to each
individual screen and each individual report

3.10.1 Security by Design

1. Error reporting

The error reporting will be set to highest level to
ensure that maximum protection and visibility into system issues

Directive name

Production

Development

Software Design Document

Student
Information System

21

display_errors

Off

On

error_reporting

E_ALL

E_ALL

log_errors

On

On

errr_logo

Record all errors in
error.txt file

Record all errors
in error.txt file


2. SQL Injection

Normalizing malicious data

All data will be
made safe

by applying escape sequences to the malicious data. For this purpose, mysql extension
will be utilised, specifically the mysql_real_escape_string will be utilised which normalizes all

malicious data by
escape sequences.

Below is a sample code script that will be used:

<?php

$db = mysql_connect('localhost', 'username', 'password');

mysql_select_db('school', $db);

$studentName = mysql_real_escape_string($_POST['student_name'], $db);

$que
ryResult = mysql_query("INSERT INTO Students (name) VALUE ('{$studentName}')");

if ($queryResult) {


echo 'Success.';

}

else {


echo 'Insertion failed. Please try again.';

}

?>

3. External File Access

A directory structure has been identified

that will be used in order to make sure if Apache/WAMP server fails (that
is running PHP), none of the website’s code is displayed to the end user:

/application


/controllers


/models


/views

/library

/public_html <
--

document root


/index.php

Software Design Document

Student
Information System

22


/medi
a


/images


/javascript


/css

/config

/cache

/tmp

/public_index.php

/logs


4. Remote file access

All remote file access to the system will be disabled since there is no system requirement to do so. The following
two php configurations will be set

to false:

1.

allow_url_open

2.

allow_url_include

5. Session data security

The security of the session data will be ensured by:

1.

Using dedicate hosting instead of shared hosting

2.

Regenerating session ids periodically

6. The directory traversal will be disabled

7.
The login page will be encrypted using SSL certificate.

8. All data will be validated on the server side (in addition to the client validations)

9. Login credentials will be kept different for all applications connections (FTP users, database users/passwor
ds
etc)

10. Strong passwords will be used.

11. All server software will be patched with the latest patches.

12. Any services that are running on the servers but not being used will be stopped.

13. Only local Australian hosting will be used to ensure accou
ntability for data held on the hosting.

3.
11

Operating

E
nvironment.

The system should run on any computer (desktop, workstation, laptop) with a Windows XP or above Windows
based operating system.

Software Design Document

Student
Information System

23

3.1
2

Development Technology

3.1
2
.1
Server Operating Sy
stem



Linux based server

3.1
2
.
2

Computer software.

Technology Type

Preferred Technology

Development Platform

Linux, WAMP Stack

Programming Language

PHP
5

Database

MySQL

Server Application

Server Application

Client Software Requirements

Standard Web
Browser

No client installations are required

3.1
2
.
3

Decision Log/Rationale
.

Type

Decision

Decision Rationale

Development Architecture

3
-
Tier Web Architecture

Web a
rchitecture has been
chosen for development of
Student Information System for
following
reasons:

1.

Easy deployment

2.

No installation on client
workstations

3.

Comprehensive options
for GUI functionality

4.

Proven and tested
architecture

5.

Plenty of open source
technologies to support
rapid development

6.

Opportunity for public
accessibility (e.g.,
employees

working from
home in the future)

Technology Type (Proprietary /
Open Source)

Open Source

Open Source platform
(Linux/WAMP/PHP/MySQL) has
been chosen as the preferred
technology for the development
of

Student Information System
for following reasons:

1.

Fre
e

2.

Tested and Proven

3.

Good for moderate size
systems

Software Design Document

Student
Information System

24

4.

Readily available
technical expertise for
future support and
development

5.

Simple architecture

6.

Proven security

Development Platform

Linux, WAMP Stack

WAMP Stack on Linux has been
used for following reasons:

1.

Linux offers better
security that windows
based operating systems

2.

WAMP has a simple
architecture and
combines PHP & MySQL
into a single web server

3.

WAMP is lightweight

4.

WAMP offers
comprehensive error
logging and monitoring.

Programming Language

PHP 5

See
above

Database

MySQL

MySQL is compatible with PHP
as a number of development
stacks including WAMP support
the PHP+MySQL combination. In
addition,
PHP has a number of
built in features that allow easy
interaction with MySQL.

Client Software Requirements

Standard Web Browser

No client installations are required

This was one of the main
reasons for choosing web based
architecture. The web based
architecture will mean that
clients do not have to install any
additional software on their
machines. This is good in a
school environment where
technology upgrades may be
slow
.

Programming Methodology

Object Oriented

[Decision made in 2
nd

design phase]

It has been decided that all
coding will be implemented in
object oriented manner. This will
ensure the easily debugging,
maintainability and extensibility
of the software.

Hosting Solution

Internally Hosted

[Decision made in 2
nd

design phase]

It has been decided that the
system will be hosted at the
school premises due to the
Software Design Document

Student
Information System

25

privacy laws governing the use
of storage of student
information.

3.1
3

Software quality.

3.1
3
.1

External System Quality

After careful review of various software quality review models, McCall model

has been chosen to evaluate the
quality of this product.

McGall model has three major viewpoints for defining and classifying the quality of a software p
roduct:



ability to undergo changes (Product Revision),



adaptability to new environments (Product transition) and



operational characteristics of the application(its operation characteristics)

Specifically, following quality requirements must be met by the
system as a minimum:

1.

The system should be easy to use (i.e. should be able to learn without a manual).

2.

The system should include help on major or complex features within the system (e.g. like a Help Menu)

3.

The website theme should be consistent and match th
e school’s theme of colours and designs.

4.

The file input/outputs should be easy to use.

5.

The system should support up to 20 simultaneous users.

6.

The system should be highly secure
since it is going to store highly sensitive data. The student data should
be en
crypted.

7.

The system should be available 24x7 except maintenance which should only be carried outside of working
hours.



Software Design Document

Student
Information System

26


Figure1: McCall’s quality attributes

3.1
3
.2 Internal System Quality

The Internal System
quality will ensure the following quality att
ributes:


1.

Usability


a.

The usability of the system will be measured using the following criteria:

i.

The users should be able to perform all tasks except the importing/exporting of data and
administrative functions without a user manual;

ii.

The
system should be
able to perform all functions within 2 seconds;

iii.

The system should provide informative error messages for any invalid actions. These
informative messages should ensure that the user doesn’t have to look around in the
system to find the cause of the error.


2.

Portability


a.

The system
will

be portable to a Windows based server platform without any code changes (i.e.
only minor changes to the WAMP configuration
may

be required)
. For this purpose, all of the
configuration will be stored in
general

configuration fi
le. There will be no hard coding of any type
in the PHP Code.


b.

The system will be portable to a different technology stack (e.g. Apache) server platform without
any code changes (i.e. only minor changes to the configuration may be required). For this purpo
se,
Software Design Document

Student
Information System

27

all of the configuration will be stored in
general

configuration file. There will be no hard coding of
any type in the PHP Code.


3.

Architecture Quality


a.

The system architecture will include


i.

Dedicated hosting to ensure safety and reliability

ii.

Hosting in
Australia to avoid any legal concerns around student data privacy

iii.

SSL encryption for all login pages

iv.

Code level security as explained in the
security guidelines above


4.

Code Quality

a.

The code quality will ensure that the code is readable, maintainable and ea
sy to extend

b.

The code quality guidelines
that will be followed during coding
are listed in Appendix 2
.


5.

Documentation Quality


6.

Security


a.

System Security


i.

The system should be hosted inside a secure HTTP (HTTPS) environment.

ii.

The system should protect agains
t the SQL Injection attacks.


b.

User Security


i.

The security model should be based on the principle that
user should have minimum access
to ensure they can do their job functions
.

ii.

All changes to database records should be audited.


3.1
4
User and Technical
Training
.

The system must provide sufficient information for a user to be able to use the system without any training.

There is a need to develop following comprehensive training related documentation for future sustainability of the
system:

1.

Comprehensi
ve User Manual


one user manual for each of the following functional area

a.

Contact Information Management

b.

Welfare Information Management

c.

Incident Information Management

d.

Reporting

e.

Access Rights Management


2.

There is also a requirement for the project team to

provide face to face training for up to five users that
will train the users at the school.


3.

Comprehensive Programmer Manual


one programmer manual containing all information that is
necessary for a future development team to understand and extend the St
udent Information System
.


Software Design Document

Student
Information System

28

4.

All artefacts included in the System Analysis and Design Document will be kept up to date throughout
the development lifecycle.

This will enable the project team to hand over the system will full technical
specifications includin
g the context of why certain decisions were made during the design phase.


The school will then be able to use the comprehensive programmer manual and the up to date SAD document to
provide all required
information to

a freelance programmer/development agency in the future.

3.1
5

Non Functional Requirements.

The following non functional requirements apply to the development of the Student Information System:

Operational
Requirements


-

The system should provide 100% u
ptime.

-

The system must be technologically, functionally and operationally feasible for at least 5 years from go live.

-

The system must provide different levels of access for users

-

The system must have a high level of accessibility and usability


Security Re
quirements

-

Confidential data should only be viewable by authorised personnel.

-

Different types of user groups are to be created with different roles and privileges.


Performance Requirements

The system should be able to handle

-

Up to 50 simultaneous users

-

Da
ta for approximately 1
2
00 active students at any given time

-

Data for approximately 10000 students historically

-

The system should archive students who have left the university


Other non functional requirements


-

The system must be robust such that additiona
l development/maintenance on the system can be performed
without any major restructure of the system



Software Design Document

Student
Information System

29

4
.
Entity Relationship Diagram
.



U
serTable

user_id

first_name

last_name

user_type

active?


RoleTable

role_id

role_name


SystemFunctionTable

System_function_id

function_name



OnDemandResultsTable

student_id

session

year

mark



IncidentTable

incident_id

incident_type

dateofincident

timeofincident

priority

description

location

problem_nature

resolution


StudentTable

student_id

first_name

last_name

dateofbirth

street_address

city

postcode

state

country

emergencycontact_name

emergencycontact_relation

emergencycontact_phone

emergencycontact_email

active?




EmailConfigurationTable

incident_type

priority

content





WelfareTable

welfare_id

type_of_welfare_info

description



WelfareCommentHistory

comment_id

comment

post_date




1

*

commits


1

*

has


1

*

1

*

has


has


1

1

1

is recorded by


Sent to


1

*

has


1

1

is recorded by


1

*

has


1

1

is recorded by


Software Design Document

Student
Information System

30

4.1 File Formats.

4.1.1 Import File Formats

1. The import files (to be imported into the system) will need to be the CSV format.

2. The only data that can be imported in the system will be the student data.

3. The
names and order of columns in the file to be imported will need to be:

student_id



This column will be mandatory (must be populated)

first_name


This column will be mandatory (must be populated)

last_name


This column will be mandatory (must be populated)

dateofbirth


This column will be mandatory (must be populated)

street_address

city

postcode

state

country

emergencycontact_name

emergencycontact_relation

emergencycontact_phone

emergencycontact_email

active?


If the column is empty, it will be set to N


4.1.2 Report Formats

The user will be able to produce the reports in the following formats:

1.

Web format (HTML Table)

2.

CSV Format

3.

PDF Format


Software Design Document

Student
Information System

31

5. Data Dictionary.


StudentTable



This table stores the core student data

student_id


A unique identifier
assigned to each student

first_name


The student’s first name

last_name



The student’s last name

dateofbirth



The student’s date of birth

street_address



The street address (including unit no., house no., street name)

city



The suburb for student addr
ess

postcode



The post code for the student address

state

-

The state for the student address

country



The country for the student address

emergencycontact_name



Emergency contact person’s name

emergencycontact_relation



Relationship with the emergen
cy contact

emergencycontact_phone



Emergency contact’s contact phone number

emergencycontact_email



Emergency contact’s email address

active?



Indicator to store whether the student is a current student


OnDemandResultsTable


This table stores

the on demand results (2 sessions per year per studnt)

S
ession



The session one or session two in the year

Y
ear



The year for on demand results

M
ark



The mark for the year/session


IncidentTable



This table stores the incident (disciplinary or otherw
ise) that occur

incident_id



A unique identifier assigned to each incident

incident_type



The type of incident

dateofincident



Date of incident

timeofincident



Time of incident

priority



Priority (Severe, Medium, Low)

location


The location of the

problem (e.g. Corridor)

nature of problem


The nature of problem (Physical, Emotional etc)

Software Design Document

Student
Information System

32

description



Description of the incident

resolution_details



details of the resolution


WelfareTable

-

This table stores the welfare information (e.g. special ca
re requirements, childhood trauma
details etc)

welfare_id



A unique

welfare id assigned to each record

type_of_welfare_info



Type of welfare information

description



Full details of welfare information


WelfareCommentHistory



The comments that are added to the welfare history records by the users

comment_id



A unique id assigned to each comment

comment



The actual comment

post_date



The date comment was posted


EmailConfigurationTable



The email configurations will be st
ored here. These emails will be automatically
sent to the relevant staff members when
an incident of the given type/priority is changed

incident_type



The incident type

priority



The priority of incident

content


The content of the email

that will be se
nt for this incident type / priority


UserTable



The user table. All users of the system will be recorded in this table

user_id



A unique user id assigned to each user

first_name



The first name of the user

last_name



The last name of the user

user_typ
e



The type of user (Teacher, Student Administrator)

active?



If the user is still active in the system, e.g. if a user leaves the school, then the Active flag will be set to N


SystemFunctionTable



All function of the system will be stored in this table
. This table will essentially store
names of all screens and reports.

System_function_id



A unique id assigned to each system function

function_name



The name
of the screen or the function


Software Design Document

Student
Information System

33

RoleTa
ble



This is he link table between the users and roles (to resolve the many to many relationship)

role_id



A unique id assigned to each role

role_name



The name of the role
Software Design Document

Student
Information System

34

6. Object Oriented Design.

6.1 Class Diagram


Student

-

student_id : String

-

first_name : String

-

last_name : String

-

dateofbirth : Date

-

street_address : String

-

city: String

-

postcode: String

-

state: String

-

country : String

-

active : Boolean

-

incidentManager : WelfareManager

-

welfareManager : WelfareManager

+ Student()

+ Student(String,String,String,Date)

+ mutatorMethods(newValue)

+ accessorMet
hods() : Type

+ addIncident(Incident) : Boolean

+ getAllIncidents() : List<Incident>

+ removeIncident(String) : Boolean

+ getIncident(Incident) : Incident

+ updateIncident(String,Incident) : Boolean

+ toString() : String


StudentManager

-

studentList:
List<Student>

+
StudentManager()

+ addStudent(Student) : Boolean

+ getStudent(String) : Student

+ deleteStudent(String) : Boolean

+ updateStudent(String,Student) :
Boolean

Incident

-

incident
_id : String

-

incident_type

: String

-

dateofincident

:
Date

-

timeofincident

:
Time

-

priority

: String

-

description
: String

-

resolution_result
: String

+
Incident
()

+ Incident (String,String,Date,Time)

+ mutatorMethods(newValue)

+ accessorMethods() : Type

+ toString() : String


IncidentManager

-

incidentList: List<
Incident>

+
IncidentManager ()

+ addIncidentt(Incident) : Boolean

+ getIncident (String) : Incident

+ deleteIncident (String) : Boolean

+ updateIncident (String,

Incident) :
Boolean

Welfare

-

welfare_info
_id : String

-

info_type : String

-

description : Strin
g

-

commentManager : welfareCommentManager

+
Welfare

()

+ Welfare (String,String,String)

+ mutatorMethods(newValue)

+ accessorMethods() : Type

+ addWelfareComment(WelfareComment) : Boolean

+ getWelfareComment(String) : Welfare

+ deleteWelfare comment(String)

: Boolean

+ updateWelfareComment(String,

WelfareComment) :
Welfare

+ toString() : String

WelfareManager

-

welfareList: List<Welfare>

+
WelfarManager ()

+ addWelfare (Welfare) : Boolean

+ getWelfare(String) : Welfare

+ deleteWelfare (String) : Boolean

+ u
pdateWelfare(String,

Welfare) : Welfare

WelfareComment

-

welfare_comment
_id : String

-

date_time : Datetime

-

description : String

+
WelfareComment

()

+ WelfareComment
(String,DateTime,String)

+ mutatorMethods(newValue)

+ accessorMethods() : Type

+ toString()

: String


WelfareCommentManager

-

welfareCommentList: List<WelfareComment>

+
WelfarCommentManager ()

+ addWelfareComment(WelfareComment) : Boolean

+ getWelfareComment(String) : Welfare

+ deleteWelfare comment(String) : Boolean

+ updateWelfareComment(Stri
ng,

WelfareComment) : Welfare

1

*

1

*

1

*

1

*

contains

1

*

1

*

SystemUserManager

-

systemUserList: List<Student>

+
SystemUserManager()

+ addSystmeUser(SystemUser) : Boolean

+ getSystemUser(String) :
SystemUser

+ getSystemUser(String,String) : SystemUser

+ deleteSystemUser(String) : Boolean

+ updateSystemUser(String,SystemUser) :
Boolean

SystemUser

-

User_id : String

-

Password : String

-

name : String

-

Type : String

-

email : String

-

roleManager :
RoleManager

+
SystemUser
()

+ SystemUser(String,String,String,String)

+ mutatorMethods(newValue)

+ accessorMethods() : Type

+ toString() : String


1

*

RoleManager

-

roleList: List<Role>

+
RoleManager()

+ addRole(Role) : Boolean

+ getRole(String) :
Role

+ deleteRole(String) : Boolean

+ updateRole(String,Role) : Boolean

contains

1

*

Role

-

role_id: String

-

role_name: String

+Role()

+Role (Integer,String)

+ mutatorMethods(newValue)

+ accessorMethods() : Type

+ toString() : String



SystemFacade

-

studentManager : StudentManager

-

systemUserManager : SystemUserManager

+
SystemFacade
()

+ addStudent(Student) : Boolean

+ getStudent(String) : Student

+ deleteStudent(String) : Boolean

+ updateStudent(String,Student) : Boolean

+ addSystmeUser(S
ystemUser) : Boolean

+ getSystemUser(String) : SystemUser

+ getSystemUser(String,String)

+ deleteSystemUser(String) : Boolean

+ updateSystemUser(String,SystemUser) : Boolean

+ addIncident(Student,Incident) : Boolean

+ getAllIncidents(Student) : List<Incid
ent>

+ removeIncident(Student ,String) : Boolean

+ getIncident(Student ,Incident) : Incident

+ updateIncident(Student String,Incident) : Boolean



uses

uses

DBFunctions

-

dblocation : String

-

dbuser : String

-

dbpassword : String

-

syststemFacade

: SystemFacade

+ DBFunctions(String,String,String)

+
connect()

+ disconnect()

+ executeUpdate(Query)

+ executeDelete(Query)

+ executeGet() : List<Variant>

uses

Software Design Document

Student
Information System

35

6.2 Sequence diagrams

6.2.1 Login to the system






Software Design Document

Student
Information System

36

6.2.2 Create new user





Software Design Document

Student
Information System

37

6.2.3 Assign roles/privileges to a
user





Software Design Document

Student
Information System

38

6.2.4 Record a new student





Software Design Document

Student