S OFTWARE
DESIGN DOCUMENT
Student Academic Plan System V1.0
Team Netinfotech
Name
Role
Phone
E-mail
Mohammad
Nuruzzaman
Project
Manager
61405062921
Felix2020@live.com
Karan Jalan
Risk/QA
Manager
61452233047
JalanKaran@gmail.com
Paola
Morales
Technical
Head
61431193001
paomorales@hotmail.com
Manish
Design
Architect
61432073811
manishbajracharya@live.com.au
Dinesh
Head
Programmer
61451450778
dinesh88@gmail.com
Mohammad Nuruzzaman
5/18/2013
5/18/2013
Contents
Version History: ............................................................................................................................. 3
1. Introduction ................................................................................................................................ 4
1.1 Project Name:........................................................................................................................ 4
1.2 Project Summary .................................................................................................................. 4
1.2.1 Purpose ........................................................................................................................... 4
1.2.2 Scope ............................................................................................................................... 4
1.2.3 Objectives ....................................................................................................................... 4
1.2.4 Assumptions and Constraints ....................................................................................... 5
1.2.5 Deliverables .................................................................................................................... 5
1.2.6 Length of Commitment ................................................................................................. 7
1.3 Client Information ................................................................................................................ 7
1.4 Project manager and team details ....................................................................................... 8
1.5 Acceptance Criteria .............................................................................................................. 8
1.6 Success factors ...................................................................................................................... 8
1.7 System Context diagram ...................................................................................................... 9
1.8 Acronyms Used ................................................................................................................... 10
2. Development methodology and technologies .......................................................................... 11
2.1 Development Methodology: Waterfall ............................................................................... 11
2.2 Development Environment/languages .............................................................................. 12
2.3 Design Tools ........................................................................................................................ 12
2.3 Decision Log ........................................................................................................................ 13
3. storyboards/ GUI design .......................................................................................................... 14
3.1 Storyboard-Login Screen.................................................................................................... 14
3.2 Storyboard-Search Screen:................................................................................................. 14
3.3 Database requirements ............................................................................................................. 16
4. Entity Relationship (ER) Diagram ......................................................................................... 17
4.1 ER Diagram 1 ..................................................................................................................... 17
4.2 ER Diagram 2 ..................................................................................................................... 17
4.3 ER Diagram 3 ..................................................................................................................... 18
5. Data Dictionary ........................................................................................................................ 19
1
5/18/2013
6. Sequence Diagram ................................................................................................................... 20
6.1 Sequence Diagram-Login to the Screen ............................................................................ 20
6.2 Sequence Diagram-Add a Student .................................................................................... 20
7. System Architecture and Interfaces ....................................................................................... 21
7.1 Interface identification and diagrams ............................................................................... 21
7.2 Limitations/Constraints ..................................................................................................... 21
7.3 Architecture qualities ......................................................................................................... 21
7.4 Operating Environment ..................................................................................................... 21
7.5 Development Technology ................................................................................................... 22
7.5.1. Server Operating System ........................................................................................... 22
7.5.2 Software ........................................................................................................................ 22
7.6 Software Quality ................................................................................................................. 22
7.6.1 External software quality ............................................................................................ 22
7.6.2 Internal software quality ............................................................................................ 22
7.7 Non functional Requirements ............................................................................................ 23
8. System Decomposition ............................................................................................................. 25
9. References ................................................................................................................................. 27
10. Appendices .............................................................................................................................. 28
2
5/18/2013
VERSION HISTORY:
Date
Person
Version
Description
23/04/2013
Karan Jalan
1.1
Create SDD template
24/04/2013
Manish/Dinesh
1.2
Scope, Objectives,
context diagram,
Architectural design
24/04/2013
Mohd Nuruzzaman
1.3
Compile all member’s
Part and Update SDD
27/04/2013
Mohd/Paola/Karan
1.4
Sequence diagram and
ER Diagram, Data flow
diagram and data
dictionary
01/05/2013
Mohd/Karan / Paola /
Manish/Dinesh
1.5
Update summary and
Finalized Document
3
5/18/2013
Introduction and general (scope, member details, objectives, traceability to requirements, context diagram, tell the
big picture of how the system will interact with other systems. Is useful for future maintainers of system(10 marks)
1. INTRODUCTION
1.1 Project Name:
Student Academic Plan System (SAPS)
1.2 Project Summary
1.2.1 Purpose
The purpose of this project is to create an administration database system for IIBIT
Adelaide. The database will include student information, course and semester details. It will
facilitate IIBIT course coordinators to select courses for new and continuing students. IIBIT
currently uses Microsoft Excel to store student and course information and would like to
transfer this information to a new and interactive database. The budget for this project is
$10,000 and it has to be completed within 3 months.
1.2.2 Scope
The manual system that is being used to choose courses for students needs to be updated to
an interactive database system that will facilitate IIBIT course coordinators to choose
courses for students. IIBIT course coordinators will need to login into the system. The system
will include all new and continuing student information and all courses offered in the
institution. The system will display all core and elective courses a student need to complete
the program. Based on the courses offered in a particular semester, the system will display
suggested courses for a student upon entering a Student ID. The system will also display the
list of students enrolled in a particular course for the current semester upon entering a
course ID. The main requirement of the client is that the product be time-efficient, so that
the client doesn’t have to have more than the minimum interactions with the interface in
order to produce desired results. IIBIT will perform all system maintenance once handed
over. The client will provide the training for users. The client will setup the network and
perform maintenance on it. The client will also be responsible for hardware maintenance.
1.2.3 Objectives
The objective of this project is to create an online, browser-based system to store students
and course information. This is to be a database system that will run in World Wide Web.
The new system must be easy to use to allow for a simple changeover from the current
system in use. The system must also easy to maintain as maintenance will not be provided
by the Netinfotech project team.
4
5/18/2013
1.2.4 Assumptions and Constraints
The following assumptions and constraints will be affecting the progress of the project:
1. It is to be assumed that client will be the only user of the system being developed.
2. The system will be available on the World Wide Web.
3. Academic plan is currently maintained manually using Microsoft Excel and it would
be ideal if the information could be electronically transferred to a new system.
4. Simple login functionality is required for security issues.
5.
There is a time constraint on the project in that it must be completed by 25/6/2013
6. The project development team is constrained to the resources available at IIBIT
Adelaide, as well as those owned by team members.
1.2.5 Deliverables
The deliverables of the project are as follows:
1. Software Project Management Plan (SPMP)
It outlines the project and people involved and detail the processes and guidelines to be
followed throughout the duration of the project.
2. Work Breakdown Structure (WBS)
A deliverable oriented grouping of the work involved in the project that defines total scope of
the project.
3. Status Reports
It describes where the project stands at a specific point in time.
4. Milestone Reports
It outlines the major milestones in the project and their status at the point in time.
5. Software Requirements Specifications (SRS)
SRS defines what is required of the system by the client. It contains both functional and nonfunctional requirements.
6. Software Architecture Design Document (SADD)
SADD is a top level design of the system.
5
5/18/2013
7. Software Design Document (SDD)
SDD contains an in-depth design of the software, including use-case, collaboration, sequence
and class diagrams.
8. Test Plan
Test Plan details the types of tests to be carried out on the system to ensure the system
meets requirements and maintains integrity.
9. Quality Assurance Plan
It is a document that outlines the procedures and processes in place to ensure that the
quality of the end product is at a desired level.
10. Risk Management Plan
It is a document that details the procedures for managing risk throughout the project.
11. Source and Object Code
It is the main deliverable of the project which allows the client to run and maintain the
required system.
12. User Manual
It details how the system runs and instructs users how to install and use the product.
Task
Approx. Due Date
Member(s) responsible
Software Project Management Plan (SPMP)
April 10, 2013
ALL
Work Breakdown Structure
April 10, 2013
Mohammad
Nuruzzaman
Status Reports
April 15, 2013
ALL
Milestone Reports
April 15, 2013
ALL
Software Requirements Specifications (SRS)
May 5, 2013
ALL
Software Architecture Design Document
(SADD)
May 20, 2013
ALL
Software Design Document (SDD)
May 27, 2013
ALL
6
5/18/2013
Test plan
April 27,
June1,2013
ALL
Quality Assurance Plan
June 03, 2013
ALL
Risk Management Plan
June 03, 2013
ALL
Source and Object code
June03, 2013
ALL
User Manual
June 03, 2013
ALL
1.2.6 Length of Commitment
Each team member will be committed to spending 150 for the duration of the project. Our
team consists of five members; so this equates to a total obligation of 750 hours over the
length of the project.
Work Package
Person Responsible
Hours needed
SPMP, WBS
ALL
50
Status Report, Milestone Report
ALL
50
SRS
ALL
100
SADD, SDD
ALL
150
Test Plan
ALL
100
QAP, RMP
ALL
150
Source code/User Manual
ALL
150
TOTAL
750
1.3 Client Information
The clients name is Siddarth, the campus manager of IIBIT Adelaide. The team’s point of
contact will be Nadil who will organize direct contact with Siddarth when needed. Mr. Nadil
will be contacted via email at nadil @iibit.edu.au.
7
5/18/2013
1.4 Project manager and team details
Role
Name
Position
Sponsor
Nadil Sundereppurama
Sponsor/Consultant
Stakeholder
IIBIT
Sponsor
Project Manager
Mohammad Nuruzzaman
Project Manager/System Analyst
Team Member 1
Karan Jalan
Risk/QA Manager
Team Member 2
Paola Morales
Technical Head
Team Member 3
Manish
Design Architect
Team Member 4
Dinesh
Programmer
1.5 Acceptance Criteria
The criterion for the software that must be met in order to be accepted by the client is as
follows:

All core functional requirements are implemented.

All non-functional requirements are satisfied.

User documentation has been provided.
1.6 Success factors
The following success factors will be analyzed before the final product delivery:

The software must be reliable, implemented functions must work properly and pass
all suitable tests.

All core functions required by the client needs to be completed.

Project must be on schedule as the deadline is final and cannot be changed.

Extra functionalities that the user may like will only be implemented if time permits.
These functionalities are not essential to the system operation.
8
5/18/2013
1.7 System Context diagram
9
5/18/2013
1.8 Acronyms Used
Terms
Definitions
SDD
System Design Document
WBS
Work breakdown Structure
ER
Entity Relational Diagram
DFD
Data Flow Diagram
Scope
All the work involved in creating this
academic plan system and the processes
used to create them.
SDLC
Software development life cycle
10
5/18/2013
Description and Justification of chosen methodology for project, including development environment/languages.
Applicability of methodology to this particular project. (10 marks)
2. DEVELOPMENT METHODOLOGY AND TECHNOLOGIES
2.1 Development Methodology: Waterfall
This project has a clear specification. Therefore traditional software development
methodology “waterfall model” will be used in the development of this system. The phases in
the waterfall model include:
Requirements: This phase has already been completed. It included consultation with clients,
requirements analysis and documentation. The requirements have been signed off by the
client before this document was written.
Design: The design phase expands the user requirements into a functional solution. This
document is part of the design phase of the project.
Implementation: The implementation phase will begin once this document is completed and
signed off. The implementation phase will include coding and testing.
Testing: The testing phase will include complete functional and non-functional testing of the
system.
Maintenance: The project team takes no responsibility of the maintenance. IIBIT will
perform all maintenance once the fully functional system is handed over.
The key activities that are also included in the WBS are:









Project initiation
Requirements Analysis
Project planning
Software Design
Development
Testing
Documentation
Implementation
Maintenance
The waterfall methodology has been chosen for the following reasons:

The project team is working together for the first time and inexperienced. The waterfall
methodology provides a regulated and sequential process for software development, and
therefore it is easy to use. A non-sequential methodology such as agile requires a lot of
discipline which is difficult to adopt for the team.
11
5/18/2013
It is a client requirement that the first half of the project is used to plan and analyse the
system. It is only possible in waterfall model. In other methodologies such as agile or
scrum, the development and analysis go side by side.
 The project related deliverables (such as SRS, SDD) are only relevant to the waterfall
development cycle.
 Deliverables are comprehensive, signed off and refined. None of the knowledge and
information gathered in first and second phase of the project will be lost in subsequent
phases.

2.2 Development Environment/languages
Justification of Development environment/languages are described in Decision log in Page
11.
2.3 Design Tools
Design methods used to represent the system are:
UML for sequence diagrams
 Context Diagram
 Entity-relationship diagram
 System Architecture diagram

The tools that have been used to create these diagrams are:
Microsoft Office 2010
 Microsoft Office Visio 2010
 Enterprise Architect

Layout and Presentation, Table of contents, revision history, referencing, appropriateness of document to this
particular project.(5 marks
Decision Log – major decisions regarding design and implementation so far, list reasons for /against. Justify
decisions made. (10 marks)
12
5/18/2013
2.3 Decision Log
Justifications of major decisions regarding design and implementation are mentioned in the
following decision log table:
Type
Development
Architecture
Decision
3 Tier web
architecture
Technology type
Open Source
Development
platform
Linux, WAMP
stack
Decision rationale
 Easy deployment
 No installation on client computer
 Plenty of open source technologies
 Options for GUI functionality
 Public accessibility
Open source platform has been chosen for the
following reasons:
 Free, tested and proven
 Good for small to moderate size systems
 Simple architecture, proven security
 Easily available technical support.




Linux offers better security than Windows
WAMP is lightweight and has a simple
architecture
Combines PHP and MYSQL into a single
web server
Error logging and monitoring
Programming
language
Database
PHP 5
Client software
requirements
Programming
methodology
Hosting solution
Standard web
browsers
Structured
Compatibility with PHP
PHP has built in features that allows easy
integration with MYSQL
Clients do not need to install any additional
software on their machines
Simple and clear specification.
Externally
hosted
It is decided that the system will be hosted
externally until IIBIT is ready to host internally.
MYSQL


Additional requirement for 7602: Justify with references to industry white papers/ journal articles- brief research
Detailed storyboards/ GUI design/ Screen and Report layouts. Define Colours, Fonts, Button layouts, menu design,
etc. (20 marks)
13
5/18/2013
3. STORYBOARDS / GUI DESIGN
3.1 Storyboard-Login Screen
3.2 Storyboard-Search Screen:
14
5/18/2013
#Head
{
Font family: Tahoma ;
Font-size: 14px;
Colour: #999999;
Font-weight: bold;
}
#Head1
{
Font-family: Tahoma;
Font-size: 13px;
Colour: #999999;
}
#Head2
{
font-family : Tahoma;
font-size: 12px;
color: #999999;
}
#Content
{
font-family : Tahoma ;
font-size: 12px;
color: #000000;
}
#ttnlink
{
font-family : Tahoma;
font-size: 12px;
color: #666666;
}
#ttnnotice
{
font-family : Tahoma ;
15
5/18/2013
font-size: 12px;
color: Red;
}
3.3 Database requirements
‘User’ table will be accessed. ‘Username’ and ‘password’ will be read.
‘Course’ table will be accessed.
 ‘Student’ table will be accessed.


Description of data and processing relevant to system as appropriate. E.g. Data dictionary, file formats, detailed
data structures,. Appropriate diagrams might include Normalised E-R Diagrams, Description of objects, Flow
Diagrams, Event diagrams, Sequence diagrams (15 marks)
16
5/18/2013
4. ENTITY RELATIONSHIP (ER) DIAGRAM
4.1 ER Diagram 1
4.2 ER Diagram 2
17
5/18/2013
4.3 ER Diagram 3
18
5/18/2013
5. DATA DICTIONARY
19
5/18/2013
6. SEQUENCE DIAGRAM
6.1 Sequence Diagram-Login to the Screen
6.2 Sequence Diagram-Add a Student
20
5/18/2013
Architectural diagram showing high level architecture (e.g. 3 tiered architecture, client server, etc.). Discuss
limitations/constraints, mention portability and other quality issues (non functional requirements) and how they are
addressed in this design. (15 marks)
7. SYSTEM ARCHITECTURE AND INTERFACES
7.1 Interface identification and diagrams
The software system will be developed as a web application using PHP and MYSQL. The
application will need to interact with a web based server with a standard web browser acting
as the client.
The client will be a standard browser. The web application will run on a server with
a load balancer. The web server will connect to the SAPS database. Therefore, there are
mainly two interfaces:
Client to the web server
 Web server to the SAPS database.

7.2 Limitations/Constraints
Admin and course coordinators must have access to the internet to be able to access the
system
 IIBIT must be willing to buy dedicated in-house servers or outsourcing the hosting to an
external service provider.
 There will be need to establish in-house hosting since privacy laws prohibits storing
student and course data on outside hosting.
 Client will need to hire at least one person for the maintenance and support of the system.

7.3 Architecture qualities
Portability: The system will be highly portable because of the chosen architecture. The
system can be deployed on most server systems including Windows, Linux and UNIX that
can run the lamp stack. There will not be any need to make any changes to the system
except minor configuration changes.
 Features: Client can use the system from anywhere using a web browser.
 Security: The security of the system will be centralized on the server since server software
provides much better level of security than desktop based applications.
 Code management: The code will be managed centrally on a production server to ensure
proper maintainability of the system.

7.4 Operating Environment
The system should run any computer with a Windows XP or above Windows based operating
system.
21
5/18/2013
7.5 Development Technology
7.5.1. Server Operating System

Linux based server
7.5.2 Software
Technology Type
Development Platform
Programming Language
Database
Server Application
Client Software Requirements
Preferred Technology
Linux, WAMP Stack
PHP 5
MYSQL
Server Application
Standard Web Browser
7.6 Software Quality
7.6.1 External software quality





The system should be easy to use.
The system should include a “Help menu”.
The website theme should be consistent and match the IIBIT theme of colors and
design.
The student and course data should be encrypted.
The system should be available 24X7 except maintenance that should be carried out
in non-business hours.
7.6.2 Internal software quality
The internal software quality will ensure the following attributes:
1. Usability
i. The user should be able to perform all tasks and 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 message for any invalid
action.
2. Portability
i.
The system will be portable to a Windows based server platform
without any code changes. All of the configuration will be stored
in the general configuration file.
22
5/18/2013
ii.
The system will be portable to a different technology stack such
as Apache server platform without any code changes.
3. Architecture quality
i.
Hosting in Australia
ii.
SSL encryption for the login page.
iii.
Dedicated hosting to ensure safety and reliability
4. Code Quality
i.
Code is readable and maintainable and easy to expand.
5. System security
i.
The system will be hosted inside a secure HTTPS environment.
ii.
The system will protect against SQL injection attacks
6. User security
i.
ii.
The users should have access to the system only to perform their
task and functions.
All changes to database records should be audited.
7.7 Non functional Requirements
The following non-functional requirements will be applied to the development of the Student
Academic Plan System:
Operational Requirements
The system must have high level of usability
The system must be operational for at least 5 years.
 The system should be easy to maintain
 The system should be running 24X7


Security Requirements
In-house hosting will be implemented to store student and course data.
 Admin and coordinators will have different level of access.

23
5/18/2013

System will be locked after 3 unsuccessful login attempts.
Performance requirements
The system should be able to hold data for 500 students at any given time.
The system should store historical student data from past students.
 All functions should work in 2 seconds or less.


The system will be robust so that future upgrades and maintenance can be done without the
need for restructuring the system.
Decomposition of system into sub-parts. Structure charts and module decomposition, or class diagrams, detailed
storyboards for multimedia. (15 marks
24
5/18/2013
8. SYSTEM DECOMPOSITION
The system will be decomposed into the following layers:
Presentation layer
Business logic layer
 Database layer


User Interface
User Management
Presentation Layer
Data Management
Business Logic Layer
Reporting
User Data
Student data
Course Data
Database Layer
25
5/18/2013
The following table provides the description of each layer:
Layer name
Presentation
layer
Business Logic
layer
Database layer
Component
User interface
User
management
Data
management
Reports
management
User data
Student data
Course data
Notes
The user interface will be developed using HTML and
CSS.
Pages will be structured into the following file
structure:
Public.html
Images- all images stored here
CSS- all CSS stored here
Admin-all admin PHP pages stored here
Coordinators-all coordinators PHP pages stored here.
Config-all config items stored here.
Reports-the generated reports stored here.
This module allows for adding/deleting/updating users.
This module allows for management of data.
 Student data create, update, delete
 Course data create, update, delete
This module handles generation of reports.
All data will be stored in a single production database.
The user data table will be responsible for storing user
and related access information.
The student data will store all student information.
The course data will store all course and semester
information.
26
5/18/2013
9. REFERENCES
1) Heldman, K. (2006). Project Management Professional Study Guide. Hoboken: John Wiley &
Sons, Inc.
2) International journal of project management(2006). Retrieved 24th March 2013,
http://www.sciencedirect.com/science/article/pii/S0263786306001438
3) Kerzner, H. (2010). Organizing and staffing the project office and team. Project Management:
A Systems Approach to Planning, Scheduling, and Controlling (pp. 141-144), Wiley.
4) Milestone report (2007).Retrieved 2nd April 2013, from
5)
http://www.dairyaustralia.com.au/Industry-overview/Research-and-development/ResearchFunding/Reporting-Requirements/Milestone-Reports.aspx
6) Project Risk management (2012). Retrieved 4th April 2013, from
7) http://www.projectperfect.com.au/info_risk_mgmt.php
8) Project scope management (2010).Retrieved 6th April 2013, from
9) http://www.fastprojectplans.com/scope-management-plan-template.html
10) Larson, E. & Gray, C. (2011) Project Management: The Managerial Process (5th Ed) Chapter
2, 3.
11) Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. p.110.
12) Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill
Professional, 2003. p.354.
13) PMI (2010). A Guide to the Project Management Body of Knowledge p.27-35
14) Dennis Lock (2007) Project Management (9th ed.) Gower Publishing, Ltd., 2007.
15) Harold Kerzner (2003). Project Management: A Systems Approach to Planning, Scheduling,
and Controlling (8th Ed. ed.). Wiley.
16) James P. Lewis (2000). The project manager's desk reference: a comprehensive guide to
project planning, scheduling, evaluation, and systems. p.185
17) Jorg Becker, Martin Kugeler, Michael Rosemann (2003). Process management: a guide for
the design of business processes. p.27.
18) Body of Knowledge 5th edition, Association for Project Management, 2006.
19) Albert Hamilton (2004). Handbook of Project Management Procedures. TTL Publishing, Ltd.
20) Technical White papers: Practical Project Management: Tips, Tools and Techniques.
Retrieved April 09, 2013 from
http://www.techrepublic.com/whitepapers/it+management/project+management
27
5/18/2013
10. APPENDICES
28