Tài liệu tham khảo hỗ trợ môn học CÔNG NGHỆ PHẦN MỀM

Tài liệu tham khảo hỗ trợ môn học CÔNG NGHỆ PHẦN MỀM

Tài liệu tham khảo hỗ trợ môn học

CÔNG NGHỆ PHẦN MỀM

H n i, 2009à nội, 2009 ội, 2009

CHƯƠNG 1 TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 3

1.1 ÔI I U V V N ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ ỀU VỀ VẤN ĐỀ THUẬT NGỮ ỀU VỀ VẤN ĐỀ THUẬT NGỮ ẤN ĐỀ THUẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỀU VỀ VẤN ĐỀ THUẬT NGỮ THU T NGẬT NGỮ Ữ 3

1.2 CÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỊNH NGHĨA VÀ THUẬT NGỮNH NGH A VÀ THU T NGĨA VÀ THUẬT NGỮ ẬT NGỮ Ữ 3

1.3 PH M VI C A CÔNG NGH PH N M MẠM VI CỦA CÔNG NGHỆ PHẦN MỀM ỦA CÔNG NGHỆ PHẦN MỀM Ệ PHẦN MỀM ẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ 6

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 2 QUY TRÌNH LÀM PH N M MẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ 14

2.1 MỞ ĐẦU ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẦN MỀM 14U 2.2 KHÁCH HÀNG, NGƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI PHÁT TRI N VÀ NGỂN VÀ NGƯỜI SỬ DỤNG ƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNG Ử DỤNG ỤNGI S D NG 14

2.3 PHA XÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỊNH NGHĨA VÀ THUẬT NGỮNH YÊU C UẦN MỀM 14

2.4 PHA ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)C T (HAY PHÂN T CH)Ả (HAY PHÂN TÍCH) ÍCH) 15

2.5 PHA THI T KẾT KẾ ẾT KẾ 17

2.6 PHA CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH) 18T 2.7 PHA T CH HÍCH) ỢP 18P 2.8 PHA B O TRÌẢ (HAY PHÂN TÍCH) 19

2.9 THÔI S D NGỬ DỤNG ỤNG 20

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 3 CÁC MÔ HÌNH VÒNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI PH N M MẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ 21

3.1 MÔ HÌNH XÂY D NG-VÀ-HI U CH NH (BUILD-AND-FIX MODEL)ỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL) Ệ PHẦN MỀM ỈNH (BUILD-AND-FIX MODEL) 21

3.2 MÔ HÌNH THÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỔ (WATERFALL MODEL) (WATERFALL MODEL) 22

3.3 MÔ HÌNH B N M U (RAPID PROTOTYPING MODEL)Ả (HAY PHÂN TÍCH) ẪU (RAPID PROTOTYPING MODEL) 23

3.4 MÔ HÌNH T NG D N (INCREMENTAL MODEL)ĂNG DẦN (INCREMENTAL MODEL) ẦN MỀM 25

3.5 MÔ HÌNH T NG D N ĂNG DẦN (INCREMENTAL MODEL) ẦN MỀM ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL)NG THỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI (CONCURRENT INCREMENTAL MODEL)27 3.6 MÔ HÌNH ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL)NG B -VÀ- N Ộ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL) Ổ (WATERFALL MODEL) ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỊNH NGHĨA VÀ THUẬT NGỮNH (SYNCHRONIZE-AND-STABILIZE MODEL)28 3.7 MÔ HÌNH XO N C (SPIRAL MODEL)ẮN ỐC (SPIRAL MODEL) ỐC (SPIRAL MODEL) 28

3.8 MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG (OBJECT-ORIENTED MODEL) 31

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 5 PHA XÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỊNH NGHĨA VÀ THUẬT NGỮNH YÊU C UẦN MỀM 32

5.1 N M B T YÊU C UẮN ỐC (SPIRAL MODEL) ẮN ỐC (SPIRAL MODEL) ẦN MỀM 32

5.2 PHÂN T CH YÊU C UÍCH) ẦN MỀM 33

5.3 LÀM B N M U (PROTOTYPING)Ả (HAY PHÂN TÍCH) ẪU (RAPID PROTOTYPING MODEL) 33

5.4 T NH THÂN THI N VÍCH) Ệ PHẦN MỀM ỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)I NGƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI D NG C A PH N M MÙNG CỦA PHẦN MỀM ỦA CÔNG NGHỆ PHẦN MỀM ẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ 34

5.5 B N M U NH M T K THU T Ả (HAY PHÂN TÍCH) ẪU (RAPID PROTOTYPING MODEL) Ư Ộ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL) Ỹ THUẬT ĐẶC TẢ ẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)C TẢ (HAY PHÂN TÍCH) 34

5.6 CÓ NÊN S D NG L I B N M U?Ử DỤNG ỤNG ẠM VI CỦA CÔNG NGHỆ PHẦN MỀM Ả (HAY PHÂN TÍCH) ẪU (RAPID PROTOTYPING MODEL) 35

5.7 S D NG CÁC CÔNG C CASE TRONG PHA YÊU C UỬ DỤNG ỤNG ỤNG ẦN MỀM 35

5.8 CÓ KHÁI NI M YÊU C U HỆ PHẦN MỀM ẦN MỀM ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG KHÔNG? 35

5.9 TÓM T T CHẲT CHƯƠNG ƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 36

5.10 PHA YÊU C U: TÌM HI U V N ẦN MỀM ỂN VÀ NGƯỜI SỬ DỤNG ẤN ĐỀ THUẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỀU VỀ VẤN ĐỀ THUẬT NGỮ AIR GOURMET 36

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 6 PHA ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)C T CÓ C U TRÚCẢ (HAY PHÂN TÍCH) ẤN ĐỀ THUẬT NGỮ 39

6.1 TÀI LI U Ệ PHẦN MỀM ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)C TẢ (HAY PHÂN TÍCH) 39

6.2 PHÂN T CH H TH NG B NG PHÍCH) Ệ PHẦN MỀM ỐC (SPIRAL MODEL) ẰNG PHƯƠNG PHÁP CẤU TRÚC ƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG PHÁP C U TRÚCẤN ĐỀ THUẬT NGỮ 40

6.3 PHÂN T CH H TH NG V D LI UÍCH) Ệ PHẦN MỀM ỐC (SPIRAL MODEL) ỀU VỀ VẤN ĐỀ THUẬT NGỮ Ữ Ệ PHẦN MỀM 49

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 7 T NG QUAN V UML VÀ PHỔ (WATERFALL MODEL) ỀU VỀ VẤN ĐỀ THUẬT NGỮ ƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG PHÁP HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 53

7.1 S RA ỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL) ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI C A PHỦA CÔNG NGHỆ PHẦN MỀM ƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG PHÁP HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 53

7.2 T NG QUAN V NGÔN NG UMLỔ (WATERFALL MODEL) ỀU VỀ VẤN ĐỀ THUẬT NGỮ Ữ 53

7.3 MÔ HÌNH USE-CASE 56

7.4 MÔ HÌNH LỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL) 67P 7.5 BI U ỂN VÀ NGƯỜI SỬ DỤNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL) HO T ẠM VI CỦA CÔNG NGHỆ PHẦN MỀM ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL)NG 74

7.6 BI U ỂN VÀ NGƯỜI SỬ DỤNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL) TR NG THÁIẠM VI CỦA CÔNG NGHỆ PHẦN MỀM 79

Chương 1 Tổng quan về công nghệ phần mềm

7.7 BI U ỂN VÀ NGƯỜI SỬ DỤNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL) TU N TẦN MỀM ỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL) 80

7.8 BI U ỂN VÀ NGƯỜI SỬ DỤNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỒNG THỜI (CONCURRENT INCREMENTAL MODEL) Ộ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL) C NG TÁC 82

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 8 PHA PHÂN T CH HÍCH) ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 83

8.1 PHÂN T CH HÍCH) ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 83

8.2 QU N LÝ THÔNG TIN V CH Ả (HAY PHÂN TÍCH) ỀU VỀ VẤN ĐỀ THUẬT NGỮ ẾT KẾ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL) ĂNG DẦN (INCREMENTAL MODEL) ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH) N C BI T TRÊN MÁY BAYỆ PHẦN MỀM 83

8.3 NH NG V N Ữ ẤN ĐỀ THUẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỀU VỀ VẤN ĐỀ THUẬT NGỮ ẦN MỀM C N CHÚ Ý TRONG PHA PHÂN T CHÍCH) 89

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 9 PHA THI T KẾT KẾ ẾT KẾ 91

9.1 THI T K VÀ S TR U TẾT KẾ ẾT KẾ ỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL) ỪU TƯỢNG HÓA (DESIGN AND ABSTRACTION) ƯỢPNG HÓA (DESIGN AND ABSTRACTION) 91

9.2 THI T K HẾT KẾ ẾT KẾ ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG HÀNH ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL)NG 92

9.3 PHÂN T CH DÒNG D LI UÍCH) Ữ Ệ PHẦN MỀM 92

9.4 THI T K HẾT KẾ ẾT KẾ ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 94

9.5 NH NG THÁCH TH C TRONG PHA THI T K HỮ ỨC TRONG PHA THIẾT KẾ HƯỚNG ĐỐI TƯỢNG ẾT KẾ ẾT KẾ ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 100

9.6 THÊM M T S GHI CHÚ V V N Ộ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL) ỐC (SPIRAL MODEL) ỀU VỀ VẤN ĐỀ THUẬT NGỮ ẤN ĐỀ THUẬT NGỮ ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỀU VỀ VẤN ĐỀ THUẬT NGỮ THI T K HẾT KẾ ẾT KẾ ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 100

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 10 PHA CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)T VÀ T CH HÍCH) ỢP 101P 10.1 L A CH N NGÔN NG L P TRÌNHỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL) ỌN NGÔN NGỮ LẬP TRÌNH Ữ ẬT NGỮ 101

10.2 CÁC PHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG PHÁP CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)T VÀ T CH HÍCH) ỢP 102P 10.3 KI M TH S N PH M PH N M MỂN VÀ NGƯỜI SỬ DỤNG Ử DỤNG Ả (HAY PHÂN TÍCH) ẨM PHẦN MỀM ẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ 103

10.4 KI M TH CH P NH NỂN VÀ NGƯỜI SỬ DỤNG Ử DỤNG ẤN ĐỀ THUẬT NGỮ ẬT NGỮ 104

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 11 PHA B O TRÌẢ (HAY PHÂN TÍCH) 106

11.1 VÌ SAO B O TRÌ LÀ C N THI T?Ả (HAY PHÂN TÍCH) ẦN MỀM ẾT KẾ 106

11.2 B O TRÌ PH N M M HẢ (HAY PHÂN TÍCH) ẦN MỀM ỀU VỀ VẤN ĐỀ THUẬT NGỮ ƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)NG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG 106

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀMNG 12 CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)T OOD B NG NGÔN NG L P TRÌNH KHÔNG H TRẰNG PHƯƠNG PHÁP CẤU TRÚC Ữ ẬT NGỮ Ỗ TRỢ HĐT ỢP ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ 108 H T 12.1 MỞ ĐẦU ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẦN MỀM 108U 12.2 CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)T CÁC LỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)P VÀ CÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL)C L PẬT NGỮ 109

12.3 CÀI ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮẶC TẢ (HAY PHÂN TÍCH)T CÁC LỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)P VÀ CÁC ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮỐC (SPIRAL MODEL)I TƯỢPNG CÓ T NH TH A KÍCH) ỪU TƯỢNG HÓA (DESIGN AND ABSTRACTION) ẾT KẾ 112

12.4 ÔI LĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ ỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNGI K T LU NẾT KẾ ẬT NGỮ 113

2

Chương 1 Tổng quan về công nghệ phần mềm

CHƯƠNG 1 TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM

1.1 ĐÔI ĐIỀU VỀ VẤN ĐỀ THUẬT NGỮ

Theo tiếng Anh thì công nghệ là technology, còn phần mềm là software Như vậy công nghệ

phần mềm phải chăng theo tiếng Anh là “software technology”? Tuy nhiên thực tế lại khôngphải vậy Trong tiếng Anh không có thuật ngữ “software technology” trong các từ điển tin học

hay bách khoa toàn thư, mà chỉ có thuật ngữ “software engineering” Từ “engineering” có

nghĩa là “kỹ nghệ” Cũng chính vì vậy mà trong một số tài liệu có một số tác giả dùng thuật ngữ

“kỹ nghệ phần mềm” Ở Việt nam người ta quen dùng từ "công nghệ" hơn Do đó phần lớn cáctrường vẫn gọi môn học “software engineering” là “công nghệ phần mềm” Ở đây chúng tôicũng dùng thuật ngữ này trên tinh thần như vậy

Ngày nay kho kiến thức của loài người ngày càng được mở rộng, nhiều ngành khoa học đã ápdụng các thành tựu của nhau và do đó ranh giới giữa chúng không còn rõ ràng như trước đây.Việc định nghĩa chính xác các khái niệm cũng trở nên khó khăn và khó nhất quán Cùng mộtkhái niệm, cùng một thuật ngữ nhưng trong một hoàn cảnh nhất định lại được hiểu khác đi Lấy

ví dụ ngay trong lĩnh vực tin học: thuật ngữ "hệ thống" (system) có khi được hiểu là một tập hợp

các chương trình giải quyết một vấn đề nào đó, ví dụ operating system hay management information system; nhưng có khi bao hàm cả các chương trình và thiết bị phần cứng, ví dụ computer system hay the flight control system Chính Stephen R Schach, tác giả cuốn

"Object-Oriented and Classical Software Engineering" cũng phải thốt lên rằng, tác giả đã quámệt khi phải đánh vật với cối xay gió (tác giả ám chỉ việc sử dụng thuật ngữ) và mong các bạnđọc thông cảm

Trong bối cảnh đó, các định nghĩa chúng tôi nêu ra sau đây chỉ nhằm mục đích cung cấp cho cácbạn một sự hình dung về các khái niệm Như vậy các bạn chỉ cần hiểu, và có thể diễn đạt lại theocách suy nghĩ của mình, chứ không cần học thuộc từng chữ các khái niệm này Có một số kháiniệm các bạn có thể chưa hiểu ngay khi đọc lần đầu Trong trường hợp này các bạn cứ tạm chấpnhận rồi tìm hiểu sau

1.2 CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ

1.2.1 Một số khái niệm chung

Khoa học (science) là hệ thống các tri thức do con người khám phá ra Khoa học tập trung

vào việc tìm hiểu và rút ra các quy luật thực tế (của tự nhiên và của con người) Các quy luật nàythường được phát biểu dưới dạng các định lý, các mệnh đề, các công thức toán học, các bàiviết ví dụ định luật vạn vật hấp dẫn, định lý Pitagor, quy luật giá trị thặng dư Khoa học đượcchia thành các nghành như toán học, hóa học, sinh học, văn học, lịch sử,

Kỹ thuật (technique) là chỉ ra một cách thức tiến hành một công việc cụ thể nào đó Cách

làm này thường có áp dụng kiến thức khoa học và được hệ thống thành các bước sao cho những

người khác cũng có thể học và làm theo Ví dụ kỹ thuật hàn, kỹ thuật tân trang xe máy Trong tin học ta nói đến kỹ thuật phần mềm bao gồm kỹ thuật viết hệ điều hành, kỹ thuật làm chương

trình điều khiển Ta cũng hay nói “kỹ thuật lập trình” tức là cách thức viết chương trình sao chotối ưu theo một nghĩa nào đó

Công nghệ (technology) nói tới cách thức hay phương pháp để làm một việc gì đó, cụ thể

hoặc trừu tượng, có áp dụng các thành tựu của khoa học và được thực hiện một cách có bài bản,

hệ thống Ta thường nói “công nghệ sinh học”, “công nghệ jen”, hay “công nghệ giáo dục” Như thế, “công nghệ” có thể được hiểu là khái niệm rộng hơn khái niệm kỹ thuật Kỹ thuật nóitới cách thực hiện chi tiết, còn công nghệ thì nhấn mạnh tính hệ thống, bài bản

Kỹ nghệ (engineering) là việc sử dụng phối hợp các công nghệ cần thiết để tạo ra các sản

phẩm

Công nghiệp (industry) là khái niệm bao trùm cả một nghành lớn, trong đó bên cạnh yếu tố

kỹ nghệ còn có thêm các yếu tố khác như kinh tế, tài chính, tổ chức xã hội

Câu sau đây cho chúng ta cách hình dung về mối liên quan của các khái niệm vừa nói (trừ khái

Chương 1 Tổng quan về công nghệ phần mềm

niệm khoa học):

Trong ngành công nghiệp xe hơi, kỹ nghệ xe hơi cần đến các kỹ thuật đúc hàn của công nghệ cơ khí, kỹ thuật làm lốp xe của công nghệ cao

1.2.2 Một số khái niệm liên quan đến công nghệ phần mềm

Phần cứng (hardware) là các thiết bị cấu kiện mang tính vật lý có thể tiếp xúc bằng tay được

như máy in, ổ đĩa, máy quét, các mạch tích hợp (IC)

Nghĩa đơn giản nhất của phần mềm (software) là các chương trình chứa các dòng lệnh chỉ thị

cho máy tính thực hiện một công việc nào đó Tuy nhiên thường người ta hiểu phần mềm là mộttập hợp các chương trình và cả dữ liệu phục vụ cho một công việc được tin học hóa nào đó Ví

dụ phần mềm quản lý các dịch vụ bay, phần mềm điều khiển lò phản ứng hạt nhân, phần mềmđiều khiển dịch vụ mobile phone Đôi khi người ta gọi phần mềm là chương trình, cho dù thực

tế thì phần mềm gồm nhiều chương trình và dữ liệu Ví dụ: chương trình quản lý nhân sự,chương trình quản lý tín dụng

Trong công nghệ phần mềm, người ta hiểu phần mềm không chỉ là các chương trình, dữ liệu,

mà còn gồm cả các tài liệu liên quan như các bản đặc tả, thiết kế, hướng dẫn sử dụng.

Chương trình (program): đôi khi người ta gọi phần mềm là chương trình Hay chính xác hơn,

người ta thường gọi phần được cài đặt trên máy tính để chạy là chương trình Với cách hiểu như

vậy thì phần mềm = chương trình + tài liệu Tuy nhiên, trong thực tế có khi người ta đồng nhấthai khái niệm này Ví dụ người ta nói rằng "phần mềm được cài đặt trên máy tính khách hàng"

Kỹ nghệ phần mềm (software engineering) là cách làm phần mềm tuân theo những nguyên tắc

tương tự như các nguyên tắc của kỹ nghệ truyền thống (ví dụ kỹ nghệ xây dựng cầu, kỹ nghệlàm đường, )

Như chúng tôi đã nói tới ở trên, do thói quen, chúng ta dùng từ công nghệ phần mềm thay cho

từ được dịch đúng nghĩa hơn là kỹ nghệ phần mềm.

Vòng đời phần mềm (software life-cycle) là các bước mà một phần mềm phải trải qua, bắt đầu

từ khảo sát nhu cầu khách hàng cho đến khi phần mềm không còn được sử dụng

Phát triển phần mềm (software developement) quá trình xây dựng phần mềm từ bắt đầu cho

đến khi chuyển giao cho khách hàng

Người phát triển (software developer) là tên gọi chung cho những người tham gia xây dựng

