TP032057 JOSHUA JEBARAJ

Table of Contents
1.0 Introduction ...................................................................................................................................... 3
1.1 Project Background ....................................................................................................................... 3
1.2 Aims............................................................................................................................................... 4
1.3 Objectives...................................................................................................................................... 4
2.0 Methodology..................................................................................................................................... 5
2.1 Methodology Chosen .................................................................................................................... 5
2.3 Methodology Evaluation ............................................................................................................... 5
2.3 Justification of Choice ................................................................................................................... 7
3.0 Quality Assurance Process ................................................................................................................ 8
3.1 Quality Definition .......................................................................................................................... 8
3.2 Process .......................................................................................................................................... 9
3.2.1 Review project-level plans ..................................................................................................... 9
3.2.2. Develop quality assurance plan ............................................................................................ 9
3.2.3 Coordinate metrics............................................................................................................... 10
3.2.4 Coordinate risk program ...................................................................................................... 11
3.2.5 Perform audits ..................................................................................................................... 12
3.2.6 Coordinate review meetings ................................................................................................ 12
3.2.7 Facilitate process improvement........................................................................................... 13
3.2.8 Monitor test program .......................................................................................................... 13
4.0 Estimation ....................................................................................................................................... 15
4.1 Time Estimation .......................................................................................................................... 15
4.2 Effort Estimation ......................................................................................................................... 16
4.3 Cost Estimation ........................................................................................................................... 17
5.0 Software Quality Assurance Plan .................................................................................................... 19
5.1 Project Management .................................................................................................................. 19
5.1.1 Organization ......................................................................................................................... 19
5.1.2 Roles and Responsibilities .................................................................................................... 20
5.2 Documentation ........................................................................................................................... 21
5.2.1 Software Requirement Specification (SRS) .......................................................................... 21
5.2.3 Software Verification and Validation Plan ........................................................................... 26
5.2.4 Software Configuration Management Plan ......................................................................... 27
5.3 Standards, Practices, Conventions and Metrics.............................................................................. 28
5.4 Review and Audit ............................................................................................................................ 29
5.5 Testing ............................................................................................................................................. 30
TP032057 JOSHUA JEBARAJ

5.6 Tools, Techniques and Methodology .............................................................................................. 31

5.7 Risk Management ........................................................................................................................... 32
5.7.1 Purpose of Risk Management Plan .......................................................................................... 32
5.7.2 Risk Management Procedure................................................................................................... 32
6.0 Software Metrics ............................................................................................................................. 35
7.0 Conclusion ....................................................................................................................................... 40
References ............................................................................................................................................ 41
TP032057 JOSHUA JEBARAJ

1.0 Introduction

1.1 Project Background

Depression, a mental illness, that is faced by 20% of millennials in the current 6 years.
In the US, 22% of students who committed suicide due to depression. And most of them were
also treated at student counselling centres. Suicide is the 11th leading cause of death in the US.
It is the 3rd in the world for young people aged 15 to 24. In the past 6 years, the number of
college students reporting depression symptoms. Recently surfaced “the Blue Whale
Challenge”, has caused an increase in the number of suicide cases in the US, UK, Russia and
India. According to The SUN newspaper in the UK, Investigative newspaper Novaya Gazeta
reported: "We have counted 130 suicides of children that took place between November 2015
to April 2016."Almost all these children were members of the same internet groups and lived
in good, happy families. “Two schoolgirls Yulia Konstantinova, 15, and Veronika Volkova,
16, fell to their deaths from the roof of a 14-storey apartment block. Yulia left a note saying
“End” on her social media page after she posted a picture of a big blue whale.

A 17-year-old girl from India allegedly taking part in the suicide game was so desperate
to die she tried to kill herself twice in just two days, according to reports. She was recovering
from injuries sustained while jumping into a lake when she took a near-fatal drug overdose at
home. Another unnamed 15-year-old girl was also critically injured after falling on to snowy
ground from a fifth floor flat in the city of Krasnoyarsk, also Siberia. Two days earlier, a 14-
year-old girl from Chita was reported to have thrown herself under a commuter train. A 13-
year-old boy was also saved from killing himself after he was spotted perching on the edge of
a roof in Lviv, Ukraine. A family raced to stop a 15-year-old girl from killing herself, with the
young girl reportedly now recovering in a hospital in Barcelona. The Russian parliament
proposed a bill bringing about criminal responsibility for the creation of pro-suicide groups on
social media.
TP032057 JOSHUA JEBARAJ

1.2 Aims

This paper focuses on the development of an AI chat-bot that helps depressed individuals to
talk to and open-up without having the fear of being misjudged, which in turn helps lessen their
depression. This chat-bot will be monitored by experts, and the AI will learn more of the
individual. The app will also detect extreme levels of depression among individuals to avoid
them from taking their own lives. This app is mostly aimed to be used by individuals who are
pursuing higher education in universities, who mostly goes through multiple amount of stress,
be it with studies, relationship, etc. This causes a trigger in their depression levels. Besides that,
this app is also aimed for working young adults who also has an increase the number of
depressed individuals.

1.3 Objectives

 To develop a chatbot app that helps communicate with users under depression, to avoid
them to take away their own life.
 To help users find a platform to talk to without being misjudged
 To learn about a depressed individual through machine learning {AI}
