Tìm hiểu về quản lý yêu cầuvà kiểm thử tại phòng phát triển phần mềm trung tâm tin học trườngĐHKHTN xây dựng phần mềm hỗ trợ

Luận văn, khóa luận, chuyên đề, tiểu luận, quản trị, khoa học, tự nhiên, kinh tế

Chúng em xin chân thành cám ơn thầy Trần Đan Thư, thầy Nguyễn Trọng Tài

đã tận tâm hướng dẫn chúng em, giúp đỡ chúng em hoàn thành đề tài này

Chúng em cũng xin cám ơn các anh chị làm việc trong phòng phát triển phần mềm Trung tâm Tin học trường Đại học Khoa học Tự nhiên đã sẵn sàng giúp đỡ chúng

em, cung cấp các thông tin cho chúng em trong quá trình khảo sát Chúng em cũng xin cám ơn các thầy cô, cán bộ giảng viên trẻ đã nhiệt tình đóng góp những kinh nghiệm, ý kiến quý báu cho chúng em

Chúng em xin gửi lời cám ơn tất cả các quý thầy cô đã giảng dạy, cung cấp cho chúng em vốn kiến thức quý báu suốt những năm học vừa qua

Chúng em cám ơn khoa Công nghệ thông tin trường Đại học Khoa học Tự nhiên

đã tạo điều kiện cho chúng em thực hiện đề tài này

Chúng tôi cũng xin cám ơn các bạn đã nhiệt tình giúp đỡ khi chúng tôi vướng phải những khó khăn, động viên chúng tôi trong suốt quá trình thực hiện đề tài luận văn tốt nghiệp này

Mặc dù chúng em đã cố gắng rất nhiều để hoàn thành tốt luận văn, nhưng chắc chắn không tránh khỏi những thiếu sót, chúng em rất mong được sự cảm thông và tận tình giúp đỡ của quý thầy cô

Tp Hồ Chí Minh, 07/2004 Nhóm sinh viên thực hiện Nguyễn Khánh Chi- Tăng Nguyễn Trung Hiếu

KHOA CNTT –

ĐH KHTN

2

Sau cuộc khủng hoảng trong ngành công nghệ thông tin vào đầu những năm

2000, đến nay, công nghệ sản xuất phần mềm trên thế giới và nhất là Việt Nam đang tiến những bước tiến mạnh mẽ hơn Vượt qua cuộc khủng hoảng này, ngoài những kinh nghiệm trong kinh doanh, các công ty tin học Việt Nam nhận thức được rằng quy trình sản xuất phần mềm của chính công ty họ cần được nâng cấp với mục tiêu đầu tiên

là nâng cao chất lượng, gia tăng tính chuyên nghiệp trong sản xuất phần mềm

Một điều không thể tranh cãi , quy trình đóng một vai trò rất quan trọng trong việc sản xuất phần mềm Hiện nay có rất nhiều quy trình sản xuất phần mềm như Quy trình RUP, Quy trình xoắc ốc, Quy trình thác nước , nhưng điều cốt lõi nhất là ứng dụng những quy trình đó như thế nào và ứng dụng như vậy sẽ đạt được những thuận lợi

gì, quá trình sản xuất phần mềm có tốt hơn không, chất lượng phần mềm có được nâng cao hay không Trong một quy trình sản xuất phần mềm, ngoài việc thành lập các chuẩn coding, phân công sắp xếp các công việc cho các thành viên trong tổ chức, một yếu tố rất quan trọng là việc quản lý các tài liệu bao gồm các bản đặc tả yêu cầu, bản phân tích thiết kế chương trình, chương trình nguồn, các bản báo cáo kiểm thử và vô số những tài liệu không tên khác

Trong bối cảnh đó, chúng em đã thực hiện đề tài “Tìm hiểu về quản lý yêu cầu

và kiểm thử tại Phòng phát triển phần mềm Trung Tâm Tin Học trường ĐHKHTN_Xây dựng phần mềm hỗ trợ” nhằm có thể hiểu rõ hơn việc quản lý yêu cầu

và kiểm thử, những mục tiêu, thuận lợi mà hai tiến trình này đem lại

Đề tài này có thể được xem như một phần trong việc quản lý cấu hình, trong đó chú trọng ở hai giai đoạn khảo sát và kiểm thử Luận văn của chúng em được trình bày với tám chương chính, bao gồm :

KHOA CNTT –

ĐH KHTN

3

việc quản lý yêu cầu, quản lý kiểm thử

- Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử

hiện nay

- Chương 4 Giới thiệu về ứng dụng “Phần mềm quản lý yêu cầu và quản lý

kiểm thử” (Requirements and Testing Management)

- Chương 5 Thực hiện _ Kiểm tra ứng dụng

- Chương 6 Tổng kết

KHOA CNTT –

ĐH KHTN

4

Chương 1 Mở đầu 9

1.1 Khái quát vai trò quy trình phát triển phần mềm 9

1.2 Tầm quan trọng của việc quản lý quy trình 10

1.3 Hiện trạng phát triển phần mềm tại T3H 10

1.4 Đánh giá hiện trạng 19

1.4.1 Quản lý yêu cầu : 19

1.4.2 Quản lý kiểm thử : 19

1.5 Mục tiêu đề tài 20

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

2.1 Vai trò của việc quản lý chất lượng phần mềm 21

2.2 Tại sao cần quản lý chất lượng ? 24

2.3 Tổng quan về quản lý yêu cầu 25

2.3.1 Quản lý yêu cầu là gì ? 25

2.3.2 Các thông tin cần quản lý trong quản lý yêu cầu .25

2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI 27

2.4 Tổng quan về quản lý kiểm thử 28

2.4.1 Mục tiêu của quản lý kiểm thử 28

2.4.2 Các thông tin cần quản lý trong quản lý kiểm thử 29

2.4.3 Giới thiệu tiến trình Verification (VER) trong CMMI 30

Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay 32 3.1 Công cụ hỗ trợ quản lý yêu cầu 32

3.1.1 Giới thiệu : 32

3.1.2 Định nghĩa công cụ quản lý yêu cầu 33

3.1.3 Các loại công cụ 33

3.1.4 Tại sao phải sử dụng các công cụ quản lý yêu cầu : 34

3.1.5 Kiến trúc chức năng : 35

3.1.6 So sánh với các phần mềm có chức năng tương tự : 37

3.1.7 Đánh giá các công cụ quản lý yêu cầu 38

3.2 Công cụ kiểm thử : 38

3.2.1 Các loại công cụ kiểm thử : 38

3.2.2 Một số công cụ quản lý kiểm thử : 41

Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management) 44

4.1 Mục tiêu của ứng dụng 44

4.2 Thủ tục cho các quy trình được xây dựng mới 44

4.3 Đặc tả yêu cầu 49

KHOA CNTT –

