đồ án công nghệ thông tin Quản lý vết yêu cầu trong EA

Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Định hướng đề tài
Ngày nay, khi lĩnh vực công nghệ phần mềm ngày càng phát triển, việc đặt ra
vấn đề đáp ứng được yêu cầu người dùng đòi hỏi càng cao. Chính điều này đã
đưa ra câu hỏi “Làm thế nào để quản lý yêu cầu người dùng”. Đây cũng chính là
định hướng đề tài ĐATN của tôi. ĐATN này nhằm nNghiờn cứu phương pháp
quản lý yêu cầu phần mềm và vết yêu cầu phần mềm. Tỡm hiểu công cụ thiết kế
và xõy dựng phần mềm phù hợp cho phép quản lý yêu cầu và vết yêu cầu phần
mềm. Xây dựng một ứng dụng thực nghiệm về quản lý vết yêu cầu phần mềm
và đánh giá về công cụ sử dụng.
2. Các nhiệm vụ cụ thể của ĐATN
1. Tìm hiểu về các phương pháp quản lý yêu cầu phần mềm và vết yêu
cầu.
2. Lựa chọn và tìm hiểu công cụ CASE phù hợp-cụng cụ Enterprise
Architecture 7.0.
3. Quản lý yêu cầu, quản lý vết, quản lý kiến trúc sử dụng công cụ EA
4. Xõy dựng ứng dụng và thực nghiệm.
5. Đưa ra những đánh giá kết luận về EA.
3. Lời cam đoan của sinh viên
Tôi – Phạm Phương Thuỷ – cam kết ĐATN là công trình nghiên cứu của
bản thân tôi dưới sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng.
Các kết quả nêu trong ĐATN là trung thực, không phải sao chép toàn văn
của bất kỳ công trình nào khác.
Hà Nội, ngày 24 tháng 5 năm 2008
Tác giả
Phạm Phương Thuỷ
4. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và
cho bảo vệ.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48

i
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Hà Nội, ngày24 tháng 5 năm 2008
Giáo viên hướng dẫn

PGS.TS Huỳnh Quyết Thắng
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
ii
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP
Đối với lĩnh vực công nghệ phần mềm, việc phần mềm thoả món được yêu cầu người
dùng là một vấn đề vô cùng quan trọng. Vấn đềYêu cầu đặt ra là hệ thống khi đưa ra sử
dụng luôn đảm bảo đáp ứng được các yêu cầu của người dùng đưa ra đồng thời đảm bảo
khi có bất kì thay đổi nào về hệ thống cũng không tốn quá nhiều thời gian và giá thành
trong việc quản lý thay đổi đó.
Trong các dự án phát triển phần mềm, mọi thứ đều có khảkhẳ năng thay đổi, việc lặp đi
lặp lại nhiều lần sẽ làm cho các dự án khó khăn trong vấn đề quản lý. Yêu cầu phần mềm
được đưa ra sử dụng càng ngày càng phải đáp ứng được đòi hỏi khắt khe trong việc đáp
ứng được yêu cầu người dùng và hỗ trợ việc quản lý những thay đổi. Thông tin vết chỉ ra
rằng các phần tử nào đã thay đổi hay đưa ra những phần tử bị tác động bởi thay đổi đó.
Số lượng của thông tin vết yêu cầu có thể dẫn tới giá cả cao, nhiều lỗi hay sự thay đổi
không thành công, khả năng dùng lại các thành phần và kiểm tra lỗi một cách khó khăn
Nếu thông tin vết là có sẵn, các thay đổi sẽ được đưađư ra một cách đúng đắn và hoàn
thành trong quá trình phát triển dự án. Thông tin vết yêu cầu giúp quản lý yêu cầu. Các yêu
cầu được quản lý tốt sẽ làm tăng chất lượng dự án. Tuy nhiên vấn đề đặt ra các công ty sử
dụng thông tin vết như thế nào và để làm gì? Những dạng thông tin vết nào là cần thiết.
Các công ty lấy thông tin vết như thế nào? Những thông tin vết được khai tác sử dụng như
thế nào. Nhưng phần mềm được sản xuất qua nhiều giai đoạn, chúng ta nên quan tâm đến

các yêu cầu trong từng giai đoạn được hoàn thành như thế nào? Thiết kế, lập trình, kiểm
thử hay ngay khi phần mềm được triển khai. .
Trong khuôn khổ của đề tài, tác giả sẽ đi sâu nghiên cứu quản lý yêu cầu phần mềm đặt
trọng tõm vào vết yêu cầu, từ đó đề xuất ra một quy trình phù hợp cho thiết kế phần mềm
được áp dụng vào công cụ CASE được lựa chọn là Enterprise Architecture 7.0. Đồng thời
đưa ra những nhận định về ưu nhược điểm về công cụ được sử dụng. Ngoài ra tác giả cũn
xõy dựng lên ứng dụng và thử nghiệm đưa ra thông tin vết dưới dạng báo cáo.
Từ khóa: Enterprise Architecture 7.0, Kỹ thuật phần mềm, quản lý yêu cầu, kỹ thuật yêu
cầu, vết yêu cầu,
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
iii
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
ABSTRACT OF THESIS
For the field of Information Technology, one of the most important things for a software
product is to satisfy all users’ requirements. It is required for a deployed software product
to server all of its users' needs and ensure that any force to change to the system is not
time-consuming and too much expenditure in managing that change.
In software development projects, all things are susceptible to change. It leads to the
difficulty in managing. The requirements in satisfying users' requirements and in
supporting change management put on software products are more and more increasing.
The tracing information shows the changed elements or the elements that are affected by
that change.
The sheer volume of tracing information can lead to the high price of software products,
the large number of errors, unsuccessful in change, difficulty to re-use components and in
error checking, etc. If the tracing information is available, the changing decisions to
software system will be able to be given precisely and completed during the time of system
development. The tracing information helps to manage requirements. The more
requirements are managed, the more quality of software projects will be increased.
However, the foresee problems existed such as: “how the tracing information is used?”,

“which kinds of information are needed?”, and “how the tracing information is solicited?”.
We all know that any software product must go through several stages of development
lifecycle before being used. For that reason, we must pay attention to how requirements
will be solved in each stage of development.
In this research study, author focuses on studying change management, especially on
tracing requirements. This leads to a proposal for a suitable process for designing software
products applies with the selected CASE tool, Enterprise Architect 7.0, and discuss about
the disadvantages of the tool used. In addition, author also develops an application for
exporting tracing information to print out in the form of report.
Keywords: Enterprise Architect 7.0, Software System, Requirement Manager,
Requirement Engineering, Requirement Ttraceeace abilityTreaceability,
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
iv
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
MỤC LỤC
i
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP i
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP iii
ABSTRACT OF THESIS iv
MỤC LỤC 1
DANH MỤC HÌNH 4
DANH MỤC BẢNG 7
BẢNG TỪ VIẾT TẮT 8
Lời cảm ơn 9
Mở đầu 10
TỔNG QUAN VỀ VẾT YÊU CẦU 2
1.1. Tổng quan 2
1.1.1. Định nghĩa 3
1.1.2. Phân loại vết yêu cầu 4

