Final document of software project

PROJECT PLAN
FOR “FOOTSTEP”
11/29/2014 Software Project Management

Report on
Software Project Management
FootStep
SE 803
Software Project Management
Prepared By:
Nadia Nahar – BSSE 0327
Tasnova Chowdhury – BSSE 0334
Sadid Khan – BSSE 0328
Md. Samsuddoha – BSSE 0309
Anirudhya Robi – BSSE 0333
Submitted To:
Ajmal Huda
Submission Date:
29th November, 2014
i

Letter of Transmittal
ii
November 29, 2014
Ajmal Huda
Course Teacher
Institute of Information Technology
University of Dhaka
Subject: Letter of Transmittal
Dear Sir,
We are pleased to submit the Software Project Management Report on FootStep that
you had asked. We tried to find the scope of this Project and its prospect from a
pragmatic point of view. We have faced many obstacles in preparing the diagrams.
But at the end, we have successfully accomplished preparing this document.
Therefore, we request you to accept this report. We believe that you’ll find it in order.
We are eagerly expecting your feedback on the overall report.
Yours sincerely,
Nadia Nahar BSSE-0327
………………………………………..
Tasnova Chowdhury BSSE-0334
………………………………………..
Sadid Khan BSSE-0328
………………………………………..
Md. Samsuddoha BSSE-0309
………………………………………
Anirudhya Robi BSSE-0333
………………………………………..

iii
Abstract
Implementing a service that would track an object on transportation is a feasible
notion considering the context of our country. The growing field of courier services
has been selected as our prime objective to be accustomed with the service we intend
to provide as this type of facility has not yet been facilitated by other leading
shipment and logistics companies in Bangladesh. The service is targeted to be an
assistive part of the courier services providers to notify both the service provider as
well as customer about the time of departure, current location and estimated arrival
time of the transported object on demand. From business perspective this service will
add an extra mileage to the courier industry in Bangladesh as this is still to be unfold
in this industry having a very big as well as growing demand to ensure the potentiality
along with steady growth of this service.

Acknowledgement
By the Grace of ALMIGHTY ALLAH we have completed our Report on Software
Project Management. We are grateful to the project supervisor Ajmal Huda Sir for his
supervision throughout the working time. He helped us a lot by sharing his valuable
knowledge with us.
iv

Table of Contents
Abstract ........................................................................................................................ iii
Acknowledgement ........................................................................................................ iv
1 Overview ..................................................................................................................... 1
2 Goals and Scope .......................................................................................................... 2
2.1 Project Goals ........................................................................................................ 2
2.2 Project Scope ....................................................................................................... 4
2.2.1 Included......................................................................................................... 4
2.2.2 Excluded ....................................................................................................... 4
3 Organization ................................................................................................................ 4
3.1 Organizational Boundaries and Interfaces ........................................................... 4
3.1.1 Resource Owners .......................................................................................... 5
3.1.2 Receivers ....................................................................................................... 5
3.1.3 Sub-contractors and Suppliers ...................................................................... 5
3.2 Project Organization ............................................................................................ 5
3.2.1 Project Manager ............................................................................................ 6
3.2.2 Project-internal Functions ............................................................................. 6
3.2.3 Project Team ................................................................................................. 7
3.2.4 Steering Committee ...................................................................................... 7
4 Schedule and Budget................................................................................................... 7
4.1 Work Breakdown Structure ................................................................................. 7
4.2 Schedule and Milestones...................................................................................... 8
4.3 Budget ................................................................................................................ 10
4.4 Development Process ......................................................................................... 10
4.5 Development Environment ................................................................................ 11
5 Domain Analysis ....................................................................................................... 12
v

5.1 General knowledge about the domain................................................................ 12
5.2 Customers and users .......................................................................................... 13
5.3 Tasks and procedures currently performed ........................................................ 13
5.4 Competing system .............................................................................................. 13
5.5 Similarities across domains and organizations .................................................. 14
6 Software Requirements Specification ....................................................................... 14
6.1 Requirements Analysis of “FootStep” ............................................................... 14
6.1.1 Inception ..................................................................................................... 14
6.1.2 Elicitation .................................................................................................... 18
6.2 Analysis Model of Our Project .......................................................................... 21
6.2.1 Scenario Based Model ................................................................................ 21
6.2.2 Data Model.................................................................................................. 65
6.2.3 Class-based Model ...................................................................................... 68
6.2.4 Flow-Oriented Model.................................................................................. 71
6.2.5 Behavioral Model........................................................................................ 74
6.3 Requirement Change Management of Our System ........................................... 79
6.3.1 Bugs and Glitches ....................................................................................... 80
6.3.2 Patches ........................................................................................................ 80
7 Software Design ........................................................................................................ 80
7.1 Architectural Design .......................................................................................... 80
7.1.1 Represent the System in Context ................................................................ 81
7.1.2 Refine the Architecture into Components................................................... 82
7.1.3 Describe Instantiations of the System ......................................................... 83
7.1.4 Mapping Requirements into a Software Architecture ................................ 84
7.2 Component Level Design: ................................................................................. 85
8 Risk Management ..................................................................................................... 95
vi

8.1 Context ............................................................................................................... 96
8.2 Identifying Risks ................................................................................................ 96
Identification Methods ......................................................................................... 97
Risk Register ........................................................................................................ 99
Risk Data Sheets .................................................................................................. 99
8.3 Analyzing Risks ............................................................................................... 101
Likelihood Rating Scale ..................................................................................... 101
Consequence Rating Scale ................................................................................. 101
Risk Rating Scale ............................................................................................... 102
8.4 Evaluating Risks .............................................................................................. 102
8.5 Treating Risks .................................................................................................. 102
8.6 Monitoring and Review ................................................................................... 102
9 Communication and Reporting ............................................................................... 103
10 Delivery Plan ........................................................................................................ 104
10.1 Deliverables and Receivers ............................................................................ 104
11 Quality Assurance ................................................................................................. 104
11.1 Test Plan......................................................................................................... 104
11.1.1 Test Plan Identifier .................................................................................. 104
11.1.2 References ............................................................................................... 104
11.1.3 Introduction ............................................................................................. 105
11.1.4 Test Items ................................................................................................ 105
11.1.5 Software Risk Issues ............................................................................... 106
11.1.6 Features to be Tested .............................................................................. 107
11.1.7 Features not to be Tested ........................................................................ 107
11.1.8 Approach ................................................................................................. 107
11.1.9 Item Pass/Fail Criteria............................................................................. 113
vii

11.1.10 Suspension Criteria and Resumption Requirements ............................. 114
11.1.11 Test Deliverables .................................................................................. 114
11.1.12 Remaining Test Tasks ........................................................................... 114
11.1.13 Environmental Needs ............................................................................ 115
11.1.14 Responsibilities ..................................................................................... 115
11.1.15 Schedule ................................................................................................ 115
11.1.16 Planning Risks and Contingencies ........................................................ 115
11.1 Test Cases ...................................................................................................... 116
Abbreviations and Definitions ................................................................................... 122
Revision ..................................................................................................................... 122
List of Tables
Table 1: Project Goals .................................................................................................... 2
Table 2: Resource Owners ............................................................................................. 5
Table 3: Project Manager ............................................................................................... 6
Table 4: Project-internal Functions ................................................................................ 6
Table 5: Project Team .................................................................................................... 7
Table 6: Steering Committee ......................................................................................... 7
Table 7: Schedule and Milestones ................................................................................. 9
Table 8: Budget ............................................................................................................ 10
Table 9: Development Environment ............................................................................ 11
Table 10: Use Cases ..................................................................................................... 22
Table 11: Data Types ................................................................................................... 91
Table 12: Identifying Risks .......................................................................................... 97
Table 13: Risk Data Sheet Template ......................................................................... 100
Table 14: Likelihood Rating ...................................................................................... 101
Table 15: Consequence Rating Scale ......................................................................... 101
Table 16: Risk Rating Scale ....................................................................................... 102
Table 17: Communication and Reporting .................................................................. 103
Table 18: Deliverables and Receiver ......................................................................... 104
viii