phần mềm

Nhóm đảm bảo chất lượng phần mềm (software quality assurance group = SQA group) nhóm

chuyên kiểm tra chất lượng phần mềm, kiểm tra kết quả của từng giai đoạn xây dựng phần mềm

Quy trình phần mềm (software process) là cách thức làm ra phần mềm, bao gồm vòng đời

phần mềm, các công cụ và những người phát triển phần mềm

Pha (phase) là một giai đoạn trong quá trình xây dựng phần mềm Ví dụ pha xác định yêu cầu,

pha phân tích

Yêu cầu (requirements) là pha đầu tiên trong quá trình xây dựng phần mềm Pha này thường có

tên gọi là tìm hiểu khái niệm (concept exploration) Người phát triển và khách hàng ngồi lại vớinhau Khách hàng nêu ra những yêu cầu mà phần mềm phải có Những người phát triển ghi chéplại Nếu dịch theo tiếng Anh "requirements phase" là pha yêu cầu Tuy nhiên cách gọi quá đơn

4

Chương 1 Tổng quan về công nghệ phần mềm

giản như thế này có thể hơi khó hiểu, do đó ta sẽ gọi là pha xác định yêu cầu

Đặc tả (specification) hoặc phân tích (analysis): Trên cơ sở những yêu cầu của khách hàng,

người phát triển mô tả lại chính xác hơn các yêu cầu mà phần mềm phải có Cách mô tả này cótính chuyên môn và đôi khi sử dụng các công cụ trợ giúp Pha này trả lời câu hỏi "phần mềmlàm cái gì?"

Phân tích hệ thống (system analysis) người ta thường gộp hai pha yêu cầu và phân tích thành

một pha và gọi là pha phân tích hệ thống

Thiết kế (design) là pha tiếp theo pha đặc tả Căn cứ vào tài liệu đặc tả, pha này mô tả cách thức

mà phần mềm thực hiện các công việc cụ thể Pha này trả lời câu hỏi "phần mềm làm như thếnào?" Pha thiết kế thường có hai phần: thiết kế kiến trúc (architecture design) và thiết kế chi tiết(detail design)

Cài đặt (implementation) hoặc mã hóa (coding) hay lập trình (programming): viết chương

trình bằng một ngôn ngữ cụ thể nào đó

Tích hợp (integration) kết nối các phần chương trình đã viết thành một phần mềm thống nhất và chạy thử, hiệu chỉnh cho đến khi chạy tốt Pha này đôi khi được gọi là kiểm thử hoặc kiểm chứng hay đơn giản là thử.

Bảo trì (maintenance) hay đôi khi được gọi là hỗ trợ (trong tài liệu tiếng Việt): Khi chương

trình đã được cài đặt trên máy của khách hàng vẫn có thể có lỗi phát sinh cần loại trừ hoặc phảihiệu chỉnh lại phần mềm theo yêu cầu khách hàng

Kế hoạch quản lý dự án phần mềm (software project management plan - SPMP) bản kế hoạch

được soạn thảo sau khi hoàn thành pha đặc tả, trong đó mô tả chi tiết kế hoạch xây dựng phầnmềm (có cả thời gian hoàn thành và giá cả)

Trong các phần sau chúng ta sẽ còn nêu lại các khái niệm này

Như vậy các bạn có thể thấy, trong tin học các thuật ngữ không được sử dụng một cách chính

xác như toán học.

1.2.3 Vấn đề dịch các thuật ngữ tiếng Anh ra tiếng Việt

Phần lớn các thuật ngữ tin học đều có xuất xứ tiếng Anh, khi dịch sang tiếng Việt thường rấtkhó dịch chính xác, vì một từ tiếng Anh tương ứng với rất nhiều từ tiếng Việt Ví dụ từ

"process" có các nghĩa là xử lý, quá trình, quy trình, trong đó từ quá trình được sử dụng nhiều

hơn Tuy nhiên khi dịch cụm từ "software process" sang tiếng Việt, nếu dịch là "quá trình phầnmềm" sẽ nghe lạ tai và khó hiểu Có tác giả dịch là "tiến trình phần mềm" tuy có dễ nghe hơnnhưng vẫn hơi khó hiểu Theo chúng tôi có một số tác giả dịch là "quy trình phần mềm" có lẽnghe xuôi tai và dễ hiểu hơn cả Khi ta nói "quy trình làm sổ đỏ" có lẽ dễ hiểu hơn là nói "tiếntrình làm sổ đỏ"

Một số từ khác, ví dụ "implementation" có hai nghĩa như nhau là thực hiện, thi hành Và vì thế

trong quy trình làm phần mềm thì việc dịch thuật ngữ "implementation phase" là "pha thựchiện" có thể coi là cách dịch duy nhất Tuy nhiên từ "thực hiện" lại được dùng ở rất nhiều nơivới ý nghĩa khác, chứ không hẳn là viết chương trình Vì vậy nếu nói "pha thực hiện" thì đối vớingười chưa quen với tin học nghe rất khó hiểu Làm sao họ có thể hiểu được "thực hiện phầnmềm" lại là viết chương trình? Vì vậy có tác giả dùng từ "cài đặt" để thay thế, và dịch

"implementation phase" là pha cài đặt Bản thân tôi cũng ủng hộ cách dịch này, vì ở Việt nam

vẫn quen dùng từ "cài đặt" để chỉ việc viết chương trình, ví dụ: cài đặt thuật toán Euclid bằngngôn ngữ Pascal Tuy nhiên từ "cài đặt" vẫn có thể nhầm với nghĩa của từ "installation" hay

Chương 1 Tổng quan về công nghệ phần mềm

"setup", tức là cài đặt (chứ không phải viết chương trình) một phần mềm lên máy tính để phầnmềm này có thể chạy được Có lẽ chúng ta đành chấp nhận từ "cài đặt" có hai nghĩa vậy: mộtnghĩa tương ứng với từ "setup" trong tiếng Anh, còn một nghĩa là "writing code", tức là viết

chương trình Như vậy nếu các bạn gặp các thuật ngữ: lập trình, cài đặt, thực hiện, viết mã, viết code, mã hóa, thì thực ra chúng chỉ là một mà thôi Có thể nói rằng tin học là lĩnh vực đang

phát triển nên ngay ở Mỹ việc dùng thuật ngữ cũng không có sự thống nhất Lấy ví dụ ngaytrong mô hình vòng đời phần mềm, thì có người gọi pha "đặc tả" là pha "phân tích", hay gộp hai

pha "yêu cầu" và pha "phân tích" thành pha phân tích hệ thống Cách dịch sát ý nhiều khi làm

cho câu khó hiểu Ví dụ như chúng tôi đã nói đến trong phần trước, nếu dịch "requirements

phase" là pha yêu cầu thì khó hiểu hơn là dịch thoát ý: pha xác định yêu cầu Như vậy, khi sử

dụng các tài liệu tiếng Anh chúng tôi sẽ áp dụng cách dịch thoát ý nếu thấy cần thiết

Khi đọc các tài liệu khác nhau, các bạn sẽ thấy những thuật ngữ được sử dụng không nhất quán.Chúng tôi nghĩ rằng điều đó đối với các bạn không quá quan trọng để các bạn phải băn khoăn.Các bạn hãy dùng một cách gọi nào đó mà các bạn thấy thích hợp, điều quan trọng là các bạnphải nắm được ý nghĩa thực sự của nó

1.3 PHẠM VI CỦA CÔNG NGHỆ PHẦN MỀM

1.3.1.Mở đầu

Mục tiêu của công nghệ phần mềm là sản xuất ra các phần mềm không có lỗi, được hoàn thành đúng thời hạn với kinh phí cho phép và thỏa mãn yêu cầu khách hàng Hơn nữa phần

mềm phải dễ sửa đổi khi người sử dụng cần

Để đạt được điều này các kỹ sư phần mềm phải được trang bị các kỹ năng về kỹ thuật cũng như

về quản lý Các kỹ năng này không chỉ thể hiện khi viết chương trình, mà phải được áp dụngtrong các pha xây dựng phần mềm, bắt đầu từ khảo sát yêu cầu khách hàng cho đến giai đoạnbảo trì

Có nhiều người đã từng viết những chương trình máy tính, thậm chí đã tham gia viết nhiềuchương trình ứng dụng trong thực tế mà chưa hề biết về "công nghệ phần mềm" Một điều đángnói là không phải vì thế mà chương trình của họ kém hiệu quả Vậy thì "công nghệ phần mềm"liệu có ích lợi gì, có thực sự cần thiết đối với những người phát triển phần mềm không?

Chúng ta hãy xem một ví dụ thực tế: giả sử bạn cần xây dựng một ngôi nhà Nếu bạn là thợ xây

và ngôi nhà nhỏ thì bạn có thể xây mà không cần thiết kế trên giấy Thực ra thì trước và trongquá trình xây nhà, bạn cũng đã hình dung ra công việc mình cần làm, bạn đã tưởng tượng rangôi nhà của mình, nghĩa là bạn cũng có thiết kế, nhưng không ghi ra trên giấy mà thôi Nếucũng là ngôi nhà đó nhưng bạn lại nhờ một người khác thì sao? Rõ ràng bạn phải giải thích chongười đó biết cần phải làm gì Không ít trường hợp xẩy ra là cho dù bạn đã giải thích rất rõ,nhưng người thợ vẫn làm không đúng ý bạn Có thể buổi sáng bạn đã căn dặn người thợ phảixây cầu thang như thế nào nhưng buổi chiều về bạn lại thấy một chiếc cầu thang khác hẳn điềubạn đã mô tả và kết quả là phải phá đi để làm lại Đó là việc "xây ngôi nhà nhỏ" Nếu công trình

ta cần xây dựng là cả một tòa nhà hay chiếc cầu bắc qua sông lớn thì không thể thiếu bản thiết

kế chi tiết Bản thiết kế phải được thảo luận rất nhiều trước khi đi đến phương án cuối cùng Bảnthiết kế đó phải rõ ràng sao cho người kỹ sư thi công và những nhười thợ phải hiểu được chínhxác, không bị nhầm lẫn Đối với việc viết chương trình cũng vậy Nếu là vấn đề nhỏ như tínhđịnh thức ma trận hay tính xấp xỉ tích phân, bạn chỉ cần biết thuật toán rồi bắt tay vào viếtnhững dòng lệnh trên máy Thậm chí đối với bài toán lớn hơn như quản lý bán hàng ở một cửahàng nhỏ chẳng hạn, với một phần mềm quản trị cơ sở dữ liệu có sẵn như foxpro, bạn chỉ cầntrao đổi đôi điều với khách hàng rồi có thể bắt tay vào vừa viết vừa hiệu chỉnh cho đến khi nhậnđược sản phẩm có thể sử dụng được Chương trình máy tính có một đặc điểm khác với các sảnphẩm khác là có tính "mềm" như tên gọi của nó: ta có thể hiệu chỉnh các dòng lệnh hoặc xóa điviết lại từng đoạn chương trình mà không tốn nhiều công sức và không ảnh hưởng đến kết quảcuối cùng Trong thực tế có những việc khiến chúng ta phải cân nhắc rất kỹ trước khi thực hiện.Nếu là xây một bức tường ta có thể phá đi từng phần để xây lại, cho dù như thế có thể tốn một

6

Chương 1 Tổng quan về công nghệ phần mềm

số vật liệu và công sức Nhưng với người bác sĩ phẫu thuật thì anh ta phải suy nghĩ vô cùng cẩnthận khi đưa lưỡi dao cắt đi một phần nào đó của cơ thể người, vì nếu anh ta sai sót thì hậu quảthật khôn lường và đôi khi không thể sửa chữa được

Ngày nay có những hệ phần mềm cần hàng trăm người làm trong nhiều năm như hệ phần mềmdùng cho chương trình không gian của Mỹ Thậm chí có những hệ cần đến hàng ngàn ngườitrong nhiều nước làm trong nhiều năm như chương trình điều khiển tổng đài điện thoại hiệnđược bán khắp nơi trên thế giới Khác với các sản phẩm khác, phần mềm không bao giờ giữnguyên mà không ngừng được thay đổi Ví dụ như chương trình quản lý kết quả thi đại họcchẳng hạn Có thể mỗi năm lại có một chính sách khác và phải sửa lại cho phù hợp Chươngtrình quản lý nhân sự của một cơ quan, chương trình quản lý du lịch, cũng vậy Thường thìsau một thời gian cài đặt và sử dụng, khách hàng lại có thêm một số yêu cầu và họ muốn phầnmềm được sửa lại theo yêu cầu đó Nếu lúc đó họ phải tìm lại tác giả cũ thì thật là khó khăn.Điều này đặt ra thêm một yêu cầu cho phần mềm: phần mềm phải được xây dựng sao cho cácchuyên gia phần mềm khác (mà không phải là tác giả) có thể hiểu và bảo trì được Tóm lại, cóthể nêu một vài lý do khiến chúng ta phải nghiên cứu các cách thức xây dựng phần mềm mộtcách có khoa học là:

 Ngày nay phần lớn phần mềm được xây dựng theo đơn đặt hàng Như vậy cần có mộtngôn ngữ chung giữa người xây dựng phần mềm và khách hàng

 Phần mềm thường không do một người mà gồm rất nhiều người xây dựng Những ngườicùng phát triển một phần mềm phải hiểu rõ công việc của mình và công việc chung, mốiliên hệ giữa công việc của từng cá nhân hoặc từng nhóm Cần có một cách thức diễn đạtcác công việc làm phần mềm sao cho mỗi kỹ sư phần mềm đều có thể trao đổi dễ dàngcác ý tưởng và công việc của mình với các kỹ sư trong nhóm làm việc

 Phần mềm cũng là một thứ hàng hóa như những thứ hàng hoá khác và do đó phải tuân

thủ nguyên tắc của kinh tế thị trường là sản phẩm phải độc lập với người sản xuất.

Nghĩa là sau khi mua hàng, người mua không bị lệ thuộc vào người bán Muốn vậy thìsản phẩm phần mềm ngoài chương trình chạy trên máy, cần có thêm các tài liệu sao chongười khác có thể tìm hiểu và bảo trì được Vậy thì cần một ngôn ngữ, một cách trìnhbày chung cho các sản phẩm phần mềm

1.3.2 Công nghệ phần mềm nhìn từ góc độ lịch sử

Máy tính điện tử đầu tiên cho mục đích thương mại là máy UNIVAC-1 được sản xuất năm

1951 ở Mỹ Từ khoảng những năm 1955 thì bắt đầu có các phần mềm, tức là các chương trìnhmáy tính Cho đến nay, nếu lấy phương pháp và mức độ phức tạp làm căn cứ, thì có thể chia quátrình phát triển phần mềm thành 3 giai đoạn: 1955 - 1970, 1971 - 1985, 1986 đến nay Tất nhiên

sự phân chia này chỉ là tương đối mà thôi Đặc điểm của từng giai đoạn là:

- 1955 - 1970: Tính toán và quản lý rời rạc, quản lý nhỏ Đặc tả những yêu cầu của khách

hàng lúc đó còn dùng ngôn ngữ tự nhiên thông thường Ví dụ các câu kiểu như: tôi muốn cótệp dữ liệu chứa những thông tin về bán sản phầm như số hóa đơn, người bán, mặt hàng, Dữliệu sẽ được nhập từ bàn phím, có kiểm tra rồi mới đưa vào tệp Hàng tháng tôi muốn lấythông tin về doanh thu, lãi, số hàng bán Thiết kế thời ấy không được soạn thảo ra giấy màchỉ hình thành trong tư duy của người lập trình Người lập trình vừa viết chương trình vừasuy nghĩ về cách tổ chức dữ liệu, cách sử dụng các thuật toán sao cho chương trình chạy tốt,đáp ứng được yêu cầu của khách hàng Chương trình hồi đó chỉ gồm khoảng trên dưới vài

trăm dòng lệnh Phương pháp lập trình được sử dụng thời đó là lập trình tuyến tính, tức là

cách viết chương trình trong đó phần lớn các lệnh được đặt theo trình tự thực hiện của chúng,nghĩa là lệnh cần thực hiện trước sẽ được viết trước, lệnh thực hiện sau được viết sau

- 1971 - 1985: Lúc này đã có nhu cầu xây dựng các phần mềm thời gian thực (nghĩa là tính

toán và sử dụng ngay kết quả, ví dụ tính toán trong lò phản ứng hạt nhân phải có ngay kết quả

Chương 1 Tổng quan về công nghệ phần mềm

để điều khiển kịp thời) Lúc này có nhu cầu xây dựng các mạng cục bộ và kết nối các cơ sở

dữ liệu Đặc tả thời đó chú trọng vào đặc tả đầu vào đầu ra, dữ liệu và các luồng dữ liệu

(data flow) Ví dụ những tệp dữ liệu lưu trữ những thông tin gì, trong quá trình xử lý thì dữliệu được tính toán và di chuyển ra sao Đầu ra của tệp dữ liệu này sau khi xử lý lại có thể trở

thành đầu vào của tệp khác Thiết kế thời đó chú trọng tới cấu hình hệ thống (system configuration) Vấn đề cấu trúc đối với dữ liệu và giải thuật cũng được chú ý, vì vấn đề lớn

cần phải được mô tả có cấu trúc cho dễ hiểu Các chương trình tiêu biểu thời đó có thể kể tới

hệ điều hành DOS, UNIX Lúc đó cũng đã có những cơ sở dữ liệu có thể truy cập từ xa Do

nhu cầu thực tế, các ngôn ngữ lập trình ra đời giai đoạn này đã có khả năng hỗ trợ phương

pháp lập trình có cấu trúc, nghĩa là chương trình được phân chia thành các chương trình

con, mỗi chương trình con có tên và các chức năng xử lý riêng, có thể giao tiếp với các

chương trình con khác thông qua các đối số và kiểu trả về (nếu có)

- Từ 1986 đến nay: Đây là thời kỳ của máy vi tính PC, thời nối mạng tầm rộng, mạng

toàn cầu Internet Đặc tả dự án được biết nhiều là hướng đối tượng, công cụ CASE (Computer Aided Software Engineering) Trong thiết kế người ta chú ý đến môđun

(module), đối tượng (object), giao thức (protocol) và giao diện (interface) Giao thức hay

giao diện nói về sự trao đổi giữa các đối tượng Khi cài đặt trên máy tính người ta thường

dùng ngôn ngữ hướng đối tượng Ngoài các phần mềm được viết theo đặt hàng, người ta

chú trọng đến các phần mềm đóng gói như: Netscape, Internet Explorer, Word, Excel Ngày nay phần mềm ngày càng lớn, càng tích hợp Phần mềm ngày nay còn được truy cập ởkhắp nơi trên thế giới thông qua Internet

Người ta cho rằng việc xây dựng một phần mềm cũng cần tuân theo những nguyên tắc và kỹ luậtgiống như khi xây dựng một chiếc cầu hay thực hiện những công việc kỹ nghệ khác Nếu mộtchiếc cầu bị lỗi khi xây dựng và do đó bị sập thì tác hại gây ra rất lớn Một phần mềm quantrọng như phần mềm điều khiển hệ thống tên lửa đạn đạo của một nước mà có lỗi, cho kết quảtính toán sai thì hậu quả nó gây ra cũng thật là kinh khủng Chính vì vậy một nhóm nghiên cứu