a. Vết trước và sau yêu cầu 4
b. Vết từ trước và sau 6
c. Phân loại theo dạng vết 6
1.1.3. Kỹ thuật yêu cầu 7
a. Kỹ thuật yêu cầu 8
b. Quản lý yêu cầu 9
1.1.4. Các vấn đề tìm vết 9
a. Thiếu định nghĩa thông thường: 10
b. Mâu thuẫn giữa các vấn đề 10
c. Mức độ chi tiết hóa vết đưa ra 10
1.1.5. Nguyên nhân và ưu điểm tìm vết yêu cầu 10
a. Kết luận về yêu cầu và mức độ hoàn thành dự án 10
b. Kiểm thử 11
c. Văn bản hoá hệ thống 11
d. Ưu điểm 11
1.2. Sự hỗ trợ hiện tại cho tìm vết yêu cầu 12
1.2.1. Công cụ tự động 12
a. Công cụ quản lý yêu cầu 13
b. Công cụ hỗ trợ thông thường 13
c. Công cụ hỗ trợ đặc biệt 13
d. Work-bench 13
e. Môi trường 14
1.2.2. Kỹ thuật tìm vết 14
a. Dạng kỹ thuật vết 14
b. Kỹ thuật 14
1.2.3. Quản lý vết yêu cầu 17
a. Quy tắc tìm vết 17
b. Hướng dẫn tìm vết 18
c. Chiến lược tìm vết 18
1.3. Phương thức dò vết yêu cầu trong UML 19

1.3.1. Vết yêu cầu trong UML 19
Hướng đi 20
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
1
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
1.4. Kết chương 21
CÔNG CỤ ENTERPRISE ARCHITECTURE 7.0 22
1.5. Khái niệm 22
Đặc trưng 23
Quản lý 23
a. Quản lý mô hình 23
b. Quản lý dự án 26
c. Quản lý yêu cầu 28
Kỹ thuật điển hình áp dụng trong EA 28
d. Gỡ rối 28
e. Kỹ thuật viết mã (Code Engineering) 29
f. Kỹ thuật MDG 30
g. Chuyển đổi MDA 30
h. Kỹ thuật XML 31
Văn bản và CSDL 31
i. Tạo văn bản 31
j. Mô hình hoá CSDL 32
1.6. EA và vai trò tham gia dự án 33
1.6.1. Quản lý 33
a. Quản lý dự án 33
b. Quản trị CSDL 33
c. Quản lý thực thi 34
1.6.2. Phát triển kỹ thuật 34
1.6.3. Phân tích và thiết kế 35

a. Phân tích giao dịch 35
b. Thiết kế 36
1.6.4. Các vai trò khác 36
a. Kỹ sư phần mềm 36
b. Nhóm phát triển 37
c. Tester 38
Vết yêu cầu trong EA 38
1.6.5. Vết và quan hệ yêu cầu 39
1.6.6. Ma trận vết yêu cầu 39
1.7. Ưu/nhược điểm 40
1.7.1. Ưu điểm 40
1.7.2. Nhược điểm 41
1.8. Hết chương 41
ÁP DỤNG EA VÀO TÌM VẾT YÊU CẦU 42
1.9. Phương pháp xây dựng vết yêu cầu 42
1.9.1. Chiến thuật đưa ra vết yêu cầu 42
1.9.2. Quy trình thu thập vết yêu cầu 45
1.10. Đề xuất đưa ra vết yêu cầu từ các mô hình trong EA 47
a. Mô hình yêu cầu 48
b. Mô hình phân tích và thiết kế 49
c. Mô hình kiểm thử 53
1.11. Kiến trúc vết yêu cầu trong EA 54
1.12. Kết chương 55
XÂY DỰNG ỨNG DỤNG VÀ THỬ NGHIỆM 56
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
2
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
1.13. Ý tưởng 56
1.14. Xây dựng ứng dụng 57

1.14.1. Thiết kế cơ bản 57
1.14.2. Kiến trúc hệ thống 58
1.14.3. Thiết kế chức năng 58
a. Lấy thông tin 58
b. Báo cáo 59
1.14.4. Thiết kế chi tiết 59
a. Tích hợp với EA 59
b. Tỡm kiếm yêu cầu 60
c. Đưa trạng thái yêu cầu 60
d. Xử lý kết nối 61
e. Lập báo cáo 61
f. Chức năng trợ giúp 62
1.14.5. Giao diện chương trình 62
1.15. Mô hình DMS 64
1.15.1. Giới thiệu 64
a. Hệ thống quản lý tài liệu được xây dựng nhằm mục đích: 64
b. Mô tả 64
1.15.2. Phõn tích thiết kế 65
a. Mô hình quy trình giao dịch 65
b. Mô hình phân tích 66
c. Mô hình thiết kế 71
d. Mô hình kiểm thử 79
1.16. Thử nghiệm 81
1.16.1. Thử nghiệm 81
1.16.2. Nhận xét và đánh giá 82
1.17. Kết chương 82
KẾT LUẬN 83
TÀI LIỆU THAM KHẢO 85
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
3

Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
DANH MỤC HÌNH
Hình 1-11-2: Vị trí của vết yêu cầu trong quy trình phát triển phần mềm 3
Hình 1-11-2: Vị trí của vết yêu cầu trong quy trình phát triển phần mềm 3
Hình 1-31-4: Phân biệt vết trước và sau yêu cầu 5
Hình 1-31-4: Phân biệt vết trước và sau yêu cầu 5
Hình 1-51-6: Phân loại vết yêu cầu 6
Hình 1-51-6: Phân loại vết yêu cầu 6
Hình 1-71-8: Các dạng vết 7
Hình 1-71-8: Các dạng vết 7
Hình 1-91-10: Kiến trúc phân tích lĩnh vực kỹ thuật yêu cầu [Wiegers 1999, p.19]
8
Hình 1-91-10: Kiến trúc phân tích lĩnh vực kỹ thuật yêu cầu [Wiegers 1999, p.19]
8
Hình 1-111-12: Kỹ thuật yêu cầu 9
Hình 1-111-12: Kỹ thuật yêu cầu 9
Hình 1-131-14: Mô hình vết tổng quan 20
Hình 1-131-14: Mô hình vết tổng quan 20
Hình 2-152-16: Mô hình kiến trúc MOF 26
Hình 2-152-16: Mô hình kiến trúc MOF 26
Hình 2-172-18: Ma trận thiết lập quan hệ thống EA 39
Hình 2-172-18: Ma trận thiết lập quan hệ thống EA 39
Hình 3-193-20: Mô hình phân tích thiết kế theo quy trình RUP 43
Hình 3-193-20: Mô hình phân tích thiết kế theo quy trình RUP 43
Hình 3-213-22: Kỹ thuật yêu cầu 45
Hình 3-213-22: Kỹ thuật yêu cầu 45
Hình 3-233-24: Quy trình vết yêu cầu 46
Hình 3-233-24: Quy trình vết yêu cầu 46
Hình 3-253-26: Vết theo mô hình 48

Hình 3-253-26: Vết theo mô hình 48
Hình 3-273-28 Mô phỏng mô hình yêu cầu trong EA 49
Hình 3-273-28 Mô phỏng mô hình yêu cầu trong EA 49
Hình 3-293-30: Mô phỏng thông tin vết đặc tả yêu cầu 49
Hình 3-293-30: Mô phỏng thông tin vết đặc tả yêu cầu 49
Hình 3-313-32: Mô hình đặc tả usecase 50
Hình 3-313-32: Mô hình đặc tả usecase 50
Hình 3-333-34: Mô phỏng thông tin vết yêu cầu-use case được đưa ra 51
Hình 3-333-34: Mô phỏng thông tin vết yêu cầu-use case được đưa ra 51
Hình 3-353-36 Mô phỏng mô hình usecase trong EA 51
Hình 3-353-36 Mô phỏng mô hình usecase trong EA 51
Hình 3-373-38 Đặc tả mô hình lớp trong EA 52
Hình 3-373-38 Đặc tả mô hình lớp trong EA 52
Hình 3-393-40 Đặc tả mô hình kiểm thử trong EA 52
Hình 3-393-40 Đặc tả mô hình kiểm thử trong EA 52
Hình 3-413-42: Mô phỏng thông tin vết Use-case-Class 53
Hình 3-413-42: Mô phỏng thông tin vết Use-case-Class 53
Hình 3-433-44 Mô phỏng mô hình kiểm thử trong EA 53
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
4
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Hình 3-433-44 Mô phỏng mô hình kiểm thử trong EA 53
Hình 3-453-46: Mô phỏng thông tin yêu cầu-Test và Class-test 54
Hình 3-453-46: Mô phỏng thông tin yêu cầu-Test và Class-test 54
Hình 3-473-48:Kiến trúc vết hiển thị trong EA 55
Hình 3-473-48:Kiến trúc vết hiển thị trong EA 55
Hình 4-494-50: Mô phỏng kiến trúc hệ thống 58
Hình 4-494-50: Mô phỏng kiến trúc hệ thống 58
Hình 4-514-52: Mô phỏng chức năng lấy thông tin 58

