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

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ảokhi có bất kì thay đổi nào về hệ thống cũng không tốn quá

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 ravấ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ápquả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ầnmề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êucầu

2 Lựa chọn và tìm hiểu công cụ CASE phù hợp-cụng cụ EnterpriseArchitecture 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ủabả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ăncủ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ệ.

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

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ườidù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ảokhi 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ànhtrong 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ầnmề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 đổikhô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ànthà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êucầ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 đếncá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ểmthử 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 đặttrọ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ũnxõ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êucầu, vết yêu cầu,

ABSTRACT OF THESISFor the field of Information Technology, one of the most important things for a softwareproduct 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 nottime-consuming and too much expenditure in managing that change

In software development projects, all things are susceptible to change It leads to thedifficulty in managing The requirements in satisfying users' requirements and insupporting change management put on software products are more and more increasing.The tracing information shows the changed elements or the elements that are affected bythat 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 inerror checking, etc If the tracing information is available, the changing decisions tosoftware system will be able to be given precisely and completed during the time of systemdevelopment The tracing information helps to manage requirements The morerequirements 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 developmentlifecycle before being used For that reason, we must pay attention to how requirementswill be solved in each stage of development

In this research study, author focuses on studying change management, especially ontracing requirements This leads to a proposal for a suitable process for designing softwareproducts applies with the selected CASE tool, Enterprise Architect 7.0, and discuss aboutthe disadvantages of the tool used In addition, author also develops an application forexporting tracing information to print out in the form of report

Keywords: Enterprise Architect 7.0, Software System, Requirement Manager,Requirement Engineering, Requirement Ttraceeace abilityTreaceability,

MỤC LỤC

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP .i

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP .ii

ABSTRACT OF THESIS .iii

MỤC LỤC 1

-DANH MỤC HÌNH 4

-DANH MỤC BẢNG 6

-BẢNG TỪ VIẾT TẮT 7

-Lời cảm ơn 8

-Mở đầu 9

-CHƯƠNG 1 TỔNG QUAN VỀ VẾT YÊU CẦU 10

-1.1 Tổng quan 10

-1.1.1 Định nghĩa 11

-1.1.2 Phân loại vết yêu cầu 12

-a Vết trước và sau yêu cầu 12

-b Vết từ trước và sau 13

-c Phân loại theo dạng vết 14

-1.1.3 Kỹ thuật yêu cầu 15

-a Kỹ thuật yêu cầu 16

-b Quản lý yêu cầu 16

-1.1.4 Các vấn đề tìm vết 17

-a Thiếu định nghĩa thông thường: 17

-b Mâu thuẫn giữa các vấn đề 17

-c Mức độ chi tiết hóa vết đưa ra 17

-1.1.5 Nguyên nhân và ưu điểm tìm vết yêu cầu 18

-a Kết luận về yêu cầu và mức độ hoàn thành dự án 18

-b Kiểm thử 18

-c Văn bản hoá hệ thống 18

-d Ưu điểm 18

-1.2 Sự hỗ trợ hiện tại cho tìm vết yêu cầu 20

-1.2.1 Công cụ tự động 20

-a Công cụ quản lý yêu cầu 20

-b Công cụ hỗ trợ thông thường 20

-c Công cụ hỗ trợ đặc biệt 20

-d Work-bench 21

-e Môi trường 21

-1.2.2 Kỹ thuật tìm vết 21

-a Dạng kỹ thuật vết 21

-b Kỹ thuật 22

-1.2.3 Quản lý vết yêu cầu 24

-a Quy tắc tìm vết 24

-b Hướng dẫn tìm vết 25

-c Chiến lược tìm vết 25

-1.3 Phương thức dò vết yêu cầu trong UML 26

-1.3.1 Vết yêu cầu trong UML 26

-1.3.2 Hướng đi 28

-1.4 Kết chương 28

-CHƯƠNG 2 CÔNG CỤ ENTERPRISE ARCHITECT 7.0 29

-2.1 Khái niệm 29

-2.2 Đặc trưng 30

-2.2.1 Quản lý 30

-a Quản lý mô hình 30

-b Quản lý dự án 33

-c Quản lý yêu cầu 35

-2.2.2 Kỹ thuật điển hình áp dụng trong EA 35

-a Gỡ rối 35

-b Kỹ thuật viết mã (Code Engineering) 36

-c Kỹ thuật MDG 37

-d Chuyển đổi MDA 37

-e Kỹ thuật XML 38

-2.2.3 Văn bản và CSDL 38

-a Tạo văn bản 38

-b Mô hình hoá CSDL 39

-2.3 EA và vai trò tham gia dự án 40

-2.3.1 Quản lý 40

-a Quản lý dự án 40

-b Quản trị CSDL 40

-c Quản lý thực thi 41

-2.3.2 Phát triển kỹ thuật 41

-2.3.3 Phân tích và thiết kế 42

-a Phân tích giao dịch 42

-b Thiết kế 42

-2.3.4 Các vai trò khác 43

-a Kỹ sư phần mềm 43

-b Nhóm phát triển 44

-c Tester 44

-2.4 Vết yêu cầu trong EA 45

-2.4.1 Vết và quan hệ yêu cầu 45

-2.4.2 Ma trận vết yêu cầu 46

-2.5 Ưu/nhược điểm 47

-2.5.1 Ưu điểm 47

-2.5.2 Nhược điểm 48

-2.6 Hết chương 48

-CHƯƠNG 3 ÁP DỤNG EA VÀO TÌM VẾT YÊU CẦU 49

-3.1 Phương pháp xây dựng vết yêu cầu 49

-3.1.1 Chiến thuật đưa ra vết yêu cầu 49

-3.1.2 Quy trình thu thập vết yêu cầu 52

-3.2 Đề xuất đưa ra vết yêu cầu từ các mô hình trong EA 54

-a Mô hình yêu cầu 55

-b Mô hình phân tích và thiết kế 56

-c Mô hình kiểm thử 59

-3.2.2 Kiến trúc vết yêu cầu trong EA 60

-3.3 Kết chương 61

-CHƯƠNG 4 XÂY DỰNG ỨNG DỤNG VÀ THỬ NGHIỆM 62

-4.1 Ý tưởng 62

-4.2 Xây dựng ứng dụng 63

-4.2.1 Thiết kế cơ bản 63

-4.2.2 Kiến trúc hệ thống 64

-4.2.3 Thiết kế chức năng 64

-a Lấy thông tin 64

-b Báo cáo 64

-4.2.4 Thiết kế chi tiết 65

-a Tích hợp với EA 65

-b Tìm kiếm yêu cầu 66

-c Đưa trạng thái yêu cầu 66

-d Xử lý kết nối 67

-e Lập báo cáo 67

-f Chức năng trợ giúp 68

-4.2.5 Giao diện chương trình 68

-4.3 Mô hình DMS 70

-4.3.1 Giới thiệu 70

-a Hệ thống quản lý tài liệu được xây dựng nhằm mục đích: 70

-b Mô tả 70

-4.3.2 Phân tích thiết kế 70

-a Mô hình quy trình giao dịch 70

-b Mô hình phân tích 71

-c Mô hình thiết kế 77

-d Mô hình kiểm thử 84

-4.4 Thử nghiệm 86

-4.4.1 Thử nghiệm 86

-4.4.2 Nhận xét và đánh giá 86

-4.5 Kết chương 86

-KẾT LUẬN 87

-TÀI LIỆU THAM KHẢO 89

-PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP .i

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP .ii

