Luận văn
Xây dựng ứng dụng Từ điển
trên Pocket PC

KHOA CNTT – ĐH KHTN

1

Lời cám ơn

Lời đầu tiên, chúng con xin gửi đến cha mẹ lòng biết ơn, sự tôn kính của chúng
con. Cha mẹ đã sinh dưỡng và không ngại khó khăn tạo mọi điều kiện tốt nhất cho
chúng con có được ngày hôm nay.
Chúng em xin chân thành cám ơn thầy Trần Đan Thư, thầy Nguyễn Trọng Tài
đã tận tâm hướng dẫn chúng em, giúp đỡ chúng em hoàn thành đề tài này.
Chúng em cũng xin cám ơn các anh chị làm việc trong phòng phát triển phần
mềm Trung tâm Tin học trường Đại học Khoa học Tự nhiên đã sẵn sàng giúp đỡ chúng
em, cung cấp các thông tin cho chúng em trong quá trình khảo sát. Chúng em cũng xin
cám ơn các thầy cô, cán bộ giảng viên trẻ đã nhiệt tình đóng góp những kinh nghiệm, ý
kiến quý báu cho chúng em.
Chúng em xin gửi lời cám ơn tất cả các quý thầy cô đã giảng dạy, cung cấp cho
chúng em vốn kiến thức quý báu suốt những năm học vừa qua.

kinh nghiệm trong kinh doanh, các công ty tin học Việt Nam nhận thức được rằng quy
trình sản xuất phần mềm của chính công ty họ cần được nâng cấp với mục tiêu đầu tiên
là nâng cao chất lượng, gia tăng tính chuyên nghiệp trong sản xuất phần mềm.
Một điều không thể tranh cãi , quy trình đóng một vai trò rất quan trọng trong
việc sản xuất phần mềm. Hiện nay có rất nhiều quy trình sản xuất phần mềm như Quy
trình RUP, Quy trình xoắc ốc, Quy trình thác nước , nhưng điều cốt lõi nhất là ứng
dụng những quy trình đó như thế nào và ứng dụng như vậy sẽ đạt được những thuận lợi
gì, quá trình sản xuất phần mềm có tốt hơn không, chất lượng phần mềm có được nâng
cao hay không. Trong một quy trình sản xuất phần mềm, ngoài việc thành lập các
chuẩn coding, phân công sắp xếp các công việc cho các thành viên trong tổ chức, một
yếu tố rất quan trọng là việc quản lý các tài liệu bao gồm các bản đặc tả yêu cầu, bản
phân tích thiết kế chương trình, chương trình nguồn, các bản báo cáo kiểm thử và vô số
những tài liệu không tên khác.
Trong bối cảnh đó, chúng em đã thực hiện đề tài “Tìm hiểu về quản lý yêu cầu
và kiểm thử tại Phòng phát triển phần mềm Trung Tâm Tin Học trường
ĐHKHTN_Xây dựng phần mềm hỗ trợ” nhằm có thể hiểu rõ hơn việc quản lý yêu cầu
và kiểm thử, những mục tiêu, thuận lợi mà hai tiến trình này đem lại.
Đề tài này có thể được xem như một phần trong việc quản lý cấu hình, trong đó
chú trọng ở hai giai đoạn khảo sát và kiểm thử. Luận văn của chúng em được trình bày
với tám chương chính, bao gồm :
KHOA CNTT – ĐH KHTN