ĐH KHTN

5

4.5 Mô hình dữ liệu 72

4.5.1 Kiến trúc hệ thống 73

4.5.2 Thiết kế màn hình 77

Chương 5 Thử nghiệm ứng dụng 89

5.1 Dữ liệu thử nghiệm 89

5.1.1 Giới thiệu project thử nghiệm : 89

5.1.2 Bộ dữ liệu thử nghiệm : 90

5.2 Kết quả thực hiện chương trình 91

Chương 6 Tổng kết 92

6.1 Tự đánh giá 92

6.1.1 Những kết quả đạt được : 92

6.2 Hướng phát triển của chương trình 93

Phụ lục 95

Phụ lục A Mô tả dữ liệu 95

Phụ lục B RM Tool Survey Summary [INCOSE] 98

KHOA CNTT –

ĐH KHTN

6

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

Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm 14

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

Hình 1-4 Mô hình kiểm thử tại T3H 18

Hình 2-1 Các hoạt động trong CM 22

Hình 2-2 Tổng quan về CM 23

Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI) 27

Hình 5-1 Mô hình tiến trình quản lý yêu cầu cho hệ thống mới 45

Hình 5-2 Mô hình quản lý kiểm thử cho hệ thống mới 48

Hình 5-3 Mô hình usecase 51

Hình 5-4 Kiến trúc hệ thống 73

Hình 5-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử 75

Hình 5-6 Các lớp xử lý yêu cầu 76

Hình 5-7 Các lớp xử lý kiểm thử 76

Hình 5-8 Sơ đồ màn hình cho phần truy cập cơ sở dữ liệu 77

Hình 5-9 Sơ đồ các trang tổng quát 77

Hình 5-10 Sơ đồ nhóm các màn hình liên quan đến phần quản lý yêu cầu 78

Hình 5-11 Sơ đồ các màn hình liên quan đến phần kiểm thử 79

Hình 5-12 MH Trang chính 80

Hình 5-13 MH.Thông tin yêu cầu tổng quát 81

Hình 5-14 MH Cập nhật tài liệu mô tả yêu cầu 82

Hình 5-15 MH Cây kiến trúc của project 83

Hình 5-16 MH Thiết lập mối liên hệ giữa các yêu cầu và phân hệ 84

Hình 5-17 MH Các release trong Project 84

Hình 5-18 MH Cập nhật môi trường kiểm tra 85

Hình 5-19 MH Các release và file đã được lập testcase 86

Hình 5-20 MH Cập nhật thông tin review 87

KHOA CNTT –

ĐH KHTN

7

được gắn liền với các tài liệu mô tả và các

dữ liệu có liên quan đến tác vụ của một

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

mong đợi của khách hàng, dựa vào những yêu cầu cho sản phẩm.[PGSQM]

Việc đảm bảo chất lượng _Quality Assurance hay Kiểm soát chất lượng _ Quality Control

Là một tập các hành động đã được dự định trước đó nhằm dò tìm, dẫn chứng qua các tài liệu, phân tích, và hiệu chỉnh các lỗi của sản phẩm cũng như quản lý các thay đổi của sản phẩm.[PGSQM]

Quản lý chất lượng _ Quality Management

Là việc ủy nhiệm, xúc tiến nhà sản xuất nhận ra, chấp thuận các cải tiến cho tiến trình sản xuất sản phẩm.[PGSQM]

Tin học trường Đại học Khoa học Khoa học Tự nhiên

chương trình đã hoàn tất

KHOA CNTT –

ĐH KHTN

9

Chương 1 Mở đầu

1.1 Khái quát vai trò quy trình phát triển phần mềm

Thưở ban đầu của ngành công nghiệp máy tính nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm được xem như một quá trình “viết và sửa” (code and fix), không có bất kỳ một kế hoạch nào trước đó Quá trình này thành công cho đến khi các chương trình phần mềm bắt đầu có quy môlớn hơn, độ phức tạp caohơn, cần có sự hợp tác của nhiều người hơn, do đó các phương pháp phát triển phần mềm hay quy trình phần mềm ra đời.Thực tế cho thấy, hầu hết các dự án thất bại do các nguyên nhân sau 1 :

· Hiểu không đúng yêu cầu người dùng

· Không thể thích ứng với các thay đổi về yêu cầu đối với hệ thống

· Các module không khớp với nhau

· Phần mềm khó bảo trì và nâng cấp, mở rộng

· Phát hiện trễ các lỗ hổng của dự án

· Chất lượng phần mềm kém

· Hiệu năng của phần mềm thấp

· Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi

· Quá trình build-and-release không đáng tin cậy

Để khắc phục những rủi ro này đòi hỏi việc phát triển phần mềm phải theo một quy trình cụ thể đảm bảo phần mềm được xây dựng đảm bảo được chất lượng, thỏa mãn các yêu cầu của người dùng

1 [LVRUP99]

KHOA CNTT –

ĐH KHTN

10

1.2 Tầm quan trọng của việc quản lý quy trình

Như đã đề cập ở trên, việc thỏa mãn nhu cầu (Fitness for purpose) của người dùng rất quan trọng, đó là đích cuối cùng cho mọi sản phẩm được sản xuất ra Vì vậy, việc đảm bảo chất lượng phần mềm cũng là một phần rất quan trọng trong quá trình sản xuất phần mềm và do đó, việc quản lý chất lượng cũng được đặt ra

Hơn thế nữa, quan điểm hiện đại về việc đảm bảo chất lượng ngày càng phức tạp hơn, không còn giới hạn ở mục tiêu thỏa yêu cầu khách hàng Một sản phẩm phần mềm chất lượng cao (high quality product) phải kết hợp được nhiều nhân tố chất lượng (quality factors) hay thuộc tính chất lượng (Quality Attributes), trong đó có thể chia làm ba loại, đó là những nhân tố có thể tìm thấy trong đặc tả yêu cầu ví dụ như tính linh động (portability), là “cutural factors” ví dụ như tính hiệu dụng (usability), và những nhân tố mà người lập trình sẽ chú trọng nhưng người dùng thì không, đơn cử là tính tái sử dụng (reusability) Để một sản phẩm đặt ra đạt được những nhân tố chất lượng này không phải là một việc dễ dàng, vì vậy, việc quản lý chất lượng phần mềm

là một công việc không thể tránh khỏi trong công nghệ phần mềm

1.3 Hiện trạng phát triển phần mềm tại T3H

T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau :

· Khảo sát hiện trạng – xác định yêu cầu

NV quản trị hệ thống

NV lập trình

NV kiểm tra

NV huấn luyện

NV quản lý cấu hình

NV phân tích _ thiết kế

NV phân tích _ thiết kế

NV lập trình

NV phân tích _ thiết kế

NV lập trình

NV huấn luyện

Lập kế hoạch & theo dõi tiến độâ