ABSTRACT OF THESIS .iii

MỤC LỤC 1

-DANH MỤC HÌNH 4

-DANH MỤC BẢNG 6

-BẢNG TỪ VIẾT TẮT 7

-Lời cảm ơn 9

-BỐ CỤC TRÌNH BÀY CỦA ĐỒ ÁN 10

-CHƯƠNG 1 TỔNG QUAN VỀ VẾT YÊU CẦU 1

-1.1 Tổng quan 1

-1.1.1 Định nghĩa 2

-1.1.2 Phân loại vết yêu cầu 3

-a Vết trước và sau yêu cầu 3

-b Vết từ trước và sau 5

-c Phân loại theo dạng vết 5

-1.1.3 Kỹ thuật yêu cầu 6

-a Kỹ thuật yêu cầu 7

-b Quản lý yêu cầu 8

-1.1.4 Các vấn đề tìm vết 8

-a Thiếu định nghĩa thông thường: 9

-b Mâu thuẫn giữa các vấn đề 9

-c Mức độ chi tiết hóa vết đưa ra 9

-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ử 10

-c Văn bản hoá hệ thống 10

-d Ưu điểm 10

-1.2 Sự hỗ trợ hiện tại cho tìm vết yêu cầu 11

-1.2.1 Công cụ tự động 11

-a Công cụ quản lý yêu cầu 12

-b Công cụ hỗ trợ thông thường 12

-c Công cụ hỗ trợ đặc biệt 12

-d Work-bench 12

-e Môi trường 13

-1.2.2 Kỹ thuật tìm vết 13

-a Dạng kỹ thuật vết 13

-b Kỹ thuật 13

-c Danh sách vết 16

-d Liên kết vết tự động 16

-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 17

-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

-1.3.2 Hướng đi 20

-1.4 Kết chương 20

-CHƯƠNG 2 CÔNG CỤ ENTERPRISE ARCHITECTURE 7.0 22

-2.1 Khái niệm 22

-2.2 Đặc trưng 23

-2.2.1 Quản lý 23

-a Quản lý mô hình 23

-b Quản lý dự án 27

-c Quản lý yêu cầu 28

-2.2.2 Kỹ thuật điển hình áp dụng trong EA 29

-a Gỡ rối 29

-b Kỹ thuật viết mã (Code Engineering) 29

-c Kỹ thuật MDG 30

-d Chuyển đổi MDA 30

-e Kỹ thuật XML 31

-2.2.3 Văn bản và CSDL 32

-a Tạo văn bản 32

-b Mô hình hoá CSDL 33

-2.3 EA và vai trò tham gia dự án 34

-2.3.1 Quản lý 34

-a Quản lý dự án 34

-b Quản trị CSDL 34

-c Quản lý thực thi 35

-2.3.2 Phát triển kỹ thuật 35

-2.3.3 Phân tích và thiết kế 36

-a Phân tích giao dịch 36

-b Thiết kế 37

-2.3.4 Các vai trò khác 37

-a Kỹ sư phần mềm 37

-b Nhóm phát triển 38

-c Tester 39

-2.4 Vết yêu cầu trong EA 39

-2.4.1 Vết và quan hệ yêu cầu 40

-2.4.2 Ma trận vết yêu cầu 40

-2.5 Ưu/nhược điểm 42

-2.5.1 Ưu điểm 42

-2.5.2 Nhược điểm 42

-2.6 Hết chương 43

-CHƯƠNG 3 ÁP DỤNG EA VÀO TÌM VẾT YÊU CẦU 44

-3.1 Phương pháp xây dựng vết yêu cầu 44

-3.1.1 Chiến thuật đưa ra vết yêu cầu 44

-3.1.2 Quy trình thu thập vết yêu cầu 47

-3.2 Đề xuất đưa ra vết yêu cầu từ các mô hình trong EA 50

-a Mô hình yêu cầu 51

-b Mô hình phân tích và thiết kế 52

-c Mô hình kiểm thử 55

-3.2.2 Kiến trúc vết yêu cầu trong EA 56

-3.3 Kết chương 57

-CHƯƠNG 4 XÂY DỰNG ỨNG DỤNG VÀ THỬ NGHIỆM 58

-4.1 Ý tưởng 58

-4.2 Xây dựng ứng dụng 60

-4.2.1 Thiết kế cơ bản 60

-4.2.2 Kiến trúc hệ thống 60

-4.2.3 Thiết kế chức năng 60

-a Lấy thông tin 60

-b Báo cáo 61

-4.2.4 Thiết kế chi tiết 61

-a Tích hợp với EA 62

-b Tìm kiếm yêu cầu 62

-c Đưa trạng thái yêu cầu 63

-d Xử lý kết nối 63

-e Lập báo cáo 64

-4.2.5 Giao diện chương trình 64

-4.3 Mô hình DMS 66

-4.3.1 Giới thiệu 66

-a Hệ thống quản lý tài liệu được xây dựng nhằm mục đích: 66

-b Mô tả 66

-4.3.2 Phân tích thiết kế 66

-a Mô hình quy trình giao dịch 66

-b Mô hình phân tích 67

-c Mô hình thiết kế 73

-d Mô hình kiểm thử 81

-4.4 Thử nghiệm 82

-4.4.1 Thử nghiệm 82

-4.4.2 Nhận xét và đánh giá 82

-4.5 Kết chương 82

-KẾT LUẬN 83

-TÀI LIỆU THAM KHẢO 84

-DANH MỤC HÌNH

Hình 1-1: Vị trí của vết yêu cầu trong quy trình phát triển phần mềm 11

-Hình 1-2: Phân biệt vết trước và sau yêu cầu 12

-Hình 1-3: Phân loại vết yêu cầu 14

-Hình 1-4: Các dạng vết 14

-Hình 1-5: Kiến trúc phân tích lĩnh vực kỹ thuật yêu cầu 16

-Hình 1-6: Kỹ thuật yêu cầu 17

-Hình 1-7: Mô hình vết tổng quan 27

-Hình 2-1: Mô hình kiến trúc MOF 33

-Hình 2-2: Ma trận thiết lập quan hệ thống EA 46

-Hình 3-1: Mô hình phân tích thiết kế theo quy trình RUP 50

-Hình 3-2: Kỹ thuật yêu cầu 52

-Hình 3-3: Quy trình vết yêu cầu 53

-Hình 3-4: Vết theo mô hình 55

-Hình 3-5 Mô phỏng mô hình yêu cầu trong EA 55

-Hình 3-6: Mô phỏng thông tin vết đặc tả yêu cầu 56

-Hình 3-7: Mô hình đặc tả usecase 57

-Hình 3-8: Mô phỏng thông tin vết yêu cầu-use case được đưa ra 57

-Hình 3-9 Mô phỏng mô hình usecase trong EA 58

-Hình 3-10 Đặc tả mô hình lớp trong EA 58

-Hình 3-11 Đặc tả mô hình kiểm thử trong EA 59

-Hình 3-12: Mô phỏng thông tin vết Use-case-Class 59

-Hình 3-13 Mô phỏng mô hình kiểm thử trong EA 60

-Hình 3-14: Mô phỏng thông tin yêu cầu-Test và Class-test 60

-Hình 3-15:Kiến trúc vết hiển thị trong EA 61

-Hình 4-1: Mô phỏng kiến trúc hệ thống 64

-Hình 4-2: Mô phỏng chức năng lấy thông tin 64

-Hình 4-3: Mô tả chức năng báo cáo 65