1.3 Hiện trạng phát triển phần mềm tại T3H 10
1.4 Đánh giá hiện trạng 19
1.4.1 Quản lý yêu cầu : 19
1.4.2 Quản lý kiểm thử : 19
1.5 Mục tiêu đề tài 20
Chương 2 Tổng quan về SQA và các công việc quản lý yêu cầu, quản lý kiểm thử 21
2.1 Vai trò của việc quản lý chất lượng phần mềm 21
2.2 Tại sao cần quản lý chất lượng ? 24
2.3 Tổng quan về quản lý yêu cầu 25
2.3.1 Quản lý yêu cầu là gì ? 25
2.3.2 Các thông tin cần quản lý trong quản lý yêu cầu 25
2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI 27
2.4 Tổng quan về quản lý kiểm thử 28
2.4.1 Mục tiêu của quản lý kiểm thử 28
2.4.2 Các thông tin cần quản lý trong quản lý kiểm thử 29
2.4.3 Giới thiệu tiến trình Verification (VER) trong CMMI 30
Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay32
3.1 Công cụ hỗ trợ quản lý yêu cầu 32
3.1.1 Giới thiệu : 32
3.1.2 Định nghĩa công cụ quản lý yêu cầu 33
3.1.3 Các loại công cụ 33
3.1.4 Tại sao phải sử dụng các công cụ quản lý yêu cầu : 34
3.1.5 Kiến trúc chức năng : 35
3.1.6 So sánh với các phần mềm có chức năng tương tự : 37
3.1.7 Đánh giá các công cụ quản lý yêu cầu 38
3.2 Công cụ kiểm thử : 38
3.2.1 Các loại công cụ kiểm thử : 38
3.2.2 Một số công cụ quản lý kiểm thử : 41
Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements
and Testing Management) 44

Phụ lục A. Mô tả dữ liệu 95
Phụ lục B. RM Tool Survey Summary [INCOSE] 98

KHOA CNTT – ĐH KHTN

6

Danh sách các hình Hình 1-1 Mô hình phát triển phần mềm theo quy trình thác nước tại T3H 11
Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm 14
Hình 1-3 Mô hình quản lý yêu cầu tại T3H 16
Hình 1-4 Mô hình kiểm thử tại T3H 18
Hình 2-1 Các hoạt động trong CM 22
Hình 2-2 Tổng quan về CM 23
Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI) 27
Hình 5-1 Mô hình tiến trình quản lý yêu cầu cho hệ thống mới 45
Hình 5-2 Mô hình quản lý kiểm thử cho hệ thống mới 48
Hình 5-3 Mô hình usecase 51
Hình 5-4 Kiến trúc hệ thống 73
Hình 5-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử 75
Hình 5-6 Các lớp xử lý yêu cầu 76
Hình 5-7 Các lớp xử lý kiểm thử 76

hệ thống máy tính.[PGSQM]

Chất lượng _Quality
Việc thỏa mãn một sản phẩm theo đúng sự
mong đợi của khách hàng, dựa vào những
yêu cầu cho sản phẩm.[PGSQM]

Việc đảm bảo chất lượng _Quality
Assurance hay Kiểm soát chất lượng _
Quality Control
Là một tập các hành động đã được dự
định trước đó nhằm dò tìm, dẫn chứng qua
các tài liệu, phân tích, và hiệu chỉnh các
lỗi của sản phẩm cũng như quản lý các
thay đổi của sản phẩm.[PGSQM]
Quản lý chất lượng _ Quality
Management
Là việc ủy nhiệm, xúc tiến nhà sản xuất
nhận ra, chấp thuận các cải tiến cho tiến
trình sản xuất sản phẩm.[PGSQM]

SQA
Software Quality Assurance
SQS
Software Quality System
CM
Configuration management
T3H
Phòng phát triển phần mềm Trung tâm
Tin học trường Đại học Khoa học Khoa

KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

9

Chương 1 Mở đầu
1.1 Khái quát vai trò quy trình phát triển phần mềm
Thưở ban đầu của ngành công nghiệp máy tính nói chung và công nghệ phần
mềm nói riêng, việc phát triển phần mềm được xem như một quá trình “viết và sửa”
(code and fix), không có bất kỳ một kế hoạch nào trước đó. Quá trình này thành công
cho đến khi các chương trình phần mềm bắt đầu có quy mô lớn hơn, độ phức tạp cao
hơn, cần có sự hợp tác của nhiều người hơn, do đó các phương pháp phát triển phần
mềm hay quy trình phần mềm ra đời.Thực tế cho thấy, hầu hết các dự án thất bại do
các nguyên nhân sau
1
:
· Hiểu không đúng yêu cầu người dùng
· Không thể thích ứng với các thay đổi về yêu cầu đối với hệ thống.
· Các module không khớp với nhau.
· Phần mềm khó bảo trì và nâng cấp, mở rộng.
· Phát hiện trễ các lỗ hổng của dự án.
· Chất lượng phần mềm kém.
· Hiệu năng của phần mềm thấp.
· Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở
đâu, tại sao phải thay đổi.
· Quá trình build-and-release không đáng tin cậy.