Lập giải pháp khả thi

Khảo sát phân tích

-Thiết kế phần mềm

Xây dựng phần mềm

Kiểm tra & thử nghiệm nội bộ

Triển khai

Hoàn chỉnh sản phẩm

Quản lý cấu hình

NV phân tích _ thiết kế

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

KHOA CNTT –

ĐH KHTN

12

MÔ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

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

- Tài liệu thiết kế phần mềm

3 Xác định yêu cầu nghiệp

- Kinh phí

- Thời gian thực hiện

6 Thương thảo hợp đồng

1 Khảo sát chi tiết

2 Mô tả và phân tích hiện trạng (chi tiết hơn Giải pháp khả thi) :

- Quy trình nghiệp vụ

- Sơ đồ tổ chức xử lý

- Mối liên quan với hệ thống khác

3 Phân tích sơ bộ

- Mô hình dữ liệu sơ bộ

- Yêu cầu nghiệp vụ

- Yêu cầu hệ thống

- Yêu cầu giao diện

- Yêu cầu sao lưu

- Yêu cầu bảo mật

- Yêu cầu đường truyền (gửi/nhận) dữ liệu

- Yêu cầu về chuyển đổi, cập nhật dữ liệu cũ

4 Tập hợp các tài liệu đã thu thập từ quá trình khảo sát

1 Thiết kế kiến trúc phần mềm

2 Thiết kế dữ liệu mức vật lý

3 Thiết kế chiến lược:

- Các quy ước chung

- Cơ chế phát sinh khóa

- Kiểm tra RBTV

- Xử lý và thông báo lỗi

- Sao lưu và phục hồi dữ liệu

- Các lớp đối tượng (hoặc màn hình) cơ sở

2 Thiết kế chi tiết chức năng

5.Thủ nghiệm chuyển đổi từ dữ liệu cũ

6 Lập tài liệu hướng dẫn

3 Xem xét và duyệt kết quả công việc

4 Tập huấn, chuyển giao kết quả công việc

KHOA CNTT –

ĐH KHTN

13

· Các vai trò tham gia trong một quy trình phát triển phần mềm

- NVPhân tích thiết kế - Quản trị hệ thống : hoạt động chủ yếu trong giai đoạn

lập giải pháp khả thi & khảo sát phân tích, các hồ sơ, tài liệu cuối cùng được lưu trữ chủ yếu là văn bản giấy, nếu có lưu trữ trên máy thì cũng lưu trữ trên máy của nhân viên phụ trách Sau khi kết thúc quá trình khảo sát, nhân viên ghi nhận các yêu cầu từ khách hàng, lưu lại dưới dạng document Khi có sửa đổi thì ghi nhận lại ngay trên document đó

- NV Phân tích thiết kế : Khảo sát phân tích, thiết kế phần mềm lưu lại dưới

dạng các document, không theo chuẩn nhất định và cũng được sửa chồng khi

có sự thay đổi Việc chuyển giao sang giai đoạn khác được thực hiện thông qua việc ký nhận văn bản

- NV Lập trình : chịu trách nhiệm lập trình, chỉnh sửa code, đưa ra các release

Mỗi nhóm lập trình sẽ được phân công từng module cụ thể Quản lý các phiên bản bằng Visual Source Safe Khi source code thay đổi sẽ phát sinh 1 phiên bản mới, tuy nhiên nó không thể hiện được sự thay đổi này ảnh hưởng đến những module nào Việc phân công coding cũng được thực hiện bằng tay

- NV Kiểm tra : Sau khi 1 module được coding xong hay đến 1 thời điểm quy

định, chương trình được test bởi nhóm NVKiểm tra Việc kiểm tra được thực hiện trên giấy Khi phát hiện lỗi, nhân viên kiểm tra ghi nhận lại lỗi, và thực hiện lặp lại cho đến hết module Sau khi test xong một module, bảng tường trình lỗi sẽ được gởi đến người chịu trách nhiệm đánh giá lỗi, thường là quản

lý dự án Nếu là lỗi có thể sửa sẽ đựơc xác nhận và chuyển giao cho bộ phận lập trình Nếu lỗi có thể bỏ qua, người quản lý dự án sẽ xác nhận và kết thúc việc test (xem chi tiết mô hình bên dưới)

- NV quản lý đề án : là người có chức vụ cao nhất trong quy trình phát triển

phần mềm, quản lý toàn bộ các thành viên, chịu trách nhiệm phân công, lên kế hoạch, theo dõi tiến độ thực hiện

- Trưởng dự án : chịu trách nhiệm xem xét duyệt lại các tài liệu, kiểm soát các

tiến trình, đảm bảo các tiến trình được thực hiện đúng đắn và đúng tiến độ

KHOA CNTT –

ĐH KHTN

14

- NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài liệu

cĩ liên quan đến đề án đang thực hiện như : quản lý các thành phần của từng phiên bản cĩ trong đề án, tạo các phiên bản test và phiên bản giao cho khách hàng, đĩng gĩi sản phẩm

- NV Quản lý kiểm thử : chịu trách nhiệm về việc lên kế hoạch kiểm thử, cho

từng giai đoạn của đề án, đánh giá kết quả của việc kiểm thử Và cùng với nhân viên quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử trong trường hợp chương trình vẫn cịn lỗi nhưng những lỗi đĩ khơng nghiêm trọng, cĩ thể chấp nhận để giao cho khách hàng vì thời giao đã gần kề

2/25/2004

Subtitle

Sơ đồ các vai trò trong một đề án

Wednesday, February 25, 2004

TRUNG TÂM TIN HỌC

Trường đại học Khoa học Tự nhiên Đại học Quốc gia TpHCM

PHÒNG PHÁT TRIỂN PHẦN MỀM

Quản lý dự án

Trưởng dự án

NV Quản lý cấu hình NV Quản lý kiểm thử

NV Phân tích thiết kế

NV Quản trị hệ thống

NV lập trình

NV kiểm thử

NV huấn luyện

Hình 1-2 Sơ đồ tổ chức các vai trị của nhân sự trong 1 đề án phần mềm

Trong các quy trình phát triển trên, đề tài chú trọng đến hai tiến trình : Quản

lý yêu cầu và quản lý kiểm thử

KHOA CNTT –

ĐH KHTN

15

· Quản lý yêu cầu

- Khách hàng đặt hàng, T3H đồng ý nhận đơn đặt hàng, chuẩn bị tiến hành khảo sát

- Quản lý dự án lập kế hoạch ban đầu, đặc tả các nhiệm vụ, phân công Bảng kế hoạch được in giấy, phân phát cho nhân viên liên quan

- Khảo sát viên tiến hành khảo sát, sau mỗi lần khảo sát, một bản mô tả hiện trạng, yêu cầu khách hàng được thiết lập Đến thời hạn, nhân viên này đưa bản báo cáo cuối cùng cho Quản lý dự án Khảo sát viên hoàn toàn tự quản lý các tài liệu này và chỉ giao cho Quản lý dự án bản cuối cùng