-Hình 4-4:: Chức năng tích hợp EA 66

-Hình 4-5: Chức năng tìm kiếm yêu cầu 66

-Hình 4-6: Chức năng đưa ra trạng thái yêu cầu 67

-Hình 4-7: Chức năng xử lý kết nối 67

-Hình 4-8: Chức năng lập báo cáo 68

-Hình 4-9: Chức năng trợ giúp 68

-Hình 4-10: Giao diện sử dụng chính 69

-Hình 4-11: Giao diện cho phép thiết lập chọn lưa báo cáo đưa ra 69

-Hình 4-12: Mô phỏng phân lớp người sử dụng trong hệ thống DMS 70

-Hình 4-13: Biểu đồ giao dịch 71

-Hình 4-14: Biểu đồ domain 71

-Hình 4-15: Yêu cầu quản lý tài liệu 72

-Hình 4-16: Yêu cầu quản lý người dùng 73

-Hình 4-17: Yêu cầu An toàn 73

-Hình 4-18 : Yêu cầu bảo mật 74

-Hình 4-19: Yêu cầu quy định 74

-Hình 4-20: Yêu cầu thực hiện 74

-Hình 4-21: Biểu đồ tác nhân 75

-Hình 4-22: Usecase tổng quan 75

-Hình 4-23: Usecase quản lý thành viên 76

-Hình 4-24: Usecase quản lý nhóm 76

-Hình 4-25: Usecase quản lý văn bản 77

-Hình 4-26: Usecase tạo thư mục 77

-Hình 4-27: Usecase tạo thư mục con 78

-Hình 4-28: Usecase tạo thư mục gốc 78

-Hình 4-29: Usecase quản lý văn bản 79

-Hình 4-30: Usecase quản lý người dùng 79

-Hình 4-31: Usecase xem thông tin 80

-Hình 4-32: Usecase đăng nhập 80

-Hình 4-33: Usecase quản lý thành viên 81

-Hình 4-34: Quản lý nhóm 82

-Hình 4-35: Usecase thay đổi mật khẩu 83

-Hình 4-36: Usecase thiết lập cấu hình 83

-Hình 4-37: Biểu đồ lớp 84

-Hình 4-38: Biểu đồ CSDL 84

-Hình 4-39: Kiểm thử lớp 85

-Hình 4-40: Kiểm thử yêu cầu chức năng 85

-Hình 4-41: Kiểm thử yêu cầu phi chức năng 86

-Hình 1-1: Vị trí của vết yêu cầu trong quy trình phát triển phần mềm 2

-Hình 1-1-2: Phân biệt vết trước và sau yêu cầu 4

-Hình 1-3: Phân loại vết yêu cầu 5

-Hình 1-4: Các dạng vết 6

-Hình 1-5: Kiến trúc phân tích lĩnh vực kỹ thuật yêu cầu [Wiegers 1999, p.19] 7

-Hình 1-6: Kỹ thuật yêu cầu 8

-Hình 1-7: Mô hình vết tổng quan 20

-Hình 2-1: Mô hình kiến trúc MOF 26

-Hình 2-2: Ma trận thiết lập quan hệ thống EA 40

-Hình 3-1: Mô hình phân tích thiết kế theo quy trình RUP 45

-Hình 3-2: Kỹ thuật yêu cầu 3-1 47

-Hình 3-3: Quy trình vết yêu cầu 48

-Hình 3-4: Vết theo mô hình 51

-Hình 3-5 Mô phỏng mô hình yêu cầu trong EA 51

-Hình 3-6: Mô phỏng thông tin vết đặc tả yêu cầu 51

-Hình 3-7: Mô hình đặc tả usecase 52

-Hình 3-8: Mô phỏng thông tin vết yêu cầu-use case được đưa ra 53

-Hình 3-9 Mô phỏng mô hình usecase trong EA 53

-Hình 3-10 Đặc tả mô hình lớp trong EA 54

-Hình 3-11 Đặc tả mô hình kiểm thử trong EA 54

-Hình 3-12: Mô phỏng thông tin vết Use-case-Class 55

-Hình 3-13 Mô phỏng mô hình kiểm thử trong EA 55

-Hình 3-14: Mô phỏng thông tin yêu cầu-Test và Class-test 56

-Hình 3-15:Kiến trúc vết hiển thị trong EA 57

-Hình 4-1: Mô phỏng kiến trúc hệ thống 60

-Hình 4-2: Mô phỏng chức năng lấy thông tin 61

-Hình 4-3: Mô tả chức năng báo cáo 61

-Hình 4-4:: Chức năng tích hợp EA 62

-Hình 4-5: Chức năng tìm kiếm yêu cầu 63

-Hình 4-6: Chức năng đưa ra trạng thái yêu cầu 63

-Hình 4-7: Chức năng xử lý kết nối 64

-Hình 4-8: Chức năng lập báo cáo 64

-Hình 4-9: Giao diện sử dụng chính 65

-Hình 4-10: Giao diện cho phép thiết lập chọn lưa báo cáo đưa ra 65

-Hình 4-11: Mô phỏng phân lớp người sử dụng trong hệ thống DMS 66

-Hình 4-12: Biểu đồ giao dịch 67

-Hình 4-13: Biểu đồ domain 67

-Hình 4-14: Yêu cầu quản lý tìa liệu 68

-Hình 4-15: Yêu cầu quản lý người dùng 69

-Hình 4-16: Yêu cầu An toàn 69

-Hình 4-17 : Yêu cầu bảo mật 70

-Hình 4-18: Yêu cầu quy định 70

-Hình 4-19: Yêu cầu thực hiện 70

-Hình 4-20: Biểu đồ tác nhân 71

-Hình 4-21: usecase tổng quan 71

-Hình 4-22: Use case quản lý thành viên 72

-Hình 4-23: Usecase quản lý nhóm 72

-Hình 4-24: Usecase quản lý văn bản 73

-Hình 4-25: Usecase tạo thư mục 73

-Hình 4-26: Usecase tạo thư mục con 74

-Hình 4-27: Usecase tạo thư mục gốc 74

-Hình 4-28: Usecase quản lý văn bản 75

-Hình 4-29: Usecase quản lý người dùng 75

-Hình 4-30: Usecase xem thông tin 76

-Hình 4-31: Usecase đăng nhập 76

-Hình 4-32: Usecase quản lý thành viên 77

-Hình 4-33: Quản lý nhóm 78

-Hình 4-34: Usecase thay đổi mật khẩu 79

-Hình 4-35: usecase thiết lập cấu hình 79

-Hình 4-36: Biểu đồ lớp 80

-Hình 4-37: Biểu đồ CSDL 80

-Hình 4-38: Kiểm thử lớp 81

-Hình 4-39: Kiểm thử yêu cầu chức năng 81

-Hình 4-40: Kiểm thử yêu cầu phi chức năng 82

-DANH MỤC BẢNG

Bảng 1-1: Báo cáo Chaos 10

-Bảng 1-2: Ví dụ về vết các yêu cầu 22

-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 22

-Bảng 1-4: nguồn gốc cho thông tin liên kết vết yêu cầu 23

-Bảng 1-5: Danh sách vết 24

-Bảng 2-1: -Bảng phân tích chức năng của các bản 30

-Bảng 4-1: -Bảng đặc tả yêu cầu 62

-Bảng 4-2: -Bảng thông tin vết khi có Class và Use-Case 62

-Bảng 4-3: -Bảng thông tin về Use-Case 63

-Bảng 4-4: -Bảng thông tin vết khi có UseCase và Class 63