làm ba loại, đó là những nhân tố có thể tìm thấy trong đặc tả yêu cầu ví dụ như tính
linh động (portability), là “cutural factors” ví dụ như tính hiệu dụng (usability), và
những nhân tố mà người lập trình sẽ chú trọng nhưng người dùng thì không, đơn cử là
tính tái sử dụng (reusability). Để một sản phẩm đặt ra đạt được những nhân tố chất
lượng này không phải là một việc dễ dàng, vì vậy, việc quản lý chất lượng phần mềm
là một công việc không thể tránh khỏi trong công nghệ phần mềm.
1.3 Hiện trạng phát triển phần mềm tại T3H
T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau :
· Khảo sát hiện trạng – xác định yêu cầu
· Lập giải pháp khả thi
· Phân tích
· Thiết kế
· Coding
· Kiểm thử
· Triển khai và bảo trì
Quy trình được minh họa qua sơ đồ

KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

11

NV quản lý đề

Triển khai
Hoàn chỉnh sản
phẩm
Quản lý cấu hình
NV phân tích _
thiết kế

Hình 1-1 Mơ hình phát triển phần mềm theo quy trình thác nước tại T3H

KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

12MÔ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
Gđoạn
Lập giải pháp khả thi Khảo sát – phân tích Thiết kế phần mềm Xây dựng phần mềm Kiểm tra và thử nghiệm nội
bộ
Tài liệu
đầu vào

Tài liệu giải pháp khả thi Tài liệu khảo sát phân tích - Tài liệu khảo sát phân tích

2. Mô tả và phân tích hiện trạng (chi tiết
hơn Giải pháp khả thi) :
- Quy trình nghiệp vụ
- Sơ đồ tổ chức xử lý
- Mối liên quan với hệ thống khác
3. Phân tích sơ bộ
- Mô hình dữ liệu sơ bộ
- Yêu cầu nghiệp vụ
- Yêu cầu hệ thống
- Yêu cầu giao diện
- Yêu cầu sao lưu
- Yêu cầu bảo mật
- Yêu cầu đường truyền (gửi/nhận) dữ
liệu
- Yêu cầu về chuyển đổi, cập nhật dữ
liệu cũ
4. Tập hợp các tài liệu đã thu thập từ quá
trình khảo sát
1. Thiết kế kiến trúc phần mềm
2. Thiết kế dữ liệu mức vật lý.
3. Thiết kế chiến lược:
- Các quy ước chung
- Cơ chế phát sinh khóa
- Kiểm tra RBTV
- Xử lý và thông báo lỗi
- Sao lưu và phục hồi dữ liệu
- Bảo mật
- Truyền (gửi/nhận) dữ liệu
4. Thiết kế chức năng:
- Sơ đồ màn hình

Mô tả
công việc
chung
1. Lập kế họach và theo dõi tiến độ
2. Quản lý cấu hình
3. Xem xét và duyệt kết quả công việc
4. Tập huấn, chuyển giao kết quả công việc
Kết quả
đầu ra
-Tài liệu giải pháp khả
thi
-Hợp đồng đã ký
Tài liệu khảo sát phân tích - Tài liệu thiết kế phần mềm
- Prototype chương trình
- Tài liệu Xây dựng phần mềm
- Script phát sinh CSDL
- Chương trình
-Tài liệu Kết quả
-Kiểm tra chương trình
-Tài liệu hướng dẫn
-Chương trình đã kiểm
tra

KHOA CNTT – ĐH KHTN

phần mềm, quản lý toàn bộ các thành viên, chịu trách nhiệm phân công, lên kế
hoạch, theo dõi tiến độ thực hiện.
- Trưởng dự án : chịu trách nhiệm xem xét duyệt lại các tài liệu, kiểm soát các
tiến trình, đảm bảo các tiến trình được thực hiện đúng đắn và đúng tiến độ.

KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

14

- NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài liệu
có liên quan đến đề án đang thực hiện như : quản lý các thành phần của từng
phiên bản có trong đề án, tạo các phiên bản test và phiên bản giao cho khách
hàng, đóng gói sản phẩm
- NV Quản lý kiểm thử : chịu trách nhiệm về việc lên kế hoạch kiểm thử, cho
từng giai đoạn của đề án, đánh giá kết quả của việc kiểm thử. Và cùng với nhân
viên quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử
trong trường hợp chương trình vẫn còn lỗi nhưng những lỗi đó khơng nghiêm
trọng, có thể chấp nhận để giao cho khách hàng vì thời giao đã gần kề
2/25/2004
Subtitle
Sơ đồ các vai trò trong một đề án
Wednesday, February 25, 2004KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

15

· Quản lý yêu cầu
- Khách hàng đặt hàng, T3H đồng ý nhận đơn đặt hàng, chuẩn bị tiến
hành khảo sát
- Quản lý dự án lập kế hoạch ban đầu, đặc tả các nhiệm vụ, phân công.
Bảng kế hoạch được in giấy, phân phát cho nhân viên liên quan.
- Khảo sát viên tiến hành khảo sát, sau mỗi lần khảo sát, một bản mô tả
hiện trạng, yêu cầu khách hàng được thiết lập. Đến thời hạn, nhân
viên này đưa bản báo cáo cuối cùng cho Quản lý dự án. Khảo sát viên
hoàn toàn tự quản lý các tài liệu này và chỉ giao cho Quản lý dự án
bản cuối cùng.
- Khi tiến hành phân tích thiết kế, phân tích viên hay nhân viên thiết kế
sẽ làm việc trên tài liệu mà Quản lý dự án đưa. Nếu có thay đổi, nhân
viên đó sẽ thay đổi trên tài liệu này, ghi nhận và đến thời hạn sẽ giao
lại cho Quản lý dự án.
- Cuối giai đoạn này, một bản đặc tả yêu cầu và phân tích thiết kế được
đưa ra.
- Thông thường, khảo sát viên, nhân viên phân tích thiết kế là một và là

Tiến hảnh khảo
sát
Đưa ra các yêu
cầu
Khách hàng chấp
thuận bản yêu cầu
Kết thúc khảo sát
Bảng yêu cầu
(tự quản lý thông
tin)
Y
N
Y
N
Tài liệu đặc tả yêu
cầu cuối cùng
Toản bộ các tiến trình được thực hiện bằng tay. Các tài liệu được phát sinh trong giai đoạn này do người
phụ trách tự quản lý. Chỉ có bản yêu cầu cuối cùng được gửii cho các thành viên phát triển dự án

Hình 1-3 Mô hình quản lý yêu cầu tại T3H

KHOA CNTT – ĐH KHTN

Chương 1 Mở đầu

KHOA CNTT – ĐH KHTN

Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H

19

1.4 Đánh giá hiện trạng
1.4.1 Quản lý yêu cầu :
· Hiện tại T3H làm phần mềm có quy trình, các nhân viên đều nắm được
nhưng việc thủ tục hóa từng quy trình không có, kết quả là không có một
mẫu biểu chuẩn ghi nhận lại nên thông tin có thể không nhất quán.
· Khi các yêu cầu thay đổi trong quá trình thực hiện đề án, nhân viên không
nhất thiết phải ghi lại thông tin thay đổi nên có thể họ sẽ quên một số thông
tin, điều này có thể gây ra sự bất đồng bộ trong việc thực hiện phần mềm ở
những bộ phận khác nhau.
· Đối với một công ty nhỏ như T3H chỉ gồm khoảng trên dưới 30 nhân viên thì
việc trao đổi thông tin bằng miệng như hiện nay rất dễ dàng. Khi có một
vướng mắc nào đó họ có thể hỏi ngay tại đó để làm rõ vấn đề. Nhưng đặt
trường hợp PPTPM mở rộng, phát triền hơn thì với việc quản lý như hiện
nay sẽ rất khó khăn.
· Khi yêu cầu thay đổi, yêu cầu mới được ghi chồng lên các yêu cầu cũ mà
không có sự ghi nhận rõ ràng ( người sửa, ngày sửa, nguyên nhân,…) do đó
không lưu vết được các yêu cầu, gây ra khó khăn khi cần xem xét lại tài liệu
hoặc truy cứu trách nhiệm khi yêu cầu sai.