của NATO trong năm 1967 đã sử dụng thuật ngữ "Software engineering" Họ muốn rằng khi

xây dựng phần mềm thì các kỹ sư cũng cần áp dụng các nguyên tắc của kỹ nghệ truyền thống.Tuy nhiên, có nhiều sự khác biệt giữa sản phẩm của kỹ nghệ truyền thống và công nghệ phầnmềm Ví dụ như chiếc cầu và hệ điều hành chẳng hạn Sự cố cầu sập rất ít khi xảy ra và nếu xảy

ra thì cách khắc phục thường là xây dựng lại Còn hệ điều hành nếu có sự cố có khi chỉ cần tắtmáy khởi động lại là lại chạy tốt Phần mềm có thể sửa lại, có khi là tới 50% để có thể chạy trênmáy tính có cấu hình khác hoặc thực hiện thêm các chức năng khác Còn chiếc cầu muốn sửa lại50% thì rất khó, nhiều khi xây dựng mới còn dễ thực hiện hơn

1.3.3 Từ góc độ kinh tế

Trong kỹ nghệ truyền thống, khi có nhiều cách thức để sản xuất một sản phẩm nào đó, ví dụchiết xuất dầu lửa từ than đá chẳng hạn, các kỹ sư thường chọn phương án rẻ nhất Khi xây dựngphần mềm cũng vậy, người ta thường lựa chọn cách thức chi phí ít nhất Một phương pháp lậptrình mới có thể viết chương trình nhanh hơn, nhưng chi phí huấn luyện sử dụng và công bảo trì

có thể lớn hơn khiến người ta phải cân nhắc khi lựa chọn

1.3.4 Về vấn đề bảo trì

Dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo sát ban đầu cho đến khi

phần mềm không còn được sử dụng được gọi là vòng đời của phần mềm (software life cycle).

Cho đến những năm 70 của thế kỷ trước, việc sản xuất một phần mềm được coi là kết quả của

hai giai đoạn nối tiếp nhau: phát triển (developement) và bảo trì (maintenance) Dần dần quan

điểm này trở nên không phù hợp Ta có thể lấy một ví dụ đơn giản: phần mềm ngày nay có thểđược phát triển trong một vài năm Trong khoảng thời gian đó có thể có những phần đã hoàn

8

Chương 1 Tổng quan về công nghệ phần mềm

thiện theo đúng thiết kế ban đầu nhưng khách hàng lại bổ sung những yêu cầu mới và phải thiết

kế lại, viết lại Công việc này có thể xem là bảo trì Có quan điểm cho rằng công việc sửa lỗihay hiệu chỉnh những phần chương trình đã hoàn thiện theo thiết kế ban đầu thì nên coi là côngviệc bảo trì Tuy nhiên cho đến nay thường người ta vẫn coi công tác bảo trì là những hoạt độngsau khi phần mềm đã hoàn chỉnh và được cài đặt để sử dụng Trong tài liệu này chủ yếu chúng

ta cũng hiểu từ "bảo trì" với nghĩa như vậy

Trong những năm cuối của thập kỷ 70 của thế kỷ trước, phần lớn các công ty khi sản xuất các

phần mềm đã sử dụng mô hình vòng đời phần mềm mà ngày nay người ta gọi là mô hình thác

đổ (waterfall) Mô hình này bao gồm 7 giai đoạn như sau:

1 Xác định yêu cầu (Requirements phase)

2 Phân tích hay còn gọi là đặc tả (Analysis or specification phase)

3 Thiết kế (Design phase)

4 Cài đặt (Implementation phase)

5 Tích hợp (Integration phase)

6 Bảo trì (Maintenance phase)

7 Thôi sử dụng (Retirement)

Trong thực tế có thể một vài pha được bỏ qua hoặc được thay thế bởi các pha khác Ví dụ người

ta hợp nhất hai pha đầu tiên thành pha hệ thống Người ta lại cho rằng việc tích hợp phải đượcthực hiện trong quá trình cài đặt, cài đặt xong thì phải có một thời gian kiểm thử, và như thế môhình gồm các giai đoạn sau:

kế

Cài đặt và tích hợp Bảo trì Thôi sử dụng

kế

Ý nghĩa của các pha:

1 Xác định yêu cầu: Tìm hiểu các yêu cầu của khách hàng, đưa ra các khái niệm và vấn đề.

2 Phân tích: Phân tích các yêu cầu của khách hàng Mô tả các kết quả phân tích dưới dạng "tài

liệu đặc tả" Cuối giai đoạn này là kế hoạch quản lý dự án phần mềm được đưa ra, mô tả chitiết quá trình phát triển phần mềm Câu hỏi mà pha này cần cho câu trả lời là: "phần mềm sẽlàm gì?" (What the product is supposed to do?)

3 Thiết kế: Pha thiết kế bao gồm hai giai đoạn nối tiếp nhau: thiết kế kiến trúc (architechtural

design) và thiết kế chi tiết (detailed design) Thiết kế kiến trúc phân chia phần mềm thành các

thành phần gọi là module Thiết kế chi tiết là thiết kế từng module một cách chi tiết Câu hỏicần trả lời trong pha này là: phần mềm thực hiện các công việc như thế nào? (How theproduct is to do it?)

Chương 1 Tổng quan về công nghệ phần mềm

4 Cài đặt: Từng thành phần khác nhau được lập trình và kiểm thử.

5 Tích hợp: Các thành phần của sản phẩm được kết hợp với nhau và kiểm thử tổng thể Sau khi

những người phát triển đã kiểm thử và cho rằng tất cả các chức năng của phần mềm đã hoạt

động tốt thì đến lượt khách hàng kiểm thử Sự kiểm thử của khách hàng được gọi là kiểm thử chấp nhận (acceptance testing) Khi sự kiểm thử của khách hàng kết thúc và khách hàng vừa

lòng với sản phẩm thì phần mềm được cài đặt trên máy của khách hàng Trong thực tế thì phatích hợp được tiến hành song song với pha cài đặt Khi mỗi thành phần của sản phẩm đượchoàn thành thì người ta tiến hành thử luôn

6 Bảo trì: Sản phẩm được sử dụng để thực hiện các công việc đã đặt ra trước đó Trong quá

trình này có thể xẩy ra những sự cố: đó có thể là các lỗi chương trình chưa được loại trừ hết,hay kết quả không được như khách hàng mong đợi Người ta phân chia công việc bảo trì

thành hai loại: bảo trì sửa lỗi (software repair) và bảo trì cập nhật (softwair update) Trong

tiếng Anh bảo trì sửa lỗi còn được gọi là corrective maintenance, bảo trì cập nhật còn được gọi là software enhancement.

Bảo trì sửa lỗi như tên gọi của nó, là sửa các lỗi có thể vẫn còn xuất hiện trong khi chạy

chương trình Bảo trì cập nhật lại được chia làm hai loại: bảo trì hoàn thiện (perfective

maintenance) và bảo trì thích nghi (adaptive maintenance) Bảo trì hoàn thiện là sửa đổi phần

mềm theo ý khách hàng để nâng cao hiệu quả Bảo trì thích nghi là sửa đổi để phần mềmthích nghi với môi trường mới, ví dụ sửa đổi công thức tính lương theo chính sách mới banhành hay hiệu chỉnh để chương trình phù hợp với phiên bản mới của ngôn ngữ lập trình (Sựphân chia này cũng chỉ là tương đối mà thôi) Người ta tính toán rằng bảo trì sửa chữa vàthích nghi chiếm thời gian gần bằng nhau và khoảng 20% mỗi loại, còn bảo trì hoàn thiệnchiếm thời gian khoảng gấp 3 lần mỗi loại bảo trì kia (khoảng 60%)

Ngư.i ta thư.ng ngh r ng "s n ph m x u" m i ph i b o trì Tuy nhiên th c t thìĩ rằng "sản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ằng "sản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ấu" mới phải bảo trì Tuy nhiên thực tế thì ới phải bảo trì Tuy nhiên thực tế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ực tế thì ế thì

ngư7 8c l i: "s n ph m x u" b v t v o s t rác, còn "s n ph m t t" thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ấu" mới phải bảo trì Tuy nhiên thực tế thì ị vứt vào sọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, ứt vào sọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, à nội, 2009 ọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ốt" thì được hiệu chỉnh, đư7c hi u ch nh,ệu chỉnh, ỉnh,nâng c p v s d ng trong nhi u n m (t c l ấu" mới phải bảo trì Tuy nhiên thực tế thì à nội, 2009 @ A ều năm (tức là được bảo trì) Phần mềm là mô hình của ăm (tức là được bảo trì) Phần mềm là mô hình của ứt vào sọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh, à nội, 2009 đư7c b o trì) Ph n m m l mô hình c aản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ần mềm là mô hình của ều năm (tức là được bảo trì) Phần mềm là mô hình của à nội, 2009 ủa

th gi i th c, m th gi i th c thì bi n ế thì ới phải bảo trì Tuy nhiên thực tế thì ực tế thì à nội, 2009 ế thì ới phải bảo trì Tuy nhiên thực tế thì ực tế thì ế thì đổi không ngừng, do đó phần mềm cũng phảii không ng ng, do ó ph n m m c ng ph iừng, do đó phần mềm cũng phải đ ần mềm là mô hình của ều năm (tức là được bảo trì) Phần mềm là mô hình của ũng phải ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì

c b o trì th ng xuyên ph n ánh úng th gi i th c Trong th c t công vi c b ođư7 ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ư để phản ánh đúng thế giới thực Trong thực tế công việc bảo ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì đ ế thì ới phải bảo trì Tuy nhiên thực tế thì ực tế thì ực tế thì ế thì ệu chỉnh, ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thìtrì chi m m t lế thì ội, 2009 ưJng th i gian v chi phí khá l n so v i các pha khác N u ta g i các pha à nội, 2009 ới phải bảo trì Tuy nhiên thực tế thì ới phải bảo trì Tuy nhiên thực tế thì ế thì ọt rác, còn "sản phẩm tốt" thì được hiệu chỉnh,1-5 th nh tên chung l các pha phát tri n, ph n còn l i l pha b o trì thì th c t cho th yà nội, 2009 à nội, 2009 ể phản ánh đúng thế giới thực Trong thực tế công việc bảo ần mềm là mô hình của 8 à nội, 2009 ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ực tế thì ế thì ấu" mới phải bảo trì Tuy nhiên thực tế thì

r ng trung bình pha b o trì thằng "sản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ư.ng chi m kho ng hai ph n ba (67%) chi phí s n ph m.ế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ần mềm là mô hình của ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì

Th m chí có nhi u công ty ph n chi phí cho b o trì có th lên t i 80% T l % th iK ều năm (tức là được bảo trì) Phần mềm là mô hình của ần mềm là mô hình của ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì ể phản ánh đúng thế giới thực Trong thực tế công việc bảo ới phải bảo trì Tuy nhiên thực tế thì ỷ lệ % thời ệu chỉnh, gian th c hi n các pha phát tri n có th th y trong b ng sau:ực tế thì ệu chỉnh, ể phản ánh đúng thế giới thực Trong thực tế công việc bảo ể phản ánh đúng thế giới thực Trong thực tế công việc bảo ấu" mới phải bảo trì Tuy nhiên thực tế thì ản phẩm xấu" mới phải bảo trì Tuy nhiên thực tế thì

Các pha Các dự án từ 1976-1981 132 dự án gần đây của Hewlett- Packard

có thể chứa trong mọi pha Dễ thấy rằng lỗi trong pha trước cũng sẽ gây nên lỗi ở pha sau Do

đó nếu phát hiện lỗi càng chậm thì chi phí sửa chữa càng lớn Chi phí tốn kém nhất là khi phầnmềm đã được chuyển giao và cài đặt cho khách hàng Lúc đó không những phần lệnh phải viếtlại mà có thể các báo cáo trước đó cũng phải sửa chữa Sau khi phần mềm được sửa chữa thì lạitốn công phân phối và cài đặt lại Trong các pha xác định yêu cầu, phân tích thiết kế thì sảnphẩm còn nằm trên giấy và việc sữa chữa thường chỉ cần đến tẩy và bút chì Vì vậy nên thựchiện các pha này thật kỹ sao cho có ít sai sót nhất Người ta cũng đã sử dụng một số kỹ thuật tìm

10

Chương 1 Tổng quan về công nghệ phần mềm

lỗi nhanh trong các pha yêu cầu và pha phân tích

1.3.6 Vấn đề lập trình theo nhóm

Ngày nay nhờ sự phát triển rất nhanh của kỹ thuật, các công ty đã có thể trang bị những máytính có cấu hình cao, có thể chạy được những chương trình lớn Nhiều phần mềm trở thành quálớn và không thể viết được bởi một người Ví dụ người ta cần có sản phẩm trong khoảng thờigian một năm, nhưng nếu một người làm thì mất 15 năm, rõ ràng lúc này phần mềm phải đượclàm bởi nhiều người Tuy nhiên không giống như việc xây nhà hoặc đào kênh rạch, việc pháttriển phần mềm theo nhóm thường gặp khó khăn trong việc phân chia và kết hợp công việc giữacác thành viên Ví dụ A và B đồng thời viết code cho hàm p và q Hàm p có lời gọi tớihàm q Để chương trình không báo lỗi, khi viết p A phải khai báo nguyên mẫu cho q Nếukhông có sự trao đổi cẩn thận, có thể B xây dựng hàm q với các tham số không hoàn toàngiống với nguyên mẫu mà A khai báo, ví dụ thứ tự các tham số khác chẳng hạn, khi đó việc kếthợp sẽ không thành công Thực tế chứng tỏ rằng không phải nhiều người làm là thời gian đượcgiảm xuống tỷ lệ với số người Giả sử một phần mềm được làm trong một năm bởi một người.Khi đó nếu có 3 người làm thì thời gian không phải là 4 tháng như ta nghĩ mà có thể là gần 1năm và chất lượng có thể kém hơn phần mềm do một người xây dựng Vấn đề làm việc theonhóm quả thực là vấn đề rất khó và là một lĩnh vực mà công nghệ phần mềm cần nghiên cứu

1.3.7 Phương pháp hướng đối tượng

Trước 1975 phần lớn các công ty phân mềm đều không sử dụng một kỹ thuật nào đặc biệt

Thường thì mỗi công ty có cách làm phần mềm riêng Từ 1975 - 1985 phương pháp cấu trúc (structured paradigm) ra đời, đánh dấu một sự thay đổi đáng kể trong kỹ thuật làm phần mềm.

Kỹ thuật này bao gồm: phân tích hệ thống có cấu trúc (structured system analysis), phân tích

dòng dữ liệu (data flow analysis), lập trình cấu trúc (structured programming) và kiểm thử theo cấu trúc (structured testing) Lúc mới ra đời, phương pháp cấu trúc tỏ ra có rất nhiều hứa

hẹn và cũng đã được áp dụng khá hiệu quả Tuy nhiên, khi độ lớn của các phần mềm tăng lên thìphương pháp này bộc lộ những nhược điểm Theo thời gian, người ta rút ra 2 nguyên nhân hạnchế khả năng của kỹ thuật này:

Thứ nhất, người ta nhận thấy rằng phong cách lập trình cấu trúc tỏ ra không phù hợp với những phần mềm chứa khoảng trên 5000 dòng lệnh (tức là khoảng 100 trang) Các phần mềm

ngày nay có thể chứa đến 500 000 , thậm chí chứa đến 5 triệu dòng lệnh hoặc hơn

Thứ hai, khi xây dựng phần mềm người ta dự kiến về trung bình thì kinh phí bảo trì chiếm

khoảng hai phần ba tổng kinh phí (66%) Tuy nhiên trong thực tế thì phương pháp cấu trúc đãkhông làm được điều này Rất nhiều công ty đã dùng đến 80% kinh phí cho công việc bảo trì

Nguyên nhân làm cho lập trình cấu trúc chưa thật thành công là vì phương pháp này hoặc là định hướng hành động (action oriented) hoặc là định hướng dữ liệu (data oriented), chứ không

phải là cả hai Các thành phần cơ bản của một phần mềm chính là các hành động và dữ liệu

mà các hành động này tác động lên Ví dụ việc xác định chiều cao trung bình bao gồm hai thao

tác: thu thập chiều cao (dữ liệu), và tính chiều cao trung bình Một vài kỹ thuật cấu trúc, ví dụphân tích dòng dữ liệu (xem [6], mục 13.3), là định hướng thao tác Nghĩa là kỹ thuật này chú ýhơn các thao tác, dữ liệu chỉ là thứ yếu Ngược lại, kỹ thuật khác như hệ thống Jackson (xem [6],mục 13.5) lại là định hướng dữ liệu Ở đây sự nhấn mạnh lại là dữ liệu, còn thao tác là thứ yếu

Phương pháp hướng đối tượng lại xem dữ liệu và hành động đều quan trọng như nhau.

Người ta xem đối tượng là một thành phần của phần mềm trong đó bao gồm dữ liệu và các

hành động thao tác trên dữ liệu này

Tài khoản ngân hàng là một ví dụ về đối tượng Dữ liệu của đối tượng là số dư tài khoản Cáchành động tác động lên số dư tài khoản là việc gửi tiền, rút tiền và tính số dư

Nhìn từ quan điểm phương pháp cấu trúc thì phần mềm giải quyết bài toán này bao gồm mộtthành phần dữ liệu là số dư tài khoản và 3 hành động là gửi tiền, rút tiền và tính lại số dư

Theo quan điểm hướng đối tượng thì tài khoản ngân hàng là một đối tượng bao gồm 3 thành

Chương 1 Tổng quan về công nghệ phần mềm

phần trên Ta có thể biểu diễn các phương pháp này trong các hình sau đây:

dư thì chỉ có thể gửi thông báo đến đối tượng (người ta nói gửi thông báo đến đối tượng cónghĩa là chạy một hàm thành phần của đối tượng) Ví dụ nếu khách hàng gửi 10$ thì sẽ gửithông báo và kích hoạt hàm gửi tiền, và hàm gửi tiền sẽ tăng số dư lên 10 $

Ích lợi của phương pháp HĐT còn thể hiện trong quá trình bảo trì phần mềm Trở lại ví dụ trênđây Giả sử kiểu dữ liệu của số dư bị thay đổi do một lý do nào đó Trong phương pháp cấu trúcthì tất cả các phần của chương trình liên quan đến số dư đều phải sửa đổi Ngược lại, trongphương pháp HĐT thì số dư chỉ bị tác động bởi các hàm của chính đối tượng chứa nó, vì vậy chỉcần sửa đổi các hàm này

Phương pháp HĐT được thiết kế tốt thì các đối tượng là những phần độc lập, ít phụ thuộc lẫn

nhau, và như vậy chúng có thể được xây dựng một cách độc lập và do đó dễ phân chia công việc cho nhiều người thực hiện Một phần mềm được xây dựng theo phương pháp cấu trúc thì

thường được coi là một đơn thể duy nhất (vì cho dù nó chứa nhiều thành phần nhưng các thànhphần lại phụ thuộc lẫn nhau), do đó phương pháp này không thích hợp cho phần mềm kích cỡlớn

Cũng nhờ tính độc lập của các đối tượng mà khả năng sử dụng lại của phương pháp HĐT cao hơn

Nếu sử dụng phương pháp HĐT, vòng đời phần mềm sẽ được sửa đổi chút ít như trong hình sau:

3 Thiết kế hướng đối tượng (thiết kế chi tiếtcác đối tượng)

12

số dư

t i à nội, 2009 khoản

rút tiền

tính số dư

rút tiền thông báo

thông báo

thông báo

Chương 1 Tổng quan về công nghệ phần mềm

thiết kế chi tiết các module)