Table 19: Responsibilities .......................................................................................... 115
Table 20: Abbreviations and Definitions ................................................................... 122
Table 21: Revision ..................................................................................................... 122
List of Figures
Figure 1: Major Work Breakdown ................................................................................. 8
Figure 2: Work Breakdown ........................................................................................... 8
Figure 3: Use Case (Level-0) ....................................................................................... 31
Figure 4: Use Case (Level-1) ....................................................................................... 32
Figure 5: Use Case (Level-2.1) .................................................................................... 33
Figure 9: Activity Diagram (Log In) ........................................................................... 35
Figure 10: Activity Diagram (Log Out) ....................................................................... 36
Figure 11: Activity Diagram (Change Password) ........................................................ 37
Figure 12: Activity Diagram (Add User) ..................................................................... 38
Figure 13: Activity Diagram (Add Parcel) .................................................................. 39
Figure 14: Activity Diagram (Add Station) ................................................................. 40
Figure 15: Activity Diagram (Add Vehicle) ................................................................ 41
Figure 16: Activity Diagram (Edit User) ..................................................................... 42
Figure 17: Activity Diagram (Edit Station) ................................................................. 43
Figure 18: Activity Diagram (Edit Vehicle) ................................................................ 44
Figure 19: Activity Diagram (Edit Parcel) ................................................................... 45
Figure 20: Activity Diagram (Delete User) ................................................................. 46
Figure 21: Activity Diagram (Delete Station) ............................................................. 47
Figure 22: Activity Diagram (Delete Vehicle) ............................................................ 48
Figure 23: Activity Diagram (Delete Parcel) ............................................................... 49
Figure 24: Swimlane Diagram (Log In) ....................................................................... 50
Figure 25: Swimlane Diagram (Log Out) .................................................................... 51
Figure 26: Swimlane Diagram (Change Password) ..................................................... 52
Figure 27: Swimlane Diagram (Add User) .................................................................. 53
Figure 28: Swimlane Diagram (Add Station) .............................................................. 54
ix

Figure 29: Swimlane Diagram (Add Vehicle) ............................................................. 55
Figure 30: Swimlane Diagram (Add Parcel) ............................................................... 56
Figure 31: Swimlane Diagram (Edit Parcel) ................................................................ 57
Figure 32: Swimlane Diagram (Edit User) .................................................................. 58
Figure 33: Swimlane Diagram (Edit Vehicle) ............................................................. 59
Figure 34: Swimlane Diagram (Edit Station) .............................................................. 60
Figure 35: Swimlane Diagram (Delete Station) ........................................................... 61
Figure 36: Swimlane Diagram (Delete Vehicle) ......................................................... 62
Figure 37: Swimlane Diagram (Delete Parcel) ............................................................ 63
Figure 38: Swimlane Diagram (Delete User) .............................................................. 64
Figure 39: E-R Diagram............................................................................................... 67
Figure 40: Class Card (User) ....................................................................................... 68
Figure 41: Class Card (Authentication) ....................................................................... 69
Figure 42: Class Card (Parcel) ..................................................................................... 69
Figure 43: Class Card (Vehicle) .................................................................................. 69
Figure 44: Class Card (Station).................................................................................... 70
Figure 45: Class Card (Database) ................................................................................ 70
Figure 46: CRC Model................................................................................................. 71
Figure 47: Data Flow Diagram (Context Level) .......................................................... 72
Figure 48: Data Flow Diagram (Level 1) .................................................................... 72
Figure 49: Data Flow Diagram (Level 2.1) ................................................................. 73
Figure 50: Data Flow Diagram (Level 2.2) ................................................................. 73
Figure 51: State Diagram (Authentication).................................................................. 74
Figure 52: State Diagram (User) .................................................................................. 75
Figure 53: State Diagram (Admin) .............................................................................. 75
Figure 54: State Diagram (Database) ........................................................................... 76
Figure 55: Sequence Diagram (Login) ........................................................................ 77
Figure 56: Sequence Diagram (User Activity) ............................................................ 78
Figure 57: Sequence Diagram (Create User) ............................................................... 78
Figure 58: Sequence Diagram (Add Parcel/Vehicle/Station) ...................................... 79
Figure 59: Architectural context diagram (ACD) ........................................................ 81
Figure 60: Overall architectural structure for LCS with top-level components .......... 82
Figure 61: LCS with component elaboration ............................................................... 83
x

Figure 62: First level factoring .................................................................................... 84
Figure 63: Second level factoring (2.1) ....................................................................... 84
Figure 64: Second level factoring (2.2) ....................................................................... 85
Figure 65: Problem Domain Classes............................................................................ 86
Figure 66: Class elaboration for User .......................................................................... 87
Figure 67: Class Elaboration for Admin ...................................................................... 88
Figure 68: Class Elaboration for Parcel ....................................................................... 89
Figure 69: Collaboration details for create user and others item ........................... 90
Figure 70: Collaboration details for user management ........................................... 90
Figure 71: Collaboration details for user, parcel and vehicle management ................. 91
Figure 72: Dataflow for authentication ........................................................................ 92
Figure 73: Data Store ................................................................................................... 94
Figure 74: Required Class ............................................................................................ 94
Figure 75: Deployment Model ..................................................................................... 95
Figure 76: AS/NZS 4360:1999 Risk management process ......................................... 96
xi

1 Overview
In the age of information merely delivering package within a particular time is not just
good enough for consumers where real time information about the package can be
provided through tracking and monitoring system.
Courier services bear major productive value in both business and personal purposes.
A number of courier services are available across the globe offering tracking and
monitoring system for consumers although it is not provided in Bangladesh. The
intended project is to deliver such a system, through which courier companies can
manage their parcels and consumers can be offered the status of their package from
time to time as well. Few courier services provide this functionality already within
other facilities but it is not provided in this country and there is little probability that it
would be included in near future.
Both the consumers and the courier service providers could be the clients of this
project but it is not yet completely certain. Different corporations can become our
clients on a monthly or yearly basis or they can acquire the entire project too.
The approximate cost of this project would stand 795,000 BDT with 6 months for
feasibility study, requirement engineering, project design, function development, and
quality assurance.
The project involves five members of BSSE 3rd batch from IIT, University of Dhaka.
This project is mutually exclusive with any other project as it is a part of completion
for Software Project Management course of BSSE 8th semester.
1 | P a g e

2 Goals and Scope
FootStep is an online parcel management system where customer can get notification
of his parcel by the system and company can manage their parcel using this system.
This section describes the project scope, and project goals including functional goals,
technical goals, business goals, etc.
2.1 Project Goals
The project goals are divided into five categories and prioritize them on High,
Medium, and Low which are presented by 1, 2, and 3 respectively.
2 | P a g e
Table 1: Project Goals
Project Goal Priority Comment/Description/Reference
Functional Goals: 1 All specific functions or modules of
FootStep
Feasibility study of FootStep
Domain analysis FootStep
Requirements gathering
Requirement elicitation and
prioritizing
Preparing SRS
FootStep project design
Coding of FootStep
Testing of FootStep
Configuration Management
Release and change management
Business Goals:
3 List of business related issues
Cost estimation
Delivery plan
Budget management

Time schedule set
Technological Goals: 2 All technical modules for FootStep
Database design
Customer and Admin(company)
user creation
Main admin creation
Map creation
User profile creation
Create the module for create user,
parcel and vehicle
Notification system (by email)
Quality Goals: 2 Test all module and confirm the
3 | P a g e
quality assurance
User creation correctly
Parcel and vehicle creation
correctly
mail send for notification
remove browser dependency
easy to use and confidential
documents security
Constraints: 3 Other modules and services to
develop
Collect specific requirements from
stakeholders
developing environment setup
application specific standers
follow all SDLC process to
develop FootStep
Time and resources

2.2 Project Scope
The scope FootStep are described on this section including which are currently ready
to deliver and which are still ongoing process.
2.2.1 Included
The deliverables of FootStep are given bellow:
 Manage user profile
 Manage parcel management module
 Manage vehicle management system
 Manage the google map with parcel position
 Email notification system
 Documentation
2.2.2 Excluded
The features are covered currently, described below:
 fully modularized database
 plagiarism detection
 documents markup by private user
 excluded project version controller
 excluded comments section on a specific document
3 Organization
This section describes the internal project organization and all organizational issues
affected by this project result or the project is dependent on. “FootStep” is a business
project and will be used for business purpose.
3.1 Organizational Boundaries and Interfaces
The environment of “FootStep” system is described in this section. The description of
external stakeholders the project and internal stakeholders are attached here.
4 | P a g e

3.1.1 Resource Owners
A team of BSSE third batch is the owner of this project. Name and description of
those members are:
5 | P a g e
Table 2: Resource Owners
Name ID
Nadia Nahar BSSE 0327
Tasnova Chowdhury BSSE 0334
Sadid Khan BSSE 0328
Md. Samsuddoha BSSE 0309
Anirudhya Robi BSSE 0333
3.1.2 Receivers
The receivers are not currently defined. This project is the property of the resource
owners only. Later on, different companies can be monthly/ yearly clients or buy the
project. Those companies will be the receivers.
3.1.3 Sub-contractors and Suppliers
No external sub-contractors and external organization contributing are involved in this
project. This project is developed by only the 5 members of BSSE third batch which
is mention early sub-section.
3.2 Project Organization
This part describes how the project is organized. Describe what subprojects and other
areas of responsibility are planned. Identify and staff all steering functions, project
management functions, and execution functions.

