Capstone Project Guide Line

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 47

DownloadCapstone Project Guide Line
Open PDF In BrowserView PDF
MINISTRY
TRAINING

OF

EDUCATION

FPT UNIVERSITY

Capstone Project Document
Tên đề tài
Nhóm số
Group members Tên các thành viên trong nhóm – Mã số sinh viên
Supervisor Giảng viên hướng dẫn
Ext. Supervisor N/A
Capstone Project Mã đề tài
code

-Ho Chi Minh City, Ngày bắt đầu làm-

PAGE \* MERGEFORMAT 1

AND

This page is intentionally left blank

PAGE \* MERGEFORMAT 1

Table of Contents
Table of Contents ................................................................................................................................3
List of Tables........................................................................................................................................4
Definitions, Acronyms, and Abbreviations..........................................................................................6
A.

Report No. 1 Introduction ...........................................................................................................7
1.

Project Information .................................................................................................................7

2.

Introduction ............................................................................................................................7

3.

Current Situation .....................................................................................................................7

4.

Problem Definition ..................................................................................................................7

5.

Proposed Solution ...................................................................................................................8

6.

7.

5.1

Feature functions ............................................................................................................8

5.2

Advantages and disadvantages .......................................................................................8

Functional Requirements ........................................................................................................9
6.1

Name Card Management ................................................. Error! Bookmark not defined.

6.2

Event ................................................................................ Error! Bookmark not defined.

6.3

Searching .......................................................................... Error! Bookmark not defined.

6.4

Suggestion ........................................................................ Error! Bookmark not defined.

6.5

User Management ........................................................... Error! Bookmark not defined.

Role and Responsibility ...........................................................................................................9

PAGE \* MERGEFORMAT 1

List of Tables
Table 1: Roles and Responsibilities .....................................................................................................9

PAGE \* MERGEFORMAT 1

List of Figures
Figure 1: Modified Waterfall Development Model.............................. Error! Bookmark not defined.

PAGE \* MERGEFORMAT 1

Definitions, Acronyms, and Abbreviations
Miêu tả từ viết tắt hay các term dùng trong tài liệu thuyết minh bên dưới
Name
Definition
Từ viết tắt
Định nghĩa

PAGE \* MERGEFORMAT 1

A. Report No. 1 Introduction
1. Project Information
-

Project name: 
Project Code: 
Product Type: 
Start Date: 
End Date: 

2. Introduction

Ví dụ:
In this document, we introduce a solution for motorbike insurance company. Current insurance
company systems have some problems like delayed in renew contracts for customer or inconvenient
in checking insurance card validation process. Based on our researches and analysis, we proposed
a solution for insurance company in Vietnam and other developed countries.
We build a system, which help the insurance companies to solve current problems. In the process of
analysis, we believe the NFC cards is capable to resolve the problem by using NFC card to save
information about insurance contract. NFC cards are convenient to manage the contract
information and checking, validating process. Beside of that we also provide an information system
to manage NFC cards so that insurance companies will manage the contracts easier.
This document also describes our working process in 4 months includes our perspective in the
system, component designs and detailed core workflows. We hope the system and our solution will
help resolve the problems from insurance companies in Vietnam and other developed countries.

3. Current Situation

Ví dụ
When participating in traffic, vehicle owners are required to have compulsory insurance
(according to Article 6, Decree on compulsory insurance for civil liability of motor vehicle owners,
Decree No. 103/2008/ND-CP by Vietnam Government). Therefore, vehicle owners buy insurance
from insurance companies or its agents. They pay insurance premium by cash or in online website
and receive an insurance certificate with a term of one year, the term can be shorter in some
specific situation. When their insurance out of date, they must buy a new insurance, old certificate
will be useless. Traffic police will read insurance certificate to check traffic participants.

4. Problem Definition
<Định nghĩa vấn đề: nêu ra các khó khăn, khuyết điểm, hạn chế ở hệ thống hiện
tại>

PAGE \* MERGEFORMAT 1

Ví dụ
Below are disadvantages of current situation:


Forget insurance’s expired date: Vehicle owners usually keeps their insurance certificate
in wallet or somewhere on their vehicle. However, except in cases of necessity, people are
not often check their insurance so they could forget its expired date. An expired insurance
is not good while it be revealed by traffic officers and could get worse in case of traffic
accident.



Hard for traffic officers to check and verify insurance: ....



...

5. Proposed Solution

Ví dụ:
Our proposed solution is to build an insurance NFC card system named “MIC system” to resolve
the current situations and compatible with current laws, we also design the system to be scalable
so we can deploy this system to a multiple insurance services company in future plan.
MIC system includes a web application and two mobile applications with following functions:

5.1 Feature functions

Ví dụ




Web application:
o

Register insurance: user can register a new insurance card with on website using
online payment. A staff will contact the user to create contract and sends an
insurance NFC card to him/her. If users already have a NFC card, they can use
the website to renew current contract.

o

Check card information: ...

o

...

Insurance card printer (mobile app):
o



Simulating NFC card printer: staff can print NFC card....

...

5.2 Advantages and disadvantages

- Advantages:

Ví dụ

PAGE \* MERGEFORMAT 1

-

o

The interaction between the insured one and the insurance company: the insured
one and the company now are easier to communicate through the website when
each person has an account.

o

...

Disadvantages:


Ví dụ
o

