Software Engineering (Sessional) Final Report

Course: CSE-434

Kid’s Safety: An application for teaching children safety rules

Sadia Tasnuva Pritha

ID: 1604122
Rahnuma Tasnim
ID: 1604103

Department of Computer Science & Engineering

Chittagong University of Engineering & Technology
Team Members’ Details

Total
Contact CGPA
Photo Name ID Email Credit
No. Acquired
Passed

u1604122
Sadia Tasnuva Pritha 1604122 01788905333 121.25 3.30
@student.cuet.ac.bd

u1604103
Rahnuma Tasnim 1604103 01772035052 121.25 3.40
@student.cuet.ac.bd

1
Executive Summary

2
Contents

1 Introduction 7
1.1 Goals and Objectives of the project . . . . . . . . . . . . . . . . . . . . 7
1.2 Scope of the work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Current situation and context . . . . . . . . . . . . . . . . . . . 7
1.2.2 Competing products (available in market) . . . . . . . . . . . . 8
1.3 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Terms, Acronyms, and Abbreviations Used . . . . . . . . . . . . . . . . 8

2 Project Management Plan 9

2.1 Project Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Individual Contribution to the project . . . . . . . . . . . . . . 9
2.2 Process Model Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Rationale for choosing your lifecycle model . . . . . . . . . . . . 9
2.3 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Constraints to project implementation . . . . . . . . . . . . . . . . . . 11
2.5 Hardware and Software Resource (Tools/Language) Requirements . . . 11
2.6 Project Timeline and Schedule . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Estimated Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Social/Cultural/Environmental impact of the project . . . . . . . . . . 11

3 Requirement Specifications 12
3.1 Stakeholders for the system . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Use case diagram with Graphical and Textual Description . . . . . . . 12
3.3 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Static model – class diagram . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Dynamic model – sequence diagram . . . . . . . . . . . . . . . . . . . . 15
3.6 Safety and Security requirements . . . . . . . . . . . . . . . . . . . . . 17
3.6.1 Access Requirements . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.2 Integrity Requirements . . . . . . . . . . . . . . . . . . . . . . . 17

3
 3.6.3 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . 17

4 Architecture 18
4.1 Architectural model/style used . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1 Rationale for choosing your architectural model/style . . . . . . 19
4.2 Technology, software, and hardware used . . . . . . . . . . . . . . . . . 19

5 Testing and sustainability plan 20

5.1 Requirements/specifications-based system level test cases . . . . . . . . 20
5.2 Traceability of test cases to use cases . . . . . . . . . . . . . . . . . . . 20
5.3 Techniques used for test generation . . . . . . . . . . . . . . . . . . . . 20
5.4 Assessment of the goodness of your test suite . . . . . . . . . . . . . . . 20
5.5 Sustainability Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.2 Flexibility / Customization . . . . . . . . . . . . . . . . . . . . 20

4
List of Figures

2.1 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Usecase Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5
List of Tables

6
Chapter 1

Introduction

1.1 Goals and Objectives of the project

Children’s safety is a major concern for parents. When children are equipped with
proper safety rules, they will be able to handle adverse situations safely. However,
there are various safety rules to be covered. So, it can get confusing for parents as to
which ones are most important and how to easily convey them to their children.
The primary goal of our project is to develop an application that will teach children
the basic safety rules in an effective and age-appropriate manner. This will help both
parents and teachers in ensuring that the children are properly equipped with safety
rules for leading a safer life.
• Developing a software platform to teach children safety rules.
• Evaluation of children’s knowledge about each rule for better learning outcomes.
• Allowing the parents and teacher to monitor children’s progress.

1.2 Scope of the work

1.2.1 Current situation and context
Children are susceptible to all kinds of dangers. The best way of protecting them is
equipping them with knowledge regarding how to approach and handle adverse situa-
tions. Knowing the basic safety rules can help children escape harmful situations and
avoid accidents.
But our educational system does not include this crucial part in the school system.

7
So, it becomes more difficult for parents to understand which rules to teach and how
to effectively teach them. Also, sensitive topics need to be taught in a kid friendly
manner. As a result, children do not learn how to keep themselves safe in dangerous
situations.
A mobile application that teaches all the important safety rules is the best option since
almost every household owns a smartphone today. And it’s easier to engage children’s
attention when lessons are shorter and taught using attractive interfaces. The scope
for mobile application can be a platform where children learn important safety rules
effectively and parents and teachers monitor the children’s progress in learning the
safety rules and ensure the children are well-equipped with the rules.

1.2.2 Competing products (available in market)

There are no applications that teach children safety rules available in Bangla language.

1.3 System overview

Users of the system will be able to create a profile and then login once their information
has been verified. The safety rules will be provided as separate lessons. Children can
attend the first lesson after login. After the completion of a lesson children have to
complete a quiz. The result of the quiz can be seen on the view progress screen. Also,
each lesson will end with an overview of the safety rules covered in that lesson.
Both teachers and parents can access the child’s profile using his/her name or id and
check the progress. This way the application can be used in both home and school
settings.

1.4 Structure of the document

1.5 Terms, Acronyms, and Abbreviations Used

8
Chapter 2

Project Management Plan

2.1 Project Organization

2.1.1 Individual Contribution to the project

2.2 Process Model Used

In this project, we will use the waterfall model as a process model shown in Figure 2.1.
Using this process model, we can divide our project into several sequential phases. The
phases are: 1) Requirements, 2) Design, 3) Development, 4) Testing, 5) Deployment,
6) Maintenance. We will complete each phase sequentially to reach our goal.

2.2.1 Rationale for choosing your lifecycle model