3.2.1 Project Manager
6 | P a g e
Table 3: Project Manager
Role Organization: Name
Project Manager Nadia Nahar
Technical Project Mgr. Nadia Nahar
3.2.2 Project-internal Functions
Table 4: Project-internal Functions
Function Responsible person name Comments
Requirement engineering Nadia Nahar, Md. Samsuddoha Collect requirements from
stakeholders and analyse them
Project Design Team Tasnova Chowdhury, Md.
Samsuddoha
Design the project based on
requirements specification
Development Team Nadia Nahar, Sadid Khan Develop whole function of IIT
Repository
Quality Assurance Anirudhya Robi Test this project and confirm
the quality assurance
Validation Lead Nadia Nahar, Anirudhya Robi Validate the project
Configuration Management Nadia Nahar, Sadid Khan Manage the all configuration
of this project
Change Management Tasnova Chowdhury, Md.
Samsuddoha
Manage the changes if need or
request from user to change
any module

3.2.3 Project Team
7 | P a g e
Table 5: Project Team
Name Position
Nadia Nahar Project Manager
Tasnova Chowdhury System Analyst
Sadid Khan Developer
Md. Samsuddoha Developer
Anirudhya Robi Quality Assurance Engineer
3.2.4 Steering Committee
Table 6: Steering Committee
Organization Name Comment
Class Teacher Ajmal Huda Manage the whole
project from to bottom
and verify every step
4 Schedule and Budget
This section described the project timeline, its working approach selected process for
development etc. An approximate budget is also proposed in this chapter section.
4.1 Work Breakdown Structure
Work breakdown is the decomposition is the whole project in several parts. To
achieve the full project FootStep is divided into several millstones. The project is
mainly divided into three phase.
1. Project Study
2. Design
3. Project Development

Project Study Design
Domain
Analysis
Domain
Report
8 | P a g e
Figure 1: Major Work Breakdown
Project
Development
First phase is related with project scope, domain analysis, and requirements for this
project. Second phase is related with design, functions and data working flow,
database design etc. Finally development phase is concern with development with
different modules. These three parts are divided further into several small parts.
FootStep
Design
Preliminay
Design
Design
Report
Database
Design
Design
Report
Figure 2: Work Breakdown
Project Study
Requirement
Analysis
SRS Report
4.2 Schedule and Milestones
Project
Development
Web
Applicaton
Android App
Achieving the above the full work the project is divided into several milestones. Each
milestone has its specific outcome and date of finish. For managing time properly
there is a buffered time between each milestone. A bird’s eye view of this project
milestone is given in the table below:

9 | P a g e
Table 7: Schedule and Milestones
Milestones Description Milestone Criteria Planned Date
M0 Start Project 01/07/2014
Define Project
Goals and Scope
Project define and
Budget Release
5/07/2014
M1 Start Planning 13/07/2014
Project Domain and
Risk
Scope and concept
described
20/08/2014
M2 Start Execution 22/08/2014
Requirement
gathering and
System design.
Requirement and
Design document
10/09/2014
M3 Confirm Execution 15/09/2014
Development
process selection,
Team form and
handover it to
Development team
Architecture
reviewed and stable
20/10/2014
M4 Start Introduction 01/11/2014
Development and
Coding
Coding of new
functionality
finished,
Draft documentation
25/11/2014
M5 Release Product 01/12/2014
Project complete Product system
tested,
documentation
reviewed
10/12/2014
M6 Close Project 13/12/2014
Handover 14/12/2014

4.3 Budget
This subsection proposed an approximate budget for FootStep. Budget is proposed for
each milestone by considering different aspects. Final amount is the total budget for
this project. The budget is shown in the table below:
10 | P a g e
Table 8: Budget
Category Budget for Period in TK.
M0-M1 M1-M2 M2-M3 M3-M4 M4-M5 M5-M6
Human Resources 50,000 1,00,000 30,000 2,00,000 80,000 50,000
Purchases - - - 70,000 30,000 -
Equipment - - - 10,000 - -
Premises 20,000 20,000 40,000 80,000 20,000 10,000
Tools - - 5,000 20,000 8,000 -
Travel costs 3,000 - 5,000 - - 2,000
Training - - - 10,000 - -
Review activities - 2,000 5,000 - - -
Other 1,000 2,000 2,000 5, ,000 2,000 3,000
Total 74,000 1,24,000 87,000 3,95,000 140,000 65,000
Total cumulated 74,000 1,98,000 2,85,000 5,90,000 7,30,000 7,95,000
4.4 Development Process
FootStep is a well defied project and both requirement providers and developers are
technical person, so for developing this project iterative waterfall method is
considered. In this approach phase are linked to one another one end of one phase
leads to start another. There is also an opportunity to quick adapt little change because
of small team.

4.5 Development Environment
This subsection describes the necessary methods tools and technology used in this
project. The following table shows the environment used in this project in different
milestones and its purpose.
11 | P a g e
Table 9: Development Environment
Item Applied for Availability by
Methods
Use Case Requirements capturing M0
Dataflow Data behavior capturing M2
E-R Diagram Database design M2
Class Cards Card design M2
Tools
Microsoft Project Management M0-M6
Microsoft Visio Design M4
Visual Studio 2010 Development M4
Eclipse ADT Bundle Development M4
Microsoft SQL server R2 Database M4
Bugzilla Test M5
TFS Version controller M4,M5
Languages
UML Design M3
C# Development M4
HTML Design M4
AngularJS Development M4
Android Development M4

5 Domain Analysis
In Bangladesh, now a days courier services are in a vital position for personal,
official, export, import and business purposes. Courier Agency means a commercial
concern engaged in the door to door transportations of time sensitive documents,
goods or articles, utilizing the services of a person either directly or indirectly.
Couriers are distinguished from ordinary mail services by features such as speed,
security, tracking, signature, specialization and individualization of services, and
committed delivery times. Tracking is one of the important features in courier
business. But in Bangladesh, this feature is completely unavailable in national courier
companies as well as international companies.
Our tracking system provides insight about customer shipment's status all along its
journey. They will feel confident and have peace of mind knowing that they have the
most up-to-date information when they use our enhanced tracking options.
5.1 General knowledge about the domain
Generally a tracking system is used for the observing of persons or objects on the
move and supplying a timely ordered sequence of respective location data to a model
e.g. capable to serve for depicting the motion on a display capability. There are a
myriad of tracking systems. Some are 'lag time' indicators, that is, the data is collected
after an item has passed a point for example a bar code or choke point or gate. Others
are 'real-time' or 'near real-time' like Global Positioning Systems depending on how
often the data is refreshed. There are bar-code systems which require a person to scan
items and automatic identification (RFID auto-id). For the most part, the tracking
worlds are composed of discrete hardware and software systems for different
applications. That is, bar-code systems are separate from Electronic Product Code
(EPC) systems, GPS systems are separate from active real time locating systems or
RTLS for example, a passive RFID system would be used in a warehouse to scan the
boxes as they are loaded on a truck - then the truck itself is tracked on a different
system using GPS with its own features and software.
12 | P a g e

5.2 Customers and users
Tracking service is popular in worldwide courier business. This service gives
customer the real information. It provides convenient ways to stay informed of current
status, unexpected delays, and ultimately the delivery of their shipment. This creates a
positive attitude among the customers. If a customer is satisfied that means that a
product of service has met his expectations and that he was not dissatisfied by it. In
Bangladesh, customer faces the trust problem and sometimes they are dissatisfied.
They can’t get information about their shipments. If a courier service company uses
our system, they are able to give the real time monitoring. It gives more satisfaction to
their customer.
5.3 Tasks and procedures currently performed
Courier service without tracking facility is not feasible nowadays. Currently
customers have no way to know the current location of their parcel. Customers need
to query for their package to the service providing company by either calling them or
sending contact messages to their website. Phone calls are costly and contact
messages are often not checked by the company as they need full-time employees for
giving customer care service for that. So running Courier Company without tracking
service create obstacle for both customer and company owners.
5.4 Competing system
The world's largest courier companies like Aramex, DHL, FedEx, UPEX, TNT N.V.
and UPS spread their business in Bangladesh. They all have real time monitoring
system, but according to their business policy, this service is unavailable in
Bangladesh. Customer satisfaction is doubtlessly very important. It is the precondition
for repeat purchases and it prevents the customer from telling others about his
disappointing experiences. So like worldwide courier business, our national courier
companies will use this system to enhance their customer satisfaction. If local
companies adopt this, international companies will also implement their existing
service in Bangladesh.
13 | P a g e

5.5 Similarities across domains and organizations
Our tracking system could be generalized as the real time monitoring system. We
might therefore consider developing a generic framework for this aspect of the
problem which could be used in any other transportation system.
6 Software Requirements
Specification
6.1 Requirements Analysis of “FootStep”
This section includes the Inception and Elicitation phase of the SRS. It specifies the
stakeholders, their viewpoints, QFD (Quality Function Deployment) of our
application and also the User Story of it.
6.1.1 Inception
Inception is the beginning phase of requirements engineering. It defines how does a
software project get started and what is the scope and nature of the problem to be
solved. The goal of the inception phase is to identify concurrence needs and conflict
requirements among the stakeholders of a software project.
Identifying Stakeholders
We identified following stakeholders for our project:
1. Client Company (e.g. Courier Company): Companies are the major clients of
this project as they will buy it. They have some rules and regulation to maintain.
We will have to follow them strictly to make them buy the project.
2. Company Manager: The Company Manager is the administrative body to
manage the software.
3. Company Owner: The Company Owner is the person who has the final authority
over company’s budget, personal resources, and ultimately the finished product.
His position empowers him to veto a decision made by the other Stakeholders.
14 | P a g e