Hình 4-514-52: Mô phỏng chức năng lấy thông tin 58
Hình 4-534-54: Mô tả chức năng báo cáo 59
Hình 4-534-54: Mô tả chức năng báo cáo 59
Hình 4-554-56:: Chức năng tích hợp EA 60
Hình 4-554-56:: Chức năng tích hợp EA 60
Hình 4-574-58: Chức năng tìm kiếm yêu cầu 60
Hình 4-574-58: Chức năng tìm kiếm yêu cầu 60
Hình 4-594-60: Chức năng đưa ra trạng thái yêu cầu 61
Hình 4-594-60: Chức năng đưa ra trạng thái yêu cầu 61
Hình 4-614-62: Chức năng xử lý kết nối 61
Hình 4-614-62: Chức năng xử lý kết nối 61
Hình 4-634-64: Chức năng lập báo cáo 62
Hình 4-634-64: Chức năng lập báo cáo 62
Hình 4-65: Chức năng trợ giúp 62
Hình 4-664-67: Giao diện sử dụng chính 63
Hình 4-664-67: Giao diện sử dụng chính 63
Hình 4-684-69: Giao diện cho phép thiết lập chọn lưa báo cáo đưa ra 64
Hình 4-684-69: Giao diện cho phép thiết lập chọn lưa báo cáo đưa ra 64
Hình 4-704-71: Mô phỏng phân lớp người sử dụng trong hệ thống DMS 65
Hình 4-704-71: Mô phỏng phân lớp người sử dụng trong hệ thống DMS 65
Hình 4-724-73: Biểu đồ giao dịch 65
Hình 4-724-73: Biểu đồ giao dịch 65
Hình 4-744-75: Biểu đồ domain 66
Hình 4-744-75: Biểu đồ domain 66
Hình 4-764-77: Yêu cầu quản lý tàitìa liệu 66
Hình 4-764-77: Yêu cầu quản lý tàitìa liệu 66
Hình 4-784-79: Yêu cầu quản lý người dùng 67
Hình 4-784-79: Yêu cầu quản lý người dùng 67
Hình 4-804-81: Yêu cầu An toàn 67
Hình 4-804-81: Yêu cầu An toàn 67

Hình 4-824-83 : Yêu cầu bảo mật 68
Hình 4-824-83 : Yêu cầu bảo mật 68
Hình 4-844-85: Yêu cầu quy định 68
Hình 4-844-85: Yêu cầu quy định 68
Hình 4-864-87: Yêu cầu thực hiện 68
Hình 4-864-87: Yêu cầu thực hiện 68
Hình 4-884-89: Biểu đồ tác nhân 69
Hình 4-884-89: Biểu đồ tác nhân 69
Hình 4-904-91: Uusecase tổng quan 69
Hình 4-904-91: Uusecase tổng quan 69
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
5
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Hình 4-924-93: Use case quản lý thành viên 70
Hình 4-924-93: Use case quản lý thành viên 70
Hình 4-944-95: Usecase quản lý nhóm 70
Hình 4-944-95: Usecase quản lý nhóm 70
Hình 4-964-97: Usecase quản lý văn bản 71
Hình 4-964-97: Usecase quản lý văn bản 71
Hình 4-984-99: Usecase tạo thư mục 71
Hình 4-984-99: Usecase tạo thư mục 71
Hình 4-1004-101: Usecase tạo thư mục con 72
Hình 4-1004-101: Usecase tạo thư mục con 72
Hình 4-1024-103: Usecase tạo thư mục gốc 72
Hình 4-1024-103: Usecase tạo thư mục gốc 72
Hình 4-1044-105: Usecase quản lý văn bản 73
Hình 4-1044-105: Usecase quản lý văn bản 73
Hình 4-1064-107: Usecase quản lý người dùng 73
Hình 4-1064-107: Usecase quản lý người dùng 73

Hình 4-1084-109: Usecase xem thông tin 74
Hình 4-1084-109: Usecase xem thông tin 74
Hình 4-1104-111: Usecase đăng nhập 74
Hình 4-1104-111: Usecase đăng nhập 74
Hình 4-1124-113: Usecase quản lý thành viên 75
Hình 4-1124-113: Usecase quản lý thành viên 75
Hình 4-1144-115: Quản lý nhóm 76
Hình 4-1144-115: Quản lý nhóm 76
Hình 4-1164-117: Usecase thay đổi mật khẩu 77
Hình 4-1164-117: Usecase thay đổi mật khẩu 77
Hình 4-1184-119: Uusecase thiết lập cấu hình 77
Hình 4-1184-119: Uusecase thiết lập cấu hình 77
Hình 4-1204-121: Biểu đồ lớp 78
Hình 4-1204-121: Biểu đồ lớp 78
Hình 4-1224-123: Biểu đồ CSDL 79
Hình 4-1224-123: Biểu đồ CSDL 79
Hình 4-1244-125: Kiểm thử lớp 80
Hình 4-1244-125: Kiểm thử lớp 80
Hình 4-1264-127: Kiểm thử yêu cầu chức năng 81
Hình 4-1264-127: Kiểm thử yêu cầu chức năng 81
Hình 4-1284-129: Kiểm thử yêu cầu phi chức năng 81
Hình 4-1284-129: Kiểm thử yêu cầu phi chức năng 81
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
6
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
DANH MỤC BẢNG
Bảng 1-1: Bỏo cáo Chaos 2
Bảng 1-2: Ví dụ về vết các yêu cầu[Wiegers 1999, p. 303) 15
Bảng 1-3: Ma trận vết yêu cầu hiển thị yêu cầu chức năng và use-case 15

Bảng 1-4: nguồn gốc cho thông tin liên kết vết yêu cầu [Wiegers 1999,p.305] 16
Bảng 1-5: Danh sách vết [Sommerville & Sawyer 1997, p. 229] 17
Bảng 2-6: Bảng phân tích chức năng của các bản 23
Bảng 4-7: Bảng đặc tả yêu cầu 56
Bảng 4-8: Bảng thông tin vết khi có Class và Use-Case 57
Bảng 4-9: Bảng thông tin vềvể Use-Case 57
Bảng 4-10: Bảng thông tin vết khi có Use-Case và Class 57
Bảng 4-11: Bảng thông tin vềvể Class 57
Bảng 4-12: Mô phỏng thông tin vết yêu cầu-testcript 57
Bảng 4-13: Bảng thông tin vết đưa ra khi có Test-Suite tương ứng 57
Bảng 4-14: Bảng chức năng chi tiết của ứng dụng 59
Bảng 4-15: Bảng so sánh kết quả 81
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
7
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
BẢNG TỪ VIẾT TẮT
Từ viết tắt Từ đầy đủ Ý nghĩa
UML Unifield Modeling Language Ngôn ngữ mô hình hóớa hợp nhất
CSDL Cơ Sở Dữ Liệu Cơ sở dữ liệu
SBT Scenario Based Treaceability Vết dựa trên kịch bản
RT Requirements Treaceability Vết yêu cầu
Pre-RT Pre Requirements Traceability Vết trước khi đưa ra yêu cầu
Post-RT Post Requirements Traceability Vết sau khi đưa ra yêu cầu
TS Technical Specification Đặc tả kỹ thuật
CASE Computer Aided Sofware
Engineering
Công cụ kỹ thuật phần mềm trợ
giúp máy tính
O&MO&M Operation and