Currently not consistent with the law of Vietnam about insurance card issues.

o

...

- Notes: Có thể phân tích điểm vượt trội hay khuyết điểm của giải pháp sẽ
được thực hiện so với hệ thống đang có sẵn

6. Functional Requirements
Function requirements of the system are listed as below:

Ví dụ






User component:
o

New contract request

o

...

Staff component
o

Create new contracts

o

...

...

7. Role and Responsibility
Liệt kê danh sách và vai trò theo mô hình phần mềm mà nhóm sẽ lựa chọn
trong phần tiếp theo. Các thành phần nên đặc tả vào bảng để dễ nhìn
Ví dụ
No
1
2
3
4
5

Full Name

Role

Position

Kiều Trọng Khánh
Đinh Quang Trung
Nguyễn Hữu Phúc
Phùng Quang Minh Trí
Nguyễn Chí Kha

Project Manager
Developer
Developer
Developer
Developer

Supervisor
Leader
Member
Member
Member

Contact
khanhkt@fpt.edu.vn
trungdqse60994@fpt.edu.vn
phucnhse60749@fpt.edu.vn
tripqmse60746@fpt.edu.vn
khanc60351@fpt.edu.vn

Table 1: Roles and Responsibilities

PAGE \* MERGEFORMAT 1

B. Report No.2 Software Project Management Plan
1. Problem Definition
1.1 Name of this Capstone Project
-



Ví dụ


Official name:

Insurance Card



Vietnamese name:

Thẻ bảo hiểm



Abbreviation:

MIC

1.2 Problem Abstract

Ví dụ
As current in Viet Nam customer use Motor Insurance Certificate Paper when they get problems
with their motor. Using the Motor Insurance Certificate Paper is inconvenient, for example, it can
be wet or to insert or update the information in to insurance certificate paper is complicate. So we
use the NFC card we call it is insurance card to handle it. Insurance company supplies the NFC
card when the customer buy insurance. The card contains the information of customer, if the
customer joins with many insurance service they just use only one card.
We provide a software to check the validation of card, the expired date of card and insurance
services that customer joined. We also provide other advantages that can help save time and costs
in some process of company. For example, the software can automatic extend the insurance
service, update the information about accidents of motor. In addition, we also provide a system
software to manage the information of customer via some insurance card we bought, this software
will deploy at insurance company

1.3 Project Overview
1.3.1 Current Situation
-



Ví dụ
Below are the problems encountered in this project:


Security: currently, there is few possible problems encountered with NFC tags, as NFC
tags can be counterfeited, attacked during data transmission caused data loss, data
corruption.

PAGE \* MERGEFORMAT 1



Server crash: all the needed data is stored in the server. So if server crash, all the devices
cannot get card information.



Absence of team members: team members can get sick or unexpected problems.



Currently not consistent with the law of Vietnam about insurance card issues.



...

1.3.2 The Proposed System

Ví dụ
According to the technology researches, we found out that the NFC technology is very capable of
resolve the current situations in insurance companies. We can use a feature of NFC tag to resolve
the security problem from NFC card. The basic idea is to use a NFC tag (or NFC “card”) which
contains a unique card ID as an insurance card instead of paper card currently.
We also build a high available web server to maintain the main system to work 24/7 to make sure
that if mobile applications need access to the information there will be always available.
We assign responsibility in vertical to make sure if any member in this problem cannot continue to
work in our team there will be the least harmful to the project processes.
To resolve problem from Vietnam laws of insurance for motorbike, we support the insurance
companies to propose new law sections about using technology devices to work with insurance
certificate paper to make our system work legally in current situation.
Our system includes three main subsystems: an online website for company’s staffs, a mobile
application for police officers and a mobile application to simulate the card printer

1.3.2.1 Web Site
- 
Ví dụ
Website is a common communication portal for insurance company’s staffs and users (customers).
Website provide following features:




For users (customers):
o

Users can register new insurance card with online payment.

o

...

For staffs:
o

...

Beside above, website system also provides an API interface for two mobile applications to
retrieve, update data from mobile applications.

1.3.2.2 Mobile Application
- 
PAGE \* MERGEFORMAT 1

Ví dụ
This is a simulating application to simulate the work of Card Printer. In reality, the company who
deploy this system need to have a NFC Card Printer to write information about the insurance
company and customer information into an NFC card. However, our system currently only support
this as a simulating application. This application is used by company’s staffs and do followings:


Retrieves insurance contract information and write data to a physical NFC card.



...

...

1.3.3 Boundaries of the System

Ví dụ
This section supposes that the government laws in local area supports the method of using NFC
cards as insurance cards, and accept NFC insurance cards are legal.


Every company who has Information System infrastructure can deploy this system.



Companies who deployed this system has to equip enough devices for the system to run,
includes:
o

Computer system with internet connection.

o

...

1.3.4 Future Plans

Ví dụ
Current system only can deploy to a company which provides single service: motor insurance card,
we call this is the Isolated Single Service Model. We design the system to make it easy to scale to 2
bigger models:


Isolated Multiple Service Model: system can be deployed to one company which provide
multiple insurance services such as motor insurance, health insurance, assets insurance…



Distributed Multiple Service Model:.....



...

1.3.5 Development Environment
1.3.5.1 Hardware requirements 


PAGE \* MERGEFORMAT 1

Ví dụ:

Windows
Internet Connection
Operating System
Computer Processor