- Khi tiến hành phân tích thiết kế, phân tích viên hay nhân viên thiết kế

sẽ làm việc trên tài liệu mà Quản lý dự án đưa Nếu có thay đổi, nhân viên đó sẽ thay đổi trên tài liệu này, ghi nhận và đến thời hạn sẽ giao lại cho Quản lý dự án

- Cuối giai đoạn này, một bản đặc tả yêu cầu và phân tích thiết kế được đưa ra

- Thông thường, khảo sát viên, nhân viên phân tích thiết kế là một và là quản lý dự án

Quá trình này được mô hình hóa thông qua mô hình sau :

KHOA CNTT –

ĐH KHTN

16

QUẢN LÝ YÊU CẨU (Hệ thống hiện tại)

Khảo sát viên Trưởng dự ánKhảo sát viên

Trưởng dự án Quản lý dự án

Nhận đơn đặt hàng từ KH

Đưa ra các yêu cầu

Khách hàng chấp thuận bản yêu cầu

Kết thúc khảo sát

Bảng yêu cầu (tự quản lý thông tin)

Y N

Y N

Tài liệu đặc tả yêu cầu cuối cùng

Toản bộ các tiến trình được thực hiện bằng tay Các tài liệu được phát sinh trong giai đoạn này do người phụ trách tự quản lý Chỉ có bản yêu cầu cuối cùng được gửii cho các thành viên phát triển dự án

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

- Đến thời hạn, nhân viên này đưa lại cho trưởng bộ phận kiểm thử (Test manager) xem xét đánh giá lỗi trên tài liệu kiểm thử và đưa lại bản tài liệu đã được đánh giá cho người lập trình sửa lỗi

Quá trình này được mô hình hóa bên dưới :

KHOA CNTT –

ĐH KHTN

19

1.4 Đánh giá hiện trạng

1.4.1 Quản lý yêu cầu :

· Hiện tại T3H làm phần mềm có quy trình, các nhân viên đều nắm được nhưng việc thủ tục hóa từng quy trình không có, kết quả là không có một mẫu biểu chuẩn ghi nhận lại nên thông tin có thể không nhất quán

· Khi các yêu cầu thay đổi trong quá trình thực hiện đề án, nhân viên không nhất thiết phải ghi lại thông tin thay đổi nên có thể họ sẽ quên một số thông tin, điều này có thể gây ra sự bất đồng bộ trong việc thực hiện phần mềm ở những bộ phận khác nhau

· Đối với một công ty nhỏ như T3H chỉ gồm khoảng trên dưới 30 nhân viên thì việc trao đổi thông tin bằng miệng như hiện nay rất dễ dàng Khi có một vướng mắc nào đó họ có thể hỏi ngay tại đó để làm rõ vấn đề Nhưng đặt trường hợp PPTPM mở rộng, phát triền hơn thì với việc quản lý như hiện nay sẽ rất khó khăn

· Khi yêu cầu thay đổi, yêu cầu mới được ghi chồng lên các yêu cầu cũ mà không có sự ghi nhận rõ ràng ( người sửa, ngày sửa, nguyên nhân,…) do đó không lưu vết được các yêu cầu, gây ra khó khăn khi cần xem xét lại tài liệu hoặc truy cứu trách nhiệm khi yêu cầu sai

· Khi một yêu cầu được thay đổi người trưởng dự án không biết được yêu cầu này ảnh hưởng đến những module nào, và khó biết yêu cầu mới có bị trùng lặp với những yêu cầu cũ hay không

1.4.2 Quản lý kiểm thử :

· Như phần hiện trạng đã đề cập ở trên, các test case được chính người kiểm thử đề ra, và cũng người đó thực hiện việc kiểm tra, nên những người khác hoàn toàn không biết về những test case này nếu nó không có xảy ra lỗi Như vậy các nhân viên khác khó có thể học hỏi kinh nghiệm test cũng như chưa

kể người thực hiện kiểm thử có thể quên hoặc thiếu một số trường hợp test

có người gặp phải lỗi đó thì người đó có thể biết ngay cách chỉnh sửa Nhưng đặt trường hợp người đó không biết có người gặp phải lỗi này, thì người đó

có thể phải tự tìm tòi, chưa kể nếu lỗi đó xuất hiện nhiều lần lại phải tốn nhiều công sức đầu tư

· Do không quản lý phiên bản test, nên trong một sản phẩm, có những lỗi đã được phát hiện rồi, sửa rồi, nhưng phiên bản cuối cùng lại là phiên bản cũ, có lỗi

· Từ việc chuyển giao các test case đến người lập trình viên để cập nhật kết quả đến việc xem xét lại các testcase, cho đến việc kiểm và sữa chữa lỗi trải qua nhiều giai đoạn, do đó các hồ sơ dễ bị thất lạc và không đúng phiên bản hiện hành

1.5 Mục tiêu đề tài

Tìm hiểu về việc quản lý yêu cầu và quản lý kiểm thử trong quá trình phát triển phần mềm Ứng dụng xây dựng phần mềm hỗ trợ việc quản lý yêu cầu và kiểm thử tại T3H

· Tìm hiểu công việc quản lý yêu cầu và quản lý kiểm thử nhằm bảo đảm chất lượng phần mềm Trong đó, chú trọng các thông tin cần phải quản lý trong hai tiến trình này

· Ứng dụng những kiến thức đó, xây dựng chương trình nhằm cải tiến và

hỗ trợ công việc quản lý yêu cầu và quản lý kiểm thử tại Phòng phát triển phần mềm, Trung tâm Tin học trường Đại học Khoa học Tự nhiên

2.1 Vai trò của việc quản lý chất lượng phần mềm

Hệ thống quản lý chất lượng SQA hay SQS có hai mục tiêu chính :

· Đưa vào việc quản lý chất lượng ngay từ khi bắt tay vào xây dựng phần mềm

· Đảm bảo chất lượng trong suốt quá trình xây dựng phần mềm

Để đạt được hai mục tiêu trên, SQS đòi hỏi sự kết hợp của 10 yếu tố :

· Standards : là một yếu tố mấu chốt trong SQS Các chuẩn là nền tảng để

có thể đánh giá các hoạt động Hơn nữa, chúng cung cấp những phương thức thông thường mà theo đó cùng một công việc sẽ được hoàn thành theo cùng một cách mỗi khi nó được thực hiện Khi áp dụng các chuẩn trong phát triển phần mềm sẽ giúp cho việc đánh giá sự phát triển được đồng đều