MaintainceOperation and
Maintaince
Thực thi và bảo trìThực thi và bảo
trì
RUP Rational Unified Process Quy trình phát triển phần mềm của
Rational
XML eXtensible Markup Language Ngôn ngữ đánh dấu có thể mở rộng
DP Descision Point Điểm mô tả
MS MileStone MốcGiai đoạn
XMI . XML Metadata Implementation. Thực thi đa dữ liệu XML
RM Requirement Manager Quản lý yêu cầu
RE Requirement Engineering Kỹ thuật yêu cầu
SE Sofware Engineering Kỹ thuật phần mềm
WSDL
Web Service Definition language
Ngôn ngữ định nghĩa dịch vụ Web
XSD XML Schema Diagram Giản đồ XML
MOF Meta Object Facibility Đặc tính đa đối tượng
US Use Case Trường hợp sử dụng
Cl Class Llớp
UT Unit Test Kiểm thử đơn vị
ST System Test Kiểm thử hệ thống
IT Intergration Test Kiểm thử tích hợp
ScT Scenaorio Test Kiểm thử kịch bản
AT Acceptance Test Kiểm thử chấp nhận
PIM Platform-Independent Model Mô hình độc lập nền tảng
PSM Platform Specific Model (PSM) Mô hình chi tiết nền tảng
DBMS DataBase Management System Hệ quản trị cơ sở dữ liệu
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
8

Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Lời cảm ơn
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
Trước hết, em xin được chân thành gửi lời cảm ơn sâu sắc tới
các thầy cô giáo trong trường Đại học Bách Khoa Hà Nội nói
chung và các thầy cô trong khoa Công nghệ Thông tin, bộ môn
Công nghệ phần mềm nói riêng đã tận tình giảng dạy, truyền đạt
cho em những kiến thức và những kinh nghiệm quý báu trong suốt
5 năm học tập và rèn luyện tại trường Đại học Bách Khoa Hà Nội.
Em xin được gửi lời cảm ơn đến PGS.Ts Huỳnh Quyết Thắng -
Giảng viên bộ môn Công nghệ phần mềm, khoa Công nghệ Thông
tin, trường Đại học Bách Khoa Hà Nội đã hết lòng giúp đỡ, hướng
dẫn và chỉ dạy tận tình trong quá trình em làm đồ án tốt nghiệp.
Cuối cùng, em xin được gửi lời cảm ơn chân thành tới gia đình,
bạn bè đã quan tâm, động viên, đóng góp ý kiến và giúp đỡ trong
quá trình học tập, nghiên cứu và hoàn thành đồ án tốt nghiệp.
Hà Nội, ngày 24 tháng 05 năm 2008
Phạm Phương Thuỷ
Lớp CNPM – K48
Khoa CNTT – ĐH Bách Khoa HN
9
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Mở đầu
Các nhiệm vụ cụ thể của ĐATN
Với bài toán “Quản lý vết yêu cầu phần mềm” nhiệm vụ được đặt ra như sau:
1. BỐ CỤC TRÌNH BÀY CỦA ĐỒ ÁN Tìm hiểu về các phương pháp quản lý yêu cầu
phần mềm và vết yêu cầu.
2. Lựa chọn và tìm hiểu công cụ CASE phù hợp-công cụ Enterprise Architect 7.0.

3. Quản lý yêu cầu, quản lý vết, quản lý kiến trúc sử dụng công cụ EA
4. Xây dựng ứng dụng và thực nghiệm.
5. Đưa ra nhứng dụng và thực nghiệm. EA
Đồ án được chia làm 4 chương và 1 mục kết luận
Chương I
Trong chương I sẽ trình bày tổng quan về vấn đề quản lý yêu cầu và vết yêu cầu phần
mềm cùng một số các kỹ thuật và vấn đề tìm vết đồngdồng thời xác định vấn đề cần giải
quyết để đưa ra thông tin vết phù hợp.
Chương II
Nội dung trình bày chính của chương II là công cụ CASE được chọn mang tên
Enterprise Architecture 7.0. Trong chương này sẽ giới thiệu một cách tổng quan về công
cụ, việc quản lý yêu cầu và vết yêu cầu trong công cụ này đồng thời đưa ra đánh giá về ưu
nhược điểm của nó.
Chương III
Chương III sẽ trình bày về việc áp dụng EA như thế nào trong việc tìm vết và quản lý
vết. Chương III sẽ đưa ra quy trình lưu vết cụ thế và áp dụng vào EA để có thế đưa ra
thông tin vết
Chương IV
Trong chương IV, đưa ra ý tưởng về ứng dụng về quản lý vết yêu cầu trong EA. Xây
dựng lên một thực nghiệm đẻ kiểm tra ứng dụng đã xây dựng.
Kết luận
Mục này sẽ tổng kết lại những việc đã làm được trong đồ án tốt nghiệp, những khó khăn
trong quá trình thực hiện đề tài và những điều tồn tại, chưa thực hiện được trong đề tài.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48 Lớp CNPM Khoá 48
10
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
1
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần

mềm
TỔNG QUAN VỀ VẾT YÊU CẦU
Kể từ năm 1994, tổ chức Standish Group-một tổ chức nghiên cứu độc lập có tìm
hiểu và đưa ra báo cáo Chaos. Standish Group tìm hiểu 13 522 công ty và phân loại
40000 dự án từ các công ty đó thành 3 loại :
• Các dự án thành công: Là các dự án đưa ra đúng thời gian, trong ngân
sách cho phép và có hầu hết các đặc tính được thực thi.
• Các dự án không được thừa nhận: Là những dự án đã bị muộn nhưng bị
muộn, quáqúa ngân sách hay không đạt được một số đặc tính cần thiết
ban đầu.
• Dự án lỗi: Là dự án có thể bị ngừng ở một vài thời điểm trong suốt quá
trình thực thinghiên cứu.
Dạng dự án Báo cáo Chaos năm
1994
Báo cáo Chaos năm
2004
thànhThàng công 16% 34%
Thay đổi 31% 51%
Lỗi 53% 15%
Bảng 1-1: Bỏo cáo Chaos
Theo chuẩn IEEE 2004, yêu cầu là một thuộc tính mà hệ thống phải đạt được để
thích ứng với chức năng của nó. Tập các hành động xung quanh quy trình liên quan
tới yêu cầu được gọi là kỹ thuật yêu cầu. Kỹ thuật yêu cầu có thể được định nghĩa
như lĩnh vực bao quanh toàn bộ vòng đời dự án liên quan tới việc hiểu biết các đặc
tính và thuộc tính thiết yếu của sản phẩm [Weigers 03]. Có nhiều quy trình tạo lên
KỸ THUẬT YÊU CẦU (RET) như suy luận đưa ra các yêu cầu, phân tích yêu cầu,
chi tiết hoỏ yờu cầu, quản lý yêu cầu và vết yêu cầu và kiểm tra yêu cầu [IEEE 04].
Trong đó, quan trọng nhất là quả lý vết yêu cầu (RT).
Nói một cách đơn giản thì RT được xem xét như khả năng liên kết các yêu cầu,
thiết kế, mã nguồn và kiểm thử lại trong quy trình làm phần mềm