-Bảng 4-5: -Bảng thông tin về Class 63

-Bảng 4-6: Mô phỏng thông tin vết yêu cầu-test 63

-Bảng 4-7: -Bảng thông tin vết đưa ra khi có Test-Suite tương ứng 63

-Bảng 4-8: -Bảng chức năng chi tiết của ứng dụng 65

-Bảng 4-9: -Bảng so sánh kết quả 86

-Bảng 1-1: Báo cáo Chaos 1

-Bảng 1-2: Ví dụ về vết các yêu cầu 14

-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 15

-Bảng 1-5: Danh sách vết 16

-Bảng 2-1: -Bảng phân tích chức năng của các bản 23

-Bảng 4-1: -Bảng đặc tả yêu cầu 58

-Bảng 4-2: -Bảng thông tin vết khi có Class và Use-Case 59

-Bảng 4-3: -Bảng thông tin vể Use-Case 59

-Bảng 4-4: -Bảng thông tin vết khi có Use-Case và Class 59

-Bảng 4-5: -Bảng thông tin vể Class 59

-Bảng 4-6: Mô phỏng thông tin vết yêu cầu-testcript 59

-Bảng 4-7: -Bảng thông tin vết đưa ra khi có Test-Suite tương ứng 59

-Bảng 4-8: -Bảng chức năng chi tiết của ứng dụng 62

-Bảng 4-9: -Bảng kết quả 82

-BẢNG TỪ VIẾT TẮT

UML Unifield Modeling Language Ngôn ngữ mô hình hóớa hợp nhất

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 andMaintaince

Thực thi và bảo trìThực thi và bảotrì

RUP Rational Unified Process Quy trình phát triển phần mềm của

RationalXML eXtensible Markup Language Ngôn ngữ đánh dấu có thể mở rộng

XMI XML Metadata Implementation Thực thi đa dữ liệu XML

RE Requirement Engineering Kỹ thuật yêu cầu

WSDL Web Service Definition language Ngôn ngữ định nghĩa dịch vụ Web

MOF Meta Object Facibility Đặc tính đa đối tượng

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

Lời cảm ơn

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

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ầuphầ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

CHƯƠNG 1

CHƯƠNG 2 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ìmhiể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

 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

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 quantớ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ĩanhư 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 đặctí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

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

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ềunguyên nhân gây ra các lỗi này và kết quả của tổ chức Standish Group Internationalnă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à đẩynhanh 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ườngxuyên được đưa vào trong nhiều dự án

2.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

nổi bật vấn đề này, Gotel có đưa ra hình minh hoạ sau:

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ảnphẩ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 đượcxá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êucầ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êutí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ủamộ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ầutrong 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íchhợp vào trong bất kỳ giai đoạnpha nào.”

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áchay 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êucầ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ởinhiề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 quytrình phát triển phần mềm [1Gotel & Finkelstein 1994, p.1].

2.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 & Finkelstein1994a, 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 baogồ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ạnPre_RS và Post-RS

Hình 1-31-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àotrong 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ố Xahơ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ôngqua 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êucầ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ầuphầ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ìnhphá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ỏckờ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áttriể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ếtPpost-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ếtlậ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àochấ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

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ácthay đổ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áchhà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ỗiyê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 ứngdụ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ụngnhưng một dòng codemã nờn có nguyên nhân được thực thi [4Wiegers 1999, p

299]

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ộtthà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ểncủ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ủamộ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 2nhúm được đề cập bên trên của RT là Pre-Rt và Post-RT Dạng đầu tiên được gomvào Pre-RT và 4 dạng cuối được gom vào Ppost-RT

Hình 1-71-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êucầu có thể là người tham gia dự án, các chuẩn, văn bản kỹ thuật, các yêucầ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ântí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ướnggiả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 đượcxác định và truy cập nhanh chóngchóg khi thông tin của yêu cầu cầnthiế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 đượcduy 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ầuthự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óatrong hệ thống được sử dụng để thực thi yêu cầu đú Chỳng có thể là phầncứ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ácyê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ấpnhậ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]

2.1.3 Kỹ thuật yêu cầu

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ỗingườ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ểncủa hệ thống phần mềm khám phá, xem lại, đdưa ra và hiểu những điềungườ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ắtnguồn từ những nguồn khác nhau Trong những ràng buộc giai đoạn nàyluô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ữngngườ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 cungcấ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ếtlậ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ầuphầ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ủacá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ự ánphá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ântích, kiểm tra và bao gồm việc lập dự án Tìm vết, đáp ứng được thay đổiyê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ùngtên trong sự phát triển yêu cầu

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]

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ómphá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

Các công việc này gồm :

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

 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ìnhthiế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áchhà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ả:

Theo Sommerville và Sawyer [1997, p.217] để quản lý yêu cầu, thông tin vết yêucầ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ể ảnhhưở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ữacá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ựcthi 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 quantrọng của nó

2.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ụ chitiế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ọngnhấ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

Một số vấn đề về RT được đưa ra như:

 Thiếu định nghĩa thông thường

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

 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ăngliê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àotrong 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ớimụ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ânchí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ếtKhả năng này thường được gọi là không làm gì cả [Reifer 20017] Nếu tổ chứckhô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ươngphá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ỉnhKhả 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 choccs 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 đượcliên kết hay bảo trì

 Mức phức tạpKhả 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ểmthử 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ảocho 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ứctạ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áclớ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

2.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ăngthời gian cho phép từ 90 đến 120 ngày

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ổngthế xem đã có bao nhiêu phần trăm công việc được hoàn thành một cách dễ dàngnế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ốilượ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ườikiể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ạchkiể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àngngà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 trongnhiề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êucầ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ácbả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àotrong 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áchchí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 địnhrằ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ếtyê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 đổiVế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ácnhiệ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ệnthời trong suốt quáquas trình phát triển dự án Nếu thông tin vết quáqúa cũ, chúng ta

có thể không bao giờ xây dựng lại được nó

Theo Wiegers [2003, p 301-302] mMột số ưu điểm của việc thực thi vết yêu cầutrong phát triển dự án là:

 Sự chứng nhận: Thông tin vết có thể sử dụng để chứng nhận các ứng dụng

đã được thực thi

 Phân tích các thay đổi gặp phải: Thấy được khả năng nhìn tổng thể mộtphần tử của hệ thống có thể bị tác động nếu thờm, xoỏ hay thay đổi yêucầu cụ thể

 Bảo trì: Các tính năng của thông tin vết tạo ra thay đổi chính xác và toànvẹn trong quá trình bảo trì để cải tiến sản phẩm

 Kiểm tra dự án : Nếu dữ liệu vết được báo cáo trong quá trình phát triển,một báo cáo về trạng thái thực thi dự án sẽ sẵn sàng được đưa ra

 Tạo lại [Kỹ thuật yêu cầu]: Các chức năng trong hệ thống kế thừa có thể

được tạo danh sách vào báo cáo tại vị trớ chỳng được đặt trong các yêucầu và thành phần phần mềm và yêu cầu hệ thống mới

 Dùng lại: Thông tin vết có đặc tính dùng lại các thành phần sản phẩmbằng việcviẹc nhận dạng cỏc gúi yêu cầu, thiết kế, codemã, kiểm thử liênquan

 Thu nhỏ vấn đề: Việc tạo văn bản các mối quan hệ nối liền giữa các thànhphần làm giảm vấn đề nếu một thành viên đội dự ỏn có hiểu biết cần thiết