Waterfall is a sequential model which divides the software development process into
pre-defined phases. Each phase should be finalized before the succeeding phase can
start. Also, there can be no overlap between the stages.
We chose this model as it’s recommended for smaller projects where requirements are
properly defined. Also, for projects for which proper resources are available. In our
case, the basic safety rules are already stated clearly. And the requirements are well-
defined too.
Moreover, the waterfall model includes elaborate documentation in each stage which is
helpful in rectifying any mistakes in the future or even recreating the system. Also, too
much user intervention can delay the development process of a model. But, this model
is completely dependent on the project team and includes minimum user intervention.

9
Figure 2.1: Process Model

10
2.3 Risk Analysis
2.4 Constraints to project implementation
2.5 Hardware and Software Resource (Tools/Lan-
guage) Requirements
The hardware and software resources that are required to complete the proposed
methodology are specified below.
Software: Java Development Kit(JDK), Android Studio
Languages: JavaScript, Html, CSS, MySQL

2.6 Project Timeline and Schedule

Requirement Specification: 1 week
Planning: 1 week
Modeling: 2 week
Code generation: 10 week
Testing: 2 week

2.7 Estimated Budget

2.8 Social/Cultural/Environmental impact of the
project
Children are the future of our society. If they are not safe, the stability of a society is at
danger. Our application will teach the children how to stay safe in different precarious
situations. Using this application, parents and children will be able to ensure their
children are equipped with all the crucial knowledge that’ll help keep them safe.
Moreover, this application will make parents and teachers more aware of the safety
rules. So, they’ll be able to understand the importance of teaching children the safety
rules. As a result, with the continuous usage of this application, a more knowledgeable
society will be developed and a cultural shift will happen. This society will be proactive
in making their children capable of protecting themselves by teaching them safety rules.

11
Chapter 3

Requirement Specifications

3.1 Stakeholders for the system

Stakeholders are the people or companies that are involved in the project and will get
impacted by the outcome of the project. In our project, children, parents, and teachers
are the stakeholders. Children will familiarize themselves with the application and learn
different safety lessons. Then attend quizzes to evaluate their knowledge. Parents and
teachers can familiarize themselves with the system to help younger children learn using
the app. Also, they can view the progress of the children by logging into the childrens
profile.

3.2 Use case diagram with Graphical and Textual

Description
Use case diagram (Fighure 3.1) is a representation of the system that portrays how
users interact with the system.
We can see in the diagram, there are three actors in our system: child, teacher, and
parent. They are external components of the system. And we have six processes called
‘create profile’, ‘log in’, ‘verify’, ‘attend class’, ‘complete quiz’, and ‘view progress’.
The processes are presented in a logical order for better understanding. The diagram
shows how each actor interacts with each process.
The child actor interacts with the ‘create profile’ process for creating a new profile.
Then, this actor interacts with ‘log in’. ‘Log in’ base process includes another process
‘verify’ for authenticating the user log in. After successful login, a child actor can

12
attend class, complete a quiz and view his/her progress using the respective processes.
The parent and teacher can login using the child’s name and view the progress too.

Figure 3.1: Usecase Diagram

3.3 Activity Diagram

Activity Diagram (Figure 3.2) is used to represent the control flow in a system. It
shows different decision paths from an initial point to a finish point in a sequential
and concurrent order. Our activity diagram focuses on the condition of flow and the
sequence in which it happens.

13
Figure 3.2: Activity Diagram

14
 Figure 3.3: Class Diagram

3.4 Static model – class diagram

The class diagram provides a structural view of our system in Figure 3.3. It shows the
different classes, their attributes, methods, and the relationships among objects. Our
project has two classes: login and user. The attributes and methods of these classes
are shown in the class diagram.

3.5 Dynamic model – sequence diagram

The dynamic communication between objects are shown in the sequential diagram
(Figure 3.4). It simply depicts the interaction between objects in a sequential order.
Our system has one actor user. This actor interacts with the objects of the system but
is situated outside the scope of the system. We have two lifelines that include ‘system’
and ‘database’ objects which are internal to the system.

15
Figure 3.4: Sequence Diagram

16
3.6 Safety and Security requirements
3.6.1 Access Requirements
3.6.2 Integrity Requirements
3.6.3 Privacy Requirements

17
Chapter 4

Architecture

4.1 Architectural model/style used

The architectural design depicts the organization of data and software components
needed to build a system. It includes the system’s architectural style, the properties
and arrangements of components, and the relationships between all of the components.
In our educational application system, we used a data-centered architecture design. As
seen in the figure 4.1, a database is at the center of this architecture and is frequently
accessed by other components.

Figure 4.1: Architectural Model

18
4.1.1 Rationale for choosing your architectural model/style
The user interface gathers the information provided by the user during the registration
process and stores it in the database This information is accessed to verify the user
login. Also, after each lesson completion, the results of the quiz are stored in the
database. When children, parents, and teachers want to view the progress, these results
are accessed from the database and viewed by them. So, our system is data-centered
and the data stored in the database is frequently accessed. Also, the components of
our system are independent and only interact and access data through the database.
This model also ensures data integrity and ensures scalability. So, we can add new
components to the system later on without affecting the previous components. Hence,
we used the data-centered architecture model.

4.2 Technology, software, and hardware used

19
Chapter 5

Testing and sustainability plan

5.1 Requirements/specifications-based system level

test cases
5.2 Traceability of test cases to use cases
5.3 Techniques used for test generation
5.4 Assessment of the goodness of your test suite
(Which metrics were used for such assessment?)

5.5 Sustainability Plan

5.5.1 Scalability
(Describe how designers allow for future capacities- number of simultaneous users pos-
sible, maximum stored data, etc.)

5.5.2 Flexibility / Customization

20
Acknowledgement

21
Bibliography

22