[Gotel 94].
1.1. Tổng quan
Trong rất nhiều môi trường, sự phát triển phần mềm và tốc độ của quy trình phát
triển phần mềm là hai đặc tính có thể thay đổi được và rất được quan tâm. Các dự
án phát triển nên bao gồm cả thời gian, ngân quỹ và kết quả đáp ứng được mong đợi
của khách hàng. Tất cả các mặt này đều đo chất lượng của dự án nhưng cuối cùng
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
Chương này gồm những nội dung chính sau:
Đưa ra khái niệm tổng quan về quản lý yêu cầu và vết yêu
cầu
Các phương pháp và kỹ thuật tìm vết
Sự hỗ trợ hiện tại cho việc tìm vết
Đưa ra tầm quan trọng của việc lưu vết yêu cầu
2
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
nhiều lỗi dự án phát triển phần mềm lại không nằm trong các mặt này. Có rất nhiều
nguyên nhân gây ra các lỗi này và kết quả của tổ chức Standish Group International
năm 2001 nghiên cứu chỉ ra rằng có 4 nguyên nhân chính như: thiếu hụt thông tin
đầu vào của người sử dụng, đặc tả không đầy đủ các yêu cầu, thay đổi các yêu cầu
và việc đặc tả chúng và thiếu hụt sự hỗ trợ. Do đó, một cách tăng chất lượng và đẩy
nhanh tiến độ phát triển phần mềm là cải tiến kỹ thuật yêu cầu và quản lý quy trình.
Vết yêu cầu là một phần quan trọng của quản lý yêu cầu nhưng lại không thường
xuyên được đưa vào trong nhiều dự án.
1.1.1. Định nghĩa
Trọng tâm của nhiệm vụ quản lý yêu cầu là để chắc chắn rằng các yêu cầu có thể
được lưu vết từ giai đoạn sớm nhất thông qua quá trình phát triển vào bảo trì hệ
thống. Theo Gotel giảng viên trường cao đẳng Imperial ở London-Anh [Gotel
2000], chỉ ra rằng vết các yêu cầu (RT) là “trỏi tim” của quản lý yêu cầu. Để làm
nổi bật vấn đề này, Gotel có đưa ra hình minh hoạ sau:

Hình 1-1 1-2: Vị trí của vết yêu cầu trong quy trình phát triển phần mềm
Với RT là vết yêu cầu nằm ở trung tâm.
RM là quản lý yêu cầu
RE là kỹ thuật yêu cầu
SE là kỹ thuật phần mềm
Có rất nhiều định nghĩa khác nhau về RT được đưa ra.
Robertsons năm 1999 có định nghĩa: “Yêu cầu có thể dò vết nếu bất kì một sản
phẩm nào tồn tại được xác định bởi yêu cầu và cho bất kì một sản phẩm nào được
xác định yêu cầu đó bởi chớnh nú”
Trong các nhiều bài thuyết trình của mình Robertsons cũng nói: ”Đặc tả các yêu
cầu phần mềm là khả năng tìm vết nếu nguồn gốc của mỗi yêu cầu là rõ ràng và nêu
tính năng được đưa ra trong văn bản phát triển trong tương lai”
Định nghĩa này đưa ra các vết từ yêu cầu tới tất cả các văn bản đó cú từ trước và
từ yêu cầu trước tới tất cả các văn bản sẽ được tạo ra. Một định nghĩa khác được
đưa ra trong từ điển Oxford English Dictionary là “Khả năng dò vết được mô tả và
chỉ ra dấu hiệu của những gì đã tồn tại hay được diễn ra trong giới hạn thời gian của
một yêu cầu để có thể đưa ra trong một bản bỏo cỏo”
Orlena C. Z. Gotel và Anthony C. W. Finkelstein năm 1994 đã tổng hợp lại và
đưa ra định nghĩa tổng quan: “Khả năng mô tả và theo dừi vòng đời của yêu cầu
trong cả hai hướng trước và sau: ví dụ từ nguồn gốc của nó thông qua phát triển và
chi tiết hoá để triển khai và sử dụng và thông qua các giai đoạn đang xảy ra và tích
hợp vào trong bất kỳ giai đoạnpha nào.”
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
3
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Thông tin vết sẽ trả lời các câu hỏi sau:
1. Tác động của thay đổi 1 yêu cầu là gì?
2. Một yêu cầu được thực thi ở đâu?
3. Tất cả các yêu cầu có được xác định?

4. Điều gì cần được xác đinh bởi 1 yêu cầu?
5. Sự thiết yếu của yêu cầu là gì?
6. Thiết kế nào tác động đến việc thực thi 1 yêu cầu?
7. Tại sao một thiết kế thực thi cách này và có thể thực thi cách khác
hay không?
8. Sự thực thi này có đáp ứng các yêu cầu đã đề ra?
9. Kiểm thử chấp nhận nào sẽ được sử dụng để thẩm định một yêu
cầu?
10. Có cần thiết kế phân tử đú khụng?
11. Làm sáng tỏ yêu cầu này như thế nào?
RT thông qua mối quan tâm trong việc làm tăng số lượng các tiêu chuẩn, và
hướng dẫn hệ thống và quản lý yêu cầu phần mềm. Mối quan tâm này xuất hiện bởi
nhiều phương thức và công cụ được phát triển để đưa ra vị trí các vấn đề tìm vết.
RT là một lĩnh vực vấn đề lớn trong sản xuất và tính tồn tại của các vấn đề RT có
thể vẫn được thông qua dù tồn tại sự thiếu hụt các vấn đề phân tích cụ thể trong quy
trình phát triển phần mềm [1Gotel & Finkelstein 1994, p.1].
1.1.2. Phân loại vết yêu cầu
Vết yêu cầu được phân loại bằng nhiều cách khác nhau. Cách phổ biến nhất trong
là phân loại vết theo giai đoạn trước và sau yêu cầu (Pre-RT và Post-RT) [1Gotel &
Finkelstein 1994a, p.11], phân loại theo vết từ trước và sau [1Gotel & Finkelstein
1994a, p10] và phân loại theo các dạng vết [2Sommerville & Sawyer 1997, p 226].
Cần chú ý rằng nhiều cách phân loại không giới hạn tới cách phân chia khỏc, chỳng
hỗ trợ và nhấn mạnh lẫn nhau.
a. Vết trước và sau yêu cầu
Việc phân loại vết trước và sau yêu cầu chia vết yêu cầu thành 2 loại cơ bản bao
gồm các mặt của RT. Định nghĩa sau được đưa ra bởi Gotel [1995, p. 78].
Nghiên cứu về RT,Gotel nhận định RT được chia thành 2 giai đoạn: giai đoạn
Pre_RS và Post-RS.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
4

Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Hình 1-3 1-4: Phân biệt vết trước và sau yêu cầu
• Vết trước khi đưa ra yêu cầu (Pre-RT)
Vết các yêu cầu Pre-RS bao gồm vòng đời các yêu cầu trước khi được đưa vào
trong một bản đặc tả yêu cầu phần mềm [Finkelstein 1991, Gotel 1994].
• Vết sau khi đưa ra yêu cầu (Post-RT)
Vết Post-RS được định nghĩa là khả năng để dò vết các yêu cầu và lật ngược lại,
một đường cơ sở thông qua sự nối tiếp những thành phần mà chúng phân bố. Xa
hơn, bất kỳ một thay đổi nào tới ranh ggiới này này cần được truyền bá lại thông
qua kênh kết nối vết [Gotal 94].
Pre-RT là một phần phát triển các yêu cầu của kỹ thuật yêu cầu bao gồm: đưa ra,
phân tích, chi tiết hoá và kiểm tra. Đầu ra của Pre-RT dựa trên văn bản đặc tả yêu
cầu phần mềm bao gồm thông tin vết trước pha thiết kế. Nếu công việc ban đầu của
RT tốt, chất lượng quy trình phát triển phần mềm sẽ tăng theo. Bản đặc tả yêu cầu
phần mềm đưa ra càng toàn diện sẽ càng cú ớt thay đổi xuất hiện trong quá trình
phát triển. Đây là nguyên nhân tại sao chúng ta thường nhấn mạnh vào vết Ppre-RT
và Ppost-RT chỉ giới hạn hiệu quả trong chất lượng của quy trình phát triển.
Gotel [1995, p. 79] đã nói rằng “Post-RT phụ thuộc vào khả năng tìm vết các yêu
cầu thông qua văn bản tĩnh liên quan và thông qua những phần văn bản và sản
phẩm mà chúng tham gia”. Post-RT giúp quản lý thay đổi tới bản đặc tả thông qua
cỏc kờnh đóng góp yêu cầu và giúp truy nhập vào các vấn đề thay đổi trong dự án
phát triển. Do dó, chỉ nếu Pre-RT hoàn thành, Ppost-RT không thể thực hiện mà
không có sự xây dựng là lập kế hoạch tốt. Post-RT cần có một số quy tắc để chính
vì thế nó có thể được thực thi hiệu quả [3].
Các vấn đề với vết Ppost-RT xuất hiện chính khi các hành động và cốt lõi của kỹ
thuật yêu cầu đưa ra từ những vấn đề khác. Vấn đề này có thể giới hạn bằng thiết
lập phát triển thông thường thay vì phương thức phát triển thông thường. Post-RT
tổ chức từ bản đặc tả yêu cầu và nếu nền tảng đú cú nhầm lẫn, các khó khăn cũng sẽ
được tập hợp cả trong vết Ppost-RT. Do dó, vết Ppost-RT không ảnh hường vào

