Final document of software project

PROJECT PLAN FOR “FOOTSTEP”

11/29/2014 Software Project Management

i

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

ii

Letter of Transmittal 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.

iv

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.

v

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

vi

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

vii

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

viii

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

ix

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

x

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

xi

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

1 | P a g e

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.

2 | 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.

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

3 | P a g e

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

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

4 | P a g e

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.

5 | 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:

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.

6 | P a g e

3.2.1 Project Manager

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

7 | P a g e

3.2.3 Project Team

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

8 | P a g e

Figure 1: Major Work Breakdown

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.

Figure 2: Work Breakdown

4.2 Schedule and Milestones

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:

Project Study Design Project

Development

FootStep

Project Study

Domain Analysis

Domain Report

Requirement Analysis

SRS Report

Design

Preliminay Design

Design Report

Database Design

Design Report

Project Development

Web Applicaton

Android App

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

10 | P a g e

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:

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.

11 | P a g e

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.

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

12 | P a g e

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.

13 | 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.

14 | 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.

15 | 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

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

16 | P a g e

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

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

17 | P a g e

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)

18 | 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

19 | 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

20 | 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

21 | 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.

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

23 | P a g e

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



24 | 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


25 | 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.

26 | 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:

27 | 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


28 | 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

29 | 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:

30 | 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



31 | 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

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



35 | P a g e

Activity Diagrams

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)

50 | P a g e

Swimlane Diagrams

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)

65 | P a g e

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

66 | 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

67 | P a g e

E-R Diagram

Figure 39: E-R Diagram

68 | P a g e

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

Figure 40: Class Card (User)

69 | P a g e

2. Authentication

Figure 41: Class Card (Authentication)

3. Parcel

Figure 42: Class Card (Parcel)

4. Vehicle

Figure 43: Class Card (Vehicle)

70 | P a g e

5. Station

Figure 44: Class Card (Station)

6. Database

Figure 45: Class Card (Database)

71 | P a g e

CRC Model

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.

72 | P a g e

1. Context level Diagram

Figure 47: Data Flow Diagram (Context Level)

2. Level 1

Figure 48: Data Flow Diagram (Level 1)

73 | P a g e

3. Level 2.1

Figure 49: Data Flow Diagram (Level 2.1)

4. Level 2.2

Figure 50: Data Flow Diagram (Level 2.2)

74 | P a g e

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

Figure 51: State Diagram (Authentication)

75 | P a g e

2. User

Figure 52: State Diagram (User)

3. Admin

Figure 53: State Diagram (Admin)

76 | P a g e

4. Database

Figure 54: State Diagram (Database)

77 | P a g e

Sequence Diagrams

Sequence diagram indicates how events cause transitions from object to object.

1. Login

Figure 55: Sequence Diagram (Login)

78 | P a g e

2. User Activity

Figure 56: Sequence Diagram (User Activity)

3. Create User

Figure 57: Sequence Diagram (Create User)

79 | P a g e

4. Add Parcel/ Vehicle/ Station

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.

80 | P a g e

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.

81 | 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.

Figure 59: Architectural context diagram (ACD)

82 | P a g e

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

83 | P a g e

7.1.3 Describe Instantiations of the System

Figure 61: LCS with component elaboration

84 | P a g e

7.1.4 Mapping Requirements into a Software

Architecture

Level 1:

Figure 62: First level factoring

Level 2.1:

Figure 63: Second level factoring (2.1)

85 | P a g e

Level 2.2:

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.

86 | P a g e

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.

Figure 65: Problem Domain Classes

87 | P a g e

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.

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)

90 | P a g e

Figure 69: Collaboration details for create user and others item

Figure 70: Collaboration details for user management

91 | P a g e

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).

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

92 | P a g e

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.

Figure 72: Dataflow for authentication

93 | P a g e

Step-IV: Describe persistent data sources (databases and files) and identify the

classes required to manage them.

Data Source

– Database

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.

95 | P a g e