TP032057 JOSHUA JEBARAJ

2.0 Methodology

A system development methodology refers to the process that are utilized to shape, plan, and
control the way toward building up an information system since it is essentially difficult to
drive forward a venture to automate strategy without earlier work. Invalid source specified.It is
a methodology for systematically organizing the best ways to develop systems efficiently. It
includes, for example, descriptions of work to be performed at each stage of the development
process and drafted documents. Multiple methodologies—which differ according to
viewpoint—are available. In terms of the development process, some example methodologies
are "water-fall development," "spiral development," and "agile-software development."
(S.Balsamo, et al., 2004)

2.1 Methodology Chosen

In this project, the developer has put into consideration and after researching, has chosen two
development methodology to plan, structure, test and control the development of this system.
The two methodologies that were chosen are Rapid Application Development (RAD)
methodology and Rational Unified Process (RUP)

2.3 Methodology Evaluation

The fundamental purpose of the Rational Unified Process is to provide a model for effectively
implementing commercially proven approaches to development, for use throughout the entire
software development life cycle. he Rational Unified Process is not a concrete development
model, but rather is intended to be adaptive and tailored to the specific needs of your project,
team, or organization. The Rational Unified Process is based on a few fundamental ideas, such
as the phases of development and the building blocks, which define who, what, when, and how
development will take place.

The Rational Unified Process is structured around six fundamental best practices, which are
so-named due to their common use throughout the industry:
TP032057 JOSHUA JEBARAJ

 Develop Software Iteratively: Encourages iterative development by locating and

working on the high-risk elements within every phase of the software development life
cycle.
 Manage Requirements: Describes how to organize and keep track of functionality
requirements, documentation, tradeoffs and decisions, and business requirements.
 Use Component-Based Architectures: Emphasizes development that focuses on
software components which are reusable through this project and, most importantly,
within future projects.
 Visually Model Software: Based on the Unified Modeling Language (UML), the
Rational Unified Processprovides the means to visually model software, including the
components and their relationships with one another.
 Verify Software Quality: Assists with design, implementation, and evaluation of all
manner of tests throughout the software development life cycle.
 Control Changes to Software: Describes how to track and manage all forms of change
that will inevitably occur throughout development, in order to produce successful
iterations from one build to the next.

Figure 1: Rational Unified Processing process (RUP)

TP032057 JOSHUA JEBARAJ

2.3 Justification of Choice

The developer has compared the two methodology and has chosen Rational Unified Processing.
The reason of choosing the Rational Unified Process (RUP) methodology because it helps the
developer to addresses the risk elements in every phase in the development lifecycle and reduce
the project’s risk profile with the help of iterative approach.Invalid source specified..

The Rational Unified Process assist the developer to organize the project by controlling the
functionality requirements and constraints, documentations and customers’ requirements. The
Rational Unified Process methodology will ensure the software quality is well maintained and
assist the developer on the design, implementation, and evaluation of the system throughout
the development lifecycle. Invalid source specified..
TP032057 JOSHUA JEBARAJ

3.0 Quality Assurance Process

3.1 Quality Definition

According to Chappell (2018), there is no single right way to define software quality. It
becomes simpler, as such, to group the various components of quality into three broader aspects
these are functional quality, process quality, and structural quality. In terms functional quality,
software quality will imply that the software performs the tasks that it is intended to perform.
The characteristics of this definition include meeting specified requirements, software has no
or few defects, performance is good enough, and the software is easy to learn and use.

In terms of structural quality, software quality implies that the code is well structured. The
attributes of this definition include several factors, which are maintainability, testability,
security, efficiency and understandability. The process quality is characterized by attributes
such as meeting delivery dates, meeting budgets and a repeatable development process
(Chappell, 2018).

The general definition of the term software quality assurance, as can be derived from the above
definitions, is that software quality assurance entails the efforts to make sure that the software
and the processes and procedures of its development meets requirements of both standards
schedules and budgets. For this report, the term software quality assurance will imply the ability
of the software to meet user needs and to conform to international standards (Schulmeyer,
2007).
TP032057 JOSHUA JEBARAJ

3.2 Process

3.2.1 Review project-level plans

The project-level plans must be reviewed prior to publication. Since publication of the SQA
plan occurs in the same time frame as publication of these other project-level plans, review of
the project-level plans is necessary to determine that they are consistent, correct, and of
acceptable quality. This review also identifies top-level tasks that SQA is tasked to perform,
and identifies the interfaces between SQA and other groups in the development organization

There are three subprocesses that are components of the review project-level plans process:

 Review the project management plan

 Review the CM plan
 Review the software development plan

3.2.2. Develop quality assurance plan

The SQA plan provides a road map to the activities that the SQA organization will perform.
Essentially, the SQA plan serves as a formal contract between the SQA organization and the
other groups on the project, specifying what tasks will be performed, according to what
schedule. There are 11 subprocesses associated with SQA planning. The subprocesses define
the activities to develop 11 sections that make up an SQA plan, as defined in IEEEStandard-
730.

 Develop QA plan introduction

 Create management section
 Identify documentation requirements
 Identify standards
 Specify reviews and audits
 Review configuration management interface
 Review defect reporting
 Develop metrics strategy
 Identify tools and techniques
TP032057 JOSHUA JEBARAJ

 Define supplier control

 Define records approach