chất lượng của vết Pre-RT mà chỉ thông qua chất lượng của vết Pre-RT ảnh hưởng
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
5
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
vào vết Ppost-RT. Cuối cùng, các nguồn gốc yêu cầu cần được dò vết để hỗ trợ các
thay đổi trong cơ bản và truy cập vào tác động của chúng [3Gotel 1995, p.79-80].
b. Vết từ trước và sau
Một sự phân chia nữa là vết từ trước và sau yêu cầu có nghĩa là một yêu cầu được
đưa ra từ nguồn gốc thực thi thông qua sự thực hiện của chúng. Hình 1-3 giới thiệu
4 dạng liên kết trước-sau của RT. Khách hàng cần vết sau tới các yêu cầu chỉ nếu có
thay đổi trong quá trình phát triển, các liên kết này chỉ ra trực tiếp yêu cầu nào sẽ bị
tác động. Điều này cải thiện sự chi tiết hoá được đưa ra ở tất cả các yêu cầu khách
hàng. Các yêu cầu có thể tìm vết lật ngược lại từ yêu cầu tới nguồn gốc của nó
[4Wiegers 1999, p. 298]. Các yêu cầu hệ thống đưa vào các yêu cầu phần mềm,
thiết kế, codemã và các sản phẩm khác trong quá trình phát triển, các yêu cầu có thể
được dò vết lật trước hay sau bằng việc định nghĩa liêen kết giữa các yêu cầu riêng
lẻ vcà chi tiết các phần tử sản phẩm đặc biệt. Các liên kết này chắc chắn rằng mỗi
yêu cầu có thể được thiết lập bởi nó có thể chỉ ra rằng các thành phần sản phầm
được đặt tại đâu. Dạng thứ 4 của liên kết vết chi tiết các sản phẩm công việc từ
trước tới các yêu cầu và giải thích tại sao mỗi mục đó được tạo ra. Hầu hết các ứng
dụng bao gồm codemã không liên quan trực tiếp tới các yêu cầu người sử dụng
nhưng một dòng codemã nờn có nguyên nhân được thực thi [4Wiegers 1999, p.
299]
Hình 1-5 1-6: Phân loại vết yêu cầu
Có 4 dạng liên kết vết như sau:
• Vết từ trước tới yêu cầu: Chỉ ra liên kết bắt đầu từ một yêu cầu tới một
thành phần
• Vết từ sau yêu cầu: Chỉ ra liên kết tời từ một thành phần trong phát triển
của hệ thống tới một yêu cầu.

• Vết sau từ yêu cầu: Chỉ ra liên kết từ nguồn của yêu cầu tới chính yêu cầu
đó.
• Từ sau trở lại yêu cầu: Cú cỏc liên kết tới từ một yêu cầu tới nguồn của
một yêu cầu.
c. Phân loại theo dạng vết
Có nhiều dạng vết khác nhau về thông tin vết có thể được duy trì thông qua dự án
phát triển. Hình 1-4 đưa ra 8 dạng thông tin vết. Sự phân chi này chia RT dựa trên
lien kết các yêu cầu và thực thể khỏc. Cỏc dạng này có thể được gom nhóm vào 2
nhúm được đề cập bên trên của RT là Pre-Rt và Post-RT. Dạng đầu tiên được gom
vào Pre-RT và 4 dạng cuối được gom vào Ppost-RT.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
6
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Hình 1-7 1-8: Các dạng vết
• Nguồn-yêu cầu: Liờn kết tới thông tin chứa các yêu cầu: Một nguồn yêu
cầu có thể là người tham gia dự án, các chuẩn, văn bản kỹ thuật, các yêu
cầu khác hay bất kỳ một kết nối nào tới chúng. Liên kết này giúp phân
tích 1 yêu cầu để hiểu tại sao yêu cầu tồn tại[2].[Sommerville & Sawyer
1997, p. 75, 226]
• Yêu cầu-cơ sở: Các yêu cầu với một mô tả tại sao yêu cầu tồn tại. Quan
hệ này là liên kết giữa các vấn đề và các yêu cầu được đưa ra cùng hướng
giải quyết chúng[2].[Sommerville & Sawyer 1997, p. 87, 226]
• Con người- yêu cầu là liên kết tới ngườingừời chi tiết húa cỏc yêu cầu.
Nếu có người đưa ra thông tin về yêu cầu cần thiết, chúng sẽ luôn được
xác định và truy cập nhanh chóngchóg khi thông tin của yêu cầu cần
thiết[5]. [Leino 2000, p. 14]
• Yêu cầu – giao tiếp: Liờn kết các yêu cầu với giao diện của hệ thống được
sử dụng trong sự chuẩn bị các yêu cầu[2]. [Sommerville & Sawyer 1997,
p. 226]