4 Cài đặt (viết chương trình)

Trong phương pháp cấu trúc, pha phân tích trả lời câu hỏi: "phần mềm làm gì?" , còn pha thiết

kế trả lời câu hỏi: "làm như thế nào?" Pha thiết kế gồm hai pha con: thiết kế kiến trúc (phần mềm được chia thành các module như thế nào?) và thiết kế chi tiết (mỗi module được thiết kế

như thế nào?)

Với phương pháp HĐT, trong pha phân tích thì ngoài việc xác định phần mềm sẽ làm những gì (như phương pháp cấu trúc) còn phải xác định các đối tượng trong phần mềm; như vậy trong pha thiết kế không phải xác định các đối tượng nữa, mà chỉ cần thiết kế chi tiết các đối tượng Như vậy trong phương pháp HĐT các bước chuyển tiếp từ pha này sang pha khác mịn hơn, và

do đó giảm được các lỗi trong quá trình phát triển

CHƯƠNG 2 QUY TRÌNH LÀM PHẦN MỀM

2.1 MỞ ĐẦU

Quy trình làm phần mềm (hay gọi đơn giản theo tiếng Anh: software process - quy trình phần

mềm) là quá trình tạo ra phần mềm Quy trình này là sự kết hợp mô hình vòng đời phần mềm, các công cụ được sử dụng và quan trọng hơn hết, là những người xây dựng nên phần mềm đó.

Các công ty phần mềm khác nhau có các quy trình phần mềm khác nhau Ví dụ hãy xem vấn đềtài liệu Có một số công ty cho rằng chính bản thân phần mềm với các mã nguồn là tài liệu vềphần mềm Họ cho rằng phần mềm có thể hiểu được bằng cách đọc các mã nguồn này Một sốcông ty khác chuẩn bị tài liệu rất chi tiết Ngay cả khi phần mềm đã cài đặt cho khách hàng vàchuyển sang giai đoạn bảo trì, thì mọi sự sửa đổi phần mềm cũng được ghi chép lại, các bản thiết

kế cũng được thay đổi cho phù hợp Từ thực tế có thể thấy rằng một phần mềm được kiểm thử

kỹ lưỡng và có các tài liệu báo cáo đầy đủ trong từng pha thì chất lượng sẽ tốt hơn và công việcbảo trì cũng thuận lợi hơn

Nói chung, một quy trình phần mềm thường trải qua 7 pha: xác định yêu cầu, phân tích, thiết

kế, cài đặt, tích hợp, bảo trì và thôi sử dụng Trong một số trường hợp thì tên các pha này có thể

khác Ví dụ người ta hợp nhất hai pha xác định yêu cầu và phân tích thành pha phân tích hệ thống Một vài pha khác lại được chia nhỏ hơn, ví dụ pha thiết kế được chia thành pha thiết kế kiến trúc và thiết kế chi tiết Hai pha cài đặt và tích hợp được kết hợp thành pha cài đặt và tích hợp Những lý do sau đây trả lời câu hỏi vì sao các pha của vòng đời phần mềm cần được kiểm

thử kỹ và báo cáo thành tài liệu chi tiết bởi nhóm thực hiện trước khi tiến hành các pha tiếp theo:

- Vì sự thúc ép về thời gian hoàn thành nên những phần tài liệu bị trì hoãn thường ít khi được tiếp tục hoàn thiện.

- Trách nhiệm về một pha nào đó có thể được chuyển giao cho nhóm khác thậm chí ở một công

ty phần mềm khác

- Phần mềm thường liên tục thay đổi trong quá trình xây dựng Ví dụ thiết kế có thể bị thay đổi

trong pha cài đặt Rõ ràng nếu tài liệu thiết kế được biên soạn đầy đủ thì sự sửa đổi sẽ thuậnlợi hơn

2.2 KHÁCH HÀNG, NGƯỜI PHÁT TRIỂN VÀ NGƯỜI SỬ DỤNG

(Client, developer, and user)

Khách hàng là cá nhân hoặc công ty có nhu cầu sử dụng phần mềm

Những người phát triển là những người nhận trách nhiệm xây dựng phần mềm do khách hàngyêu cầu

Người sử dụng là người trực tiếp sử dụng phần mềm khi nó được cài đặt cho khách hàng

Khách hàng, người phát triển và người sử dụng có thể ở các công ty khác nhau hoặc ở ngaytrong một công ty Cũng có khi họ là những người lao động tự do Thường thì khách hàng vàngười sử dụng ở cùng một công ty, còn những người phát triển là thành viên của một công ty

phần mềm nào đó Nếu xét về mặt giá cả thì người ta phân các phần mềm thành hai loại: phần mềm được xây dựng cho một khách hàng thường có giá cao, và phần mềm đóng gói được bán

cho nhiều khách hàng ví dụ như Microsoft Word, Microsoft Excel thường có giá rẻ hơn

2.3 PHA XÁC ĐỊNH YÊU CẦU

trong thời gian bao lâu, phần mềm cần làm việc với hệ điều hành nào, trên máy tính có cấu hình

Chương 2 Quy trình l m ph àm ph ần mềm

ra sao, giá cả khoảng bao nhiêu thì chấp nhận được Thường thì chính khách hàng hỏi lại ngườiphát triển giá của phần mềm, và người phát triển phải cân nhắc khi trả lời câu hỏi này

Những khảo sát ban đầu về nhu cầu khách hàng được gọi là tìm hiểu vấn đề (concept

exploration) Các buổi gặp tiếp theo sẽ bàn kỹ hơn về các chức năng của phần mềm, các vấn đề

kỹ thuật liên quan và kinh phí

Thường thì mọi việc trong pha xác định yêu cầu có vẻ như được thực hiện suôn sẻ Khách hàng

và người phát triển hiểu nhau, công việc được chuyển qua pha tiếp theo Tuy nhiên thực tế lạichứng tỏ rằng, thường thì pha xác định yêu cầu không được thành công lắm Sau này khi sảnphẩm được cài đặt và đưa vào sử dụng, khách hàng bỗng đến gặp những người phát triển vàphàn nàn rằng "quả tình là các anh đã làm đúng những gì tôi yêu cầu, nhưng bây giờ tôi mớinhận ra là có lẽ phần mềm tôi cần lại không hẳn là cái mà các anh đã xây dựng" Trong nhữngtrường hợp này, phần mềm lại phải sửa đổi, các tài liệu phải viết lại, Những tình huống trênđây rất hay xảy ra trong các trường hợp khách hàng hiểu biết ít về máy tính Lúc này người pháttriển và khách hàng thường bị "bất đồng ngôn ngữ" Để khắc phục tình trạng này, người pháttriển thường viết nhanh một phần mềm thực hiện những điều mà khách hàng yêu cầu Trongphần mềm này chưa cần giao diện đẹp, chưa cần kiểm tra nhập dữ liệu, cốt là để khách hàng cóthể dùng thử xem nó có thực hiện đúng những điều họ muốn không Phiên bản thử nghiệm nàyđược gọi là bản mẫu nhanh (rapid prototype) Phương pháp xác định yêu cầu sử dụng bản mẫu

được gọi là kỹ thuật dùng bản mẫu.

Từ đây có lúc ta sẽ gọi đơn giản pha xác định yêu cầu là pha yêu cầu, đúng như thuật ngữ tiếngAnh: requirements phase

2.3.2 Kiểm thử pha yêu cầu

Trong mỗi công ty phần mềm cần có một nhóm làm việc mà nhiệm vụ chính của họ là bảođảm rằng phần mềm hoạt động tốt và đáp ứng đúng các yêu cầu của khách hàng Nhóm nàyđược gọi là nhóm bảo đảm chất lượng phần mềm (SQA = software quality assurance) NhómSQA bắt đầu thực hiện vai trò của mình ngay từ pha khởi đầu Nếu sử dụng bản mẫu thì trongpha này nhóm cùng khách hàng kiểm thử phiên bản cuối cùng của bản mẫu xem nó đã thực hiệnđúng các yêu cầu mà khách hàng cần không

2.3.3 Tài liệu báo cáo trong pha yêu cầu

Tài liệu được biên soạn trong pha yêu cầu bao gồm bản mẫu và các ghi chép trong quá trìnhtrao đổi với khách hàng Những ghi chép này chính là cơ sở để những người phát triển xây dựng

và sửa đổi bản mẫu Nếu nhóm phát triển không làm bản mẫu thì tài liệu sẽ mô tả những yêu cầu của khách hàng Tài liệu này được kiểm tra bởi khách hàng và một số người sử dụng trước

khi được nhóm SQA kiểm tra kỹ lưỡng và chi tiết

được nêu trong tài liệu của pha yêu cầu sẽ được chi tiết và chính xác hóa Các chức năng của

phần mềm được mô tả một cách rõ ràng, tường minh Những điều kiện ràng buộc về phần mềmđược liệt kê đầy đủ Tài liệu đặc tả còn chỉ rõ đầu vào (input) và đầu ra (output) của phần mềm

Ví dụ, nếu yêu cầu của khách hàng là phần mềm tính bảng lương của một cơ quan thì đầu vào làcác mức lương của mỗi nhân viên, bảng ghi các ngày làm việc, các thông tin về thuế thu nhậpcủa từng người Đầu ra là bảng lương cùng với báo cáo về phần khấu trừ vào bảo hiểm xã hội,

bảo hiểm y tế Báo cáo đặc tả là cơ sở tạo ra bản hợp đồng Hay nói chính xác hơn, báo cáo

đặc tả là những điều kiện của bản hợp đồng Những người phát triển phần mềm sẽ được coi nhưhoàn thành hợp đồng nếu sản phẩm thỏa mãn các tiêu chuẩn nêu ra trong bản đặc tả Chính vì

vậy bản đặc tả không chứa những từ không có ý nghĩa chính xác như: nói chung, thích hợp,

Các thiếu sót sau có thể xảy ra trong pha đặc tả:

- Một lỗi mà nhóm đặc tả thường vi phạm là diễn tả vấn đề không chính xác, đôi lúc có thể

hiểu nhiều nghĩa Ví dụ: sắp xếp mảng A rồi chọn phần tử đầu tiên Ở đây từ sắp xếp chưacho cách hiểu duy nhất, sắp tăng dần hay giảm dần?

- Tài liệu chưa đầy đủ: Ví dụ nếu dữ liệu có lỗi thì giải quyết như thế nào?

Sau khi tài liệu đặc tả được biên soạn xong thì tiếp theo là xây dựng kế hoạch chi tiết và ước

lượng thời gian hoàn thành và giá trị phần mềm Khách hàng sẽ không chấp nhận dự án phần

mềm nếu chưa biết các thông tin là dự án sẽ kéo dài trong bao lâu và chi phí hết bao nhiêu Các

vấn đề này rất khó Nếu giá cả thấp thì công ty bị thiệt, cao thì có thể khách hàng lại chọn mộtcông ty khác chấp nhận giá rẻ hơn Nếu thời gian ước lượng quá ngắn, không kịp hoàn thành thìcông ty phần mềm hoặc bị mất lòng tin đối với khách hàng, hoặc nếu khách hàng kiện thì có thể

bị phạt Nếu thời hạn hoàn thành quá dài thì khách hàng có thể chọn đối tác khác làm nhanh

hơn Ngoài việc ước lượng thời gian và giá cả, những người phát triển còn phải phân công

nhân sự một cách thích hợp cho từng giai đoạn Ví dụ nhóm viết chương trình chưa thể bắt

đầu khi các tài liệu thiết kế chưa được nhóm SQA kiểm tra và chấp nhận Nhóm thiết kế lại

không thể bắt đầu công việc nếu nhóm đặc tả chưa hoàn thành công việc của họ Tóm lại, kế hoạch quản lý dự án phần mềm (SPMP) cần được biên soạn kỹ lưỡng nhằm phản ánh các giai đoạn khác nhau của quá trình phát triển phần mềm, những thành viên tham gia trong từng giai đoạn và thời hạn cần hoàn thành.

Thời điểm sớm nhất để bắt đầu xây dựng SPMP là khi phần đặc tả kết thúc Trước đó thì dự

án vẫn chưa định hình nên không thể viết kế hoạch được Dĩ nhiên cũng có những phần của dự

án có thể lập kế hoạch sớm hơn, có thể ngay khi bắt đầu; tuy nhiên cho đến khi những người phát triển xác định được là cần xây dựng cái gì thì họ không thể xem xét mọi khía cạnh của dự

án và xây dựng kế hoạch được.

Những thành phần chính của kế hoạch là: những phần sản phẩm chuyển giao cho khách hàng, các mốc thời gian cần chuyển giao, chi phí của các phần sản phẩm này.

Bản kế hoạch mô tả tỉ mỉ quy trình phần mềm bao gồm: mô hình vòng đời phần mềm được sử dụng, cơ cấu tổ chức của công ty phần mềm, những mục tiêu của dự án, các kỹ thuật và các

công cụ CASE được sử dụng, lịch trình làm việc chi tiết, chi phí

SQA còn phải xem xét tính khả thi của đặc tả, ví dụ các phần cứng nói đến trong phần này thực

sự có phù hợp với việc cài đặt phần mềm không, dung lượng các bộ nhớ trên máy khách hàng có

đủ để vận hành phần mềm không Tài liệu đặc tả phải có thể kiểm thử được, ví dụ có thể dựa

vào tài liệu này mà kiểm tra tiến độ công việc thực hiện, có thể so sánh với từng mục trong pha

yêu cầu Tài liệu đặc tả cũng nên có các phần, các mục được đánh số tương ứng với tài liệu xác

16

Chương 2 Quy trình l m ph àm ph ần mềm

định yêu cầu để tiện theo dõi Nếu có bản mẫu trong pha yêu cầu thì trong tài liệu đặc tả cũngnên có các mục tương ứng với các chức năng trong bản mẫu

Cách tốt nhất để kiểm tra tài liệu đặc tả là xem xét Đại diện của nhóm đặc tả và nhóm khách

hàng cùng ngồi lại dưới sự chủ tọa của thành viên nhóm SQA, xem xét kỹ lưỡng bản đặc tả, pháthiện những sai sót, những điều chưa chính xác

Sau khi khách hàng đã vừa lòng với bản đặc tả thì chuyển sang xem xét bản kế hoạch thực hiện

dự án Cũng như với bản đặc tả, cách tốt nhất để kiểm tra bản kế hoạch là xem xét Hai yếu tố

cần chú ý là thời gian thực hiện và chi phí Thường thì các ước lượng về thời gian và chi phí được hai hoặc nhiều nhóm nghiên cứu độc lập nhau, sau đó cùng trao đổi để đưa ra kết luận

thống nhất

2.4.3 Tài liệu báo cáo trong pha đặc tả

Tài liệu được biên soạn trong pha đặc tả bao gồm hai tài liệu: bản báo cáo đặc tả và bản kế hoạch quản lý dự án phần mềm (SPMP).

Sau khi kết thúc việc phân chia phần mềm thành các module (thiết kế kiến trúc), nhóm làm việc

bắt đầu công việc thiết kế chi tiết cho từng module Với mỗi module cần chọn các thuật toán và các cấu trúc dữ liệu thích hợp.

Trong quá trình phân chia phần mềm thành các module, nhóm làm việc cần ghi chép lại các bước quyết định và lý do lựa chọn Làm như vậy có hai điều lợi:

Thứ nhất, có thể đôi khi công việc đi đến chỗ bế tắc, người ta phải quay lại và sửa đổi một số

quyết định của các bước trước đó Nếu có bản ghi chép đầy đủ thì việc quay lại này dễ dàng hơn

Thứ hai, việc ghi chép đầy đủ sẽ rất tốt cho công tác bảo trì Chúng ta biết rằng phần mềm

không bao giờ giữ nguyên mà thường hay bị sửa đổi Một phần mềm tốt phải có tính mở ended), có nghĩa là ta có thể thêm vào, bớt đi hoặc thay đổi một số module mà không phải thayđổi nhiều các phần còn lại Tuy nhiên điều này trong thực tế rất khó thực hiện Do sức ép về thờigian, nhóm làm việc chủ yếu tập trung vào việc thiết kế phần mềm theo các yêu cầu hiện có mà