For server
Minimum Requirements
Cable, Wi-Fi (4 Mbps)
Window Server 2008
Intel® Xeon ® 1.4GHz

Computer Memory

1GB RAM

Recommended
Cable, Wi-Fi (8 Mbps)
Window Server 2008
Intel® Xeon ® Quad Core
(12M Cache, 2.50 GHz)
2GB or more

Table 2: Hardware Requirement for Server
...

1.3.5.2 Software requirements 
Mô tả các yêu cầu phần mềm mà nhóm sẽ áp dụng trong phát triển
sản phẩm. Nên mô tả dưới dạng bảng biểu
Ví dụ:
Software
Operating system
Environment
Modeling tool
IDE
DBMS
Source control
Web browser

Name / Version
Window Server 2008
Java EE 6
Microsoft Visio 2013
Netbeans 7.2.1, Intellij IDEA
14.1
MySQL 5.6
TortoiseSVN 1.8.11
Chrome 42 or above

Description
Operating system and platform for development
Specification for developing web application
Used to implement website and web service
Programming tools
Used to create & manage the database for system
Used for source control
Testing browser

2. Project organization
2.1 Software Process Model



Ví dụ
This project is developed under waterfall model. We apply customized waterfall model to capable
with current situation in our team. We choose this model because the following reasons:


Based on researches and clarify Vietnam laws of insurance for motorbike and current
system in insurance companies, the requirements of this project are stable, clear, fixed and
well understood by all team members.



This project use NFC technology, ...



...

PAGE \* MERGEFORMAT 1

Figure 1: Waterfall model
Reference: Page 30, chapter 2, Software process model, SOFTWARE ENGINEERING 9th Edition,
by Ian Sommerville.

2.2 Roles and responsibilities 

Ví dụ

No
1

Full name
Kiều Trọng Khánh

Responsibilities
 Specify user requirement
 Control the development
process
 Give out technique and
business analysis support
Trần Nguyễn Đăng
Team Leader, BA,  Managing process
Khoa
DEV, Tester
 Designing database
 Clarifying requirements
 Prepare documents
 GUI Design
 Create test plan
 Coding
 Testing

Table 3: Roles and Responsibilities Details

2

...

Role in Group
Project manager

2.3 Tools and Techniques

Ví dụ
Tool / Technique
Frontend
Backend
...

Name / version
HTML, CSS, JavaScript, jQuery, Bootstrap
JavaEE, Servlet, JSP, Hibernate

PAGE \* MERGEFORMAT 1

3. Project Management Plan
3.1 Software development life cycle

Ví dụ
Phase

Description

Deliverables

Requirement
Analysis

- Collect
requirements
from customer.
-Identify and
clarify
requirements for
the system in
general.
- Architecture
design for the
system
- Detail design
using top-down
break down
- Choose
Architecture style

-Introduction of
proposed system.
-Software
requirement
specification.
-Project Task
Plan.
- Prototypes
- Software
20 manDesign Document days
- Base code
structure
- Technology
notes

Design

Resource
needed
20 mandays

Dependencies
and Constrains
N/A

Depend on
“Requirement
Analysis”

Risks
- Missing
requirement
- Unclear
scope of
project
- Lack of
member share
of understand
- Lack of
experience.
- Not fulfil
requirement.

....

Table 4: Software Development Life Cycle Detail

3.2 Phase Detail

Ví dụ

3.2.1 Phase 1: Requirement Analysis
Task
1. Collect requirements

2. Identify and clarify
main functions.
...

Description
Find which systems currently provide
similar service, their strengths and
weakness.
Define which main functions system
should provide.
Table 5: Phase 1: Requirement Analysis

PAGE \* MERGEFORMAT 1

Author
KhoaTND, HuyDN,
TanNH
KhoaTND, HuyDN,
TanNH

3.3All Meeting Minutes


4. Coding Convention


PAGE \* MERGEFORMAT 1

C. Report No. 3 Software Requirement Specification
1. User Requirement Specification

Ví dụ

1.1 Guest Requirement
Guest is a person who doesn’t have access to the system. Guest can use some
functions in the system. To use all functions, guest must login. These are some
functions guest can use:
 Register.
 Login.
 ...

1.2 Member Requirement
 ...

1.3 ...

2. System Requirement Specification
2.1 External Interface Requirement
2.1.1 User Interface


Ví dụ