về hệ thống đọc lướt qua về dự án

 Kiểm thử: Với liên kết giữa các trường hợp kiểm thử, yêu cầu và cácthành phần của codemã có thể được chỉ ra để thực hiện tìm lỗi Kiểm thửviên có thể nhận dạng dễ dàng các yêu cầu nào đã được thực thi

Vấn đề trên được để cập chi ra rằng những người ở vị trí khác nhau thì đưa ra vàyêu cầu những đặc tính khác nhau của yêu cầu vết Kỹ sư quản lý yêu cầu có thểquản lý yêu cầu tốt hơn với thông tin vết Các yêu cầu được tập hợp sớm cho phiênbản sau của sản phẩm nếu vết yêu cầu đã được hoàn thành Những phần có khảnnăngnăg dùng lại được đưa ra giúp công việc của kỹ sư yêu cầu, kiến trúc sư, thiết

kế và kiểm thử trong phiên bản tới của sản phẩm Khi gặp phải sự thay đổi thì dễdàng để phân tích giúp quản lý dự án và kiến trúc sư ước lượng được khối lượngcông việcviêc và phân tích vấn đề gặp phải cũng như giả cả và lịch trình làmmf dự

án Kiểm thử viên có thể xác định chính xác yêu cầu nào được thực thi do đó kháchhàng chắc chắn rằng những gì họ muốn đã có được

Vết yêu cầu sẽ giúp người thiết kế xác định chĩnh xác mã nguồn hệ thống vànhững gì cần nhưng không thành công Điều này làm tăng chất lượng của sản phẩm

RT cũn giỳp quản lý cả quy trình làm dự án và có thể chắcchuắc chắn rằng trạngthái đưa ra của xác sản phẩm là hoàn thành hay chưa Khả năng dùngdùg lại yêucầu, các thành phần và kiểm thử được đưa ra trong phiên bản mới sẽ nhanh hơn.Điều này tốt trong khi tốc độ là một trong những đặc tính quan trọng nhất trong quátrình phát triển phần mềm ngày nay

2.2.1 Công cụ tự động

Các công cụ tìm vết không làm việc một cách riêng lẻ bởi sự kiểm tra các yêu cầuđòi hỏi nhiều vấn đề Tuy nhiên, các công cụ cho phép thành viên sự án xem xét cácquan hệ vết để chắc chắn rằng không có quan hệ kiểm tra nào bị bỏ xót và không cóquan hệ kiểm tra sai nào được đưa ra [9Leffingwell & Widrig 2000, p 333]

Leino [2001, p 19] đưa ra trong các buổi thuyết trình rằng nếu tỡm vết có thểđược thực thi, nó có thể đưa ra kết quả trong hầu hết các trường hợp phát triển hệẹthống phần mềm khác nhau

Các công cụ đưa ra thông thường có thể được cấu hình để hỗ trợ về các hành vi

và hỗ trợ đưa ra tự động liên kết vết được miêu tả bên trên Các công cụ tự động baogồm trình soạn thảo văn bản, trình duyệt từ vựng, hệ thống quản lý CSDL Mặc dùvết không là trọng tâm của các công cụ đưa ra thông thường nhưng chúng có thểđược cấu hình để cho phép thiết lập và xem thông tin vết theo kiến trúc riêng Điềunày bao gồm việc thiết lập giữa các văn bản dự án, sự cập nhật thường xuyên củacác công cụ ….[3Gotel & Finkelstein 1994a, p 4-7] [Gotel 1995, p.45]

a Công cụ quản lý yêu cầu

Theo Leino, các [2001, p 21] chức năng cơ bản của công cụ quản lý yêu cầu là:

 Văn bản hoá thông tin thuộc tính các yêu cầu

 Lọc và sắp xếp để xem các yêu cầu

 Nhập và xuất các yêu cầu từ và tới công cụ đó

 Văn bản hoá thông tin sử dụng vết yêu cầu

 Hỗ trợ cấu hình và quản lý thay đổi

b Công cụ hỗ trợ thông thường

Bao gồm: Trình biên tập siêu văn bản, xử lý từ, tính toán mở rộng, hệ thốngCSDL

Công việc cá nhõn thúc đấy như việc cung cấp không thường xuyên hay đưađư rakhung cho RT, vì tỷ lệ trung bình giải pháp không định trước Được sử dụng điểnhình bởi người sử dụng đơn để đưa ra các hình vi sau:

(i) Khả năng mềm dẻo để cung cấo vết yêu cầu phù hợp với dự án và những gì

Hầu hết hố trợ cho công việc cá nhõn: Sự hỗ trợ trực tiếp các nhúm hành vi, làmtăng yếu tố trọng tõm tới cả suy trình và khả năng tỡm vết kết quả cuối cùng

(i) Có thể cung cấp vết cho những yêu cầu trung bình của các hành vi liên quan tới yêu cầu tách biệt

(ii) Hành vị gom nhúm các hỗ trợ thường cung cấp vết cho chúng

d Work-bench

Hệ thống vết yêu cầu tự động và hệ thống quản lý tìm vết yêu cầu được đưa ranhư những Work-bench Chúng là trung tâm xung quanh hệ thống quản lý CSDL và

cú cỏc công cụ để văn bản, mua, tổ chức, thay đổi, quản lý yêu cầu

Work-bench được sử dụng sau khi công cụ văn bản hoá sự kiến, chúng có thể khókhăn để đạt được công việc trong thực tế Công việc hiện tại thường khó chớnh vì ítthông tin và có thể mất thông tin

(i) Work-bench RT cung cấp thông tin vết tốt từ và sau thông tin nhập

ào từ công cụ và thông qua bề rộng hành đi liên quan

(ii) Các giá trị được thêm vào

(i) Khả năng cung cấp vết tốt.

(ii) Môi trường mở cung cấp nhiều sự lựa chọn phong phú vè phươngpháp và vết của nó

2.2.2 Kỹ thuật tìm vết

a Dạng kỹ thuật vết

Các kỹ thuật cơ bản được xác định thông qua vết các yêu cầu được thiết lập Các

kỹ thuật được chia thành 3 dạng khác nhau thông qua văn bản tham khảo làm trọngtâm, lấy văn bản sản phẩm đưa ra làm trọng tâm, lấy cấu trúc hệ thống phát triểnlàm trọng tâm Có nhiều dạng kỹ thuật đưa ra về số lượng và mang tính đa dạng vềthông tin có thể dò vết nhưng chỳng luụn quan hệ gắn liền với nhau có thể được đưa

ra thông tin tổng hợp và mở rộng để có thể phản ảnh sự thay đổi và bảo trì RT thôngqua vòng đời dự án.[3Gotel 1995, p 42].

 Vết lấy sự tham khảo làm trọng tâm

Theo Goel 1995, kỹ thuật này có thể được chia thành giản đồ tham khảo qua sựliên quan thực tế và bao hàm nhiều giản đồ tham khảo hơn Ví dụ trên giản đồ nàydựa trên một số dạng đánh số, chỉ mục cỏc yờu cầu rõ ràng, và chúng dựa trên phátbiểu và bảo trì mối quan hệ đặc biệt giữa các giai đoạn chính Vi dụ cho giản đồ nàyđược sử dụng rộng rãi ma trận yêu cầu cũng như sự mở rộng chúng trong chuỗi các

ma trận

 Vết lấy văn bản làm trọng tâm

Kỹ thuật này chắc chắc RT bằng việc tuyên bố tất cả hay một phần của cấu trúc