4. Chief Technology Officer: As head of Company IT department, the CTO has
direct authority over systems budget, and is responsible for buying the project and
managing it.
5. System Operator: System Operator will directly interact with this software.
6. Customers: The largest user group of the system. They will search for their items
(e.g. parcels in courier service) and check out their positions in map.
7. System Analyst, Developers and Testers: We selected this group as stakeholders
because they work to develop this system and also are responsible for further
maintenance. If any system interruption occurs, they will find the problem and try
to solve it.
Recognizing multiple viewpoints
1. Company’s viewpoints:
a. Financially beneficial to company
b. No disruption of rules and regulation
2. Company Manager’s viewpoints:
a. Minimum maintenance cost
b. Web-Based Interfaces
c. Maintain a database of all items in the service
d. Allow the system to be accessed via the Internet.
e. Restrict access to functionality of the system based upon user roles
f. The application can be accessed from any computer that has Internet
15 | P a g e
access
3. Company Owner’s viewpoints:
a. Increase of company revenue
b. No disruption of rules and regulation
c. Satisfied customers
4. Chief Technology Officer’s viewpoints:
a. Availability of expected requirements within the PC/mobile configuration.
b. Minimum hardware requirements
c. Minimum maintenance cost
d. Easy to update

e. Allow System Operator to check-out and check-in items for valid users
f. Allow Customers to check item positions in runtime
g. A user guide describing how to use ‘FootStep’ need to be deployed with
16 | P a g e
the system
h. A product reference manual describing how to install, setup, and run the
application shall be provided
5. System Operator’s viewpoints:
a. Allow the system to be accessed via the Internet
b. Easy access
c. Easy to operate
d. User friendly, efficient and lucrative system
6. Customers’ viewpoints:
a. Allow the system to be accessed via the Internet
b. Easy access
c. Allow valid users to see their items online by logging into the system
d. See item position in map in realtime
e. User friendly, efficient and lucrative system
7. System Analyst’s, Developers’ and Testers’ viewpoints:
a. Proper documentation of the system to be developed
b. Design whole system with efficient manner
c. Develop system within limited cost
d. Error free system (Maximum 5% error may be considerable)
Working towards collaboration
Every stakeholder has their own requirements. We followed following steps to merge
these requirements:
 Identify the common and conflicting requirements
 Categorize the requirements
 Take priority points for each requirements from stakeholders and on the basis
of this voting prioritize the requirements
 Make final decision about the requirements

Common Requirements:
 Web-Based Interfaces
 Accessible via the Internet
 User friendly efficient and lucrative system
 Allow valid users to see their items online by logging into the system
Conflicting Requirements:
We found some requirements conflicting with each other. We had to trade-off
between the requirements:
 Easy access; and strong authentication
 The application can be accessed from any computer that has Internet access;
and allow valid user to use the system
 Develop system within limited cost; and user friendly, efficient and lucrative
system
Final Requirements:
We finalized following requirements for the system by categorizing and prioritizing
the requirements:
 Web-based interfaces
 Accessible via the Internet.
 Allow valid users to login and logout.
 Restrict access to functionality of the system based upon user roles
 Maintain a database of all items in the service
 Allow administrators of the system to change user types and configure
parameters of the system
 Allow System Operator to check-out and check-in items for valid users
 Allow Customers to check item positions in runtime
 Develop system within limited cost
 Error free system (Maximum 5% error may be considerable)
17 | P a g e

Asking the First Questions
We set our first set of context-free questions focuses on the customer and other
stakeholders, overall project goals and benefits. The questions are –
 Who is paying for the project?
 Who will be using the project outcomes?
 Who gets to make the decisions about the project?
 Who has resources needed to get the project done?
 Whose work will affect the project?
These questions helped us to identify all stakeholders, measurable benefit of the
successful implementation and possible alternatives to custom software development.
6.1.2 Elicitation
Elicitation is a task that helps the customer to define what is required. To complete the
elicitation step we face many problems like problems of scope, problems of volatility
and problems of understanding. However, this is not an easy task. To help overcome
these problems, we have worked with the Eliciting requirements activity in an
organized and systematic manner.
Quality Function Deployment of “FootStep”
Quality Function Deployment is a technique that translates the needs of the customer
into technical requirements for software. It concentrates on maximizing customer
satisfaction from the software engineering process .With respect to our project the
following requirements are identified by a QFD.
o Normal Requirements
o Expected Requirements
o Exciting requirements
18 | P a g e

Normal Requirements
Normal requirements consist of objectives and goals that are stated during the meeting
with the stakeholders. Normal requirements of our project are –
1. User friendly efficient and lucrative system.
2. Minimum maintenance cost
3. Availability of expected requirements within the PC/mobile configuration
4. Easy to operate
5. Allow valid users to login and logout
6. Restrict access to functionality of the system based upon user roles
7. Help feature to explain what they are looking for
8. A product reference manual describing how to install, setup, and run the
application will be provided
Expected Requirements
These requirements are implicit to the system and may be so fundamental that the
actor/gamer/ relevant people does not explicitly state them .Their absence will be a
cause for dissatisfaction.
1. Accessible via the Internet.
2. Develop system within limited cost
3. Minimum hardware requirements
4. Design whole system with efficient manner
5. The system shall enable the Administrator to change a user’s type to any user type
6. The system shall enable the Administrator to change user passwords
7. The system shall allow the customers to log in based upon an assigned login id
and password
8. The user interface of the system shall be easy to use
19 | P a g e

Exciting requirements
These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present –
1. The user interface should provide appropriate error messages for invalid input as
well as tool-tips and online help
2. The user interface should follow standard web practices such that the web
interface is consistent with typical internet applications
3. Easy to update
4. The system’s configuration shall be documented and updated as changes to the
system are made due to patches, new releases, etc.
5. Connect user account with google, facebook or other social media
User Story of Our Application
“FootStep” is a Web Application. The main purpose of the application is to provide a
GPS tracking solution that could track anything, anywhere, anytime. The tracked item
can be identified by the users in Google map.
There will be two major types of user who will directly interact with the application.
One is the System Operator of the client company, and another is the customers of the
company. We are assuming that a courier company is taking the tracking service here.
User story of the System Operator
First of all, the System Operator will access the website of the company through
browser. He will be provided with an operator account credentials. Thus, he will go to
the Login page and sign into the system using the credentials. If a new customer
comes for sending a parcel to a destination, the operator will create a customer
account for him. The operator will go to the User Creation Tab, and fill up a form
providing the customer information. It will give him a unique customer Id and
credentials of the customer account, which will be given to the customer for accessing
his/her parcel information. After that, the operator will give an entry for the new
coming parcel and get a unique parcel Id. When it’s time for the parcel to be sent in a
truck, the operator will give an entry with the truck Id and the parcel Id. This entry
will be the tactic to identify the truck that contains a desired parcel. Every truck driver
20 | P a g e

will have a GPS device with him which will continuously identify his position and
update the web server. If the operator wants to see the position of a truck or a parcel,
he can select it. The position of the selected truck or the truck containing the selected
parcel will be shown to him in a Google map. He can see the positions in real time
and get an idea of the time of the arrival of a truck to its destination. This will help
him to take real time decision about parcel delivery.
User story of a customer
When a customer will go to our client company for the first time, he will get a
customer account credential. For the rest of his lifetime he can use these credentials to
get access to the company website. Whenever he needs to know about the position of
a parcel sent by him, he can go to the website. He will first log into the system using
his account credentials. He can change the credentials if he wants by using the
Manage Account Tab. However, if he wants to check a parcel position, he can go to
the Tracking Tab. All the parcels sent by him will be available there in a map. He can
select parcels which he wants to see and check its position anytime, from anywhere.
6.2 Analysis Model of Our Project
This section describes the Software Requirements Specification of our project by
analyzing the proper models of requirement engineering.
6.2.1 Scenario Based Model
This Model depicts how the user interacts with the system and the specific sequence
of activities that occur as the software is used.
Use Case Scenario
The following table summarizes the use cases of the system.
21 | P a g e

22 | P a g e
Table 10: Use Cases
Level – 0 Level – 1 Level – 2 Actors
FootStep
Authentication Sign In Operator, Customer
Sign Out Operator, Customer
Change Passwords Operator, Customer
User Management Add User Operator
Edit User Operator
Ban User Operator
Delete User Operator
Station Management Add Station Operator
Edit Station Operator
Delete Station Operator
Vehicle Management Add Vehicle Operator
Edit Vehicle Operator
Delete Vehicle Operator
Parcel Management Add Parcel Operator
Edit Parcel Operator
View Parcel Location - Operator
Use Case Descriptions
1. Authentication
i. Use case: Sign In
Primary Actors: Operator, Customer
Goal in context: To enter the system
Precondition: Must be registered
Triggers: Need to log in the system
Scenario:
1. Visit the login page
2. Input Username & Password
3. Proceed to the next activity