3.2.3 Coordinate metrics

There are nine subprocesses associated with coordinate metrics. The nine subprocesses within
the scope of the coordinate metrics process involve developing a metrics strategy; defining a
schema for the metrics database; developing and documenting a metrics plan; and collecting,
analysing, and reporting on metrics data. Both process and product metrics should be
addressed. Metrics reports must be published in a timely manner so that any course corrections
indicated by the metrics can be made quickly.

 Develop metrics strategy

 Create metrics database schema
 Document metrics plan
 Review metrics plan
 Collect measurement data
 Compute metrics
 Evaluate trends
 Issue metrics report
 Update metrics process and plan
TP032057 JOSHUA JEBARAJ

3.2.4 Coordinate risk program

Risk types are defined as follows:

Known unknowns. Risks due to conditions that the team “knows” it does not have complete
information about.

Unknown knowns. Risks associated with conditions that the development team believes it has
full information about, but the information is not correct.

Unknown unknowns. Risks due to conditions that the development team does not know it
does not know about.

The coordinate risk program process contains nine subprocesses:

 Develop risk plan

 Review risk plan
 Evaluate plans, schedules for risk
 Collect process and product risks
 Establish risk database
 Perform risk assessment
 Coordinate risk control
 Coordinate risk meetings
 Issue risk reports
TP032057 JOSHUA JEBARAJ

3.2.5 Perform audits

A fully engaged SQA organization will also perform a number of less formal audits. These
should be performed according to a documented and approved audit plan and will include
process and product audits. Process audits can include audits of the configuration management
database. Product audits can include review of operator manuals.

The perform audits process contains nine subprocesses:

 Review project plans

 Develop audit plan
 Review audit plan
 Establish audit database
 Perform process audits
 Perform product audits
 Perform physical configuration audit
 Perform functional configuration audit ▪ Update audit process

3.2.6 Coordinate review meetings

An SQA organization is usually chartered with coordinating review meetings, on a project

where these meetings are formally controlled. During reviews, a specific task for SQA
personnel is to evaluate the process used in performing the reviews and report on that
evaluation to management.

The coordinate review meetings process contains nine subprocesses:

 Verify peer review schedule

 Develop agenda template
 Support peer review meetings
 Track action items
 Verify design review schedule
TP032057 JOSHUA JEBARAJ

 Develop design review agenda template

 Coordinate design review data packs
 Support design review meetings
 Track design review action items

3.2.7 Facilitate process improvement

A critical function of SQA organizations in the current age is to facilitate process improvement.
This subprocess is only applicable for an SQA group when the project organization does not
have, or does not have access to, an SEPG. Even if a corporatelevel SEPG exists, it can be
advantageous for the project dedicated SQA group to be responsible for some of the process
improvement functions. That way, more general corporate-level initiatives can be tailored and
adjusted to the needs of specific projects.

The facilitate process improvement process contains eight subprocesses:

 Review project plans
 Identify process improvement opportunities
 Develop process improvement plan
 Prepare for assessment
 Perform assessment
 Process assessment result
 Monitor action plan progress ▪ Update action plans

3.2.8 Monitor test program

The final subprocess within the QA process is monitor test program. This subprocess is
designed around an SQA group that does not have responsibility for testing. It is logical for the
SQA organization to take responsibility for assuring that the testing process is performed
according to the documented and approved test documentation.

The monitor test program process contains eight subprocesses:

 Establish test metrics database
 Collect test metrics
TP032057 JOSHUA JEBARAJ

 Report test metrics

 Review test documentation
 Monitor test execution
 Plan test process improvement
 Assess test process
 Develop test assessment report

(Drabick, 2000)
TP032057 JOSHUA
JEBARAJ

4.0 Estimation

Estimation sometimes can be seen as a highly subjective process. The time taken for everyone
to complete a task is different. As a result, everyone estimation could be different. Therefore,
an accurate estimation need to be perform by breakdown the work to a list of tasks which can
be say as work breakdown structure. Using the work breakdown structure, those tasks then b
performed with the estimation methods. Some tasks are hard to deal with cause by lack of
information, so the assumptions are needed to make the estimation results more accurate. There
are three estimation methods that will be used, which is time estimates, effort estimates, and
cost estimates.

4.1 Time Estimation

In this project, the time estimation should be performed on the work breakdown on each
division of the software for different services, architecture design of the system, testing and so
on. The work breakdown structure should be generated carefully and try to cover all the tasks
that need to be done. If the tasks are incorrect, developers can waste time going down a wrong
path. After the list of tasks is generated, the developing team must estimate each tasks of the
time taken to complete it. The most accurate estimates are those rely on prior experience.
Previous project results can be reviewed and taken in consideration to how long a similar tasks
takes to be completed. Some factor that might delay the tasks might need to be considered,
overestimating might be better than underestimating.
TP032057 JOSHUA
JEBARAJ

Below is an example of estimated schedule :

Tasks Duration Remarks

Architecture 2 weeks
Design

Requirement 2 weeks Some requirements might change

Validation

System Design 3 weeks Higher Security should be performed

System 3 months
Implementation

Testing 1 months

Total duration 5 months 3 weeks

4.2 Effort Estimation

In software development, effort estimation is the process of predicting the most realistic
amount of effort required to develop or maintain software based on incomplete, uncertain and
noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets,
investment analyses, pricing processes and bidding rounds.