được phát hiện rồi, sửa rồi, nhưng phiên bản cuối cùng lại là phiên bản cũ, có
lỗi.
· Từ việc chuyển giao các test case đến người lập trình viên để cập nhật kết
quả đến việc xem xét lại các testcase, cho đến việc kiểm và sữa chữa lỗi trải
qua nhiều giai đoạn, do đó các hồ sơ dễ bị thất lạc và không đúng phiên bản
hiện hành.
1.5 Mục tiêu đề tài
Tìm hiểu về việc quản lý yêu cầu và quản lý kiểm thử trong quá trình phát
triển phần mềm. Ứng dụng xây dựng phần mềm hỗ trợ việc quản lý yêu cầu và kiểm
thử tại T3H
· Tìm hiểu công việc quản lý yêu cầu và quản lý kiểm thử nhằm bảo đảm
chất lượng phần mềm. Trong đó, chú trọng các thông tin cần phải quản lý
trong hai tiến trình này.
· Ứng dụng những kiến thức đó, xây dựng chương trình nhằm cải tiến và
hỗ trợ công việc quản lý yêu cầu và quản lý kiểm thử tại Phòng phát triển
phần mềm, Trung tâm Tin học trường Đại học Khoa học Tự nhiên.
KHOA CNTT – ĐH KHTN

Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử

21
KHOA CNTT – ĐH KHTN

Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử

22

· Defect analysing : hầu hết các tổ chức dùng thuật ngữ chất lượng
(quality) để ngụ ý không có hoặc có ít lỗi. Một số khác cho rằng đó là chỉ
việc phần mềm thỏa mong đợi của người dùng hay khách hàng. Ở đây, cả
hai quan niệm đó đều đúng. Bất cứ lúc nào, khi phần mềm không thể hiện
được như mong đợi của người dùng, lúc đó xem như một lỗi đã được bắt.
Đây có thể là trường hợp lỗi trong code, thiếu yêu cầu người dùng hay chỉ
là thiếu một hàm. Khi phát hiện ra một lỗi, công việc đòi hỏi cần thực
hiện là sửa lại cho nó đúng. Việc phân tích lỗi được thực hiện trên tất cả
các lỗi nhằm khắc phục các thiếu sót hiện tại và giảm thiểu số lượng lỗi
trong tương lai.
· Configuration management (CM) : CM đảm bảo tại bất kỳ thời điểm nào,
tình trạng của phần mềm đều được xác định rõ và có thể tái cấu trúc lại.
CM bao gồm ba yếu tố cơ bản : định danh cấu hình (configuration
identification CID), kiểm soát cấu hình (configuration control CC) và
configuration accounting (CA) tạm dịch là sự diễn giải cấu hình.

Hình 2-1 Các hoạt động trong CM
CID cung cấp một phương pháp nhằm nhận dạng sự đặc trưng và tính duy
nhất của mỗi instance (ví dụ như release, version) trong một sản phẩm

không có trung tâm lưu trữ dữ liệu sẽ rất dễ bị hư hại hoặc phá hủy hoàn

KHOA CNTT – ĐH KHTN

Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử

24

toàn. Các tai nạn như vỡ ống dẫn nước, cháy nhà, chưa kể những trường
hợp bị hacker, viruses… Vì vậy, đảm bảo an toàn dữ liệu cũng như trung
tâm lưu trữ dữ liệu cũng là một điều cần thiết.
· Education : Việc huấn luyện hay đào tạo bảo đảm những thành viên phát
triển dự án hoặc những người sẽ sử dụng phần mềm khi nó được hoàn tất
đều có thể thực hiện công việc của họ một cách đúng đắn.
Một điều rất quan trọng trong việc đảm bảo chất lượng phần mềm là
thành viên sản xuất phải được đào tạo để có thể sử dụng nhiều công cụ
phát triển khi được yêu cầu. Vai trò của người đảm bảo chất lượng phần
mềm là xem xét những kiến thức nào sẽ cần đến trong tương lai và trang
bị những kiến thức đó cho nhân viên của mình.
· Vendor management : khi một phần mềm được hoàn tất, công việc phát
hành cũng rất quan trọng. Việc quản lý những công việc nhỏ nhặt xung
quanh việc phát triển phần mềm như liên hệ mua bản quyền các phần
mềm hỗ trợ cho việc phát triển, các phần mềm chống virus… cũng là một
yếu tố trong việc đảm bảo chất lượng.