· Reviewing : là một hoạt động rất quan trọng trong kiểm soát chất lượng Việc kiểm soát chất lượng liên quan với việc tìm kiếm các lỗi ở nhiều loại sản phẩm phần mềm trong suốt quá trình phát triển chúng Nếu như việc thanh tra mã nguồn cũng liên quan đến việc tìm lỗi thì việc kiểm duyệt lại

tỏ ra hiệu quả hơn vì nó tìm các lỗi sớm hơn

· Testing : mục đích của việc kiểm thử là tìm các lỗi và kiểm tra lại xem phần mềm có thỏa yêu cầu của người dùng đưa ra hay không Trong một

số trường hợp, công việc kiểm thử lại chú trọng vào việc kiểm tra xem phần mềm chạy đúng hay sai hơn là xem phần mềm có thỏa yêu cầu người dùng hay không Điều này hơi đi chệch hướng với mục đích của việc kiểm thử chương trình Nếu công việc kiểm thử không dựa trên mục tiêu thỏa mãn yêu cầu thì chỉ phí thời gian

là thiếu một hàm Khi phát hiện ra một lỗi, công việc đòi hỏi cần thực hiện là sửa lại cho nó đúng Việc phân tích lỗi được thực hiện trên tất cả các lỗi nhằm khắc phục các thiếu sót hiện tại và giảm thiểu số lượng lỗi trong tương lai

· Configuration management (CM) : CM đảm bảo tại bất kỳ thời điểm nào, tình trạng của phần mềm đều được xác định rõ và có thể tái cấu trúc lại

CM bao gồm ba yếu tố cơ bản : định danh cấu hình (configuration identification CID), kiểm soát cấu hình (configuration control CC) và configuration accounting (CA) tạm dịch là sự diễn giải cấu hình

Hình 2-1 Các hoạt động trong CM

CID cung cấp một phương pháp nhằm nhận dạng sự đặc trưng và tính duy nhất của mỗi instance (ví dụ như release, version) trong một sản phẩm phần mềm hay một tập các sản phẩm phần mềm Bằng cách sử dụng một chuẩn đặt tên để định danh mỗi một instance của sản phẩm, mỗi một hồ

CA giữ vai trò theo vết các tình trạng của các instance sản phẩm Điều này ngày càng quan trọng hơn trong việc tích hợp các phần hay module vào các hệ thống hoặc các hệ thống con CA theo vết các thay đổi của yêu cầu, thiết kế, kiểm thử, code, v.v

Hình 2-2 Tổng quan về CM

· Security : Các hoạt động bảo đảm an ninh được thực hiện đối với dữ liệu

và trung tâm lưu trữ dữ liệu Một hệ thống quản lý chất lượng tốt nhất nếu không có trung tâm lưu trữ dữ liệu sẽ rất dễ bị hư hại hoặc phá hủy hoàn

· Education : Việc huấn luyện hay đào tạo bảo đảm những thành viên phát triển dự án hoặc những người sẽ sử dụng phần mềm khi nó được hoàn tất đều có thể thực hiện công việc của họ một cách đúng đắn

Một điều rất quan trọng trong việc đảm bảo chất lượng phần mềm là thành viên sản xuất phải được đào tạo để có thể sử dụng nhiều công cụ phát triển khi được yêu cầu Vai trò của người đảm bảo chất lượng phần mềm là xem xét những kiến thức nào sẽ cần đến trong tương lai và trang

bị những kiến thức đó cho nhân viên của mình

· Vendor management : khi một phần mềm được hoàn tất, công việc phát hành cũng rất quan trọng Việc quản lý những công việc nhỏ nhặt xung quanh việc phát triển phần mềm như liên hệ mua bản quyền các phần mềm hỗ trợ cho việc phát triển, các phần mềm chống virus… cũng là một yếu tố trong việc đảm bảo chất lượng

· Safety : Mỗi đề án đều bắt buộc phải đảm bảo an toàn cho chính phần mềm đó và cho cả hệ thống Kế hoạch quản lý dự án nên có phần mô tả các giải pháp bảo đảm an toàn

· Risk management : Bất kỳ một đề án nào cũng chứa đựng nhiều loại rủi

ro, có loại rủi ro đơn giản đến những rủi ro có thể làm phá sản hoàn toàn

đề án Do đó, rủi ro và những giải pháp cho các giải pháp đó là một phần cần thiết trong kế hoạch quản lý dự án

2.2 Tại sao cần quản lý chất lượng ?

· Như đã trình bày ở trên, mục tiêu đầu tiên của phần mềm là thỏa mãn yêu cầu được đặt ra từ phía khách hàng

· Sự thành công của một dự án phụ thuộc vào một hệ thống quản lý yêu cầu hiệu quả

· Bằng một ít kỹ năng trong quản lý nhưng ta có thể giảm đáng kể các lỗi yêu cầu và vì vậy chất lượng phần mềm cũng được cải thiện

2.3 Tổng quan về quản lý yêu cầu

2.3.1 Quản lý yêu cầu là gì ?

Quản lý yêu cầu là một cách tiếp cận có hệ thống nhằm suy ra, tổ chức lại, ghi nhận ra tài liệu các yêu cầu Đây là một tiến trình cho phép thiết lập và duy trì hợp đồng giữa khách hàng và nhóm phát triển phần mềm khi có sự thay đổi yêu cầu trên

hệ thống 2

Ở đây, chúng tôi xin đề cập một chút về các khái niệm quan trọng trong định nghĩa trên :

· Đầu tiên, bất kỳ ai đã từng có liên quan đến các hệ thống phần mềm phức

tạp đều nhận ra rằng việc suy ra được các yêu cầu từ khách hàng là một

kỹ năng chủ yếu trong tiến trình khảo sát và đặc tả yêu cầu khách hàng

· Tiếp nữa, nếu một phần mềm chỉ cần hai người làm, độ mươi mười yêu cầu thì không có vấn đề gì, nhưng một hệ thống có cả trăm, nếu không

muốn nói hàng ngàn yêu cầu, thì việc quản lý thông tin đó thực sự rất cần

thiết

· Cuối cùng, có một điều rõ ràng là bộ óc chúng ta chỉ nhớ khoảng vài chục thông tin, vì vậy việc ghi nhận bằng tài liệu các yêu cầu cũng cần thiết, nhằm hỗ trợ mối liên lạc hiệu quả với khách hàng

2.3.2 Các thông tin cần quản lý trong quản lý yêu cầu

Tài liệu đầu tiên mà nhóm phát triển phần mềm nhận được từ khách hàng là bản liệt kê các yêu cầu Thông thường, tài liệu này rất trừu tượng Bản liệt kê có hai

2 [MSR] , Chapter 2, What is requirement management ?

Bản liệt kê yêu cầu gồm có hai phần quan trọng nhất, đó là các yêu cầu chức năng và yêu cầu ràng buộc Yêu cầu chức năng mô tả hệ thống cần làm những việc