Step-VI: Elaborate deployment diagrams to provide additional implementation detail.

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

96 | P a g e

Analyzing risks

Evaluating risks; and

Treating risks

Monitoring and review

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

Lik

elih

ood

Con

seq

uen

ce

Ris

k R

ati

ng

Agre

ed P

rio

rity

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 communications

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

101 | P a g e

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

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

102 | P a g e

Risk Rating Scale

Likelihood x Consequence = Level of Risk

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

103 | P a g e

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

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)

104 | P a g e

10 Delivery Plan

10.1 Deliverables and Receivers

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

105 | P a g e

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

106 | 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 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.

107 | P a g e

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)

108 | 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.

109 | 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).

110 | 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.

111 | 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.

112 | 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)

113 | P a g e

11.1.8.3 Measures and Metrics

The following information will be collected by the Development team during the Unit

testing process. This information will be provided to the test team at program turnover

as well as be provided to the project team on a biweekly basis.

Defects by module and severity.

Defect Origin (Requirement, Design, Code)

Time spent on defects that are most critical

The following information will be collected during the test process by the test team.

This information will be provided to the test manager and project manager on weekly

basis. Here the above there information will also be submitted and in addition with it:

Number of times a program submitted to test team as ready for test.

Defects located at higher levels that should have been caught at lower levels of

testing.

11.1.9 Item Pass/Fail Criteria

11.1.9.1 DATA AND DATABASE INTEGRITY TESTING CRITERIA

All database access methods and processes function as designed and without any data

corruption.

11.1.9.2 FUNCTION TESTING CRITERIA

All planned tests have been executed. All identified defects have been addressed

11.1.9.3 USER INTERFACE TESTING CRITERIA

Each window successfully verified to remain consistent within acceptable standard

11.1.9.4 PERFORMANCE PROFILING CRITERIA

Single Transaction / single user: Successful completion of the test scripts without any

failures and within the expected / required time allocation (per transaction)

Multiple transactions / multiple users: Successful completion of the test scripts

without any failures and within acceptable time allocation.

114 | P a g e

11.1.9.5 LOAD TESTING CRITERIA

Multiple transactions / multiple users: Successful completion of the tests without any

failures and within acceptable time allocation.

11.1.9.6 SECURITY AND ACCESS CONTROL TESTING CRITERIA

For each known user type the appropriate function / data are available and all

transactions function as expected and run in prior Application Function tests

11.1.9.7 CONFIGURATION TESTING CRITERIA

For each combination of the Prototype and PC application, transactions are

successfully completed without failure.

11.1.10 Suspension Criteria and Resumption

Requirements

Test case failure percentage rise to 60 on an average

Unavailability of required hardware specifications

A specific incident shuts down both development and testing

11.1.11 Test Deliverables

Acceptance test plan

System/Integration test plan

Unit test plans/turnover documentation

Screen prototypes

Defect/Incident reports and summaries

Test logs and turnover reports

11.1.12 Remaining Test Tasks

As the project is not developed in multi-phase process and no third party is involved

in the development core there would be no remaining test tasks.

115 | P a g e

11.1.13 Environmental Needs

Few environmental needs are obligatory to address before testing initiates:

The development environment needed for testing

Extended Lab facility

Access to production process

11.1.14 Responsibilities

The following table demonstrates the tasks and the corresponding members

responsible:

Table 19: Responsibilities

Test

Manager

Project

Manager

Development

Team

Test

Team Client

Acceptance Test Documentation &

Execution

System/Integration test Documentation

& Exec

Unit test documentation & execution

System Design Reviews

Detail Design Reviews

Test procedures and rules

Screen & Report prototype reviews

Change Control and regression testing

11.1.15 Schedule

The project is predefined to be submitted by 1 November 2014, therefore the testing

must be completed before at least one week of submission deadline.

11.1.16 Planning Risks and Contingencies

Time limitation

More automated testing must be implemented and mote members are to be added in

the testing team in order to recover the time constraint.