There are two categories of estimating the effort of each tasks: deductive and inductive
methods.

Deductive

Assume the total cost for the project is given. From there assign the cost, and thus, the effort
of individual tasks based on estimated percentages derived from earlier, similar projects with
similar tasks. The advantage of deductive methods is a simple and rapid cost allocation.

Inductive

The basic idea of inductive methods is to start effort estimation with the tasks individually,
with support of experts, or knowledge of similar work packages of earlier projects, and then
summarize bottom up, following the structure of the work breakdown structure.
TP032057 JOSHUA
JEBARAJ

Delphi Method

For most of the tasks the Delphi method is used to estimate the effort. Asking the developer
for each task for their best guess, normal guess, and worst guess. Thus obtain three figures for
the expected effort: E(optimistic), E(normal), and E(pessimistic), then combine them with this
formula

Effort = (E(optimistic)+4*E(normal)+E(pessimistic))/6

If more developers is employed, the mean values could even be calculated and the
mathematical statistics can be applied with the concept of standard deviation.

Usually, all developers are asked to join an effort estimation workshop which can be combined
with a risk management workshop, of two, three, or more days depending on the number of
work packages that have to be estimated (Stoemmer, 2018).

4.3 Cost Estimation

In this system, doing cost estimation is likely with time estimation, for each tasks, assign a cost
to it. Doing cost estimation help developers to predict the resources required for the software
development. Normally the costs can be separated to development costs and operating costs.
Development costs are one-time cost that will not recur after project has been completed.
Operating costs are costs that tend to recur throughout the lifetime of the system.

Below is an example of estimate costs :

Development Costs

Spend Item Price

Android Studio developer version $7500
Programmer/Analysts ( $35/hrs ) $35000
Artificial Intelligence Specialist ( $45/hrs ) $675
Total : $43175
TP032057 JOSHUA
JEBARAJ

Annual Operating Costs

Spend Item Price

AI Maintanance $995
Programmer/Analysts ( $35/hrs ) $8750
System Librarian ( $45/hrs ) $300
Total : $10045
TP032057 JOSHUA
JEBARAJ

5.0 Software Quality Assurance Plan

There is no specific definition of the term software quality assurance plan. This is a term that
implies the set of actions that an organization opts to undertake in the implementation of
software quality assurance programs. However, a plan is often defined as a schedule showing
anticipated actions and resource implications, as well as expected outcomes. From this notion,
the term software quality assurance plan will imply the document outlining the steps or
procedures to be undertaken in complying with the software quality assurance guidelines.
Inferences will be made to several examples and templates of software quality assurance plans
to show a general outlook of the document. Software quality assurance plan is that document
that sets forth the processes, standards, and methods, as well as the procedures that will be used
in performing the software quality assurance function. As for APU, developing a software
quality assurance plan will be the first step in the implementation of the quality program aimed
at solving the current quality problems.

5.1 Project Management

5.1.1 Organization

The roles involve in SQA management team:

Roles

Project Manager

Project Librarian

System Architecture

GUI Designer

Test Manager

Review Manager

Quality Manager

Usability Test Manager

TP032057 JOSHUA
JEBARAJ

5.1.2 Roles and Responsibilities

Role Responsibility
Project Manager Managing the project plan, coordination of team members,
monitoring progress, task delegation, balancing workloads etc.

Project Librarian Maintaining the projects repository, creating new directories,

informing about changing in documentation handling.

System Architecture Defines system architecture, create the Software Architectural

Design Document.

GUI Designer Deigns user interface, creates the design forms.

Test Manager Create the test plan and test document.
Review Manager Fins sources to take part in external review, keeps track of external
reviews, organizing review meetings and their documentations.

Quality Manager Defines quality standards, writes the Software Quality Assurance
Plan, proofreading of all documents, ensure audits and reviews are
done.

Usability Test Organizing usability tests, documenting tests, classifies usability

Manager errors alongside GUI designer.
TP032057 JOSHUA
JEBARAJ

5.2 Documentation

5.2.1 Software Requirement Specification (SRS)

5.2.1.1 Overall Description

Product Perspective
An AI Chatbot for the depressed individuals
Product Features
AI Chatbot
Stress level calculator
Emergency Caller for suicidal people

5.2.1.2 System Features

Description and Priority

An AI chat-bot that helps depressed individuals to talk to and open-up without having the fear
of being misjudged, which in turn helps lessen their depression.
Functional Requirement
Distributed Database
Distributed database implies that a single application should be able to operate transparently
on data that is spread across a variety of different databases and connected by a communication
network as shown in below figure.
Client/Server System
The term client/server refers primarily to an architecture or logical division of responsibilities,
the client is the application (also known as the front-end), and the server is the DBMS (also
known as the back-end).
A client/server system is a distributed system in which. Some sites are client sites and others
are server sites.
All the data resides at the server sites.
All applications execute at the client sites.
TP032057 JOSHUA
JEBARAJ

5.2.1.3 External Interface Requirement