(open-ít khi suy nghĩ đến việc mở rộng nâng cấp trong tương lai Nhóm làm việc thường chọn sự thỏahiệp là thiết kế và ghi chép lại sao cho sau này khi cần nâng cấp phần mềm thì biết được cầnthay đổi module nào, sao cho sự sửa đổi càng ít càng tốt Thậm chí ngay cả trong trường hợpphần mềm phải thiết kế lại hoàn toàn thì bản thiết kế cũ với ghi chép đầy đủ cũng sẽ cung cấpnhiều thông tin bổ ích

2.5.2 Kiểm thử pha thiết kế

Như đã nhắc đến, một tính chất rất quan trọng của một sản phẩm (tài liệu báo cáo, phần

mềm) là tính theo dõi được (traceable) Trong trường hợp thiết kế thì điều này có nghĩa là bản thiết kế phải là sự nối tiếp của bản báo cáo đặc tả Nhìn vào bản thiết kế ta phải biết được các

phần tương ứng với báo cáo đặc tả Bản thiết kế cũng phải được xem xét kỹ, xem nó đã thực sựphù hợp với báo cáo đặc tả chưa Tuy nhiên, khác với báo cáo yêu cầu và báo cáo đặc tả, bảnthiết kế đã mang tính chuyên nghiệp và nếu khách hàng không phải là kỹ sư tin học thì sẽ rất

khó hiểu Chính vì vậy khi kiểm tra bản thiết kế thì thường khách hàng không có mặt Công việc

xem xét này được nhóm SQA thực hiện Các lỗi thường được phát hiện trong pha này thường là:

Chương 2 Quy trình l m ph àm ph ần mềm

lỗi logic, lỗi giao tiếp, thiếu phần xử lý các trường hợp ngoại lệ, và quan trọng nhất là không tương hợp với báo cáo đặc tả Ngoài ra nhóm SQA cần chú ý nhận ra những lỗi trong các pha

trước nhưng chưa được phát hiện

2.5.3 Tài liệu báo cáo trong pha thiết kế

Sản phẩm chính trong pha này chính là bản thiết kế Bản này gồm hai phần: kiến trúc và chitiết Các bản thiết kế chi tiết sẽ được chuyển cho các lập trình viên để thực hiện công việc lậptrình

2.6 PHA CÀI ĐẶT

2.6.1 Giới thiệu

Trong pha này các lập trình viên viết chương trình cho các module theo thiết kế chi tiết

2.6.2 Kiểm thử pha cài đặt

Mỗi module cần kiểm thử trong khi thực hiện và sau khi hoàn thành (desk checking) Các

module được chạy thử với số liệu thử (test case) Ví dụ với module tính lãi suất thì ta thử nhập

số liệu là số tiền gửi, thời gian gửi, loại hình tiết kiệm rồi chạy thử để cho kết quả Số liệu nênđơn giản hoặc đã được tính toán trước bằng cách nào đó, sao cho ta có thể biết được chương

trình cho kết quả đúng hay sai Công việc thử từng module này được người lập trình thực hiện Sau đó nhóm SQA sử dụng một số phương pháp đã có để thử lại các module

Cùng với việc chạy thử các số liệu mẫu, việc xem xét các mã nguồn cũng là một cách kiểm thử

hiệu quả để tìm ra lỗi lập trình Người lập trình sẽ giới thiệu các dòng lệnh, cách hoạt động củacác module Nhóm xem xét mã nguồn cần có đại diện của nhóm SQA Cũng giống như việc xemxét báo cáo đặc tả hay thiết kế, hoạt động kiểm thử trong pha này của nhóm SQA cũng phảiđược ghi chép lại

2.6.3 Tài liệu báo cáo trong pha cài đặt

Tài liệu trong pha cài đặt chính là các mã nguồn của mỗi module cùng với các lời giải thích.

Các lập trình viên phải bổ sung bên cạnh mã nguồn những tài liệu khác để hỗ trợ cho việc bảo trì

sau này, ví dụ các số liệu và kết quả mẫu dùng để thử chương trình.

2.7 PHA TÍCH HỢP

2.7.1 Giới thiệu

Trong pha cài đặt thì từng module đã được kiểm thử Trong pha tích hợp các module sẽ đượckết hợp thành phần mềm và chúng ta cần kiểm tra xem các chức năng của phần mềm có hoạt

động chính xác không Thực tế chứng tỏ rằng nên tích hợp các module lúc có thể, chứ không

chờ đến lúc tất cả các module đều được xây dựng Nghĩa là nên thực hiện pha cài đặt và tích hợp song song với nhau

2.7.2 Kiểm thử pha tích hợp

Mục đích kiểm thử ở đây là kiểm tra xem các module có được kết hợp một cách chính xác

để tạo nên phần mềm thưc hiện đúng những yêu cầu nêu trong báo cáo đặc tả hay không Lúc

này cần chú ý đến phần giao tiếp giữa các module Ví dụ các tham số thực tế và các tham số

hình thức phải cùng loại, chúng cùng là thực, nguyên hay chuỗi ký tự chẳng hạn Tuy nhiên cónhững ngôn ngữ lập trình lại không đòi hỏi khắt khe về kiểu dữ liệu

Sau khi kiểm tra tích hợp và thấy rằng các module đã được ghép nối với nhau một cách chính

xác thì nhóm SQA chuyển sang kiểm thử phần mềm (product testing) Các chức năng của phần

mềm được kiểm tra theo các ràng buộc được nêu trong báo cáo đặc tả Ví dụ như chương trìnhtính toán và cho kết quả có đủ nhanh không Bởi vì mục tiêu của việc kiểm thử phần mềm là xác

định xem phần đặc tả có được thực hiện đúng không, vì vậy nên đưa ra nhiều trường hợp thử (tức là các số liệu và kết quả mẫu) khi kết thúc phần đặc tả.

18

Chương 2 Quy trình l m ph àm ph ần mềm

Không chỉ tính chính xác mà cả tính ổn định của chương trình cũng được kiểm thử Người ta

thử xem chương trình xử lý như thế nào với một dữ liệu sai Chương trình sẽ sụp đổ hay có cách

xử lý hợp lý hơn như thông báo và tạm ngừng chờ dữ liệu mới chẳng hạn Nếu chương trìnhđược cài trên máy khách hàng cùng với một phần mềm khác thì có gây sự xung khắc không

Bước cuối của kiểm thử tích hợp là kiểm thử chấp nhận (acceptance testing) Chương trình

được cài đặt trên máy khách hàng, chạy với cấu hình và số liệu thực Cho dù nhóm phát triển đã

sử dụng những số liệu mẫu như thế nào thì thường vẫn có sự khác biệt rất lớn giữa số liệu mẫu

và số liệu thực tế Phần mềm sẽ không được coi là thỏa mãn các đặc tả chừng nào chưa trải

qua kiểm thử chấp nhận.

Trong trường hợp phần mềm đóng gói thì không có khách hàng cụ thể Với phần mềm loại nàythì sau khi nhóm phát triển xây dựng và kiểm thử xong, phần mềm sẽ được gửi cho một sốkhách hàng được coi là những người sử dụng trong tương lai để họ dùng thử Phần mềm gửi đi

được gọi là phiên bản alpha Sau khi khách hàng (được lựa chọn) kiểm thử và hiệu chỉnh thì phiên bản alpha trở thành phiên bản beta Phiên bản beta thường được coi là gần với phiên bản

cuối cùng

Lỗi trong phần mềm đóng gói thường làm cho phần mềm không bán được và công ty phát triểnchịu thua lỗ lớn Các phiên bản alpha và beta được gửi cho một số công ty được lựa chọn và sửdụng vào công việc của họ với hy vọng trong quá trình sử dụng sẽ phát hiện ra các lỗi tiềm ẩn.Các công ty thử các phiên bản alpha và beta thường được hứa là được cung cấp miễn phí phầnmềm thành phẩm Tuy nhiên các công ty này cũng phải chịu sự rủi ro là rất có thể trong quátrình sử dụng thì lỗi trong phần mềm làm cho họ tốn thời gian vô ích, các lỗi này có thể làm tổnhại những công việc khác, ví dụ như cơ sở dữ liệu bị sụp chẳng hạn Bù lại, đôi khi các công tynày lại được hưởng lợi trong cạnh tranh do được sử dụng phần mềm mới, chưa ai có

2.7.3 Tài liệu báo cáo trong pha tích hợp

Sản phẩm trong pha tích hợp là các mã nguồn đã được hiệu chỉnh cùng các lời chú thích.Kèm theo đó là tài liệu hướng dẫn sử dụng, tài liệu hướng dẫn cài đặt và vận hành chương trình,giải thích các cơ sở dữ liệu Tóm lại tất cả các tài liệu cần thiết cùng với phần mềm để chuyểngiao cho khách hàng

2.8.2 Kiểm thử pha bảo trì

Khi một phần của phần mềm bị sửa đổi thì dĩ nhiên ta phải tiến hành kiểm thử lại Việc kiểm

thử ở đây bao gồm hai phần: thứ nhất cần kiểm tra xem phần mềm được sửa theo đúng yêu cầu đặt ra chưa Thứ hai là sau khi sửa đổi lại một phần của phần mềm thì phần còn lại có bị ảnh hưởng không Để thực hiện phép kiểm thử thứ hai này ta phải giữ lại tất cả các trường hợp thử

trước đây Việc dùng các dữ liệu mẫu cũ để thử lại các chức năng không liên quan đến phần

chương trình vừa sửa đổi được gọi là phép thử lùi lại hay phép thử hồi quy (regression testing).

Chương 2 Quy trình l m ph àm ph ần mềm

2.8.3 Tài liệu báo cáo trong pha bảo trì

Tài liệu quan trọng trong pha bảo trì là các ghi chép về các sửa đổi đã được thực hiện cùngcác lý do Khi phần mềm bị sửa đổi thì cần thực hiện phép thử hồi quy Do đó các trường hợpthử hồi quy cũng là một phần quan trọng trong tài liệu này

2 Sau nhiều lần thực hiện các sửa đổi trên thiết kế ban đầu làm cho các phần của phần mểm

trở nên quá phụ thuộc lẫn nhau (một cách tình cờ chứ không phải là do yêu cầu của phần

mềm) do đó mỗi lần thay đổi một module nhỏ cũng có thể làm ảnh hướng đến các chức năngcủa toàn bộ phần mềm nên việc bảo trì trở nên quá khó khăn Tốt nhất là đặt lại yêu cầu vàthiết kế mới từ đầu, tức là làm phần mềm mới

3 Sau nhiều lần sửa đổi nhưng các tài liệu lại không cập nhật đầy đủ nên không kiểm soát

được các lỗi hồi quy Tốt nhất là nên viết lại phần mềm.

4 Phần cứng đã bị thay đổi Phần mềm không còn thích hợp nữa, tốt nhất là nên viết lại.

Trong các trường hợp trên đây, phần mềm cũ được thay bằng phần mềm mới và quy trình phầnmềm lại được bắt đầu Sự kết thúc sử dụng thực sự thường ít xảy ra hơn nhưng không phải là cábiệt Nếu một phần mềm trở nên lỗi thời thì dĩ nhiên người ta không sử dụng chúng nữa và xóakhỏi các máy tính của họ Ví dụ ở Việt nam thì các phần mềm soạn thảo văn bản thế hệ cũ đãđược loại bỏ và thay thế các phần mềm hoàn toàn mới

20

CHƯƠNG 3 CÁC MÔ HÌNH VÒNG ĐỜI PHẦN MỀM

Như đã nêu trong chương 1, dãy các bước mà một phần mềm trải qua, bắt đầu từ những khảo

sát đầu tiên cho đến khi phần mềm không còn được sử dụng được gọi là vòng đời phần mềm.

Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn Có phần mềm dùngmột vài năm cho pha khảo sát, tìm hiểu vấn đề Những trường hợp như thế này thường xảy ra dochưa có phần cứng phù hợp để xây dựng phần mềm, hoặc cần phải tiến hành khá nhiều nghiêncứu để tìm ra thuật toán hiệu quả Có sản phẩm được thiết kế và viết chương trình rất nhanhnhưng lại tốn hàng năm để bảo trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu củakhách hàng Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận thấyrằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì sản phẩm cũ Chođến nay có rất nhiều mô hình vòng đời phần mềm được sử dụng Tuy nhiên ở đây chúng ta chỉtìm hiểu một vài mô hình tiêu biểu xét cả về mặt nhược điểm và mặt ưu điểm

3.1 MÔ HÌNH XÂY DỰNG-VÀ-HIỆU CHỈNH (BUILD-AND-FIX MODEL)

Có khá nhiều phần mềm đã được xây dựng dựa trên mô hình xây dựng-và-hiệu chỉnh Trong

mô hình này không có các pha phân tích thiết kế Phần mềm được xây dựng như sau: người

phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên Tiếp theo, phần mềm đượcchạy thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa

ý (tức là đáp ứng được yêu cầu của khách hàng) Sau khi được khách hàng chấp nhận, phầnmềm được đưa vào sử dụng và bảo trì Mô hình này có thể biểu diễn trong sơ đồ sau:

Hình 3.1 Mô hình xây dựng-và-hiệu chỉnh

Vì sao cách thức này được nhiều người sử dụng để làm phần mềm, nhất là các phần mềm nhỏ?Nếu nói chính xác hơn thì mô hình trên đây không có tài liệu phân tích, thiết kế Vì thực ra khiviết chương trình thì người phát triển cũng phải hình dung ra các chức năng của phần mềm,những module phải có, những thuật toán sử dụng Nghĩa là phần nào đó họ cũng có phân tíchthiết kế, nhưng họ không biên soạn lại thành tài liệu mà thôi Chắc các bạn cũng đã từng thấynhững bác thợ mộc miệt mài làm việc, chẳng thấy có bản vẽ thiết kế nào mà họ vẫn làm ranhững chiếc tủ, chiếc giường rất đẹp Dĩ nhiên là họ không làm một cách vô thức mà theo mộtcách thức có sẵn trong trí nhớ của họ Nếu phần mềm do một người viết và dễ dàng trao đổi vớikhách hàng thì có lẽ mô hình xây dựng-và-hiệu chỉnh là cách nhanh nhất để đi tới sản phẩm Saukhi viết phiên bản đầu tiên, người phát triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũnghiểu rõ các dòng lệnh vừa viết Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần mềm thì họbiết ngay cần phải hiệu chỉnh phần nào của chương trình Công việc thường được thực hiện khánhanh chóng và phần mềm sớm được hoàn thành và đưa vào sử dụng

Về hình thức, cách làm phần mềm theo kiểu xây dựng-và hiệu chỉnh cũng giống như làm bản

mẫu Tuy nhiên có một sự khác biệt, là khi làm bản mẫu ta bỏ qua các yếu tố quan trọng khác

Xây dựng phiên bản đầu tiên

Hiệu chỉnh cho đến khi khách h ng ch à nội, 2009 ấp nhận

Sử dụng và nội, 2009 bảo trì

Thôi sử dụng Phát triển

Bảo trì

Chương 3 Các mô hình vòng đời phần mềm

mà chỉ tập trung mô tả các yêu cầu của khách hàng; còn trong mô hình xây dựng-và-hiệu chỉnhthì ta chú ý tới cả các đặc trưng này khi xây dựng phần mềm

Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì Công việc bảo trì thường là sửa lỗi

và cập nhật Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệmcông việc này thì không có vấn đề gì lắm Tuy nhiên nếu phần mềm đã được sử dụng sau mộtthời gian dài, khiến cho chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặcviệc bảo trì lại do một người khác thực hiện thì sẽ rất khó khăn Nếu bạn thử đọc chương trìnhnguồn của một tác giả khác mà không có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu.Đôi khi bạn tìm hiểu vấn đề rồi viết mới chương trình có lẽ còn đơn giản hơn là sửa lại chươngtrình của người khác

Rõ ràng mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ítkhả năng phải sửa đổi trong quá trình sử dụng Ngày nay các phần mềm thường lớn, do nhiềungười viết do đó cách thức này trở nên không thích hợp Khi có nhu cầu làm phần mềm, ta cầnlựa chọn mô hình vòng đời thích hợp (đôi khi ta nói đơn giản là mô hình) Mô hình này phảiđược cả nhóm làm phần mềm nhất trí, sau đó công việc phát triển phần mềm mới thực sự đượcbắt đầu

Cho đến đầu những năm 1980 mô hình được sử dụng rộng rãi nhất là mô hình thác đổ(waterfall) mà ta sẽ nghiên cứu sau đây

3.2 MÔ HÌNH THÁC ĐỔ (WATERFALL MODEL)

Mô hình thác đổ là mô hình phát triển phần mềm được đưa ra lần đầu tiên bởi W.W Roycevào năm 1970 Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy

trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì Thực ra, Royce có mô

tả tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặckhông phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước Hình 3.2 là sơ đồ biểu diễn mô hình thác

đổ

Hình 3.2 Mô hình thác đổ (waterfall model)

Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm.Tuy nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm nhưsau:

 Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị Mặc

dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp Kết quả là những thay đổi cóthể gây ra lẫn lộn khi nhóm phát triển làm việc

22

Phát triển Bảo trì

Chương 3 Các mô hình vòng đời phần mềm

 Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự không chắc chắn

tự nhiên tồn tại vào lúc đầu của nhiều dự án Khách hàng phải kiên nhẫn chờ đợi, vì bản

làm việc được của chương tình chỉ có được vào cuối của thời gian dự án Một sai lầm ngớngẩn, nếu đến lúc có chương trình làm việc mới phát hiện ra, có thể là một thảm họa

 Với việc phân tích một số dự án hiện tại, Bradax thấy rằng bản chất tuyến tính của vòng đời cổ điển dẫn tới "các trạng thái tắc nghẽn", nghĩa là có một số thành viên của nhóm phát

triển phải chờ đợi sự chuyển giao từ nhóm khác hoàn thành công việc ở pha trước Trongthực tế, thời gian chờ đợi có thể vượt quá thời gian sản xuất Trạng thái nghẽn có xuhướng xẩy ra vào thời gian đầu và cuối của quy trình phần mềm

Tuy nhiên, mô hình vòng đời cổ điển có một vị trí quan trọng vì nó đưa ra một hình mẫu về cácbước mà một phần mềm cần phải trải qua là: phân tích hệ thống, thiết kế, cài đặt, tích hợp vàbảo trì Nhiều mô hình sau này là cải tiến mô hình này, nhưng vẫn giữ lại những điểm cốt lõi

3.3 MÔ HÌNH BẢN MẪU (RAPID PROTOTYPING MODEL)

Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thaybằng bản mẫu Mô hình này có thể biểu diễn bởi sơ đồ sau:

Hình 3.3 Mô hình bản mẫu (rapid prototyping model)Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra (verify), các pha càiđặt và tích hợp có kiểm thử (test)

Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất

Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng Người phát triển và khách hàngcùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu

nào đã rõ ràng, yêu cầu nào còn phải xác định thêm Tiếp theo là việc "thiết kế nhanh" Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ màn hình nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo Người phát triển có thể kết hợp để thử nghiệm một thuật toán Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự

Phát triển Bảo trì

Chương 3 Các mô hình vòng đời phần mềm

hợp lý Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu Bản mẫu được giới thiệu với kháchhàng và có thể để họ dùng thử và đánh giá, góp ý kiến Trên cơ sở ý kiến khách, hàng ngườiphát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý (chủ yếu là cái vào, cái ra,giao diện ) Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu cầu khách hàng, nhữngyêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập trình phù hợp

24

Chương 3 Các mô hình vòng đời phần mềm

Hình 3.4 Mô thức làm bản mẫuMột câu hỏi đặt ra là: bản mẫu được hiệu chỉnh cho đến khi khách hàng vừa ý, vậy có nên sửdụng ngay bản mẫu này hoặc hoàn thiện thêm để thành bản chính chuyển giao cho khách hàngkhông?

Về vấn đề này Brook đã nêu câu trả lời như sau:

Trong hầu hết các dự án, hệ thống đầu tiên hiếm khi sử dụng được Nó có thể là quá chậm, quá lớn, cồng kềnh trong sử dụng hay tất cả những nhược điểm này Không có cách nào khác là bắt đầu lại, đau đớn nhưng tinh khôn hơn, và xây dựng lại một phiên bản trong đó những vấn đề này đã được giải quyết.

Một cách lý tưởng, bản mẫu chỉ được xem như một cơ chế để xác định các yêu cầu của phần mềm Khách hàng thường không biết được chất lượng thực sự của bản mẫu Họ không biết được

rằng trong khi xô đẩy để cho bản mẫu thể hiện được những yêu cầu khách hàng thì người takhông để ý đến chất lượng tổng thể hay tính bảo trì lâu dài của phần mềm Khi được thông báolại là sản phẩm được xây dựng lại để nó đạt tới mức độ chất lượng cao thì khách hàng thườngkêu trời và đòi hỏi rằng "phải ít sửa chữa" Cách tốt nhất là ngay từ đầu nên xác định với kháchhàng là bản mẫu chỉ sử dụng để xác định đúng yêu cầu khách hàng mà thôi

So sánh mô hình thác đổ và mô hình bản mẫu

Trong mô hình thác đổ, mục đích của pha xác định yêu cầu là làm sao nắm bắt được nhữngyêu cầu của khách hàng Tuy nhiên việc này thường gặp khó khăn do khách hàng đôi khi khôngdiễn đạt được chính xác yêu cầu của mình và có thể người phát triển đôi khi hiểu sai ý của kháchhàng Việc sử dụng bản mẫu trong pha xác định yêu cầu sẽ khắc phục được phần nào tình trạngnày Khách hàng dễ kiểm tra lại các yêu cầu của mình qua việc chạy thử các chức năng của phần

mềm bản mẫu Thực chất thì mô hình bản mẫu cũng là mô hình thác đổ nhưng kỹ thuật khảo sát

được sử dụng là bản mẫu Việc sử dụng bản mẫu còn có điểm lợi là giúp các nhà phát triển có cơhội áp dụng thử và đánh giá những công nghệ và kỹ thuật mới và có thể giảm thiểu những rủi rokhi sử dụng những công nghệ mới này

3.4 MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL)

Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy Nếu như khi xây dựngngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềmchúng ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp Mộtphần mềm ra đời, được đưa vào sử dụng Trong quá trình sử dụng ngoài việc phát hiện và sửachữa sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêmmột số chức năng Ví dụ như khi làm phần mềm soạn thảo văn bản chẳng hạn Phiên bản đầu