Exception:
1. Unrecognized Username
2. Wrong Password
3. User is blocked
Priority: Essential, must be implemented
When Available: First increment
ii. Use case: Sign Out
Goal in context: To exit from the system
Precondition: Must be logged in
Triggers: Need to log out from the system
Scenario:
1. Click the logout button
iii. Use case: Change Password(s)
Goal in context: To change the existing password to a new password
Precondition: System has been programmed for a password
Triggers: Need to change the existing password to a new one
Scenario:
1. Visit the login page and login
2. Go to Profile
3. Click on Edit button
4. Change Password
Exception: Weak Password: Password length is too short
23 | P a g e

2. User Management
i. Use case: Add User
Primary Actors: Operator
Goal in context: To add new user
Precondition:
1. System has been programmed for adding user in database
2. Must be logged in as Operator
Trigger: The operator has a need to add new user
Scenario:
1. Visit Login page and Log in
2. Click on Maintain User button
3. Click on Add User button to add new user
4. Enter the new user data and confirm changes
Exception: Already Exist: User is already added in the database
ii. Use case: Edit a User
Goal in context: To edit a user
Precondition:
1. System has been programmed for editing user in database
Trigger: The operator has a need to edit a user.
Scenario:
3. Search and Select the User to edit
4. Click on Edit User button
5. Edit the user details and confirm changes
24 | P a g e

Exception:
1. Does not exist: Requested user does not exist in the database
2. Ambiguous Input
Priority: Expected
When Available: Second increment
iii. Use case: Ban a User
Goal in context: To ban a user
Precondition:
1. System has been programmed for banning user in database
Trigger: The operator has a need to ban a user.
Scenario:
3. Search and Select the User to ban
4. Click on Ban User button
5. Ban the selected user and confirm changes
Exception: Does not exist: Requested user does not exist in the database
Priority: Expected
iv. Use case: Delete a User
Goal in context: To delete a user
Precondition:
1. System has been programmed for deleting user in database
Trigger: The operator has a need to delete a user.
25 | P a g e

Scenario:
3. Search and Select the User to delete
4. Click on Delete User button
5. Delete the selected user and confirm changes
Exception: Does not exist: Requested user does not exist in the database
Priority: Expected
3. Station Management
i. Use case: Add Station
Goal in context: To add new station
Precondition:
1. System has been programmed for adding station in database
Trigger: The operator has a need to add new station
Scenario:
2. Click on Maintain Station button
3. Click on Add Station button to add new station
4. Enter the new station data and confirm changes
Exception: Already Exist: Station is already added in the database
ii. Use case: Edit a Station
Goal in context: To edit a station
Precondition:
26 | P a g e

1. System has been programmed for editing station in database
Trigger: The operator has a need to edit a station.
Scenario:
3. Search and Select the Station to edit
4. Click on Edit Station button
5. Edit the station details and confirm changes
Exception:
3. Does not exist: Requested station does not exist in the database
4. Ambiguous Input
Priority: Expected
iii. Use case: Delete a Station
Goal in context: To delete a station
Precondition:
1. System has been programmed for deleting station in database
Trigger: The operator has a need to delete a station.
Scenario:
3. Search and Select the Station to delete
4. Click on Delete Station button
5. Delete the selected station and confirm changes
Exception: Does not exist: Requested station does not exist in the database
Priority: Expected
27 | P a g e

4. Vehicle Management
i. Use case: Add Vehicle
Goal in context: To add new vehicle
Precondition:
1. System has been programmed for adding vehicle in database
Trigger: The operator has a need to add new vehicle
Scenario:
2. Click on Maintain Vehicle button
3. Click on Add Vehicle button to add new vehicle
4. Enter the new vehicle data and confirm changes
Exception: Already Exist: Vehicle is already added in the database
ii. Use case: Edit a Vehicle
Goal in context: To edit a vehicle
Precondition:
1. System has been programmed for editing vehicle in database
Trigger: The operator has a need to edit a vehicle.
Scenario:
3. Search and Select the vehicle to edit
4. Click on Edit Vehicle button
5. Edit the vehicle details and confirm changes
28 | P a g e

Exception:
1. Does not exist: Requested vehicle does not exist in the database
2. Ambiguous Input
Priority: Expected
iii. Use case: Delete a Vehicle
Goal in context: To delete a vehicle
Precondition:
1. System has been programmed for deleting vehicle in database
Trigger: The operator has a need to delete a vehicle.
Scenario:
3. Search and Select the vehicle to delete
4. Click on Delete Vehicle button
5. Delete the selected vehicle and confirm changes
Exception: Does not exist: Requested vehicle does not exist in the database
Priority: Expected
5. Parcel Management
i. Use case: Add Parcel
Goal in context: To add new parcel
Precondition:
29 | P a g e

1. System has been programmed for adding parcel in database
Trigger: The operator has a need to add new parcel
Scenario:
2. Click on Maintain Parcel button
3. Click on Add Parcel button to add new parcel
4. Enter the new parcel data and confirm changes
Exception: Already Exist: Parcel is already added in the database
ii. Use case: Edit a Parcel
Goal in context: To edit a parcel
Precondition:
1. System has been programmed for editing parcel in database
Trigger: The operator has a need to edit a parcel.
Scenario:
2. Click on Maintain Parcel button
3. Search and Select the parcel to edit
4. Click on Edit Parcel button
5. Edit the parcel details and confirm changes
Exception:
1. Does not exist: Requested parcel does not exist in the database
2. Ambiguous Input
30 | P a g e

6. View Parcel Location
i. Use case: View Parcel Location
Goal in context: To view a parcel
Precondition: System has been programmed for viewing parcel
Trigger: The operator and customer has a need to view parcel
Scenario:
2. Visit the main page
3. Select the parcel to be viewed
4. Click the View button
5. View the result in map
Exception: Parcel does not exists
Use Case Diagrams
31 | P a g e
Figure 3: Use Case (Level-0)

32 | P a g e
Figure 4: Use Case (Level-1)

33 | P a g e
Figure 5: Use Case (Level-2.1)

34 | P a g e

Activity Diagrams
35 | P a g e
Figure 9: Activity Diagram (Log In)

36 | P a g e
Figure 10: Activity Diagram (Log Out)

37 | P a g e
Figure 11: Activity Diagram (Change Password)

38 | P a g e
Figure 12: Activity Diagram (Add User)

39 | P a g e
Figure 13: Activity Diagram (Add Parcel)

40 | P a g e
Figure 14: Activity Diagram (Add Station)

41 | P a g e
Figure 15: Activity Diagram (Add Vehicle)

42 | P a g e
Figure 16: Activity Diagram (Edit User)

43 | P a g e
Figure 17: Activity Diagram (Edit Station)

44 | P a g e
Figure 18: Activity Diagram (Edit Vehicle)

45 | P a g e
Figure 19: Activity Diagram (Edit Parcel)

46 | P a g e
Figure 20: Activity Diagram (Delete User)

47 | P a g e
Figure 21: Activity Diagram (Delete Station)

48 | P a g e
Figure 22: Activity Diagram (Delete Vehicle)

49 | P a g e
Figure 23: Activity Diagram (Delete Parcel)

Swimlane Diagrams
50 | P a g e
Figure 24: Swimlane Diagram (Log In)

51 | P a g e
Figure 25: Swimlane Diagram (Log Out)

52 | P a g e
Figure 26: Swimlane Diagram (Change Password)

53 | P a g e
Figure 27: Swimlane Diagram (Add User)

54 | P a g e
Figure 28: Swimlane Diagram (Add Station)

55 | P a g e
Figure 29: Swimlane Diagram (Add Vehicle)

56 | P a g e
Figure 30: Swimlane Diagram (Add Parcel)

57 | P a g e
Figure 31: Swimlane Diagram (Edit Parcel)

58 | P a g e
Figure 32: Swimlane Diagram (Edit User)

59 | P a g e
Figure 33: Swimlane Diagram (Edit Vehicle)

60 | P a g e
Figure 34: Swimlane Diagram (Edit Station)

61 | P a g e
Figure 35: Swimlane Diagram (Delete Station)

62 | P a g e
Figure 36: Swimlane Diagram (Delete Vehicle)

63 | P a g e
Figure 37: Swimlane Diagram (Delete Parcel)

64 | P a g e
Figure 38: Swimlane Diagram (Delete User)

6.2.2 Data Model
If software requirements include the need to create, extend, or interface with a
database or if complex data structures must be constructed and manipulated, the
software team may choose to create a data model as part of overall requirements
modeling.
Data Objects
A data object is a representation of information which has different properties or
attributes that must be understood by software. We found following data objects in
our Project.
Data Object: User
Attributes:
 User_id
 UserName
 Password
 Email
 Type_id