User Interface
Front-end software: android, ios
Back-end software: Firebase
Software Interface
Android Studio
XCode
Hardware Interface
Android device
IOS device
Communication Interface
This project supports specific application for Android and IOS devices.
5.2.1.4 Other Non-Functional Requirement
Performance
Normalization
The basic objective of normalization is to reduce redundancy which means that information is
to be stored only once. Storing information several times leads to wastage of storage space and
increase in the total size of the data stored.
If a database is not properly designed, it can give rise to modification anomalies. Modification
anomalies arise when data is added to, changed or deleted from a database table. Similarly, in
traditional databases as well as improperly designed relational databases, data redundancy can
be a problem. These can be eliminated by normalizing a database.
Normalization is the process of breaking down a table into smaller tables. So that each table
deals with a single theme. There are three different kinds of modifications of anomalies and
formulated the first, second and third normal forms (3NF) is considered sufficient for most
practical purposes. It should be considered only after a thorough analysis and complete
understanding of its implications.
Safety
If there is extensive damage to a wide portion of the database due to catastrophic failure, such
as a disk crash, the recovery method restores a past copy of the database that was backed up to
archival storage and reconstructs a more current state by reapplying or redoing the operations
of committed transactions from the backed-up log, up to the time of failure.
TP032057 JOSHUA
JEBARAJ

Security
Security systems need database storage just like many other applications and make sure only
authorised access are allowed to modify the database.
Software Quality Attributes
Availability: The services should be available as user are using the system
Correctness: The replied of the chatbot done should be correct
Maintainability: The chatbot should maintain correct replies

5.2.2 Software Design Description

Purpose
The people who are targeted users in the millennial age group. These will be the main users as
the app is built to cater and chat with people who are in severe depression which often leads to
suicide. The age group that would be aimed for this group are the millennial group , as statistic
shows that that the millennial group are the people with the highest number of depressed
individuals
Scope
The aim of this project is to develop an AI chat-bot that helps depressed individuals to talk to
and open-up without having the fear of being misjudged, which in turn helps lessen their
depression. This chat-bot will be monitored by experts, and the AI will learn more of the
individual. The app will also detect extreme levels of depression among individuals to avoid
them from taking their own lives. This app is mostly aimed to be used by individuals who are
pursuing higher education in universities, who mostly goes through multiple amount of stress,
be it with studies, relationship, etc. This causes a trigger in their depression levels. Besides that,
this app is also aimed for working young adults who also has an increase the number of
depressed individuals.

Overview
Provide an overview of this document and its organization.
TP032057 JOSHUA
JEBARAJ

System Overview
The targeted users are:

 Users who are suffering from depression

 Specialists ( Psychiatrists, Be-Frienders officials)

Users :

About us

 A few words or a brief sentence with logo summarizing what the app does.
 1-2 paragraphs at the top of the main About Us page that offer a bit more detail about
the app’s goal and main accomplishments.
 A section following the summary that elaborates on its key points and other essential
facts about the app.
 Provide links with descriptions for important websites.

Chatbot

 An artificial intelligence system that learns the user’s behaviour and responds to the
user accordingly.
 The user can chat with the bot to release their feelings and not kept inside.
 The user is allowed to customise their voice for the chatbot as well as the key strokes
available.

Settings

 Users can set their custom notification tone, their notification style and even their
basic ringtone.
 Users must set their emergency contacts as the app will contact them if any
emergency occurs.
TP032057 JOSHUA
JEBARAJ

Specialists ( Psychiatrists, Be-Frienders officials) :

About us

 A few words or a brief sentence with logo summarizing what the app does.
 1-2 paragraphs at the top of the main About Us page that offer a bit more detail about
the app’s goal and main accomplishments.
 A section following the summary that elaborates on its key points and other essential
facts about the app.
 Provide links with descriptions for important websites.

Chatbot

 An artificial intelligence system that learns the user’s behaviour and responds to the
user accordingly.
 The user can chat with the bot to release their feelings and not kept inside.
 The user can customise their voice for the chatbot as well as the key strokes available.

Settings

 Users can set their custom notification tone, their notification style and even their
basic ringtone.
 Users must set their emergency contacts as the app will contact them if any
emergency occurs.

System Architecture
Develop a modular program structure and explain the relationships between the modules to
achieve the complete functionality of the system. This is a high level overview of how
responsibilities of the system were partitioned and then assigned to subsystems. Identify each
high level subsystem and the roles or responsibilities assigned to it. Describe how these
subsystems collaborate with each other in order to achieve the desired functionality. Don’t go
into too much detail about the individual subsystems. The main purpose is to gain a general
understanding of how and why the system was decomposed, and how the individual parts
work together. Provide a diagram showing the major subsystems and data repositories and
their interconnections. Describe the diagram if required.
TP032057 JOSHUA
JEBARAJ

Data Design
Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized.

Component Design
In this section, give a close look at each component in a more systematic way.
Provide summary of the algorithm for each function listed in pseudocode.

Human Interface Design

Describe the functionality of the system from the user’s perspective. Explain how the user
will be able to use your system to complete all the expected features and the feedback
information that will be displayed for the user

5.2.3 Software Verification and Validation Plan

The authentication and validation testing is a development of inspection if the software has
come across with its future purpose. On the other hand, verification remains to check if the
development of a specified project progress stage satisfies the planned situations. The review
method will be selected used for the verification authentication test of AI Chatbot system

Phases of Inspection for AI Chatbot system

 Planning
 Overview Meeting
 Preparation
 Inspection Meeting
 Rework
 Follow-up