gì, trong khi đó các yêu cầu ràng buộc có thể ràng buộc về sản phẩm hay ràng buộc trong tiến trình Ràng buộc sản phẩm chứa đựng các thông tin, tính chất mà sản phẩm sau khi được hoàn thành sẽ có Ràng buộc tiến trình quy định cách mà tiến trình phần mềm hay tập các tiến trình được thực hiện

Tài liệu quan trọng nhất trong bất kỳ đề án nào là bản đặc tả yêu cầu Đây là tài liệu cơ bản cho các tiến trình sau phân tích thiết kế và đặc tả yêu cầu như : đánh giá chi phí chi tiết, thiết kế hệ thống, cấu trúc hệ thống, lập các bộ test và soạn các tài liệu hướng dẫn

Bản đặc tả được phân cấp thành nhiều phần ví dụ như phân chia các hệ thống con, đặc tả dữ liệu, các chế độ của hệ điều hành, giao diện

Một bản đặc tả yêu cầu thường có các phần3 :

Tittle Contents Introduction About this document Glossary

System requirements Target system environment Customer-imposed constraints

Phần About this document : mô tả các quy ước đặt tên, phạm vi của tài liệu,

các chủ đề chính, các thành viên có liên quan, các chuẩn, cách mà bản đặc tả được thực hiện, và cuối dùng là danh sách các đặc tả

3 The structure of the requirements specification [SQA]

Target system environment : mô tả môi trường hệ thống sẽ được thiết lập

Phần cuối cùng Customer-imposed constraints sẽ liệt kê danh sách các ràng

buộc được đưa ra từ khách hàng

2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI

CMMI (Capability Maturity Model Integration) tích hơp các tiến trình cải tiến phần mềm, được phát hành phiên bản đầu tiên vào năm 2000 CMMI đưa ra năm mức độ trưởng thành hay năm tầng trưởng thành theo năng lực phần mềm theo thứ

tự từ cao xuống thấp như sau : Optimizing (Tối ưu hóa), Quantitatively Management (Được quản lý dựa vào định lượng), Defined (Được định nghĩa), Managed (Được quản lý), Initial (Khởi động)

Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI)

Các quy tắc thực tiễn chuyên biệt cho vùng tiến trình này :

· Hiểu rõ yêu cầu (Optain an understanding of Requirement), phát triển một

sự hiểu biết với những người cung cấp yêu cầu dựa trên ý nghĩa các yêu cầu

· Thống nhất về thực hiện yêu cầu (Obtain Commitment to Requirements) giữa các thành viên thực hiện dự án

· Quản lý thay đổi yêu cầu (Manage Requirement Changes) khi có sự thay đổi phát sinh trong suốt quá trình thực hiện dự án

· Duy trì mối liên hệ hai chiều (Mantain Bidirectional Tracebility of Requirements) giữa các yêu cầu, hoạch định đề án và các công việc sản xuất sản phẩm

· Xác định mâu thuẫn giữa yêu cầu và sản phẩm công việc (Identify Inconsistencies between Project work and Requirement )

Các vùng tiến trình liên quan đến RM : Phát triển yêu cầu_Requirement Development (RD), Hoạch định đề án_Project Plan (PP), Giải pháp kỹ thuật_ Technical Solution (TS), Quản lý cấu hình_Configuration Management (CM), Theo dõi và kiểm soát đề án_Project Monitoring and Control (PMC), Quản lý rủi ro_Risk Management (RKSM)

2.4 Tổng quan về quản lý kiểm thử

2.4.1 Mục tiêu của quản lý kiểm thử

· Gồm có ba mục tiêu chính : quản lý testcase, lập kế hoạch test, quản lý testscript

· Bảo đảm tiến trình kiểm thử được thực hiện một cách đúng đắn

· Theo vết các lỗi, xác định tình trạng của một lỗi tại bất kỳ thời điểm nào.

2.4.2 Các thông tin cần quản lý trong quản lý kiểm thử

Có rất nhiều tài liệu mô tả hệ thống và các tiến trình test trong giai đoạn này bao gồm :

· Tài liệu đặc tả thiết kế test

Tài liệu đặc tả thiết kế test : đây là một trong những tài liệu mô tả cách nào

các tính năng và các nhóm tính năng liên quan được kiểm thử Tài liệu này không chú trọng vào bất kỳ một kịch bản kiểm thử nào, ở đây chỉ mô tả đến các thuật ngữ dùng trong quá trình kiểm thử

Đặc tả kịch bản kiểm thử : tài liệu này mô tả các kịch bản test thành phần

Mỗi kịch bản kiểm thử được đánh mã duy nhất Trong kịch bản kiểm thử còn có :

Test input : bao gồm danh sách các dữ liệu được dùng cho việc kiểm thử

Nếu dữ liệu được lưu trong một file thì tên file đó phải được nêu

Test output : Kết quả mong đợi sau khi kiểm tra

Yêu cầu về cứng và phần mềm : mô tả những yêu cầu cho phần cứng và phần

mềm để thực hiện kịch bản kiểm tra bao gồm cả những phần mềm hay công cụ hỗ trợ việc kiểm tra và phiên bản hệ điều hành, các phiên bản các phần mềm hỗ trợ khác

KHOA CNTT –

ĐH KHTN

30

Các chỉ thị đặc biệt : nếu công việc kiểm thử đòi hỏi người kiểm thử thực

hiện bất kỳ hành động đặc biệt nào thì những hành động này đều phải được ghi nhận lại

Thủ tục kiểm thử : đây là tài liệu mô tả từng bước một công việc kiểm thử

được thực hiện cũng như cách tiến hành các bộ test tương tự khác Thủ tục kiểm thử cũng mô tả chi tiết làm thế nào tìm thấy item cần kiểm tra, loại item này là gì, và loại kiểm tra này là loại gì Thông thường, thủ tục kiểm tra được thực hiện cho nhóm kiểm tra độc lập, không biết rõ phần mềm mình đang kiểm thử

Test log : Mô tả điều gì xảy ra khi một kịch bản được thực hiện, trong đó mô

tả nội dung kiểm thử, thủ tục kiểm tra, việc xảy ra trong suốt quá trình test, phần cứng, phần mềm nào được sử dụng, mô tả bất kỳ hành động nào không được mong đợi, và nếu như bộ test nào không được pass thì phải có tham chiếu đến bảng báo cáo các lỗi

Bảng báo cáo lỗi : được phát sinh khi một thủ tục kiểm thử cho trước nào đó

không thực hiện đúng như mong đợi Tài liệu này bao gồm thông tin các sự kiện, môi trường phần cứng và phần mềm được sử dụng, khi nào thì lỗi phát sinh, và người thực hiện kiểm tra là ai

Tổng kết kiểm thử : Đây là bảng tổng kết các kịch bản kiểm tra Thông