Data Object: UserType
Attributes:
 Type_id
 Title
Data Object: Parcel
Attributes:
 Parcel_id
 Name
 Description
 Status
 Parcel_Source
 Parcel_Destination
 User_Id
 Vehicle_Id
65 | P a g e

Data Object: Vehicle
Attributes:
 Vehicle_id
 Name
 Vehicle_Source
 Vehicle_Destination
Data Object: Station
Attributes:
 Station_id
 Station_Name
 Source
 Destination
66 | P a g e

E-R Diagram
67 | P a g e
Figure 39: E-R Diagram

6.2.3 Class-based Model
Class-based modeling represents the objects that the system will manipulate, the
operations that will applied to the objects, relationships between the objects and the
collaborations that occur between the classes that are defined.
Identifying Analysis Classes
Some potential classes are here-
1. User
2. Authentication
3. Parcel
4. Vehicle
5. Station
6. Database
Class Cards
1. User
68 | P a g e
Figure 40: Class Card (User)

2. Authentication
69 | P a g e
Figure 41: Class Card (Authentication)
3. Parcel
Figure 42: Class Card (Parcel)
4. Vehicle
Figure 43: Class Card (Vehicle)

5. Station
70 | P a g e
Figure 44: Class Card (Station)
6. Database
Figure 45: Class Card (Database)

CRC Model
71 | P a g e
Figure 46: CRC Model
6.2.4 Flow-Oriented Model
Although data flow-oriented modeling is perceived as an outdated technique by some
software engineers, it continues to be one of the most widely used requirements
analysis notations in use today. It provides additional insight into system requirements
and flow.
Data Flow Diagrams (DFD)
The DFD takes an input-process-output view of a system. In the figures, data objects
are represented by labeled arrows and transformations are represented by circles.

1. Context level Diagram
72 | P a g e
Figure 47: Data Flow Diagram (Context Level)
2. Level 1
Figure 48: Data Flow Diagram (Level 1)

3. Level 2.1
73 | P a g e
Figure 49: Data Flow Diagram (Level 2.1)
4. Level 2.2
Figure 50: Data Flow Diagram (Level 2.2)

6.2.5 Behavioral Model
The Behavioral indicates how software will respond to external events or stimuli.
There are two ways to show these responses. One is state diagram and the other is
sequence.
State Transition Diagrams
State diagram represents active states for each class the events (triggers).
1. Authentication
74 | P a g e
Figure 51: State Diagram (Authentication)

2. User
75 | P a g e
Figure 52: State Diagram (User)
3. Admin
Figure 53: State Diagram (Admin)

4. Database
76 | P a g e
Figure 54: State Diagram (Database)

Sequence Diagrams
Sequence diagram indicates how events cause transitions from object to object.
1. Login
77 | P a g e
Figure 55: Sequence Diagram (Login)

2. User Activity
78 | P a g e
Figure 56: Sequence Diagram (User Activity)
3. Create User
Figure 57: Sequence Diagram (Create User)

4. Add Parcel/ Vehicle/ Station
79 | P a g e
Figure 58: Sequence Diagram (Add Parcel/Vehicle/Station)
6.3 Requirement Change Management of Our
System
The developers intend to release a complete and fully functional application that
follows the guidelines mentioned in the SRS document. However, since the product
will be released for multiple browsers, updates will likely be required. These updates
would consist of any bug fixes that are necessary, compatibility patches for all of the
current browsers and expansions of the content. If the users find any issues or has any
comments they would be able to contact the developers through an official support
email address.
For managing the changes we are releasing versions of this document. This one is
version 1.0.

6.3.1 Bugs and Glitches
The users would be able to contact the developers through the support email system.
This is where they would present any bugs or glitches they have detected and if they
have any beliefs that the application is not functioning properly. General concerns or
comments would also need to be submitted here.
Out team will check this email regularly in order to respond to any time sensitive
information.
6.3.2 Patches
Developers would constantly be making changes in order to keep up with any
compatibility issues that may arise. These changes and any others that may be fixing
bugs or glitches would be released through these patches.
7 Software Design
7.1 Architectural Design
Architectural design represents the structure of data and program components that are
required to build a computer-based system. It considers the architectural style that the
system will take, the structure and properties of the components that constitute the
system and the interrelationships that occur among all architectural components of a
system. We follow the following steps in our architectural design process of FootStep.
i. Represent the system in context
ii. Define archetypes
iii. Refine the architecture into components
iv. Describe instantiations of the system
In following sections, we will represent these steps.
80 | P a g e

7.1.1 Represent the System in Context
In this step, we have used an architectural context diagram (ACD) to model the
manner in which software interacts with entities external to its boundaries.
81 | P a g e
Figure 59: Architectural context diagram (ACD)

7.1.2 Refine the Architecture into Components
Based on the archetypes, we refined the software architecture into components to
illustrate the overall structure and architectural style of the system.
Figure 60: Overall architectural structure for LCS with top-level components
82 | P a g e

7.1.3 Describe Instantiations of the System
83 | P a g e
Figure 61: LCS with component elaboration

7.1.4 Mapping Requirements into a Software
Architecture
Level 1:
84 | P a g e
Figure 62: First level factoring
Level 2.1:
Figure 63: Second level factoring (2.1)

Level 2.2:
85 | P a g e
Figure 64: Second level factoring (2.2)
7.2 Component Level Design:
A complete set of software components is defined during architectural design. But the
internal data structures and processing details of each component are not represented
at a level of abstraction that is close to code.
Component-level design defines the data structures, algorithms, interface
characteristics, and communication mechanisms allocated to each component. The
work product produced is a design for each software component, represented using
graphical, tabular, or text-based notation. Component is a modular, deployable,
replaceable part of a system that encapsulates implementation and exposes a set of
interfaces.

There have several steps for component level design. Each level is discussed briefly
with appropriate diagram.
Step-I: Identify all design classes that correspond to the problem domain as defined in
the analysis model and architectural model. In FootStep we found the following class.
 User
 Parcel
 Vehicle
 Station
 Database
In this part we analyze each of the class.
86 | P a g e
Figure 65: Problem Domain Classes

Step-II: Identify all design classes that correspond to the infrastructure domain
 These classes are usually not present in the analysis or architectural models
 These classes include GUI components, operating system components, data
management components, networking components, etc.
And elaborate all design classes that are not acquired as reusable components.
87 | P a g e
Figure 66: Class elaboration for User

88 | P a g e
Figure 67: Class Elaboration for Admin

89 | P a g e
Figure 68: Class Elaboration for Parcel
Step – III: These steps are done by following these steps-a)
Specify message details (i.e., structure) when classes or components
collaborate. (Collaboration Details)

Figure 69: Collaboration details for create user and others item
90 | P a g e
Figure 70: Collaboration details for user management

Figure 71: Collaboration details for user, parcel and vehicle management
b) Identify appropriate interfaces (e.g., abstract classes) for each component
(Appropriate Interfaces)
This section is only for creating interface or abstract class.
c) Elaborate attributes and define data types and data structures required to
implement them (usually in the planned implementation language).
91 | P a g e
Table 11: Data Types
Attribute Name Class Data Type/Data Structure
user_type user enum
user_name user, admin string
password user, admin string
user_status user enum
e-mail user, admin string
Parcel_id Parcel Int
Parcel_name Parcel String
Parcel_description Parcel String
Parcel_status Parcel Enum
Vehicle_id Vehicle Int
Vehicle_name Vehicle String
Vehicle_description Vehicle String
Vehicle_route Vehicle String

Station_id Station Int
Station_name Station String
d) Describe processing flow within each operation in detail by means of pseudo
code or UML activity diagrams.
92 | P a g e
Figure 72: Dataflow for authentication

Step-IV: Describe persistent data sources (databases and files) and identify the
classes required to manage them.
 Data Source
– Database
93 | P a g e

94 | P a g e
Figure 73: Data Store
 Required Class
– DB Connect
– DAO
Figure 74: Required Class
Step-V: Develop and elaborate behavioral representations for a class or component
This can be done by elaborating the UML state diagrams created for the analysis
model and by examining all use cases that are relevant to the design class.

Step-VI: Elaborate deployment diagrams to provide additional implementation detail.
95 | P a g e
Figure 75: Deployment Model
8 Risk Management
Risk management is an integral part of good management process. It is an iterative
process consisting of steps, which, when undertaken in sequence, enable
continual improvement in decision making. Risk management of a system is a
process of identifying, analyzing, evaluating, treating, monitoring and communicating
risks associated with any activity, function or process in a way that will enable
organizations to minimize losses and maximize opportunities.
The AS/NZS 4360:1999 risk management process is considered here for FootStep
project. In-line with AS/NZS 4360:1999 standards, the FootStep approach to risk
management requires five key steps:-
 Establish the context
 Identifying risks

 Analyzing risks
 Evaluating risks; and
 Treating risks
 Monitoring and review