TP032057 JOSHUA
JEBARAJ

5.2.4 Software Configuration Management Plan

The purpose of the Configuration Management Plan is to describe how configuration

management will be taking place during the project lifecycle. This includes documenting how
configuration management is managed, roles and responsibilities, how configuration item
changes are made, and communicating all aspects of configuration management to project
stakeholders. Without a documented configuration management plan it is likely that
configuration items may be wasted, unfinished, or redundant work is done because of a lack or
version and document control.

Configuration Identification

Configuration identification involves identifying the components of the APU AP Card cashless
system, uniquely identifying the individual components, and making them accessible in some
form. A proper configuration identification schema identifies each component of the network
and provides traceability between the component and its configuration status information

Roles and Responsibilities

 Configuration Control Team

This team wills analysis the document of configuration, rejects, admits and also observes the
situation, is the core responsibility of this specific group.

 Configuration Management Team

This team will be mainly responsible for maintenance the configuration management
participants as well as keep the configuration management group update.

 Configuration Control

Includes the evaluation of all change requests and change proposals, and their subsequent
approval or disapproval. It is the process of controlling modifications to the system's design,
hardware, firmware, software, and documentation.
TP032057 JOSHUA
JEBARAJ

5.3 Standards, Practices, Conventions and Metrics

Product Standard

The product produced need to follow the SQA plan designed as well as the process of agile
scrum methodology.

Process Standard

• Documentation Standards

The SQA always require a standard with well-explained complete documentation. Once the
entire documents have been arranged, need to approve by the project manager and the SQA
team. Absolutely a standard document will deliver a better presentation and through support
the developer to maintain the progress easily. The standard for the documentation are using
Times New Roman font for clarity and line spacing should be 1.5 and font size for content
should be exactly 12.

• Coding and Naming Standards

The Software Quality Assurance team is responsible to handle these standards. Whenever the
development team has accepted these standards, the coding will be going on development
department. Moreover, coding and its standard can give a better view to programmer to recover
modify and better readability.

• User Interface Standards

The development team has to ensure that the application layout must follow a certain structure
to ensure the design consistency. The user interface must be user-friendly in order to be present
a positive point of view with clear design of interfaces.

Software Metrics

Software metrics are used to measure software. Their first use is to help us plan and predict
software development. It helps to control software quality and work progress more efficiently.
For the AP Card System, 5 agile metrics is used to identify and measure the software
performance, quality, the productivity and efficiency of project.
TP032057 JOSHUA
JEBARAJ

5.4 Review and Audit

Work Product Review

The comments about this product to make sure that the product are developed according to the
standards met. Also the User review will be to assess the product. By its end-users to test and
evaluate the client side, the client may once use without any problems, the product will then
officially released.

Process Review

Process of software development is used to create and achieve quality in software products.
Software development process should follow the standards that being set, developer review
will be taken to evaluate if the methodology is suitable for the development team.

Quality Assurance Progress Review

Through the quality assurance efforts that are to be held periodically to monitor the execution
of this plan, review will be collect to identify whether the progress of QA is as scheduled.

Quality Assurance Lesson Learn Review

Every time after a project is conduct, a lesson learn report should be generated for review
purpose at future if similar tasks is being conduct again. From the previous lesson learned,
project should be organised with consideration of those lessons.

Preliminary Design Review

The PDR is a technical assessment that establishes the baseline of a system to ensure a system
is operationally effective. A PDR is conducted before the start of detailed design work. This
review assesses the allocated design documented in subsystem product specifications for each
configuration item in the system and ensures that each function, in the Functional Baseline, has
been allocated to one or more system configuration items. The PDR establishes the allocated
baseline and underlying architectures to ensure that the system under review has a reasonable
expectation of satisfying the requirements within the currently allocated budget and schedule.
TP032057 JOSHUA
JEBARAJ

Critical Design Review

A CDR assesses the system final design as captured in product specifications for each
configuration item in the system’s product baseline and ensures that each configuration item
has been captured in the detailed design documentation. The resulting set of detailed drawings
and specifications establish an initial product baseline, with a final baseline incorporating any
design changes resulting from system demonstration and Initial Operational Test and
Evaluation (IOT&E). The completion of CDR usually initiates the start of formal configuration
management by the contractor of the technical baseline.

5.5 Testing

A Software Test Plan (STP) will be written to satisfy the requirements found in the Detailed
Description of the Software Development Process. The STP may contain separate sections for
each Software Sub-Section (SSS). The plan will provide management and the testing function
with an overview of the test activities, schedules and resources required to perform testing. The
plan will describe how the testing specifications found in the following sections will be
implemented.

Unit Test

All code will be unit tested to ensure that the individual unit performs the required functions
and outputs the proper results and data. Proper results are determined by using the design limits
of the client function as specified in the design specification defining the server function. Unit
testing is typically white box testing and may require the use of software stubs and symbolic
debuggers. This testing helps ensure proper operation of a module because tests are generated
with knowledge of the internal workings of the module.

Integration Test

Integration testing is a level of software testing where individual units are combined and tested
as a group. The purpose of this level of testing is to expose faults in the interaction between
integrated units. Each module is treated as a black box, while conflicts between functions or
classes and between software and appropriate hardware are resolved. Test cases must provide
unexpected parameter values when design documentation does not explicitly specify calling
requirements for client functions.
TP032057 JOSHUA
JEBARAJ