General requirement for graphics user interface is the GUI should be simple, clear,
intuitive, and reminiscent.
The interface design is an iterate process includes: design, sketching, prototyping, user
assessment.
Some design principles will be taken into consideration:
o UI for businesss web applications Janko Jovanovic [Ref:
http://www.smashingmagazine.com/2010/02/25/designing-user-interfaces-forbusiness-web-applications/]
o Ten principles of effective web design – Vitaly Friedman [Ref:
http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-webdesign/]
o Principles of mobile interface design – Jonathan Stark [Ref:
http://www.oreilly.com/pub/e/2144]

2.1.2 Hardware Interface


Ví dụ


Smartphone with NFC support.

2.1.3 Software Interface


Ví dụ

PAGE \* MERGEFORMAT 1




Web application: work with Firefox (v30 or above), Chromes (v14 or above), Internet
Explorer (v10 or above) browse.
Mobile application: Android operating system (v 4.0 or above).

2.1.4 Communication Protocol


Ví dụ


Use HTTP protocol 1.1 for communication between the web browser and the web server.

2.2 System Overview Use Case


Ví dụ
Thông tin mô tả về đặc tả UML tham khảo tại http://www.omg.org/spec/UML/2.0/

Chú ý
- Các quan hệ giữa các use case và khi dùng extend phải ghi rõ  và condition
- Overview usercase phải thể hiện ràng buộc giữa các usecase trong hệ thống,
tuyệt đối không được liệt kê usecase
- Nên sử dụng abstract usecase với nhóm chức năng có liên quan. Không nên
sử dụng dạng abstract usecase chỉ có một usecase, không sử dụng dạng
abstract usecase có chứa thành phần abstract usecase
- Khi mô tả usecase nên chú ý tập trung chức năng, view là các thành phần
phụ trợ (có thể nói là extend) không phải là chức năng chính của hệ thống
- Cần phân biệt rõ usecase là chức năng, qui trình. Usecase không phải là
màn hình, hay các bước - step - trong quá trình xử lý
Ví dụ

PAGE \* MERGEFORMAT 1

PAGE \* MERGEFORMAT 1

Figure 2: System Overview Use Case

2.3 List of Use Case
<Đặc tả chi tiêt Use case theo từng role>

Ví dụ

2.3.1 Overview Use Case

Figure 3:  Overview Use Case

Ví dụ

2.3.1.1

 Register
Use Case Diagram

Figure 4: Register
Use Case Specification

PAGE \* MERGEFORMAT 1

GuideLine: Đây là giai đoạn lấy requirement nên các mô tả phải được diễn
đạt theo ngôn ngữ của khách hàng, không phải là nơi mô tả màn hình giao
diện khi ứng dụng đã hoàn tất. Ngoài ra, đây chính là nơi thể hiện rõ vai
trò lấy requirement với phương pháp ethnography - observate để chuẩn
bị thông tin cho thiết kế và thực hiện sản phẩm. Các nội dung trong phần
này chính là phần thông tin để hình thành nên các thực thể trong
conceptual diagram
USE CASE – 
Use Case No.
Đánh số UC
Use Case Version
Use Case Name
Tên UC
Author
Người thiết kế, hiện thực
Date
Ngày viết
Priority

2.0
Mức độ quan trọng
trong dự án. Core
flow thì đánh là
High và giảm dần
đến Normal

Actor:
- 
Summary:
- 
Goal:
- 
Triggers:
- 
Preconditions:
- 
- Ví dụ: để cancel một hóa đơn thì precondition là
o User phải là một customer
o Hóa đơn vẫn đang trong tình trạng chưa hết thời hạn hủy của hệ thống
là 3 ngày
Post Conditions:
- < Trạng thái sau khi tiến hành bắt buộc phải có 2 trạng thái cho success và fail.
Vì vậy khi ghi phải có đủ và phần fail bắt buộc xuất hiện trong exception
scenario>
- Success: Khi thành công thì tình trạng hệ thống thế nào đối với hệ thống
và đối với người dùng
- Fail: Khi có lỗi xảy ra thì hệ thống sẽ xử lý thế nào để đảm bảo usability
cho người dùng và toàn vẹn dữ liệu cho hệ thống
Main Success Scenario: 
Step
Actor Action
System Response
1
2
Alternative Scenario: 
No
Actor Action
System Response
1
Exceptions: Gồm các tình huống xử lý ngoại lệ cũng như xử lý các exception do
người dùng gây ra khi nhập liệu
No
Actor Action
System Response
Relationships: Mối quan hệ với các Use case khác nếu có trong quá trình xử lý, tuy
nhiên nó không phải là abstract usecase
Business Rules:
- Thành phần mô tả các yêu cầu về mặt nghiệp vụ của use case.
- Tất cả các giả định về nghiệp vụ nếu có phải được ghi vào
- Chú ý tới sự chuyển đổi về trạng thái của dữ liệu cũng phải được ghi tại đây
- Các định nghĩa cũng cần làm rõ (sản phẩm nổi bật, sản phẩm sắp có là sản
phẩm thế nào trong hệ thống)
- Các ràng buộc dữ liệu dưới hệ thống, các rule liên quan đến toàn vẹn dữ liệu
- Các qui trình, activities, quá trình chuyển đổi trạng thái của hệ thống

Ví dụ

USE CASE – WG01
Use Case No.
WG01
Use Case Version
Use Case Name
Login
Author
TrungDQ
Date
27/05/2015
Priority
Actor:
- Guest
Summary:
- This use case allows guest to log in the system.
Goal:
- Guest can log in the system.
Triggers:
- Guest sends the login command.
Preconditions:
- N/A
Post Conditions:

PAGE \* MERGEFORMAT 1

2.0

Normal

- Success: Guest login the system.
- Fail: Show error message.
Main Success Scenario:
Step
Actor Action
1
Guest goes to login view.

2
3

Guest inputs information.
Guest sends command to login
to system

Alternative Scenario:
Step
Actor Action
1
Guest enter wrong identity
information.
Exceptions:
Step
Actor Action
1

System Response
System requires identity information from
Guest:
- Email or customer code: free text input
- Password: free text input
Guest will login system with their specific
role
[Alternative 1]
[Exception 1]
System Response
Wrong identity information, System shows
error message.
System Response
System show message the "System is busy"
when the internet is lost

Relationships: N/A
Business Rules:
- Password are encrypted before being sent to server.
- After login to system, guest will be redirected to specific view based on their role on the
system: staff or customer.
o If role is “Customer”, the system will display to Customer view.
o If role is “Staff”, the system will display to Staff Dashboard view.

Ví dụ
 Create new contract request

Figure 5  Create new contract request

USE CASE – WG02
Use Case No.
Use Case Name
Author
Date
Actor:
- Guest

WG02
Use Case Version
Create new contract request
TrungDQ
27/05/2015
Priority

PAGE \* MERGEFORMAT 1

2.0

Normal

Summary:
- This use case allows guest to create new contract request.
Goal:
- Guest can create new contract request.
Triggers:
- Guest sends command to create contract request.
Preconditions:
- N/A
Post Conditions:
- Success: New account and new contract will be created for guest.
- Fail: Show error message.
Main Success Scenario:
Step
Actor Action
System Response
1
Guest goes to new
System requires information from guest:
contract view.
Personal information
- Name: free text input, required, length 3 – 80.
- Address: free text input, required, length 3 – 250.
- Email: free text input, required, length 3 – 250.
- Phone number: free text input, required, length 8 –
15.
- Personal ID: free text input, length 8 – 15.
Contract information (all information below are
required)
- Contract’s type: select one of the options.
- Start date: date time input, required.
- Contract term: text
- Contract’s fee: text
Vehicle information
- Plate: free text input, required, length 4 – 15.
- Brand: free text input, required, length 2 – 20.
- Model code: free text input, length 2 – 20.
- Vehicle type: free text input, length 2 – 20.
- Color: free text input, length 2 – 20.
- Engine: free text input, required, length 2 – 20.
- Chassis: free text input, required, length 2 – 20.
- Capacity: free text input, required, length 2 – 20.
- Year of manufacture: number text input, value
from 1900 to current year.
- Weight: free text input, value from 1 – 1000, unit:
kilogram
- Seat capacity: free text input, value from 1 – 100.
Security question
- Answer: free text input, required, length 1 10
2
Guest inputs
information.
3
Guest sends command System validate information, display contract details
to create new contract and request for confirmation.
request.
[Exception 1, 2, 3]
4
Guest sends command Add new account and new contract information to the
to create new contract system. Show successful message and ask user to
request.
process payment.
5

Guest sends command

Display new view let user select one of following

PAGE \* MERGEFORMAT 1

to process payment

6

7

If user chooses PayPal
gateway and sends
confirm command.
[Alternative 1]
User process the
PayPal payment

payment gateways:
- PayPal payment gateway.
- Direct payment.
And show guest the fee:
Contract’s fee: text.
Forward to PayPal payment view to process the
payment.

If payment succeed:
Show message created successful.
[Exception 4]

Alternative Scenario:
No
Actor Action
1
If user chooses direct payment
method
Exceptions:
No
Actor Action
1
Guest sends command to create
new contract request
2
Guest’s email is existed in the
system
3
Guest’s vehicle plate is existed
in the system
4
If payment failed

System Response
Show company address map.

System Response
System shows error message to ask user
input missing required fields.
Show message to notify guest that their email
is existed in the system.
Show message to notify guest that their
vehicle is existed in the system.
Show message to notify user that payment
failed and the renew request has been
aborted.

Relationships: Payment
Business Rules:
- New customer account and new contract will be created in the system with inputted
information.
- The initial status of contract will be set to “Pending”.
- When customer completed payment process:
+ if the contract’s start date has come, contract’s status would change from “Pending”
to “No Card”.
+ If start date is not come yet, the contract status is not changed.
- Staff will receive a notification about new contract request, they verify contract’s
information and issue a card for this contract, in this case, contract’s status would
change from “No Card” to “Ready”.
- System must ensure has no duplicate customer or vehicle.
- An email contains customer code and password will be sent to user, user can use this
information to login to the system later.
- Start date must not be earlier than the current date.
- Contract term is specified by the system.
- Contract types are loaded from system, contract type can be managed by system
administrator.
- Contract price would be calculated from contract type and contract term.
Table 6 Use case WG02 -  Create new contract request

Ví dụ

PAGE \* MERGEFORMAT 1

 Cancel contract

Figure 6  Cancel contract

USE CASE – WC03
Use Case No.
WC03
2.0
Use Case Version
Use Case Name
Cancel contract
Author
TriPQM
Date
27/05/2015
High
Priority
Actor:
- Customer.
Summary:
- This use case helps user cancel their contract.
Goal:
- Customer can cancel the contract.
Triggers:
- Customer sends cancel contract request.
Preconditions:
- User must login into the system with role Customer.
- User’s contract has not expired.
- Customer's contract status must not be “Expired”, "Cancelled" or “Request cancel”.
Post Conditions:
- Success: Send to the staff the cancel contract request.
- Fail: Show error message.
Main Success Scenario:
Step
Actor Action
System Response
1
User goes to cancel contract
Display new view require user input some
view.
information:
- Reason to cancel the contract: can be
optional selected from these values:
o “Xe cơ giới bị thu hồi đăng ký và biển số
theo quy định của pháp luật”
o “Xe cơ giới hết niên hạn sử dụng theo
quy định của pháp luật”
o “Xe cơ giới bị mất được cơ quan công an
xác nhận”
o “Xe cơ giới hỏng không sử dụng được
hoặc bị phá huỷ do tai nạn giao thông
được cơ quan công an xác nhận”
o Other reason: free text input, required,
length 1-250.
2
User inputs information
3
User sends cancel contract
- Change contract status.
request command.
- Send request to the Staff.
[Exception 1]
Alternative Scenario: N/A

PAGE \* MERGEFORMAT 1

Exceptions:
No
1

Actor Action
System Response
If user didn't check any reason
Show message to notify user that they have to
to cancel contract
choose the reason for cancel contract.
Relationships: N/A
Business Rules:
- Cancel contract request will be sent to the system with inputted information.
- System update status of the contract from “Pending”, “No Card” or “Ready” to
“Request cancel”.
- A notification will be sent to staff after the process is completed.
Table 7 Use case WC03 -  Cancel contract

Ví dụ

System
Auto parse
System

Figure 7:  Auto parse use case diagram
Use Case Specification
USE CASE – ARB08
ARB08
2.0
Use Case No.
Use Case Version
Auto parse
Use Case Name
Pham Nguyen Bich Hien
Author
30/05/2014
Normal
Date
Priority
Actor:
- System.
Summary:
- System can parse resource automatically from many websites at specified time.
Goal:
- Get resource from many websites.
Triggers:
- The time hits configured time.
Preconditions:
- Parse time has been configured.
Post Conditions:
- Success: New data is inserted to storage. Log file is generated.
- Fail: Nothing is changed in the storage. Log file is generated.
Main Success Scenario:
Step
Actor Action
System Response
1
Server checks the current time.
If it hits configured time, parse
process starts.
 Send request to the parsed link.
 Fetch data from the response based on
the inputted XPaths.

PAGE \* MERGEFORMAT 1

 Validate data [Exception 1].
 If data is valid, insert to storage
[Alternative 1].
 Generate log file.
Alternative Scenario:
Step
Actor Action
1
Server checks the current time. If
it hits configured time, parse
process starts.

System Response

 If fetched link resource is already in the
storage, update its information.
 Generate log file.
Exceptions:
No
Actor Action
System Response
1
Data is invalid.
 Generate log file.
Relationships: N/A
Business Rules:
- If link resource exists in storage, do nothing.
- If link resource is not active, do nothing.
- Log file structure:
ARB LOG FILE
Tạo file lúc: {Created date}, {Created time}
STT Link

Thời gian
parse

Dạng dữ
liệu

Tổng số sách
nhận được

Insert thành
công

Insert thất
bại

Tổng thời gian parse dạng {Data type}: {Elapsed time}
Tổng thời gian parse: {Total elapsed time}
Tổng sản phẩm parse được: {Total parsed books}
Table 8: Auto parse use case specification table

3. Software System Attribute



3.1 Usability
3.2 Reliability
3.3 Availability
3.4 Security
3.5 Maintainability

PAGE \* MERGEFORMAT 1

3.6 Portability
3.7 Performance
…..

4. Conceptual Diagram

Chú ý
 Chỉ sử dụng một tập kí hiệu và cần reference đến địa chỉ mô tả tập kí hiệu
để sử dụng cho chính xác
 Các Diagram cần lớn rõ ràng, phải dàn trang cho phù hợp và nên dùng
trang A3 để in
 Các thành phần trong diagram phải được thể hiện thông qua dictionary

Data Dictionary <Đặc tả các thực thể có trong hình>
Entity Data dictionary: describe content of all entities
Entity Name

Description

Ví dụ

Figure 8 Conceptual diagram

PAGE \* MERGEFORMAT 1

Data Dictionary
Entity Data dictionary: describe all content of all entities
Entity Name
User
Customer
Contract
Card
CardInstance
Payment
Staff
Compensation
Punishment
Accident
ContractType
NewCardRequest
Notification

Description
Abstract entity describes a user in system
Contain the customer information.
Contain the contract information.
Contain the card information
Represent a card assigned to a contract
Contain the payment information.
Contain the staff information.
Contain the compensation information.
Contain the punishment information.
Contain the accident information.
Contain the contract type information.
Contain the new card request information.
Contain the notification information
Table 9 Conceptual Diagram Data Dictionary

PAGE \* MERGEFORMAT 1

D. Report No. 4 Software Design Description
1. Design Overview
-

-

-


This document describes the technical and user interface design of MSSC System.
It includes the architectural design, the detailed design of common functions and
business functions and the design of database model.
The architectural design describes the overall architecture of the system and the
architecture of each main component and subsystem.
The detailed design describes static and dynamic structure for each component and
functions. It includes class diagrams, class explanations and sequence diagrams
for each use cases.
The database design describes the relationships between entities and details of
each entity.
Document overview:
 Section 2: gives an overall description of the system architecture design.
 Section 3: gives component diagrams that describe the connection and
integration of the system.
 Section 4: gives the detail design description which includes class diagram,
class explanation, and sequence diagram to details the application functions.
 Section 5: describe screens design.
 Section 6: describe a fully attributed ERD.
 Section 7: describe algorithms.

PAGE \* MERGEFORMAT 1

2. System Architectural Design




Ví dụ

Figure 9 System architecture design

This diagram is referenced and modified from an original concept from: Chapter 6
Architecture Design, SOFTWARE ENGINEERING 9th Edition, by Ian Sommerville.

2.1 Web application architecture description


Ví dụ
In Web Application, the system is developed under J2EE MVC architecture style. We choose this
architecture for Web application because of following advantages:


Web app contains a Web service (public API for mobile app), with MVC architecture, we
can separate business code with Controller and View, so we can use the business code in
web service without repeat the code.
 ...
This project follows MVC architecture with following components:



Servlet (Controller) is the parts of the application that acts like event handler to handles
user interaction. Typically, controller read data from a request and calls appropriate
Business’s method then selects view to return to user.
...

2.2 ...

PAGE \* MERGEFORMAT 1

3. Component Diagram

Ghi chú: Xem lại bộ quy ước kí hiệu của UML 2.0 trước khi vẽ các mối quan hệ
cũng như hiểu rõ thiết kế để vẽ chính xác. Nếu tool không phù hợp thì nhóm
nên dùng Paint để vẽ

Component dictionary: describe component
Component Name

Description

Ví dụ

Figure 10 Component Diagram

Component Dictionary: Describes components
Web Application

Web application package: View, Controller

Mobile Application

Mobile application package

PayPal

Handle payment process with PayPal API

Payment Component

Component to handle payment process

Web Service

Provide API for mobile applications to interact with the
system.

Staff Component

Component to handle staff activities in the system

Customer Component

Component to handle customer activities in the system

Public Component

Component to handle guest activities in the system

Admin Component

Component to handle admin activities in the system

Schedule Component

Component to handle scheduler in the system

Business Objects
Data Access Objects

Common objects to handle domain business operations for
each components
Component to handle interaction between the system and
database
Table 10 Component Dictionary

PAGE \* MERGEFORMAT 1

4. Detailed Description
4.1 Class Diagram


Class dictionary: describe Class
Class Name

Description

Ví dụ

Figure 11 Class Diagram

PAGE \* MERGEFORMAT 1

Class Name

PaymentEntity
CardEntity
CardInstanceEntity
CustomerEntity
ContractEntity
StaffEntity
CompensationEntity
PunishmentEntity
AccidentEntity
ContractTypeEntity
NewCardRequestEntity
CardAccessLogEntity

NotificationEntity

NotificationReadEntity

Class dictionary: describe Class
Mapping column
Description
with Conceptual
diagram
Payment
Contain the payment information.
Card
Contain the card information.
CardInstance
Contain the card instance information
Customer
Contain the customer information.
Contract
Contain the contract information.
Staff
Contain the staff information.
Compensation
Contain the compensation information.
Punishment
Contain the punishment information.
Accident
Contain the accident information.
ContractType
Contain the contract type information.
NewCardRequest
Contain the new card request information.
N/A
Not exist in conceptual diagram. But needed
in class diagram to contain the card access
log information.
N/A
Not exist in conceptual diagram. But needed
in class diagram to contain the notification
information.
N/A
Not exist in conceptual diagram. But needed
in class diagram to know what notifications
is read.
Table 11 Class dictionary

4.2 Class Diagram Explanation

Ví dụ

4.2.1 Role
Attribute
Attribute
RoleID
Name

Type
int
string

Visibility
Private
Private

Description
Unique identifier of a role
Role name

Method
Method
Getter
Setter

Return type
Attribute type
Void

Visibility
Public
Public

Description
Get attribute value
Set value of attribute

4.2.2 ...

4.3 Interaction Diagram
4.3.x Tên Interaction Diagram


PAGE \* MERGEFORMAT 1

Summary: .
Ví dụ

4.3.1.1

Create new contract

Summary: this diagram show process of staff creates new contract

Figure 12 Sequence diagram -  Create new contract

4.3.1.2

 View Friend List

Summary: This diagram shows how member views all contacts that
include MSSC contacts and android cell phone contacts.

PAGE \* MERGEFORMAT 1

Figure 13:  View Friend List

5. Interface
5.1 Component interface


Nội dung được đặc tả theo dạng bảng như sau
Signature
Tên hàm

Description
Mô tả mục
đích

Input
Tham số
truyền

Output
Format

Output
Kết xuất khi
hàm xử lý
xong

Kiểu dữ
liệu

Exception
Xử lý lỗi

Ví dụ

Web Service Interface

Signature
public ResponseObject
getCheckConnection(R r)

Description
Check
server
status

Input
Request object r

Output
Json Boolean
the status of
server

PAGE \* MERGEFORMAT 1

Output
Format
Boolean

Exception
JsonProcessi
ngException

...

5.2User Interface Design
.
Lưu ý phải đánh số đặc tả các control trên giao diện cùng với các
thành phần trong ràng buộc
Ví dụ

5.3Guest Interface Design
5.3.1 Login

Figure 14: Login

Fields
No
1

Field
Name
Username

2

Password

Description
Fill user
name
Fill
password

Read
only
No

Mandatory

Data
Type
String

Length

Yes

Control
Type
Textbox

No

Yes

Password

String

N/A

N/A

Buttons/Hyperlinks
No Function
Description
Validation
Outcome
3
Signin
Log-in into the system N/A
Transfer to home page

6. Database Design
6.1 Entity relationship diagram (ERD)


PAGE \* MERGEFORMAT 1

6.2 Data Dictionary

Entity Data dictionary: describe content of all entities
Entity Name

Description

Entity name
Tên


Attributes
Description
Domain
Thuộc tính 1 {PK} Mô tả
Kiểu dữ liệu
...
...
...

Null
Y/N
...

Table 12: Detail Data Dictionary

* Business integrity constraint:


7. Algorithms

Chú ý
 Không nhất thiết phải là thuật toán nổi tiếng mà có thể là cách tổ chức dữ
liệu cũng như giải thuật do nhóm đang thực hiện ở bên trong hệ thống: ghi
rõ bản chất, phân tích về độ phức tạp, nếu tham khảo phải ghi rõ nguồn
 Cách giải quyết hay cách áp dụng các qui trình nghiệp vụ hay cách chuyển
đổi bài toán khi làm bằng tay - chưa áp dụng máy tính và chương trình để
cho thấy việc áp dụng giải bài toán hay giải quyết vấn đề rồi chuyển đổi
cách đó sang thành chương trình máy tính
Ví dụ

7.1Document Breakdown
7.1.1 Definition
Document breakdown is the way to break the document into many small parts.
Each part has it own title and contents of it. And the final data has tree
structure.

7.1.2 Define Problem
All content of document is quite difficute for manage so we must re-construc
structure of document for using.

7.1.3 Solution
To solve this problem, we should follow these steps:
- Convert (save) document DOCX file as html type by using Microsoft
Word save as Web Filtered.
- Import both html file and directory that incluses all pictures of
document.
- Using xpath to get data of html file as we need, include h1, h2, h3,…,
image, text content,..
- Save them with structure as below:
-TitleA: contentA

PAGE \* MERGEFORMAT 1

---TitleA1: contentA1
------TitleA1.1: contentA1.1
------TitleA1.2: contentA1.2
---TitleA2: contentA2

7.1.4 Complexity
-

In total, the complexity of this algorithm is

7.1.5 Flowchart

PAGE \* MERGEFORMAT 1

PAGE \* MERGEFORMAT 1

Figure 15: Breakdown document flow chart

7.2 String Comparison
7.2.1

Define Problem

Given two strings. Calculate their matching percent.

7.2.2
-

-

Robustness to changes of word order: two strings which contain the
same words, but in a different order, should be recognised as being
similar.
Language independence: the algorithm should work not only in English,
but in many different languages.

7.2.3
-

Requirement

Solution

If a string contains many words, break it into a list of words.
For each word, we find out how many adjacent character pairs are
contained in it.
Create a function pairs(s) which returns a list of adjacent character
pairs of string s.
Then, we use below formula to calculate matching percent.

7.2.4

Example

Calculate the matching percent of 2 strings: France and French.
- Upper case 2 strings:
+ France FRANCE.
+ French FRENCH.
- Break string into list of adjacent character pairs:
+ FRANCE
+ FRENCH
- Calculate its matching percent.

PAGE \* MERGEFORMAT 1

E. System Implementation & Test
1. Introduction
1.1 Overview

Ví dụ
This section provides in detail all necessary information about implementation information and
testing procedure of MSSC includes test plans, test cases, test result and risks estimations.

1.2 Test Approach


2. Database Relationship Diagram
2.1 Physical Diagram


2.2 Data Dictionary

Data dictionary: describe content of all tables
Table Name Description
Tên
Explanation


Entity name
Tên

Attributes
Description
Thuộc tính 1 {PK} Mô tả
...
...
Table 13: Attribute Data Dictionary

Domain
Kiểu dữ liệu
...

3. Performance Measures


Ví dụ

3.1 Clustering Performance


Clustering is performed by running K Mean Algorithm which has complexity
of : O(n * k * I * d)
o n : number of points
o k : number of cluster
o I : number of iteration
o d : number of attributes (3)

PAGE \* MERGEFORMAT 1

Null
Y/N
...

Clustering take almost the time of process that we can ignore the time needed
to load data from database, digitalize data.
The speed of clustering will vary and increase dramatically when n increase.
The purpose of this project is not about optimizing K-Mean Algorithm so it is
accepted to let the process run till it completes. Moreover, the clustering is
designed to run by staff, wait time is acceptable.

4. Test Plan

<Đưa ra kế hoạch test>

Ví dụ
The purpose of this section is to verify and ensure that MSSC meets its design specification and
other requirements from user. The following part will describe which features to be tested and
which will not.

4.1 Features to be tested



4.2 Features not to be tested


5. System Testing Test Case

Ví dụ

PAGE \* MERGEFORMAT 1

Figure 16: Guest, Member Core Flow

PAGE \* MERGEFORMAT 1

MSSC - Introduction

5.1 Guest Test Case
5.1.1 Search Event

ID

Test Case
Description

Test Case Procedure

Expected output

Inter-test Case
Dependence

Result

Test Date

Note

MSSC - Introduction

F. Software User’s Manual
1. Installation Guide
1.1 Setting up environment at server side
The following software must be installed into the server machine:

1.1.1 Hardware requirements


1.1.2 Software requirements


1.2 Deployment at server side


1.2.1 Prepare deployment package
1.2.2 Configure Server before deploy
1.2.3 Deploy web application on server

1.3 Setting up the environment at client side
1.3.1 Setting up for computer


2. User Guide


G. Appendix



47



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 47
Language                        : en-US
Author                          : KhoaTNDSE60680
Creator                         : Microsoft® Office Word 2007
Create Date                     : 2015:09:03 17:40:02
Modify Date                     : 2015:09:03 17:40:02
Producer                        : Microsoft® Office Word 2007
EXIF Metadata provided by EXIF.tools

Navigation menu