có thể chưa có chức năng kiểm tra chính tả, chưa có chức năng chèn hình ảnh Người ta nângcấp phiên bản này bằng cách bổ sung các chức năng này Sau khi hoàn thành công việc nàyngười ta lại thấy nên thêm chức năng vẽ đồ thị, thêm khả năng tính toán trong bảng Mỗi lầnnâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét sửa đổi lại tài liệucác pha

Từ nhận xét rằng phần mềm có thể được xây dựng từng bước đã đưa đến việc ra đời một mô hình mới là mô hình tăng dần.

Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đốiđộc lập nhau Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file

Lắng nghe

khách h ngà nội, 2009 Xây dựng/hiệu chỉnh bản mẫu

Khách h ng à nội, 2009chạy thử bản mẫu

Chương 3 Các mô hình vòng đời phần mềm

management system, Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế,lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành

phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng Ban đầu người ta chưa chú ý

đến toàn bộ các yêu cầu của phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây

dựng phiên bản đầu tiên của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử

dụng Chương trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng Tiếp theo người ta lại

xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho khách

hàng sử dụng và có ý kiến Phần mềm thứ hai này sau khi hiệu chỉnh lại được tích hợp vào phầnmềm đầu tiên thành một phần mềm lớn hơn Phần mềm tích hợp này lại được kiểm thử để bảo

đảm việc ghép nối thành công và chương trình chạy tốt Cứ như vậy, thay vì xây dựng phần

mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được

sản phẩm mong muốn Sơ đồ sau mô tả mô hình tăng dần

Hình 3.5 Mô hình tăng dần (incremental model)

Nhận xét mô hình tăng dần

Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiênbản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay Thời gianhoàn thành phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn Với môhình tăng dần thì phần mềm được chia ra nhiều phần (thường là từ 5 đến 25 phần) Phần đầu tiênchứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao chokhách hàng sử dụng Thời gian hoàn thành phần đầu tiên này thường rất ngắn so với thời gianxây dựng toàn bộ phần mềm hoàn chỉnh Như vậy khách hàng được sử dụng sản phẩm trong thờigian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm Khi mỗi phần sau đượchoàn thành và được tích hợp thì họ được sử dụng ngay Như vậy họ được làm quen từng bướcvới sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ mới Nhờ theo sát từngbước phát triển của phần mềm mà khách hàng có thể có những ý kiến xác đáng, giúp cho nhàphát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra, thậm chíqua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không nên phát triển tiếp vì sẽkhông mang lại lợi ích kinh tế

Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với

phần chương trình đã có Thiết kế của mô hình này do vậy phải có tính mở và tính mềm dẻo để

26

Phát triển Bảo trì

Xác định yêu cầu

Phân tích

Thiết kế kiến trúc

Với mỗi build thực hiện:

Thiết kế chi tiết, lập trình, tích hợp, kiểm thử rồi chuyển giao cho khách h ng à nội, 2009

Bảo trì

Thôi sử dụng

Chương 3 Các mô hình vòng đời phần mềm

thích nghi với việc mở rộng dần Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì cập nhật (nâng cao) Nếu vận dụng không hợp

lý, mô hình này có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh Sự điều khiển toàn bộ

quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi

kinh hoàng cho những người bảo trì Để tránh được điều này, người phát triển ngay từ đầu phải

có cách nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia

các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó Như sơ đồ 3.5

chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng Nếu không có những nhà chuyên môn trình độ cao thì sản

phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng

Khi nào nên sử dụng mô hình tăng dần?

Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập nhau thì có thể ápdụng mô hình này Với những bài toán như xây dựng phần mềm quản lý dịch vụ bay ở các công

ty hàng không, chương trình quản lý tín dụng ở ngân hàng chẳng hạn, tính liên kết giữa cácthành phần khá cao nên không nên áp dụng mô hình này

3.5 MÔ HÌNH TĂNG DẦN ĐỒNG THỜI (CONCURRENT INCREMENTAL MODEL)

Mô hình tăng dần đồng thời được công ty Fujitsu (Nhật) sử dụng để xây dựng phần mềmtruyền thông cỡ lớn vào khoảng năm 1993 Sau này K Beck chính xác hóa khái niệm này vào

năm 1999 và đặt tên là "lập trình cực điểm" (extreme programming) Tuy nhiên chúng ta sẽ

gọi là mô hình tăng dần đồng thời cho dễ hình dung Có thể tóm tắt mô hình này như sau:

Trước hết người ta tìm hiểu nhu cầu khách hàng rồi phân chia thành nhóm các đặc trưng tươngứng với từng phần của phần mềm cần xây dựng Sau đó nhóm đặc tả tiến hành xây dựng đặc tảcủa phần thứ nhất, sau khi hoàn thành thì trao kết quả cho nhóm thiết kế thực hiện thiết kế,nhóm lại chuyển qua đặc tả thành phần thứ hai, cứ như vậy các thành phần được xây dựngsong song, và mỗi nhóm sử dụng các thông tin nhận được từ các thành phần trước đó

Cách tiếp cận này thực sự đã gây ra rủi ro là các thành phần có thể không tương thích với nhau.

Với mô hình tăng dần, khả năng rủi ro phần nào được giảm thiểu vì thiết kế kiến trúc được thựchiện trước khi phần mềm được chia nhỏ thành từng phần và được xây dựng

Sơ đồ mô hình này như sau:

Hình 3.6 Mô hình tăng dần đồng thời (concurrent incremental model)

Đây là mô hình còn có nhiều tranh cãi Thực chất là mô hình tăng dần, nhưng các phần đượcthực hiện đồng thời Mô hình này có tính rủi ro cao hơn mô hình tăng dần thông thường Bướcđầu tiên nhóm phát triển phần mềm dựa vào ý kiến khách hàng để xác định các đặc trưng khácnhau của phần mềm Với mỗi đặc trưng như vậy họ thông báo cho khách hàng là phải xây dựng

Phần 1 Phân

tích Thiết kế C i à nội, 2009 đặt&

Tích hợp

Chuyển giao cho khách h ng à nội, 2009

Phần 2 Phân

tích Thiết kế C i à nội, 2009 đặt&

Tích hợp

Chuyển giao cho khách h ng à nội, 2009

Phần k Phân

tích Thiết kế C i à nội, 2009 đặt&

Tích hợp

Chuyển giao cho khách h ng à nội, 2009 Nhóm phân tích

Nhóm thiết kế

Nhóm c i à nội, 2009 đặt v tích h à nội, 2009 ợp

Chương 3 Các mô hình vòng đời phần mềm

trong bao lâu và giá cả bao nhiêu Tiếp theo khách hàng lựa chọn những đặc trưng cho các phầncần xây dựng dựa trên phân tích giá cả và lợi nhuận (cost-benifit analysis), tức là phân tích dựatrên thời gian và giá cả nêu ra bởi nhóm phát triển và lợi nhuận dự tính của công ty họ Mỗiphần được lựa chọn lại được chia thành từng phần nhỏ hơn, được gọi là các nhiệm vụ Mỗi lậptrình viên trước hết nêu ra các trường hợp để thử cho từng nhiệm vụ sau đó cùng làm việc vớicộng sự của họ trước một màn hình (kiểu lập trình này được gọi là pair programming) Lập trìnhviên hoàn thành nhiệm vụ được giao và chạy các trường hợp thử để bảo đảm phần chương trình

họ viết đã chạy tốt Phần chương trình này sau đó được tích hợp vào phiên bản hiện thời củaphần mềm cần xây dựng Trường hợp lý tưởng là cả phần lập trình và tích hợp cho một nhiệm

vụ chỉ kéo dài trong vài giờ Thường thì các cặp lập trình viên thực hiện các nhiệm vụ songsong, như thế sự tích hợp sẽ được tiến hành một cách liên tiếp Các trường hợp dùng để thử cácnhiệm vụ được giữ lại cho các phép kiểm thử tích hợp sau này Một số đặc trưng của lập trìnhcực điểm (XP) có phần nào hơi khác thường:

1 Máy tính của các nhóm lập trình cực điểm được đặt giữa phòng lớn, trong các phòng nhỏ cóvách ngăn

2 Đại diện của khách hàng luôn luôn làm việc cùng nhóm XP

3 Không ai làm việc quá giờ trong hai tuần liên tục

4 Không có phân công đặc biệt Tất cả các thành viên của nhóm XP đều có thể tham gia phântích, thiết kế, lập trình và kiểm thử

5 Như sơ đồ đã chỉ ra, không có thiết kế tổng thể trước khi các phần được xây dựng Thay vào

đó, thiết kế sẽ được hiệu chỉnh khi sản phẩm được xây dựng Thủ tục này được gọi là táiphân tích nhân tố (refactoring) Khi một trường hợp thử không chạy tốt thì các lệnh sẽ đượcviết lại cho đến khi nhóm lập trình thấy rằng thiết kế là đơn giản, rõ ràng và mọi trường hợpthử đều chạy tốt

Mô hình này đã được sử dụng hiệu quả cho một số phần mềm vừa và nhỏ,có dung lượng côngviệc từ 9 người-tháng cho đến 100 người-năm Mô hình này thực sự có lợi khi yêu cầu củakhách hàng không rõ ràng và hay thay đổi Tuy nhiên mô hình này còn chưa được sử dụng rộngrãi và do đó cũng chưa có điều kiện để kiểm chứng lại kết luận trên đây

3.6 MÔ HÌNH ĐỒNG BỘ-VÀ-ỔN ĐỊNH (SYNCHRONIZE-AND-STABILIZE MODEL)

Công ty Microsoft là công ty sản xuất phần mềm đóng gói lớn nhất thế giới Hầu hết phầnmềm của họ được xây dựng dựa trên một phiên bản của mô hình tăng dần có tên gọi là đồng bộ-và-ổn định hóa (synchronize-and-stabilize model) Pha xác định yêu cầu được thực hiện bằngcách phỏng vấn rất nhiều khách hàng dự kiến và các đặc trưng của nhu cầu khách hàng được liệt

kê theo thứ tự ưu tiên Sau đó tài liệu đặc tả được soạn thảo Tiếp theo, công việc được chia làm

ba hoặc bốn phần Phần thứ nhất chứa các đặc trưng quan trọng nhất, phần thứ hai chứa các đặctrưng quan trọng thứ nhì Mỗi thành phần sẽ được xây dựng bởi một số nhóm nhỏ làm việc songsong Cuối mỗi ngày các nhóm đồng bộ hóa (synchrronize), tức là họ hợp lại những phần họ đãlàm riêng biệt thành một thành phần thống nhất, kiểm tra, sửa lỗi và kiểm thử Sự ổn định hóa(stabilize) được thực hiện ở giai đoạn cuối của mỗi phần Trong giai đoạn này những lỗi còn sótlại được phát hiện, được sửa chữa và thành phần được đóng gói (frozen), tức là không thực hiệnthay đổi nào đối với các đặc tả

Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau có thể được kết hợp

và cùng làm việc tốt.Một điểm lợi của cách làm này là những người phát triển có thể sớm nhìnthấy sự hoạt động của phần mềm và có thể hiệu chỉnh các yêu cầu, có thể là ngay trong quá trìnhcác thành phần được xây dựng Mô hình này có thể áp dụng ngay cả trong trường hợp các đặc tảban đầu không hoàn thiện

3.7 MÔ HÌNH XOẮN ỐC (SPIRAL MODEL)

Mô hình xoắn ốc (do Boehm đề xuất năm 1988) là kết hợp các khía cạnh của các mô hìnhtrên đây Cụ thể hơn, mô hình xoắn ốc là sự kết hợp tính lặp của mô hình bản mẫu và tính hệ

28

Chương 3 Các mô hình vòng đời phần mềm

thống của mô hình thác đổ Về bản chất, mô hình mô tả sự phát triển của phần mềm qua cácgiai đoạn tiến hoá, mỗi giai đoạn được coi như một mô hình thác đổ Ban đầu người ta chưa địnhnghĩa hệ thống một cách chi tiết, mà chỉ chú ý đến những đặc trưng nổi bật nhất Sau đó phầnđặc trưng này được xây dựng và đưa cho khách hàng xem xét, có ý kiến (cũng không hẳn là sửdụng cho công việc như trong mô hình tăng dần) Cùng những thông tin phản hồi từ khách hàng,người phát triển trở lại thực hiện các đặc trưng với mức độ chi tiết hơn Bản chất mô hình xoắn

ốc như tên gọi của nó, là bắt đầu từ những cái khái quát nhất rồi đi dần đến chi tiết Trong quá

trình đó có lập kế hoạch cho từng giai đoạn làm chi tiết hóa sản phẩm và phân tích rủi ro Tàiliệu này chẳng hạn, cũng được biên soạn theo cách thức "xoắn ốc": ban đầu nêu các khái niệmchung, về sau đi sâu dần vào các chi tiết

Quá trình xây dựng phần mềm thường chứa đựng những rủi ro Ví dụ người chủ chốt có thểxin nghỉ việc trước khi phần mềm được hoàn thành Công ty chế tạo phần cứng mà phần mềm sẽcài đặt bị phá sản Sau khi chi phí hàng trăm nghìn đô la cho sự phát triển phần mềm bỗng cómột bước thay đổi đột phá trong công nghệ làm cho phần mềm trở nên vô dụng, phải thiết kế lạihoàn toàn Công ty có thể nghiên cứu và phát triển hệ quản trị cơ sở dữ liệu, nhưng trước khi sảnphẩm được hoàn thành và đưa ra thị trường thì một công ty khác lại quảng cáo một hệ tươngđương có giá rẻ hơn Có thể công ty sử dụng mô hình tằng dần đồng thời, nhưng sau đó cácthành phần không thể tích hợp được với nhau để được phần mềm như yêu cầu đặt ra Nói tómlại, các nhà phát triển phần mềm thường có thể gặp rất nhiều rủi ro và họ muốn giảm thiểu cáckhả năng rủi ro đến mức có thể

Một trong những cách làm giảm thiểu khả năng rủi ro là sử dụng bản mẫu Như ta đã thấy, sửdụng bản mẫu trong pha xác định yêu cầu là cách thức tuyệt với để ngăn ngừa khả năng sản xuất

ra một phần mềm không thỏa mãn tất cả các yêu cầu của khách hàng Trong các pha tiếp theongười ta cũng có thể xây dựng những bản mẫu thích hợp Ví dụ, công ty điện thoại có thể vừaphát minh ra một thuật toán hiệu quả cho việc phân tuyến các cuộc gọi thông qua mạng diênrộng Nếu phần mềm được xây dựng nhưng không làm việc được như mong muốn, thì công ty

sẽ bị thiệt hại về kinh phí Trong trường hợp này khách hàng có thể bực tức và chuyển sang lựachọn một công ty khác Tình trạng này có thể được loại trừ nếu ta xây dựng một bản mẫu chỉdùng cho mục đích phân tuyến các cuộc gọi và được kiểm thử trên thiết bị mô phỏng Bằng cáchnày hệ thống thật sẽ không bị ảnh hưởng, và giá của công lập trình chỉ là thuật toán phân tuyến.Sau khi thử nghiệm, công ty sẽ quyết định được là có nên áp dụng thuật toán mới cho toàn hệthống của họ hay không

Ý tưởng làm giảm thiểu rủi ro thông qua việc sử dụng các bản mẫu và một số công cụ khác dẫnđến một mô hình mới mang tên: mô hình xoắn ốc( spiral model) Cách đơn giản nhất để xem xét

mô hình này chính là mô hình thác đổ trong đó mỗi pha (trừ pha bảo trì) được bổ sung phầnphân tích rủi ro ở trước Trước khi bắt đầu một pha nào đó người ta phân tích các khả năng rủi

ro và cách thức giải quyết có thể Nếu không có cách nào để giải quyết được các rủi ro quantrọng thì dự án sẽ kết thúc

Bản mẫu có thể sử dụng một cách hiệu quả để thu thập thông tin về sự rủi ro Ví dụ ràng buộc vềthời gian có thể kiểm thử bằng cách xây dựng một bản mẫu và ước lượng thời gian hoàn thànhsản phẩm thông qua thời gian xây dựng bản mẫu Bản mẫu với số liệu hoặc thiết bị mô phỏng cóthể kiểm tra tính thích hợp của một thuật toán mới

Tuy nhiên cũng có những rủi ro không thể đánh giá được thông qua bản mẫu Ví dụ như nếumột thành viên chủ chốt xin thôi việc trước khi sản phẩm hoàn thành thì liệu có thể thuê đượcngười thay thế kịp thời hay không? Hoặc trình độ của các thành viên trong nhóm phát triển liệu

có đáp ứng được việc phát triển phần mềm quy mô lớn hay không? Các thành viên công ty lâunay vẫn thường xây dựng các phần mềm sử dụng trong gia đình, nay phải xây dựng phần mềmphức tạp sử dụng trong công sở thì có làm được không? Một lĩnh vực khác mà bản mẫu cũngkhông sử dụng được trong việc đánh giá rủi ro là những hứa hẹn về sự phát triển phần cứng.Phần mềm được phát triển có tính tới sự ra đời của các thiết bị mà các công ty phần cứng hứahẹn, nhưng thực tế lại không xảy ra như vậy

Chương 3 Các mô hình vòng đời phần mềm

Mô hình xoắn ốc cung cấp cách thức làm phần mềm bằng cách đưa ra các phiên bản tăng dần

Sự tăng dần ở đây không phải là bổ sung thêm các thành phần mới như mô hình tăng dần, mà sựtăng ở đây là sự tiến hóa (evolution), tức là cũng các đặc trưng ấy nhưng được làm mịn hơn, chitiết hơn Phiên bản sau cùng chính là phần mềm hoàn chỉnh có thể chuyển giao cho khách hàng

sử dụng

Mô hình xoắn ốc được chia thành một số khuôn khổ hoạt động, cũng còn được gọi là vùng nhiệm vụ Về cơ bản, có khoảng từ ba đến sáu vùng Ví dụ bốn vùng như sau:

1 Xác định mục tiêu, các giải pháp khác nhau để đạt được mục tiêu, các ràng buộc

2 Phân tích rủi ro và khả năng giải quyết (thường là xây dựng bản mẫu)

3 Phát triển và kiểm tra

4 Lập kế hoạch cho pha tiếp theo

Để biểu diễn sơ đồ cho mô hình xoắn ốc, người ta vẽ hai đường thẳng vuông góc cắt nhau chiamặt phẳng thành 4 vùng Bốn vùng này tương ứng với 4 vùng công việc: nếu dịch chuyển theochiều kim đồng hồ và bắt đầu từ góc phần tư phía trên bên trái ta có các vùng tương ứng là1,2,3,4