96 | P a g e
Figure 76: AS/NZS 4360:1999 Risk management process
8.1 Context
Risk management of FootStep is being considered with keeping three factors in mind.
Three major factors were clarified as,
 Strategic Context
 Organizational context
 Risk Management Context
8.2 Identifying Risks
Risk identification involves examining all elements of risk against the four risk
categories identified. To constitute a risk three key components will be present
 A source
 Something at risk
 An effect
Once a risk is identified a mix of knowledge, experience and lateral thinking will be
applied to determine

97 | P a g e
 What can happen?
 How can it happen?
 What is the likelihood of it happening?
 What will be the consequences if it happens?
Identification Methods
While a range of identification methods will be integral to the IIT-Repository System
operations, including systems analysis, personal reports, audit recommendations,
experience and record review, two key resources will be utilized
 Risk Register
 Risk Data Sheets
Table 12: Identifying Risks
Potential Risk
Dimension
Ref.
No
Description
Likelihood
Consequence
Risk Rating
Agreed Priority
Transfer to
Risk Action
Plan
Refer Risk Chart
User U1 Users
resistance to
change
5 1 5 1 Consult with User and project
team
U2 Conflicts
between users
team
U3 Users with
negative
attitudes
toward the
project
team
U4 Lack of
cooperation
from users
5 1 5 5 Involved Top management
Requiremen
ts
R1 Continually
changing
requirements
3 3 9 2 Add effort on requirement
analysis with collaboration.
R2 System
requirement
not
adequately
indentified
4 4 16 1 Give a dummy project view at
first.

98 | P a g e
R3 Unclear
system
requirements
4 3 12 3 More meeting required with
stockholders
R4 Incorrect
system
requirements
stockholders
R5 Project
involves the
use of new
technology
4 2 8 2 Required experts or train
existing tem members
R6 Immature
technology
5 3 15 Involved Top management
Project
complexity
Planning &
Control
P1 Lack of
effective
project
management
Technology
2 5 10 4 Project planning should be
done kipping in mind about
existing tools and technology
P2 Project
progress not
monitored
closely enough
3 3 9 1 Project management and team
collaboration should be
increased
P3 Inadequate
estimation of
required
resources
2 4 8 1 Backup equipment should be
ready
P4 Poor project
planning
1 5 5 1 Assign experienced project
manager
P5 Project
milestone not
clearly defined
4 5 20 2 Continuous meeting and
monitoring
P6 Inexperience
project
managers
manager
P7 Ineffective
communicatio
ns
5 5 25 1 Taking continuous meeting
and collaboration with all
stakeholders
Team T1 Inexperience
team
members
manager
T2 Inadequately
trained
development
team
members
stockholders

99 | P a g e
T3 Team
members lack
of specialized
skill required
by the project
monitoring
Organizatio
nal
Environmen
t
O1 Change in
organizational
management
during the
project
team
O2 Corporate
politics with
negative
effect on the
project
monitoring
O3 Unstable
Academic
environment
5 5 25 1 Signed off the agreement with
detailed.
O4 Academic
program
Restructured
During project
1 5 5 1 Signed off the agreement with
detailed.
Risk Register
A list of risks identified across management and development areas has been
formulated. Risk register for FootStep are shown in Table-12. Risk in preliminary
investigation of the project and its organization are listed in this register.
Risk Data Sheets
New risks may be identified by anyone at any time. This approach facilitates a bottom
up and top down assessment ensuring a comprehensive coverage of risks. New risks
are documented on a Risk Data Sheet and provided to management for consideration
to be entered on to the Risk Register. Table-13 shows the template of risk data sheet.

100 | P a g e
Table 13: Risk Data Sheet Template
Risk Type
User
Require-ments
Team Project complexity Planning &
Control
Organizational
Environment
Complain
Description (What and How did it happen?)
What were the Causes that contributed? (please list)
Date of Occurrence Time of Occurrence Location of
Occurrence
Time & Date
Reported
Potential for Recurrence? (Please tick)
Rare Occasional Often Unknown
Supporting Comments:
What actions can be taken to eliminate or remove risk?
Person Completing Form Person Completing Form Date

8.3 Analyzing Risks
This step in the process involves analyzing the likelihood and consequences of each
identified risk, to determine its severity, and ensure that relevant actions can then be
implemented. When a new risk is identified, it enters in analysis phase. In this step
identified risks are being analyzed for determining its occurring probability, severity
and impact on the system.
The rating scales for determining impact are given below:
Likelihood Rating Scale
101 | P a g e
Table 14: Likelihood Rating
Level Rating Probability range Likelihood
Description
1 Rare 91% through 99% Very unlikely but not
impossible
2 Unlikely 61% through 90% Plausible, could occur
at sometime
3 Occasionally 41% through 60% Reasonable likelihood
to occur at sometime
4 Seldom 11% through 40% High probability of
occurring in most
circumstances
5 Certain 1% through 10% Will probably occur in
most circumstances
Consequence Rating Scale
Table 15: Consequence Rating Scale
Level Rating Impact
1 Negligible Low Impact
2 Minor Low Impact
3 Moderate Moderate Impact
4 Critical High Impact
5 Catastrophic Extreme Impact

Risk Rating Scale
Likelihood x Consequence = Level of Risk
102 | P a g e
Table 16: Risk Rating Scale
Level of Risk Criteria for Management of Risk
1-3 Acceptable
4-5 Monitor
6-9 Management Control Required
10 – 14 Urgent Management Attention
15-25 Unacceptable
8.4 Evaluating Risks
The risk evaluation step involves deciding whether the identified risk rating is
acceptable, after considering:-
 The controls already in place;
 The cost impact of managing the risks or leaving them untreated;
 Benefits and opportunities presented by the risk; and
 The risks borne by other stakeholders.
During this process, the risk rating identified during the analysis step, is compared
against all other risks and assigned priority for each risk.
8.5 Treating Risks
Risk treatment determines what can be done in response to the risks that have been
identified, with a risk rating of 6 or higher, to reduce, transfer, or eliminate the risk by
implementing new controls or enhancing existing controls. Backup resources and
buffered time is being added with each milestone. Each milestone has contingency
plane. If any risk will occur with a risk rating of 6 or higher, contingency plan will be
executed according to the risks severity.
8.6 Monitoring and Review
Regular monitoring and review of risks is an important part of the FootStep Risk
Management program. It ensures that new risks are; detected; added to the Risk

Register; managed and that action plans are implemented and progressed effectively.
The FootStep monitoring and review strategies include:-
 Risk management will be a stander topic of discussion in the monthly board
project meeting. This agenda will cover the review of risk register and its update
information.
 The Project Manager will monitor day-to-day progression of Risk Management
Action plans.
9 Communication and Reporting
103 | P a g e
Table 17: Communication and Reporting
Type of
Communication
Method / Tool Frequency
/Schedule
Information Participants /
Responsibles
Internal Communication:
Project
Meetings
Teleconference Weekly
and on
event
Project status,
problems, risks,
changed requirements
Project Mgr
Project Team
Sharing of
project data
Shared Project
Server
When
available
All project
documentation and
reports
Project Mgr(s)
Project Team
Members
Milestone
Meetings
Teleconference Before
milestones
Project status (progess) Project Mgr
Sub-project
Mgr
Final Project
Meeting
Teleconference M6 Wrap-up
Experiences
Project Mgr
Project Team
External Communication and Reporting
Project Report PowerPoint
Presentation
Monthly Project status
- progress
- forecast
- risks
Project
Manager
Class Teacher
(Ajmal Huda)

10 Delivery Plan
10.1 Deliverables and Receivers
104 | P a g e
Table 18: Deliverables and Receiver
Ident. Deliverable Planned Date Receiver
D1 Domain Analysis Report 20/08/2014 Ajmal Huda
D2 Requirements Specification 22/08/2014 Ajmal Huda
D3 Business Case Report 10/09/2014 Ajmal Huda
D4 Design Document 15/09/2014 Ajmal Huda
D5 Developers Plan 15/9/2014 Ajmal Huda
D6 Risk Management Report 15/9/2014 Ajmal Huda
D7 Test Plan 25/10/2014 Ajmal Huda
D8 Android App 25/10/2014 Ajmal Huda
D9 Web Application 20/11/2014 Ajmal Huda
D10 Final Project Report 29/10/2014 Ajmal Huda
11 Quality Assurance
11.1 Test Plan
11.1.1 Test Plan Identifier
TP_F 1.0
11.1.2 References
 Software Requirements Specification of FootStep
 Design Specification of FootStep

11.1.3 Introduction
This is the first release of Test Plan of ‘Footsteps’ which consists of test items,
strategy, risk issues, needs and an entire outline of testing the website. This document
is needed to be followed in order that anticipated outcome may be confirmed from the
project.
11.1.4 Test Items
Testing will consist of several phase, each phase may or may not include testing of
any or more of the following aspects of the website (listed alphabetically):
 Accessibility
 Availability
 Response Time
 Coding Standards
 Compatibility
 Content
 Functionality
 Navigation
 Performance
 Reliability
 Scalability
 Security
 Site recognition
 Usability
 Software Requirements Specification
 Design Specification