thường công việc này được thực hiện sau việc kiểm tra một hệ thống con hay toàn

bộ hệ thống được hoàn tất Nội dung bảng tổng kết bao gồm danh sách các bộ test

đã được thực hiện, đánh giá mức độ hoàn thành, chi tiết các lỗi quan trọng và các thông tin chung như thời gian thực hiện việc kiểm tra là bao nhiêu

2.4.3 Giới thiệu tiến trình Verification (VER) trong CMMI

Mục đích của VER là đảm bảo rằng các sản phẩm được lựa chọn đáp ứng các yêu cầu đã được quy định cho chúng

VER gồm ba mục tiêu chuyên biệt :

· Chuẩn bị cho công tác kiểm tra (Prepare for Verification) trên sản phẩm

đã chọn

· Đối với mục tiêu Tiến hành xem xét ngang cấp , các tiến trình bao gồm :

- Chuẩn bị công tác xem xét ngang cấp (Prepare for Peer Review)

- Tiến hành công tác xem xét (Conduct Peer Review)

- Phân tích dữ liệu kết quả của quá trình xem xét (Analyze Peer Review Data)

· Đối với mục tiêu Kiểm tra các sản phẩm được chọn , các tiến trình bao gồm :

- Tiến hành kiểm tra (Perform Verification)

- Phân tích kết quả kiểm tra và xác định các hành động khắc phục (Analyze Verification Results and Identify Corrective Action)

Các tiến trình liên quan đến tiến trình này : Phát triển yêu cầu_Requirement Development (RD), Xác nhận_Validation (VAL), Quản lý yêu cầu_Requirement Management (RM)

KHOA CNTT –

ĐH KHTN

32

Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản

lý kiểm thử hiện nay

3.1 Công cụ hỗ trợ quản lý yêu cầu

3.1.1 Giới thiệu :

Ngày nay có rất nhiều công cụ hỗ trợ cho việc quản lý yêu cầu, nên việc chọn lựa công cụ quản lý yêu cầu cũng gặp khó khăn Để giải quyết vấn đề này, các nhà phân tích khuyên chúng ta nên lựa chọn dựa vào những yêu cầu của Project đang thực hiện hoặc những đòi hỏi của công ty hoặc thông qua sự tìm hiểu về các công cụ này Có hai yếu tố chính giúp chúng ta trong việc lựa chọn các công cụ, thứ nhất là chúng phải giúp chúng ta theo vết các yêu cầu một cách đầy đủ và thứ hai là

hỗ trợ việc kiểm thử một cách đặc biệt Kiểm thử là một phần của quy trình phát triển sản phẩm phần mềm, và nên được duy trì cùng với việc phát triển phần mềm,

vì vậy việc theo vết để kiểm thử rất quan trọng Thời gian để học và sử dụng công

cụ thông thường khoảng một tháng

Sau đây là danh sách các công cụ quản lý yêu cầu 4:

RM Tool List

Một công cụ quản lý yêu cầu sẽ không giải quyết những vấn đề bị gây ra bởi những yêu cầu kém chất lượng Bất kể công cụ có tốt như thế nào, những yêu cầu kém chất lượng rất khó để quản lý và có thể dẫn đến sự tranh cãi với khách hàng Những yêu cầu kém làm tăng chi phí và kéo dài thời gian Chúng làm cho sản phẩm bị lỗ hổng

và có thể dẫn đến dự án bị hủy bỏ

3.1.2 Định nghĩa công cụ quản lý yêu cầu

Một bộ công cụ quản lý yêu cầu là một bộ công cụ giúp cho việc quản lý yêu cầu được dễ dàng Những tính chất cơ bản cho một công cụ được xem là công cụ quản

lý yêu cầu [INCOSE]:

· Sự xác nhận những yêu cầu riêng biệt

· Sự phân phối và sắp xếp các yêu cầu

· Sự xác nhận việc duyệt lại nhóm yêu cầu

· Cung cấp việc ghép nối dữ liệu cơ bản Tất nhiên một phần của việc lưu trữ các yêu cầu này cũng được thực hiện tùy thuộc vào người dùng, có thể trên giấy hoặc trên các thiết bị điện tử

Một bộ công cụ có thể bao gồm một hoặc vài công cụ và những công cụ này đều có thể thực hiện những chức năng phụ trợ thêm cho việc quản lý yêu cầu

KHOA CNTT –

ĐH KHTN

34

· Theo vết yêu cầu : theo vết và thường xuyên chỉnh sửa những yêu cầu trong

số các tập hợp yêu cầu được đưa vào

· Phát sinh yêu cầu : phát sinh ra những tập hợp yêu cầu trong các công cụ Các bộ công cụ như vậy thông thường cũng có thể được dùng tương tự như những công cụ có trước khác

· Mô hình có sẵn và sự mô phỏng

3.1.4 Tại sao phải sử dụng các công cụ quản lý yêu cầu :

Để tối ưu hóa chi phí phát triển phát triển, sự trễ hạn, và chất lượng phần mềm, người quản lý phải quản lý các yêu cầu một cách chính xác Những nhà quản

lý doanh nghiệp định nghĩa các yêu cầu thương mại ở cấp độ cao Bộ phận chuyên môn về công nghệ thông tin cần phải chuyển các yêu cầu thương mại này thành những đặc tính chức năng để phát triển Bộ phận này cũng cần phải thống nhất với nhà quản lý doanh nghiệp về phạm vi của project và đưa vào bản miêu tả những yêu cầu phi chức năng như là mức độ phục vụ và tính dễ bảo trì

Phạm vi của dự án thay đổi khác nhau trong suốt thời gian phát triển Nhà quản lý doanh nghiệp đòi hỏi những chức năng mới, muốn có sự tích hợp mới và thường xuyên thay đổi ý kiến của họ Do đó, bộ phận công nghệ thông tin gặp khó khăn trong việc xác nhận sự ảnh hưởng của những yêu cầu mới trong project và cần phải xác nhận phạm vi của project sau khi thêm yêu cầu mới vào là hợp lệ

Bộ phận công nghệ thông tin muốn xác nhận những yêu cầu tương tự trong những dự án khác nhau để sử dụng lại các những gì đã được phát triển trước đó Điều này giúp tiết kiệm thời gian cho việc thiết kế, phát triển và kiểm thử cho những yêu cầu tương tự

Những công cụ quản lý yêu cầu rất hữu dụng trong việc điều khiển chất lượng của việc phát triển phần mềm Nó làm việc quản lý yêu cầu được dễ dàng hơn

và đảm bảo sự toàn vẹn cho quy trình phát triển Nó giúp cho doanh nghiệp và bộ phận tin học thống nhất với nhau về phạm vi của dự án bằng cách quản lý độ ưu tiên

3.1.5 Kiến trúc chức năng :

Những công cụ quản lý yêu cầu cung cấp những chức năng sau :