116 | P a g e

11.1 Test Cases

Test Suite ID TS001

Test Case ID TC001

Test Case Summary Ensure Database access methods and processes

function properly and without data corruption.

Related

Requirements n/a

Prerequisites 1. User is authorized.

2. Minimally sized database.

Test Procedure

1. Invoke each database access method and process

2. Seeding each with valid and invalid data (or

requests for data)

3. 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)

Test Data

Expected Result

Actual Result

Status Pass

Remarks

Created By Anirudhya Robi

Date of Creation 01/11/2014

Executed By Anirudhya Robi

Date of Execution 01/11/2014

117 | P a g e

Test Environment OS: Windows 7

Browser: Chrome 38

Test Suite ID TS002

Test Case ID TC002

Test Case Summary Validate System Response time for designated

transactions or functions

Related

Requirements

Prerequisites 1. User is authorized.

2. Having a "background" load on the server

Test Procedure

1. Use Test Scripts developed for Business Model

Testing (System Testing).

2. Modify data files (to increase the number of

transactions) or modify scripts to increase the

number of iterations each transaction occurs.

3. 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).

Test Data

Expected Result

Actual Result

Status Pass

Remarks



118 | P a g e




Browser: Chrome 38

Test Suite ID TS003

Test Case ID TC003

Test Case Summary Verify System Response time for designated

transactions under varying workload conditions.

Related

Requirements

Prerequisites

1. User is authorized.

2. Load testing should be performed on a dedicated

machine or at a dedicated time.

Test Procedure

1. Modify data files (to increase the number of

transactions) or the tests to increase the number

of times each transaction occur

Test Data

Expected Result

Actual Result

Status Pass

Remarks



119 | P a g e




Browser: Chrome 38

Test Suite ID TS004

Test Case ID TC004

Test Case Summary Verify that user can access only those functions/data

for which their user type is provided permissions.

Related

Requirements

Prerequisites


2. Access to the system must be reviewed/discussed

with the appropriate network or systems

administrator.

Test Procedure

1. Identify and list each user type and the

functions/data each type has permissions for.

2. Create tests for each user type and verify

permission by creating transactions specific to

each user type.

3. Modify user type and re-run tests for same users.

In each case verify those additional

functions/data are correctly available or denied.

Test Data

Expected Result

Actual Result

Status Pass

120 | P a g e

Remarks






Browser: Chrome 38

Test Suite ID TS005

Test Case ID TC005

Test Case Summary

Validate and verify that the client Applications

function properly on the prescribed client

workstations.

Related

Requirements

Prerequisites


2. What PC Applications are available, accessible

on the clients?

3. What applications are typically used?

4. What data are the applications running (i.e.

large spreadsheet opened in Excel, 100 page

document in Word).

5. The entire systems, network servers, databases, etc.

should also be documented as part of this test.

Test Procedure

1. 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.

2. Execute selected transactions to simulate user

activities into and out of various PC

121 | P a g e

applications.

3. Repeat the above process, minimizing the

available conventional memory on the client.

Test Data

Expected Result

Actual Result

Status Pass

Remarks






Browser: Chrome 38

122 | P a g e

Abbreviations and Definitions

Table 20: Abbreviations and Definitions

IIT Institute of Information Technology

SDLC Software Development Life Cycle

SRS Software Requirements Specification

DD Design Document

BDT Bangladeshi Taka

ID Identification, Identifier

QA Quality Assurance

CM Configuration Management

EPC Electronic Product Code

RFID Radio Frequency Identification

GPS Global Positioning Systems

RTLS Real Time Locating System

RR Risk Register

RM Risk Matrix

Revision

Table 21: Revision

Rev. ind. Name Change Description Date

1.0 Final Project Management

Report

Original Version 29/11/2014

Final document of software project

Software

project scope

samsuddoha bsse

project goals

project plan

tasnova chowdhury bsse

sadid khan bsse

nadia nahar bsse

anirudhya robi bsse