và nội dung văn bản dự án Ví dụ bao gồm những giản đồ khuông dạng đặc biệt đểđiền vào cũng như sử dụng mẫumấu văn bản trong tính năng tích hợp văn bản

 Vết lấy cấu trúc làm trọng tâm

Kỹ thuật này làm tăng việc văn bản hoá để đạt được RT bằng việc cấu trúc lại nótrong các điều khoản của mạng hay đồ thị Các kỹ thuật này được sử dụng riêng lẻkhi trọng tâm của RT là sự cập nhật và phổ biến thay đổi các yêu cầu

b Kỹ thuật

Có một số kỹ thuật cơ bản có thể được sử dụng để duy trì thông tin vết Đây lànhững bảng vết, danh sách vết, liên kết vết tự động, các công cụ hỗ trợ thôngthường và các công cụ quản lý yêu cầu bảng vết còn được gọi là ma trận vết

 Bảng vết

Là một dạng ma trận thông qua sự tham khảo những thực thể trong bảng chỉ ra

một vài dạng vết liên kết giữa các mục trong hàng và các mục trong cột Bảng 1-2

mô tả một dạng bảng vết hay ma trận vết đưa ra các liên kết giữa use-case, yêu cầuchức năng, phần tử thiết kế, mã nguồn và các trường hợp kiểm thử có thể được chỉra

Use

Case

Yêu cầu chức năng

Phần tử thiết kế

UC-28 Catalog.query.sort Class

catalog

Catalog.sort() Search.7

Search.8UC_29 Catalog.query imp

ort

Classcatalog

Catalog.import()

Catalog.validate()

Search.8Search.13Search.14

Bảng 1-2: Ví dụ về vết các yêu cầu[Wiegers 1999, p 303).

Bảng 1.3 chỉ ra mỗi yêu cầu chức năng được liên kết từ sau tới các use-case được

chi tiết và trước tới một hay nhiều thiết kế, mã nguồn và các phần tử kiểm thử Cácphần tử thiết kế có thể là các đối tượng trong các mô hình như biểu đồ luồn dữ liệu,các bảng trong mô hình dữ liệu quan hệ hay các lớp đối tượng Tham chiếu mãnguồn có thể là các phương thức trong một lớp, cỏc tên file mã nguồn, thủ tục, chứcnăng tron file mã nguồn Nhiều cột được thêm vào để mở rộng liên kết tới các sảnphẩm công việc như văn bản trợ giúp online Liên kết vết có thể được định nghĩa

một-một, một-nhiều hay nhiều-nhiều giữa các dạng của phần tử hệ thống Bảng 1-3

tạo khả năng thêm vào một số mục trong mỗi khối bảng và vì có nhiều quan hệ khác

có thể được đưa ra

Bảng 1-3 cung cấp bảng hay ma trận vết thông thường sử dụng các use-case và

các yêu cầu chức năng liên kết lại với nhau Đây là một ma trận vết hai hướng Mỗi

ô chung của 2 phần tử có liên kết được đánh dấu để đưa ra quan hệ khác nhau củacác kết nối [Wiegers 1999, p 304] Các ký hiệu khác nhau có thể được sử dụng để

biểu diễn các quan hệ của các kết nối khác nhau Theo Sommerville và& Sawyer

phẩm công việc khác

Các quan hệ này được mô tả như sau:

 Chi tiết/được chi tiết bởi: đưa ra một số yêu cầu B thêm chi tiết vào yêucầu A khác

 Yêu cầu/được yêu cầu bởi: đưa ra một số yêu cầu B yêu cầu kết quả đượccung cấp bởi yêu cầu A khác

 Ràng buộc/được ràng buộc bởi: đưa ra một số yêu cầu B được ràng buộcbởi một số yêu cầu A khác

Khi các dạng quan hệ khác nhau được sử dụng, các ký tự và tính chất của mỗi

yêu cầu dễ dàng được hiểu Có nhiều dạng ma trận được đưa ra như ở trong bảng

1-3 có thể thay đổi để công cụ tự động hỗ trợ nhiều hơn là những ma trận đơn đưa ra trong bảng 1-2[Wiegers 1999, p 3044].

Liên kết vết nên được định nghĩa bởi bất cứ ai có thông tin phù hợp Một sốnguồn gốc điển hình hiểu biết về liên kết giữa các dạng nguồn gốc và đối tượng

đích được đưa ra trong bảng 1-4 Vai trò và các cá nhân có thể cung cấp mỗimội

dạng thông tin vết trong các dự án khác nhau nên được định nghĩa

Dạng liên kết

nguồn-đối tượng tượng Dạng liên kết đích đối Nguồn thông tin

Yêu cầu hệ thống Yêu cầu phần mềm Kỹ sư hệ thốNg

Yêu cầu chức năng Yêu cầu chức năng Phân tích yêu cầu

Yêu cầu chức năng phần tử kiến trúc phần

Yêu cầu chức năng Các phần tử thiết kế

khác

người phát triển

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]

là cách dễ dàng để truy cập ngược lại của một yêu cầu Điều này dễ dàng được chỉ

ra rằng R1 phụ thuộc vào R3 và R4 Bảng này mô tả sự phụ thuộc giữa các yêu cầu

Có thể có một vài phụ thuộc phải được khoá lại thông qua để nhận yêu cầu nào phụthuộc vào nó [10].[Sommerville & Sawyer 1997, p 229-230]

Yêu cầu Phụ thuộc

Bảng 1-5: Danh sách vết [Sommerville & Sawyer 1997, p 229].

 Liên kville & Sawyer Nghĩa là các yêu cầu được duy trì trong CSDL và cácliên kết vết bao gồm các trường trong báo cáo dữ liệu Khi các yêu cầu đượcquản lý trong CSDL, nó dễ dàng được duy trì liên kết giữa các yêu cầu riêng

lẻ và tìm kiếm nhóm yêu cầu liên quan Vậy các yêu cầu được nói rõ như thếnào? Nó có phải là ngôn ngữ tự nhiên, mô hình đồ hoạ, phộp toỏn sẽ được

sử dụng như các dạng của yêu cầu?

- Có bao nhiêu yêu cầu được quản lý?

- Các yêu cầu luôn được phát triển và được quản lý bởi nhóm dự án ở một vịtrí như nhau, cùng sử dụng các dạng máy tính giống nhau hay truy cập cácyêu cầu cần từ các vị trí khác nhau

- Ai sẽ có trách nhiệm quản lý CSDL hay đây là một trách nhiệm riêng biệt?Nếu các yêu cầu được quản lý trong một CSDL, CSDL có thể được thiết kế baogồm thông tin vết Chớnh vỡ mỗi yêu cầu trong CSDL nên bao gồm ít nhất 2 trườngthông tin vết Những trường này cần chứa thông tin về các yêu cầu khác mà yêu cầu

đó phụ thuộc vào và các yêu cầu phụ thuộc vào yêu cầu đó Tuy nhiên, nếu có mộtvấn đề cần bảo trì các dạng khác nhau của thông tin vết như kiến trục yêu cầu,CSDL phải bao gồm các trường và đưa ra các thông tin về mỗi dạng khác nhau củaquan hệ Tất cả những vấn đề được đề cập ở trên khi một tổ chức tiến hành chọn hệthống CSDL [10].[Sommerville & Sawyer 1997, p 227, 236-240]

2.2.3 Quản lý vết yêu cầu