Coi giao điểm của hai đường thẳng là tâm, ta vẽ các đường xoắn ốc đi từ phía trong ra ngoàicũng theo chiều kim đồng hồ Độ dài đường xoắn ốc sẽ biểu diễn giá tích lũy của phần mềm,Một vòng của đường xoắn ốc sẽ biễu diễn một pha Nếu đi từ trong ra ngoài ở góc phần tư số 3

ta được mô hình thác đổ Một pha bắt đầu từ góc phần tư phía trên bên trái (góc 1) bằng việcxác định các mục tiêu của pha, các giải pháp khác nhau để đạt được các mục tiêu này và cácràng buộc cho từng giải pháp Kết quả của giai đoạn này là chọn được giải pháp thích hợp Ởgóc phần tư thứ hai là phân tích rủi ro cho giải pháp đã lựa chọn Một vài biện pháp được đưa

ra để khắc phục rủi ro Biện pháp thường được sử dụng là bản mẫu Nếu rủi ro lớn và không cóbiện pháp khắc phục thì dự án phải dừng lại Trong một số trường hợp, dự án vẫn được tiếp tụcnhưng với quy mô nhỏ hơn Nếu vấn đề rủi ro được giải quyết thì chuyển sang góc phần tư thứ

ba là phát triển Ở góc cuối cùng là kế hoạch cho pha tiếp theo Đường xoắn ốc sẽ được lặp lạichừng nào sản phẩm chưa đạt mức hoàn chỉnh

Tuy nhiên mô hình này không phải là sự lựa chọn tốt nhất cho mọi dự án

- Trước hết, phân tích rủi ro sẽ tốn kém, do đó mô hình chỉ có thể áp dụng cho các dự án lớn,khi mà chi phí phân tích rủi ro là không đáng kể so với tổng chi phí toàn bộ dự án

- Phân tích rủi ro được thực hiện trong suốt quá trình phát triển phần mềm Tuy nhiên nếu làphần mềm ký hợp đồng mà bị dừng lại thì công ty phát triển sẽ bị phạt Do đó với các dự án

ký hợp đồng thì nhà phát triển và khách hàng phải phân tích rủi ro trước khi hợp đồng được

ký, chứ không phải trên đường xoắn ốc như mô hình mô tả

- Liệu các nhà phát triển đã nhìn thấy hết các rủi ro không? Có thể rủi ro vẫn còn nhưng họ lạichủ quan cho rằng đã hết và có thể mắc sai lầm Như vậy mô hình này chỉ nên áp dụng nếucông ty phần mềm có một đội ngũ chuyên gia phân tích rủi ro trình độ cao

Cuối cùng, chính bản thân mô hình xoắn ốc còn chưa được áp dụng rộng rãi như mô hình thác

đổ hoặc mô hình bản mẫu Cần có thêm thời gian để xác định tính hiệu quả mô hình này

30

1

2

Chương 3 Các mô hình vòng đời phần mềm

3.8 MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODEL)

Theo kinh nghiệm thì trong phương pháp hướng đối tượng, tính lặp giữa các pha và giữa cácphần trong một pha xẩy ra nhiều hơn so với phương pháp cấu trúc Khi xây dựng mô hình hướngđối tượng người ta muốn chỉ rõ đặc trưng này Một trong những mô hình như vậy là mô hình núiđồi được biểu diễn bằng các hình tròn có một phần chồng lên nhau Mỗi vòng tròn chỉ một pha.Vòng tròn không rời nhau chỉ ra rằng các pha có phần chung nhau Bên trong các vòng tròn cócác mũi tên uốn cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các phần

Các pha có phần chung là:

- Pha yêu cầu và pha phân tích hướng đối tượng

- Pha thiết kế hướng đối tượng, pha lập trình và tích hợp

- Pha sử dụng và bảo trì

CHƯƠNG 5 PHA XÁC ĐỊNH YÊU CẦU

5.1 NẮM BẮT YÊU CẦU

Quá trình khám phá các yêu cầu của khách hàng được gọi là sự nắm bắt yêu cầu (requirements

capture), hoặc sự gợi mở yêu cầu (requirements elicitation) hay tìm hiểu vấn đề (conceptexploration) Sau khi các yêu cầu được xác định thì chúng được xem xét để hiệu chỉnh, lược bỏ

bớt hoặc mở rộng Quá trình này được gọi là phân tích yêu cầu (requrements analysis) Pha yêu

cầu thường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên của nhóm yêu cầu vàmột vài thành viên đại diện cho công ty khách hàng để cùng nhau xác định xem sản phẩm phầnmềm cần những gì Cuộc trao đổi thường được thực hiện theo cách là thành viên của nhóm yêucầu đưa ra các câu hỏi có tính gợi mở về lĩnh vực mà phần mềm được sử dụng Các thành viêncủa công ty khách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ động nêu ra các vấn

đề mà họ cần Rõ ràng những thành viên tham gia khám phá yêu cầu của khách hàng phải cóhiểu viết về lĩnh vực mà phần mềm ứng dụng để có thể hiểu được những điều khách hàng nói và

có thể đưa ra các câu hỏi có ý nghĩa Vì vậy việc nhiệm vụ đầu tiên của nhóm yêu cầu chính là tìm hiểu và làm quen với lĩnh vực ứng dụng của phần mềm mà khách hàng muốn có Ví dụ nếu

phần mềm là quản lý các chuyến bay của một hãng hàng không thì lĩnh vực cần tìm hiểu là cáchthức quản lý các chuyến bay của một hãng hàng không Nếu phần mềm là chương trình quản lýthư viện thì nhóm yêu cầu cần có hiểu biết nhất định về lĩnh vực thư viện Để sử dụng từ mộtcách chính xác, các thành viên nhóm yêu cầu cần tìm hiểu các thuật ngữ Ví dụ nếu họ đangchuẩn bị làm phần mềm trong lĩnh vực sinh học thì cần tìm hiểu các thuật ngữ về sinh học Mộttrong những phương pháp khắc phục vấn đề thuật ngữ là xây dựng bộ từ vựng về lĩnh vực ứngdụng Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầu cần tìm hiểu để hiểu được một cáchchính xác và đưa thuật ngữ này vào bộ từ vựng Sau khi đã có nhưng hiểu biết nhất định về lĩnhvực ứng dụng phần mềm, các thành viên bắt đầu khám phá, tìm hiểu các yêu cầu khách hàngtheo các cách thức sau:

lệ người được phỏng vấn có thể cho câu trả lời trong một phạm vi rộng, tuy nhiên cũng khôngnên rộng quá mà chỉ nằm trong phạm vi các thông tin cần nắm bắt Phỏng vấn có hiệu quả là

công việc không dễ dàng Điều kiện quan trọng đầu tiên là người phỏng vấn cần am hiểu về lĩnh vực mà họ chuẩn bị phỏng vấn Các câu hỏi đưa ra cũng phải hợp lý để người được phỏng vấn

có thể nói ra những thông tin có ích cần thiết một cách tự nhiên, không bị gò ép hay e ngại gì.Đôi khi những câu hỏi quá thẳng thắn và trực tiếp chưa chắc đã nhận được câu trả lời đúng Ví

dụ nếu hỏi rằng "lương anh chị rất thấp, nhưng chi tiêu thì có vẻ rất nhiều Anh chị hãy cho biếtlàm sao có được khoản tiền ngoài lương kia " thì thường là người được hỏi sẽ tìm cách né tránhcâu trả lời thật

Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quả phỏng vấn và nên đưacho người được phỏng vấn xem và góp ý kiến

5.1.2 Kịch bản (scenario)

Kịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu Kịch bản là mô tả các thao tác cầnthực hiện trên phần mềm cần xây dựng để hoàn thành một công việc nào đó (trong các công việc

Chương 5 Pha yêu cầu

mà phần mềm cung cấp)

5.1.3 Một vài kỹ thuật nắm bắt yêu cầu khác

Một kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu khách hàng là gửi các bảng câu hỏi cho một số thành viên đại diện của công ty khách hàng Bằng cách này có thể gửi cho hàng trăm

thành viên và có thể nhận được các câu trả lời dưới dạng viết và được suy nghĩ kỹ Tuy nhiênnếu từ bảng câu hỏi đã được trả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi thích hợpvới người được phỏng vấn thì có thể nhận được các thông tin bổ ích Đôi khi các thông tin này

có ích hơn nhiều so với trả lời viết đã có

Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môi trường kinh

doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sử dụng Ví dụ việc xem xét các

biểu mẫu được in ra trong phòng in ấn có thể biết được các dạng báo cáo, cỡ giấy; tài liệu viết vềcách thức điều hành hoặc mô tả công việc là những côngcụ rất hữu ích để giúp tìm ra công việc

gì đang được thực hiện và được thực hiện như thế nào ở công ty khách hàng

Gần đây người ta thường áp dụng thêm một phương pháp nữa là quay băng video cảnh làm việc

ở công ty khách hàng (tất nhiên là được sự cho phép của công ty và của những người đượcquay) Như vậy có thể biết được chính xác những gì đang xảy ra Tuy nhiên cách này có mộtnhược điểm là phải tốn khá nhiều thời gian để xem lại băng và phân tích để rút ra những thôngtin cần thiết Một nhược điểm rất lớn khác của phương pháp này là phần lớn những người đượcquay đề không thích mình xuất hiện trong máy quay và trở nên dè dặt khi hành động

Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng thì bước tiếp theo là phân tích các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp ích cho việc xây dựng phần

mềm

5.2 PHÂN TÍCH YÊU CẦU

Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu của các yêu cầu khách hàng Cácyêu cầu này được phân làm hai loại: chức năng (functional) và phi chức năng (nonfunctional) Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần xây dựng và thểhiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần mềm cung cấp chức năng tìm kiếmhàng hóa theo tên hàng và ngày bán" Đặc tả phi chức năng dùng để chỉ rõ tính chất nào đó củaphần mềm cần xây dựng, ví dụ tính tin cậy và bảo trì được; hoặc liên quan đến môi trường màphần mềm được sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím vàđược lưu trong một tệp bảng dữ liệu" Tóm lại yêu cầu chức năng là nói đến một công việc cụthể, thường thể hiện bằng các mục chọn trong chương trình; còn yêu cầu phi chức năng thì nói

về các tính chất của phần mềm, các tính chất này không thể thể hiện được bằng một việc cụ thể.Thí dụ từ câu "yêu cầu phần mềm phải có giao diện đẹp, thân thiện với người sử dụng" ta khôngthể nói được cụ thể là phải làm gì

Một điều rất quan trọng là phần mềm phải theo dõi được (traceable) Điều này có nghĩa là có thểkiểm tra xem tất cả các yêu cầu đã được thể hiện trong bản đặc tả chưa; điểm nào trong bản báocáo yêu cầu tương ứng với điểm nào trong báo cáo đặc tả Tương tự báo cáo thiết kế hay chươngtrình cũng phải tương ứng với các tài liệu trước đó Như vậy nhóm bảo đảm chất lượng phầnmềm có thể kiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã được thựchiện chưa

Tất cả các yêu cầu thu thập được ban đầu đề được đưa cho khách hàng xem xét Họ sẽ sắp xếpcác mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệu chỉnh những điều không chính xáchoặc bỏ đi những mục không cần thiết

Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏng vấn và xem xét lạicác vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sót không Và như chúng ta biết, kỹ thuậtphân tích yêu cầu hiệu quả và chính xác nhất là làm bản mẫu, vì vậy nếu có thể thì nhóm chuyểnqua bước làm bản mẫu để đưa cho khách hàng xem xét một cách trực quan hơn

Chương 5 Pha yêu cầu

5.3 LÀM BẢN MẪU (PROTOTYPING)

Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất.

Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chức năng quan trọng nhấtcủa phần mềm cần xây dựng Mục đích của bản mẫu là thể hiện các yêu cầu khách hàng, do đókhi xây dựng người ta chú ý nhiều đến giao diện và các báo cáo in ra Những vấn đề quan trọngkhác mà một phần mềm sản phẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc độ tínhtoán, kiểm tra và khắc phục lỗi đều chưa được chú ý khi làm bản mẫu; nghĩa là bản mẫu chỉ làthể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu Bản mẫu được cài đặt đểkhách hàng sử dụng thử Qua việc thao tác trực tiếp với bản mẫu, họ sẽ thấy được các chức năngcủa phần mềm đã thể hiện đúng các yêu cầu của họ chưa, cái gì cần thêm bớt hay hiệu chỉnh bổsung Những người phát triển sẽ hiệu chỉnh bản mẫu cho đến khi khách hàng vừa ý và cho rằngmọi yêu cầu của họ đã được bao hàm trong phần mềm (tất nhiên là về hình thức) Bản mẫu sẽđược dùng làm cơ sở để biên soạn tài liệu đặc tả

Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mục đích để ngườiphát triển và khách hàng thống nhất càng nhanh càng tốt những điều mà sản phẩm chính cầnlàm Như vậy có rất nhiều điều có thể bỏ qua khi làm bản mẫu Bản mẫu có thể thường xuyêngặp sự cố và phải khởi động lại; màn hình nhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếubiểu tượng công ty khách hàng,

5.4 TÍNH THÂN THIỆN VỚI NGƯỜI DÙNG CỦA PHẦN MỀM

Khách hàng thao tác với bản mẫu thông qua giao diện người sử dụng (user interface) hay còngọi là "giao diện người máy" (human-computer interface, HCI) Nên khuyến khích khách hànglàm quen và chú ý tới giao diện người máy Điều này có thể giúp cho sản phẩm sau này đạt được

"tính thân thiện với người sử dụng" (user-friendliness), một tiêu chẩn quan trọng của tất cả cácphần mềm Một phần mềm có tính thân thiện với người sử dụng có nghĩa là phần mềm đó dễhọc sử dụng cho cả những người ít hiểu biết về máy tính

Một chương trình thân thiện với người sử dụng thường bao gồm các yếu tố sau: dùng thực đơnhoặc các biểu tượng thay cho lệnh phải nhớ; luôn có sẵn trợ giúp màn hình mỗi khi ấn phím; cácchức năng của chương trình được tổ chức trên bàn phím theo một trật tự logic; các thông báo lỗi

có giải thích nguyên nhân và cách khắc phục; các tính năng trung gian và phức tạp được làm ẩn,không nhìn thấy để khỏi gây rối màn hình và lẫn lộn cho người mới học

Bản mẫu nên được xây dựng có giao diện người máy thân thiện với người dùng (user-friendlyHCI) HCI của bản mẫu gần giống với HCI của sản phẩm thật, như vậy sau này khách hàng sẽnhanh chóng làm quen với sản phẩm thật và cảm thấy là các yêu cầu của họ đã được đáp ứng

5.5 BẢN MẪU NHƯ MỘT KỸ THUẬT ĐẶC TẢ

Bản mẫu được sử dụng như một công cụ để xác định rằng các yêu cầu của khách hàng đã đượcnhận biết một cách chính xác Khi bản đặc tả hoàn thành và được ký duyệt bởi khách hàng thìvai trò của bản mẫu cũng kết thúc Tuy nhiên có một cách tiếp cận khác là người ta xem bảnmẫu như là đặc tả hoặc là một phần quan trọng của đặc tả Như vậy không cần tốn thời gian viếtbản đặc tả và những khó khăn thường gặp trong phần đặc tả như sự không rõ ràng, thiếu cácthành phần hoặc có sự mâu thuẫn sẽ không còn Vì bản mẫu thay thế đặc tả, nên ta chỉ cần ghichú rằng sản phẩm thật sẽ hoạt động giống như bản mẫu, đồng thời liệt kê thêm các đặc trưngkhác mà sản phẩm cần có như cập nhật tệp, bảo mật, xử lý lỗi Tuy nhiên việc sử dụng bảnmẫu như đặc tả cũng có nhiều nhược điểm khó khắc phục Đặc tả là tài liệu được khách hàng kýduyệt và là căn cứ để nhà phát triển và khách hàng ký hợp đồng Rõ ràng bản mẫu không thểthay thế vai trò này của đặc tả, không thể căn cứ vào bản mẫu để kết luận rằng điểm này hayđiểm khác của hợp đồng chưa được thực hiện đúng Cho dù phần mềm được phát triển trong nội

bộ cơ quan thì vẫn có thể có vấn đề nảy sinh giữa người phát triển và người quản lý Rõ ràng cácnhà phát triển không thể chỉ dựa vào bản mẫu để thuyết phục các nhà quản lý là họ đã làm đúngcác yêu cầu mà cơ quan đặt ra

34

Chương 5 Pha yêu cầu

Lý do thứ hai khiến cho việc sử dụng bản mẫu làm đặc tả bị hạn chế là vấn đề bảo trì Cho dù cóđầy đủ các tài liệu thì việc bảo trì bao giờ cũng là công việc khó khăn và tốn nhiều tiền của Nếuthiếu tài liệu đặc tả viết thì việc bảo trì thực sự trở thành cơn ác mộng Đặc biệt với công việcbảo trì nâng cao (enhancement), tức là thay đổi các yêu cầu ban đầu thì công việc thay đổi lạithiết kế đặc biệt khó khăn nếu không có tài liệu đặc tả

Vậy chỉ nên xem bản mẫu là một kỹ thuật phân tích yêu cầu Nó được sử dụng để bảo đảm rằngcác yêu cầu của khách hàng đã được nắm bắt một cách đầy đủ và chính xác Bước tiếp theo làdựa vào bản mẫu để biên soạn tài liệu đặc tả dưới dạng văn bản

5.6 CÓ NÊN SỬ DỤNG LẠI BẢN MẪU?

Thực tế cho thấy rằng cho dù về hình thức bản mẫu giống với sản phẩm thật và có thể hiệu chỉnh

để trở thành sản phẩm thật, nhưng về chất lượng thực sự thì bản mẫu và sản phẩm thật còn mộtkhoảng cách rất lớn Ví dụ như phần lưu trữ dữ liệu hay một số phần chất lượng cao như thuậttoán tối ưu, tính bảo mật, còn chưa có trong bản mẫu Kinh nghiệm cho thấy rằng nên thiết kếlại và xây dựng lại hoàn toàn phần mềm Chỉ nên sử dụng một số phần của bản mẫu được tạonên bởi các bộ công cụ CASE như bộ tạo màn hình (screen generator), tạo báo cáo (reportgenerator) Cũng có khi bản mẫu và bản chính không sử dụng cùng một ngôn ngữ lập trình.Trong trường hợp này thì việc viết lại hoàn toàn bản chính là điều khá hiển nhiên, không thểkhác được

5.7 SỬ DỤNG CÁC CÔNG CỤ CASE TRONG PHA YÊU CẦU

Có thể sử dụng một ngôn ngữ lập trình nào đó để viết bản mẫu Vai trò của bản mẫu là cầu nốigiữa người phát triển và khách hàng để người phát triển nắm bắt nhanh và đầy đủ các yêu cầukhách hàng Như vậy bản mẫu cần được viết càng nhanh càng tốt Người ta thấy rằng ngôn ngữlập trình thông dịch (interpreted language) khá thích hợp cho việc xây dựng bản mẫu, vì khôngmất thời gian để dịch hay liên kết như ngôn ngữ biên dịch (compiler) Tính hiệu quả được nângcao nếu công cụ CASE được liên kết cùng với ngôn ngữ lập trình Các ngôn ngữ có hỗ trợ công