• Yêu cầu -– yêu cầu: Liờn kết các yêu cầu với yêu cầu khác trong một số
cách và chúng phụ thuộc vào nhau. Dạng thông tin này nờn luụn được
duy trì [Sommerville & Sawyer 1997, p. 2262].
• Kiến trúc -– yêu cầu liên kết các yêu cầu tới hệ thống con nới mà yêu cầu
thực thi[2].[Sommerville & Sawyer 1997, p.226]
• Yêu cầu - thiết kế liên kết các yêu cầu với các thành phần chi tiết hóa
trong hệ thống được sử dụng để thực thi yêu cầu đú. Chỳng có thể là phần
cứng, phần mềm[2]. [Sommerville & Sawyer 1997, p. 226]
• Yêu cầu -– kiểm thử: Liên kết cỏc bỏo cáo chi tiết hóa kiểm thử với các
yêu cầu. Các yêu cầu mức cao luôn được liên kết tới các kiếm thử chấp
nhận và các yêu cầu hệ thống tới kiểm thử hệ thống và kiểm thử tích hợp.
[5].[Leino 2000, p. 17-18]
1.1.3. Kỹ thuật yêu cầu
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
7
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Kỹ thuật yêu cầu thường được chia thành 5 loại khác nhau. Năm loại này mỗi
người viết khác nhau nhưng nội dung thì gần giống nhau. Thayer và Dorfman năm
1997 cùng Wiegers năm 1999 có giới thiệu
• Đưa ra yêu cầu: Quy trình này thông qua khách hàng và người phát triển
của hệ thống phần mềm khám phá, xem lại, đdưa ra và hiểu những điều
người sử dụng cần xác định yêu cầu sử dụng thông qua cuộc thảo luận.
Có 3 mức đưa ra yêu cầu: giao dịch, người sử dụng và chức năng bắt
nguồn từ những nguồn khác nhau. Trong những ràng buộc giai đoạn này
luôn thiết lập vào phần mềm và quy trình phát triển.
• Phân tích yêu cầu: Quy trình phần tích yêu cầu của khách hàng và người
sử dụng để đạt được định nghĩa về yêu cầu phần mềm. Tất cả những
người tham gia đều hiểu tính chất mừi yêu cầu.
• Đặc tả yêu cầu: Sự phát triển của văn bản báo cáo về yêu cầu của hệ

thống phần mềm và nó là mục tiêu cơ bản giữa khách hàng và người cung
cấp sản phầm. Trong các yêu cầu giai đoạn này cần được văn bản hoá
trong một số cách đưa ra và một số sự chuyển đổi chuẩn phải được thiết
lập để xác định mỗi yêu cầu.
• Xác định/kiểm tra yêu cầu: Quy trình này chắc chắn rằng đặc tả yêu cầu
phần mềm trong sự kết hợp với các yêu cầu hệ thống. Tính đúng đắn của
các yêu cầu và thuộc tính đưa ra được kiểm tra và phân tích.
• Quản lý yờu cầu : Hỗ trợ duy trì sự phát triển yêu cầu thông qua sự án
phát triển. Quản lý yêu cầu bao gồm thu thập yêu cầu, chi tiết hoá, phân
tích, kiểm tra và bao gồm việc lập dự án. Tìm vết, đáp ứng được thay đổi
yêu cầu
a. Kỹ thuật yêu cầu
Vậy vị trí của quản lý vết yêu cầu trong kỹ thuật yêu cầu như thế nào?
Wiegers năm 1999 định nghĩa RT được cấu hình như hình 5. Sự khác biệt thứ
yếu cho định nghĩa này dựa trên mô tả đưa ra dựa trên sự xác định như đưa ra,
phân tích, chi tiết hóa và xác minh lại để gom nhóm vào thành các nhómòm cùng
tên trong sự phát triển yêu cầu
Hình 1-9 1-10: Kiến trúc phân tích lĩnh vực kỹ thuật yêu cầu
[Wiegers 1999, p.19]
Wiegers cũng giới thiệu một số thực tiễn cho kỹ thuật yêu cầu RT sẽ giỳp nhóm
phát triển làm việc hiệu quả hơn trong việc tiến hành thực thi các yêu cầu.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
Kỹ thuật yêu cầu
Phát triển yêu cầu Quản lý yêu cầu
Đưa ra yêu cầu Phân tích yêu cầu Đặc tả yêu cầu Kiểm tra yêu cầu
8
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Các công việc này gồm :
• Kỹ thuật yêu cầu

• Quản lý phát triển các yêu cầu
• Đưa ra phân tích và kiểm tra chi tiết hóa.
b. Quản lý yêu cầu
Định nghĩa quản lý yêu cầu được chỉ ra bởi Leffingwell và Widrig [2000, p. 16]
đưa ra là “một phương pháp hệ thống để đưa ra, tổ chức và tạo văn bản quy trình
thiết lập và bảo trì mức độ đồng ý giữa khách hàng và đội dự án trong các yêu cầu
đang thay đổi của hệ thống”.
Quy tắc của quản lý yêu cầu là:
1. Quản lý thay đổi để chấp nhận các yêu cầu
2. Quản lý mối quan hệ giữa các yêu cầu
3. Quản lý sự phụ thuộc giữa các văn bản yêu cầu và văn bản khác được
đưa ra trong quy trình phần mềm và hệ thống[2].[Sommerville &
Sawyer 1997, p.216]
Thông thường, RT là hành vi trung tâm -– nó chắc chắn rằng tiếng nói của khách
hàng là trái tim thông qua quy trình phát triển và kỹ thuật yêu cầu không chỉ thực
hiện trong giai đoạn đơn lẻ trong chu trình [6Gotel 2000, p. 5]. Thực tiễn tốt cho
RM được mô tả trong bảng sau. Wiegers [1999, p. 268] gom nhúm chỳng vào thành
4 loại chính.
Các loại được mô tả:
Hình 1-11 1-12: Kỹ thuật yêu cầu
Theo Sommerville và Sawyer [1997, p.217] để quản lý yêu cầu, thông tin vết yêu
cầu cần được duy trì. Thông tin vết giúp tìím ra những yêu cầu khác có thể ảnh
hưởng bởi việc thay đổi yêu cầu. Quản lý yêu cầuu như duy trì sự phụ thuộc giữa
các yêu cầu có đặc tính nhóm lâu dài tốt hơn cho sự cần thiết của khách hàng và giá
cả phát triển hệ thống mức thấpáothấo. Các ưu điểm này sẽ không xuất hiện và
những người phát triển không đưa ra quản lý yêu cầu như một tiêu điểm. Việc thực
thi quản lý yêu cầu trong dự án phát triển có thể cần một số công việc thêm vào ở
thời gian đầu tạo nhiều khó khăn đối với thuyết phụúc mọi người vềè tầm quan
trọng của nó.
1.1.4. Các vấn đề tìm vết

Ngày nay, các kỹ thuật thông qua các vấn đề dò vết mà không thông qua bất kỳ
sự nghiên cứu nào về các vấn đề này, mặc dù có sự phát triển mạnh về công cụ chi
tiết hóa và các mục tiêu của chức năng quan trọng trong các công cụ này, họ sử
dụng khụng trờn diệndienedienẹdienẹ rộng trong thực tế như một yêu tố quan trọng
nhất thiết phảiảuphảu đưa ra. Các vấn đề RT chỉ tồn tại khi chúng cần được sử
dụng.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
Quản lý yêu cầu
Điều khiển thay đổi
Điều khiển phiên
bản
Tìm vết yêu cầu
Tìm vết trạng thái
yêu cầu
9
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Một số vấn đề về RT được đưa ra như:
• Thiếu định nghĩa thông thường
• Mâu thuẫn giữa các vấn đề
• Xác định mức độ chi tiết hóa vết đưa ra
a. Thiếu định nghĩa thông thường:
Các định nghĩa về vết các yêu cầu được chỉ ra như sau:
• Mục đích: định nghĩa mục tiêu nó sẽ làm gì? “khả năng tham gia vào vị trí
giao dịch, phạm vi dự án và các yêu cầu chính được đưa ra”
• Giải pháp: định nghĩa mục tiêu nên làm như thế nào? “khả năng kiểm tra
từ thực thể này tới thực thể khác dựa trên mối quan hệ ngữ nghĩa”
• Thông tin: nhấn mạnh vào thông tin có khả năng dò vết! Khả năng
liênluên kết giữa các chức năng, dữ liệu, yêu cầu và bất kì một text nào
trong trạng thái các yêu cầu liên quan tới chúng