Quy trình quản lý yêu cầu bao gồm vết yêu cầu như được để cập sớm RT là tráitim của quy trình quản lý yêu cầu Do đó, nờn cú một vài quy tắc cho quản lý yêucầu và quản lý vết yêu cầu Để quản lý tốt vết yêu cầu cần có một số quy tắc chochúng

a Quy tắc tìm vết

Theo Sommerville và Sawyer ,[1997] chính sách quản lý yêu cầu nên định nghĩa

thông tin vết nào cần được bảo trì và chúngchũng được giới thiệu như thế nào.Chính sách tìm vết là những chính sách được viết ra cần được định nghĩa như sau:

 Thông tin vết nên được duy trì

 Các kỹ thuật có thể được sử dụng để duy trì vết

 Mô tả thông tin vết được đưa ra trong suốt kỹ thuật yêu cầu và quy trìnhphát triển hệ thống Vai trò của con người nên được định nghĩa nhưngười quản lý dự ỏn-người có trách nhiệm cho duy trì thông tin vết.Một mô tả làm như thể nào để đưa ra và tạo văn bản chi tiết quy tắc khi ràng buộcthờithơig giàn có thể thực thi quy tắc vết thông thường Thực tế luôn có nhiều cơhội thay đổi được đưa ra cho các yêu cầu hay hệ thống mà bước đầu không cần truycập tới tất cả các vấn đề thay đổi và bảo trì thông tin vết Quy tắc này nên địnhnghĩa các thay đổi nào nên được ủng hộ Quy tắc vết nên được định nghĩa để chắcchắn rằng thông tin vệt được cập nhậtnhâtk sau khi thay đổi diễn ra.[Sommerville

& Sawyer 1997, p.224-225]

Các quy tắc tìm vết được thực hiện độc lập trong bất kỳ hệ thống nào Như mộtphần của quy trình kế hoạch quản lý chất lượnglượngm hầu hết các quy tắc vết liênquan nên được lựa chọn và hiệu chỉnh để chi tiết hoá yêu cầu của hệ thống đangđược đưa ra Việc bảo trì thông tin vết thì đắt bởi nó bao gồm bảo trì khối lượng lớn

thông tin quản lý Dú đú quy tắc tìm vết nên được thực tế và không quá quan liêu.[Sommerville & Sawyer 1997, p 225] Quy tắc tìm vết có thể được thực thi bởi tổ

chức của bất kỳ một mức nào trong kỹ thuật yêu cầu Thông tin vết đơn giản làthông tin vết các yêu cầu tới nguồn của chúng và các yêu cầu khác có thể bắt đầu tạithời điểm thực thi vết yêu cầu của tổ chức ở mức cơ bản trong mô hình toàn vẹnquy trình kỹ thuật yêu cầu Trong thực tế, điều này tốt để bắt đầu thực thi thông tinvết Khi tính thuần thục của tổ chức tăng, quy tắc vết sẽ phức tạp hơn có thể đượcđưa ra [Sommerville & Sawyer 1997, p 225-22610]

b Hướng dẫn tìm vết

Những văn bản được sử dụng bởi kỹ sư yêu cầu và phát triển hệ thống và là phần

bổ sung cho văn bản yêu cầu Bao gồm các quy tắc vết chi tiết được sử dụng trong

dự án và tất cả thông tin vết yêu cầu Hướng dẫn tìm vết chắc chắn rằng thành viên