System Testing

System testing is a level of software testing where a complete and integrated software is tested.
The purpose of this test is to evaluate the system’s compliance with the specified requirements.
Completion of system testing is dependent on availability of hardware.

Acceptance Testing

Acceptance testing is a level of software testing where a system is tested for acceptability. the
purpose of this test is to evaluate the system’s compliance with the business requirements and
assess whether it is acceptable for delivery. It is a formal testing with respect to user needs,
requirements, and business processes conducted to determine whether or not a system satisfies
the acceptance criteria and to enable the user, customers or other authorized entity to determine
whether or not to accept the system.

5.6 Tools, Techniques and Methodology

Reviews
Work Product Review
Process Review
Quality Assurance Progress Review
Quality Assurance Lesson Learn Review
Preliminary Design Review
Critical Design Review

Software Development Methodology

Agile Scrum methodology
Software Metrics
Customer Satisfaction
Team Velocity
Release Burndown
Escaped Defects
True Test Coverage
TP032057 JOSHUA
JEBARAJ

5.7 Risk Management

5.7.1 Purpose of Risk Management Plan

A risk is an event or condition that, if it occurs, could have a positive or negative effect on a
project’s objectives. Risk Management is the process of identifying, assessing, responding to,
monitoring, and reporting risks. This Risk Management Plan defines how risks associated with
the APU AP Card system project will be identified, analysed, and managed. It outlines how
risk management activities will be performed, recorded, and monitored throughout the lifecycle
of the project and provides templates and practices for recording and prioritizing risks.

The Risk Management Plan is created by the project manager in the Planning Phase and is
monitored and updated throughout the project.

5.7.2 Risk Management Procedure

Process

The Risk Manager will ensure that risks are actively identified, analysed, and managed
throughout the life of the project. Risks will be identified as early as possible in the project so
as to minimize their impact. The steps for accomplishing this are outlined in the following
sections.

Risk Identification

Risk identification will involve the project team, appropriate stakeholders, and will include an
evaluation of environmental factors, organizational culture and the project management plan
including the project scope. Careful attention will be given to the project deliverables,
assumptions, constraints, work breakdown structure, cost/effort estimates, resource plan, and
other key project documents.

Risk Analysis

All risks identified will be assessed to identify the range of possible project outcomes.
Qualification will be used to determine which risks are the top risks to pursue and respond to
and which risks can be ignored. \
TP032057 JOSHUA
JEBARAJ

Qualitative Risk Analysis

The probability and impact of occurrence for each identified risk will be assessed by the project
manager, with input from the project team using the following approach:

Figure 2: Probability VS Impact Matrix

Risks that fall within the Red and Orange zones will have risk response planning which may
include both a risk mitigation and a risk contingency plan.
TP032057 JOSHUA
JEBARAJ

Quantitative Risk Analysis

Analysis of risk events that have been prioritized using the qualitative risk analysis process and
their affect on project activities will be estimated, a numerical rating applied to each risk based
on this analysis, and then documented in this section of the risk management plan.

Risk Response Planning

Each major risk (those falling in the Red & Orange zones) will be assigned to a project team
member for monitoring purposes to ensure that the risk will not “fall through the cracks”. For
each major risk, one of the following approaches will be selected to address it:

 Avoid – eliminate the threat by eliminating the cause

 Mitigate – Identify ways to reduce the probability or the impact of the risk
 Accept – Nothing will be done
 Transfer – Make another party responsible for the risk (buy insurance, outsourcing, etc.)

For each risk that will be mitigated, the project team will identify ways to prevent the risk from
occurring or reduce its impact or probability of occurring. This may include prototyping,
adding tasks to the project schedule, adding resources, etc. For each major risk that is to be
mitigated or that is accepted, a course of action will be outlined for the event that the risk does
materialize in order to minimize its impact.

Risk Monitoring, Controlling, And Reporting

The level of risk on a project will be tracked, monitored and reported throughout the project
lifecycle. A “Top 10 Risk List” will be maintained by the project team and will be reported as
a component of the project status reporting process for this project. All project change requests
will be analysed for their possible impact to the project risks. Management will be notified of
important changes to risk status as a component to the Executive Project Status Report.

(CDC, 2018)
TP032057 JOSHUA
JEBARAJ

6.0 Software Metrics

Software metrics are quantitative measurements of a software product or project, which can
help management understand software performance, quality, or the productivity and efficiency
of software teams. The agile methodology has a unique approach to software metrics and how
to use them effectively. Leon Tranter presents three agile principles for software metrics
(Tranter, 2018): Metrics should be used by the team—They should not be imposed by
management, rather they should be useful for the team to assess and improve their own work.
Metrics should be part of a conversation—A metric is just a number, it should be combined
into a deeper discussion about process and challenges faced by the team. Metrics should be
used as part of an investigation of the experiment—Agile teams should use metrics with a
specific hypothesis in mind, not measure for the sake of measurement.

Customer Satisfaction

A widely used and respected metric for customer satisfaction is Net Promoter Score (NPS). It
a number ranging from -100 (indicating no customers refer you to others) to +100 (all
customers likely to refer you to others).

Figure 3: Customer Satisfaction Chart

TP032057 JOSHUA
JEBARAJ