cụ CASE như Smalltalk, Java, Perl (Practical Extraction and Report Language) có thể sử dụng

để xây dựng bản mẫu nhanh và hiệu quả HTML cũng là một ngôn ngữ làm bản mẫu được ưachuộng Nếu bản mẫu chắc chắn được vứt đi thì HTML còn một lợi điểm nữa: thật khó hìnhdung sản phẩm chuyển giao lại được viết bằng HTML, như vậy việc viết bản mẫu bằng HTMLgần như được ngầm hiểu là bản mẫu sẽ được vứt đi

Trong những năm gần đây một số ngôn ngữ lập trình thuộc thế hệ thứ 4 (fourth-generationlaguage, 4GL) như Oracle, PowerBuilder và DB2 cũng được sử dụng để làm bản mẫu Mụcđích thiết kế của hầu hết 4GL là viết ít dòng lệnh hơn cho cùng một chức năng so với ngôn ngữthế hệ thứ 3 như Java, Ada hay C++ Phần lớn 4GL là thông dịch và được hỗ trợ các công cụCASE tính năng cao, do đó làm tăng tốc độ xây dựng bản mẫu

Tuy nhiên 4GL cũng có nhược điểm Môi trường CASE trong đó 4GL được nhúng thường làmột phần của một tập hợp lớn hơn các công cụ được sử dụng cho một quy trình phần mềm đầy

đủ (complete software process) Các nhà cung cấp 4GL thường khuyến khích sử dụng ngôn ngữcủa họ làm bản mẫu, sau đó hoàn thiện dần thành bản chính thức Các nhà cung cấp không nhậnthức được rằng bằng cách này quy trình phần mềm có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh (build-and-fixed model) Đáng tiếc là các nhà cung cấp 4GL muốn khách hàng muasản phẩm của họ và họ quảng cáo rằng công cụ CASE của họ có thể thực hiện mọi phần côngviệc của một dự án phần mềm

Giả sử rằng người quản lý dự án đã bỏ ra khá nhiều tiền để mua công cụ CASE hỗ trợ cho tất cảcác pha của quy trình phần mềm Thật khó thuyết phục họ bỏ thêm tiền để mua một ngôn ngữkhác để phát triển phần mềm chính thức và bỏ đi bản mẫu vừa mới xây dựng Tuy nhiên cần chỉcho họ thấy rằng cho dù như vậy vẫn còn rẻ hơn là cố giữ lại bản mẫu và phát triển nó thành sảnphẩm chính thức Sẽ tốn một số tiền khổng lồ cho việc chuyển đổi bản mẫu thành bản chính thức

và bảo trì sau này

Chương 5 Pha yêu cầu

5.8 CÓ KHÁI NIỆM YÊU CẦU HƯỚNG ĐỐI TƯỢNG KHÔNG?

Mục đích của pha yêu cầu là xác định các nhu cầu thực của khách hàng, nghĩa là xác định xemchức năng của hệ thống cần xây dựng là gì Pha yêu cầu không đề cập đến việc hệ thống sẽ được

xây dựng như thế nào Như vậy ở đây không nói đến phương pháp hướng đối tượng hay phương pháp cổ điển, không có khái niệm "yêu cầu hướng đối tượng" Tài liệu sử dụng (user manual)

trong pha này chỉ nói đến việc người sử dụng cần thực hiện các bước thao tác như thế nào khichạy chương trình, chứ không nói đến việc phần mềm được xây dựng như thế nào Như vậytrong pha yêu cầu chỉ trả lời câu hỏi là "phần mềm làm gì" , còn cách thức mà phần mềm đượcxây dựng thì chưa nói tới Cho dù trong pha yêu cầu người phát triển phải xây dựng bản mẫu thìmục đích của họ là bằng cách nào đó xây dựng nhanh bản mẫu thể hiện được các chức năng màkhách hàng cần Có thể họ sử dụng một ngôn ngữ cổ điển như C hay Lisp, hoặc thậm chí ngônngữ hỗ trợ hướng đối tượng như C++, nhưng họ chưa quan tâm đến việc thiết kế các lớp saocho hợp lý, nghĩa là về thực chất không thể nói bản mẫu được viết theo phương pháp hướng đốitượng hay không

5.9 TÓM TẲT CHƯƠNG

Thực hiện pha yêu cầu như thế nào?

Nắm bắt yêu cầu (requirements elicitation):

- Phỏng vấn các thành viên của công ty khách hàng để xác định nhu cầu của họ (determine theirneeds)

Phân tích yêu cầu (requirements analysis):

- Viết tài liệu ghi lại các yêu cầu sơ khởi của khách hàng (preliminary requirements)

- Tinh chế lại tài liệu yêu cầu khách hàng (refine the requirements document)

- Xây dựng bản mẫu thể hiện các chức năng cơ bản của phần mềm cần xây dựng

- Hiệu chỉnh bản mẫu theo sự góp ý của các thành viên của công ty khách hàng được lựa chọndùng thử bản mẫu

5.10 PHA YÊU CẦU: TÌM HIỂU VẤN ĐỀ AIR GOURMET

Gourmet theo tiếng Anh có nghĩa là người sành ăn, a gourmet restaurant có nghĩa là cửa hàng ănphục vụ những người sành ăn, tức là cửa hàng gồm các thức ăn chọn lọc Air Gourmet là dịch

vụ cung cấp thức ăn đặc biệt cho các hành khách trên các chuyến bay Để đơn giản trong cáchviết, từ đây đôi lúc thay vì viết đầy đủ Air Gourmet, chúng tôi chỉ viết là AG

Rất nhiều hành khách đi máy bay có nhu cầu ăn kiêng, và mỗi hãng hàng không đều cố gắngcung cấp thức ăn theo yêu cầu của khách, để níu kéo số hành khách đặc biệt này cho công ty củamình Việc phục vụ thức ăn đặc biệt có một số đặc điểm sau đây:

1 Chi phí cho việc phục vụ thức ăn đặc biệt thường cao hơn so với thức ăn thông thường

2 Vì thường số người yêu cầu thức ăn kiêng rất ít, nên không thể tăng doanh thu bằng cáchđặt mua loại thức ăn này với số lượng lớn

3 Rất ít công ty hàng không chuẩn bị thức ăn kiêng trong nhà bếp của họ, mà họ thường đặtmua ở một nhà hàng khác, do đó chi phí bị đẩy lên cao

4 Nhiều truờng hợp khách hàng đặt chỗ và đặt thức ăn đặc biệt xong lại chuyển sang đichuyến khác Như vậy thức ăn đặc biệt dành cho họ lại được một người khác sử dụng

5 Đôi khi thức ăn đặt rồi nhưng do một số sai sót nên không đưa đến được đúng người yêucầu

Công ty Air Gourmet rất tự hào về dịch vụ cung cấp thức ăn trên các chuyến bay của họ Chođến nay lợi nhuận của AG được bảo đảm nhờ vào việc khách hàng luôn vui lòng trả số tiền caohơn giá vé một chút để đuợc dùng thức ăn đặc biệt Tuy nhiên gần đây thì đường biên lợi nhuận

có phần chao đảo, và các nhà điều hành AG đang tìm cách giảm bớt chi phí Họ nhận ra rằng chỉ

36

Chương 5 Pha yêu cầu

có một tỷ lệ nhất định các thức ăn đặc biệt đến được đúng người yêu cầu

Trước khi thực hiện một biện pháp nào đó, các nhà quản lý muốn có được số liệu tin cậy liênquan đến sự thành công hoặc thất bại của dịch vụ cung cấp thức ăn đặc biệt Bởi vì thức ăn đặcbiệt được cung cấp bởi một số nhà hàng bên ngoài, nên AG ngờ rằng chất lượng thức ăn khôngđạt được chuẩn như các nhà bếp của AG vẫn làm Vì vậy một cuộc khảo sát ý kiến khách hàngcần được thực hiện để xác định thái độ khách hàng về loại thực ăn này AG cũng muốn biết rằng

có bao nhiêu phần trăm thức ăn đặc biệt đã không được đưa được đến đúng khách hàng yêu cầu.Giống như các hãng hàng không có phục vụ thức ăn kiêng, 24 giờ trước mỗi chuyến bay, cơ sở

dữ liệu của hệ thống đặt chỗ của AG được truy cập và các báo cáo được in ra để các nhà cungcấp chuẩn bị và chuyển thức ăn đặc biệt đến đúng chuyến bay Ngay sau khi máy bay cất cánh,danh sách những hành khách ăn kiêng sẽ được in ra trên máy bay Báo cáo này bao gồm mã sốđặt chỗ, họ tên, số chỗ ngồi, loại thức ăn mà họ yêu cầu (Hành khách khi lên máy bay cần xuấttrình một loại phiếu quy định, do đó máy tính trên máy bay có đủ thông tin để in báo cáo này)

Để có thể nhận được các thông tin do các nhà quản lý yêu cầu, cần phải hiệu chỉnh lại phần mềm

của AG Trước hết, cứ mỗi lần có yêu cầu đặt thức ăn đặc biệt thì cần ghi lại các thông tin sau:

mã số đặt chỗ, số chuyến bay, ngày, giờ, họ tên và địa chỉ hành khách, loại thức ăn kiêng đượcđặt Các thông tin này là cần thiết để phần mềm mới sử dụng khi phân tích số liệu về thức ăn

kiêng Thứ hai, danh sách các món ăn kiêng được in trên máy bay cần có thêm một cột gồm

các ô vuông bên cạnh Hành khách tương ứng sẽ đánh dấu vào ô vuông nếu họ nhận được thức

ăn đúng yêu cầu Sau chuyến bay, danh sách các món ăn sẽ được duyệt qua Đối với phiếu cóđánh dấu, hành khách tương ứng sẽ nhận được phiếu đánh giá và họ có thể đánh giá chất lượngthức ăn từ 1->5 (kém nhất đến tốt nhất) Thông tin phản hồi này sẽ được lưu vào cơ sở dữ liệu

để xử lý sau này

Như vậy, cần thực hiện 3 bước nối tiếp nhau để phân tích số liệu về thức ăn kiêng: thông tin vềcác thức ăn kiêng được in ra 24 giờ trước khi máy bay cất cánh, xử lý các phiếu dùng để đánhdấu các hành khách đã nhận được thức ăn yêu cầu, và xử lý các phiếu đánh giá chất lượng thứcăn

Dữ liệu được ghi lại theo khuôn dạng sau đây:

Mã số đặt chỗ (Reservation identifier)

Số chuyến bay (Flight number)

Ngày bay (Flight date)

Số ghế (Seat number)

Họ tên hành khách (Passenger name)

Địa chỉ hành khách (Passenger address)

Thức ăn đặc biệt (Special meal type)

Hành khách có mặt trên chuyến bay không? (Was the passenger on board the flight?)

Thức ăn kiêng có được phục vụ không? (Was the special meal loaded?)

Điểm đánh giá chất lượng thức ăn của hành khách (Perceived meal quality)

Phần mềm mới cần lưu thông tin vào cơ sở dữ liệu và cho phép người dùng lựa chọn in bốn báocáo Với mỗi báo cáo, người sử dụng cần nhập thời gian bắt đầu và thời gian kết thúc Bốn báocáo như sau:

1 Với mỗi loại thức ăn đặc biệt cụ thể, cần in ra các thông tin sau:

Tỷ lệ phần trăm loại thức ăn này được được đưa đến cho khách hàng (trên tổng số lần thức

ăn này được đặt)

Tỷ lệ phần trăm thức ăn này được đặt trên tổng số lần đặt

Phòng quan hệ khách hàng (Customer Relation Department) cần các thông tin sau:

2 Họ tên và địa chỉ của tất cả các khách hàng có ít nhất hai lần không nhận được thức ăn đãđặt trong khoảng thời gian in báo cáo và thời điểm mà những lần này xảy ra

3 Họ tên và địa chỉ của tất cả các khách hàng, những người cho rằng thức ăn họ nhận được

Chương 5 Pha yêu cầu

không phải là tốt nhất, điểm đánh giá và thời gian mà những lần này xảy ra

Các nhà hàng cung cấp thức ăn nhạt cần biết một số thông tin để điều chỉnh chất lượng thức ăncủa họ:

4 Với loại thức ăn nhạt (low-sodium meal), in ra số chuyến bay, ngày bay và điểm đánh giá

Các nhà quản lý công ty Air Gourmet rất quan tâm đến độ rủi ro khi phải hiệu chỉnh lại phầnmềm đã có bằng cách thêm vào một số chức năng mới Họ cũng rất miễn cưỡng khi phải muamột số máy quét (scanner) dùng để quét các phiếu nhận được từ hành khách (phiếu đánh dấukhách hàng nhận được thức ăn hay không và phiếu cho điểm) Yêu cầu phần mềm là được sửdụng bằng bàn phím và có tính độc lập cao, có thể nhập các yêu cầu đặt chỗ, kiểm tra hànhkhách, quét danh sách các thức ăn đặc biệt được in trên máy bay (thay cho thao tác nhập từ bànphím), quét các phiếu đánh giá và đưa ra nhiều dạng báo cáo khác nhau Để công việc được bảođảm tin cậy, công ty Air Gourmet đã thuê một công ty phần mềm bên ngoài phát triển phầnmềm này

38

CHƯƠNG 6 PHA ĐẶC TẢ CÓ CẤU TRÚC

Pha đặc tả hay còn được gọi là pha phân tích, là pha tiếp theo pha yêu cầu Nếu gọi là pha phântích thì dễ nhầm với giai đoạn phân tích yêu cầu trong pha yêu cầu, do đó người ta thường gọi làpha đặc tả (specification) Tài liệu báo cáo của pha này phải thỏa mãn hai yêu cầu trái ngượcnhau Một mặt, tài liệu phải rõ ràng, dễ hiểu đối với khách hàng, thường là những người khôngphải là chuyên gia máy tính Mặt khác, tài liệu đặc tả lại phải đầy đủ và chi tiết, bởi vì đây gầnnhư là nguồn duy nhất để soạn thảo thiết kế Như vậy tài liệu đặc tả là mô tả sản phẩm trong mộtkhuôn dạng không mang tính kỹ thuật quá, sao cho có thể dễ hiểu đối với khách hàng, nhưngđồng thời cũng phải đủ chính xác sao cho căn cứ vào đó có thể xây dựng được phần mềm không

có lỗi và đúng như yêu cầu của khách hàng Chúng ta sẽ tìm hiểu hai kỹ thuật đặc tả: kỹ thuật

cổ điển hay còn gọi là kỹ thuật đặc tả có cấu trúc (hoặc còn gọi là phân tích có cấu trúc) và

phân tích hướng đối tượng Chương này chúng ta sẽ tìm hiểu kỹ thuật đặc tả có cấu trúc, còn

trong chương 7 tiếp theo ta sẽ nghiên cứu kỹ thuật đặc tả hướng đối tượng hay còn được gọiđơn giản là phân tích hướng đối tượng Lưu ý rằng trong thuật ngữ "phân tích có cấu trúc" thì từ

"cấu trúc" đóng vai trò tính từ bổ nghĩa cho phân tích Thuật ngữ này được dịch từ tiếng Anh là

"structured analysis" hoặc "structured specification" Như vậy nếu dịch đúng thì phải là "phântích theo kiểu cấu trúc" Từ "cấu trúc" ở đây khác với ý nghĩa của từ "cấu trúc" trong câu "phântích cấu trúc câu", vì trong câu này thì từ "cấu trúc" là danh từ Thuật ngữ "phân tích hướng đốitượng" cũng được dịch từ thuật ngữ tiếng Anh là "object-oriented analysis", và cũng có nghĩa là

"phân tích theo kiểu hướng đối tượng" Như vậy, cùng một hệ thống cần xây dựng, nhưng ta cóthể nhìn nhận và xem xét hệ thống đó theo phương pháp cấu trúc hoặc theo phương pháp hướngđối tượng Để bạn đọc tránh được sự hiểu nhầm, chúng tôi đôi khi sẽ gọi là "phân tích (hay đặctả) theo phương pháp cấu trúc" và "phân tích theo phương pháp hướng đối tượng" Tuy nhiênthường thì chúng tôi cũng viết đơn giản là "phân tích có cấu trúc" và "phân tích hướng đối

tượng" như các tài liệu khác thường sử dụng Chúng ta sẽ sử dụng khá nhiều lần thuật ngữ "hệ thống" Từ "hệ thống" ở đây là nói tới phần mềm cần xây dựng được đặt trong môi trường nó

được ứng dụng Cho nên ta nói "phân tích hệ thống" có nghĩa là ta xem xét chương trình cầnxây dựng cùng với các yếu tố liên quan Ví dụ với chương trình quản lý bán hàng thì ta xem xétchương trình cùng với các thao tác liên quan đến người bán hàng và khách hàng Tóm lại khinói "phân tích hệ thống" thì ta hiểu đó chính là phân tích phần mềm cần xây dựng

6.1 TÀI LIỆU ĐẶC TẢ

Ta đã biết rằng tài liệu trong pha yêu cầu hoặc là bản mẫu, tức là chương trình trong đó chỉ chú

ý đến giao diện, cốt thể hiện được các yêu cầu của khách hàng; hoặc là tài liệu mô tả các yêu cầu

của khách hàng được viết bằng ngôn ngữ tự nhiên Nhiệm vụ của pha đặc tả là mô tả phần mềm

thực hiện các yêu cầu đó Phải mô tả đầy đủ và chi tiết sao cho có thể dựa vào đó để đánh giáphần mềm sau này có đáp ứng được yêu cầu đặt ra hay không Tài liệu đặc tả còn là cơ sở để

thực hiện thiết kế Nếu như tài liệu đặc tả trả lời câu hỏi "phần mềm phải làm những việc gì?" thì tài liệu thiết kế lại đưa ra câu trả lời cho câu hỏi "phải làm những việc đó như thế nào?".

Vào những năm 60, 70 của thế kỷ trước, người ta vẫn dùng ngôn ngữ tự nhiên để viết tài liệuđặc tả Tuy nhiên người ta phát hiện ra rằng tài liệu biên soạn theo kiểu như thế này rất hay cólỗi và có nhiều điều mập mờ Ví dụ chỉ với tài liệu đặc tả của Naur (1969) cho vấn đề xử lý vănbản mà từ đó có thể viết thành chương trình khoảng từ 25 đến 30 dòng lệnh, người ta đã pháthiện ra nhiều lỗi Trong năm 1985, Mayer đã viết một bài báo nói về vấn đề này Mayer đưa ra

kết luận rằng nếu dùng ngôn ngữ tự nhiên để viết đặc tả thì sẽ dẫn đến tình trạng tài liệu đặc tả chứa đựng các mâu thuẫn, những điều nhập nhằng không hiểu được nghĩa chính xác hoặc bị thiếu, không đầy đủ Ông đề nghị sử dụng các thuật ngữ toán học để biểu diễn đặc tả một cách

hình thức Mayer đã dùng cách này để đặc tả vấn đề xử lý văn bản và từ đặc tả toán học ông đãchuyển đổi thành đặc tả bằng tiếng Anh Tuy nhiên người ta lại tìm thấy những điều nhập nhằngtrong đặc tả tiếng Anh này Vậy ngôn ngữ tự nhiên không phải là cách thức tốt để biểu diễn đặc