dự án có thể dễ dàng tìm ra quy tắc tìm vết cho dự án của họ và thông tin vết tạimộtmội thời điểm và dễ dàng cho việc bảo trì [Sommerville & Sawyer 1997, p

 Thời gian tồn tại của hệ thống được đo đạc: Hầu hết các quy tắc tìm vếtnên định nghĩa cho các hệ thống có một thời gian tồn tại lâu dài

 Mức độ thành thạo của tổ chức: Chi tiết quy tắc tìm vết hầu hết đều đưa rahiệu quả giá cả trong các tổ chức như có một quy trình mức cao Các tổchức ở mức thuần thục nên đặt trọng tâm vào vết cỏc yờu cầu-yờu cầu

 Thành phần và kích cỡ đội dự án: Dự án càng lớn càng có nhiều quy tắctìm vết được chi tiết hoá được yêu cầu Cơ bản, nếu đội dự án nhỏ, mô tảthông tin giữa các thành viên nhóm có thể là đủ

 Dạng hệ thống: Các hệ thống then chốt như hệ thống điều khiển thời gianthực hay hệ thống đảm bảo an toàn cần nhiều quy tắc tìm vết hơn hệthống không then chốt

c Chiến lược tìm vết

Chiến lược tìm vết là một phần rất quan trọng của hướng dẫn tìm vết Định nghĩacác vết tiềm ẩn và rõ ràng được sử dụng trong dự án Vết tiềm ẩn thiết lập cấu trúcánh xạ giữa các mô hình và quan hệ các mục mô hình

Có 2 phương pháp chiến lược quyết định các yêu cầu phần mềm được tập hợp

1 Một phương pháp là tất cả các yêu cầu được đưa vào trong chi tiết đặc tảyêu cầu phần mềm

2 Cỏch khác được định nghĩa tại 2 vị trí, mô hình use-case và bản đặc tả bổsung Phương pháp này bao gồm 4 chiến thuật khác nhau để quản lý kếtnối hai phần tử đó và lưu vết giữa chúng

Bốn chiến thuật như sau:

- Chỉ mô hình Use-case: Chiến thuật này chỉ sử dụng mô hình usecase nhưtrạng thài các yêu cầu hệ thống Chiến thuật này có thể được chọn cho các

dự án có kết cấu đón giữa khách hàng và người phát triển Dự trờn cỏc mô

cầu hệ thống Không có định nghĩa thêm nào về các yêuyeu cầu, đặcđăcktính sản phẩm hay các yêu cầu phần mềm.

- Các đặc tính điều khiển mô hình Use-case: Trong chiếnchíên thuật này,các dạng đặc tả mô hình một phần mềm hoàn chỉnh.Các đặc tính được tạovăn bản trong văn bản mục tiêu và được tạo vết tới các đặc tả chi tiết kháchoặc các use-case Chiến thuật này được sửsủ dụng trong quy trìnhRational Unified Process [RUP15]

- Mô hình Use-case là một mô tả của bản đặc tả yêu cầu Trong trường hợp

mô hình Use-Case là một phần mô tả thêm vào trong bản đặc tả yêu cầu

Nó được sử dụng khi bản đặc tả yêu cầu được yêu cầu các mẫu và môhình UseCase cho phép thực tể của sự phát triển điều khiển use-case Cácđặc tính được tìm vết trong bản đặc tả yêu cầu thông thường và các yêucầu được tìm vết trong mô hình Use-Case

- Mô hình use-case tương thích với tập các yêu cầu phần mềm được thêmvào Mô hình Use-case là sự giải thích của bản đặc tả yêu cầu thôngthường từ nhiều nguồn và cung cấp chi tiết của hệ thống đơn Trong chiếnthuật này, mỗi stakeholder đều có tập các đặc tính sản phầm và yêu cầuphên mềm riêng Những mặt này được kết hợp hài hoà trong mô hình use-case đơn được chi tiết hoá những gì mà hệ thống sẽ làm [Spence &Probasco 1998, p 6-710]

Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là mộtngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng với mục đích

mô hình hoỏ cỏc hệ thống sử dụng các khái niệm hướng đối tượng, thiết lập một kếtnối từ nhận thức của con người đến các sự kiện cần mô hình hoá, giải quyết vấn đề

về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau và cóthể tạo ra một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy

Hiện này, UML được dùng chủ yếu trong phát triển phần mềm để phân tích, thiết

kế hệ thống phần mềm, chính vì lẽ đó nên việc xây dựng vết yêu cầu phải dựa trênnhững phương thức dò vết trong UML để đảm bảo tính phù hợp và hữu dụng trongquy trình phát triển phần mềm

2.3.1 Vết yêu cầu trong UML

Sử dụng bao quát các kết nối giữa mã nguồn và thành phần được gọi là vết dựa trênkịch bản (Scenario-Based Traceability-SBT) Sự thúc đẩy bên dưới sự phát triểndạng vết này được dùng khi người sử dụng vết yêu cầu không tin tưởng vào liên kếtnhận được từ công cụ quản lý yêu cầu Chỉ khi có 30% tỷ lệ lỗi xuất hiện trong cácliên kết được trả về từ hệ thống dựa trên hững ngưỡng được đưa ra, nếu người sửdụng không biết 30% lỗi, tập các liên kết trả về ít được sử dụng cho đến khi không

có thời gian kiếm tra hết chúng [11Egyed 00] Để làm tăng độ chính xác của cácliên kết nhạn được, chi tiết hoa trong suốt kỹ thuật ảo trì sử hệ thống, vết dựa trênkịch bản tạo ra thông tin vết dựa trên khả năng suy xét kếtkêt quả của kịch bản kiểmthử được thực thi trong hệ thống

Có 3 yêu cầu trước tiên để đạt được kỹ thuật này[11Egyed 00]

Đầu tiên, phải chạy hệ thống để kiểm thử lại Hệ thống không cần phảihoàn thành, khi những nguyờn mõu và phần nhỏ hoàn thành là được

Yêu cầu thứ hai là phải có mô hình phần mềm tương ứng với hệ thốngnhư UML

Cuối cùng là phải cú cỏc trường hợp kiểm thử hay kịch bản được thựcthi

- Yêu cầu chức năng và UseCase bởi người phần tích yêu cầu

- Use-case và Module bởi nhà kiến trúc và kỹ sư phần mềm

- Module và các lớp thiết kế bởi kỹ sư phần mềm

- Các lớp thiết kế và Test_case bởi kỹ sư kiểm thử và thiết kế

- Test-case và Use-case bởi kỹ sư kiểm thử

 Thiết lập quy trình dò vết bao gồm quy trình quản lý yêu cầu được coi làmột phần của quy trình phát triển phần mềm s

 Cung cấp công cụ hỗ trợ sử dụng kiến trúc công cụ hỗ trợ CASE hiệntại

Như vậy ở chương này đó trỡnh bầy tổng quỏt hoá về quản lý yêu cầu và vết yêucầu cùng tầm quan trọng của vết yêu cầu trong thiết kế và xây dựng phần mềm Vếtyêu cầu đó gúp một phần không nhỏ trong việc quản lý thay đổi và đón đến thànhcông của hệ thống.

Vấn đề đặt ra:

- Cần có những hướng dẫn các dạng thông tin phải được đưa ra và được sửdụng trong ngữ cảnh nào Giải thích điều kiện và khả năng liên vết giữacác thành phần hệ thống tới người sử dụng

- Cần có kiến trúc mở rộng để cho phép kiểm tra quan hệ tập hợp và tổngquát hoá trong nhiệm vụ tìm vết

- Cần dịch vụ hỗ trợ ngữ cảnh của các dạng liên kết vết khác nhau

- Sự cần thiết các kiến trúc cho phép quản lý dự án và người phát triển địnhnghĩa và đưa ra một quy trình vết điều khiển mô hình kèm theo quy trìnhphát triển

- Hầu hết các công cụ hỗ trợ đều làm việc theo hướng văn bản mà khôngtích hợp với các module trong ngữ cảnh công cụ CASE

Từ những vấn đề đặt ra bên trên trong quy trình đưa ra vết yêu cầu dẫn tới nhữngnhiệm vụ cần thực hiện như sau:

- 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ầuphần mềm

CHƯƠNG 3 CÔNG CỤ ENTERPRISE ARCHITECT URE 7.0

Enterprise Architecture (EA) là một sản phẩm của Sparx Systems-Nhật Bản Đây

là công cụ kỹ thuật phần mềm trợ giúp máy tính (CASE ) dùng cho thiết kế và xâydựng hệ thống phần mềm EA dựa trên đặc tả UML 2.1-ngôn ngữ ảo cho phép sửdụng để mô hình hoá lĩnh vực hay hệ thống riêng biệt (kể cả đang tồn tại và đượcđưa ra)

EA là một công cụ tiên tiến hỗ trợ tất cả các mặt của chu trình phát triển, cungcấp đầy đủ thông tin vết từ giai đoạn thiết kế ban đầu thông qua triển khai và bảotrì Công cụ này luôn hỗ trợ kiểm thử và quản lý thay đổi Với hơn 100 000 giảipháp, EA được phổ biến trên diện rộng và được sử dụng bởi hàng ngàn công ty lớnnhỏ khác nhau từ các tổ chức đa quốc gia tới cỏc cụng ty co phụ thuộc, EA trởthành công cụ mô hình hoá cho sự lựa chọn cho người phát triển, xây dựng và phântích ở trên 60 quốc gia khác nhau

Điều khiển phiên

Chương này gồm những nội dung chính sau:

Giới thiệu tổng quản về công cụ EAThấy được quản lý yêu cầu trong EAƯu/nhược điểm của công cụ EA

1 File EAP

Một file EAP là một CSDL Microsoft JET, chính vì thế có thể mở nó sử dụng

MS Access hay bất kì công cụ báo cáo nào có thể làm việc với CSDL MicrosoftJET

2 Kho DBMS

Trong phiên bản Corporate, chúng ta có thể sử dụng CSDL DBMS cho các file

mô hình Các file dự án DBMS có một vài cấu trúc logic như mô hình EAP nhưngphải sử dụng để kết nối ADO/ODBC

 Phát triển nhóm và chia sẻ dự án

EA cho phép một tập các chức năng thiết kế đặc biệt để chia sẻ dự án trong đội

và môi trường phát triển Chia sẻ dự án có thể đạt được thông qua sự phát triểnmạng của kho mô hình, bản sao, nhập/xuất XML, điều khiển phiên bản, điều khiểngói và bảo mật người sử dụng

 Bản sao

Trong việc thêm để chia sẻ dự án qua mạng, EA luôn cho phép dự án được chia

sẻ sử dụng đặc tính tạo bản sao Bản sao là một quá trình thực có thể trao đổi dữliệu trong các kho và thích hợp để sử dụng trong nhiểu tình huống khác nhau củanhiều người khi thực thi công việc Người mô hình hoá kết hợp sự thay đổi này vàotrong Design master chỉ khi được yêu cầu Tạo bản sao yêu cầu các kho dựatrên EAP và không thể thực thi với các kho lưu trữ trên DBMS server

 Điều khiển phiên bản:

Đặc tính điều khiển phiên bản trong EA cho phép: Sắp xếp việc chia sẻ cỏc gúigiữa người sử dụng với việc truy cập chỉ đọc hay truy cập cập nhật

Điều khiển phiên bản cung cấp 2 đặc tính chính như sau:

1.Chia sẻ cỏc gúi giữa các người sử dụng2.Lưu lại lịch sử sự thay đổi cỏc gúi EA bao gồm khả năng nhận cácphiên bản trước

3.User Security (bảo mật người sử dụng)