· Tạo lập yêu cầu : Các yêu cầu có thể được tạo lập bằng cách phân tích cấu trúc của các tập tin bên ngoài Chúng có thể được định nghĩa trực tiếp từ giao diện người dùng của phần mềm Nó giúp người dùng phân loại những yêu cầu trong project và thư mục

· Cải tiến các yêu cầu : Ngay khi những yêu cầu thương mại được đưa ra từ khách hàng, người quản lý dự án cần phải tìm ra những yêu cầu chức năng một cách nhanh chóng và tác vụ cần phát triển một cách chính xác Ngoài ra các công cụ này cũng giúp liên kết các yêu cầu khác nhau trong những bước phát triển của dự án

· Phân tích các yêu cầu : Các yêu cầu được phân tích để đảm bảo tính nhất quán của nó Ngay khi những yêu cầu được lấy, các công cụ sẽ theo dõi nguồn gốc của nó Hơn nữa các công cụ này còn giúp chúng ta hiểu được các tình trạng của yêu cầu ở tất cả cấp độ của project và phân tích sự ảnh hưởng của việc thay đổi yêu cầu đối với project

· Quản lý thay đổi của những yêu cầu : Các công cụ quản lý yêu cầu giúp người dùng có thể điều khiển được sự truy xuất những yêu cầu đã được định nghĩa Nó giúp cho việc quản lý yêu cầu được đồng nhất bằng cách quản lý những phiên bản dựa trên các thay đổi được đưa vào Những thay đổi này được ghi nhận lại trong lịch sử thay đổi của yêu cầu

KHOA CNTT –

ĐH KHTN

36

Những công cụ quản lý yêu cầu cung cấp các khả năng đặc biệt làm cho việc quản

lý yêu cầu bởi nhiều người sử dụng được dễ dàng hơn :

· Khả năng cộng tác : Các yêu cầu được quản lý bởi những người khác nhau Các công cụ quản lý yêu cầu giúp tổ chức công việc giữa các yêu cầu Chúng cho phép việc truy xuất đồng thời vào các yêu cầu và cung cấp khả năng làm việc theo luồng để quản lý sự các tiến trình định nghĩa yêu cầu, dẫn xuất và thay đổi Nó cũng hỗ trợ cho các cổng liên lạc như e-mail và diễn đàn thảo luận để làm cho việc truyền đạt thông tin về các yêu cầu được dễ dàng hơn

· Khả năng tích hợp : Các yêu cầu phải được thiết kế và phát triển ứng dụng phần mềm Những công cụ quản lý yêu cầu tích hợp vào các công cụ thiết

kế, phát triển và kiểm thử Nó cũng tích hợp vào các công cụ quản lý dự án phần mềm, hay các công cụ của các sản phẩm phổ biến như mục giúp đỡ của các trình xử lý văn bản trong việc thay đổi nội dung của yêu cầu Nội dung của yêu cầu và những thông tin khác ( tự điển dùng để phân tích các yêu cầu, siêu dữ liệu về yêu cầu, mẫu kết xuất, và những tài liệu liên quan đến yêu cầu) được lưu trong một kho chứa Việc mở các thư mục này đảm bảo việc truy xuất các thông tin

Hình 3-1 Kiến trúc chức năng của các công cụ quản lý yêu cầu

KHOA CNTT –

ĐH KHTN

37

3.1.6 So sánh với các phần mềm có chức năng tương tự :

· Các công cụ quản lý yêu cầu giúp chúng ta ghi nhận, phân tích, thay đổi và cải tiến các yêu cầu đồng thời đảm bảo sự đồng nhất của nó thông qua việc theo vết các yêu cầu và xem xét sự phụ thuộc của nó

· Các công cụ quản lý yêu cầu khác với các công cụ xử lý văn bản vì các công

cụ xử lý này thiếu những đặc tính hỗ trợ cho sự theo vết các yêu cầu, một vài trình xử lý văn bản như Word (Microsoft), WordPerfect (Corel) và StarWriter (Sun Microsystems)

· Các công cụ này cũng khác với những công cụ quản lý dự án vì các công cụ này không đưa vào bản miêu tả sự nắm bắt và cải tiến yêu cầu Các công cụ quản lý yêu cầu dựa trên những công cụ này để theo dõi sự hoàn thành các tác vụ Một vài công cụ quản lý dự án như : AllFusion Project Planner (CA), Niku (Niku), TeamPlay (Primavera) and Project (Microsoft)

· Những công cụ quản lý yêu cầu khác với các công cụ quản lý phiên bản Những công cụ quản lý yêu cầu hoặc cung cấp những đặc tính quản lý phiên bản của riêng nó hoặc dựa trên những công cụ thuộc lớp thứ ba Một vài công cụ quản lý phiên bản như : SourceSafe (Microsoft), PVCS Version Manager (Merant) và CVS (Concurrent Versions System, một dự án mã nguồn mở)

KHOA CNTT –

ĐH KHTN

38

Hình 3-2 Mối liên hệ giữa quản lý yêu cầu và các hoạt động khác

3.1.7 Đánh giá các công cụ quản lý yêu cầu 5

3.2 Công cụ kiểm thử :

3.2.1 Các loại công cụ kiểm thử :

· Công cụ kiểm thử dựa trên yêu cầu : Công cụ thiết kế Test case chức năng, làm sáng tỏ yêu cầu ứng dụng, và sử dụng “yêu cầu” như là cơ sở cho việc thiết kế kiểm thử

· Công cụ quản lý kiểm thử : Theo dõi tất cả các tài liệu kiểm thử thông qua một kho chứa thông tin chung

và chứa đựng các nội dung như kế hoạch kiểm thử (test plan), trường hợp kiểm thử ( test case), kịch bản test (test script)

· Công cụ kiểm thử hồi quy : Mỗi sự thay đổi code, cải tiến, sửa lỗi, và các phần nền tảng đòi hỏi cần phải

có sự kiểm thử lại toàn bộ ứng dụng để đảm bảo chất lượng của phiên bản phát hành

· Công cụ phân tích thông tin Mục đích của nó là giám sát hệ thống trong khi một công cụ kiểm thử tự động được thực thi

· Công cụ kiểm thử động

Nó bao gồm một chuỗi thứ tự các chỉ thị của máy tính Mục đích của công cụ test động là để khảo sát một chương trình đối xử và hoạt độmg của hệ thống trong khi nó thực thi

· Công cụ kiểm thử tĩnh Mục đích của nó nhằm phát hiện các lỗi bằng cách khảo sát phần mềm hơn

là thực thi

· Công cụ quản lý Website

5 Tham khảo phụ lục B

Sau đây là bảng so sánh các chức năng của các công cụ test :

6 Lecture NoteSWE 637 Software Testing and Quality AssuranceYe Wu

KHOA CNTT –

ĐH KHTN

40