• Định hướngương nhấn mạnhmạnn vàohướng khả năng dò vết! Khả năng
đi kèm các chi tiết đặc biệt ở đầu vào các pha của chu trình phần mềm tới
mục chi tiết ở đầu ra của giai đoạn đó.
Mỗi một định nghĩa đưa ra nhấn mạnh và cụ thể hóa một phạm vi nhất định.
Không có một định nghĩa nào bao quát toàn bộ vấn đề.
b. Mâu thuẫn giữa các vấn đề
Mỗi thực tế luônluốn đưa ra cho chúng ta sự hiểu biết riêng về nguyên nhân
chính của vấn đề tìm vết. Việc tìm ra này ảnh hướng trong các bài thuyết giảng đưa
ra các thực thể có thểtểê tìm vết, các kỹ thuật tích hợp,….
c. Mức độ chi tiết hóa vết đưa ra
• Mức không dò vết
Khả năng này thường được gọi là không làm gì cả [Reifer 20017]. Nếu tổ chức
không sử dụng RT trong bất kỡ cỏch nào, khả năng này sẽ là kết quả. Trong phương
pháp này, liên kết giữa các thành phần và các yêu cầu không được tạo văn bản và
kết nối giữa chúng được duy trì trong đầu của mỗi người.
• Mức độ ma trận không hoàn chỉnh
Khả năng này hiệu quả cho người sử dụng không chỉ giữa và duy trì liờn kột cho
ccs yêu cầu thấy được mức cao và then chốt. Tất cả các yêu cầu khác không được
liên kết hay bảo trì.
• Mức phức tạp
Khả năng này giới thiệu toàn bộ liên kết của các yêu cầu có thể, thiết kế, kiểm
thử và mã sử dụng ma trậnẩtậnmẩtận thrông thườngương. Đây là kịch bản hoàn hảo
cho các tổ chức nhiều tiền và nhiều nguồn nhân lực mà họ để duy trì ma trận phức
tạp.
• Vết hỗn tạp
Đây là sự tổng hợp vết thông thường và sử dụng kỹ thuật động để thiết lập các
lớp thớch ứng với các vết dựa trên những thiếu sót, không ổn định của các yêu cầu
và khối lượng lớn các vấn đề của hệ thống.
1.1.5. Nguyên nhân và ưu điểm tìm vết yêu cầu
a. Kết luận về yêu cầu và mức độ hoàn thành dự án

Nếu yêu cầu thay đổi, điều quan trọng là nhận dạng khi nào và tại sao thay đổi.
Liệu có người sẽ nhớ trong khoảng 12 tháng tại sao chúng ta lại quyết định tăng
thời gian cho phép từ 90 đến 120 ngày.
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
10
Đồ án tốt nghiệp Quản lý vết yêu cầu trong EA 7.0 phần
mềm
Liệu người quản lý có thể dễ dàng nhận biết tiến trình làm dự án một cách tổng
thế xem đã có bao nhiêu phần trăm công việc được hoàn thành một cách dễ dàng
nếu chỉ nhìn vào codemã và văn bản kiểm thử?
b. Kiểm thử
Nếu không có vết, làm thế nào người kiểmkiiểm thử biết cách để kiểm thử. Kế
hoạch kiểm thử nên là một bản sao các yêu cầu. Thậm trí nếu thông tin vết không rõ
ràng sẽ gây khó khăn lớn cho người kiểm thử trong việc xác định trạng thái yêu cầu.
Kế hoạch kiểm thử nên là một bản sao của các yêu cầu. Nếu các yêu cầu đưa ra
khối lượng thực hiện trong 120 ngày thì việc kiểm thử cần 120 ngày thực hiện. Như
bản kế hoạch kiểm thử được phát triển trong suốt quá trình xây dựng ứng dụng,
người kiểm thử cần biết khi nào mọi thứ thay đổi. Chúng sẽ cần được điều chỉnh kế
hoạch kiểm thử. Nếu có sự thay đổi muộn tới 180 ngày, nó sẽ không được xác định
và người kiểm thử có thể không nhận biết được sự thay đổi đó.
c. Văn bản hoá hệ thống
Các yêu cầu cần trở thành văn bản hệ thống và được duy trì việc cập nhật hàng
ngày. Mọi người phát triển đều phải đưa ra sự bảo trì hệ thống được tạo văn bản.
Nếu sự bảo trì cần đưa ra phần ngày thay đổi, những người kiểm thử tìm kiếm trong
nhiều ngày sau đó ngoài những yêu cầu ngày tháng có thể dẫn tới lỗi. Những yêu
cầu cần trở được tạo văn bản và được lưu giữ cập nhật theo ngày. Sự thay đổi cần
được kiểm tra, như có thể sắp xếp hệ thống thanh toán trong ngân hàng quốc tế lớn.
Chúng có thể tách biệt hệ thống điều khiển để tính toàn sự thanh toán dựa trên các
bảng. Có một môi trường phát triển, môi trường kiểm thử, môi trường sản phẩm.
Mỗi cái có tập các bảng quan hệ riêng và mỗi sự thiết lập đều khác nhau. đầu tiên

để đưa ra văn bản hệ thống nhưng không bao giờ lưu giữ ngày. Chúng ta không có ý
kiến về dữ liệu hiện tại. Cuối cùng, chúng ta phải tạo lại toàn bộ dữ liệu và đưa vào
trong tất cả môi trường. Có thể một vài nguyên nhân liên quan tới việc duy trì chính
nó, sự quản lý không được nhạy bén để biết có bao nhiêu trợ cấp được trả một cách
chính xác.
d. Ưu điểm
Wiegers [1999, p. 15] chỉ ra rằng, quy trình kỹ thuật yêu cầu thực thi hiệu quả có
thể có nhiều lợi ích. RTt là trái tim của quản lý yêu cầu và quá quan trọng của kỹ
thuật yêu cầu. RT không ảnh hường tới chất lượng yêu cầu nhưng giúp xác định
rằng tất cả các yêu cầu được thực thi. Tuy nhiên, vết yêu cầu chỉ có giá trị của vết
yêu cầu nếu Leino [2001, p. 24] nhất trí rằng giá trị của vết yêu cầu nếu:[8].
• Các yêu cầu được mong đợi thay đổi tuần tự
• Nó quan trọng để đạt được mối quan hệ giữa các văn bản
• Các yêu cầu hay các phần hệ thống đang được sử dụng lại
• Văn bản được sử dụng dể giao tiếp giữa các phần khác nhau
• Hệ thống được bảo trì bởi công ty khác
• Thành viên dự án thường xuyên thay đổi
Vết các yêu cầu cung cấp cách chứng minh sự đáp ứng của các yêu cầu, đưa ra sự
thoả thuận với khách hàng về các yêu cầu và được chi tiết hoá ở một mức nào đấy.
Ở một mức tính năng, vết yêu cầu có thể phát triển chất lượng của các sản phẩm
đưa ra, tăng bảo trì và đặc tính dùng lại. Tuy nhiên, vết yêu cầu tập trung vào các
nhiệm vụ yêu cầu sự xem xét mức tổ chức. Nó mô tả giai đoạn lưu thông tin hiện
Sinh viên thực hiện: Phạm Phương Thuỷ, Khoá 48Lớp CNPM Khoá 48
11