105 | P a g e

11.1.5 Software Risk Issues
There are several parts of the project that are not within the control of the developer
but have direct impacts on the process and must be checked as well.
 Web site becomes unavailable: Testing will be delayed until this
situation is rectified, may need to recruit more staff to do the testing or reduce
the number of test cases.
 Web testing software is not available/does not work: This will
delay the introduction of automated testing and result in more manual testing -
May need to recruit more staff to do the testing or reduce the number of test
cases.
 Testing staff shortages or unavailability: The test staff is part-time
106 | P a g e
and has other higher priorities, in addition no slack time is allocated for
illness or vacation, may need to recruit more staff to do the testing or reduce
the number of test cases.
 A large number of defects/incidents make it functionally
impossible to run all of the test cases: As many test cases as
possible will be executed, the project manager will ultimately make the
decision as to whether the number of defects/incidents warrants delaying the
implementation of the production version.
 Not enough time to complete all test cases: If time cannot be
extended, individual test cases will be skipped, starting with the lowest
priority.
 Security of the website is hampered: The website may become
vulnerable because of malware, spoofing, denial of service attack etcetera.
Appropriate steps are is prerequisite to take in order to enhance security
measure.

11.1.6 Features to be Tested
The level of risk for each feature is specified as high (H), medium (M) and low (L):
 Response time to access the pages for different users (H)
 Animations, transitions, graphics (L)
 Management packages (H)
 Updating profile and managing (H)
 Sitemap (M)
11.1.7 Features not to be Tested
Notable features and functions that will not be tested include: None
11.1.8 Approach
The Test Strategy presents the recommended approach to the testing of the
‘Footsteps’ website. The previous section on Test Items described what will be tested;
this describes how it will be tested. The main considerations for the test strategy are
the techniques to be used and the criterion for knowing when the testing is completed.
In addition to the considerations provided for each test below, testing should only be
executed using known, controlled databases, in secured environments.
11.1.8.1 Testing Types
11.1.8.1.1 Data and Database Integrity Testing
DBMS needs to be performed to identify the tools/techniques that may exist to
support the testing identified below.
Test Objective: Ensure Database access methods and processes function properly
and without data corruption.
Technique: Invoke each database access method and process, seeding each with
valid and invalid data (or requests for data). Inspect the database to ensure the data
has been populated as intended, all database events occurred properly, or review the
returned data to ensure that the correct data was retrieved (for the correct reasons)
107 | P a g e

Special Considerations: Testing may require a DBMS development environment
or drivers to enter or modify data directly in the databases. Processes should be
invoked manually. Small or minimally sized databases (limited number of records)
should be used to increase the visibility of any non-acceptable events.
11.1.8.1.2 Function Testing
Testing of the application should focus on any target requirements that can be traced
directly to use cases (or business functions), and business rules. The goals of these
tests are to verify proper data acceptance, processing, and retrieval, and the
appropriate implementation of the business rules. This type of testing is based upon
black box techniques, that is, verifying the application (and its internal processes) by
interacting with the application via the GUI and analyzing the output (results). An
outline of the testing recommended for this website is identified below:
Test Objective: Ensure proper application navigation, data entry, processing, and
retrieval.
Technique: Execute each use case, use case flow, or function, using valid and
invalid data, to verify the following:
 The expected results occur when valid data is used.
 The appropriate error/warning messages are displayed when invalid data is
used.
 Each business rule is properly applied.
 Completion Criteria: All planned tests have been executed.
 All identified defects have been addressed.
11.1.8.1.3 User Interface Testing
User Interface testing verifies a user’s interaction with the software. The goal of UI
Testing is to ensure that the User Interface provides the user with the appropriate
access and navigation through the functions of the applications. In addition, UI
Testing ensures that the objects within the UI function as expected and conform to
corporate or industry standards.
108 | P a g e

Test Objective: Verify the following:
 Navigation through the website properly reflects functions and requirements,
including window to window, field to field, and use of access methods (tab
keys, mouse movements, accelerator keys)
 Window objects and characteristics, such as menus, size, position, state, and
focus conform to standards.
Technique: Create/modify tests for each window to verify proper navigation and
object states for each application window and objects.
Special Considerations: Not all properties for custom and third party objects can
be accessed.
11.1.8.1.4 Performance Profiling
Performance testing measures response times, transaction rates, and other time
sensitive requirements. The goal of Performance testing is to verify and validate the
performance requirements have been achieved. Performance testing is usually
executed several times, each using a different "background load" on the system. The
initial test should be performed with a "nominal" load, similar to the normal load
experienced (or anticipated) on the target system. A second performance test is run
using a peak load. Additionally, Performance tests can be used to profile and tune a
system’s performance as a function of conditions such as workload or hardware
configurations.
Test Objective: Validate System Response time for designated transactions or
functions under the following two conditions:
 normal anticipated volume
 anticipated worse case volume
Technique: Use Test Scripts developed for Business Model Testing (System
Testing). Modify data files (to increase the number of transactions) or modify scripts
to increase the number of iterations each transaction occurs. Scripts should be run on
one machine (best case to benchmark single user, single transaction) and be repeated
with multiple clients (virtual or actual, see special considerations below).
109 | P a g e

Special Considerations: Comprehensive performance testing includes having a
"background" load on the server. There are several methods that can be used to
perform this, including:
 "Drive transactions" directly to the server, usually in the form of SQL calls.
 Create "virtual" user load to simulate many (usually several hundred) clients.
Remote Terminal Emulation tools are used to accomplish this load. This
technique can also be used to load the network with "traffic."
 Use multiple physical clients, each running test scripts to place a load on the
system.
 Performance testing should be performed on a dedicated machine or at a
dedicated time. This permits full control and accurate measurement.
 The databases used for Performance testing should be either actual size, or
scaled equally.
11.1.8.1.5 Load Testing
Load testing measures subjects the system-under-test to varying workloads to evaluate
the system’s ability to continue to function properly under these different workloads.
The goal of load testing is to determine and ensure that the system functions properly
beyond the expected maximum workload. Additionally, load testing evaluates the
performance characteristics (response times, transaction rates, and other time sensitive
issues).
Test Objective: Verify System Response time for designated transactions under
varying workload conditions.
Technique: Modify data files (to increase the number of transactions) or the tests to
increase the number of times each transaction occur
Special Considerations: Load testing should be performed on a dedicated machine
or at a dedicated time. This permits full control and accurate measurement.
The databases used for load testing should be either actual size, or scaled equally.
110 | P a g e

11.1.8.1.6 Security and Access Control Testing
Security and Access Control Testing focus on two key areas of security:
 Application security, including access to the Data or Business Functions, and
 System Security, including logging into / remote access to the system.
Application security ensures that, based upon the desired security, users are restricted
to specific functions or are limited in the data that is available to them. For example,
everyone may be permitted to enter data and create new accounts, but only
administrators can delete them.
System security ensures that only those users granted access to the system are capable
of accessing the applications and only through the appropriate gateways.
Test Objective: Function/Data Security: Verify that user can access only those
functions/data for which their user type is provided permissions.
System Security: Verify that only those users with access to the system and
application(s) are permitted to access them.
Technique: Function/Data Security: Identify and list each user type and the
functions/data each type has permissions for.
Create tests for each user type and verify permission by creating transactions specific
to each user type.
Modify user type and re-run tests for same users. In each case verify those additional
functions / data are correctly available or denied.
Special Considerations: Access to the system must be reviewed/discussed with the
appropriate network or systems administrator. This testing may not be required as it
may be a function of network or systems administration.
11.1.8.1.7 Configuration Testing
Configuration testing verifies operation of the software on different software and
hardware configurations. In most production environments, the particular hardware
specifications for the client workstations, network connections and database servers
vary. Client workstations may have different software loaded (e.g. applications,
drivers, etc.) and at any one time many different combinations may be active and
using different resources.
111 | P a g e

Test Objective: Validate and verify that the client Applications function properly on
the prescribed client workstations.
Technique: Use Integration and System Test scripts Open / close various PC
applications, either as part of the test or prior to the start of the test.
Execute selected transactions to simulate user activities into and out of various PC
applications.
Repeat the above process, minimizing the available conventional memory on the
client.
Special Considerations:
 What PC Applications are available, accessible on the clients?
 What applications are typically used?
 What data are the applications running (i.e. large spreadsheet opened in Excel,
100 page document in Word).
 The entire systems, network servers, databases, etc. should also be
documented as part of this test.
11.1.8.2 Tools
 Visual Studio 13
 Bugzilla
 Firebug
 Mantis
 PhpStorm
 Selenium
 Git
 Tilt
 Chrome Developer Tools
 Browsers (IE 8+, Chrome, Firefox, Opera, Safari)
112 | P a g e

Final document of software project

Final document of software project

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Final document of software project

Semelhante a Final document of software project (20)

Mais de Nadia Nahar

Mais de Nadia Nahar (16)

Último

Último (20)

Final document of software project