If you received 100 responses to your NPS survey with 15 responses in the 0-6 range

(detractors), 25 responses in the 7-8 range (passives) and 60 responses in the 9-10 range
(promoters), your NPS score is the percentage of promoters minus percentage of detractors,
ignoring passives = 60—15 = 35.
TP032057 JOSHUA
JEBARAJ

Release Burndown

A Release Burndown chart can help you understand, across an entire software release, how
development is progressing, how much of the planned software functionality remains to be
done, and when you can expect the release to be completed.

Figure 4: Release burndown example

TP032057 JOSHUA
JEBARAJ

Escaped Defects

This metric checks, per release or product component, how many bugs or issues were identified
after the software was already in production. This is a good indication of quality as perceived
by the end user. If it’s increasing, it is a sign of a faulty quality process.
TP032057 JOSHUA
JEBARAJ

True Test Coverage

We call this metric true test coverage as opposed to the regular test coverage metric, which
only measures unit tests. This is a metric that tells you how much of your codebase or feature
set is covered by all types of tests—unit, integration, UI automation, manual tests and end-to
end acceptance tests. It can reveal quality gaps—parts of the software that are new or actively
used but do not have sufficient test coverage.

Figure 5 : True Test Coverage Example (Sealights, 2018)

TP032057 JOSHUA
JEBARAJ

7.0 Conclusion

The report that is completed here thoroughly discusses about software quality, a major element
in software development that has a big impact in global implications. The major focus on this
report is related to the software quality assurance and the compliance of it regards to the
international standards that has been drafted over the years. The concept is applied in software
engineering in hoping that the produced product would meet the standards that has been
written. This also means that the product produced must be user centric and objectives being
met.

Software quality assurance has been used to make sure that the quality standards in producing
a software is complied. This also implicates that the process of software development is
following a certain ground rule to make sure that it is productive and not counter-productive,
with keeping in mind of the resources being used in the field. Therefore, a simple set of rules
and guidelines are written in order for the costs and resources be minimally wasted and
producing an end product which satisfies customers wants and needs.

Also discussed in this report is the application and practice of the concept of software quality,
where the various characteristics of software quality have been highlighted. The software
quality plan has also been described and its components highlighted. The major reason for
developing the SQAP has been identified as being a part of the overall organizational planning.
This report has discussed thoroughly the importance of quality, and why it’s needed to ensure
that the maximum capacity of a software development is achieved.
TP032057 JOSHUA
JEBARAJ

References
Anon., n.d. What are the Software Development Life Cycle (SDLC) phases?. [Online]
Available at: http://istqbexamcertification.com/what-are-the-software-development-life-
cycle-sdlc-phases/
Austin, 2010. What’s the difference between formative and summative evaluations?. [Online]
Available at: https://www.austinisd.org/dre/ask-the-evaluator/whats-difference-between-
formative-and-summative-evaluations
[Accessed 12 December 2018].
Bevan, N., 1995 . Measuring Usability as quality of use. Software Quality Journal , 4(2), pp.
115-116.
Eeles, P., 2006. What is a software architecture?. [Online]
Available at: https://www.ibm.com/developerworks/rational/library/feb06/eeles/
[Accessed 30 November 2018].
Fundamentals, S. T., 2009. Agile Testing. [Online]
Available at: http://softwaretestingfundamentals.com/agile-testing/
[Accessed 5 November 2018].
Harvey, R., 2007. Creational Design Patterns. [Online]
Available at: https://refactoring.guru/design-patterns/creational-patterns
[Accessed 6 January 2018].
Investopedia, 2011. Organisational Structure. [Online]
Available at: http://www.investopedia.com/terms/o/organizational-structure.asp
[Accessed 5 November 2018].
IoannisStamelosa, A. A. G. F., 2012. Information and Software Technology. A methodology
to assess the impact of design patterns on software quality, Volume 54(Issue 4), pp. Pages
331-346.
John.H, 2007. Coceptual Integrity. Journal of Information System, 20(3'), pp. 140 - 200.
Lund, H., n.d. Data Interity : What is it and why is it important?. [Online]
Available at: https://www.rapidionline.com/blog/data-integrity-what-and-why
[Accessed 15 December 2018].
Mugurel T. Ionita, D. K. H. ,. H. O., 2010. Scenario-Based Software Architecture,
Netherlands: Department Software Architectures, Philips Research,.
S.Balsamo, Marco, A. D., Inverradi, P. & Simeoni, M., 2004. IEEE Transactions on Software
Engineering. IEEE Transactions on Software Engineering, 30(5), pp. 295 - 310.
TutorialPoints, 2010. Grey Box Testing. [Online]
Available at:
https://www.tutorialspoint.com/software_testing_dictionary/grey_box_testing.htm
[Accessed 3 November 2018].
TutorialsPoint, 2010. Black box Testing. [Online]
Available at:
TP032057 JOSHUA
JEBARAJ

https://www.tutorialspoint.com/software_testing_dictionary/black_box_testing.htm
[Accessed 23 December 2018].
TutorialsPoint, 2010. Rapid Application Development. [Online]
Available at: https://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm
[Accessed 18 January 2019].
TutorialsPoint, 2010. White Box Testing. [Online]
Available at:
https://www.tutorialspoint.com/software_testing_dictionary/white_box_testing.htm
[Accessed 2 January 2019].